[RELEASE] Advanced Zooz Zen27 / Zen26 Central Scene Dimmer and Switch Drivers

here you go.

1 Like

1 Like

Ok.. Yea.. This is identical to the one Iā€™m testing..

One minute

Ok.. can you swap out the driver for this one for me ?

and then run your actions again and post the logs.. I have a ton of extra logging turned on here..

ok

1 Like

I will let it run a few and recapture logs.

1 Like

Analyzing

Ok.. so clearly we are sending level 75 duration 1

Then we get back a 2603 (switchMultiLevelReport)
multilevelCapture1

Hex Dec
Current Value 0E 14
Target Value 0E 14
Duration 00 0

:man_shrugging:

Ok .. This makes no sense ..

We sent out multilevelSet 75

and got a report of 14 with a target of 14 and duration of 0 so nothing delayed ..

I don't see anything in the device config that should be causing this either..

I'm going to ping @agnes.zooz on this .. This has me stumped...

More recent reports.
App data

Device data

Thanks for your efforts.

1 Like

This is nutz

We haven't seen anything else like it before. Does the same thing happen when you just manually set the dimmer value to 75% from HE (not through an automation)? Or is it just in this particular rule that this happens?

2 Likes

That's a good question.. Not sure why I didn't think of asking that

I did not think of that either.
When I manually set device dim level to 75 in HE, the log shows the device goes to 75%.

2 Likes

Ok.. This gives me something new to look at and test... I wonder if it is some weird value conversion issue.. I'll get back to you ..

Great question @agnes.zooz

1 Like

@bcopeland @agnes.zooz
Thank you both for your assistance

2 Likes

Silly question. I have been chatting with Agnes for the last few days re: Zen22 and I have just update one of my zen27s from FW 2.03 to 2.08.

Also in doing this I switched over to your driver. I am not running any association but have manual control disabled.

Actions from the Zen27 take action on a virtual dimmer that I mirror back to the Zen27. Long story but it is an alexa work around.

First - according to this
https://www.support.getzooz.com/kb/article/314-zooz-s2-dimmer-zen27-ver-2-08-advanced-settings/
Scene button 1 should come from the upper paddle. Iā€™m getting it from the lower paddle.

Second: Control from the device works reliably but I am seeing sporadic functionality when driving from RM.

Second one is probably my issue but the first item surprised me.

1 Like

@deh2oman Can you re-download that debugger version.. I made some changes and want to see if it fixed your issue with your rules.. If it does I'll make the changes in the normal driver..

Ok... Here is the breakdown on that.. I does seem to be reversed based on the description but based on the z-wave command side it is identical to the docs... Let me break it down..

From the docs:

Upper Paddle:
1 x tap: load on to last / custom brightness; Scene 1, attribute 00 (button 1)
2 x tap: on to full / max brightness; Scene 1, attribute 03 (button 3)
3 x tap: enter inclusion (pairing) mode; Scene 1, attribute 04 (button 5)
4 x tap: Scene 1, attribute 05 (button 7)
Lower Paddle:
1 x tap: load off; Scene 2, attribute 00 (button 2)
2 x tap: Scene 2, attribute 03 (button 4)
3 x tap: enter exclusion (unpairing) mode; Scene 2, attribute 04 (button 6)
4 x tap: Scene 2, attribute 05 (button 8)

Section of code:

void zwaveEvent(hubitat.zwave.commands.centralscenev3.CentralSceneNotification cmd) {
    Map evt = [name: "pushed", type:"physical"]
    if (cmd.sceneNumber==1) {
        if (cmd.keyAttributes==0) {
            evt.value=1
            evt.descriptionText="${device.displayName} button ${evt.value} pushed"
            if (txtEnable) log.info evt.descriptionText
            sendEvent(evt)
        } else if (cmd.keyAttributes==3) {
            evt.value=3
            evt.descriptionText="${device.displayName} button ${evt.value} pushed"
            if (txtEnable) log.info evt.descriptionText
            sendEvent(evt)
        } else if (cmd.keyAttributes==4) {
            evt.value=5
            evt.descriptionText="${device.displayName} button ${evt.value} pushed"
            if (txtEnable) log.info evt.descriptionText
            sendEvent(evt)
        } else if (cmd.keyAttributes==5) {
            evt.value=7
            evt.descriptionText="${device.displayName} button ${evt.value} pushed"
            if (txtEnable) log.info evt.descriptionText
            sendEvent(evt)
        }
    } else if (cmd.sceneNumber==2) {
        if (cmd.keyAttributes==0) {
            evt.value=2
            evt.descriptionText="${device.displayName} button ${evt.value} pushed"
            if (txtEnable) log.info evt.descriptionText
            sendEvent(evt)
        } else if (cmd.keyAttributes==3) {
            evt.value=4
            evt.descriptionText="${device.displayName} button ${evt.value} pushed"
            if (txtEnable) log.info evt.descriptionText
            sendEvent(evt)
        } else if (cmd.keyAttributes==4) {
            evt.value=6
            evt.descriptionText="${device.displayName} button ${evt.value} pushed"
            if (txtEnable) log.info evt.descriptionText
            sendEvent(evt)
        } else if (cmd.keyAttributes==5) {
            evt.value=8
            evt.descriptionText="${device.displayName} button ${evt.value} pushed"
            if (txtEnable) log.info evt.descriptionText
            sendEvent(evt)
        }
    }
}

As you can see I mapped the scene number / attributes in the docs to the button number in the docs.

I did notice this seemed to be reversed based on the description of Upper/Lower paddle, but it matches the docs scene / attribute listings.


There may actually be an issue here .. I am running debugger version with @deh2oman as you can read above.. you are welcome to run that debugger version as well as the one I just posted may fix the RM issue.

If it fixes it, I'll push the changes to the normal version driver..

1 Like

Hi Brian,

I did install your debug driver version and although i have only done limited testing so far, i think it has cleaned up my issues. I will do more testing this evening.

One question related to this. It seems that with FW.v.2.08 (compared to FW.v.2.03) that with manual control disabled, i need to delay control commands back to the switch after a button push. Could it be that the amount of data the switch is sending to the hub after a button press has increased, therefore when i send back a control command to the switch too soon that it is gettign ignored or missed all together?

Thanks for the paddle / scene # explanation.

Last note: of course i had to do a new RM to handle the new numbering with button device as a trigger and so far i have only populated buttons 1 through 4, but i noticed that if i press the same button again, that it does get logged, but the button action in RM does not get triggered.

ie:
double tap down (button 3) triggers button three actions
double tap down (button 3) - no actions
double tap up (button 4) triggers button four actions
double tap down (button 3) triggers button three actions

I assume that you are comparing the current button with the last button and if it hasn't changed you do not send a trigger event. is there a configurable timeout or is this persistent? Possible something i can change with the reporting but i am still playing/trying to understand all the options in your driver/ options in the switch itself. Some of this stuff just isn't written in english :wink:

1 Like