Goose66

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?

What error are you getting? And, after the failure and reinstall did you give it the 75 minutes (or 2 hours) before you restarted the node server.

Ok, I think the 429 - Too many requests errors is an older (like several weeks) problem that still needs to be looked at, but it should only affect restarts and usually will resolve itself if you shutdown and don't retry for at least 75 minutes. Hopefully the newer 401 error is fixed (for now). The current code is a mish-mash of fixes and patches from changes to a couple of libraries on GitHub that have occurred over the last couple of years. I think there needs to be a complete restructuring of the oAuth authentication process, but outside of making it easier to maintain, I am not exactly sure HOW it needs to be restructured. The entire API is made to support the app. The oAuth authentication and token retrieval process works for a short access window, i.e. do authentication when the user starts the app, get the token, then use the token while the user is using the app. The token doesn't need refreshing for over an hour, so in the majority of cases, the user will have stopped actively using the app by then. Moreover, the app makes requests in spurts, where the node server makes requests on a steady basis every 20 seconds or 60 seconds (depending on active vs. inactive polling mode), hour-by-hour, day-in and day-out. Another difference - when a connection is severed (usually MyQ servers stop responding temporarily), the node server tries to reconnect every 60 seconds by going back to square one and go through the oAuth authentication process to retrieve a new token. After four or five retries, the oAuth servers will return a retry delay required to avoid subsequent 429 errors, but it is like the aforementioned 75 minutes. So that may work for the app, but for the node server that's just not going to work. Then there is the whole thing with userAgent, which is the change that appears to be specifically targeting the unauthorized users, and if Chamberlain is going to continue that game it's going to get harder and harder to keep it working. I think it needs one of two things: either learn how to track the app communication with the API in order to keep up with all the changes myself (instead of waiting on others to work through the issues), or change the node server to work with one of the two libraries out there and put the burden on maintaining operability on someone else. Neither is a great solution: the former requires a level of hacking that's above my paygrade, and the latter means we have no control over the timeline. For example, much of the learning that went into the current v3.2.23 fix came from the pymyq library from arraylabs. But the fixes for the last few months are in pull requests by individual users - the latest version of the library in pypi goes back to last December. In addition, both of the libraries that appear to be maintained are async, and the node server environment for PG3/PG3x is decidedly not async. All that to say it's complicated, I appreciate your patience, and I hope you understand why I made this one a subscription instead of a perpetual license. The ultimate solution would be for Chamberlain to publish a simple, public, REST-based API with a specified maximum polling frequency, and I think that would satisfy most users (i.e., you won't be able to turn on lights when a garage door is activated, but you can monitor door status and close them for security reasons over reasonable periods). After 5 or 6 years of working on this, though, I don't see that happening soon.

What is everyone's shortpoll and longpoll set to?

I have uploaded a new version of the MyQ Node Server (v3.2.23) to the Node Server Store. This version implements fixes to oAuth to try and keep up with the changes coming from Chamberlain. I would like to say this version should work for some time, however, I feel like we are chasing our tails right now with this and the node server is getting quite fragile. When it has a valid token, it works great. But every time you restart the node server (or potentially every 60 minutes when in refreshes the token) there is a chance that the authentication will fail. There are also a couple of bugs in this version that occur in rare network conditions that will take some time to run down, but I wanted to get a semi-working version out to you guys as fast as possible.

Update to the latest version (v3.2.23) and see if it works for you.

I flashed my Shelly 1 to Tasmota, and it was pretty easy. Followed the instructions here: https://tasmota.github.io/docs/devices/Shelly-1/. I needed a USB-to-TTL device that also supplied 3.3v, so I got this one: https://www.amazon.com/gp/product/B07WX2DSVB. Worked great! Anyway, the Tasmota node server is published and supports the Shelly 1 device. Hope to add additional Tasmota support soon.

The initial version of the node server (v3.0.4) supports the following devices: Martin Jerry (MJ) MJ-S01 Switch (Switch) MJ Plug V by MJ (Plug-in Module) MJ US-SD-TC01 (Dimmer) MJ US-FC-01 (Fan Controller) MJ US-SS01 Switch (Switch) MJ US-SS02 Switch (Humidity Switch) Shelly 1 (Switch) Device support is determined by the module name the device reports in the Tasmota discovery payload. You will see in the installation instructions and release notes that the configuration includes, in some cases, changing the module name in the template in order for the node server to distinguish particular device types during discovery. This is necessary because, while Tasmota abstracts out much of the device particulars, there are still some things that manufacturers like Martin Jerry will implement that make their device operate in a unique fashion. All that said, adding support for additional Tasmota devices, whether pre-flashed or flashed by the owner, may be trivial given the type of device it is (e.g., Switch, Plug-in Module, Dimmer, Fan Controller, etc.). If I can be provided remote access to the built-in web user interface of the device to peruse around in, I can probably include initial support for it in a new version of the node server without having to have one here locally to test with. So let me know what devices people would like to see added here and I will see what I can do.

I have published a new node server for PG3 and PG3x that allows IoX to access and control Martin Jerry switches and modules pre-flashed with Tasmota as well as other Tasmota devices, such as the Shelly 1 module. Detailed installation instructions, release notes, and version history can be found here: https://github.com/Goose66/NSDocs/blob/main/tasmota-pg3.md. The initial version is v3.0.4. Currently supported devices are: Martin Jerry (MJ) MJ-S01 Switch (Switch) MJ Plug V by MJ (Plug-in Module) MJ US-SD-TC01 (Dimmer) MJ US-FC-01 (Fan Controller) MJ US-SS01 Switch (Switch) MJ US-SS02 Switch (Humidity Switch) Shelly 1 (Switch)

Looks like someone created a PR at arraylabs/pyMyQ that is working for folks, so hopefully I can get it implemented quickly. Of course, the day job.......

You’ll notice that was a month ago. That whole userAgent thing prompted the latest version of MyQ as discussed in the other posts for the past few weeks in this subforum. This 401 error is new - maybe less than3 or 4 days old. But as I said only seems to affect people who restart.

Just so everyone knows, I believe this and most of the previous issues the past month or so have been done by Chamberlain to specifically thwart non-authorized access to their cloud service. Just so you all know what we're dealing with.

I am seeing this from users of the the arraylabs library as well (the library used by HomeAssistant integration). No solution yet from the developer of arraylabs. My node server in my production environment is running fine, but I haven't restarted it in the last several days (or weeks). I can bring production down tonight and then start it up in the development environment and play with the userAgent header and retry timing to see if I can get it working.

Everybody (including non Polyglot users) are dealing with this issue, but it usually only happens on reconnection (e.g., restart of the node server). Last three or four posts in this MyQ sub-forum all deal with this issue and it's evolution over the last month or so, so I won't repeat all that here. Suffice to say if you are running the latest version of MyQ (the one released to deal with this very issue), then shutdown the node server, wait 30 minutes or so, and start it back.

Oh, I hear you on the "if it ain't broke" thing. But seeing that it is a forum of geeks, if you throw out some speculation on what's happening at a technical level on something, you're bound to get a response or two! 😉

The 429 error is starting to crop up in other circles. Evidently there is a header included in these that specify how long you need to wait before retrying and the numbers are like 30 minutes or more, so I may need to rework the retry logic to find and start using this number on the retry. Note again this seems to be somewhat limited to when the node server is restarted and it has to acquire a whole new oAuth token for access.

BTW, I followed the chain starting here: You may need one or two more reboots than what's specified in the Wiki before everything is done.

That is the latest (and likely last) version of PG3. You should upgrade to PG3x. My upgrade went nearly flawlessly. Had to delete and reinstall one of six node servers.

Why would it be "my router" that is "allowing both the IP and friendly URL to reply?" I don't think my router plays any role in mDNS. I would think the two entries would be result of some sort of configuration issue on the Polisy (in my case) that causes it to respond twice to the same mDNS broadcast - probably a misconfiguration in the local network interfaces. On second thought, the two entries are more likely the result of being in transition from the old discovery methodology to the new mDNS discovery metholodgy.