Sorry, I don’t understand. Are you saying this is an intended feature?
Um, that was a joke . . .
1 Like
Sorry, just my sarcasm at work. I think once the edge driver gets updated then it should resolve your issue. It’s working great now on Hubitat. I should’ve checked for the most updated driver, but didn’t think Mark was whipping out drivers as quick as he’s been getting new features.
4 Likes
Are you not using HPM on Hubitat? It notifies you when an update is available.
(But of course, I would prefer that you help me test new versions by running the beta drivers which aren’t available via HPM)
1 Like
I do use HPM on one of the Hubitat units; the other I don’t use. I don’t always go into the apps package to check for updates, so unless there’s a big notification like for Hubitat updates, then I most likely will over look it. I’m sure there’s a rule to setup a notification…
Probably doesn’t matter since you’re going to start running the latest beta versions from now on, right? 
1 Like
FYI - re: the magnetic ballast thing.
I do believe the new firmware had something to do with it. When these switches were on 2.08, I had them controlling the florescent lights (with the magnetic ballast) just fine. They were in on/off mode (obviously) not dimming (both before and after firmware upgrade).
It was only really when I upgraded their firmware they started to self-destruct, specifically in this manner. So something in the firmware changed in how it handled the feedback from the magnetic ballast, or sent the signal to the ballast differently which caused it to feed back more, or something.
(kept in this thread because it IS firmware related)
Ok, I can talk to the engineer with you in MS Teams to try to figure this out. I’m not sure what would’ve changed aside maybe the leading/trailing edge had something to do with it? Honestly not sure.
I just fixed this and will push it out a little later today.
I had a similar experience to @PreZ. When I first installed the switches, one of them was controlling some under-cabinet fluorescent lights in the kitchen, and it worked fine and I thought nothing of it. Once I updated that switch to 2.14, it became permanently stuck on.
Leading edge dimming cuts out the front edge of each waves half cycle.
Trailing edge dimming cuts out the second half of each waves half cycle.
In ON/OFF mode, neither of these apply as this will only change behavior when dimming the load. I have personally tested the oscillations with my scope. I have however noticed a difference in the wave’s severity when relay click is ON. It seems much more like a sine wave when the switch is in ON/OFF mode with relay click DISABLED.
It does appear max power output was changed, but I’m not sure if that was only used for dimming mode… It appears to be used regardless. Max brightness is higher in 2.14. You can set it lower and it may fix your issue.
Either way, these switches were never meant for any type of motor or inductive load and so the point is somewhat moot. Installing them can not only cause a fire, but it will fail a home inspection if you decide to sell later.
2 Likes
Can you try to change it to full-sine mode? Or 3-way dumb mode to see if it makes a difference?
Oh, good call. I’ll try that, but since I’m on Z2M, I think I need to wait for the next Z2M update to see the full sine wave parameter…?
Update: Tried 3-way dumb mode. No change.
You can also try z2m edge. Copy your z2m config, stop z2m, install z2m edge and paste in your config.
I have 4 switches that are binded to groups with zha.
Neither switch processes double tap up/down.
Double tap up isn’t recognized when I double tap it says Up event was fired and not double tap.
The command it sends to the lights is the brightness setting i have for default_level_local
What’s interesting is I have another switch binded to a group and it works for double tap up/down by going to the levels I set for both.
It recognizes single tap up/down and respects default level local and turns off for single tap down. Do I need to do a reset of the problem switches or something? I checked they share the same settings for these cluster attributes.
Do you have Button Delay set to 0? That will disable multi-taps.
This is how it looks on Hubitat, but the same setting exists on the other platforms
4 Likes
Wow that was it. I wish we had that description in zha lol. Zwavejs does that for configuration parameters.
It looks like the latest Z2M update now includes the new parameters for these switches
1 Like
The HA Z2MQTT update to 1.30.4-1 just hit, and included the UI changes to access the new features on the Blues! A quick report:
-
Higher power on non-neutral option is included, and it works! I can confirm it’s a bit brighter on my downlights (like a full “step” up, 10% more). Not a full 120v to the lights, but definitely better and I don’t worry about it anymore.
-
Brightness dimming and ramp-up/ramp-down is SO much smoother. No flickering during dimming anymore! This is a huge improvement that I’m happy to see (I assume it was part of the "trailing edge/leading edge conversation that I really didn’t understand). But suffice to say, my lights no longer flicker when I adjust brightness.
-
Double tap up to full brightness and double tap down to min brightness is in as well, and it works so well. Great QOL addition.
Issues
-
The double-tap titles and descriptors refer the “Param55” and 56. which none of the others do, and may be confusing to users. The “brightness for doubletap” refer to descriptors that are unlabeled in my Z2M interface (P53/54):
-
On a couple of my dimmers, I’m noticing that it takes far longer than the button delay (set to 200ms) to start dimming down. I have to hold down the down-paddle for over 2 seconds before the lights start to dim. There’s no delay on dim-up.