Goose66

I have another minor fix to put into this node server (clearing of notifications on startup), and I am going to rework the node server so that the listener thread doesn't shutdown on these errors since they are technically not fatal (the interface goes to sleep for a few seconds and then retries the connection to PG3). It may miss several state updates, which I know is not ideal for an alarm panel node server, but at least you won't have to restart. I should get to it this weekend.

In addition to your UDI equipment, what kind of pool controller do you have?

@rob7419 This error is coming from the Polyglot interface (udi_interface) and not the actual node server code. Can you let me know what version of PG3 and what version of ISY you are running? @bpwwer Are we experiencing this MQTT error in other node servers?

In the MyQ Service node. EDIT: That was the solution. It is in the Configuration Help as well as the Installation Instructions/Release Notes ("More Info" from Node Server Store listing). This was done to allow users to be able to rediscover devices in order to discover newly added devices, restore previously deleted devices, restore original device names, etc.

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.