Even if you give full path of the file or a ./ if it is in the current directory ?
I will try again in a bit. Thank you
I am tired but finally got it working. The reason my myq.txt was not working is due to the fact I based it on the config.json file - just assumed. When I happened to discover the proper method about 20 minutes ago from one of @rumrunner424 posts did it finally start working. thanks!
We are super close now. Got all the code cleaned up tonight, new binaries generated (including successfully running the arm64 on my pi), new container images tested on the beta tag, and pull request is staged.
All that’s left is to find some time to update the docs and instructions. Looking forward to seeing how this helps simplify things.
Awesome! Is this the version that doesn’t require a separate hardware server on your home network? Or has that not panned out?
You’re always going to need a component running on a machine external to the hub but in the same network, as the ST hub can’t communicate with anything outside of the local network.
The new version is out! If you had the previous version here, you will unfortunately need to start over, killing the old server and deleting the devices in SmartThings. I think these changes make it worth the effort, though! Follow these steps if you had the old driver:
- Click the link to my driver channel again
- If you’ve already enrolled your hub in the channel, click the “available drivers” link
- Uninstall the MyQDoor driver
- Install the MyQ Controller driver.
- I suggest reading through the revamped instructions in the github repo (see original post).
Summary of changes:
- Upon scanning for new devices, you will now see a MyQ-Controller device get created. The mobile app scan only creates the controller device, which is basically a virtual controller. No connection is made to the bridge server until you add credentials.
- Username/password are now configured in the controller device. The config file for the bridge server has been removed.
- New feature: IP/Port can be manually set in the controller device
- New feature: Device include list can be set in the controller device
- Added support for voice-controlled devices via switch capability behind the scenes
- Added MyQ lamp module support
- Added arm64 (Raspberry Pi) executable
- Devices now have a status capability to better show issues
- Modified SSDP flow to simplify auto IP/Port discovery, especially when running the server in Docker
These are major changes, but the end result should help with a lot of the issues people have been having. Let me know how things go.
Shout out to @TAustin for sharing his work on lantrigger - I learned a ton about the Edge driver flow from it and applied it to this iteration.
I had to install the MyQ Connector driver. The previous driver was called MyQ Door.
Thanks again for your tireless and well-documented work.
@brbeaird, two problems with the new version:
-
Broadcast is not working for me. I have to set an IP address and port in the MyQ-Controller for the hub and the bridge to connect. Maybe broadcast is not being passed by a device on my network.
-
When I “Scan for nearby devices”, SmartThings device discovery is not finding the garage door that the bridge has successfully discovered on the myQ API. CLI shows that it seems to invoke discovery, and then immediately exit discovery:
2022-11-02T07:35:49.713664605+00:00 TRACE MyQ Connector Received event with handler discovery
2022-11-02T07:35:49.849928855+00:00 DEBUG MyQ Connector Device discovery invoked
2022-11-02T07:35:49.870234397+00:00 INFO MyQ Connector Found controller.MyQControllerhttp://192.168.4.200:8090
2022-11-02T07:35:49.880504105+00:00 DEBUG MyQ Connector Exiting discovery
2022-11-02T07:35:49.898884605+00:00 DEBUG MyQ Connector discovery device thread event handled
I have deleted the MyQ-Controller device and recreated it. Same results.
The connection between the bridge and MyQ-Controller device seems to set up OK despite the broadcast failure.
2022-11-02T07:24:20.151721488+00:00 DEBUG MyQ Connector MyQ-Controller device thread event handled
2022-11-02T07:24:20.578897697+00:00 TRACE MyQ Connector Received event with handler device_lifecycle
2022-11-02T07:24:20.584053655+00:00 INFO MyQ Connector <Device: 281dab52-3dd2-4daa-a06d-e73436fa0e53 (MyQ-Controller)> received lifecycle event: infoChanged
2022-11-02T07:24:20.589284655+00:00 TRACE MyQ Connector Found DeviceLifecycleDispatcher handler in myQConnectorDriver
2022-11-02T07:24:20.592150072+00:00 DEBUG MyQ Connector Info changed handler invoked
2022-11-02T07:24:26.162876991+00:00 ERROR MyQ Connector Non-code response calling: http://192.168.4.200:8090/devices -
2022-11-02T07:24:26.242526533+00:00 ERROR MyQ Connector Refresh Failed.
2022-11-02T07:24:26.283742325+00:00 DEBUG MyQ Connector MyQ-Controller device thread event handled
2022-11-02T07:24:26.329152700+00:00 DEBUG MyQ Connector MyQ-Controller device thread event handled
2022-11-02T07:24:31.706614827+00:00 INFO MyQ Connector <Device: 281dab52-3dd2-4daa-a06d-e73436fa0e53 (MyQ-Controller)> emitting event: {"attribute_id":"statusText","capability_id":"towertalent27877.myqstatus","component_id":"main","state":{"value":"Connected"}}
Broadcast does work for me if I set the container to the host network and remove the port mappings.
However, still no go on the garage door device discovery. I even tried adding Garage Door to the Device Include List in case that was some kind of constraint. No difference.
Just updated everything by removing the old drivers and devices and started fresh. Working great, but still no device showing in Google Home for Assistant voice commands. (and I nuked my virtual switch so I’ll have to redo this part also…). Thanks, as always, for continuing to improve this project for everyone!
I assume you mean this one, MyQ: Connector?
As everything is working for me right now, I might wait a day or two for the dust to settle here.
Thanks for clarifying - I was not totally sure about that, but it makes sense.
It is important to note that the auto-discovery piece of this is now different than the SmartThings discovery flow - it does not fire when tapping the “scan for nearby devices” anymore. Now, all that does it trigger the MyQ controller device be created.
Once you put in a username and password on the controller device, that will trigger the hub to broadcast out to try and discover the server. I can see in your logs that the refresh failed. What do your server logs look like? If the server successfully received a valid username/password from the hub, you should see where it connects to MyQ and if you manually hit that /devices link, you should get a list of your MyQ devices.
Google is weird. I wonder if it requires some other capability to make it show up. I’m not sure if the old SmartApp still works with Google at this point.
Yep - I will clarify my post, thanks.
I installed the new server and driver. It appears the connection is working, but I am not able to get my garage door device to be created (I see the MyQConnector and it says it is connected). In the SmartThings logs I only see reference to the GarageDoor that is shared with me, not my Garage Door.
I’ve tried deleting and re-adding the connector, but I keep getting into the same loop. Here is a snip of the SmartThings CLI that shows the update that keeps repeating.
Is there anything else I can try or is there a better way to “reset” the MyQConnector?
Thank you!
If you update any of the settings on the controller (ip, port, user/password) it should reset the connection and try again. Did you manually enter that IP and port? What do the logs say on your myq server?
The initial installation was my first time using docker. Thanks to everyone who helped me set it up. I have a couple of questions with these changes.
Will the previous MyQ Door installation continue to work or do I have to use the new installation?
On a Rapsberry PI 4b do I still use docker as before or do I use the RPI executable and what is the benefit to one or the other?
Is this the Raspberry Pi executable? myQBridgeServer-linux-arm64
I have tried entering the IP and port. It looks like it refreshed, but I get back to the same spot.
Here is the output from the server.
Ok, I may have a bug in the manual IP/Port flow. Admittedly, I have tested that far less than just leaving those blank and auto-discovering. Let me check on that.
You should ask how to run it as an executable on RPI so I don’t have to
Thank you very much! I have tried deleting the MyQConnector and letting auto discovery take over. Each path I try leads me to the same spot.
Let me know if there is any logs you need or any tests you would like me to try! Thank you so much!