Goose66

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.

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.