Goose66

Just for clarity, do you have access to the devices in the Resideo app?

The problem is that installing the upgrade is not deleting old files that have been moved to another location. Accordingly, when it starts up, it is loading an older file instead of the new file in its new location. I have rolled back the Node Server to 3.0.19. If you upgraded, you are going to have to delete and reinstall. Sorry about that folks!

Sorry it has an install issue. But… but… football! I have asked Bob to roll back the release.

I have uploaded a new version of the MyQ Node Server (v3.1.20) to the Node Server Store. This version slightly changes the way initial connections are made on restart and adds Low Battery and No Comms states to garage door openers to support door position sensors (DPS). See release notes at https://github.com/Goose66/NSDocs/blob/main/myq-pg3.md for more info.

You’re technically not using your Amazon credentials. Your doing third-party oAuth through Amazon. Same is available through Apple and Google. The node server does not support third-party oAuth as it requires user interaction through a web browser or app. The node server requires a MyQ account.

I assume you used the free version on the RPi or did you code on PC/Mac then download to RPi?

ISY994 still supported. It’s the Polyglot running on DIY platforms that’s no longer supported, and precisely because of problems like yours. Polyglot and polyglot node servers were initially created by hobbyists in the UDI community. At some point in the PG2 to PG3 migration, UDI recognized the importance of Polyglot to the ecosystem and absorbed it as a core product (although the vast majority of node servers are still from community members like myself). Of course by adopting it as their own, they also took on support. And it’s very hard to support an ecosystem that has a critical piece being run on whatever hardware and OS a user can cook up. There were folks running Polyglot in Docker and various emulators on Macs and all kinds of things. Thus Polisy was born.

Wow! Is the code on GitHub?

Firstly, I am not supporting PG2 node servers any more. It's just too much to keep both PG2 and PG3 node servers working. PG2 has been deprecated by UDI, and you won't get any support for it from them either. But as to the error, it looks like the problem is a syntax error in the Python code - specifically on the first instance of an f-string. I am going to assume you are running an out-of-the-box version of Raspbian Stretch from 2017 with Python 3.5 that doesn't support f-strings. If you install Python 3.6 or better on your RPi, then it may run correctly. But if the MyQ API changes, you'll just be right back to non-functional, since only PG3 version will be updated moving forward.

That’s just a code error. Can’t have a set of dictionaries in Python. Was this node server perhaps converted from nodejs?

Are the Polisy and EnvisaLink on the same LAN? If so, then the router/firewall wouldn’t come into play. Also, if the node server couldn’t reach the EnvisLink you would get a timeout on the connect. What’s happening is the node server is connecting to the EnvisaLink and the EnvisaLink is immediately resetting the connection. I’ve only ever seen this when there is another connection to the EnvisaLink.

And you rebooted the EnvisaLink?

Yes, the browser connection is different (HTTP). The specific socket connection to port 4025 that Nodelink and the node server use is the one that allows only one connection.

From what I can see in the log, it is trying to connect to the Envisalink at 192.168.1.251. Not ever getting to login because the initial socket connection is being refused: evltpi_dsc:_get_next_cmd_seq: TCP Connection to EnvisaLink unexpectedly closed. Socket error: [Errno 54] Connection reset by peer The "connection reset by peer" error message has normally been the result of another connection to the Envisalink, e.g. another version of the node server, NodeLink, or some other controller connected to the Envisalink. If you know there is no longer another process running somewhere that is connecting to the Envisalink, then I would suggest using the web interface of the Envisalink (http://192.168.1.251) to go to "Network" settings then click "Reboot Envisalink."

I can take a look in a few days. In the meantime, make sure the PG2 node server is shut down. The EnvisaLink will only accept one socket connection.

The short answer to your question is yes, Polyglot on Polisy will work fine with your ISY-994i and give you integration with a lot of additional devices. When your are ready to migrate to IoP, it will be ready.

The short answer is that you are likely to see different solutions here depending on the node server. There is no "built-in" node server running/operating state (status) in the Node Server API, and the requirement for a "Controller" node representing the node server that was present in PG2 node servers was removed in PG3 (which is a good thing for reasons I would be glad to discuss 😆). One consequence of this is there is no standard way for PG3 node servers to report their state. Node servers do various things here depending on the design philosophy of the developer: some choose a state (driver) value for one of their nodes to (attempt to) reflect the running state of the node server; some send heartbeats (e.g., AWAKE commands) periodically form a node that allow the ISY to monitor the running state; some use a driver to effect heartbeat (e.g., alternating 1 and -1 in the ST driver of a "controller-type" node). Personally, my hope is that state tracking for node server running state (heartbeat or otherwise) is built into the API at some point - potentially when the intervening REST layer is removed and node servers start communicating with the ISY directly through MQTT (let's call it the "Polyglot" API).

@carealtor How are you with network resources? I know when I sold my house, I was able to port most of the function of my Autelis/Jandy node server to network resources. I left my ISY994i but didn't leave the RPi running PG2, so this allowed me to leave most of my kepad keys that had printed key labels functioning without having to explain all of the Polyglot stuff to the new owner.

I think Red is supposed to be for controllers and blue is supposed to be for responders, at least in scenes (source: ISY-994i Home Automation Cookbook). However, I've seen this question asked a lot over the last 10 years and have never come away with a clear understanding of the differentiation of the colors in the node hierarchy.

It was indeed a "quirk" in Polyglot. When you recreate nodes in Polyglot on restart, even if you initially set the UOMs for the drivers to their default values, Polyglot updates them to the UOMs stored in the database for the node (for nodes (thermostats) that were already created). I have uploaded yet a new version to implement a fix that changes the UOM back to the intended default after the update. Note that the UOM for CLIHCS will continue to show in the Polyglot Dashboard as 66 - no way to fix this without deleting and re-adding your thermostats. The new version is v3.0.11. Let me know if it is working.

LOL. That's definitely what it feels like sometimes. It's been a slow evolution of ISY Node Servers and Polyglot from end-user or third-party add-ons to an integral part of the UDI/ISY ecosystem, but it is evolving, and I think (hope) eIsy will see us even closer to a robust, fully-integrated platform.

You may need to flash SSD on your Polisy. You should put a ticket in with UDI support. But before you do that, make sure you are giving the “Upgrade Packages” ample time. My last one took nearly 20 minutes. Wait for the 5 beeps before rebooting.

Look at the log files for the individual node servers. Are there entries at the bottom with timestamps corresponding to the last time your tried to start them? If not, look at the PG3 Log (via the "Log" menu item at the top right of the dashboard). Are their items in the PG3 Log with timestamps corresponding to the last time you tried to reboot or start a Node Server? If so, DM the log or a log package to @bpwwer.

There are several interwoven points here, so I will enumerate for the sake of clarity: 1. You point out a valid bug in the node server that also appears in the PG3 version: the hostname (often IP address) and token are stored in the node for the bridge, tied to a specific node address. Once the hostname and token for the bridge are stored for a particular node address, they can't be changed. If the actual hostname/IP address or token for a bridge changes, connectivity to that bridge will be lost. Adding the IP address and token in the configuration parameters won't help, because these are only used in device discovery to find Bond Bridges that won't or can't respond to the discovery broadcast messages. 2. Moreover, if you perform the Discovery process again (with or without configuration parameters), while it should find the bridge at its new hostname, it won't add the bridge node because a node already exists with the bridge address (the bridge address is derived from the bridge ID in a deterministic manner). I will add code to allow it to update the hostname and token in these situations in a future version (but read on). 3. A couple of notes (to be added to the Release Notes): a) you should add an IP address reservation in your router or DHCP server for your Bond Bridge (just as I recommend for all of your home network and automation devices) to prevent this from happening; and b) if this does happen, delete the bridge node from the Polyglot Dashboard (which should remove it from the ISY as well), restart the node server, and then perform the Discovery process again. This should be a low impact change since the bridge node and device nodes should all be added back with the same addresses, thus your programs and scenes should all work the same (but read on). 4. However, if the firmware of your Bond Bridge has been updated from the 2.X branch to the newer 3.X branch, it is possible that the bridge ID and device IDs have changed due to changes in the firmware, and thus re-performing Discovery will add them back with different node addresses. Accordingly, in this case, you will have to adjust all scenes and programs to utilize the new device nodes and bridge nodes (but read on). 5. If the firmware of your bridge is updated or has been updated from the 2.X branch to the 3.X branch, the PG2 version of the node server will stop working because a change that Olibra made in the API in the 3.X firmware branch. This has been fixed in the PG3 version, but I doubt I will ever add this fix (or any future fixes such as #2 above) in the PG2 version since Polyglot v2 has been deprecated by UDI. In summation, if you haven't updated the firmware in your Bond Bridge, then deleting the bridge node from the Polyglot v2 Dashboard, restarting the node server, and re-performing Discovery should work. If you have upgraded the firmware to the 3.X version, you will need to upgrade to Polyglot v3 to continue to use the node server. As far as not being able to delete the node server from Polyglot, this is likely a Polyglot v2 problem and not a problem with the specific node server, but you probably won't be able to get any support for this issue since Polyglot v2 has been deprecated.

This may be a quirk in Polyglot. Let me look into it deeper.