Goose66

Did you "click the 'Discover Devices' button for the [MyQ Service] node to discover MyQ bridges (hubs) and devices linked to your account?"

Pleas put the Logging Mode for the node server to Debug, restart the node server, and DM me a log package (not just the PG3 log, but I specifically need the node server log file.)

@bpwwer can help with the expired license issue. As far as the “bad credentials” message, when you say “I didn’t change anything from before” does that mean you used the same credentials as before or that you did not add the credentials again after the reinstall.

I had a room in my house (theater room in the basement) that had four different leaks over the years. The first two were broken water supply lines that flooded from the outside into the house and were huge problems - new padding/carpet, water mitigation, mildew treatment, new wall for one of them, etc. The second one was a faulty pressure relief valve on hot water that leaked for a month or more before we noticed. That one was also a lot of cleanup and the one that prompted me to get sensors with a supply line valve actuator. All these were probably 10s if not 100s of gallons of water over time. The fourth was a three and one-half gallon drinking water container that got shoved to the back of the pantry and sprung a small leak. Leak down through the tile floor and subfloor and through basement ceiling. We noticed it right away and captured maybe a gallon in a bucket. The remainder was sucked up with wet dry vac and dried with fans - no removal of carpet or pad. The ceiling took a little Kilz and some paint and everything was good. Moisture probes showed 0 for floor, ceiling and carpet after several days of drying. sensors and a shutoff valve are definitely worth it and one of my home automation must-haves. It’s just the extra expense of the system drainage components that I think is probably overkill for the additional couple of gallons it may prevent. Don’t get me wrong go, though. I certainly appreciate the design and engineering (and fun) that went into going that extra mile. 😁

I think you are way overestimating how much damage a couple of gallons of water can do, especially when we are talking about clean potable water.

The "connection reset by peer" error in the log is what normally occurs when there is another process connected to the EnvisaLink. You mentioned that you can access the EnvisaLink's web-based configuration page? Try using that to reboot the EnvisaLink then restart the node server.

I haven’t upgraded to 5.5.5 yet.

There are changes in Polyglot on eISY in regard to permissions. This could have something to do with it. Also make sure your Polisy is completely shutdown because only one connection to the EnvisaLink is allowed. Also, you can’t run NodeLink and the node server at the same time either.

A new version 3.1.13 has been uploaded. This version mostly comprises changes for on-going testing of Sidekick Scene keypads on Bond Bridge Pro. Also, the node profiles have been updated to fix the editor ranges to work better with UD Mobile.

Probably best to DM the author of the SolarEdge node server directly. Developing a node server without the hardware in your own environment to test with is very difficult.

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.

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.