Anybody looking at the new Homeseer HS-WD200+ wall switches? Specifically to create a Device Handler?
I have a house full of the HS-WD100+ (and they work great!), but the HS-WD200+ adds the one thing I feel is missing, programmable control over the LED lights - not just for on off, but complete control over all 7 individual LEDs for color and on/off! I would love to replace a few 100s with 200s if a new DTH provides everything to webcore.
In their own words:
“In status mode, individual LEDs can be controlled to reflect the status of nearly anything in the home. For example, if it’s after midnight and the garage door was left open, the 3rd LED on all the bedroom dimmers can be programmed to glow yellow (or any color). If a smoke alarm goes off, all LEDS on all dimmers can blink red. If no status conditions are active, wall switches automatically return to normal mode.”
I used to have this feature with a Control4 system, but left that in an old home when I sold it. (Example: with 2 dogs that go outside first thing in the morning - ‘If Alarm is Armed, set LEDs = Red’)
I was informed by HomeSeer that they have already created a SmartThings device handler based on my code for the WD100+. Their commitment to the SmartThings platform is impressive. Since it’s based on the previous handler code, existing CoRE rules should (hopefully) work as-is if the device is swapped in place for a WD100+.
Fantastic. In that linked article, they even mention you have to use Core to set the Status LEDs. Awesome. Now, if we can just get this DTH approved by ST as lighting so it can be run locally. Your DTH, and I bet this one will make it be a cloud only device - so you have a minor set back.
Here’s what Homeseer gets though for this prompt support - even after a house full of the 100s, ordering several 200s right now. Yay.
Nice, installed my new 200 series dimmers and switches today and they work perfectly with smartthings and the above mentioned device handler. The led colors can be configured in the device handler to various colors and they are nice and bright.
Yes they do, but there are is limited documentation on how to set the switch to status and change the color of a LED. I’ve tried several combinations of commands, all to no avail. I can increase lumens, turn the switch on or off, just not able to set the LED a specific color. I called support - they said they are making a video.
I just replaced two of my many 100’s with 200’s. Like above, I am able to change the default LED color through the provided device handler. The 200’s also easily integrate into my CoRE pistons that used the switches I replaced.
I have begun to try to use the status lights with CoRE. I have not yet been able to get a specific LED to respond to a trigger. Using a nearby motion detector as my trigger, so far I have tried:
First sending the setSwitchModeStatus command, followed by the setStatusLed command.
After returning it to “normal mode”, sending only the setStatusLed command.
Using both methods above, using both number and string as variable type.
Using the string type, using the *** and ,,* format.
Having the blink variable on and off in each attempt above in case that was a problem.
All the above actions were performed with each individual 200 switch, as well as both combined.
The only small success I have had was when I started in normal mode, the activated trigger did indeed switch it to “status mode” and turned off all the LEDs. Manual paddle use after this remained LED-free. If I sent another piston to activate normal mode, it returned right away when trigger was activated.
I’m out of ideas. Anyone else have any success or other ideas? Anyone with experience using variables able to tell me which format will (should) work eventually (with or without commas?)
I pretty much did everything you described as well. I too can get the
switch to “seemingly” go into status mode, but no joy in configuring any of
the LEDs to change color, blink, or otherwise. Interesting enough I’m
able to increase brightness turn onto off the light.
I also tried removing setSwitchModeStatus and just using setStatusLed.
Nothing…
Their documentation states “setStatusLed (led,color,blink)”
Your first digit set the lowest LED, thus we can learn they count from bottom up
Your second digit is the color:
0=Off
1=Red
2=Green
3=Blue
4=Magenta
5=Yellow
6=Cyan
7=White
And the third digit is blink=true.
Detailed, but seems surmountable. Great stuff!
I just got my first 200+ switch, but may not have free time until this weekend to really get it installed and start writing pistons. Exciting!
Considering HomeSeer is a competitor of ST, I have to say I am impressed with their efforts to support ST - of course, they drive hardware sales this way, but still…
Finally installed the switch and attempted the programing. It’s a little funky to find the way to set the values that go inside the parentheses setStatusLed(1,1,1). There is a dropdown (Parameters) near the delete button to set.
All that worked for me, but I accidentally set them all to blink. I went back, change the third attribute per LED to ‘0’. Note in the off condition I also used the setSwitchModeNormal and the light returns to normal operation. However, after making the change to not blink - only the lowest LED would go steady while the top 6 remaining LEDs continuously blink when triggered. Nothing I did would change that state. I rewrote the piston to ONLY control the 6th LED or only LED 1 and 2. In all cases, the lowest LED was solid, the rest were blinking. Anybody fine a reset command of some sort?
It sounds like you’re trying to program all or perhaps many of the LEDs on one dimmer simultaneously? What I found is this… When I try to invoke the SetStatusLed command on multiple LEDs simultaneously, I put the dimmer into a funky state. For example, If I set all seven LEDs to turn on, then immediately off. By doing so, I put the dimmer into a state where invoking another SetStatusLed command later in the piston yielded undesirable results, meaning the LEDs on the dimmer were not behaving as expected when issuing the SetStatusLed command. Instead the SetStatusLed command behaved much like what you described above - what I would call erratic. The only way to get out of this state was to reset the dimmer back to factory default. To do this, you’ll need to follow the instructions found in the user guide. A snippet is below.
(1) Turn dimmer on by tapping the top of the paddle once.
(2) Quickly tap top of the paddle 3 times.
(3) Quickly tap bottom of paddle 3 times.
(4) If light turns off and then on again, dimmer is reset
I was hoping to set the LEDs to perform whatever I want, whenever want. However, it seems when using SmartThings/Webcore, for the time being, we’re limited to invoking the SetStatusLed command to 1-2 LEDs, maybe three LEDs simultaneously. In other words, invoking the SetStatusLed command on one LED seems to work fine. But invoking the SmartThings command on all 7 LEDs simultaneously seems to break it. Homeseer has informed me that this should work using their controller. I’m going to test it out.
I have not had time to try @dougberman’s solution. However a few notes to add.
Homeseer youtube part 2 for this device, now covering setting the LEDs is live (using Core, not webCore - too bad, oh well!). https://www.youtube.com/watch?v=99Ufc5-fv20
I note he did NOT use setSwitchModeStatus yet it worked. I saw notes that if no LEDs are set the switch automatically falls back to Normal Status…I wonder if the opposite works, ‘if ANY LEDs are set then the switch automatically sets to Mode Status’? That is my guess.
I emailed Homeseer that my switch is stuck, they replied today as well. They stated the following:
You cannot send this many parameter changes to a z-wave device at once. If you are only trying to turn the LEDs red, simple change the color with setDefaultColor(1) and to set it back to white use setDefaultColor(0).
That seems a really important note! It also left me with a bunch of questions for them, which I sent back in email to them.
My questions:
With setDefaultColor(1), does that also turn them on. I am already using setSwitchModeStatus(), but I am not seeing what will cause the LEDs to light up. Note I am not home to test at the moment.
Per your mention of a z-wave limit, if I had wanted to individually set all 7 LEDs based on 7 different events (let’s assume different colors and blink vs steady state) how would I handle this to handle the mentioned z-wave limit?
Nor did they offer any way to get the switch unstuck (as @dougberman has suggested).
I’ll continue to post as they reply. We’ll get this right and figured out!
RE: setDefaultColor: Q: Does that turn them on? A: “Unfortunately, this solution would only work if the lights were on.”
RE: z-wave limit: Q: How to overcome limit? A: "You simply cannot send all of the commands at once. If you need them all to change try setting a small delay between the commands. I will add something to the documentation to clarify this."
Seems reasonable - any z-wave specialists out there that can comment on command speed limit? 200 miliseconds enough time between commands?
RE: Switch stuck: Q: How can I get it unstuck? A: “In order to reset the LEDs, use setStatusLed (N,0,0)”
*Where ‘N’ = LED in question. I might pass this one at a time to reset each LED, then start over. I’d rather do this than the reset @dougberman offers as resetting the switch pulls it out of all the pistons (I think)
Not sure I can test all this tonight, but I’ll get to it.
I used 500ms delays between Z-Wave configuration commands in the WD100+ device handler and didn’t run into any issues. I did not test for a reliability limit since this does not affect normal performance.
Good to know. I am hoping 200ms is safe, if I have 7 LEDs to set @ 500ms each, that’s 3.5 seconds, which would be painfully obvious (to me - and only me, but still ).
