Goose66

1. The Venstar node server does not maintain a connection* to the thermostat where it can get real-time status updates. Instead it relies on polling to retrieve the latest status every short poll interval. However, unlike the MyQ or iAquaLink node servers, the poling takes place on your LAN directly to the thermostat and doesn't utilize a cloud service as a go-between. Accordingly, the polling call is not very expensive network-wise, and can be done frequently (defaults to 15 seconds). Therefore, there is no need for a "Force Update" command. If the 15 seconds is not real-time enough, you can set the short poll interval to 10 seconds or less. Note that the node server also updates the remote sensor states, the system runtimes, and the alert states every long poll interval. * technically it does maintain an HTTP session so that subsequent calls to the thermostat after the initial call are more efficient. But there is no two-way connection allowing the thermostat to update the node server with current status values in real-time, like the EnvisaLink-DSC or Bond node server.

3. If the EnvisaLink is not firewalled and can connect to the EyezOn web service, then you don’t need the “disablewatchdog” setting. This is also documented in the node server "More Info."

2. The “Alarm Panel Connected" reflects the status of the connection between the node server and the the EnvisaLink device. It is really only updated to True when the node server logs into to the EnvisaLink device and to false when the node server disconnects or attempts to send a command to the device and it fails. It’s not updated in real-time. The node server does have a heartbeat functionality, however. It sends an AWAKE command to the ISY on a periodic basis based on a periodic communication received from the alarm panel. The heartbeat functionality is documented in the node server "More Info."

1. Some background: If you “Query” a node from the Admin console, the node server will generally just respond with all of the current status values for the node. The node server doesn’t necessarily query the device for the latest values unless the node server programmer specifically overrides that functionality and adds the device query. The EnvisaLink DSC node server uses the default query approach. Further, the EnvisaLink-DSC node server generally doesn’t poll but instead listens for status update commands from the EnvisaLink device. Other than initial startup functionality, the only thing that the node server does on the short poll interval is update the zone timer values. What the Force Update command does is cause the node server send a command to the EnvisaLink device to resend all its status reporting commands with current status values, similar to what happens on startup. The node server then processes the commands as received. After a Force Update command it may take several seconds for the EnvisaLink to send all the status reporting commands and for the node server to update the ISY.

<rant> A “node” is an individual item (“leaf”) in the tree structure in the left panel of the ISY Admin Console. Nodes have states (“driver values”) and send and/accept commands. Each node usually represents a device, but a node may represent a group of devices, a gateway or hub, a connection to a cloud service, or even a node server instance. The thing you install, upgrade, and configure in PG3 is a “node server.” A node server creates and supports nodes in the ISY. Every node in the ISY that’s not native (Insteon, Zigbee, Zwave) has an associated node server managing the corresponding device. </rant> Thank you for your time.

I have looked at the API available for Schlage Encode lock and feel like it will be possible to build a node server for it. I started it about 3 months ago but, as I said, it fell off the radar. What I can't tell you is 1) will it definitely support Encode Plus (e.g., since it's homekit compatible may it be purposefully limited in what other APIs it supports) or 2) how long will it last (e.g., they could change or withdraw the API). Overall, many of my home automation projects have been pushed to the back burner since I moved last August and have since been waiting to see how Matter shakes out before diving in at my new townhome. I've also been working remotely at my vacation home a lot. I return from an extended absence in the second week of June and will try and look at it then.

From what I can tell, the API that the node server would us should work for any of these Schlage locks that use the mobile app and connect over Wi-Fi.

I installed a Schlage Encode Wi-Fi lock some months back and played with the API a little in preparation for developing a node server, but it just fell of the to-do list. Hopefully can circle back to it in a couple of weeks.

Looks to me like the ISY has lost connection to the node server and/or PG3. Did you just update your Admin Console (firmware)?

I am going to assume that "I can't get to the Admin Console" means you can't run the ISY Launcher from the icon on your desktop - if that's not the case, you can ignore. After installing the latest version of Java, make sure you clear your Java Cache. This is covered in the Wiki, but some of it is outdated. Here is what I suggest: 1. Search for "javacpl" in the Windows Search bar, and the results should include the "Configure Java" app (the Java Control Panel). 2. Run the "Configure Java" app as Administrator. 3. Under "Temporary Internet Files," choose "Settings..." and then "Delete Files..." 4. Make sure "Installed Applications and Applets" is checked, and then click "Ok." As it deletes the cache files, the ISY Launcher icon should disappear from your desktop. 5. Run the IoX Launcher from the Web at https://isy.universal-devices.com/start.jnlp. It may start in Chrome, but it will most likely just download, then you need to open it from the Downloads menu (or the Downloads folder). Once you run it from the Web once, it should put a new icon for the IoX Launcher on your desktop. 6. In the IoX Launcher, click (or double-click - it's a bit wonky) your Polisy in the list, and then select "Admin Console (LAN)." Hope this helps!

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

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.