Goose66

I agree that it’s weird that you are consistently receiving the same data yet I am calling it “malformed.” But I say that only because I can see how the data is malformed - specifically the message data starts in the correct format for a few characters, then contains one or two invalid characters, then contains a complete message data string in the proper format. That’s why I am calling it malformed.

A new version (v3.1.4) of the EnvisaLink-HW plugin has been released. This version does not add any new Alarm Panel functionality but instead is intended to increase robustness in the plugin itself in addition to providing multiple ways to monitor the plugin, EnvisaLink and Alarm Panel's health. These include: - Plugin now sends an AWAKE command to IoX every 3 to 4 minutes as long as it is receiving regular keypad updates from the Vista alarm panel through the EnvisaLink. - The Alarm Panel node now has the PG3-managed "Plugin Status" status value to indicate if the Plugin is running. - Malformed (meaning non-compliant to the API) messages from EnvisaLink are ignored instead of causing the listener thread to crash. - If the listener thread crashes, the node server will shutdown the EnvisaLink connection and attempt to restart everything on the next shortpoll from PG3.

A new version of the EnvisaLink-HW plugin has been released that should fix your problem. Malformed data messages like the one you are consistently experiencing should be ignored. Of course, because I was unable to reproduce the error, I await your feedback that the problem has been fixed.

Consistency of approach is one consideration. Else branch may work with state conditions, but rarely works as intended with events. i usually have one, enabled program for events (commands received, times, etc.) and another, disabled program to check states (variables, light status, time or date ranges, etc.) and perform actions.

An update to the PG3 interface (3.3.2) has been made that should fix the error. In PG3x, you can do "System->Reinstall all Plugins" and it should install the new interface (along with the latest versions of all your plugins).

There are also a couple of plugins that require the portal, including Ring and a soon-to-be-released Nest plugin. These plugins utilize push events from the associated cloud services to provide near-realtime status updates obviating the need for polling. The push events are sent to a UD web server which is forwarded to the particular eisy or Polisy via the portal.

like I said, the zone's are squirrely. By squirrely, I mean that the EnvisaLink does a good job of informing the plugin when a Zone is open, but not a good job of informing the plugin when the zone closes again. The EnvisaLink says that's because the panel doesn't inform it: That's what smartzonetracking is about. It basically uses the ready status of the partition and the bypass flags to help the plugin keep up with the zone statuses. If one zone is open, e.g., a motion zone, and then another zone is open, e.g. an exit door, without the partition going to ready in between, then it is possible for the closing of the motion zone to not take place until all zones are closed and go to ready. However, the ready status should be solid - when the partition goes ready, the EnvisaLink sends a specific command to the plugin and the plugin sets the status (ST driver) for the partition node to ready. There's really no logic involved there. First thing is to make sure you set up your panel for the EnvisaLink according to the instructions, including ALL the programming steps. Next, re-enable smartzonetracking and run it with Debug-level logging set in the PG3 dashboard until the error condition occurs, then send me the plugin log file.

Do you have "smartzonetracking" enabled? From the current Release Notes: What shouldn't be "squirrely" is Ready status. This is (or at least has always appeared to be) reliably and accurately reflected by the EnvisaLink - what you see on your panel should always be the same as what you see in the Admin Console. If this is out of sync, then the problem may lie in the link between EnvisaLink and your panel. But I need to look at it more closely. Let me know on the smartzonetracking setting.

I don’t know. I wasn’t involved in the PG2 warning.

I see the problem. It uses the first 14 characters from the "name" from the ratgdo for the node address. For the light, it lops off 3 trailing characters and adds "_lt". So while that's enough characters to distinguish "housegarage" and "housegarage2," it's not enough to distinguish "housegarage_lt" and "housegarage_lt". Rookie mistake. I will put something in the next release.

I need some info: 1) ratgdo firmware version, 2) control mode (sec+2.0, sec+1.0, dry contact), 3) debug level log file with you sending commands. One note: the plugin doesn’t change status when commands are received. It sends the command on to ratgdo and waits for ratgdo to report a changed status. If you are turning on and off the light and the light status in IoX is responding correctly, then it sounds like the problem may lie in the ratgdo.

First, check the EnvisaLink website to make sure your alarm panel is supported. Also, make sure you have the installer passcode or be prepared to factory reset the unit. If the Evisalink 4 will work with your panel, then the plugin will work as well.

I also hope to be using this plugin soon.

But yes, I will put a note in the plugin to add in the next release a "Stop" command for all blinds. The plugin will just ignore it for blinds that don't support stop, or maybe go ahead and send it and let the Bond bridge deal with the lack of support.

Can you not set the stop position for open in the blinds themselves? E.G., manually control the blinds with your remote to set the "Open" position? Two subsequent opens then open to 100%. That's how my blinds at my last house worked.

There is only one state here, and it reflects the lockout function of the GDO that prevents remote activation by RF controllers. The ratgdo publishes status messages for it with the topic ".../status/lock" and the plugin calls it "Lockout". It can have the values of "locked" and "unlocked".

I will probably change it to paid for new subscribers at some point.

Yes. The MyQ plugin is dead. It’s been removed from the Plugin store. My next step is to physically take down the MyQ hardware and toss it in the garbage.

This is done in new version v3.2.5. You need to delete and re-Discover your nodes to get the hierarchy.

I have published a new version of the ratgdo plugin (v3.2.5). This version adds both a "Motion" command (DON3) on motion detection and a Motion state that goes to "detected" on motion detection, and then "clear" approximately 60 seconds after the last motion. Motion is only supported on GDOs with Security+ 2.0 and control pads with a motion sensor. NOTE: You need to change your shortPoll to a smaller increment (such as 10 seconds) because the shortPoll is where it checks to clear the Motion state, and thus the shortPoll value is the maximum resolution for the 60 second timer for clearing the Motion state.

The Bond plugin doesn't dynamically build the profile of the nodes. Thus the node profiles are designed to support the broadest set of features for each class. In the case of blinds, that's Open and Close. What's the use case for automating a Stop command of a blind?

You don't need Java server. Write a local HTML page with buttons hooked to javacript functions to make the REST calls. The javascript can ignore the reply from the REST calls. Add one bookmark to the local HTML page and just use the buttons on it to control the devices.

Also, to clear up some confusion with the original photo, the black to white connection in box 1 is fine and normal in this type of circuit, except the white wire should have had a piece of black tape wrapped around each end (and particularly in the box 2) to signal to electricians doing after-work that the wire is being used as a hot wire.

Ghost voltage in travelers on long runs in a 3-way circuit is common. Never used to show up in older incandescent lighting, but I have had problems with LED bulbs in 3-way (or 4-way) circuits where the line was at one end and the load at the other with long run travelers in between.

Without logs or any knowledge of your configuration, I would say the problem is most likely with your Lincoln. You probably have your Lincoln set up to connect to your wifi while at home and when you arrive back home there is a period where the Lincoln is unsure if it’s on LTE or WiFi.