Goose66

Assuming the MyQ service (and the node server) is up, it's fairly reliable for opening and closing the door and for (eventually) reporting the door transition from closed to open and from open to closed. It's never going to be good for triggering things like lights or alarms when a door is opened, however, unless Chamberlain comes back with a much better API. I think we really need to get rid of the "instant" state update to "Opening" or "Closing" when you open or close a door and instead just rely on the state report from polling. For example, this occurs frequently when you, e.g., open the door using a command from the ISY to the node server: the state of the door goes to "Opening" then back to "Closed" then (sometimes) back to "Opening" and eventually to "Opened." This is due to the latency in the door reporting to MyQ service as well as the node server polling from MyQ service. And closing the door is even worse due to the 6 second or so (depending on unit) alarming period before the door even transitions state. Of course, this kind of wonkiness happens for me in the MyQ app too sometimes. In the past I've tried to think of some fancy ways of anticipating the state over time to smooth this out, but honestly I can think of more use cases that could depend on actual status reports from MyQ then could benefit from guesses of what the status should be from the Node Server. Perhaps if we remove the "instant" change to "Opening" and "Closing," we can instead wait a few seconds and then force a status update, in conjunction to switching the polling mode to active (i.e., polling every like 20 seconds), which we are already doing.

I can’t speak specifically to the eISY, but performance of the PG3 node server on the eISY should be substantially similar to the performance on other UDI platforms. As far a delays, the only imterfsce available requires periodic polling of a cloud-based website for status, and especially in polling during periods of inactivity, a state change in a door opener may not be reflected in the corresponding ISY node for several minutes. Sending open and close commands is relatively quick, however - less than a second.

Please DM me with the log package.

@TJF1960 If it's not too late I would still like to get a log package from you, including the node server log (which may be gone) and the PG3 log so that I can understand what went wrong. Version 3.1.21 was released to fix the same, specific symptoms you described which were happening in 3.1.20.

I haven’t seen it in the (hacked) API, nor does it appear to be something available in the MyQ app (which is what the API is built to support). So I would say it’s probably not accessible. Similar to the light itself, control of which is an often reported feature but it’s just not supported by the API.

First you need parentheses around the first AND clause. Second, as described in the release notes for the node server, the statuses get wonky when a command is sent from the ISY due to the slow polling period. So, for example, if I send a close command, the status goes to “Closing,” but there is at least a 5 second alarming period and a 4 to 5 second closing period, in which a poll may return an “Open” status before the status finally goes to closed. So probably best to test for “status = open” instead of “not closed.” Third, your going to need a local variable to track the notifications, otherwise it’s just going to send them repeatedly every poll beyond 6 minutes. Fourth the ‘Garage Doors Are Open Too Long’ program will never run, because the program restarts during the wait everytime the duration value changes, i.e., every poll.

I have uploaded a new version of the MyQ Node Server (v3.1.21) to the Node Server Store. This version fixes an issue with v3.1.20 where files from the older version were being left in the install directory and causing the new node server not to run. See release notes at https://github.com/Goose66/NSDocs/blob/main/myq-pg3.md for more info.

Just released a version 3.1.21 that includes a script to remove the old files on install. Should fix all problems with upgrades. Again, sorry for the problem.

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.

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.