Hi,
i have a Fibaro flood sensor with Aeotec USB Stick running with openhab3.
Unfirtunately I noticed that the flood sensor was not reporting anything for several days (also no flood alarms when tested).
Openhab showed the thing as online. This is something that I do not understand. The wake up interval was set to 21600 (6hrs), but the sensor was not communicating with the controller for several days - but still online.
Shouldn’t openhab set the device as failed when a device is not communication much longer than set in the wake up config?
So how would I get notified about an offline device ?
I look very forward for anything helpful,
Kindest regards,
Philip
Hi, thanks for pointing me to these topics.
I see there quite some different approaches, one of them asking of the thing status via REST, but that feels somehow wrong to me.
Point being is, that openhab shows my device as online, which is wrong in this case. In case that the wakeup is set to 6 hrs it just does not feel right to show the device as online when “zwave_lastwakeup” property is older than 6 days right?!
No and ultimately, as you have seen in those other threads, it is very dependant to your use case and the device in question. With a battery powered zwave device you may have to create something specific to your use case. I couldn’t find the thread but I remember a recent very similar issue. I think a timer was started every time the sensor checked in and after so many hours if the timer was not reset, a alert was sent.
this is the most worrisome part of your issue. Alarm that sends no alarm is well… useless
Note that a sensor can still be online even though it isn’t sending reports. I have a Zooz/Monoprice motion sensor that stops sending motion reports when the battery gets low. However, it’ll still send temp/humidity/light updates. It sounds like your Fibaro wasn’t even sending temperature reports, but it may have still checked in with your controller.
Instead of having a rule to inform me, I just use the timestamp profile to indicate when the last update occurred. That way, if I have a suspicion that a sensor isn’t reporting, I just have to check the timestamp.
Putting notifications aside, did you get the sensor working again? And if so, what was the fix? Notifications are nice, but you’d rather avoid the sensor failing in the first place.
Periodic reminder that a Thing ONLINE/OFFLINE status is about the openHAB Thing, and not about any device it roughly models. Best viewed as indicating that the pathway to the device looks okay; e.g.in the case of a zwave device, if and when device decides to report to OH then OH is ready and able to receive the message.
Users should implement other methods if needing a true device availability indicator.
The sensor was not even reporting flood alarms. A flood sensor that does not report a flood event is worth nothing, so it should not be shown as online imho. I hat to exclude and include the device again, because the sensor was not even able to communicate with the controller in a distance of 10cm.
“Periodic reminder that a Thing ONLINE/OFFLINE status is about the openHAB Thing, and not about any device it roughly models.”
That is a very important remark which I was not aware of.
That looks like custom implementation efforts again. May i ask whether there are extensions/plugins or whatever available which tackle this challenge already?
thanks for heling
No, because the whole point is that there are several thousand different devices using a hundred or so different methodologies to connect to openHAB. Even within a single technology like zwave, there are devices that could be polled and devices that cannot. There are devices that make periodic reports and those that do not. Those that do, may do so at arbitrary time intervals.
You ain’t going to get away from a requirement for a custom set up, because your corner of the world is unique to you.
I don’t have alerting set up for such cases, only a sitemap that shows which device has sent “anything” the last time.
Maybe this is something you can use in your setup as a basis, the only thing you would need to add is a rule that is triggered every few hours/minutes (as needed) that compares the “last-seen”-timestamps against the current time and send a message/mail/whatever if one of the devices is overdue.
My setup looks like this:
There are items defined for each device:
DateTime WC_Fenster_LastUpdate "Last seen [%1$ta %1$td.%1$tm. 1$tH:%1$tM]" <clock>
These items are updated by rules that are triggered by events from the respective device:
// WC_Fenster_LastUpdate
rule "last seen WC_Fenster"
when
Item WC_Fenster_Kontakt received update or
Item WC_Fenster_Hell received update or
Item WC_Fenster_Temp received update
then
postUpdate(WC_Fenster_LastUpdate, new DateTimeType())
end
Note that in the rule you can aggregate different events to update the item. The best choice would be a report the device sends regularly. Consult your event.log for events belonging to the respective device.
In my case the result is shown in a sitemap:
Text item=WC_Fenster_LastUpdate label="WC Fenster" valuecolor=[>172800="red",>86400="orange",<=86400="green"]
In your case you may want to check the state of the “last-seen” items for outdated timestamps. Group them into a group and use one of the methods documented in various threads to check each member of the group for an entry that is “too old”, alerting you in a way you prefer.
Just chiming in with what I’ve done to address this… for a given Thing called thingname I create a single Item called thingname_last_report. For each Channel I’m using on the Thing (say alarm_motion, battery-level, etc) I add a second Link to thingname_last_report and use the “Timestamp on update” profile. In theory, whenever there’s activity on any of the Thing’s Channels, it should write a fresh timestamp to thingname_last_report. Because it’s listening to all of the Channels on the Thing, this should be a rough proxy for the last time the Thing was known to be alive.
Each of these _last_report Items goes into a group called “Last reports” where I set the aggregation function to “MIN”. This way I can see at a glance which Thing hasn’t checked in for the longest period of time.
Next step would be a rule that notifies me if a Thing hasn’t updated its _last_report timestamp for some period of time, but I haven’t quite gotten that far yet.
Also as an aside related to @rossko57’s comment, I can only speak for this approach with Z-Wave devices. I hit the referenced bug with openweathermap in 3.0.2 as well, and it was definitely spiteful (brought my system to its knees), but haven’t tried to trigger it in 3.1.
I have MQTT event bus binding. So every time when Z-wave sensor reports some value it is published on event bus. If you have Nodered installed then simple trigger node with restartable delay as on config below, subscribed to sensor data, will do the job
E.g I have Aeon Multisensor, sending temperature/humidity reports every 10 minutes. Timeout of delay node is set to 25 mins. If sensor becomes dead (in my case it happened once due to Z-wave stick deadness) it triggers some actions - sends email that Openhab is dead in my case for example. Sorry is it is too specific to my setup.
Hi Stefan,
so do I understand right, that you would scan the event.log in order to get the latest_update_dates?
This means another scheduler would be required in order to do such a scan, right?
No Phil, I mentioned event.log only as a source of information to scan it manually for checking events (and thus assiciated channels) to use as a trigger in the rules that update the “last-seen” timestap-items.
As Russ pointed out, using the new timestamp-update profile may be less troublesome. I did not use that yet but will check it out later when time permits. Getting rid of explicit rules is always worth a test
