Jump to content

myQ Integration


midrar

Recommended Posts

I can’t speak specifically to the eISY, but performance of the PG3 node server on the eISY should be substantially similar to the performance on other UDI platforms.

As far a delays, the only imterfsce available requires periodic polling of a cloud-based website for status, and especially in polling during periods of inactivity, a state change in a door opener may not be reflected in the corresponding ISY node for several minutes.

Sending open and close commands is relatively quick, however - less than a second.

Edited by Goose66
Link to comment
10 hours ago, Goose66 said:

As far a delays, the only imterfsce available requires periodic polling of a cloud-based website for status, and especially in polling during periods of inactivity, a state change in a door opener may not be reflected in the corresponding ISY node for several minutes.

Sending open and close commands is relatively quick, however - less than a second.

Reinforcing what @Goose66 said above. I recently added MyQ and due to the long polling periods, I found I could not use the "state" of the door as a trigger in a program w/o strange / unwanted results. I am sure one could program around it with delays and multiple disabled programs etc, but luckily I have wired sensors to my elk for state of the door. Otherwise, the open / close commands work well.  

I used to use an elk output to "short across" an extra garage door transmitter that I soldered wires to. But it wasn't 100% reliable for some reason: ISY to Elk NS to output to transmitter to garage door opener....

So I have now switched my programming so that if the MyQ NS is online, then use it, otherwise, use the Elk output as I havent physically uninstalled it. This way if the Internet is down or the NS goes down, I have a "local" solution that will work.

Generally I wold recommend the MyQ NS though. Havent had any issues with it. 

Link to comment

Assuming the MyQ service (and the node server) is up, it's fairly reliable for opening and closing the door and for (eventually) reporting the door transition from closed to open and from open to closed. It's never going to be good for triggering things like lights or alarms when a door is opened, however, unless Chamberlain comes back with a much better API.

I think we really need to get rid of the "instant" state update to "Opening" or "Closing" when you open or close a door and instead just rely on the state report from polling. For example, this occurs frequently when you, e.g., open the door using a command from the ISY to the node server: the state of the door goes to "Opening" then back to "Closed" then (sometimes) back to "Opening" and eventually to "Opened." This is due to the latency in the door reporting to MyQ service as well as the node server polling from MyQ service. And closing the door is even worse due to the 6 second or so (depending on unit) alarming period before the door even transitions state. Of course, this kind of wonkiness happens for me in the MyQ app too sometimes.

In the past I've tried to think of some fancy ways of anticipating the state over time to smooth this out, but honestly I can think of more use cases that could depend on actual status reports from MyQ then could benefit from guesses of what the status should be from the Node Server. Perhaps if we remove the "instant" change to "Opening" and "Closing," we can instead wait a few seconds and then force a status update, in conjunction to switching the polling mode to active (i.e., polling every like 20 seconds), which we are already doing.

Edited by Goose66
  • Like 1
Link to comment
Guest
This topic is now closed to further replies.

×
×
  • Create New...