Splitt receivingState into RSSI & repeater count

[dominikkv]

I think of splitting the channel "receivingState" into its parts RSSI & repeater count to log these values in database, to see anomalies. I think the best would be to remove "receivingState", because one can build this string on his own.

I'm open for discussion :-)

[fruggy83]

That is a good idee. Another interesting information could be the last update timestamp. What do you thing should we add this too or do we have other easy options to get this information?

[dominikkv]

I have also thought about the last update timestamp in the context of this issue :-D This is definately an important maintenance factor. But I think we have to think about these points:

• Let's call it "last received", because updates can be performed through OH. We are intrested in the time when we received a message, not when the user changed an item state in OH.
• This channel would represent the last time OH received a telegram from the thing, so the scope is the thing, not an item.
• Let's keep in mind that this can be also done by the persistence layer or a rule.

Never the less, to be more user friendly, I think we should implement it.
Another question, I'd like to implement these channels as basic channels which every EnOcean Thing has, so we do not have to declare those channels on each individual thing type. That would lead to a situation where even things only used to send messages would have those channels. Is that OK?

PS: I have opened a discussion about meta channels in the forums:
https://community.openhab.org/t/metadata-for-things/62037

[dominikkv]

So the first implementation of the three channels is in branch 37-metadata. I haven't deleted the old receivingState channel still exists, because I'd like to wait until the other branches are merged into master to avoid conflicts. The plan is to remove the channel from all EEPTypes.

[dominikkv]

Old channel deleted & PR created.