Goose66

Does anybody have salinity, ph, or orp values showing up in their node server? These values may actually not be implemented, and I am contemplating removing them from the node server altogether.

Do you see salinity on a mobile app screen, or when you click the "Web" button and it takes you to the associated website in an internal browser?

Good catch! I see the problem here. I am working on a new version with OneTouch macro nodes, and I will fix it in that version.

I will look for the "OneTouch Scenes" in the API. I could provide nodes for each OneTouch scene with a "Toggle" command and state or I could just include 6 command buttons labeled "OneTouch 1," "OneTouch 2," etc. on the System node. Let me know what you think.

There is a salinity value that’s returned in the “API” (I put that in quotes because it’s not really a public or published API). But in my own pool, I never had a salinity sensor (or a saltwater pool) so it always returned 0. And I worked with another user at one point who did have a salinity sensor that showed a value on his control device that nevertheless returned a salinity value of 0 in the “API.” If someone with a salinity sensor that sees a value in the mobile app or otherwise would be willing to share credentials, I could look at their returned values from the API and make sure the node server is just not missing something.

Salinity is being read and should work. I would need to get your credentials and run a special debug version of the code to see what data your system is reporting. Color lights should work as well. Really don’t know if pump speeds or watts info are available. Only what’s available in the mobile app (not the web interface) is available to the node server. One touch configurations are basically macros that could be recreated in programs in the ISY. Unfortunately, I no longer have a pool, so this is a hard one to make changes to.

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.