[SOLVED] Zigbee Binding: manually refresh the state of an item to get the actual condition of the hardware

[chris (Chris Jackson)]

@rlkoshak

I think OH core prevents one from sending a command to a Contact.

Sorry - I have not tested it, so if you know there is a limitation, then I assume it is correct.

[5iver (Scott Rushworth)]

@rlkoshak

Because I think OH core prevents one from sending a command to a Contact.

The only Contacts I have linked to Channels are zwave. There are messages that ‘Node doesn’t support get requests’, but at least for battery devices, this appears to work. Note, polling is started for all Channels, which may be a zwave binding specific “feature” .

events.sendCommand("US_MasterBathroom_Contact", "REFRESH")

2019-05-31 18:44:25.566 [DEBUG] [org.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 69: Command received zwave:device:07cb40a2:node69:alarm_entry --> REFRESH [RefreshType]
2019-05-31 18:44:25.566 [DEBUG] [org.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 69: Polling intialised at 1800 seconds - start in 50 milliseconds.
2019-05-31 18:44:25.617 [DEBUG] [org.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 69: Polling...
2019-05-31 18:44:25.617 [DEBUG] [org.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 69: Polling zwave:device:07cb40a2:node69:alarm_entry
2019-05-31 18:44:25.617 [DEBUG] [org.openhab.binding.zwave.internal.converter.ZWaveAlarmConverter] - NODE 69: Generating poll message for COMMAND_CLASS_ALARM, endpoint 0, alarm BURGLAR, event 2
2019-05-31 18:44:25.617 [DEBUG] [org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveAlarmCommandClass] - NODE 69: Node doesn't support get requests
2019-05-31 18:44:25.619 [DEBUG] [org.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 69: Polling zwave:device:07cb40a2:node69:alarm_tamper
2019-05-31 18:44:25.620 [DEBUG] [org.openhab.binding.zwave.internal.converter.ZWaveAlarmConverter] - NODE 69: Generating poll message for COMMAND_CLASS_ALARM, endpoint 0, alarm BURGLAR, event 3
2019-05-31 18:44:25.620 [DEBUG] [org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveAlarmCommandClass] - NODE 69: Node doesn't support get requests
2019-05-31 18:44:25.621 [DEBUG] [org.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 69: Polling zwave:device:07cb40a2:node69:battery-level
2019-05-31 18:44:25.621 [DEBUG] [org.openhab.binding.zwave.internal.converter.ZWaveBatteryConverter] - NODE 69: Generating poll message for COMMAND_CLASS_BATTERY endpoint 0
2019-05-31 18:44:25.622 [DEBUG] [org.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 69: SECURITY not supported
2019-05-31 18:44:25.622 [DEBUG] [org.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 69: Command Class COMMAND_CLASS_BATTERY is NOT required to be secured

events.sendCommand("US_MasterBathroom_Contact_Battery", "REFRESH")

2019-05-31 18:47:19.484 [DEBUG] [org.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 69: Command received zwave:device:07cb40a2:node69:battery-level --> REFRESH [RefreshType]
2019-05-31 18:47:19.485 [DEBUG] [org.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 69: Polling intialised at 1800 seconds - start in 50 milliseconds.
2019-05-31 18:47:19.535 [DEBUG] [org.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 69: Polling...
2019-05-31 18:47:19.536 [DEBUG] [org.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 69: Polling zwave:device:07cb40a2:node69:alarm_entry
2019-05-31 18:47:19.537 [DEBUG] [org.openhab.binding.zwave.internal.converter.ZWaveAlarmConverter] - NODE 69: Generating poll message for COMMAND_CLASS_ALARM, endpoint 0, alarm BURGLAR, event 2
2019-05-31 18:47:19.537 [DEBUG] [org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveAlarmCommandClass] - NODE 69: Node doesn't support get requests
2019-05-31 18:47:19.538 [DEBUG] [org.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 69: Polling zwave:device:07cb40a2:node69:alarm_tamper
2019-05-31 18:47:19.538 [DEBUG] [org.openhab.binding.zwave.internal.converter.ZWaveAlarmConverter] - NODE 69: Generating poll message for COMMAND_CLASS_ALARM, endpoint 0, alarm BURGLAR, event 3
2019-05-31 18:47:19.539 [DEBUG] [org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveAlarmCommandClass] - NODE 69: Node doesn't support get requests
2019-05-31 18:47:19.539 [DEBUG] [org.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 69: Polling zwave:device:07cb40a2:node69:battery-level
2019-05-31 18:47:19.539 [DEBUG] [org.openhab.binding.zwave.internal.converter.ZWaveBatteryConverter] - NODE 69: Generating poll message for COMMAND_CLASS_BATTERY endpoint 0
2019-05-31 18:47:19.540 [DEBUG] [org.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 69: SECURITY not supported
2019-05-31 18:47:19.540 [DEBUG] [org.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 69: Command Class COMMAND_CLASS_BATTERY is NOT required to be secured

[rossko57]

@5iver

polling is started for all Channels, which may be a zwave binding specific “feature”

Comment: likewise for Modbus, a large number of channels could be associated with one polled “block” of modbus registers, which are normally polled in one transfer.
Issuing a REFRESH to any one of those channels will cause a poll/update cycle for every register/channel in that block. (but not other blocks)

Can also confirm OH2.4 allows RERESH to Contact types (with the quotes kludge for now).

[rossko57]

@rlkoshak

If I have to say in the generic docs about REFRESH that when you send the command what happens depends on what the binding implements, and there is nothing in the binding docs to describe what happens the users are left with ?

I do see what you are saying. On reflection, I think it needs a mention both in the general and specific bindings.
As I’ve just been reminded, what the total effect of a REFRESH does is very dependent on any target device, as “reading” a device/service could be limited to “reading” a whole bunch of related data from the device/service in one shot. Or grossly delayed, as in sleeping zwave. Depending on technology i.e. binding.

So, a generalised “intent” for the command’s purpose? And specific details per binding, where it’s non-obvious?

[rlkoshak (Rich Koshak)]

@rossko57

So, a generalised “intent” for the command’s purpose? And specific details per binding, where it’s non-obvious?

That’s what I’m thinking. It’s going to be a pain though to update the bindings docs, but the behavior is so specific to what the Binding does and the limitations of the technologies I see no other way. We can get the main page updated this weekend.

[mark_leonard_tuil (Mark)]

@rossko57

You might get your answer in a few hours

Does this mean that sending a refresh to a battery device locks up a thread until the device responds? In that case a warning about that might be appropriate. Your rules might lock up just like with sleep.

[chris (Chris Jackson)]

@5iver

The only Contacts I have linked to Channels are zwave. There are messages that ‘Node doesn’t support get request

That means that it IS possible to send the REFRESH to a contact - just that in this case the device doesn’t support it.

@mark_leonard_tuil

Does this mean that sending a refresh to a battery device locks up a thread until the device responds?

No - it doesn’t mean that. It simply means that the device won’t really be refreshed until the device wakes - this is normal ZWave operation for battery devices.

[rossko57]

@mark_leonard_tuil

sending a refresh to a battery device locks up a thread until the device responds?

I think many bindings maintain an internal queue of things-to-do while waiting for resources, e.g. modbus queues actions for several devices awaiting their turn on a shared bus. This adds no particular load to the system, it’s only a list.

item.sendCommand(REFRESH) never ever locks up a thread. Any more than myLight.sendCommand(ON) does. It just puts the command on OH event bus for anyone interested.

Note the implications of that - the results of REFRESH (or any other command) are not available immediately. It just kicks off a process. To get the results of any command you generally have to listen out for an update.

[mark_leonard_tuil (Mark)]

Thanks for the explanation! Really clear. Looking forward to playing with refresh.

[rossko57]

I’ve known about it for ages, and it works for my main devices. But I don’t think I use it anywhere in my setup. It’s less useful than you think
It’s most likely to be of use in some setup where you have to build your own keep-alive or long-delay poll setup, I think.