Goose66

The DSC Node Server does not use any cloud resources, and does not need the Portal to be active. I don't know about the Hue node server for controlling the lights.

Good to hear (that you found your problem - not that your PLM is dying )

I do see some a couple of "Turn On" (DON) commands for the light at 07:50:23 and again at 07:50:26, followed by "Turn On" (DON) and then "Turn Off" commands for the fan at 07:51:08 and 07:51:12, respectively. While these were 30 minutes or so before the log file was put into debug mode, I don't see any errors or warnings or anything to suggest these commands didn't make it to the Bond bridge. Have you check the status of these devices in the Bond Home app to see if the status (as far as the bridge is concerned) is being changed by the ISY Scene commands?

@hart2hart Looking at the node server log file debug.log in the second DM you sent, I don't see any errors or warnings, but I also don't see any commands to control the ceiling fans or lights - just status updates on the shortPoll interval at 08:23:14 and 08:23:44. Can you provide a better understanding on what the symptoms are here? E.g., what action are you performing and what expected response are you not getting? Also, when checking the actual results, please use the status of the device as reported in the Bond Home app as the resulting status, and not the physical status of the fan or light itself, in that the node server communicates with the Bond Bridge (as the app does), but communications and failures between the bridge and the physical device are outside the scope of the node server.

The missing server.json error is expected (server.json files are deprecated). Future versions of PG3 should remove that error. can you send a log package - preferably one that contains attempted control actions for the nodes?

+1 for "it depends." I use these "backstop" programs for "All Lights" buttons, and it depends on what the most likely use case for the "All Lights" button will be. For example, in our old house, in the Master Bedroom (before our full-on Alexa integration) the most likely thing we wanted from the "All Lights" button (scene controller) was to turn all the lights OFF. So the "backstop" program ran any time the status of a Master Bedroom light changed and would make sure the "All Lights" button was ON so long as ANY of the Master Bedroom lights were on. That way, the button was setup to perform an "All Lights" OFF if any of the individual lights or any combination of lights were ON. In contrast, the All Lights button for my backyard was handled differently. Here, some of the lights were part of the evening and nightime lighting schemes, so there were usually some of the lights on at night. The most used use case for the All Lights button for our backyard lights, however, was to turn all the lights ON, including the floods, when the dog went outside (yes I know most dogs don't need it, but she was old). So the backstop program for the backyard All Lights button only turned on the button if EVERY backyard light was on. That way the button was most often setup to turn all of the backyard lights ON if pressed. Side Note: the problem here, of course, was that using the button to turn all of the backyard lights OFF when the dog came back in didn't return them to the evening or nightime state, but that was not really a problem and it would get all cleaned up on the next scheduled state change. Another side note: one may think that the inconsistency was a problem, but this setup had a high WAF even without her understanding the subtleties of the implementation because the result was that the scene button was most often in the state that one would want it to be for the primary use case.

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.

Now admittedly it's been a LONG TIME since I have looked at the Insteon protocol. I had a pretty thorough understanding of it when making my forays into the ISY 99i back in 2008. There was a "Status Update" command as well, but it wasn't really used for anything, IIRC. Maybe later versions of Insteon devices use this, but it requires specific acknowledgment by device profile in the ISY. I would think you would still see the "Status Update" command in the PLM logs, however. I guess I need to buy one of these.

Well there's the salient fact, right? I mean "responds just as you would hope" and "not updating "Status" when manipulated at the device" are oxymoronic, IMO. It clearly shows that "nothing changes about how they work" is not a true statement. For example, your SwitchLinc may control the load on your i3 Dimmer when in a scene, but if the i3 Dimmer can't control the load on SwitchLinc in that scene then everything is not working as expected or hoped. This seems like a significant departure from conventional Insteon functionality.

I would have thought this would be handled like the Motion Sensor IIs. Even though UDI never received the full specs and the ins and outs on how to configure over extended Insteon protocol, and thus their "full support" was late in coming (if it ever did), their functionality as basic Insteon devices worked immediately. Concepts like sending/receiving On (DON), Off (DOF), Fast On (DFON), Fast Off (DFOF), Brighten one step (over 32) (BRT), Dim one step (DIM) commands and reflecting "state" (ST) are tightly entrenched in the Insteon protocol and should work by default out of the box for any Insteon device, "supported" or not.

But if you can drop the i3 device into a scene as a controller with other, older Insteon devices and it all works as expected, then traditional ISY/PLM setup's ability to reflect the device's state in the Admin Console should also work when local state of the device changes, because it is Insteon scene functionality that's behind it. What am I missing in that statement?

Do you have access to product installation manuals? What does multi-switch linking look like with these devices? I am curious if and how well this works, because it may be indicative of how the new i3 devices are using the Insteon protocol(s). The way original Insteon devices worked is that they were in a scene with a Hub or PLM as a controller (the first scene in the scene list). So when you changed state locally it would broadcast equivalent messages to all the scenes that it was a controller in, which included the Hub or PLM. However, while you could still technically command and configure an older Insteon device through the PLM even if it was not linked to the PLM, it would not update the PLM with local state changes. This goes back to the need of a local API for the Hub that ISY (or a node server) could interface with to support all devices equally despite changes in the protocol (or new devices using the protocol in a different way). But perhaps I am just panicking. 🤨