Goose66

This is non-sensical. You can "Run Then" or "Run Else" programs in a disabled folder, it will update the "Last Run Time," "Last Finish Time," and "Status" appropriately, but the program itself doesn't appear to run. What would be the point of that design?

Seems to me that if you have a leak, you are going to get drainage from your system out of the leak from static pressure in the pipes - even after shutoff - whether you have an expansion tank or not. The expansion tank just adds a couple of more gallons (if that). Do you really need another system to account for that?

A new version 3.1.12 is available. This version changes the way bright/dim works for both fans and lights to make them scene-compatible with Insteon SwitchLinc dimmers that brighten/dim over 32 steps. This has not been tested, however. This version also contains Alpha-level support for Sidekick Scene keypads on Bond Bridge Pro. If you have these devices, try them out and let me know how the functionality works.

I like the view…

Hey!

What node server?

@wafflesNot sure if this is one time or you want to enable or disable the batch based on some condition. If the latter, use a folder, then set your condition for the folder. If the folder condition is not true, then the programs are effectively disabled. For example, I (use to) have a folder for my irrigation programs in a folder that had the condition of date between May 1 and October 31. Similarly, I have my holiday light programs (indoor, outdoor, etc.) in a folder with a condition of a "Holiday" state variable being set.

I will take a look at your log file tonight. Here's another question: did you migrate these nodes from your ISY 994i to IoX on Polisy and then (separately?) migrate the PG3 node server from Polisy to Polisy Pro? There is data stored with each node object in PG3, and I wonder if that data is not getting migrated.

Another way we can debug is that if you send me the model number of your Minka fans and the Hunter fan, I may be able to set them up in my Bond app (even if they don't actually exist) and then debug interaction with the Bond app here.

Also note, that as previously stated, there is the whole issue of the Bond bridge and state tracking in play here, and what commands exist for the fan in the setup on the Bond bridge may affect how that plays out. For example, the "porch fan 1" and "fan bbq" have light toggle commands. The Bond bridge will tell the node server that these fans have ToggleLight capability as well as TurnOnLight and TurnOffLight capability, with the node server choosing to use the latter. The Bond bridge tracks the state of the light and interprets On and Off commands from the IoX/node server accordingly. But if you are also using your fan's remote, for example, to control the light, the state will get out of sync in the Bond bridge and then it will not work as expected. That's why I say user the Bond app and the reflected states there to debug the node server, not the fan itself. On the other hand the "guest room fan" only has a "light on" command. So I don't know what the Bond bridge is going to tell the node server about it. It may say it just has TurnOnLight capability, or it may indicate it has both TurnOnLight and TurnOffLight capability. Either way, the node server is going to assume it can turn on and turn off the light. If IoX/node server sends an Off command (DOF or DFOF), then who knows what the light will do? Is the Bond bridge smart enough to know how to turn off the light? There is no "light off" command shown in the UI of the app, so we don't know. These are the kinds of things that would (hopefully) show up in the log file taken during discovery with the debug logging level turned on.

Ok, if that ends up fixing things, then great. I would like to explore (at some point) the issue with the node server adding both up light and downlight nodes if the fan only has one of the lights in the Bond app, however. This particular NS is difficult because, while the API to the bridge is reliable and well defined, with the numbers and types of devices that the bridge supports (with all the varied features and commands), it is impossible to know how any one particular fan or blind is going to look or respond.

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.