Handling fault value from sensor

I’m doing some PoC for future home installation.
It’s all based on Arduino and OpenHab.
I’m having some issues on Arduino side but I’m trying to solve it on OH side.
My Arduino has attached dht12 sensor with i2c and sends information about temperature and humidity to OH. Sometimes Arduino can’t read one of those values so I’m sending value of 999 for feedback. In openhab I don’t want to see that value so I’m looking for a way to ignore it.
I know I can create dummy item and reassign value if it matches my expectations but I want to avoid it.
Is it possible to create some mapping that will ignore value of 999 or rule that triggers before using item?

This is the only way to handle it on the OH side.

So Just to let you know at 8:40 I have created rule:

    rule "hum_fix_value"
             Item kuch_hum changed to 999
             logInfo("heating-control.rules", "humidity fix")
             publish("broker", "dom/kuchnia/1/hum/cm", "1")

last line prompts humidity to resend value and now in events log I dont have 999 any more:

[2h gap is missing timezone configuration on OrangePI]

So it seems if we receive another value quite fast old - faulty value is not getting saved to events.log file or rrd4j persistance.

just make it the other way round:

your “real” value item is the Proxy one - and only gets updated if the value !== 999:

rule "hum_fix_value"
             Item kuch_hum changed
             if (kuch_hum.state !== 999) kuch_hum_proxy.sendCommand(kuch_hum.state)

that way your kuch_hum gets updated (and possibly persisted) on everychange - but you’ll only get your “real” proxy item updated with real values.

=> but best would be, you filter out the 999values in your arduino in the first place and you only send clean values…

Yes, that is what I was calling dummy item. Probably when OH grows it will be best solution but for now I like the one with requesting to resend value.
Fixing that on Arduino is for sure best solution but I need to find core issue with i2c and it takes me much more time as I don’t have much experience in electronics. Preventing sending dummy values out of Arduino will only hide issue not solve it. Also having a full picture in MQTT server is good for later hardware issues debugging.

This is not a correct statement. Every other line is showing it being set to 999. You are not eliminating the 999, you are just minimizing the amount of time the Item stays at 999. The fact that is is not saving to rrd4j implies you are not using an everyChange or everyUpdate strategy and just using a everyMinute strategy. If you are using everyChange and it isn’t saving the 999 to the db then this points to a bug in rrd4j. And if you are using everyMinute, it is only a trick of the timing that will prevent the 999 from being saved to the DB.

The only way, short of taking advantage of a bug, is to use a proxy Item. You cannot prevent the Item from being set to a received value that I can think of.

Wait, I just thought of something. You can use the regex_filter and use something like: ^(100|[1-9]|[1-9][0-9])$ which will match 100, any two digit number, and any single digit number. Since 999 doesn’t match that pattern it will not apply that message to the Item.

You are right. It seems core issue has solved itself as I simply dont get 999 any more. If I post mqtt with value 999 manually I can see it in events.log. Indeed I have rrd4j set to eachMinute so I dont see 999 at all.

Thanks for that filter. Will test it soon.

So I have ended up with proxy item. Filter was causing error message in openhab.log that item cannot be set to NULL.