Define a way to handle NULL values

[stedon81]

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]

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:

• logging: https://github.com/homieiot/convention/blob/homie5/convention.md#logging
• alerts: https://github.com/homieiot/convention/blob/homie5/convention.md#alert-topic

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

[stedon81]

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]

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:
openhab/openhab-addons#16307

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