Goose66

@drprm1 Received the DM with the log files. Good to know you found the "All Off" command and disabled it. That one really doesn't make much sense in the current ISY ecosystem because so many different types of devices are integrated in the controller. Looks like after the initial problem at 6:26 am the MyQ service behaved pretty well, i.e., if you sent an open command they went to "Opening" state and then "Open" state in a few seconds, and if you sent a close command they went to "Closing" and then "Closed" state. Hopefully the physical response you noticed in the door operation was consistent with this. From your door IDs, I am going to guess that you have the MyQ Smart Garage Control system and not actual Chamberlain/Liftmaster door openers. Because this system can only assume the open/closed state from the last position change transmitted by the sensor, it is possible that the MyQ service had a bad internal state and sent an activation to the door even though it was already closed. That would have caused it to actually open, and then when the sensor transmitted the state change, the state changed from "Closing" to "Opening" and then eventually to "Open." If you check your "History" in the MyQ app, it should show the Close commands coming through around 6:26 am yesterday from your name, and it would be interesting to see if there are subsequent entries with no name changing the state to "Open." Just to wrap up, the net-net is that I don't really see any To-Dos here for the the MyQ Node Server, and we just need to watch more carefully and see if this weird state tracking error (if that is what it was) happens again.

Thanks, @Geddy. @drprm1, try sending the log file to me again.

Oops, sorry. I meant to say that I can see I can't get messages and that I was asking @Geddy why that was the case. Maybe a little TOO MUCH shorthand. Anyway, maybe @Geddy will forward to me.

Hmmm.... @Geddy ?

There appears to be two things going on here (both which may be issues): 1. There appears to have been an "All Off" command sent to most likely all your devices. This is evident in that both of your garage door opener nodes received a DOF (Close) command at 06:26:50 am in addition to two gateway nodes and the MyQ Service node, which logged errors because they don't support Close (DOF) commands. This is (and has been for some time) possible from the top-level of the node tree. I think it is an artifact leftover from when 99% of your devices were Insteon lights. As is the case with most node servers, the MyQ node server uses the base On (DON) and Off (DOF) commands for actions, in that the ISY didn't support a lot of specific commands (like an Open or Close command) in the early days. That may not be the case now, but the MyQ node server has always used DON and DOF for open and close going all the way back to the Polyglot v1 version. But if the user goes to the top level of the node tree in the Admin Console and does an "All On" or "All Off," all of the nodes receive the DON or DOF command and will respond accordingly (or error out if DON and/or DOF are not supported). 2. It further appears that both doors received the Close (DOF) commands, sent "close" commands to the MyQ service for both doors, and then changed the status of the doors to "Closing" (again, as evident from the log entries posted). However, 10 seconds later the status returned from the MyQ service for at least the first door was "Opening." So, either something went wrong in the MyQ service in receiving the "close" command and it opened the doors instead, or the doors were opened, started closing, and hit some sort of obstacle and reopened after the command. This may be a harder issue to nail down, and would be best troubleshooted by changing the logging level for the node server to "DEBUG" in the PG3 Dashboard and then opening and closing the doors via commands from the ISY Admin Console (please allow a couple of minutes between commands so that the doors can get through the whole remote open and close cycles). Then DM me the log files. NOTE: changing the logging level to Debug WILL EXPOSE YOUR CREDENTIALS in the log file, so only DM me the log files and don't post any log entries here.

Ah, my bad.

This is one of the hardest things for folks new to programming the ISY to understand: Adding a condition to the "If" statement really creates two things: 1) a trigger event that will cause the program to run, and 2) a condition that will be evaluated each time the program runs that will determine whether the "Then" or "Else" branch is executed. So, for example, "If 'Holiday / Indoor Holiday 1' Responding is not True" creates a trigger event for the program of "Responding status of 'Indoor Holiday 1' device changes" and a condition evaluated at the start of the program to decide which branch to execute. Understanding this element, along with the "re-entrant" nature of the programs during Waits and Repeats is critical to effectively using the programming model of the ISY, and is the reason why you seldom end up using Else branches and often need two programs, with one enabled and one disabled, for getting programs to operate as expected, as is explained ad nauseum in many postings in this forum (and in the Wiki, I believe).

The If statement of the status check program should only fire when the the Responding status of the Insteon device (here, "Indoor Holiday 1") changes. AFAIK, the Responding status of an Insteon device will only change resulting from a query - that's the important bit. So you would need two programs. The first one would be the "polling" program and would be run every day to perform the polling (query) on some interval, e.g., every 10 minutes: Polling - [ID 0005][Parent 0001] If From 1:00:00AM For 24 hours Then Repeat Every 10 minutes Set 'Holiday / Indoor Holiday 1' Query Else - No Actions - (To add one, press 'Action') The next program runs each time the status changes. Each status change causes the program to be executed anew, cancelling any prior running instance of the program, i.e., sitting in the wait: Status Check - [ID 0006][Parent 0001] If 'Holiday / Indoor Holiday 1' Responding is not True Then Wait 30 minutes Send Notification to 'Default' Else - No Actions - (To add one, press 'Action') So if a query results in the Responding status of the Insteon device changing to False, then the program will run, the If statement will be true, and it will enter the wait (which should be an interval larger than the poling interval and the maximum acceptable time for your GFCI to be tripped). If the Responding status of the Insteon device changes back to True during the wait, the program runs again, cancelling the current wait, and falls into the Else branch, which does nothing. If the Responding status of the Insteon device remains False during the wait through all the subsequent queries, then eventually the Wait interval will end and the notification will be sent.

What I don’t understand about your programs is that there is no delay between the query and the running of the programs that check the Responding status. But it takes some time after a query for the ISY to mark the device as not responding. Does the program wait on the results of the query before moving to the “Run” commands? The beauty of the programs I suggested is that the polling (query) and the checking the responding status are uncoupled. As long as the program querying runs more frequently than the wait before the notification, it should work beautifully. It also gives time for multiple queries to take place with no response before sending the notification, thus accounting for occasional Insteon communication glitches (which may be frequent here).

Just tested this with a plug-in module, and it works. New Program - [ID 0006][Parent 0001] If 'Holiday / Indoor Holiday 1' Responding is False Then Wait 5 minutes Send Notification to 'Default' Else - No Actions - (To add one, press 'Action')

There does appear to be a "Responding is True" condition. Never used it - didn't even know it was there. Anyway, you probably need two programs: One that polls the device and one that checks the "Responding" status. The polling program could perform a Query action of the device every minute, and the status check program could have "If <device> Responding is False, Wait 5 minutes, then send a notification." If the Responding returns to True within the 5 minute wait, then the program will be preempted and no notification will be sent. Let us know how it works.

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?

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.