Goose66

Unfortunately I am selling my house. I think I will be taking the Venstar Colortouch with me (putting back the old Insteon thermostat so they all match), but if I am renting for a while (looking likely), I may not be able to have it available for testing of the conversion. May need to get somebody to help. Similar story for Autelis, MyQ, EnvisaLinkl-DSC, and iAquaLink, I'm afraid.

If a command was sent from the ISY, then it will be in the MyQ Node server log. Search for “DON” and/or “open”.

The Bond Bridge is essentially just a gateway between a Wi-fi-based API and IR and RF remote control signals. What can be controlled on any given ceiling fan, fireplace, blind, or other device is a product of the design of the device and its remote. So if the fan is only controlled by one class of remote and that remote only offers a single button to cycle the speed of the fan, then that's the most that the Bond Bridge will be able to absolutely control. This is the case with the light as well, which more frequently represents a problem. While most fans I have seen offer separate speed controls on the remote, the remote often time only offers a single toggle switch for the light. So there is not absolute control over the light state. However, there are a couple of other considerations here: 1. While the remote that comes with the fan may only offer that one button, other remotes available for the fan may offer finer control over speed, light, etc., which means there are remote codes built into the fan controller onboard the fan that the Bond Bridge may be able to replicate to give you finer absolute control. Olibra has a library of codes available that can be downloaded to your Bond Bridge by specifying the FCC ID of your fan or remote, so you may enter the FCC ID of a very limited remote but get otherwise functional commands that the remote is not even capable of sending. You should investigate the capabilities of the fan and the available control/remote codes before purchasing. 2. For limited commands like speed and light toggle buttons, the Bond Bridge will (configurably) attempt to track the state of the device and provide "simulated" remote control buttons that allow you to do more absolute controls. For example, even though the fan in my bedroom only has a toggle switch for the light, I have enabled track state and the Bond Bridge presents an On and Off button in the app (and through the API) to control the light. This really only works if ALL control of the light is done through the Bond Bridge (e.g., ISY control, Alexa control, BondHome app control), however, and if someone picks up the fan remote or uses the wall controller to change the status of the light, the Bond Bridge will lose the tracked state and it has to be manually reset. The way I get around this is the remote is kept in a drawer and the wall controller is kept behind a door panel, and I have Insteon switches and Alexa commands that control the fan through the Bond Bridge via the ISY and the Bond node server. The Bond node server only exposes the commands that the Bond Bridge makes available in the BondHome app, whether the commands represent absolute commands/remote buttons available for the fan or simulated commands through tracked state. The node server itself doesn't do anything to track the state. The one thing the node server does do is provide two different ways to access and set fan speed: for a multi-speed fan that exposes absolute controls for each speed, the corresponding node from the node server exposes a state (ST) value that is controllable like an Insteon dimmable switch or fan controller, i.e. is a percentage 0-100% and responds to On, Off, Brighten, and Dim commands. The node server mathematically converts the percentage into the absolute speed and sends it to the fan via the Bond Bridge (or vice-versa for status reporting). This allows the fan to be dropped into a scene with, e.g., an Insteon dimmer switch to allow easy wall control of the fan through the ISY/node server/BondBridge. The node also has a Set Speed command allowing you to set the speed of the fan, e.g. from the Admin Console or through a program, to a specific speed number between 1 and 10 (you have to know your fan's max speed number). This allows you to setup more precise control of the fan, e.g., through Insteon keypad keys and associated programs in the ISY. My advice is, if HA control of the fans are a priority, then make sure the fans have the capability to be directly controlled. For DC fans (which I assume you are considering in a new remodel), the only way to control speed is through the remote and controller that comes with - using an AC dimmer like the Insteon Fanlinc just doesn't work. Having a fan with absolute control codes for both fan speed and light state is most desirable. Also, if the fan has more than one light, e.g. an uplight and a downlight, make sure those can be controlled separately. Whether the fan has it's own Wi-Fi interface or you end up using the Bond Bridge, choosing the right fan will give you the most options for integrating into your home automation system.

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

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?

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.

When doors have been idle for some period, the Node server is in "inactive" polling mode and polls based on the longpoll setting. When a door state change is detected or a command is sent from the ISY, the Node server switches to an "active" polling and polls based on the shortpoll setting. It remains in active polling mode until there have been no more status changes/commands for 3 minutes. This accounts for the behavior you mentioned on closing because of the 10 second or so alarming period before the door starts moving on remote close (see # 6 in the release notes linked in the pinned topic - https://github.com/Goose66/NSDocs/blob/main/myq-pg3.md). This also accounts for the status taking a minute or more to show up when you open the door via the app and the Node server is in inactive (longpoll) mode. However, I have not experienced this type of behavior on an open, in that when I send an open command from the ISY the door begins to move almost immediately (1 or 2 seconds). The purpose of this rather convoluted process is that it is important for the Node server to appear like an instance of the mobile app to the MyQ service. Remember that the MyQ Node server is a hack and not an (officially, at least) approved usage of the MyQ API. If we have a bunch of node servers pinging the MyQ service every 10 seconds 24/7, they will detect this and lock us out!

Maybe create a user code specifically for the ISY/Node server, then at least you could differentiate disarms from the automation system from those done with the master code.

According to API documentation and the current programming, if a partition is armed or disarmed with a user code, then the "Last Arm/Disarm User" state values for the partition is set to the number of the user code. If a partition is armed or disarmed using some other method (by key switch, by button on a keypad, etc.), then the "Last Arm/Disarm User" is set to 0. So when you disarm from the ISY via the Node server, it uses the user code configured in the Custom Configuration Parameters. Accordingly, the number of that user code (40=mater user code) is what will appear in "Last Arm/Disarm User." So I would think that is technically accurate - the master user code configured in the panel was used to disarm the alarm. That said, there maybe could be a way to add a disarm command that took a different user code. It would have to be able to pass an integer between 1 and 999,999 and would result in a dropdown list in the ISY with 1,000,000 selections (which would probably break Java). It would also result in your user code being transmitted across the network in an unencrypted REST request.

The commands that the Node server sends for each node type are here: https://github.com/Goose66/NSDocs/blob/main/evldsc-pg3.md I just updated it to show the values for the "Control" conditions in the ISY. That said, I am open to changing how these work based on how people use them. I toyed with the idea of changing the DON and DOF for the partition to be armed and disarmed. Currently I use the Zone "Opened" and "Closed" commands (in ISY scenes with Insteon devices) and I use partition "Alarm Triggered" and "Alarm Restored" to turn on my floods when an alarm goes off. But the Alarm Panel "Alarm Triggered" and "Alarm Restored" are probably better for this, since the floods would be best used for a fire alarm at night.

@TJF1960 "Status" will only show states (driver values) for the node, e.g., "Partition" state. Setting an if condition on a state will trigger the program whenever the state (driver) value changes, regardless of the value being tested for in the if statement. As I mentioned above, there is no "Disarm" state - it just goes to "Ready" after a few seconds. "Control" will show commands that the node generates that are received by the ISY. If you put a control in the If statement, the program will be triggered only when that command is generated, e.g.: resulting in: If 'Perimeter / Alarm Panel / Partition 1' is switched Alarm Restored Then Set 'Perimeter / House MyQ Gateway / Light Module' Off Else - No Actions - (To add one, press 'Action')