Goose66

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.

I am not going to take the time to go back and research it all (because it's all moot now) but that is not how I remember it. A couple of points as I remember it: 1. The API for the hub required an application key. The application key was obtained by an email (or web form) submission to Smarthome/Insteon support. I tried many, many times over several years to obtain an application key with no response. By the time I received an application key, the Hub II was out and the REST (HTTP) interface was online only and limited in functionality. And yes, I understand you could find application keys in GitHub repositories and they were passed around for some time, but if certainly wasn't official and was subject to change. 2. The networked PLM were exactly that - access to PLMs. You didn't get the benefit of the configuration and management of the hub. You had to do everything yourself. Similarly, there was a local API to the Hub that gave you access to the PLM internally. You could monitor the Insteon traffic in the home and send Insteon commands over the PLM. However, again, you were decoupled from the setup, configuration, and management of the devices in the hub itself. Given these points, I think my original submission stands - Insteon has never made a public, published, and local API to the hub available.

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 am coming specifically from the position of an API for the hub. They have allowed other software to access through their PLMs, but that means the software vendor (and any node server) has to be handle EVERYTHING, including adding and removing devices, device configuration, scene setup, etc. If they wanted to sell a great HA solution (IMHO) , they would provide a hub that provides management and configuration of devices as well as access to those devices through a variety of mechanisms, including open protocols like Matter as well as a published (local) API. They have never done that. If they also have a great software product, like Director (never seen it), then maybe folks will use that too. But let it stand on its own two feet. Don't force users who want their hardware to also use their (potentially inferior) software.

So from the CEO, they are emphasizing and supporting their product “Director” but state “i3 is not proprietary it is absolutely open-ended as Insteon has always been.” I read that to mean same support for third-party software vendors as has always been available to Insteon and all development work will focus on Director. Thus no API will be forthcoming.

I am assuming 3rd parties that they deem worthy and that pay required “licensing” fees. But will they add a local API to their hub for open access to all software products? No. Because it limits future potential revenue streams — specifically subscription services to their control website.

I understand why they do it (it’s been discussed so many times on this forum over the last 12 years I believe everyone understands why they do it). The point still stands that it just winds up being another crappy closed HA ecosystem that most people can’t use or afford (whether it “just works” or not). Only interoperability will bring HA to the masses, and if hardware manufacturers would make a quality and affordable product that fully supports open protocols like Thread and Matter, all the software vendors would support it and they could carve out a stable market position. I am thinking like Cree, Leviton, LG, EPISTAR, etc.

Seems like adding Matter support to the Insteon hub will be a no-brainer programming/technology-wise if they decide to do it. The question is will they make the smart decision to do it. Like so many HA companies, Insteon needs to decide if they want to be a hardware company or a software company and then stay in their lane. When these companies decide they want to own both sides, they just wind up being crap.

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.