Thanks, is it working for update too?
Thing "zwave:device:xxx:node3" received update
instead of
Thing "zwave:device:uzb:node26" changed
Just try it 
I cannot try it, my things send only update notification, no change notification. I can see this in the log.
The question is, can you test it on your side. Because you have a running rule which is triggered by change and have a device which causes this. The update rule should be triggered too. If this is working on your side, I know that something is wrong on my side.
My z-wave items send only update messages no change in the log. Therefore my rule “changed” will never triggered.
I get no update events on the nodes, but changed events on openHAB restart.
So I guess you need to find something else for your usecase.
Do you only need this for number items? I’m using an expire binding function and a group for some of my temperature devices which works pretty well:
Group:Number:OR(UNDEF,NULL) gCheckSensorStates
Number Temperature (gCheckSensorStates) { mqtt="<[mosquitto:/esp8266three/temperature/rainwater:state:default]",expire="60m" }
rule "check sensor state"
when
Item gCheckSensorStates changed
then
if (gCheckSensorStates.state==UNDEF) {
val triggerItem = gCheckSensorStates.members.filter[ i|i.state==UNDEF ]
logInfo("EXTRA","No more data from: "+triggerItem)
}
end
I have some z-wave devices which do not send any updates without a trigger. For them I search for something to know if they are connected/active and not dead.
Most of my devices send a battery update within 4 hours. I catch thsi and update the corresponding last_update item. Some not. But I see
Thing 'zwave:device:xxx:node3' has been updated.
in the log for them. I tried to catch this message and update the last_update state of these device.
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.