Option to use HTTP post to trigger door open/close.

[betatester88]

Sorry if this is not the right place to request new features.
Since myQ api is currently broken and most likely it will remain broken, I am wondering is it possible to add a feature to trigger “open” and “close” using http post on Tesla-YouQ like so http://<arduino_IP>/open and http://<arduino_IP>/close” ?

First, I am not a developer, nor good at coding anything. Everything I have ever coded was via googling.

Several years ago, before I had myQ. I have an Arduino ESP8266 wired to a garage door remote and leveraging MQTT from adafruit.com. Using IFTTT on my phone, I can trigger/simulate the remote button press.

If Tesla-youQ can trigger Open/Close using http post then I can then program the ESP8266 to listen for “open/close”

Using IFTTT as a hub connecting to Arduino and Smartthings (or any door sensor that works with IFTTT), I can have smartthings door status update the GarageDoorStatus feed at adafruit.com. My logic will be something like this.

From Tesla-YouQ:
http://<arduino_IP>/open

On the Arduino: Only simulate button press if door status is closed.
Subscribe to Adafruit GarageDoorStatus feed. (open=1 and close =0)

If (GarageDoorStatus =0)
{
Trigger door remote button press on Arduino
}
Else do nothing

From Tesla-YouQ:
http://<arduino_IP>/close

On the Arduino: Only simulate button press if door status is opened.
If (GarageDoorStatus =1)
{
Trigger door remote button press on Arduino
}
Else do nothing

Thank you in advance.

[brchri]

Hi! I don't know if you saw but I recently updated the readme with a Notice of Deprecation for this app because of the MyQ API changes, and in the notice I mention that I'm working on a fork of this app to support other smart Garage Door Openers (GDO's) instead. In that effort, I've rewritten a significant portion of the codebase, which includes abstracting control of the garage doors away from the rest of the logic of YouQ (or whatever the new app will be called; I'm open to suggestions 😄 ).

Because of this abstraction, it would be incredibly simple to implement HTTP endpoint calls to operate an arduino as you've suggested. If you want to handle the required door state for operation in the arduino and abstract that logic away from YouQ, that's fine, or YouQ can also handle that logic if you have an endpoint for it to receive status updates for the garage door state.

As I mention in the notice of deprecation, the initial version of the fork will support ratgdo and other generic mqtt smart garage door openers, so if your arduino can watch for mqtt events (and optionally publish door status to a topic), then YouQ will support that method out of the box when it releases. Otherwise I can add in the http endpoint as you've described and you can use that.

[betatester88]

Wow, you really think of everything :). I can’t ask for anything better than this. Thank you!

[brchri]

If you're feeling adventurous, I have a prototype up that you can see if you can get working. Just run the docker image brchri/tesla-youq:add-ratgdo-deprecate-myq, and use the reference config here. Note that I've also modified the structure of the global settings, so you'll want to pay attention to those changes here.

If you give it a try, let me know how it goes. I don't have an actual device to test this with so I've just been working with mock endpoints. 😅

[betatester88]

wow, never thought you were this fast. When I say several years ago, I meant ~10 years ago :). I don't have my source code (all local on my old laptop), also I am thinking to rebuild the device with MOSFET to replace the relay. I am not an electrical engineer, this should be simple enough, just need the get the parts. I also need to 'relearn' to program the device. Anyway, to show my appreciation for your hard work. I have couple of ESP8266 around. If you can send me your mailing address, I can send you couple of these :).

One other question. In your config, you have "http_method: post", does it take "get" as well? Was thinking of an option to put everything in the URL.

BTW, I came across https://github.com/Kaldek/rat-ratgdo, not sure if you are aware of this project.

[brchri]

Heh, appreciate it, but nah I'm not great with reading microcontroller schematics. But yes, you can use any (valid) http_method in the config. You would just omit the body parameter for a GET method, for example.

[betatester88]

Thanks, like I have said you really thought of everything. :)

[betatester88]

Hi Brchri,
Is add-ratgdo-deprecate-myq also ready for test with MQTT? I got my opener working but only with MQTT. I am using Adafruit.com as the broker.
The feeds are as follows:
userid/feeds/garagecmd # Command for open or close
userid/feeds/garagedoorstatus # door status opened or closed
Here is my config.yml file

[betatester88]

fyi, I tested and it worked. Thanks for your hard work. My Arduino also included logic to only open/close if the door current status is the opposite. Now, I got double "safety switch" :) - even better.

Here is my config
config.yml.txt
I only use it to open.

@ 10:23:00 , I opened the garage door using garage door opener (other method than tesla-youQ)
@10:23:08 While drive out of the geofence, I got this msg: [WARNING] Action and state mismatch: garage state is not valid for executing requested action; current state: opened; requested action: open
I think it got confused, the car wasn't from outside of the geofence into the geofence. I believe this should not be triggered.

@12:00:00, the garage door "open" action was triggered by tesla-youQ

Here is the log
11/06/2023 23:42:14 [INFO ] Config loaded successfully
11/06/2023 23:42:14 [INFO ] mqtt door opener connected to MQTT broker
11/06/2023 23:42:14 [INFO ] Connected to Teslamate MQTT broker
11/06/2023 23:42:14 [INFO ] Subscribing to MQTT topics for car 1
11/06/2023 23:42:14 [INFO ] Topics subscribed, listening for events...
11/06/2023 23:42:21 [INFO ] Received interrupt signal, shutting down...
11/06/2023 23:42:22 [INFO ] Config loaded successfully
11/06/2023 23:42:22 [INFO ] mqtt door opener connected to MQTT broker
11/06/2023 23:42:22 [INFO ] Connected to Teslamate MQTT broker
11/06/2023 23:42:22 [INFO ] Subscribing to MQTT topics for car 1
11/06/2023 23:42:22 [INFO ] Topics subscribed, listening for events...
11/07/2023 10:23:08 [INFO ] Attempting to open garage door for car 1 at lat 35.463090, long -67.566614
11/07/2023 10:23:08 [WARNING] Action and state mismatch: garage state is not valid for executing requested action; current state: opened; requested action: open
11/07/2023 12:00:00 [INFO ] Attempting to open garage door for car 1 at lat 35.463192, long -67.566568
11/07/2023 12:00:00 [INFO ] setting garage door open
11/07/2023 12:00:08 [INFO ] Garage door state has been set successfully: opened

[betatester88]

Disclaimer: I am not a developer but enjoy solving problems and learning along the way.

I should have done that previously using MQTT explorer for tests. With the latest built, I can't duplicate the issue with MQTT explorer. I'll test it again with the car in a bit and give you updates.
I want to pick on your brain if you don't mind. How do you get the CURRENT status of the door via MQTT? In my Arduino, I have logic to "sync" the status with the switch (status=closed, switch = close or status=opened, switch = open). What I can't seem to do is get the status at first boot of the device. Subscribe to the topic only receive update when there is a change. So, at each boot of the device, there is a chance of mismatch of the switch and door status. It eventually sync up if the door was open/close once after boot by any method.

[brchri]

Hey glad to hear that your MQTT tests have been successful.

For the initial status of the door via MQTT, subscribing to the door status topic should immediate return a "publish event" (as far as the client is concerned) if the last message published to the topic had the retain flag set. retain in MQTT means that any new clients that connect will receive the last message published whenever they subscribe. If this is not set, then new clients would either receive the last published message that was set, or nothing at all.

Example:
Let's say I have topic door/status, and I publish the following events to it:

1. open
2. closed
3. open (with retain flag set)
4. closed
5. open
6. closed

If I have a new client connect after step 2, then it will receive no status on topic subscription. In this case, I just default to closed, as an assumption that doors are usually closed, especially if a user is messing around with restarting their services. If a client were to connect and subscribe to the topic after step 6, then the client would receive open as the status, even though the last status published was actually closed at step 6, because step 3 had the retain flag set, but none of the following steps did. So if you always publish with the retain flag set for status, then your clients should always get the correct status when they subscribe.

I wouldn't recommend setting retain flags for commands, as you don't want old lingering commands in there when a GDO subscribes after a restart, for example.

I hope that makes sense.

[betatester88]

ah, thanks for the explanation. Unfortunately, retain flag is not an option for me. Besides, I am using smarthings door sensor in combination with IFTTT for door status feed (smartthings --> IFTTT-->adafruit.com). I don't think that is an option for the flag even if the broker allows this.

Here is from adafruit.com
Ref: https://io.adafruit.com/api/docs/mqtt.html#adafruit-io-39-s-limitations

"Retained values:
MQTT is a tremendously useful protocol for building small connected devices and is relatively simple to understand and implement (if implementing networking protocols is your thing). Unfortunately, a few features of the Adafruit IO platform make it difficult for us to support the entire MQTT 3.1+ protocol specification in our broker. Specifically, one particular feature, the publish retain flag."

The GOOD NEWS is I just tested with my car, and everything worked as expected! Thank you again for your hard work.

[brchri]

That's great! Sorry to hear about the MQTT limitations. You could "cache" the status it to a local MQTT broker if you wanted, e.g. have a small service subscribed to the topics in adafruit and when a message is published, re-publish that message to (for example) the MQTT broker with the retain flag set, and then get your statuses from there on your devices. A bit clunky but can help mitigate the issue. 🤷

[betatester88]

That was a good idea with another broker as a workaround. You have pointed me to the right direction on your last post. Now I am aware of "retain". From the Adafruit page I posted earlier, there is a workaround for that. I just modified my code to perform a publish "get" to get the latest status. Adjust the 'opener' according to the door status. I am all good now. Thanks again.

Ref: https://io.adafruit.com/api/docs/mqtt.html#adafruit-io-39-s-limitations
"For any given Adafruit IO MQTT feed or group, subscribe to the appropriate topic using the feed or group key, then add /get to the topic you subscribed to and publish anything to that new topic (our Arduino library uses the null character: \0). IO will immediately publish, just for that client, the most recent value received on the feed."