I recently updated to Z-wave JS and my three HSM200's can no longer set the LED colors correctly. I've tried the driver linked in this thread, as well as @kahn-hubitat version (EZmultiPli new) and erocm1231's version (EZmultiPli)
Anyone else seeing a similar issue or come across a solution?
I'm having the same issue with my HSM200. Tried 4 different drivers but none of them work properly. I might need to roll back to legacy Z/IP or move them to my C7 and use Hub Mesh until all of this gets ironed out.
If the driver worked on ZIP it should work on ZWJS with one rare exception.
If there are not errors in the logs it is probably not a driver issue. More likely either ZWJS is having issues completing the interview with the device, or one of the command classes being used is broken in ZWJS.
My guess is the color switch command class. If Z-Wave bulbs weren't all mostly terrible, I might still have one around to test. Might have an old Inovelli light strip around somewhere I could use to confirm...
I was thinking that might be the issue based on what I was able to find on Homeseer’s website.
It’s not entirely clear to me how Zwave JS might be impacting it but I feel like the issue is related
All of the command class parsing had to be rebuilt to handle the data from the JS gateway and parse it into the expected format. There are hundreds of these especially when you consider most have multiple versions with different output. Some of the less commonly used one did not get tested well in beta and may have lingering issues.
I have a few Inovelli light strips I can test later today. Their CCT LEDs have turned on/off since I migrated to Zjs but I havent tried any colors
Just tested tested an Inovelli color bulb, and color control (and CT, which I already suspected due to not noticing any problems) worked for me. So, I'm not sure it's something with the Switch Color command class, or at least not the entire class in general -- though that doesn't rule out some problem with some specific piece of this, or maybe one particular version that the bulb driver isn't using, etc.
To figure out what's going on with yours, it may be helpful to know more information:
(I don't have one of these and I don't know if Bryan does anymore, either, so the above is probably the next-best...)
Also, moving this all into its own topic since you had posted in two different ones before, and this should make this particular issue easier to track.
Thanks for the help
I switched to the built in driver as you suggested. Unfortunately it does not allow any control of the LED (only gives motion state, temperature and illuminance). If I recall correctly, that’s the reason for using the community driver instead.
Here is the driver I had been using for several years. The discussion in first post is likely related to why it’s not working on Zjs. Apparently it does not use the Switch Color command class
I’m no longer able to change the color of the LED using the community driver above. Turning it on/off isn’t an issue.
I can do some testing and check the logs this week
I don't think "color control" exists on Z-Wave (sounds like the Zigbee name for the similar cluster?), but from that snippet of the driver, it's apparent he's using raw hex. That's not going to work on Z-Wave JS. But it also appears he's using command class 0x33 given the "33" that all those raw strings start with. That's the Switch Color command class, adding evidence to my assumption. Perhaps this didn't exist when he wrote the driver, or maybe one of us is very confused...
In any case, it should be possible to rewrite the driver using the Z-Wave classes provided by the platform, unless something is missing (not sure what this device needs offhand -- I don't have one and didn't dig into that driver much -- but I'm not aware of any gaps here). The problem presented so far, however, is a driver problem and one that nothing with the platform or Z-Wave JS can fix as long as it's parsing or sending raw hex, which is tied to the legacy implementation.
i have tried (still on zip) to use the switch color instead of the hard coding hex.. but it does not seem to work.. ie
result << zwave.switchColorV3.switchColorSet(stateDataLength: 3, red: rgb[0], green: rgb[1], blue: rgb[2], warmWhite:0, coldWhite:0)
doesnt return any errors but also doesnt work.
Without seeing that in context or at least a minimal example, it's hard to say more (e.g., do you ever format() it?), but offhand, the only thing I'm not sure is what that stateDataLength parameter is doing, since I'm not finding any evidence for that anywhere. It's also possible this device does not support V3 of this command class, though don't know its specifics off the top of my head.
It looks like Bryan's old driver does use the class instead of raw hex. Not sure what anyone specifically has tried, but here's a specific link to that one, which is often helpful in such discussions: [RELEASE] HomeSeer HSM200 Multi-Sensor
If that doesn't work for something, I'd be curious for the same answers as above.
More evidence of Z-Wave ColorSwitch not working right
that extra parameter was becuase it was not working without it.. so tried it.. {found online in an example) but just tried again with the same approach as brians driver.. ie
result << zwave.switchColorV1.switchColorSet(red: rgb[0], green: rgb[1], blue: rgb[2])
result << zwave.switchMultilevelV2.switchMultilevelSet(value: 99, dimmingDuration: 0)
result << zwave.switchMultilevelV2.switchMultilevelGet()
same result light just comes on white.. the colorset appears to not be working..
just tried again with format ..
result << zwave.switchColorV3.switchColorSet(red: rgb[0], green: rgb[1], blue: rgb[2], warmWhite:0, coldWhite:0).format()
no go.
so that appeas to point to a hub issue vs a driver issue?
thanks for testing.
Looks like a ZWJS issue for me. My customer driver worked 100% last time I tested it, now not working on JS. The device is sending all the messages back, per z-wave logs, but they are just getting dropped and not passed to the driver.
I was able to set the colors, and device changes, but the response never makes it to the driver.
That's interesting. Not sure if I ever tested the report parsing...
But it wouldn't explain the issue that started this, which appears to be related to the Set command (which did work for me on another device and sounds like it does for you too; I just don't have one of these to test with). Out of context, I'm not sure what's going on with the above, but the questions I asked originally would still be the most helpful to know.
So different issues I guess, just same command class.
In my case the Set appears to be working, the device changes colors, but the reports are just getting dropped and never passed to the driver.
Download the Hubitat app
