[SOLVED] Zooz Zwave Zen26 not updating properly

Hardware Home Automation
,
1

EDIT: Solution was a firmware update from 1.0 to 2.02

Hello,

I have a Zooz Zen26 Zwave switch, it is a simply on/off switch. It is added to OpenHAB via the PaperUI as a “Thing” and I have assigned an item (a simple switch) to it’s switch channel.

When I toggle the switch Off -> On, it updates in OpenHAB (on the habpanel and in the control secion) and if I toggle the switch On -> Off it does the same. So control physically from the switch works fine.

Where things go to hell in a handbasket it when I go to control the switch from HapPanel or the control section in the PaperUI. If I toggle it from Off -> On, it works just fine (every time, without fail), but when I toggle it from On -> Off, it changes, but then openHAB immediately turns it back on (this happens consistently), though the switch remains in off mode (I have to physically toggle it on, then off to sync it back up).

Here are the relevant lines from the events.log file.

Toggling the switch physically.

2020-02-05 16:13:30.951 [vent.ItemStateChangedEvent] - MasterBedroom_Light_Zooz changed from OFF to ON
2020-02-05 16:13:30.957 [GroupItemStateChangedEvent] - gLight changed from OFF to ON through MasterBedroom_Light_Zooz
2020-02-05 16:13:33.448 [vent.ItemStateChangedEvent] - MasterBedroom_Light_Zooz changed from ON to OFF
2020-02-05 16:13:33.454 [GroupItemStateChangedEvent] - gLight changed from ON to OFF through MasterBedroom_Light_Zooz

And here it is from the habPanel and/or the control section in the PaperUI

Off to On:

2020-02-05 16:15:11.900 [ome.event.ItemCommandEvent] - Item 'MasterBedroom_Light_Zooz' received command ON
2020-02-05 16:15:11.925 [vent.ItemStateChangedEvent] - MasterBedroom_Light_Zooz changed from OFF to ON
2020-02-05 16:15:11.932 [GroupItemStateChangedEvent] - gLight changed from OFF to ON through MasterBedroom_Light_Zooz

On to Off (the line break is where openHab reverts the state).

2020-02-05 16:15:22.821 [ome.event.ItemCommandEvent] - Item 'MasterBedroom_Light_Zooz' received command OFF
2020-02-05 16:15:22.844 [GroupItemStateChangedEvent] - gLight changed from ON to OFF through MasterBedroom_Light_Zooz
2020-02-05 16:15:22.847 [vent.ItemStateChangedEvent] - MasterBedroom_Light_Zooz changed from ON to OFF

2020-02-05 16:15:25.931 [vent.ItemStateChangedEvent] - MasterBedroom_Light_Zooz changed from OFF to ON
2020-02-05 16:15:25.937 [GroupItemStateChangedEvent] - gLight changed from OFF to ON through MasterBedroom_Light_Zooz

I have no idea why this is happening, the suggestion is that it may have something do with the polling after the command has been sent, which is currently set to the default of “1500” and I did try some other valued (3000 and 6000) but that made no difference.

I have no idea where to go from here, or even where to look or what to change to try and diagnose this, so any help will be greatly appreciated.

Oh, and for the record:

Openhabian on a Raspberry Pi, everything configured via the PaperUI. The Zwave stick plugged into the Pi is across the room from the switch, which is sitting on my desk, so interference is very unlikely. And gLight is the item group the switch item has been placed in.

2

Zooz is one of my favorite vendors here since they help us get their devices supported.
I see @5iver made some updates to this device recently that will likely be in a snapshot build this weekend. He likely has that switch do I will give him a chance to help first.

That issue seems familiar to be but I cannot remember the solution :frowning:

1 Like
3

That is good to know. I put in a ticket with them last night too, so we will see what happens there. I did note that I am running the initial firmware, and they are now a few version ahead of that, so I at the least I expect they’ll want me to update that.

I shall wait to see what @5iver has to say on the matter. Hopefully there is a simple solution.

4

Their support is top notch in my opinion.

5

I had updated the one device to lower the firmware to <2.0 and added one for >=2.0. The newer firmware adds scene control. I only used the device for testing, and did not notice the issue you are reporting. Try setting the command polling to 15s (the max) and see if that helps. It will also help to troubleshoot with some debug logs.

If we can’t figure it out, I’ll set the switch up again and do some functional testing, but since I have the 2.0 firmware, it wouldn’t really be apples to apples.

6

Thanks Scott.
You have the newer firmware. I do not believe their devices are upgradable. I will need to look closer at the older one in the database.
It is possible it is no longer supported by Zooz. If we need information to complete the database I may be able to get it though.

7

My understanding is that the firmware of most Zooz devices can be updated OTA…

http://www.support.getzooz.com/kb/article/253-how-to-perform-an-ota-firmware-update-on-zooz-devices/

It’s possible the update could be done through OH, but I’ve never seen it done. @chris, once we have the firmware files, can we use the binding to update it? Or would we need a UI first? Zooz suggests using the SiLabs PC Controller software.

Here are some details on what has changed in the ZEN26…

http://www.support.getzooz.com/kb/article/302-zen26-s2-switch-change-log/

8

This is not currently implemented in the current binding. The main reason is that I’ve not yet found ANY companies willing to provide the OTA files. Maybe that will change (or is changing with Zooz?) but as far as I know it’s still the situation so I’ve not bothered implementing the OTA functionality for ZWave (only ZigBee).

9

I have opened a ticket with Zooz support to get some firmware files for testing.

1 Like
10

Ok, let’s see what happens. I can look at it for the new binding if there’s interest, but for some reason most companies won’t supply them publicly. Even for ZigBee, while some are made available, I’ve only received others through NDA (eg Osram).

A while back, Fibaro told me they would not make them available as they consider they could be reverse engineered. I suspect it’s more that they want to hold that as an incentive for users to buy their gateway, although Aeotec also have said the same thing and they do have software available using a standard stick.

11

Has your test Item got autoupdate disabled for now?
While there are no “predicted” messages shown in response to commands ON/OFF, the state update in 25mS seems a bit too quick for a real device derived status.

1 Like
12

As predicted they told me to update the firmware (running 1.0). They sent me the OTA firmware files (2.02) today. I can upload them somewhere if that helps, just let me know.

Is that the Command Poll Period (currently at 3000 red sheep)? Or do you mean the Polling period (currently set to 1 day)?

The Command Poll Period field gives me no units, so I am not sure how to convert 15s into whatever that amount is expected to be, it’s currently set to 3000 octopuses. On a side note, it might be useful to add units to the name of that field (eg “Command Poll Period in x units”) at some point.

Once again, I am assuming we are talking about the Command Poll Period, in which case no, it was set to 3000 tangerines when I ran the test to get the logs posted above. I did try it disabled, 1500 orangutans and 6000 chimps, but that did not seem to make any real difference.

13

EDIT: All of this is before the firmware update. Something I hope to get to over the weekend.

Actually, I stand corrected. When the Command Poll Period is disabled it would appear that it works as expected. The higher that number goes, the longer it takes OH to switch back to on when you toggle it off in the control section.

Also, not sure if this is relevant, but if you turn it off in OH and it turns itself back on (but leave the switch in the off position) and then you go to flip the switch on, there is no event logged in events.log

Here is the log when the Command Poll Period is set to 6000 tomatoes:

2020-02-06 20:24:11.938 [ome.event.ItemCommandEvent] - Item 'MasterBedroom_Light_Zooz' received command OFF
2020-02-06 20:24:11.966 [vent.ItemStateChangedEvent] - MasterBedroom_Light_Zooz changed from ON to OFF
2020-02-06 20:24:18.028 [vent.ItemStateChangedEvent] - MasterBedroom_Light_Zooz changed from OFF to ON

And 12000 bananas

2020-02-06 20:26:06.679 [ome.event.ItemCommandEvent] - Item 'MasterBedroom_Light_Zooz' received command OFF
2020-02-06 20:26:06.698 [vent.ItemStateChangedEvent] - MasterBedroom_Light_Zooz changed from ON to OFF
2020-02-06 20:26:18.764 [vent.ItemStateChangedEvent] - MasterBedroom_Light_Zooz changed from OFF to ON

And then again back down to 1500 oranges:

2020-02-06 20:27:50.473 [ome.event.ItemCommandEvent] - Item 'MasterBedroom_Light_Zooz' received command OFF
2020-02-06 20:27:50.490 [vent.ItemStateChangedEvent] - MasterBedroom_Light_Zooz changed from ON to OFF
2020-02-06 20:27:52.050 [vent.ItemStateChangedEvent] - MasterBedroom_Light_Zooz changed from OFF to ON

And just for the hell of it I set that field to 100 frogs (well I tried 1, but apparently 100 is the lowest it’ll go):

2020-02-06 20:29:43.076 [ome.event.ItemCommandEvent] - Item 'MasterBedroom_Light_Zooz' received command OFF
2020-02-06 20:29:43.097 [vent.ItemStateChangedEvent] - MasterBedroom_Light_Zooz changed from ON to OFF
2020-02-06 20:29:45.627 [vent.ItemStateChangedEvent] - MasterBedroom_Light_Zooz changed from OFF to ON
14

Scott also received the firmware.

15

No. I said autoupdate because I meant autoupdate, and I said Item because I meant Item, which has no command poll period property.

Autoupdate is an internal openHAB feature that operates purely on Items.
It listens for Item commands, and predicts then sets Item state, in order to speed up response times for clicking UI users.
It’s enabled on each Item by default, and can be disabled on any individual Item.

Because it generates Item state changes in response to commands, it is really unhelpful if you are trying to analyse a command-response problem with a real device.

So my recommendation is to disable autoupdate on your test Item, at least for now.

2 Likes
16

Yes, Command Poll Period. You’ve probably read this already, but here is the relevant documentation.

Just apply the well known conversion…

1 octopus = 1 millisecond

So, set it to 15000 (that’s the max allowed). There will now be a unit, when/if this gets merged…

Thank you, but Zooz already sent it to me too!

1 Like
17

I know Scott has just updated this, but you can also check the documentation for the binding which states the following -:

The binding can perform a poll of the device shortly after sending a command to make sure that the command was implemented, and the binding has the correct view of the devices state. This is called “Command Poll Period” and may need adjustment for some devices that may update their state slowly (e.g. dimmers that have a slow transition). This is defined in milliseconds, and can be set to 0 to disable this polling.

2 Likes
18

That’s one hell of a fast octopus. FYI - I meant no offense with my comment, was just having some fun with it…

I was not going to update the firmware last night, but I decided to just go ahead and do it. My testing was not extensive, but it did seem like that may have fixed the issue. I plan to test more over the weekend, and will report back.

I also asked them to send me the new firmware for the Zen27 (dimmer) that I have, and they just sent that over to me as well.

19

I told you they are helpful.

1 Like
20

Ok, I get it. But to be fair this is all very new to me, and anyone starting out with this is going to definitely get items/things etc mixed up, not to mention that the chosen nomenclature is REALLY easy to skip over as it matches very generic nomenclature we use in day to day life. I completely missed the fact that you said “item” because of this.

1 Like