Most of my logic is outside Openhab (managed by NodeRED) but all states are on MQTT.
There are situations when some sensor is down and I want to reflect that in Openhab.
What value should I set in the MQTT topic to get the uninitialized state in Openhab? I tried all I can think of : empty, NULL, null, undefined etc… but in the log I have:
given new state is NULL, couldn't post update for ....
This is a bigger problem for Numbers. For the Strings most likely I can handle it from the MAP file.
NULL - indicates an Item is not yet initialized.
null - part of the language, indicates that a variable does not have a value.
UNDEF indicates something has gone wrong e.g. a calculation or communication failed. That’s distinct from NULL - never initialized yet.
For something like a sensor you might use expire binding to set state UNDEF if updates fail to arrive within N minutes/hours. That should work in case of sensor failure, MQTT failure, etc.
None of these works. I need it only for MQTT binding. There must be a magical keyword to set the value to “not yet initialized”
Open MQTT client and post a value toa a topic that is connected to a number item in OpenHab. OH only accepts a number otherwise it is ignored
Log is showing:
given new state is NULL, couldn’t post update for Water_pressure
For something like a sensor you might use expire binding to set state UNDEF if updates fail to arrive within N minutes/hours. That should work in case of sensor failure, MQTT failure, etc.
I have this logic in NodeRED but I can not tell the result to openHAB
That would be NULL.
All Items start out at system boot as NULL.
You might have persistence with restoreOnStartup for this Item, in which case it will get some previous value instead of NULL.
Once it’s been set to something else, you cannot set it back to NULL (not yet initialized) because it has been initialized.
You can update it to UNDEF.
For something like a sensor you might use expire binding to set state UNDEF if updates fail to arrive within N minutes/hours.
It’s an openHAB binding, nothing to do with NodeRED.
It’s really only useful if you get regular updates from the sensor. If you don’t get those, there’s no way to tell if its broken or not.
Thanks!
I was not aware of expire binding. I was looking for something like that fow a long time but I moved the logic to NodeRED before migrating from OH1 to OH2.
Seems like publishing UNDEF does work for numbers, for Strings it becomes “UNDEF” text but that is OK.
Are you sure this works??? If I send UNDEF:
mosquitto_pub -t /status/disinfection/ph/value -m UNDEF
I get:
2019-06-19 18:30:24.040 [WARN ] [eneric.internal.generic.ChannelState] - Incoming payload 'UNDEF' not supported by type 'NumberValue'
The Thing is defined as:
Type number : Disinfection_PH [ stateTopic="/status/disinfection/ph/value" ]
and the Item as:
Number Poupool_Disinfection_PH "pH [%.2f]" {channel="mqtt:topic:unsecure:poupool:Disinfection_PH"}
I’m using 2.5.0M1. I need to set some item to UNDEF via MQTT but nothing seems to work. I don’t want to use the expire binding if possible.
That’s right. Some string sent by MQTT isn’t going to fit in a Number Item.
We’re talking about openHAB internal states.
someNumberItem.postUpdate(UNDEF)
works fine, but it’s not a state you could send out over a binding either.
You can’t. If you send some valid value, then it’s a valid value and not really “undefined”.
You’ll need to consider sending some valid but “special” value for your purpose.
Thank you for your answer.
Oh I thought you were talking about sending UNDEF via MQTT.
Well, in some cases, I want my values to be “undefined” because the measurements do not make sense (e.g. in my case, the pH readings when the pool filtration is not running). I’m not a big fan of a “special” value (like 0 or -1 or MAX_INT or …) and UNDEF would be actually exactly this. I mean if the recommendation is to use the expire binding to set the items to UNDEF then I don’t see any reasons to not be able to explicitly set that value via MQTT (or any other protocol).
I’ll use the expire binding and not update the values I want to see UNDEF. Since I push the value at regular interval, that workaround should work fine.
This MIGHT work?? Curious to find out!
Use a string channel for incoming MQTT
Link it to a Number type Item - but with a JS profile
The profile needs to parse “normal” numeric data to pass to the Item
And also intercept your special value (which could be the string “UNDEF” and pass that as UNDEF
EDIT - while I think the basic idea is sound - it won’t work at present.
Transform profiles are currently limited to string output, so cannot be used to update a Number type Item.
You’d have to use a String type Item, and if you’re going to do that you may as well do it directly from MQTT and dispense with profile.
The thing about UNDEF is that it is meant to internally indicate invalid or unavailable data. As I outlined before, if a sensor is sending a message like “reading out of range”, then it’s not invalid data. The sensor is providing us with a valid state, as distinguished from it being broken or corrupt data.
Thanks for the hint. I just put some expire=“2m” to the relevant items 
I’ll try your suggestion later, time for bed now 
Thanks again for your support.