Goose66

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.

What is your method of integrating the DSC Alarm with your ISY? Knowing that will allow the question to be answered by the right person.

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.

Is it local control (once it goes through the key pairing routine)?

I would gladly pursue a nodeserver using the Lutron's LEAP API if I can get some help getting the hardware to test with. Let me do some research and I will put together a proposal.

I used EyezOn central monitoring when traveling and the kids were at home. But now I am fine with the alerts I get with the free package. That’s enough for me.

I have the ecobee (and ecobee nodeserver) for my upstairs and the Venstar ColorTouch in my basement. I have to say I like the ColorTouch better for the simple fact that it is, well, simple. The ecobee has lots of features, but is almost frustrating complex to control. You have to jump through hoops to kill of its "logic" and just get it to perform as a simple thermostat. I have my ISY for automation of my home - and that includes the thermostats. I just want thermostats to control the preset temps - that's it. That's why the two main-floor systems are on Insteon thermostats - simple, no-fuss, and natively supported by the ISY. I got the Venstar system for free and installed in the basement to develop the nodeserver (the removed Insteon thermostat is still down there somewhere), and I won the ecobee system and installed it upstairs to get my flair vents working.

That's actually Polyglot Nodeserver OR NodeLink. At this juncture, I would recommend Polisy, which is the surest (and fully supported) way to run nodeservers.

Yes, that should be possible in a program on the ISY.

My whole system is wired, so I’m not the guy to help with pairing wireless sensors.

I believe the Elk is more powerful than the DSC, has a lot more functions, and has some home automation capabilities built in. My motivation for using the DSC was that it was already in the house when I bought it. It was installed by the builder with branding for a specific company (Loud Communications) and they offered the monitoring services and upgrades and such. I was able to factory reset/unlock the unit and set my own installer code, then I could set it up the way I wanted. If I were starting from scratch, I would probably still choose DSC over Elk for the following reasons: 1. DSC is significantly cheaper than Elk. You can find a DSC 1832 board, cabinet, and power supply online for under $100. The Elk M1 Gold is a lot more expensive than that (like $500 for just the board). That said, to use it with the nodeserver, you will also need and EnvisaLink for an additional $130. I think the Elk M1 Gold comes with an ethernet port built in. 2. I like discreet devices. The DSC is specifically an alarm panel and nothing else. So I use my ISY for automation, my DSC for security, my RainMachine for irrigation, my Alexas for voice control, etc. I think the Elk system has a lot of this functionality built in. Not that you have to use it, but it would bother me for it to be there and disabled (I'm functional OCD). As far as DSC functionality, the nodeserver exposes the individual zone states, partition states and arming commands, panel troubleshooting indicators, panic alarms, and programmable command outputs, and more - basically anything you can do from a keypad. It is primarily limited by the command codes exposed through the EnvisaLink API. The EnvisaLink offers different levels of online event generation (independent of the ISY) as well as inexpensive monitoring.

I think the info you got from Brinks is wrong. the IQ 2 system is a wireless security system using proprietary hardware. I don't see anything there that suggests it would support or integrate with a wired DSC system. EDIT: Ah, I see. The IQ 2 system supports legacy DSC wireless sensors along with Power-G sensors. But it's not a DSC system, and thus the ISY nodeserver (and EnvisaLink) will not connect to it.

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.

It appears to me that the Brilliant controller(s) are intended to be the HA hub in a home, i.e., more of a replacement for the ISY than additional devices for the ISY to interface with. They are working on their own integrations with other device vendors. This is a shame, but is unfortunately the way most device manufacturers have thought about deployment of HA products for three decades. There are very few exceptions. I did register an interest in an API (providing my email address) so hopefully I will hear if they ever release one.

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.