They should work just fine, but like @harjms mentioned, it would probably be best to bench test it first if you can.
Sorry for the confusion lol. As @Bry mentioned, definitely try to hardwire them as these switches are not rated for outlets. In theory if they are single-pole and you use Full-Sine Mode (Parameter 22), it should work, but we can’t officially endorse it as it’s not rated by UL for outlets.
Another option for you would be to use a Z-Wave smart plug (Zooz has some) that supports the wattage and then use Z-Wave Associations from the switch to the plug.
But if you want a hardwired approach to control an outlet, then I would recommend what @StevenZwave mentioned.
I haven’t made a location yet, but I will throw something in GitHub and let you guys know shortly. Great idea!
No, I just hadn’t updated the GitHub page – I just added the parameters and descriptions so it should be up to date!
Looks like I made a mistake – checking with the other Eric. I thought this made it into this firmware file. But I don’t see it either. I was testing 1.01 and I see it in the 1.01 change-log. I’m just noticing this today as I updated the GitHub parameter page.
If you need Leading Edge, let me know and I can share the 1.01 file. I feel really dumb.
Yeah this is my fault (again… arg)… the correct parameter is 161.
The GitHub page should be up-to-date now with the correct parameters.
Looks like @mamber nailed the rest of the questions you had – let me know if you have any more!
Yeah sorry about this, this also happens on the Blue Series switches and this was the explanation we got from the engineers:
The reason this happens is that the traveler wire is used to detect when the dumb switch is toggled. When there are many bulbs, the switch can sometimes get confused about whether the switch is flipped or not when the circuit is at a higher level. So it flips the load on and off quickly. Lowering the max level will get rid of the interference on the traveler.
Correct
When did you update them? We just pushed an update late last week. The problem was that there was a new fingerprint that was used on the device that we didn’t have in the driver. So, if you installed the driver before last Friday, then that’s likely why it’s not picking it up.
I’m also not too familiar with HPM and how it grabs drivers. I just installed the driver manually from GitHub, so maybe there’s a disconnect there? I’m not sure.
I can tell you that I was able to get it to detect following these directions (I just re-verified just now): Knowledge Base Redirect – Inovelli