Goose66

You are connecting to the Envisalink successfully, it is returning valid data, but it appears that the Envisalink is rejecting the password on login (returns "FAILED"). When you say "tested with web logon" does that mean you logged into the EnvisaLink device on your LAN directly with user ID "user" and the password in the configuration, or that you logged into the EyezOn portal over the web with the password from the configuration? The password for your EnvisaLink device and the password for the EyezOn portal are different. You can reset the password on your EnvisaLink from the EyezOn portal, I believe. There is a problem in the node server in recognizing the error - it provides the proper bad password notification if the return message is "Failed", but not "FAILED", evidently. I will put that in the TODO list for fixing in the next version.

There is an API call to set the stored state vector for a device. However, I have shied away from it because I'm afraid everyone's use case will be different, and the functionality was already accounted for in the Bond mobile app (along with other configuration functions). For example, making it a set function seems counterintuitive, in that people may think they are changing the state, and not setting the stored state. In addition, depending on the device, the current stored state vector may include values for power, light, speed, brightness, breeze, timer, etc., making a set function unwieldy. However, providing specific commands, such as "Set Stored State to Off" is also problematic, in that there would have to be a lot of them to satisfy everyone's desired usages. For example, your light coming on after a power outage seems like a special case, in that I would think most would default to Off. I am open to suggestions for an elegant solution here. Also, for @ISY4Me, you could try adding a network resource to reset the stored state vector. Here is an example CURL command: curl -H "BOND-Token: {token}" -i https://{hostname}/v2/devices/{device_id}/state -X PATCH -d "{\"light\": 1}"

Can you set the node server logging level to Debug, restart the node server, then DM a log file?

First off, if you already have a pool controller, e.g., Jandy or Pentair, I don't recommend removing the current temperature sensor from that and using it for the ISY994i. But if you don't have a controller and are just winging it with ISY switches, then you could buy and install a 10-KOhm water temperature sensor designed for these types of controllers and build a circuit to interface it to an analog input with a supporting node server, such as the Contemporary Controls BASpi 6U6R. As I have posted before, I am not a big fan of having the ISY perform complex and critical control functions for systems such as pools, security systems, HVAC systems, etc., and prefer dedicated and directly connected controllers for those systems (i.e., respectively, pool controllers, alarms panels, thermostats, etc.). You can then find ways to interface each of these dedicated controllers with the ISY994i to create an integrated home automation system.

The MyQ node server uses the MyQ API utilized by Chamberlain's mobile app. The API is not public, so use of the API is made possible by hacking (yes, that is the proper term). I wouldn't say that the API was "reversed engineered" or suggest that hacking the API is protected by "fair use" because using such legal terms invoke the Google v. Oracle case, which is not at issue here. Unlike Google v. Oracle and related cases, the API is not being "copied," in that it is MyQ's implementation of the API that is being used in the way it was intended - no code, data structures, or APIs were copied or recreated. Now that is not to say that the use of the hacked MyQ API is legal or not legal. I am an intellectual property attorney, but I'm not your intellectual property attorney, so I can't give you any legal advice. But it's common knowledge (and therefore not legal advice) that the primary place you should look to determine whether your activity in regard to the MyQ cloud service is allowed or disallowed is whatever EULAs or other agreements you have agreed to with Chamberlain regarding use of the MyQ products and services. All that said, I wouldn't buy Chamberlain garage door openers because the MyQ node server is available. I'm not a big fan of using cloud services nor hacked APIs. I wrote the MyQ node server because I already had Chamberlain (actually Liftmaster) garage door openers in my home, just as I wrote the iAqualink node server (also uses a hacked API) because I already had a Jandy (Zodiac) pool controller. These are both very good products, and I am happy with them. But if I was deciding on what to buy at this point, I would certainly favor a product that lends itself to local control and/or integration with HA systems.

Well, I guess that makes @TSinclair original post deserving of a "Thanks!"

So the maintenance did indeed cause eISYs (and associated PG3/node servers) to reboot?

If something in the brief portal maintenance caused node servers to restart, then this would be important learning for all of us!

Just for folks searching in the future, the problems here were 1) bad credentials specified in the Custom Configuration Parameters and 2) an expired/invalid notification for the licensing issue stuck in the PG3 database with nobody (PG3 or node server) clearing it out.

To answer the "Please Educate Me" question, most node servers do not require the portal or other UDI cloud-based resources to operate - even those that operate through vendors' cloud-based services. However, some node servers utilize oAuth (actually, a specific oAuth method) for authorization to the vendors' cloud-based services, and these node servers may very well require UDI cloud-based resources to complete and maintain this authorization. I will also throw in my personal 2-cents here: the UDI platform is now and has always been a DIY Home Automation platform, and, IMO, it is the responsibility of each individual to educate themselves on the architecture and interface requirements of each automation device they add to their system. That said, it may be helpful for node server developers to specifically point out when their node servers require UDI cloud-based resources for oAuth authentication or other.

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?

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.