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.
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.
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/
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).
I have opened a ticket with Zooz support to get some firmware files for testing.
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.
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.
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.
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 ONScott also received the firmware.
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.
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!
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.
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.
I told you they are helpful.
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.
No, no offense at all! My response was all in jest too… just much dryer. BTW, an octopus is not a measure of time.
This can get confusing even if you are an OH veteran! I like to use capitals for class instances, like Item, Thing, etc. to help identify that I am talking about OH objects.
Oh yeah, I know that. It’s a measure of Command Poll Periods…
Like the Iowa Caucus??
No, but a jiffy is. 
The earliest technical usage for jiffy was defined by Gilbert Newton Lewis (1875–1946). He proposed a unit of time called the “jiffy” which was equal to the time it takes light to travel one centimeter in a vacuum (approximately 33.3564 picoseconds)