Goose66

@AnthemAVM If you wind up with newer fans with DC motors in them, those ZWave fan switches (or FanLinc, for that matter) ain't going to work. Also, there are several DC fans from Minka Aire available that has Bond controller built-in ("Smart By Bond" or "SBB"). That way you don't have to buy a Bond Bridge, but you're going to pay the difference in the price of the fan. But if that's what the wife lands on from a style standpoint - bonus!

Or we could just use Node Server API -> Polyglot -> Insteon node server which is all supported now if a local API could be implemented (or perhaps simply exposed if it's already there) in the Insteon Hub.

Note that the Node Server API is currently a REST API (HTTP), but I believe (hope) it is on the roadmap to shift the Node Server API to MQTT (UDP), thus eliminating Polyglot (or at least shifting it into ISY on Polisy (IoP)).

Yeah, it seems a little bit of a stretch, but I guess you could view PLC data like Ethernet vs. Wi-fi. I can do UDP/TCP and HTTP over both Ethernet and Wi-fi even though they are completely different. So why not over PLC if the packet length and addressing is sufficient. But, I would think there would need to be a gateway of some kind until the devices can have a low power Wi-fi (802.11n) chip in them. Frankly one of the things I like about Insteon over, say, Wi-fi enabled bulbs or switches, is that it has its own communication network (PLC/RF) and works pretty flawlessly within its own sphere. I have way more problems talking to devices from the ISY through the PLM than I have problems with device-to-device communication in my Insteon switches and such. Of course, a large portion of the devices in my home that must communicate with each other are most often in the same room and/or on the same circuit.

I don't think UDI wants to be in the business of switch and module hardware manufacturing (but I could be wrong). The solution I suggested would just be a way to give the large base of ISY users who's homes are almost 100% Insteon a few years to transition to ZWave or other while keeping the seamless integration of the ISY/IoP.

What I would like to see is UD purchase/license the Insteon chips, device designs, hubs, and website. Get the website back up and running supporting the hubs, and then let me develop a local realtime API for the hub which would then be linked to IoP through a Polyglot node server. The current Insteon code could be removed from IoP in favor of only Zwave native support. Programs/Schedules functionality would be removed from the Insteon website leaving only device configuration. There could then be a Hub for PLM swap program. Whether UD would want to start back manufacturing Insteon devices would be their decision - but that's a big lift! (not that I think UD is not capable - they already have hardware design chops and manufacturing relationships) I don't mind having to use a cloud service to configure my devices - in fact I prefer it because those sites are usually much more advanced and a whole lot easier to deploy updates to. But I don't want my integration platform and programs to have to operate through cloud-services. I want to be able to drop Insteon devices into scenes with Zwave devices, Ring devices, Venstar thermostats, DSC alarm zones, MyQ garage door openers, etc. like I can do today on ISY/IoP, and have the whole thing be as local as possible. The above strategy is one path to get us there.

I guess this could be differences in the panels and/or the programming. I have a DSC PC1832 board and there are four ways to arm it: "Away" keypad button, "Stay" keypad button, what they refer to as "*9" (Zero Entry) arming, and by entering user code. These correspond to the four available arming commands in the EnvisaLink TPI: CMD_ARM_PARTITION = b"030" CMD_ARM_PARTITION_STAY = b"031" CMD_ARM_PARTITION_NO_ENTRY_DELAY = b"032" CMD_ARM_PARTITION_WITH_CODE = b"033" The three buttons on the Partition node in the node server, "Arm Away," "Arm Stay." and "Arm Zero Entry" correspond to the first three methods, respectively. If your panel is programmed to require a code for arming, the EnvisaLink will ask for the code and node server will supply it through a sort of "handshake" routine. The fourth (user code entry) is meant to be interactive (all the keypads beep incessantly during the exit delay and such) and is not supported in the node server.

I can only arm my system AWAY, no matter how I arm it, which is probably because I have no motion sensors. So I wonder what would happen in your case if you just used the node server (or Nodelink) to send command 032 (in the node server's case the "Arm Zero Entry" button) to the alarm panel without previously arming it? Would it arm in Away Zero Entry or Stay Zero Entry mode? In my case, it arms in Away Zero Entry mode (I have no motion sensors).

Ok, so I just tested it remotely thanks to UD Mobile, and unfortunately the Arm Zero Entry command by itself does seem to put it in Armed Away ZE status instead of Armed Stay ZE status. Further, sending the Arm Zero Entry command after an Arm Away or Arm Stay seems to have no effect - it just remains in the Armed Away or Armed Stay state. So I will have to play with this and rollout a new version of PG3. Seems what we want is an Arm Zero Entry command that results in Armed Stay ZE, because the alternative (Armed Away ZE) doesn't really make any sense.

Ah, sorry I was way off track here. In my defense, I was responding from vacation using my phone, and it was after coming back from dinner with my group, so..... let's start again: Yes, in the current EnvisaLink-DSC node server, there is a "Arm Zero Entry" command (button) on the Partition node that sends command TPI command 032. Interestingly, there is one partition status for Armed Stay Zero Entry (ZE) and another for Armed Away ZE, but I haven't really known how the panel ever gets into the latter state. If the intent of the API (TPI) was that the node server would send Arm Stay or Arm Away AND THEN Arm Zero Entry, then that's not how it working right now. It just sends code 032 and the panel seems to arm with it. My previous alarm system had an "Instant" button that armed Stay with no entry or exit delays. We used it every night to the point that the label was rubbed off, and I miss that on the DSC.

I’m asking what happens today when you press “Armed Zero Entry” button on the partition node in the ISY Admin Console.

So what happens when you press the Arm Zero Entry button on the partition? Is that arm away zero-entry?

I am not aware of that command. I don’t believe the DSC supports an instant arm. If you are talking about Zero Entry, that’s already supported. If not, please send the command details and I will take a look at it.

@Rootdet Can you PM me a log package so that I can debug the PKCE install error.

There was a change in newer versions of PG3 - we are no longer using the configuration file and must make all settings in the Node Server Store. I updated the settings for the Bond node server last nigh to enable the Discover button in the Node Server Store, and that should have propagated to your Polisy by now, so try stopping and restarting the node server (you may not even have to do that) to see if the Discover button is now available.

@Rootdet The PKCE package is definitely in the requirements.txt and has been working for everybody else. What version of PG3 are you running?

This looks like a PG3 bug. It's still in development (as I am sure you can tell). I will get see if I can UDI/Bob involved here.

@garybixler In order for the PG3 node server to discover bridges and devices, you have to press the "Discover" button in the PG3 Dashboard for the node server. The "Discover" button should show up between the "Log" button and the "Delete" button in the node server Details. From the instruction document:

Since I don't use Oracle's JRE (and thus don't have the deprecated Java Web Start), I had to download the isyfinder-2.0.jar file and run the ISY Launcher manually: java -jar .\downloads\isyfinder-2.0.jar I have this in a batch file in my default user directory (thus the relative path to "downloads").

In PG3, the "Discover" is actually a button on the Polyglot Dashboard now. Going to take all of us some time to get use to the changes.

Neighbors?

1) Yes. Also, you could see some differences when sending off commands, or subsequent off commands, after turning off the load. Check your ISY logs. 2) Also yes, in that it's the receiver on the PLM that's probably the weak component, IMO.

I'm betting the power supplies in your LED lights are causing interference in the PLC communication from the switchlinc. Try a filter between the switch load wire and the lights.

See if your fans have a remote control unit available that can be added, and then buy a Olibra Bond Bridge to control the fans via the remote codes.

Several years ago I installed my first PG1 Node server that loaded a malformed nodesdef.xml that prevented the ISY from starting. Since I didn’t have a recent backup, I pulled the SD card and mounted it Windows. I was able to decipher the file system enough to find the errant profile XML file and remove it, allowing the ISY to start. I think I recall that each program is similarly stored in an XML file in various folders. proceed at own risk — possibly warranty voiding — and all that jazz. BTW, UD quickly fixed the profile load bug in a firmware update. It’s also very possible that subsequent firmware changes have made the underlying file system unreadable/indecipherable.