Hope the attached log will help to clarify the circumstances. I disabled energy reports from my network devices otherwise it would have 10 times more entries.
rule "Remote Functions"
when
Item ZWaveNode35SoftRemoteRemoteControl_SceneNumber received update
then
if (ZWaveNode35SoftRemoteRemoteControl_SceneNumber.state == 3.3)
{
logInfo("Remote Functions", "Rule: Button3 DoubleClick")
if (ZWaveNode29ZW096SmartSwitch6_Switch.state == ON)
{
sendCommand(ZWaveNode29ZW096SmartSwitch6_Switch, OFF)
}
else
{
sendCommand(ZWaveNode29ZW096SmartSwitch6_Switch, ON)
}
}
end
Mention everything is working fine. The only problem is if i did not interact with any device for a long time (1h) i have delay from remote trigger (NODON) until the physical state changed. The INFO logs seems to be in realtime. So if i push the button a few ms later i got the log from rule and a INFO log from your binding to. BUt the physical state changes after 5 seconds and more. This happens after long inactivity.
The scene is received, and the OFF command is sent, and then the response from the device is received? All this happens in under 1/2 a second. Or am I missing something?
It’s strange that it’s exactly 5 seconds. There are 2 places I know of where there are 5 second timeouts - either a timeout in the ZWave binding, or in the framework. I don’t think this is a zwave issue - there’s no timeout messages in the logfile, and in the log above the STATE UPDATE message is sent immediately, and the COMMAND RECEIVED is 5 seconds later.
So, there are other threads on this sort of thing -:
I don’t know if this is related or not, but it might be worth looking there?
Here is a snippit from the log when polling my NODE 33. The humidity value returned is 147 which doesn’t seem to make sense since it should be a percentage. I can provide more complete logs and create a ticket on your site if that makes more sense since this is a small excerpt. Of the three thermostats I have, only one provides a legitimate value. I would say it was a possible issue with the device database if it weren’t for one thermostat that appears to work. I haven’t had any issues reading humidity from these thermostats in the past.
Value returned:
2017-04-17 09:07:29.015 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 33: Got a value event from Z-Wave network, endpoint = 2, command class = COMMAND_CLASS_BASIC, value = 147
2017-04-17 09:07:29.015 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 33: Updating channel state zwave:device:93af1255:node33:sensor_relhumidity2 to 147 [DecimalType]
It’s returned as a BASIC message and in hte database this is linked to the sensor - maybe this is wrong and the message shouldn’t be linked to BASIC, or maybe the sensor is actually returning dud data, but based on the current configuration, the binding appears to be doing the right thing…
I’d suggest that possibly removing the BASIC class link might be a good move.
Wow, thanks! I updated my thing definition in the jsondb and that worked! Since things now look good for all 3 of my devices, I just updated the device database on your site.
Even though I opened in the wrong version, I see you already added it so won’t reopen it in the correct version. Thanks!!
Question, is there anyway to reference the labels in a rule? Just thinking ahead to when you have time to add the ability to get the user code entered during an Alarm Notification event.
Just in case anyone else ends up with this issue. I’ve had it happen twice, and both times I stopped openhab, deleted the Userdata/Cache directory and it worked on a restart.
I’m not sure - I doubt it. They are stored as parameters, so if the new rule system has the ability to access things parameters, then yes ;). I don’t think it’s possible right now though… There are other ways - using direct access to the REST interface, but it’s not nice.
One thing I noticed from @shawnmix logfile is that his log has 200 user codes. The binding will download these each time it starts - this takes quite a long time - if you’re restarting the binding multiple times per day (as you might be at the moment) I could imagine this could impact battery quite considerably.
Under more routine operation, it should be fine as it won’t talk to the lock very often.
Sorry, what I was asking is that when you add the ability to get the userid # that comes as part of the alarm event notification string from the device, instead (or in addition) to just returning the 1-30 userid #, is it possible to return the label associated with that userid? Does that make more sense?
This is not so simple - how would you propose to do this? Would you propose to have multiple items - one with the alarm, one with userid, one with user name? How would you then use these? How would you tie them to a specific event so that you know you have a consistent set for data for a single alarm???
I’m not just asking these questions to be a pain ;). I’m quite interested in this as it’s a question I have myself, and I’ve recently raised this on the ESH forum so I’m interested in ideas.
