Goose66

I have released the PG3 version of the Bond Node server (v3.0.9). Installation instructions, release notes, and version history can be found here: https://github.com/Goose66/NSDocs/blob/main/bond-pg3.md. There is a 1-month trial period and then the Node server is a one-time purchase at $10.95.

You could instead just alter your program to run every 30 minutes: If 'ZW 016 On-Off Power Switch' Status is On And Time is Last Run Time for 'Reset kWh sump 2' + 30 minutes Then Set 'ZW 016 Energy Meter Sump 2' Reset Else - No Actions - (To add one, press 'Action') Make sure "Run at Startup" is Enabled.

I think a DSC panel would be better - yes. But you have to replace all of your keypads as well. Looks like the DUO from Eyezon has the Envisalink functionality plus an LTE modem, so it should work with the nodeservers (HW or DSC).

I believe there is a small number of folks that use the HW EnvisaLink nodeserver in "production." You may want to PM @bgrubb1 and see what he thinks.

The Vista 20P with Envisalink is exactly what was used to develop the nodeserver. It does give you the ability to arm, disarm, and monitor the status of your partitions, bypass zones, toggle the door chime, etc. It also gives you a status for each zone, but the zone status is probably not as reliable (or timely) as the DSC (and I assume Elk) panels provide. With DSC panels, the nodeserver gets a specific message from the panel every time a zone opens and another specific message when the zone closes again, along with other messages that flow from these conditions (alarming, partition not ready, etc.). In the Honeywell panel, while you get a general message that the status of one of the zones has changed when a zone is opened, it doesn't identify which zone and you really never get a specific indication of when the zone goes closed again. So the nodeserver implements a "smartzonetracking" feature where it will use other status messages, such as zone bypassed and partition ready, to try and divine the status of the individual zones. I certainly wouldn't tie any fail-safe decisions to the zone status in the HW nodeserver, but to have it turn on and off lights and stuff like that would be OK.

So long as the system has JRE v9 or less, or Oracle JDK v8 or less, it should work. Anything newer probably won't support Java applet launch from jnlp files. For others, download the isyfinder-2.0.jar file on the web and use the following command (in a script or batch file): java -jar .\downloads\isyfinder-2.0.jar

In addition to what @JAbraham said, it appears that you are running ISY on Polisy. If the Polisy is running both PG3 and ISY on Polisy, try 127.0.0.1 for the IP Address.

I have released the PG3 version of the MyQ Node server (v3.0.18). Installation instructions, release notes, and version history can be found here: https://github.com/Goose66/NSDocs/blob/main/myq-pg3.md. There is a 3-month trial period and then the Node server is $12.95 a year. I decided on an annual subscription for this one since I am generally required to update it a couple of times a year to keep it running.

The BondBridge PG3 nodeserver (now just "Bond") is currently in the works. However, I don't know how well the backup and restore is going to work. The new API for Bond uses 16 digit device IDs instead of 8, and while any existing devices registered in your Bond Bridge will continue to utilize 8 digit IDs, the nodeserver itself has to be changed to get a valid node address from 16 digit device IDs, which may end up changing the node address for nodes representing existing devices. Does this means that restoring a backup from PG2 into PG3 won't work? Answer is I won't know, and it won't be something I will be able to test. I know I (and I can assume others) are taking the opportunity in converting nodeservers to PG3 to make some foundational improvements as well as doing some standardization across nodeservers developed over a span of years. This may result in subtle changes in the way existing nodeservers work that could cause a restored PG2 backup to be non-functional. I would think a better course of action would be to systematically delete your PG2 nodeservers from the PG2 Dashboard and then spin up a fresh install of the corresponding nodeserver on PG3 into the same slot number. That way, the nodeserver installation is consistent and the ISY has the updated profile, but all of your programs and scenes should still hopefully work, with only minor changes potentially required.

Everything goes through the MyQ cloud service - there is no local communication (sadly). There is (currently) no node-level state that indicates the status of the connection between the ISY, PG3, and the nodeserver. The "MyQ Service Connected" state for the MyQ Service node means that the nodeserver is connected to the MyQ cloud service and logged into your account. This may occassionall go down as the nodeserver runs, but will reconnect automatically as the cloud service is restored. Each device (including Gateways) have a "Online" status indicating whether the MyQ could service is in communication with the device. If a device is going through a MyQ gateway, however, the Online status of the device seems to indicate whether the gateway is up or down, and not whether the actual device is connected. This is a MyQ issue and not a nodeserver issue. I have a light module that I used for testing and unplugged it for 24 hours, and it never showed offline. For devices with built in connectivity, like the newer door openers with MyQ Wi-fi built in, the online status should indicate whether the door opener is connected to the MyQ cloud service or not.

@TJF1960 It appears that in PG3, a command named "QUERY" simply performs the same action as the query built into the ISY Admin Console (i.e., right-mouse click on the node and select "Query" and the ISY simply polls Polyglot for the last known values of the states). However, what I wanted here was a way to force the nodeserver to immediately poll the MyQ service to update all nodes as well as flip the nodeserver into active polling mode, so I changed the command to "UPDATE" and the button reads "Force Update." You still have both the QUERY option and the new UPDATE option available to your programs. The "Update Profile" and "Logging Level" functions are now handled in the PG3 Dashboard, so they aren't needed here. I started out with the notion that the "Nodeserver Online" was redundant to the "MyQ Service Connected" in the new architecture, but as my understanding of this evolves, I may be bringing it back. I sort of wished this had worked its way completely into the PG3 architecture, but it appears that's not the case.

Looks like MyQ was running fine this morning but failed with a "OSError: Could not find a suitable TLS CA certificate bundle, invalid path: /usr/local/lib/python3.7/site-packages/certifi/cacert.pem" error. Did you do something to the Polisy that was running Polyglot v2 that would have replaced something in the Python library? Alterantivel, just try restarting Polyglot v2.

The JDK does come with the JRE (the "runtime"), but not Java Web Start, which is what you need to open a Java Web Start file (*.jnlp). If you need the JDK (or more appropriately, a specific version of the JDK) installed, you can start the ISY Finder with the following command: java -jar .\downloads\isyfinder-2.0.jar where ".\downloads\" is my path to the isyfinder-x.x.jar file. The latest isyfinder-x.x.jar can be downloaded from the web - in these forums, I believe.

I looked into a nodeserver for Polyglot, but it really doesn't make any sense at this point. There is no way to use Voice Monkey API to retrieve the "monkeys" setup in the Voice Monkey system. Nor does the ISY->Polyglot architecture allow programs to send text strings to nodeservers. So there is a lot of fundamental pieces missing here that renders a nodeserver pretty useless. Currently Network Resources is probably your best bet until Benoit can get Smarthome Status Announcements working natively. I have contacted the developer and suggested some things and I will circle back to it if the situation changes.

I get the same errors in my Java console when I launch the ISY Finder. However, that doesn't prevent the ISY Finder from running. Where are you seeing a "cannot determine a valid java home" error that you eluded to in your original post.

In the Polisy Dashboard, select "Details" for each nodeserver, and then the "Nodes" button, and here delete the nodes for each nodeserver, deleting the Controller node for each nodeserver last. You may then delete the nodeservers from your Polisy using the "Delete" button (again under Details). Then just shutdown the Polisy - you're done. NOTE: You could try just Deleting each nodeserver - that may work without having to delete the individual nodes.

Multiple ISYs is a PG3 thing.

I am agreeing with you - just laying out what expectations would be.

So something like EnvisaLink you pay $15 once and your done and you might get bug fixes/minor improvements. If a new EnvisaLink comes out with more functionality, you can get a new nodeserver. But something like Ring or MyQ or Ecobee you could be looking at $15 every year or two for basically the same nodeserver if the manuf. changes the API.

The decision to run on Polisy only is another architectural change in PG3. This is really going to take out a lot of complexity on managing dependencies and supporting different versions of languages. I can foresee a time when ISY and PG3 are both running on Polisy for the vast majority of users and the REST-based Node Server API is deprecated in favor of direct MQTT between the ISY and the "nodeserver manager" (call it Polyglot if you like). At that point, it would seem that the Polyglot Dashboard would be rolled into ISY Admin Console, as well.

Here's where I differentiate the pricing model. As others have posted, typically if I buy a device, I don't want to have pay monthly to control it. So I generally favor fixed pricing. Looking at my nodeservers, Autelis Pool Control, Venstar Thermostats, Sony AVR, Bond, EnvisaLink, etc., I would likely charge a one-time fee of $15 or so and then you would get updates when I felt they were warranted, e.g., when new features were added to the device APIs. But for MyQ and iAquaLink, these two take a certain amount of vigilance to keep running, because they used unauthorized APIs that the vendors play hot and fast with it to prevent access (or maybe just because they only have to support their own app). In these cases, there is more of a support role here, and a need for me, as a part-time hobbyist developer, to be "on call" to keep the nodeservers running. I would think a monthly or annual subscription would be a better case here because you can just about guarantee that there will be updates required, and you don't want the author disappearing for months until they can get around to updating the nodeserver for API changes (as is sometimes the case now ?).

That's correct. You weren't setting the status of the keypad button through the "Entry All Off" scene, you were adjusting the "Entry All Off" scene so that the "Entry D" button has an "On Level" of "Off." The net of this is now when you turn the "Entry All Off" scene on, the button status will go to Off. So in addition to changing your program to turn the "Entry All Off" scene on or off, make sure you go back to the "Entry All Off" scene setup and reset the "Entry D" "On Level" to "On" in the scene.

It runs every time the state of one of the devices changes.

From the post above: "You create a scene that has nothing but the All On/Off button as a responder - let's call it "Backyard Keypad Button B." So it's a new scene that just has the All On/Off keypad button in it as a responder. The program sets the state of that scene on or off to toggle the state of the keypad button. Note that this isn't just controlling the backlighting of the key, it also toggles the button state between On to Off, which changes what command it sends when subsequently pressed.

I utilize Keypads in several places that have All On/Off button (usually button B in our house) linked to an "Everything" scene containing devices that are in other scenes or operated on their own. The approach that I use is programs on the ISY. You create a scene that has nothing but the All On/Off button as a responder - let's call it "Backyard Keypad Button B." The same All On/Off button is a controller in the "Everything" scene. Then add a program that names every device in the "Everything" scene like so: Backyard Keypad Button B Status - [ID 0032][Parent 001E] If 'Backyard / Balcony Lantern' Status is not Off Or 'Backyard / Balcony Can C' Status is not Off Or 'Backyard / Pool Deck Floods' Status is not Off Or 'Backyard / Gazebo L Sconce' Status is not Off Or 'Backyard / Gazebo R Sconce' Status is not Off Or 'Backyard / Balcony Lanterns' Status is not Off Or 'Backyard / Covered Porch Lantern' Status is not Off Or 'Backyard / Covered Porch Lanterns' Status is not Off Or 'Backyard / Stair Lanterns' Status is not Off Or 'Backyard / Backyard Floods' Status is not Off Then Set 'Backyard Keypad Button B' On Else Set 'Backyard Keypad Button B' Off In this way, if any device in the "Everything" scene is turned on directly, by another scene, or by another program, then All On/Off button will illuminate, and pressing it will make sure everything is turned off. If the last device in the "Everything" scene is turned off, then the All On/Off button will turn off. This example shows the setup favoring the All Off function. But it could be very easily changed to favor the All On function, i.e. change the if statements to "'<device>' Status is Off," the Then to Set 'Backyard Keypad Button B' to Off, and the Else to set it to On, and then the All On/Off button will be lit only when EVERY device in the Everything On scene is on. In some cases in the past, I have had to put a 2 or 3 second Wait in the program before turning the button scene on or off to prevent some "bouncing" of the status. But I just do this if I am noticing a problem.