Goose66

The order page says 2-3 weeks.

The ratgdo does connect to Wifi, but it is actually the ratgdo that connects to the Polisy's or eISY's MQTT broker. So as long as there is TCP/IP connectivity between the ratgdo and the Polisy, it would work (even if not on the same LAN segment). You configure the IP address or .local name of the Polisy/eISY into the ratgdo. The node server simply connects to the MQTT broker on localhost. The node server would probably have the ability to connect to some external MQTT broker, however, for advanced configurations, just like my Tasmota node server does.

I don't see motion as a state (unless you mean door motion). I see availability state: Online and Offline (MQTT LWT), door state: Open, Close, Opening, Closing; obstruction state: Obstructed and Clear; light state: On and Off; lockout state: Locked and Unlocked; door command: Open and Close; light command: On and Off; and lockout command: Lock and Unlock. Another thing to note here is, while Chamberlain may not like having this third-party device being able to control the door locally, it is doing so using PWM over the control line and emulating one of their wall control keypads, so there's no way they can push out new firmware to block access.

if I can make a ratgdo node server that basic mirrors the current MyQ node server profile (interface), it should be easy enough just to plug-in to your current programs and scenes and such.

Local. The ratgdo uses (among other options) MQTT. There is an MQTT broker on the Polisy/eISY that you would connect it to, and the node server would use the same MQTT broker to control and receive status updates from the ratgdo. Updates would be near realtime (unlike the polling of MyQ) and could be used to control lights and such, and probably more appropriately reflect "opening" and "closing" statuses and report obstructions. But yes, on backorder. Just ordered one and my friend did too (we are together on vacation at the moment).

The ratgdo looks the most promising. I would love to get one and write a node server for it, but I have Genie GDOs with the MyQ Universal Controller and Door Sensors, so I don't really have a testbed for it. I have a friend with MyQ GDOs that's buying one, but he's ditching UD to go with HomeAssistant. Maybe I can convince him to keep his Polisy running long enough to test the ratgdo node server.

This effort to block unauthorized access is only a year or less after they rolled out the public API to their "trusted partners." I suspect that none of the technical reasons the CTO would give you for blocking unauthorized access would be valid, and that the real reason is they want to make 3rd-party access exclusive to their partners. This leads me to believe that being a "trusted partner" comes with a financial cost. Now, I can't see any way that this could represent a significant amount of revenue to Chamberlain. It just doesn't make sense that HA integrators would pay enough money to Chamberlain for access that it would even pay for the efforts to block unauthorized access. If anything, you would think the result would be that Chamberlain GDOs (their primary and significant source of revenue) would just be less attractive to some purchasers, even if only to the "small percentage of users" that's mentioned in the Chamberlain letter. In my 20+ years of experience with helping companies license their IP and create new revenue streams, the ones that have tried to monetize their non-strategic IP portfolios are rarely successful. The likes of IBM, AT&T, Microsoft, and Intellectual Ventures aside, for most companies it really comes down to staying in your lane and just staying out front of your competitors in your primary market(s). So my questions for the CTO (which I am sure he wouldn't answer) are 1) what are the real reasons and concerns for blocking third-party access, and will he give us the opportunity to address and mitigate them, and 2) why not respond to Michel's requests to be a "trusted partner," even if just to say "f' off." Seems to me all they have to lose is an increase in product sales, even if it is marginally small and insignificant. EDIT: Also, a lot if not most people end up moving and inheriting whatever GDOs the builder originally installed in their home. If Chamberlain wants to open up a new revenue stream, I think a $75 gateway that allows "trusted partner" HA integrators to access their GDOs through the public API would be a much better revenue generator than a pay-to-play partner program, and would be much more inline with their primary market as a hardware OEM then that of some kind of SaS provider.

Actually, you said the setpoints update temporarily in the Admin Console, but then go back on the next poll, so I assume you won't find the "Error message returned from control API" messages in your logs. Also, I notice that the setpoints in the second query after the POST in your curl test don't match the setpoint values actually set in the POST. Are you sure you are POSTing to the same thermostat that you are querying and not the ColorTouch thermostat (stupid question but I had to ask)? Is it possible that the Explorer has screen lock set requiring a PIN to change the settings?

Addressing the two problems separately: 1. Schedule mode reporting: the API documentation says the schedpart will be 255 when schedule mode is inactive, and that's what the ColorTouch reports. The ColorTouch was the thermostat I had at hand when coding this node server, so I just used schedpart to determine the schedule setting - kind of a shortcut. Obviously, the Explorer does not report the same way, so I need to go back and look at the schedule state and the schedpart to report the schedule status values to IoX - should be an easy fix. 2. Temp setpoints: The API documentation sort of alludes to a requirement that you have to send all four settings in the settings POST (like you do in your curl test), but the ColorTouch didn't enforce any such requirement. Accordingly, the node server only sends the settings that are changing (after testing modes and setpoint deltas). That may be why the Explorer is not accepting the setpoint changes from the node server. The REST API will report success but put an error message in the return data if the POST command is not successful. Look in the node server log and do a search for "Error message returned from control API" (or some part thereof) and see if you see any messages. Or better yet, send a copy of the logs and I can take a look. If that turns out to be the problem, that would be an easy fix too.

Same with Honeywell Home - they change the active room based on occupancy (motion) sensors. But none of the node servers that I can see allow the ISY to set the active room programatically.

He wants to be able to programmatically set the remote sensor that is controlling the thermostat. E.g., if motion in basement office, set basement office as controlling sensor, otherwise set main floor as controlling sensor.

Looking at the Honeywell Home (Resideo) API, it does appear, however, that the API would support changing of rooms. The plug-in could perhaps be modified to allow changing of the priority room (along with changing the priority type to "Pick a room"). However, I don't believe the original develop is around, and the current version that Bob put out was for conversion to PG3 only.

Also the Honewell Home plug-in (formerly node server) allows you to see the "Priority Type": "Pick a Room," "Follow Me," or "Whole House," but IoX can't change it or select a particular remote sensor.

Currently goes through the Cloud, and in a very circuitous route at that.

Afraid not. Neither setting nor determining the current controlling sensor is supported by the API. I don't believe you can in the Honeywell Thermostats, either. You may want to ask @Jimbo.Automates about Ecobee.

There’s been some changes to another project (not pymyq) that seem to be working, although the developer has shutdown posts from users to the issue in the GitHub repository. I am going to implement his changes this weekend and see if I can restart mine. Longer term, I am implementing some local solution as well (maybe ratgdo device), and if a node server is required I will make it free to all MyQ owners (or everyone if it’s easier). But ultimately I don’t’ want to give up on Chamberlain and MyQ, because there is a whole batch of Polisy/eISY users out there that are DIY enough to own one but not DIY enough to be wiring some 3rd party device into their garage door opener. We don’t want to forget about those folks!

Also, there should be no problem with restoring the nodes from a backup even if PG2 and the node servers are not running.

AFAIK no version of IoX has ever spontaneously deleted nodes, including just because the node server fails to respond. It just leaves the nodes with unknown state (status) values. The way the ISY Node Server REST API works, the ISY has no way of knowing whether the node server is just not currently responding or PG2 (or the RPi it's running on) has died. There are only four ways I know of to delete node server nodes: 1) delete them from the Admin Console (and, because PG2/RPi is dead, they won't get added back), 2) delete them from the PG2 Dashboard while ISY is running and available to PG2, 3) the node server code deletes them while the node server is running, or 4) delete the node server from the Admin Console (Node Servers-->Configure--><Node Server> and then "Delete" button on configuration page) and then all of the nodes for the node server are also deleted.

I am assuming the reason mine is still running is that I haven't rebooted in a while.

Just FYI, I've been waiting for two things to happen before a dive into this: 1) for the folks discussing the issue over at the pymyq Github repository to find/settle on a solution, and 2) for my MyQ node server to stop working. To date, neither of those have happened yet. But I will keep looking at it. EDIT: I should say I'm waiting on my production installation of the MyQ node server to stop working.

Also, depending on what you are looking for, there is a Tasmota node server available as well. Are your Sonoff devices using Tasmota firmware?

You don’t have to change the configuration of the generic MQTT broker, and you probably shouldn’t because there are other node servers using it as configured. What errors are logged in the node server log (not the pg3 log) when the node server is started?

It appears to only work with one model Genie (H8000D), which is not what I have. I have CM7600ICs which have a keypad controller sort of like MyQ that allow you to control the light and door separately and and lock the door. So I assume the device would have to be programmed to talk the Genie protocol, just like it's programmed to talk the MyQ Security+ 2.0 protocol. Maybe somebody has got it working with a Genie like mine.

I like the ratgdo device. It has everything I am currently looking for in HA integration devices: Wi-Fi, MQTT, and defined local API. I would be all over this IF I STILL HAD Chamberlain door openers. Unfortunately, my new townhome (not so "new" now, I guess) had Genie openers, and I bought the Chamberlain Smart Garage Control because I had the MyQ Node Server and IoX programs and Alexa routines that went with it. If there were a Genie version of the ratgdo, that would be cool. $30 per door would be a little tough to swallow after already paying $75 for my Chamberlain Smart Garage Control and a second door position sensor, but ultimately local control is the goal. A node server for the ratgdo would be a no brainer - you could use Network Resources or the free MQTT node server to get basic functionality, or we could copy the Tasmota node server with the MyQ profile to get a real garage door opener (possibly with independent light control) node server. I still have some hopes we can get in with the Chamberlain public API - it's better than nothing - but ultimately I think local is always the better choice when you have the option. I mean, that's why we all use the Polisy/eISY to begin with, right?

Just to be clear, I don't think it's necessarily "evil." Since they are, primarily, a hardware manufacturer, I'm sure they ultimately want to sell as much hardware as possible. Rather than trying to force people into their ecosystem and dominate the HA market (as many other OEMs seem to want to do), however, I think there need to put guard rails (and potentially fees) on access to their API may be more of a way to reduce their own fixed costs.