Hello,
I have a question regarding the zigbee binding. Did some research but could not find any information about this:
Is there any way to actively refresh / poll / update the state of an item (e.g. in a rule) to safely determine the hardware’s actual condition (e.g. ON/OFF for a switch)? This is something the zigbee coordinater seems to be capable of (e.g. at startup), but I could not find a way to trigger it manually.
Background:
I have some zigbee switches that I want to control with openhab. After sending a command (via BasicUI or rule), in some rare cases, Openhab tells me “OnOff_Item changed from OFF to ON”, but the hardware is still OFF (and vice versa). As I want to install the system at a remote location, this is a problem for me. If I could manually refresh an item’s state, I could just send another command until it worked.
Openhab and zigbee binding are both version 2.5.0 M1.
Coordinator CC2531
Switches: two Osram Smart Plugs and a Ksentry OnOff controller
I thought that I implemented the standard REFRESH command in the ZigBee binding (eg by using myItem.sendCommand(REFRESH)) - have you tried this? If not, I will take a look at the binding code.
Both give me this error: 2019-05-31 12:35:59.232 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'Test': The name 'REFRESH' cannot be resolved to an item or type; line 9, column 32, length 7
I checked the binding code, and it is definitely included. I suspect your rule is wrong (maybe it should be RefreshType.REFRESH but I’m not 100% sure as I don’t use this in rules).
I was on my phone before, but back at my PC now. To do this without the import, just put it in quotes…
OnOff_Schalter.sendCommand("REFRESH")
RefreshType.REFRESH should have been included in the default imports, and I also see it missing in the new rule engine. I’ll add these as issues for now and submit PRs to include it at some point down the road.
I’ve updated my previous post in case it confuses someone in the future.
@chris, @5iver, I don’t really see this in the documents anywhere. The Modbus binding mentions REFRESH being used like this but I can’t find it anywhere in the Zigbee docs or in the generic docs (it does appear in the developer docs). Is this something that needs an article or section somewhere in the docs? It seems like a pretty useful feature that should be documented. I don’t mind filing a PR but the information posted here isn’t sufficient for me to write about it.
@mrfrh, I might suggest a small tweak to your approach. If you configure the Item linked to this Zigbee device with autoupdate=false, then using a Rule send the REFRESH after sending the command, your Item will not actually change state until the REFRESH returns the device’s state. This will help keep your Item in the last state until the REFRESH gives you the current actual state. You could even set a Timer and if the Item doesn’t change state soon enough you know something is wrong.
It’s not a binding feature, so it shouldn’t need mentioning in binding docs.
Having said that, not all (many?) bindings support it yet so I’m not surprised when it gets mentioned as an exception.
Maybe it should go as a footnote to the Item/Command table, any Item can accept REFRESH (it might not do anything depending on bindings!).
A bit like NULL and UNDEF ought to get a mention in states.
I really have no opinion about where it gets documented. But this is the first time that I’ve heard of this Command type and as far as I can tell there are only two bindings thus far that support it. Are there more?
If we were to document it in general, the best we can say is “some bindings support a special Command REFRESH which will cause the binding to request the latest state from the device”. OK… but then the question is which bindings support it? What happens if I send it to a binding that doesn’t support it? Does that not raise the issue from the other thread of it failing silently?
Indeed and that’s issue is actually even more fundamental than this issue. Are all the types and all the commands actually documented? REFRESH has been around since before 2017 and this is the first I’m hearing of it. What other features are there lurking in the code without mention in the docs?
I am thinking that we need more than just a footnote. I like chris’s idea or creating a separate section to discuss this command, any other universal commands (are there any), and the special states of UNDEF and NULL.
I’m more than happy to submit the PR but I’m now really doubting I know enough. I thought REFRESH was something really new.
Given that REFRESH is ignored when sent to a binding that doesn’t support it (I just tested it with the Network binding and that seems to be the case, unless Network does support it) I do think it is worth having the bindings that do support it mention that in their readme’s and especially if they do something interesting in response to it.
Or maybe it’s widely supported and I just don’t know about it?
Well, a simple search on the repo came up with 255 hits, so I think a lot of bindings support this (I didn’t try and count how many separate bindings these 255 files belong to). ZWave and ZigBee are not included in this since they are in a separate repo, but clearly a lot of others supporting this.
Well, it’s the same as any command. Some bindings support the command ColorType, and some support Dimmer… It’s just a command type that can be sent to a channel…
Maybe, but this is not about the binding, it’s a command that can be sent to a CHANNEL. So it’s down to “does the channel support it”.
But unlike other command types which can only be sent to specific types of Items, this command type can be sent to any Item type. That makes it unique in that regard.
Interesting though, does it work for Contact? Usually we can’t send a command to a Contact type Item.
And only the binding developer can tell the user that (or whom ever write’s the docs). It doesn’t seem reasonable to me to require users to search Github to figure out why sending REFRESH to some Item appears not to do anything (because the binding doesn’t support it).
Since so many bindings do support it, maybe it’s easier to add to the bindings readmes that don’t support it. But either way I look at it, we have to give the users a way that doesn’t include looking through code to figure out which ones support it and which ones do not.
Sending to a 1.x binding or a 2.x channel (e.g. write only) that doesn’t support it should be silently ignored, like any other unsupported command.
umm, I don’ think so. Example, it is legit to issue a REFRESH to a sleeping zwave device. You might get your answer in a few hours
Wahh, silent failure? Not undetectable failure, because if successful it causes an update. Check lastupdate if looking for a problem.
Really good question. If it gets blocked, we ought to raise an issue.
I’m not trying to be difficult but if I’m going to write this up I need to know all the ins and outs.
But you’ve been in this forum as long as I have. Can you not predict the “I sent REFRESH like it said in the docs and nothing happened” posts? And I have nothing I can send them to to figure out how it’s supposed to work for that binding, or for the cases where it is handled different for different Channels.
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’d almost rather leave this feature as a secret only known about by the binding developers.
Because I think OH core prevents one from sending a command to a Contact.
I’ll try on sunday, currently I’m not able to test.
Chris had it too.
? I’d almost rather leave this feature as a secret only known about by the binding developers.