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?

+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.