[RELEASE] MyQ Lite Door and Lamp Control (for Liftmaster/Chamberlain)

Still chugging along. I keep learning new things I can do with Edge stuff, so I’ve been mostly working on ways to make things as stable as possible. A big thing I want to handle well is IP address changes, both on the hub and the local server, which means they’ll both be sending regular pings to each other so they can hopefully automatically recover in most cases if needed. I also realized I could have the server send door status updates to the hub as soon as they are detected rather than needing the hub to ping the server every few seconds, so that will be cleaner as well.

Getting closer.

10 Likes

Thanks for your efforts.

Appreciate all the fine work you have been doing Brian! I’ve been using your integration for years and it’s been awesome. Question, for those of use who are unlikely to go down the road of self-hosting I assume there is no other work-around that would leverage your app, post groovy?

If not, in a post groovy world and for those using contact or tilt sensors and running Alexa, couldn’t we create virtual (Edge driver) GDO’s in SmartThings connected to those contact sensors, and then use virtual switches to send open and close commands to Alexa? Since Alexa can connect with Simple Commands, I think that can serve to trigger the open and close commands to MyQ, meanwhile the virtual GDO updates status to Smarthings based on the contact sensors? Maybe I am missing something but that would seem to be a solution that doesn’t require self hosting and isn’t all that technical, for those of us less inclined. I guess it would rely on 4 cloud services operating, though in the current state I think your integration still requires 3 cloud services, assuming one is also using Alexa for voice access.

Thoughts? Thanks in advance!

How were you planning on doing this? I’m not sure why the server side needs to notice IP address changes of the client side (hub) though. The client would use UPnP/SSDP to find running servers on its local network, connecting to it. If you really need the server to know the client’s IP, you could get the local IP on the client and pass it over the tunnel, or the server could request the remote IP address of its connected TCP socket.

I’m looking forward to testing your new driver. I have a MyQ bridge arriving this week in fact.

1 Like

I’m only using SSDP during discovery. Once the device is created and IP is known, it makes normal http calls. Or at least, that’s my current implementation. This stuff is still kinda wide open in terms of making it do what you want.

Perhaps use a SSDP subscription on the client side, have the server send out its SSDP updates every 60 seconds. Have the client cache the last known IP address/port for any HTTP requests. This is similar how Control4 would find and track devices on the network.

I had considered something like this. Really not a bad idea as long as it’s not too chatty.

1 Like

Self-hosting is pretty much it, either via something on your LAN or something on a cloud service that operates as a new smartApp that hits the SmartThings API.

This seems technically possible. I’d say give it a shot.

Possibly of interest to this thread

1 Like

Would it be possible to make the self hosted part a little docker that could be dropped on RaspberryPi?

Yep, I’ll definitely have a docker image available - I plan to run it on my Unraid server.

1 Like

Hi just checking to see if you have cone up with a way to keep the myq garage door working with smartthings. Not sure if i missed it in the thread on