Goose66

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.

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.

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

If you can, please add some screenshots of the Admin Console interface for building the program, including the pull-down with the available values.

Are you sure you have the new version (v3.0.10). It still seems to be reporting CLIHCS with the wrong UOM (66 instead of 25).

@bigDvette I may have found the issue, and I have uploaded a new version (v3.0.10) to the Polyglot Node Server Store. Unfortunately, cannot test it since I no longer have the thermostats. Let me know if this resolves the problem.

Can you attach some screenshots of what you are seeing in the programming interface?

The short answer is “not at this time.” The MyQ node sever utilizes a hack of the API the MyQ app utilizes. This is not public, undocumented, and changes every year or so, requiring updates to node server code, thus the annual “subscription” for the node server instead of one time $10.95 like my other node servers. The subscription for integration of MyQ with other home automation platforms is new. If this ends up being a public, documented API that we can use for integration with the node server, that would be a better solution, IMO, and we may want to convert the node server over to it. I would probably just change the pricing of the node server to perpetual, in that case. I also note that the subscription for third-party integrations appears to be $12 a year ($1 a month), not $10 a month. Looks like the more expensive subscription is for their cameras - mainly long term storage of video.

Excellent. @rwsani99 You can reinstall the node server to get the latest version and clear the error using the method above, or just let the current version run until Bob has v3.1.15 of PG3 ready for release. Hope that helps.

In the meantime would it help if I went out and just uploaded a dummy upgrade with a new version (e.g., v3.0.11) to the Node server Store?