Goose66

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.......

I have uploaded a first version of a Tasmota node server that supports the range of Martin Jerry products (as well as the Shelly 1). I will post the details when the forum is created.

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.

Nevermind, just had to delete it and reinstall it.

No messages in /var/log/messages. This is what I get when I try to start it: [admin@polisy /var/log]$ sudo service 000db953da90_4 onestart Starting NS000db953da90_4. su: unknown login: 000db953da90_4 /usr/local/etc/rc.d/000db953da90_4: WARNING: failed to start NS000db953da90_4

The pool controllers have proprietary network busses (usually RS-485 based) that they use to connect remote controllers like a wall mounted controller. The Autelis device is a third party product that connects to that bus and then provides a Ethernet network-based access to the pool controller, either web (REST) or lower level TCP/IP protocols. The Autelis device is discontinued, and most pool controllers today either come with an Ethernet or wifi connection option or offer one for an additional cost. Unfortunately tapping into the protocol for these first-party network interfaces is difficult, because the API is unpublished and they want you to use their proprietary apps and websites. The Autelis device was made for DIY home automation users (as well as being significantly less expensive). It’s a shame they went out of business.

I would need Internet access to someone’s Autelis device, and some beer money. (Ok, I’m not fooling anybody - it’s money to buy more HA devices 😁).

FYI, a lot of people around the World, evidently, are noticing that removing special characters from your MyQ password can help reduce the errors folks are getting when their app token expires and they have to re-login to the MyQ service, e.g., restarting the node server.

Np. I recognize that there are inconsistencies in the way all these node servers work - even among the ones I have written. A lot of this comes from legacy releases from Polyglot v2 (or even Polyglot v1). The MyQ node server was first released in 2018. I, for one, have expected for some time now that Polyglot would get subsumed by IoX (i.e., direct MQTT to IoX without intervening REST layer or PG3 database) and the Dashboard functionality brought into Admin Console, and that would be the opportunity to true up interface design paradigms, e.g., configuration parameters, device discovery, node management, heartbeat, status monitoring, notifications, and such. I think it’s still coming - just taking a lot longer than I expected.

Initial question: Are you using the "Discover Devices" button in the MyQ Service node?

Here's what the two instances I mentioned above look like: It gets an initial error in oAuth, e.g. a 401 error (not uncommon). It retries every minute (longPoll interval) for 6 or 7 minutes, then the server starts responding with the 429 - Too many requests error. So I think I need a longer retry on failure than the longPoll interval, or maybe after some number of failure retries, I crank down the frequency of retries. I'll put a TODO in the code for the next version.

Excellent. I will try to keep an eye on it. I may need to back off on the frequency it tries to refresh the token on initial failure. It may just be a simple longPoll change, or it may need its own period setting.

I checked my log files under PG3x since my migration last week. I got the same 429 - Too many requests error back on 9/26 on every longpoll oAuth token refresh for approx. 3 hours around 1:00am and again on 9/29 for a similar timeframe. Otherwise the MyQ node server has run fine since the migration. At this point, it looks like it's a transient error having something to do with the partner Chamberlain is using for oAuth authentication. I don't see anything about it in the Issues for the pymyq library (from which the node server was patterned). If a bunch of people start getting it all the time, I will look into it further.