Then you aren't choosing the correct device when you choose the button device or you aren't choosing "Button Device" as the trigger and you are choosing just "Button" instead.
Would you mind adding a setStatusLED(string,string,string) that calls your setStatusLed?
I'm writing an app that uses WD200 status LEDs and I just ran into an error where my code doesn't work with dimmers running your driver vs the default driver.
I already have. To be honest, it shouldn't be there. Mike should change the OOB driver. In fact, Bruce could use reflection in RM to infer data types and do conversion/casting so users might not have to supply a data type at all.
At any rate, I already have. You either don't have the current version that's been posted a while or something else is wrong.
It's the capitalization I need matching, not the param types. To not break others already using your driver we cant rename so we would need:
setStatusLed(int, int, int) // your original and IMHO correct signature
setStatusLed(string, string, string) // fix for states
setStatusLED(string, string, string) // my request to allow calling devices with either your or OOB driver
I see. You want a second overload but not because Mike changed the name but because you are going to convince Mike to also add an overload to the OOB driver?
I don't understand. This command is already not standard. What are you trying to do? Mike isn't going to add an overload I don't think.
I call dimmers.setStatusLED("0", "0", "0")
This works on OOB driver but not on yours since your is called Led, not LED. I have no illusions I will be able to convice HE to make changes but I was hoping you would add another method that matches the OOB method exactly, including capitalization since Groovy is case sensitive.
I could just do it on my end but I was hoping you could match the OOB driver?
If that works on the OOB driver then he has likely changed the name. If you read up through this thread it used to be called setStatusLed(String, String, String) and that's why the one overload already exists. People created RM rules with the OOTB driver and switched to mine. I created the first overload for that and I'm pretty sure it was confirmed to work then as "Led" rather than "LED".
I don't want two overloads. I will change my existing one. I'll setup a RM rule with the OOTB driver, switch and see if it works there and if that checks out then do it. This may force a user to change a rule, or update a hub firmware or not update this driver but I don't think that I'm going to worry about that. I'm not going to support HE changes over time; only the most recent version.
Ah! You think they changed the method name on the OOB driver? Ack!
I thought you added the string version since people swapped back and forth between yours and OOB and the state types were the wrong type.
In any case, a bit of a mess and I totally agree that your signature is correct and there are better ways to deal with this in RM. I could just use a hasCommand on my end but thought I would ask you first instead of adding more layers of workarounds.
This thread says the driver has been with drawn and I see that @codahq repo is not on Github any more. Does anyone know why? It's obviously not codahqs responsibility to keep this stuff around for anyone else, I'm just curious if it went away or got moved or is obsolete etc. This is my first post since unpacking my Hubitat yesterday. I'm making the switch from Smartthings and hoping to get more involved on the coding side.
@codahq has chosen to pull all his apps/drivers, however this device is on the compatible device list. Hubitat does not make their built in drivers open source, but they do have some example drivers.
Welcome to the community.
Unfortunately though I can add my devices, the first one I’ve added connects and shows status but does not turn the light on or off (or otherwise make updates). I was hoping the updated driver would help. Other devices are working so far. I’ll keep building my mesh and see if the other wd-200 I have work (I’ve got about 10 of them and another 4-5 of their fan cousins).
Have you tried hitting the configure button under the device?
If you are referring to the HS-FC200+ Zwave Fan Controller, I have it on good authority it will be in the 2.2.3 update.
2 Likes
Excited about the fans. Yes, that is what I meant.
I did hit configure but it doesn’t seem to do anything (no event in the logs, no behavior change or other acknowledgement.
Sounds like you have got a good plan to continue building out the mesh.
TLDR - My HS-WD200+ work with my C7 hub if (and only if) I update to 2.2.3 (and firmware update) AND uncheck all security boxes when including.
Indeed - glad to see the new firmware for my C7. I did find the driver code (searched github for copies) and that did not fix my issue. In the end the combination of updating to the new firmware + disabling security does appear to get these switches working. With S2 on, they will report status but not accept changes. Having said that a) they've been running for years on Smarthings w/o S2 so I'm not overly concerned about it and b) I haven't updated the firmware in forever. I may try s2 again after doing some firmware updates. Just as a point of reference I have the same behavior on an Inovelli gen 1 wall plug, I'm hoping disabling security there will fix it too, but I won't know til tomorrow since waking the 6 month old to find out would put my WAF down in the negative.
Hi, I'm new to Hubitat and I have some WD200 dimmers in my house. I was able to make them work, except one that's working weirdly. The led 1 stays on all the time. Even if I set it to off, it remains off for 1 second and turns automatically on. Anyone has a solution for that? I would like to set the default color as well and it seems this driver was supporting this behavior but the default Hubitat driver is not. Anyone has this driver so I can try it? Since it was pulled of...
FYI, I tried this driver with Hubitat 2.2.8.136 and got 8-10 duplicate events with multi-tap buttons. See Basic Rule Triggering many times
I switched over to Any Z-Wave Dimmer Driver v1.1.8 and single events for multi-tap are working as expected.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
