Goose66

Well, the other thing is I don't know how to check the "polling" response of an Insteon device in a program. I know you can Query a device in a program, but the status of the device will only change if the device returns a new status value. If the status value returned from the query is the same or no reply is received, then I don't know how you could differentiate between a same status or no reply in a program. With the setup I suggested, you would get an Insteon broadcast and status value change when the GFCI tripped, and you could hang a program off that. You could also periodically query the low voltage device to get the current status just to be sure.

Something like this: https://www.amazon.com/10Amp-Module-Plastic-Enclosure-Pre-Wired/dp/B0BBRBR1KT/ Wired on the downstream side of the GFCI. If the GFCI (or the panel breaker) ever trips, then the relay output will change and the Insteon Low Voltage device will pick it up.

My concern would be an Insteon device plugged into a GFCI with a faulty ground may give unreliable responses, even if the GFCI is not tripped. I suggest a 120V relay module with the contact closure wired to an Insteon Low Voltage / Contact Closure Interface device plugged into a different circuit. So the 120V relay would be close to the GFCI outlet, but the relay output would need a low-voltage cable run for some distance to reach the Insteon Low Voltage device plugged into a different outlet. The status of the Insteon Low Voltage device plugged into a good circuit should be more reliable.

Are you trying to detect that the septic pump is running, or that the GFCI has not tripped? And, is there another outlet on a different circuit near it?

Have you tried IAquaLink support? I think they have a chat that’s available 24/7.

Can you see and/or control these things through the MyQ app?

To be clear (or perhaps overly pedantic), IoX is the common platform that integrates all these devices. PG3 is the platform that allows IoX to interface with devices other than ZWave and Insteon. I, for one, hope that this distinction is removed in the (very near) future.

I have released a new version (v.3.1.10) of this node server that includes support for OneTouch macros and a few minor bug fixes. See the release notes at https://github.com/Goose66/NSDocs/blob/main/iaqualink-pg3.md for details. Note that if you have an "All Off" OneTouch macro (scene) configured, the state of the macro will remain "Off" even after you send an "On" command. Accordingly, only "On" commands are possible to an "All Off" OneTouch macro even though this macro turns everything off.

Also, for someone with OneTouch, what does it mean to "turn OFF" a OneTouch. Is there really a distinction between turning ON a OneTouch button and turning OFF a OneTouch button?

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.