I figured it out - there are 2 versions of the Z-wave Firmware Updater - both labelled v 1.00 - how interesting, I figured the one with more lines (706) was the correct one…
Man this is going to be EPIC! Thanks for the continuous improvement on these devices. What a thrill it has been to be along for the ride!
Has anyone started the openzwave PR for this update? On HA and want to be able to implement this firmware on HA, but I’ve never been through this process before.
I’m on OZW 1.6 beta, what is the path to getting that implemented?
@nathanfiscus I see you are a contributor already, just wanted to tag you so you see this firmware update!
I have more than 20 of these switches. I updated the firmware to 1.52 on all of them. It worked except for one. That one seems to be dead now. The LED stays blue forever. It does not work anymore and i can’t light on. The configuration button does not work anymore. I tried manual config, 5 sends press, 10 seconds press and even 25 seconds press to reset, nothing worked. I also closed the breaker for a couple of minutes. As soon as I open the breaker the LED becomes blue and nothing work. Since it was not working from HE anymore I forced a remove in HE. I really thinks it’s dead.
Do you have a special method to update them, or you manually update them one by one ? I’ve got 20 of them, and it seem so far like doing them 1 by 1 it will take me over 3 hours to do ! Also, when I update, I get to this progress " Complete device is flashing…"… Does that mean it done, or is currently flashing the downloaded image to the flash ? The … in there tell me I should be waiting for something else… I did try to upload the firmware Target 1 and it then updated to show 1.52 was installed… But I wonder if this is normal or I should wait a lot longer when I get this prompt.
Personnaly I’m using the Hubitat firmware updater. No problem with the OTZ but sometimes I had problem with the .BIN file. I had to reboot the hub and restart the bin file to complete it.
It happens a couple of times that after all packets were sent it did not receive the answer from the switch but it was completed. I installed the new driver and the new parameters are working fine.
The 1.52 say this : Modified Smart Bulb Mode so that the output can only be turned off by sending a BasicSet(0x00).
Is BasicSet(0x00), mean just clicking Off for example in the device page ? How do I remotely tell the switch to go Off without closing the light power ?
For example, if I close my light via Google Home, it tell the switch to turn off, which cut power to the light. Is there a different On/Off setting I need to use so it remain powered on ?
hey guys am i missing something? I tried to download the otz file for 1.52 and apply it with PC Connector and i’m getting error
“Status: Invalid Fragment Size=0x02”
@stu1811 did you ever get this resolved?
I refreshed the node info a few times from the network management and then a get on the update screen. I also tried pulling the air gap a few times. Eventually it worked. Not sure exactly what did it.
Why do you want the switch itself to maintain these values? Assuming the LED strip can be made into a property that your hub can set, shouldn’t having that data stored and controlled by the hub be all that’s needed?
I noticed you mentioned homeassistant elsewhere in this thread. If you’re using HA, you can accomplish “press and hold for dimming” functionality in node red. The switch sends start and end events for a long press - so you just create a loop in node red that initiates on the long press start event and then loops until the long press end event. I have this running currently and it works as expected.
I’ve been moving further and further away from home assistant in favor of node red (with zwave2mqtt), and I think I could be convinced that provided I can set the led bar to a percentage and have it outputting full power always (no exception) then it would do what I want. Though I have some reservations about how smooth the “animation” of the notification bar filling up would be if it relied on a round trip to the hub.
I think it would be ok if the firmware for the LED bar internally handled the animation.
In my case for example, I’m incrementing the brightness of my bulbs by 10% per loop (each loop is 200ms). You’d think that’s way too high to get smooth looking dimming, but the lights themselves (ikea tradfrii bulbs in this specific light fixture) natively fade so I don’t need to worry about making my loop fast enough and incrementing brightness in quicker, smaller steps. Basically, as long as my loop is faster than whatever pre defined timing ikea uses to internal fade the bulb - then I could even move in 50% steps and it would still look smooth since the bulb is handling the animation internally
I see that joshfee already gave his response. But there are several good reasons for wanting it. One is so zwave associations continue to work as expected (same as they have before) . Also any existing rules or automations would not need to be changed. Another reason is that using the switch paddles to dim smart bulbs should still have the switch “look like” its dimming even though the load is held at 100% the intern “logical level” and the LED bar should reflect the desired setting as well as what is being sent back to the hub.
I can’t speak to your first point as I don’t use any zwave bulbs directly. For that though, I can understand why you need the switch the essentially be a hub, since it plays the role of orchestrator in that system.
I was more referring to a hub based setup. As long as all button presses (including HOLDs) are exposed to my hub, and the LED level is exposed to my hub - then my hub should be able to do everything. I feel like it keeps it cleaner to not have the same piece of information (the brightness of my smart bulb) held in 2 distinct locations.
Figured it out @stu1811!
For anyone else if you’re getting this:
“Status: Invalid Fragment Size=0x02”
make sure your fragment size is 28… for some reason mine was defaulted to 40.
2 Likes
mamber’s suggestion is the correct one, IMO. Any z-wave dimmer already maintains the dim level internally, hence why when you go back to turn on a dimmer locally it will default to the last level it was set at (some dimmers can be programmed to override/change this). All the Red Dimmer is doing that is different in SBM is keep the voltage constant on the triac (or whatever load controller they using). The dimmer then operates like a Z-wave remote dimmer accessory.
Having to have the hub to feedback to the dimmer what the dimmer is doing is actually a kludge, IMO.
1 Like
If you’re talking about direct zwave dimming with no hub, then I’d agree.
But if your hub sees the bulbs, then I think having that data stored in the dimmer is the kludge. I mean, when I press a button - the switch technically doesn’t even know what’s going to happen. That button is just sending an event to my hub, which then might be doing various things dependent on various other conditions. Is the switch supposed to contain all the internal logic that’s contained in my hub so it can independently calculate the same value as my hub, and then internally update it’s led bar? Seems a lot more reasonable for my hub to just tell the switch what’s it’s led bar should be.
I don’t follow your logic, why should the dimmer have to calculate anything?
That’s like saying Z-wave remote accessory dimmers shouldn’t maintain their own dim state??
Most modern Z-wave dimmers support instant status on most hub platforms. My hub always knows the dim level of my remote Z-wave dimmers.
If I want to dim a light to 10% at the remote dimmer then the dimmer tells the hub, “hey, the human just set me to 10%.” You can then do whatever you want with that information at your hub to take action on whatever you want.
You’d need to spell out a specific use-case where this doesn’t make sense.
1 Like
I’m doing a couple things,
I’m using the long press events to cycle colours after the config button is pressed. Basically, I’m listening for the config button in node red, and starting a 4 second counter. If I get a long press up or long press down event before that 4 seconds end - instead of triggering my dimming functions, I’m cycling RGB values on a loop.
Also, during straight dimming, when I hit the lowest dimming level (the level where I can continue dropping the brightness but there is no longer a visual change in the light output) I start turning off bulbs. I should clarify, the light fixture in question is a 3 bulb fixture. So at10% brightness, I continue dimming by turning off bulb 3, then bulb 2 - I never let it dim all the way to zero (which in this case would mean turning off the last bulb).
Thank you for sharing that. In your use-case you’re not really dimming, you’re using events.
And again, according to the Z-wave specification and how dimmers and remote dimmers work, your hub could calculate to whatever % you think the virtual/group/whatever dim level should represent and send that command back to the remote dimmer, ie, “hey, set yourself to 10% now” and the dimmer’s status lights would show 10%. This would alter the status lights but not affect your load levels since you’re using events (long hold on paddle) to trigger your action logic that sets your load levels on the devices elsewhere…
There’s zero reason to alter how a Z-wave remote dimmer should fundamentally operate as per the Z-wave specification and command classes.
1 Like
Exactly. That’s what I was saying. As long as my controller can control the status light, then its irrelevant for the switch itself to know anything.
But I understand in your context where the dimmer is controlling the light directly why it would need to know that.
I was just saying that in a hub scenario, I want to have only one canonical source for the status of various entities. If that data is in two places, and different things are running logic based on reading that status from different places - then I feel it adds extra complexity into the system (and potential bugs).