Zwave Scene Number - Command or Update?

Tags: #<Tag:0x00007f015a29cfb8> #<Tag:0x00007f015a29cdd8> #<Tag:0x00007f015a29cb30>

(John Schmitz) #1

Basic questions on the Scene Number channel from ZWave devices such as the HomeSeer dimmer: does a linked Item Number get a Command or Update (or both) when the up or down paddle is tapped? I.e., should one use a ‘received command’ or ‘received update’ in rules with it? Or do both work?

(Rolf Vermeer) #2

It receives a command, and as described in the link below, a received update rule should not be triggered by that.

(John Schmitz) #3

I know it does trigger a received update since I just tried that experiment. I’ll also try a received command and see what that does. Received command didn’t trigger. So I guess it only does an update?

I’m looking for a way for this not to fire when loaded from persistence. I could not save it in the default persistence, but that doesn’t look easy to do without putting in everything explicitly and leaving this out. No “* except” that I can see. And I can’t used ‘changed’ since it is a use case to press the same button later, so must use update. The best I can find right now is to check the Item’s .previousState() and see if it is NULL and return if so. Seems like that would work.

(Markus Storm) #4

It should work to trigger on commands only. See events.log and eventually put zwave binding into debug mode to see original commands to arrive.

Why? mapdb reload of persisted values happens before rules are fully parsed/their execution started.
[ yes there could be corner cases where it doesn’t work but you shouldn’t be restarting OH anyway ].

(Vincent Regaud) #5

Not all the time. It really depends on the startup sequence.
I currently have problems with the MQTTv2 binding and mapdb restoreOnStartUp for example.
Mapdb reloads value, the binding initialise and the items are set to UNDEF
The binding initialises, items to UNDEF, mapdb kicks in, items restored

It’s a lottery

(Markus Storm) #6

That you should protect against anyway (by testing for ==NULL).

Well I called it corner cases but yes it can happen. Long story, see ESH #1896 and others.

(Vincent Regaud) #7

I know it will be solved someday. It’s ok I am patient…
I just have to spend 5 minutes on the rest API to reset my devices everytime
I may just write a special rule for now that kicks in a couple of minutes after start-up

(John Schmitz) #8

Circling back to the original question, I can see why a Zwave toggle switch would send an ‘update’ to indicate that it’s state has changed as it did the action locally such as turning on a lamp. But the Central Scene coming from the switch is more of a command and not an update. It’s telling the controller to do something. Shouldn’t that be a ‘command’ and not an ‘update’? (@chris any thoughts?)

As to the startup, I agree that openHAB should stay on, but with debugging and features and upgrades and power cycles, it does get restarted. And as I depend more and more on openHAB, this startup behavior is not so good. I don’t want lights to go on or the hot water recirculation pump to start just because openHAB was restarted.

I tried checking the item with ‘if (Scene.previousState() == NULL) return;’, but that did not work. Perhaps I need a .state at the end?

if (Scene.previousState().state == NULL) return;

(Rich Koshak) #9

received command will only trigger on a command.

charged will trigger only if the item changes state regardless of whether the charge came from a command or an update.

received update will trigger any time the Item gets updated regardless of whether the update causes the Item to change or not. A command will usually cause an update a well.

so, unless the item in question is not configured with autoupdate=false, a received update rule will trigger for commands because the command causes and update.

that won’t work because typically NULL and UNDEF do not get saved to the database. and .previiusState just returns data from the database.

If the rule is triggered by changed, then the previousState implicit variable will have NULL if the state changed because of restoreOnStartup.

Design Pattern: Group Based Persistence could help with this.

(John Schmitz) #10

My rule is triggered by ‘received update’. ‘changed’ won’t work because the minimote or the zwave switch can have the same button pressed again without any other buttons in between. I’ll take a look at the group persistence to see if that will help. thanks.

(Rich Koshak) #11

when I used the minimote I used a Rule to set the Switches that represent the buttons to off immediately after they changed to ON. Then I triggered the rules with changed to ON.

I wrote it up here: Aeon Minimote Configuration OH 1.8.2?

(John Schmitz) #12

Yes, that should work too. I’m going to try the method of not restoring the items such as these which should prevent them from inadvertently firing at restart. If that doesn’t work well, I’ll try this next. Thanks.

(Chris Jackson) #13

Possibly - arguably this distinction is pretty blurry - switches also do this, but they are updates…

Anyway, within the binding everything is treated the same - it’s not super easy to change this at the moment as the converters that process the ZWave data all feed their data in in the same way.