Thank you for this driver! I'm having as issue with it. I have many Zooz 77 dimmers. I like to have them set up so that a single tap turns to full brightness, and a double tap turns to a pre-set brightness. I've done this by adjusting parameters 12, 18, 25 with the Advanced Driver (v1.5):
The issue I'm having is that when I double tap, the light first goes to full brightness, then dims to the set level, instead of turning on directly to the set dimmed level. This is really annoying at night, since I use the double tap to go into rooms where I don't want to turn the light to full brightness.
When I change over to the built in Zen77 driver, it behaves as it should (single tap to full brightness, double tap to pre-set dimming level). Contrasted with the Advanced driver behaviour on double tap that first turns it to full brightness, then dims to the pre-set dimming level.
The same driver, same settings, with a Zen72 dimmer works as it should (goes straight to preset dimming level with double tap, instead of first to full brightness, then to dimming level).
Firmware on the dimmers is 10.0
Is there something I should change, or is this a driver issue?
I am not at home this week to test, but you enable debug logging and get a screenshot of both cases on the ZEN77 and post it.
The parameters are set directly to the device, and I assume you are setting them with my driver and they are not being changed when going to the stock driver. So that should not be a variable. The actual native single and double tap up features those parameters set are totally firmware level, the driver has no part in telling the switch what to do once the parameters are set, so that should not matter between drivers. When you tap the switch physically it does its thing and tells the hub what it did, the driver itself does not send any commands back in this case.
The ONLY thing I can think of is that you setup a button controller or rule, to act on button 3 pushed and have the scene control enabled (param 7). This would possibly only trigger with my driver because I think the stock driver sends a "doubletapped" event and not the button 3 pushed.
Also, it looks like you have modified the driver, as your param 12 and 25 marked "DEFAULTS" are not the actual defaults in my code.
I forgot, I had modified the defaults, to save time since I wanted the same behaviour in all my switches. I've restored to your original code for the purpose of debugging.
As I was compiling this response, I could not get the desired behaviour out of either driver this time. I could swear before I wrote my original email, I had confirmed this behaviour. So I'm guessing it's a firmware issue then with the Zen77. Looks like with a double tap, it registers a single tap then double tap. When I switch the single tap and double tap behaviour, the bug persists (single tap brings it to full brightness, double tap brings it it custom level, then to full).
Desired behaviour:
Single tap: Full brightness
Double tap: Custom brightness (set by param18)
Case 1:
ZEN77 dimmer with driver: Zen Dimmer Advanced v1.5:
Behaviour:
-- Single tap: turns on to full brightness
-- Double tap: turns on to full brightness, then immediately dims to custom brightness level.
@jtp10181@agnes.zooz Not sure if this is a driver issue, firmware issue, or intended behavior. This is on a Zen21 with firmware 4.04, though it may be the same on other models too. The auto-off timer doesn't work under the following conditions:
Turn on scene control
Disable paddle control
It could be just one of the above settings that makes the auto off not work. I have not tested. I had the auto-off set to 20 minutes and it was working before I made those changes. This switch is for a closet light and the reason I wanted to turn off physical control of the relay and enable scene control is that I use a contact sensor to turn the closet light on and off. I wanted to re-purpose the switch to turn a lamp on/off. So button 1 & 2 control the lamp, but I can still control the closet light manually if needed using buttons 3 & 4.
I know I can easily create an additional rule to turn the light off after a set amount of time when it comes on, which is what I plan on doing, but I thought I'd let you know just in case.
That is a device setting so it is totally hardware/firmware controlled. I would guess that disabling paddle control inadvertently also prevents the auto-on/off from working. The only way it could be a driver issue is if the parameter is somehow not being set. Check in the DATA section at the bottom for the "configVals" data map. First number in each pair is the parameter number, second number is the value the device reported back to the hub it is set to. You can use that to confirm the parameters are set as desired. The auto-off timer on that model is a combination of parameters 3 and 4, #3 would be set to 1 to enable it and #4 would be the duration (20 in this case).
This is indeed what shows in the data section. Which makes total sense because the auto off was working before I made the changes.
EDIT: I always forget, which one is canceled when the rule retriggers, a wait or a delay? I'm thinking I want to use a delay so that if you open the closet door, close it, and then open it 19 minutes later it doesn't turn off after 1 minute. But maybe I need a wait 20 minutes. I really wish there was helper text somewhere when selecting various wait or delay actions.
I didn't even know one would cancel if the rule triggers again? I have done it before by doing a wait for actions with a timeout. Have it wait for the device to turn off, so either it turns off before the timeout and the rule turns if off again, or it times out and turns off.
I also just found in the Basic Rules app there is a "on and stays on for.." setting which basically does all that for you.
FWIW - I've played around and gotten the Indicator Command Class working to turn the LED on and off (I'm using ZEN77's, only tested there). I found that only the Device Identifier indicator ID (0x50) is supported, and only Parameter ID's 3, 4, and 5 (all related to toggling of the indicator). But it's possible to "abuse" those parameters to turn the LED on and off with this:
The extra check against state variable was needed in my application because I can get multiple "off" commands in sequence, and that caused a short flash of the LED.
Small nitpick - and I'm not sure if this is something that could be addressed by the driver at all. Can you make it so that doing a refresh updates the last activity at field for the child device of the Zen30? Would be helpful for those of us that use Device Watchdog to keep on eye on our devices to make sure everything is responding properly. It seems to update like I'd expect for other devices, so I'm sure it has something to do with being a child device.
I probably could, but you really only need to monitor the parent device, since they are tied together its going to be all or none situation if they go offline. I need to refactor that entire driver to bring it up to speed with the other one anyway,
Minor update to 1.5.1, a couple of parameter fixes and also a fix that prevents some errors with HE v2.3.1 was the main reason I wanted to push it out.
UPDATE: [1.5.1] - 2022-03-22
Changed
Description text loging enabled by default
Fixed
Added inClusters to fingerprint so it will be selected by default
threeWaySwitchType options corrected between switches and dimmers
Parameter #7 removed from ZEN71/72 which do not have that option
Global (Field static) Maps defined explicitly as a ConcurrentHashMap
Thanks for the great work on this. However, I'm still lost when it comes to creating scenes to be controlled by my Zen82 switches.
I have tried both the onboard Zen72 drivers and your drivers. I've tried setting the SCENE parameter (#13) to ENABLED or DISABLED, and I've tried setting the double-tap behavior (parameter #12) to DISABLED and FULL BRIGHTNESS.
No matter what combination of settings and drivers I try, when I go in to create a new scene, none of the switches show up as options under "Select button to push upon scene activation".
What do I need to do to trigger scenes by double tapping my Zen72 switches?
The terminology Zooz uses it a little misleading. The buttons don't trigger scenes directly, they just send out button events. Use the stock "Button Controller" app to catch the button events and then trigger a scene (or whatever you want really).
If you are still stuck on setting it up (or any other settings on the switch), I would start a new thread and feel free to @ tag me. Myself and others I am sure will jump in get you going.
I'm working to associate a Zen71 to directly control a Zen51 relay. I have everything up and running independently in Hubitat, but I'm hitting a roadblock on the association. My Zen51 deviceID is shown as 513, and I believe that it is decimal, so it converts to 201 in Hex. No matter what I enter in the Device Associations - Group 2 field, it appears to cut it down to only the last 2 digits. For example, if I enter 201, after I save, it changes is to just 01. If I enter 513, it changes to 13. I'm able to enter numbers all they way up to 99, but then after that, it ignores all leading digits.
This is my first foray into associations, so my assumption is that I'm simply missing something obvious, but I'm having a hard time finding anything with Google searches. Any help would be greatly appreciated! Also, thanks for all the hard work on this driver!!
@djlotus51 that is probably the hub device ID, you need the zwave device ID (aka DNI). For Zwave devices this is a max of 2 HEX chars. You can find it on the device details page next to the name:
Thanks so much, that took care of it...I thought I was probably just doing something dumb! To make it even dumber, I just realized that the flood light that the Zen51 is controlling is dusk-to-dawn, so it wouldn't turn on now anyway.
I have recently found out that the ZEN30 now has a V2 and V3 hardware, and the ZEN7x are starting a V2 hardware as well. With this Zooz decided to standardize the firmware numbering such that going forward the major version in the firmware should match the hardware revision. Unfortunately some version numbers will be going backwards due to this and some of the newer parameters may be hidden in this case because the driver will think it is an older firmware. I will be working on a plan to accommodate this in the driver so that it is fully forward and backwards compatible as much as possible.
Otherwise as far as I know the drivers should work on all the new hardware, you just may not see all the parameters that the device has.
I'd vote for Zigbee with an MG24 chip that is future-proofed for a Thread/Matter upgrade. While we're at it, how about a paddle that's crisp like the Zen 26/27s, instead of the mushy cheap-feeling one they put on the Zen30?