@Rob - Which version of PC Controller you running?
Edit - Scratch that. You’re installing the wrong or corrupt file. The .bin file is only 399 packets. No where near the 23xx packets.
1 Like
I think that is actually a bug in an earlier version of PC Controller. So @harjms is right in his original post and the Edit. Make sure you have v5.39+. Earlier versions won’t properly grab the bin file and will try to send the otz file to target 1.
1 Like
Will update device handler and see if performance is improved. Should I keep energy reporting off for now, or turn back on (or both)?
Is this what you are looking for?:
Edit: No changelog for 2020-07-13 version of DTH, looks like some coding cleanup for boolean values?
That was it. Thanks. Once I updated PC Controller, the updates worked. You may want to mention version requirements in the instructions so others can avoid this.
Alright folks I finally got all my dimmers and switches updated to 1.45 including both target0 and target1. It took forever for my ZWave sticks to arrive and then it took a little bit of dust and cobweb cleaning to get my Windows 10 VM going again. But I’m finally here and have some updates to report. I did post on the other thread the same information.
In all my testing I can report the following:
- With a neutral present and the driver in Hubitat configured appropriately, smart bulbs and low wattage non-smart LED bulbs work perfectly without any issues. This is a notable improvement over previous tests. Right now I am up to a few hours of run time in this configuration without any issues at all.
- Without a neutral the situation is worse for smart bulbs with 1.45. All I get this go around is a dimmer with its LED bar blinking red at a constant rate. I no longer see a rave mode from the light source and the dimmer appears to be very upset otherwise.
- Without a neutral non-smart LED bulbs still exhibit instability in the same way as previous firmware versions. The “75% threshold” seems to still hold true where at 70% most loads are stable and dim without issue. At 75% or more, with loads approximately 50W or less, the dimmer will reset as though power was lost. I suspect that is what is happening as when the dimmer becomes functional again it will obey the “State After Power Restored” value as set on the device page. In addition (and this is particularly related to smart bulbs) if that “State After Power Restored” value is set to 75% or more the dimmer will go into a reset loop where every time it reboot itself and raises up to that value it restarts the reset loop again.
Hoping someone else either can confirm my results or tell me what I can do differently to overcome these issues?
Turning to the lockups issue — since updating to 1.45 I have not experienced a single lockup. The only lockup type experience I had I now can confirm was my fault in Rule Machine and not caused by any other issue. I’ll continue to zniff/test/report as it goes…
Random question: are you guys by any chance piloting firmware updates with SmartThings? Rumor has it that firmware update is coming to SmartThings with vendor support.
Wish I could “officially” say the answer to this 
1 Like
Hopefully you’re capturing the other formats required to upgrade other firmware (e.g. LZW36 obt filenames) and not sure the otz and bin files.
Since updating the target 0/1 I have finally had a chance to play around in hubitat and was hoping to get the white LEDs working. I believe I have successfully updated both firmwares as well as the device handler in hubitat, but when I select White (1.45+ only) I get red as my color. I didn’t get any errors in the Z-Wave Controller for either target, so I am not sure which piece I am missing at this point…
I was having a very similar problem. For me the problem was that i had a value in “Custom LED RGB value” Changing this to 360 made it white for me.
I have tried with and without value, will try setting to 360 next. I tried 255 and got a weird purple color.
Edit:
Tried 360 with and without white selected from drop down and got red in both cases.
Do you have the option to create an LED child device on? If so does disabling it and deleting the custom LED RGB value work?
I had it earlier today, but removed before trying to change to white since I hadn’t used this functionality yet.
I am not sure which parameter should pertain to this color bar… Here is the list I copied from the page in hubitat
- parameter2value : 3
- parameter5value : 40
- parameter21value : 1
- actualAssociation4 : []
- actualAssociation3 : []
- parameter10value : 0
- parameter8value : 0
- oldLabel : Living Room Lights
- parameter19value : 32767
- parameter13value : 46
- parameter16value : 0
- rfProtectionState : 0
- parameter22value : 2
- lastRan : 1594952378415
- parameter3value : 1
- parameter9value : 0
- parameter6value : 90
- parameter17value : 3
- localProtectionState : 0
- parameter14value : 10
- parameter11value : 0
- associationGroups : 4
- parameter7value : 0
- parameter15value : 1
- parameter4value : 1
- parameter18value : 45
- needfwUpdate : false
- defaultG3 : []
- actualAssociation2 : []
- parameter1value : 3
- defaultG2 : []
- actualAssociation1 : [01]
- defaultG1 : [01]
- parameter20value : 10
If you are still getting a red LED bar when you set the parameter to 255 then my guess is that the target 1 firmware didn’t get flashed. Probably a glitch during the process. You might want to try to flash it again.
1 Like
Thanks, third time was the charm! Love the white!
1 Like
there seem to ve two files when updating the firmware… how do we apply the other update? “holtek” or watver file that is.
You generally can’t flash it through a hub like HomeSeer or SmartThings as hubs only support one firmware target. You need to get the Z-Wave device utility directly from Sigma / Zwave Alliance. Read the full flashing instructions- it goes over it.
The 2nd target (Holtek) is a second controller chip in the dimmer which handles the RGB strip and some other functions. It’s there because the Z-Wave chip itself didn’t have enough memory for all the functions they wanted to put in the switch, so they had to offload some.
1 Like
To add to what @Chris said, Hubitat actually has the ability to flash both target 0 & target 1.
Also, check the main post because there is a firmware 1.47 out that you probably want to use instead of this one.
If you have a Hubitat hub you can use the new firmware updater @bcopeland created which allows .bin and .gbl files