search

homieiot / convention

🏡 The Homie Convention: a lightweight MQTT convention for the IoT
https://homieiot.github.io/
Other
705 stars 59 forks source link

Define a way to handle NULL values #284

Open stedon81 opened 6 months ago

stedon81 commented 6 months ago

Hi, if devices run into issues, like cannot measure a value correctly, there's no chance to communicate this to the controller (e.g. SmartHome system). Not updating the value means that the currently retained value will remain unchanged, which is a wrong information. I'd like to see a possibility to explicitly tell the controller that there is no value available. Unfortunately, currently this can only be done by defining a "special value" within the current value range that must be known by both devices and filtered out accordingly. For some applications, there is no value that can be excluded from the value range to serve this purpose.

Long story short: I'd like to see an update in the convention that defines a NULL value, irrespective of the data type.

Best regards, stedon81

Tieske commented 6 months ago

the status can be updated to "alert" to indicate this situation, see https://homieiot.github.io/specification/#device-lifecycle (in Homie5 this state has been removed).

In Homie5 there are alternatives:

Lastly one could define a specific property for error states, but that would be device specific.

stedon81 commented 6 months ago

Hi Tieske, Thanks for your answer and suggestions.

Your proposals would not meet the purpose intended. There might be devices that have a primary and a secondary purpose, i.e. a roller shutter that also reports room temperature. If the temperature cannot be determined, it would not be reasonable to set the whole's device status to an alert state although the primary function is still working normal. I understand that it would be possible to define elaborate enums describing all kinds of malfunctional states, reported via the alert topic. However, this still does not resolve the problem that the temperature property still contains an invalid value because the alert topic is not related to the temperature property. In case of OpenHAB as a receiver, it still would plot the wrong temperature into grafana charts although on the other channel the alert has been recognized. The user would need to explicitly write a rule to NULL the temperature item in case of an alert.

In my opinion, it still would be beneficial to have a possibility on a per-property basis to indicate that a retained value is not valid anymore .

Best regards, stedon81

stedon81 commented 5 months ago

Hi, obviously I'm not the only one requiring such a feature. OpenHab developers have included a respective functionality in their mqtt binding just recently: https://github.com/openhab/openhab-addons/pull/16307

Would be great if the Homie convention could be adapted accordingly. Cheers, Stefan D.