Goose66

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.

We haven't heard back from Chamberlain on the use of the public (or semi-private) API, but it may be a cost associated with using it. So Chamberlain may be shutting out unauthorized users in order to drive HA integrators to use the (perhaps pay-to-play) public API.

Not a lot to go on from "can't get a single node to work" so here's my generic suggestions: 1. Pick one of the node servers and concentrate on it. For example, let's look at the Hue PG3 Node Server. 2. Read fully the "More Information" in the Node Server Store, the Configuration information on the Configuration page in the Dashboard, and the release notes in the forum for the Hue PG3 Node Server. There may be a lot of information there about what your setup needs to look like as well as step-by-step instructions to install and configure the node server. 3. Once you've tried all that, post a new topic in the Hue PG3 Node Server forum with a detailed message of the symptoms you are getting that make it "not work."

There’s been chatter in the pymyq repository of new errors but no solutions. It may be additional changes made to Chamberlain’s handling of the user-agent in order to continue to try to block unauthorized use of the mobile app API. Hopefully will see some solutions soon.

Could commissioning (at least for wifi or Zigbee connectivity) be done, even temporarily, through existing (perhaps hardware manufacturer-supplied) mobile apps, with IoX taking control once connected to the network? In other words, does Matter require IoX to control the devices end-to-end or can IoX just be a (one of potentially a plurality of) controller?

My diagnosis: You are running a new version of the launcher with your ISY running an old version of IoX. The current launcher involves two forms of discovery and access: the older broadcast method and newer mDNS. So when the ISY responds to broadcast discovery, the launcher expects there to be two paths to the ISY. But since your ISY isn't (can't) run Zeroconf for mDNS, the second path doesn't exist.

There was one request for Sonoff MINIR2. It looks similar in functionality and size to the Shelly 1, except much easier to wire (meaning less Wago connectors and more space in the J-box). Only 10 amp limit though, so if you are putting it into a standard 15A circuit in the U.S., it can't carry the max amperage load of the entire circuit (although especially with LED lighting, I doubt you would ever have more than 10A on you circuit). Also looks like it supports flashing of Tasmota OTA, instead of having to hook it up to your PC through a USB-to-TTL adapter like with the Shelly 1. As far as support in the node server, while it has a different template from the Shelly 1, I think you could get basic "Switch" module functionality (i.e., ON and OFF) functionality for it with the existing code. So I will add it to the list of supported devices in the next version and someone can test it for me.

Did you shut it down for a couple of hours and then retry?