I am trying to write my first Z-wave device handler although this is my first Z-wave handler I have written other device drivers successfully. I have an issue where the driver will not parse all of the relevant Z-wave commands and was wondering if this is a limitation of the hubitat device or a limitation of my knowledge
As I understand it the parse function should trigger when a valid z-wave event occurs and then I process it by providing the required function and passing the received command to that function.
For my device that is working as expected on some of the button pushes. However on other button pushes the zwave event is not parsed. I know they have been transmitted because I can see them with my Z-wave sniffer but nothing shown in the hubitat logs to indicate the event has been seen or processed.
Whilst it would be good to get my device working this post is more about developing my understanding.
Below is a capture of the button press that doesn't seemed to be being parsed:
If I have bought a device which isn't supported than I am happy to do some leg work to get it working and in fact from academic point I also like to understand how things work rather than just rely on others to make things work for me.
However I am completely stuck here and not sure if its a limitation of the habitat hardware and therefore I am wasting my time or I just need to keep persevering.
I have the device joined without security and I can see the colour set command is being transmitted by the device but seems to be completely ignored by my hub (no response from the parse function) and therefore its pointless trying to build a function to actually handle the incoming event.
@jtp10181 Hi Jeff, Thanks. However that's where I started. However nothing is being logged by the hub despite the Zniffer showing that a frame is being transmitted. To be honest I have all but thrown my driver away and working with the basic Z-wave tool.
I have just tried enabling the security in case that was something "funny" happening but that just seem to have made things worse.
That is certainly odd. The HE docs show they support the SwitchColor classes.
Those captures you got I think are the packet going from node 49 to 29, I assume you can the see it go from 29 to the hub as well? It does show it en-route to the hub so it should get there.
Also, have you tried sending the device a SwitchColorGet ?
When you changed to security I assume you factory reset the device and then joined it again?
Glad you said that. I thought it was just me going mad
Yes they are reaching the hub. I have joined and reset many times since these original captures. The route is now going direct. ie no hopping
Not sure what the device would do with this as its a touch panel but I will give it a shot and see what happens.
Yes. The odd thing is that the hubitat picked it up as a thermostat device???? Also the Zniffer was pretty much missing all of the button presses from the device so not even sure that the events were being generated so I guess I am not surprised that the hub is not responding to them.
I have another hub in the garage but its not close enough to allow the device to join too so will try and move it later on and see if that makes any difference. Not expecting a miracle but its something else I can try.
However I will need to give it an hour or two before I try it though as my patience level is almost 0
Wait a minute... Color Switch Set, that's the device sending an outbound command to SET the color of something (the hub in this case). The hub is ignoring it because the hub itself doesn't know what to do with that. The hub does not support inbound Set commands AFAIK, just outbound.
I think you would need to associate the device directly to whatever you want to control, so it can send the ColorSwitchSet directly to the device and not the hub.
I wonder if there is a way to configure it so that it sends a report to the hub instead of a set? If you find a link for a manual I can take a peek at it. I could search for it also but working on something else at the moment.
MMMMM. Maybe this is my lack of understanding and why I am going nowhere. So I know this is a set command. I was thinking that I could write a device driver to handle the command and control the relevant device, I have also read that there is a mirrorme app that might do this as well but if you are right that the hub wont parse the set command then I guess I have an ornament. However looking at the RGB device drivers that @bcopeland wrote I thought this was possible although he uses a child device which I haven't tried to replicate yet.
Control of groups of other Z-Wave devices using 'ON', 'OFF', Dim and Color Control commands.
Activation of scenes in Gateways
Basically that's saying you can directly control other zwave devices. Point 2 is sending some sort of button press or command to the hub in which you could activate a preset scene. After looking further in the manual it looks like it uses centralscene notifications.
So... are the devices you want to control with it zwave? If so I can help you set it up.
@jtp10181 thanks for your help but infortunately the device I want to control is not zwave so direct control is not an option. I was hoping to be able to use the touch panel and then use the mirror me app to control the non z-wave device.
It does appear that the Color.swich set is just not parsed (which kind of makes sense but would have been nice to confirm 100%)and therefore it appears there is no way forward with this device. Shame as it;s a nice panel and I can't see to find alternatives in the UK.
RGBGenie devices are not available over here which seem to be supported
If you have a manual and link to a custom driver for the RGB Genie I would be happy to take a peek to see if there are any hidden secrets of how it works. That device is possibly sending a ColorSwitchReport to the hub, basically telling the hub: "FYI here are my current color settings". Which the driver can then post as an event and other apps can action from it.
Sending a ColorSwitchSet to the hub is basically telling the hub itself to change colors. The hub does not support that command class inbound (inclusters), so it is understandable that it is ignoring that command.
@jtp10181 thanks i wasnt expecting to drag you in this much but if you have time it would be nice to bottom this out. Manual and the link to the driver is below:
It appears that device works in the same manner as the one you bought. You can see in this chart that it only sends an alert to the group 1 (hub) if it is factory reset. The rest of the commands go to group 2 and it uses the same Color Set command that the hub will ignore.
There is one parameter called "Send to Where" which has no additional info so not sure what it does. Guessing maybe if you set that to 0 it will send everything to the gateway (hub) but again, its commands the hub will mostly ignore because it is not an RGB controller itself.
Do you have any evidence that it works differently?
No but the driver written by @bcopeland includes the following method:
void epZwaveEvent(hubitat.zwave.commands.switchcolorv3.SwitchColorSet cmd, short ep)
so would suggest that it does indeed do something with the switchColorSet Class.
However....................... After taking a little bit more time to understand the driver I think I may have had a bit of an understanding breakthrough.
Whilst pressing the colour wheel or the RGBW buttons as well as a ColorSet cmd being transmitted there is also a MultiChannel Command. I now believe that the driver is actually parsing the multichannel command and the SwitchColor method is then being used to set the child device that is created when the device is created and therefore I need to do something similar. I guess its time to learn how to get the multichannel encapsulation working.
No the zwave command would not be setting a child device on the hub itself, that is sending a command to the device.
In this case, this would be for if you change the color on the hub, it would send it to the RGB Genie, which would then change its set color (not sure if the display changes?) and send out the ColorSet command to its associated Group 2 devices.
In order for the color wheel devices to report color changes back to the hub so you can act on it, they would have to implement a ColorSwitchReport. I do not understand why they chose not to do this, it seems like it would be a simple thing to add and allow the device to be more versatile.
The multichannel is just a way for a device to basically have multiple devices embedded in it. So for example a double outlet may have two channel endpoints so that you can control each one separately. On the hub side this could be displayed as child devices. The parent driver will encapsulate the commands with the endpoints using the multichannel class. When the device gets that it then knows which endpoint to apply the commands to. This goes both ways, the device will also reply back with multichannel encapsulation to indicate which endpoint the reports are for.
Thanks. I think I have finally got it....... So in summary for anyone that is following in my footsteps this device (Sunricher SRZV9001TRGBW) can be used to directly control other devices via association but cannot be used to request color change to the hub for ongoing processing.
