Please support the Leviton Wifi switches and dimmers. Amazon, Google, and SmartThings have support.
Model #s?
Basically everything that requires the My Leviton app.
- DW6HD-1BZ
https://www.amazon.com/dp/B01NASBN1V/ref=cm_sw_r_cp_apa_i_h4rvFbBN0JAP7
- DW15S-1BZ
- DW15R-1BW
1 Like
AFAICT, there is no official MyLeviton API, so it’s very unlikely we’ll see an official Hubitat integration. I think Leviton created the SmartThings, Google Home, and Alexa integrations.
Looks like the Home Assistant folks reverse engineered the MyLeviton REST API using the Android app to create their integration.
Maybe a Hubitat community member will be motivated to do the same.
2 Likes
This guy has a pretty clean breakdown, and it looks similar to the flow that I used for supporting Genie Aladdin here.
I'll ping you via direct message @ken. If we can get the communication working as a proof of concept, it shouldn't be too hard to write a switch/dimmer driver.
3 Likes
There actually is an API, it just isn't public. You need to apply to be in their developer program. See here:
http://homeauto.com/support/developers/developerapplication.asp
2 Likes
Thank you...that would be awesome for me...and a big one for Hubitat in general. Those switches are pretty popular.
It doesn't look like that implementation will receive state change notifications if you manually turn a switch on or off. SmartThings has that functionality (Alexa and Google do not), and not having that is what's blocking my move. There are plenty of ways I can think of to easily hook up a Hubitat to control these devices via a 3rd party that can do it, but none that would be able to react to someone turning a light on or off using the wall switch.
1 Like
They probably have a webhook or something that you can subscribe to. We'll see what they share if I get approved for the dev program.
3 Likes
I'm not holding my breath on their developer program. I applied also.
Since I have neither a hub nor any groovy experience, would you be able to write a controller driver based on the python code? Worst case I'll replace the switches that need bidirectional control with z-wave versions.
Spoiler alert: if you apply, you aren't likely to get a reply. I never heard back, either.
In the meantime, I made a driver which is ready for beta testing, based on info that I cribbed from python-decora_wifi.
The code and installation/usage instructions are here: GitHub - tomwpublic/hubitat_myLeviton
Request for input: switches and dimmers are combined into a single child driver. I am interested to hear whether this creates any confusion or issues for users that give this a try with various Hubitat apps and extensions.
2 Likes
I tried it out. The only issue I have is that the refresh interval is too long if you want to use it for automations. Waiting a full minute for the status of the switch to change makes it pretty useless as an automation trigger.
I changed the code so that the refreshInterval was in seconds, rather than minutes, and then set the value to 5. It works better, but I'm not sure if the constant polling will be an issue for Leviton or my network.
1 Like
Yeah, refresh interval is tricky.
These devices don't push updates, at least not in a way that has been discovered publicly. So, any integration is left to poll for updates.
On the one hand, this makes status updates be pretty laggy, unless you're operating the switch via Hubitat in which case they should be timely.
On the other hand, these are switches and dimmers, not buttons. So, it would be nice if a physical update could trigger an event for automations, but as you said crushing the server with polling for updates in order to accomplish this could have other unintended consequences.
I know that @djgutheinz has tried many times to tackle the polling interval challenge in his Kasa drivers (which I use and am very happy with).
I'll update the refresh interval input to be in seconds rather than minutes and set the default to something moderate, like 30 seconds. Thanks for your feedback.
EDIT: the polling interval is now specified in seconds in the myLevitonSystem driver. Anyone who updates that code should be sure to update the setting on the system device accordingly.
Mine aren't dimmers, they’re just switches. So I just need to know the on/off state.
I too signed up for the developer access. Figure maybe if one of us gets in then we can share the knowledge.
1 Like
Thanks for the kind words. Note that the Kasa Integration is LOCAL and not cloud-based. If it were cloud-based, I would not have support fast polling due to the impact on the Kasa cloud as well as Hubitat.
1 Like
I'm going to chime in here because I've been working with @tomw on this project, mostly testing, but also on design.
I completely agree with this. I would not pound a cloud service any more often than once per minute. @storageanarchy's Ecobee Suite Manager is also a polling driver for a cloud service. I currently use that set up to poll once per minute.
I think that's fine, but the minimum value should be 60. We don't want Leviton blocking the driver because people are abusing them with it.
I agree. Unless Leviton shares their API with us, this driver is useless as an automation trigger. What I realized is that even though I had a lot of these switches, the vast majority of them were not needed as triggers, only as results. If you go through your setup, you will probably be surprised at how few of your light switches you actually need as triggers. I ended up replacing most* of my trigger switches with their Z-wave equivalents -- Leviton's Z-wave switches are quite good at reporting instant status, and they're much faster than the cloud switches because everything is local.
I suggest you review your home automation and see how many switches you actually need as automation triggers and how many you only need to control as the result of a trigger.
*Why not all? Because I realized that there were some automations I had where I was OK with a 1 minute delay, so there was no need to replace those switches.
1 Like
I agree. I modified it to make the default 60 and also added a brief comment that 60s is the minimum recommended value.
In that case it's not much use to me. I'd be better off using ifttt which only has a 5-10s delay.
If Leviton ever accepts any of us to their developer program and we can use a websocket or webhook then I'll go with a direct driver.
I understand- sounds like your use model has a faster latency requirement.
I'll just say that you are free to poll that quickly if you like. I suspect at some point that the server will throttle access, but I don't have a guess on what that threshold would be.
I'm playing with this a bit more and I have a couple of suggestions.
First off is the naming scheme. You've hard coded the name and label of each device to {SystemName}-{DeviceName}. This creates issues with Alexa and Homebridge because every device has a weird name instead of the intended logical name. For example if I call the system 'Leviton' then all my switches are something like Leviton-Kitchen Light, instead of just Kitchen Light. You can change the device label but it's tedious when you have a bunch of devices like I do. I ended up changing the code to just use 'name' for the 'label' attribute but kept your naming scheme for the device name.
The second issue is that you don't do any status checking before sending the command to Leviton's servers. With this setup it's possible to create an IFTTT loop. For example say you set up IFTTT to listen for a Leviton switch to turn on then set the Hubitat switch to on. That causes the Hubitat switch to send another on command to Leviton, which then triggers the IFTTT trigger, which then repeats the cycle. I set up a little test using notifications and it appears that after 3 cycles Leviton or IFTTT stops this loop, but it's still bad form. The driver should update the status of the device and then compare it to the command that's being sent and if the states already match it should just return without sending the HTTP command again. The only potential issue I see with this approach is that if you do an HTTP status check it could lag which would slow down the triggering of the switch. However if you just compare to the current known status of the device then at worst it would cause one extra loop cycle but should stop on the second attempt as the status will have been updated from the previous call.
I'm going to make both of these changes on my end, but I thought you might want to consider adding them to your project as well.
My plan here is to use a combination of Hubitat and IFTTT to keep the status of each device synced rather than using a higher polling interval. Since IFTTT is officially supported by Leviton I shouldn't have any issues with using their triggers to keep everything synced. Although since I have 22 devices, and each one will require two IFTTT triggers (on and off) it's going to be a b*tch to set up. (I already pay for the IFTTT pro service, so that's not an issue)
