[ST Edge] SmartThings MyQ Edge (Obsolete)

How do you change the container to bridge mode?

I have the server up and running in docker and I can see it discovers all 3 garage doors. However, when I try to scan for devices in SmartThings App, it doesn’t find any. When I use smartthings cli to see the logs for the driver, this is what i get (looks like it is finding the MyQ server on the IP address of my gateway eero router instead of the IP address of the iMac where the server is actually running:

2022-10-03T00:37:41.010491310+00:00 TRACE MyQ Door Setup driver MyQDoor with Capability handlers:
CapabilityCommandDispatcher: MyQDoor
default_handlers:
doorControl:
close
open
refresh:
refresh
child_dispatchers:

2022-10-03T00:37:41.018548102+00:00 TRACE MyQ Door Server.new_with
2022-10-03T00:37:41.021368602+00:00 TRACE MyQ Door Server:post
2022-10-03T00:37:41.026942560+00:00 TRACE MyQ Door Server:post
2022-10-03T00:37:41.029812643+00:00 TRACE MyQ Door Server:listen
2022-10-03T00:37:41.057797602+00:00 DEBUG MyQ Door driver device thread event handled
2022-10-03T00:37:41.060895227+00:00 TRACE MyQ Door Received event with handler _resync
2022-10-03T00:37:41.064134352+00:00 TRACE MyQ Door Received event with handler environment_info
2022-10-03T00:37:41.068244143+00:00 TRACE MyQ Door Received event with handler environment_info
2022-10-03T00:37:41.071158727+00:00 DEBUG MyQ Door Z-Wave hub node ID environment changed.
2022-10-03T00:37:41.075479310+00:00 TRACE MyQ Door Received event with handler discovery
2022-10-03T00:37:41.092805768+00:00 INFO MyQ Door ===== SCANNING NETWORK…
2022-10-03T00:37:41.105524727+00:00 INFO MyQ Door ===== MyQ Server FOUND IN NETWORK AT: http://10.0.4.1:1900/igd.xml
2022-10-03T00:37:41.108330768+00:00 INFO MyQ Door ===== FETCHING DEVICE METADATA… http://10.0.4.1:1900/igd.xml
2022-10-03T00:37:41.198449477+00:00 INFO MyQ Door ===== res <?xml version="1.0"?>


1
0

http://10.0.4.1:1900/

urn:schemas-upnp-org:device:InternetGatewayDevice:1
eero
eero inc.
https://eero.com
eero
0.0.1

uuid:fcdb9233-a63f-41da-b42c-7cfeb99c8adf


urn:schemas-upnp-org:service:Layer3Forwarding:1
urn:upnp-org:serviceId:L3Forwarding1
/l3f
/l3f/events
/l3f.xml




urn:schemas-upnp-org:device:WANDevice:1
eero
eero inc.
https://eero.com
eero
0.0.1

uuid:fcdb9233-a63f-41da-b42c-7cfeb99c8adf


urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1
urn:upnp-org:serviceId:WANCommonInterfaceConfig
/ifc
/ifc/events
/ifc.xml




urn:schemas-upnp-org:device:WANConnectionDevice:1
eero
eero inc.
https://eero.com
eero
0.0.1

uuid:fcdb9233-a63f-41da-b42c-7cfeb99c8adf


urn:schemas-upnp-org:service:WANIPConnection:1
urn:upnp-org:serviceId:WANIPConnection
/ipc
/ipc/events
/ipc.xml






https://eero.com


2022-10-03T00:37:41.202090602+00:00 ERROR MyQ Door discovery thread encountered error: [string “discovery.lua”]:35: attempt to index a nil value (local ‘raw_data’)

Google Home Workaround

I believe that Google Home was able to see the myQ Lite Garage Doors is because Google Home was seeing the legacy custom DTH myQ Lite Doors as a Switch, and not as actual Garage Doors. Even if you were using the old myQ integration with Google Assistant to control your Garage Doors, Google Home would not allow you to “open” the garage doors with a verbal command.

My workaround for this apparent intentional Google Home security policy (which restricts you from bringing over SmartThings Garage Doors) was to implement edge driver Virtual Switches (with a Garage Door icon) instead. Google Home is perfectly happy bringing over a SmartThings switches. You cannot use Virtual Garage Doors instead of the Virtual Switches, as Google Home will see them as Garage Doors and will restrict them also.

Utilizing my Tilt Sensors that I was using with the old DTH myQ Lite app, the Edge Driver Virtual Switches, and the actual myQ Garage Doors using the proxy server… I created the following SmartThings Routines (a set for each of my doors) to keep everything in sync. No matter how you initiate the command (Google Home Garage Door tile, Google Home verbal Command, Smartthings tile or Routine, or the actual Garage Door Remote or Button in your garage, everything remains in sync. Even if you were to initiate an open or close command from Google Home or SmartThings, and somebody was to stop the command by hitting the actual Garage Door button and stop the doors mid-way, everything remains in sync. Of course, you will have to create Google Home Routines if you want to use verbal commands with the word “open”. Since Google is seeing the doors as a ON/OFF switch, I guess it doesn’t quite understand how to open a switch.

Hope this helps

1 Like

Thanks for the logs - this confirms what I suspected. I need to update the driver to filter out noise from other SSDP devices. Whatever is on your network as 10.0.4.1 is interfering with the communication.

Great find, I suspected it was something like this. I will see about exposing switching capability to these door devices.

1 Like

When it initially failed, the container console showed that the server found the door and the gateway. After I fixed the network connection, there was an additional line where the IP of the opener was recognized.

My NAS has it as an option in the Docker GUI. It may be as simple as adding --network bridge to the run command?

The idea to try that came from here; @jc214809 may be able to explain how to do it in a command line environment.

Yeah for any eagle eyes out there… yes I noticed I was using the wrong door sensor for the Charger Door close routine, and have fixed it. :blush:

I am getting

Fatal error in , line 0

unreachable code

Not sure why. Any Ideas?
Running on a Pi via Docker

1 Like

I’m in the middle of pushing some updates. Haven’t had a chance to test on pi yet.

I had this and have been fighting it all day. I finally got the docker container to run. From my limited Docker knowledge and todays web education. I think it has something to do with the seccomp profile.

I was able to get past this error buy adding the following option to my run file.

–security-opt seccomp=unconfined

Don’t know why? and its probably not a smart thing to do? I’m just hacking along trying to get things to work.

I got the docker container to work but still not seeing it find any devices in smartthings app. Sooooo still hacking along.

No luck for me. :frowning:

@brbeaird nice work on this new driver
I installed it on my Ubuntu server (under Proxmox), using docker and it is running fine, but Smartthings doesn’t find anything and so driver is added.
Reading some of the comments, I think the problem is the port number. Does it need to be port 8125??
If so, then every time I restart the docker container, a new port is created for the HTTP listening (I can connect from a broswer to get details at the port published in the log files). Should I set the container to port 8125?

Sorry, in my experimenting throughout the day. This is the command that gets the container created and running for me.

docker run --security-opt seccomp=unconfined -d --name=‘smartthings-myq-edge’ --net=‘bridge’ -e ‘MYQ_EMAIL’=‘email address’ -e ‘MYQ_PASSWORD’=‘password’ ‘brbeaird/smartthings-myq-edge’

I have used this command twice now to get it running it reports in the logs it connects to MyQ and reports the devices. BUT still no luck in getting the devices discovered in smartthings. I am thinking its something to do with my network settings. I have tried pinging outside of the docker container and it see’s the rest of the world.

I’m now reinstalling again and gonna try to ping out to my garage door controller on my LAN and see what I learn.

Ok that fixed it I put the switch at the end, but when I moved it to the start of the command it worked. But like you I am not getting it to show in ST

So I went to ip:8125 on the raspberry Pi I am running the docker on and I get “Cannot GET /” Not sure what the means

So we appear to be at the same place.

My latest command line change was to change the --network from bridge to host.

Hoping that would allow the container to have access to the hose network connections.

It did change my result when I went to the web address to the same you got.

Still hacking away at it!

I pushed a few updates today, mostly on the server side. You should see new docker images and executables.

  • The server now spins up on a random port each time. This should avoid any port conflicts.
  • Added more logs to the server and timestamps to go with them
  • Pushed one small update to the Edge driver to better filter out non-MyQ bridge traffic during discovery.
  • Pushed out Linux-arm64 executable (untested)

I am still making a few tweaks to the driver to make sure it filters out unwanted ssdp traffic in periods other than discovery - not quite happy enough with it yet to fully push out.

I also have not yet made it to testing on the pi but hopefully should get time to focus on that soon. In theory, the Linux-arm64 executable should work for some, but I may need to generate a 32-bit one as well.

With the latest server code and images pushed, the port should be randomly generated each time.

I would suggest trying one of these:

  1. Make sure UDP port 1900 is open on the container. SSDP is a little tricky, but I think that’s what is tripping some people up
  2. Change the container to run in host mode
1 Like

I will look into that. Thank you for the reply.

Thank you for your help. I am 1 step closer.

I kept trying different run commands this is the one I used last
docker run --security-opt seccomp=unconfined -d --network host --name=‘smartthings-myq-edge’ -e ‘MYQ_EMAIL’=‘email’ -e ‘MYQ_PASSWORD’=‘password’ ‘brbeaird/smartthings-myq-edge’.

This enabled me to finally get a reply in the web browser when I went to the
“Pi IP address”:8125/details
It reports all the devices and the base IP address and port of the Pi.
unfortunately still no devices in smartthings.

Just to clarify I am supposed to select the MyQ Door driver not the MyQ DoorBeta?

I updated my docker container with the latest image and still Smartthings doesn’t find it to create the devices. Read up on ssdp and wrote a small client script in nodejs to test the server and it finds it perfectly on my network. I’m guessing something on the smartthings side is the issue at this point.