Goose66

Before you do that, try setting your logging level to debug, re-perform the discovery process (without deleting or changing anything), and send me the complete log package. I can scan through it and see if I find any errors. Just for clarity, do the MinkAire fans have separate Up and Down lights? I don't see any controls for them in your screen prints.

@Chris McKean In general, the best way to debug the Bond NS is to divide things up between the node server to the bridge, and the bridge to the device. The Bond app should show you what is going on at the bridge. So a couple of things here: 1. As to "Four of the MinkaAire fans have three nodes on each fan (fan, up light, down light). One MinkaAire fan has two nodes (fan, light). All MinkaAire fans are the same model...," how are these shown in the Bond app? Do they all show identically with up light and down light controls, or does the one that is different also show differently in the Bond app? If it does, then the problem is with when you added the fan to the Bond bridge, and not with the node server discovery. 2. "All work properly (fans and lights) from the Bond phone app." Like every button press (in a slow, methodical fashion) works 100% of the time, or when I press buttons in the Bond app - sometimes multiple, rapid presses - the lights eventually come on or go off. Remember that the node server sends a single on or single off. It generally has no way of knowing if the bridge was actually able to transmit successfully to the device (fan) because the bridge->device communication is one way. Also, many fans offer only a light toggle and dim and bright buttons that are designed to support a person standing in a room looking at the fan/light to evaluate its current state. In these cases, the Bond bridge (not the node server) will attempt to track the state and offers up "On" and "Off" commands to the node server to use to change it. This is called "state tracking," and it gets messed up occasionally. So "Off" and "On" commands from the node server may not work as expected if the state tracking in the Bond bridge is messed up. 3. "The fans that have three nodes default to up light (off) and down light (on)..." The node server defaults the state of all drivers to "Unknown" (or 0 if "Unknown" is not a valid state for the UOM). The node server then reads the initial state of the devices from the bridge just after discovery . You should be able to ascertain the initial state of the lights and fan speed from the Bond app before discovery. If the initial "default" states in the nodes match that of the Bond app after discovery, then the node server is working. If they don't match the states of the devices themselves, then that's a problem with state tracking in the Bond app and not the node server. There's lots of information on state tracking in the Bond app and resetting it on the interwebs, but if that turns out to be (at least a part of) your problem, I and others can help here as well. 4. "Toggling either the up light or down light doesn't turn on the light." Does it modify the light state in the Bond app? Again, to debug the node server, check what is happening to the state reflected in the Bond app. If the device itself is not reflecting this state it could be a problem with the bridge->device communication (or tracked states, as noted above). 5. In regard to the log, it appears to be truncated. I don't see attempts to turn on or off lights in the node server log, so it's hard to help there. Also, please put the logging mode to "Debug" for future log submissions. I do see the periodic connection failures others mentioned. This could be the Wi-fi connection to the bridge or the Wi-fi connection to your Polisy Pro.

Is the node server running? I was under the impression that we've decided that server.json files were no longer necessary (or even deprecated) and I have been removing them from my node servers. Despite this fact, several subsequent versions of the PG3 have all continued to log a missing server.json file as an ERROR. But the node server runs just fine. The WARNING regarding "MQTT Send waiting on connection" now appears on the first MQTT message sent from the node server to PG3 in all (at least my) node servers and isn't a problem. I think something was changed to make the connection to MQTT wait for the first send (probably for simplifying reconnects).

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.

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.