@bgreet - Try again. 
1 Like
Perfect. By the way, would definitely codename this release as 1.47 HWHL release (happy wife happy life). Both the wife and mother in law greatly approve.
1 Like
@EricM_Inovelli When I enable smart bulb mode I am able to dim the smart bulbs and the light bar while the power stays at 100%.
Only issue I have is that it cuts the power when the off button is pressed. This causes the bulbs to lose power until I press the on button again. Is this the intended behavior?
Completely agree. Across the board win. ST is faster, switch is faster, the updates when locally controlled are faster to the ST app, etc.
I did ONE TIME last night think I saw a flicker when on 1% for a duration of time, but frankly it might have been when an AC unit kicked on so it might have just been a coincidence. Otherwise 12 hours of SOLID performance here. I loved the update so much I pushed it to my other 15 switches, up to ~20 ish that are working GREAT!
1.47 - HWHL update 
1 Like
Still need to disable local control even with the smart bulb setting on. This was just to force the switch to be at 100% all the time.
Thatās too bad. I was hoping it would leave the relay on all the time even when the off button was pressed and allow the dimmer to show the dimming level too.
1 Like
A few items:
A) After enabling the smart bulb parameter (52) the bulbs seem to hold their power at low dim levels. No resets, no flickering. Yea!
B) Iām not sure the documentation of āDisable Physical On/Off Delayā (parameter 51) is correct. The documentation says that when 51 is set to Yes than buttons 2-6 are disabled. Neither 6 nor 8 are disabled. And thatās good IMO as those buttons relate to the physical press and hold of the toggle buttons, which get mapped to raising and lowering of lights. It would be great to see even more minimization of response times for buttons 6 & 8 when set to Yes.
Relatedly, there is no documentation other than this community board ([HOW-TO] Hubitat: Setting Up "Scenes" in Rule Machine) with the button maps. And that documentation has the actions of buttons 6 & 8 swapped. IMO there should be an article at https://support.inovelli.com/portal/en/kb/inovelli/products/troubleshooting/hubitat for the buttons.
C)
I had to re-enable the local control parameter in Hubitat to get the expected functionality. Steps: 1) toggle āDisable Local Controlā to No, save preferences 2) toggle āDisable Local Controlā back to Yes, save preferences.
All in all the 1.47 update is really good!
Just updated a bunch of these. No problems so far! I did notice that parameter 51 seems to default to a āmulti-taps offā setting (Hubitatās Basic Z-Wave Tool reports -127 for the value, and multi taps do not work; manually setting parameter 51 to 1 restores this functionality, so Iām not sure what this apparently invalid default value is). This has happened on each of the three devices Iāve updated so far.
FYI keep at it on the bin file if it doesnāt work the first time. A few of my updated took up to 4 tries flashing the bin before it took. Each time different behavior on different packet numbers but in the end I got them all flashed. Dear Lord please let this be the released version because one at a time using z-stick took SO LONG.
I am running home assistant and for some reason my scenes are no longer working with this firmware. Anyone have any ideas? This is my config:
<CommandClass id="91" name="COMMAND_CLASS_CENTRAL_SCENE" version="1" request_flags="4" innif="true" scenecount="0">
<Instance index="1" />
<Value type="int" genre="system" instance="1" index="0" label="Scene Count" units="" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="-2147483648" max="2147483647" value="2" />
<Value type="int" genre="user" instance="1" index="1" label="Bottom Button Scene" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="-2147483648" max="2147483647" value="3" />
<Value type="int" genre="user" instance="1" index="2" label="Top Button Scene" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="-2147483648" max="2147483647" value="3" />
<Value type="int" genre="user" instance="1" index="3" label="Config Button Scene" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="-2147483648" max="2147483647" value="0" />
</CommandClass>Iād love for Inovelli to release a better tool than what is currently out there for flashing devices. Current options are clunky. @Eric_Inovelli, any chances of you folks releasing some kind of tool (generic command line type thing would be great) to help us flash devices quicker so we can give you feedback faster?
Hubitat has a tool that letās you push OTA updates to the devices from the hub itself, not sure what that looks like but ST also has been hinting at this integration as well.
At 20-30 mins per device, I spent somewhere in the neighborhood of 7.5 hours updating devices (on and off) this weekend.
Fun hobby I guess?
Unfortunately, no we donāt have access to all the hubs out there to be able to figure out how to push OTA updates. This has been a problem for a while with a lot of them and the reason why we have to go down the Z-Stick route.
Basically, how it works is that each hub has its own proprietary way of allowing OTA updates and most do not allow Z-Wave updates at this time. Even if we were to come out with a Z-Stick of some sorts, it would be the same process as with any of the other Z-Sticks out there.
Hubitat is the only hub that I know of that allows OTA (possibly HomeSeer too, but Iām not entirely sure) for Z-Wave at this time. Even there, it can take a while depending on where the device is in relation to your hub. If itās close, it shouldnāt take too long, whereas if it is further away, it will take longer as the packets have further to travel.
I wish there was a better solution 
@kreene1987 - I know itās a pain and extra money, but look into a Z Wave stick. I flash a device in about 2-3 minutes (for the large file) and about 1-2 mins for the Black devices. I get about 2-3 ft from each device before flashing (via laptop and Z wave stick). Time is precious and at $125 hourly rate (my time worth) it was a no brainer.
I was actually dreaming of a better Z-Stick method thatās specific to Inovelli. Iām running Home Assistant on a Synology NAS via Docker with a Z-Wave stick. Since Iām already using a Z-Stick it would be nice to run a *nix command line tool that automatically finds all the Inovelli devices and updates them. This would be hub-agnostic.
Iād honestly pay a bounty for thisā¦ whatās 30 devices x 10 minutes x $60/hour? Totally worth it. (I know, I know, bigger fish to fry on the company side, but maybe some dev here whoās smarter than me will take me up on it.)
2 Likes
Iām hobbling along on what Inovelli gave me praying for the ST OTA for Z-Wave to become a reality.
Iām cheap, but this update was too good not to implement.
1 Like
I noticed for this 1.47 release it looks like there is a .otz and a .bin file. With the Hubitat firmware uploader, it only supports .otz files so I just got a new zwave stick and added it as a secondary controller so I can update bins as well. For this release of 1.47, does the .bin also need to be uploaded or just the otz. and if yes to both, can you confirm I flash the file LZW31-SN_1.47.otz to target 0 and LZW31-SN_1.47.bin to Target 1 (which I think is the Holtek part)? Is that right?
@dario_rossi - Correct. You should be flashing both. The .otz will go to target0 and .bin will go to target1. Also the new updater tool will now do both files.
2 Likes
Awesome! Thanks for the quick reply!
Just used the new updater tool (Hubitat) to update .otz and .bin to 1.47. Is there any way to validate the version of the .bin file from the switch after the update? I can see the firmware version of the .otz but it was showing that before I did the .bin file