You could set an timestamp for the update. I had some help last night doing this.
In this way I can tell from an “virtuel” item, when an action (ie item, could be channel as well I guess) has updated. I suspect you could set a state insted of a date/time for this “virtuel” item…
Anyway, have a look at this:
That is very uncommon. I have a lot of different brands (Fibaro, Everspring, D-Link, …) which all send proper updates, even the cheap ones from Shenzen Neo.
Also note that you can switch a lot of devices from Switch Binary to Notification Reports which may help.
Do you have a link to the database for one of those devices?
I would suspect they have to trigger in some way, before they´ll send update, specially if they´re motion sensors.
Temperatur, humidity, lumiance etc will send an update either in a specific time or a from threshold, both are part of the z-wave device configuration.
The binding will normally poll channels every 30 minutes (unless this is changed), so it’s unclear why this should be needed?
Hi chris,
I just want to know via a rule, if the device is still there. I use a lot of door/window sensors. One of my windows is not so often opened. Therefore no report was send due to open/close of the window. All my other sensors send a battery update every 4h. Only this type not.
I have a rule which catches this battery update and sets a last_update Item corresponsing to it. This works perfect. But not for this one z-wave device (Aeon Labs). It sends battery updates only if battery value is changed. If nothing happen, the device is silent and I do not know if it is still alive.
Yes I can take a lock at habmin to know if it is already there but this will not help my rule. In the log I see the update message from that device, but my rule did not trigger.
I follow you on this one… Actually I had the same idea the other day…
What if a z-wave device (or any other device) goes offline. How will I know, (except something probably wont be working ofcouse) ?
The binding knows. But I don´t see any way to catch this statement, which I believe would be a great way to handle this, or??
You will know if watching the Thing status for offline/online:
03-Jul-2018 16:11:13.475 [INFO ] [org.eclipse.smarthome.model.script.EXTRA ] - ON_OFFLINE: node 44 offline
03-Jul-2018 16:11:59.348 [INFO ] [org.eclipse.smarthome.model.script.EXTRA ] - ON_OFFLINE: node 44 online
03-Jul-2018 16:41:12.983 [INFO ] [org.eclipse.smarthome.model.script.EXTRA ] - ON_OFFLINE: node 44 offline
In the above log I tested that with a power plug so I did not have to flip fuses or pull the batteries.
The only (little) downside: you will have to wait for the bindings polling interval (30 min)
But this is not very optimal way of doing it. One can not sit and look at habmin/paperUI evert half hour (or even more, as you can change the polling time).
Like Homeautomatic mention, he got windows which are seldom opened. In that situation, not even operating the window would discover if something is wrong with the device, (ie offline).
It doesnt seem very safe to me, since there isn´t a control wether or not a device is online. Polling for battery state may be a good idea. But the missing part is:
What if…
A device is offline for some reason?
I for sure would like to get a notification the minute a device goes offline, and not wait untill I discover it from either habmin/paperui or some trigger state telling me it hasn´t updated for ages.
@chris isn´t it possible to get an offline/online state directly from the binding?
Again: watch the Thing status.
Or you are using the wrong term: you want to know if a device does not send data anymore. That is a whole different story. I already posted a solution above:
That would not make sense at all. Do you expect every developer to add the same code to each and every binding?
You need to open a feature request in the ESH core repo if you still think that is what your need:
If you want to know when the binding marks the thing as offline, that is exactly what the Thing status trigger is for:
Thing "zwave:device:uzb:node26" changed to "Offline"
If that’s not what you’re after I dont’t understand what is.
Of course - the binding can potentially do anything and everything, but if we start adding “system” functionality to the binding, then we don’t need the framework. These sort of functions are the domain of the overall system, and I believe it’s already available as we have had exactly this discussion a few times in the past.
Sorry I misunderstood when you previous wrote “watching” the status. I thought you meant watching in habmin/paperui.
I wasn´t aware that there is a trigger for thing offline. If thats the case, I see no problem using that one, ofcouse.
1 Like
This was indeed what I was looking for. I didn´t know it already were there.
While it might seem a little off-topic at first glance, let me also throw in that there’s always a chance of a sensor to respond but to deliver bad values. That’s even worse than no response at all.
And it means it is not sufficient to watch a thing or item’s state but you have to come up with some sort of “active” validation rule framework anyway.
For the window sensor case, you might want to issue a refresh from within the validation routine, sensor should respond on next wakeup then. That interval should be configurable or it can even do FLiRS (Aeon devices IIRC don’t support FLiRS).
See this thread.
For the general case, see my presentation on last Smart Home day.
[I noted the link is offline, so here’s copies of two slides just to get you an idea, it applies to sensors in general]
-
False positives
Animals crossing, left mobile at home / in car, devices left on, … -
False negatives
Out of power
Out of connectivity: outdated values -
Bad values
Improper deployment/use/config:
Reed sensors too far away from magnet, temperature sensors in the sun or next to heat sources, light reflections to affect luminance sensors etc, non-suitable value range, … -
peaks, misses, misreadings due to outer and inner noise
Inappropriate detection range/resolution/sensitivity: flapping, proper thresholds
============================
(what to do before using a sensor-delivered value)
- Combine the most reliable sensors for a detection purpose into a custom group and use group status
- Use lambdas to validate values before use
val Functions$Function1 validate [ double input | …… ] - use a moving average on sensors (motion detectors, analog sensors)
item.averageSince(now.minusMinutes(period)) - implement anti-flapping (binary) / hysteresis (numeric) sound volume, light level,…
!item.changedSince(now.minusMinutes(period)) - use quorum to fight false positives & negatives
Group:Number:SUM groupname
If you’re talking about analogue sensors, then yes, of course this can be done, but most notification sensors do not support refresh - it’s not supported in the ZWave standard.
For ZWave, this is basically defined by the wakeup period.
There are few devices that support FLiRS - I don’t know of any sensors that do this. Mostly it’s locks that have to be responsive, and there are some new thermostats also supporting FLiRS.
I mostly agree with you, Markus.
Validation is not always possible or suitable in my opinion. You have to make up, whats the reason for validating. In a security matter, it´s important. But it can be very complicated to validate devices like motion sensors and door/window sensors.
Validate values from motion or door/window sensors.
It is highly complicated and in my opinion almost impossible. A door/window sensor where someone has placed a very small magnet close to or directly onto the sensor, would be impossible to spot.
A motion sensor where someone placed a cover in front of the sensor is almost impossible as well.
Both kind of sensors will respond normally. A validation will have to rely on other devices/actions before it will make any sense. This leaves a door/window sensor or a motion sensor, which doesn´t open/trigger often, in a critical situation, in my opinion.
Sensor manipulation is a corner case and that’s not what I was referring to. Someone who is up to build a foolproof alarm system will not rely on single RF sensors and openHAB DIY programming.
Still, you can well validate even binary sensor values, it’s just a question of the amount of logic you’re applying on top.
You could for example combine a window sensor’s output with a motion sensor in the same room (or other sign of presence such as a light being turned on) and only ever do the alarming if both of them are triggering.
You could for example do persistence and calculate from historic data when the next update is due and what a likely value would be, or you could calculate an expected value or value-period combination, then only raise an alarm if the computed expectation isn’t met. And so on … it’s all just a matter of ‘big data’ computing. Point is, you can’t expect the binding or any other part of OH do it for you but you have to code that yourself in rules, based on your specific setup.
If it’s just about the OP’s request to detect sensor outage, that thing offline trigger is probably sufficient.
Agree.
Thats why I wrote…
In my opinion, that is the first step. Have a validation of wether the thing is online or not. There is no reason to rely on a rule with several things involved, if one of them are offline/not responding or even wrong data, as you mention…
So the offline/online statement has to be involved in some way. At least, thats my opinion.
Hi all. It’s been a while since the last post, but I have come across this issue myself. I have a NodON battery operated wall switch which does not report anything except: Thing ‘zwave:device:d106546d:node80’ has been updated when pressed.
I can work with that, and all I need is for a rule to use this as a trigger. Seeing as it shows up in the console, I can’t see why this doesn’t work:
Rule "ConLights"
when
Thing "zwave:device:d106546d:node80" received update
then
...
It would be great if there is a way to do this in a .rules file without having to resort to writing additional code to monitor the log file. Any ideas?
This works for me:
rule "online or offline"
when
Thing "allplay:speaker:507fe0c8-d42f-43dd-9ce0-2eb13e7323d3" changed or
Thing "allplay:speaker:6c1eb8f5-705a-4b8a-a7a9-18b765901eed" changed
then
logInfo("OnlineOrOffline", "speaker changed status")
end