Goose66

Not sure I understand the current context. No node for aux_1 in IoX, yet aux_1 is still turning on randomly? Are there any corresponding log entries for aux_1 and DON commands, like in the first log snippet you posted? Have you tried shutting down the plugin for a couple of days to see if the random aux_1 behavior stops? Just FYI, I did a quick check to verify that the cmd_DON method that generates the INFO log entry in the first post is not called by any other part of the code, i.e., only called as a result of DON commands received from PG3 for the node.

Could it be in a scene?

It does appear the DON command for aux_1 is coming from IoX.

Here's an additional piece of (completely unsolicited) advice: I have disabled this program because we occasionally receive deliveries in the evening (e.g., Uber Eats), and I have noticed if the porch light comes on as the delivery driver is walking up to the front door, the driver will assume you know they're there and NOT ring the doorbell.

There should be battery information related to your "Front Door" node, even if it is powered by the 12V doorbell transformer. See below for mine of the same type: Motion detection is facilitated by the "Front Door (Motion)" node, not through a state change but through a command ("Motion") that is received from the node when motion is detected. Use a "Control" condition from the "Front Door (Motion)" node instead of a "Status" condition, like the following: Front Entry on Doorbell - If ( 'Perimeter / Ring / Front Door' is switched Ding Or 'Perimeter / Ring / Front Door (Motion)' is switched Motion ) And From Sunset + 15 minutes To Sunrise (next day) Then Set 'Perimeter / Front Entry' On Wait 12 minutes Set 'Perimeter / Front Entry' Off Else Set 'Perimeter / Front Entry' Off Also, I think I did notice when I first added this plugin that the states were not populated until one or more events were received from the Ring service, but that was a while ago.

Query only appears to work (or at least be implemented) for security+ 2.0. But querying the ratgdo won't do any good because it is the ratgdo that is unaware of the door state, so even if I could force it to report the current state back to the plugin, it seems to me it would just report "Unknown." I guess every morning, if the door state is reporting unknown, you could just toggle the door state and then about 10 seconds later close (or open) the door based on the newly reported state. But I would prefer that the ratgdo firmware be corrected to determine the door state on restart so that it could initially report the correct door state. I have logged an issue with Paul Wieland.

Something I came across when looking into some firmware issues: It appears that in security+ 1.0 and dry contact modes, after a reboot the ratgdo firmware does not seem to know the door state. You must move the door for the ratgdo to regain the door state. This does not appear to be the case in security+ 2.0 mode because that mode supports "querying" the state from the controller. The potential issue here is that, with the unknown door state, any subsequent open or close command to the ratgdo just reverses the true state of the door. So if you have, e.g., a program that automagically closes your door at night, but the ratgdo was rebooted due to a power failure during the day, that close command when sent to the device may, in fact, open the door. I have logged an issue and hope that the firmware can be updated to set the door state in dry contact mode from the current state of the limit switches upon reboot. In the meantime, keep an eye on it.

It actually seems to have something to do with "client ID" (?). From the faq:

It does appear that the issue you posted is what’s happening. It also seems that the problem may be fixed in the ESPHome firmware, so maybe there’s hope that a similar fix is coming to the MQTT firmware. I have dry contact mode openers and am not having similar problems. Maybe the problem is something to do with the rolling codes? That could explain why a reflash fixes it (temporarily).

It looks like from the logs you sent that the door state wasn't changing from the door commands, but the light state was changing correctly based on the light commands. The ratgdo plugin uses MQTT. So for the plugin, a command for a node is "successful" if the plugin puts the corresponding message for the ratgdo device into the MQTT message queue. The MQTT message queue runs on the same Polisy or eISY as the plugin, so sending commands are almost always logged as successful. If the ratgdo retrieves the message from the MQTT message queue on the Polisy and correctly executes the command, then the ratgdo turns around and sends a status change back to the MQTT server (e.g., Polisy) which the plugin picks up and changes the corresponding node state. Accordingly, from the log file, all I can tell is that your door open and close commands are successfully making their way into the MQTT message queue. I believe there must be a problem with your ratgdo as to network connectivity to the Polisy/eISY or the ability of your ratgdo to control the door. Because the light commands seem to work, I think it must be the latter. Unfortunately for all of us, the current MQTT firmware for the ratgdo device does not contain a locally hosted website that allows you to test/exercise control functions like the other firmwares do in order to debug operation. At least you can test the connectivity to the ratgdo device by accessing the locally hosted website. Outside of that, restarting or flashing and reconfiguration as @gzahar suggested may be your best debug options. We all need to chime in on an issue in the ratgdo firmware Github repository that control buttons needed to be added to the locally hosted website for troubleshooting.

The classic example: If 'Front Door Motion' is switched Motion And From Sunset To Sunrise (next day) Then Set 'Front Entry Light' On Wait 15 minutes Set 'Front Entry Light' Off Else - No Actions - The clear intent of this program is that if there is motion at the front door at night, I want to turn on the front porch lights. However, what you will quickly find is that if motion occurs just a few minutes before sunrise, the light is turned on but never turned off, because the "To Sunrise (next day)" condition generates a trigger event that cancels the Wait and runs the Else branch. This can be mitigated by putting a "Set 'Front Entry Light' Off in the Else branch, but then you have the problem that, at Sunset, the front porch lights will be turned off even if you had just set them On, e.g., in anticipation of a pizza delivery. While this example is somewhat benign, it does demonstrate the somewhat unpredictable and often unwanted effects of having every condition imply a trigger event. It is much more straightforward, IMHO, to just put conditions for trigger events in a first, enabled program, and conditions for, erh..., conditions in a second, disabled program, and have the first call the second. Programs created with this paradigm are self-documenting and straightforward. If you want events to happen at sunset and/or sunrise (e.g., clean up the outside lights), then just create separate programs for that.

Exactly. Also, it allows predictable use of Else branches. Else branches are problematic in regular programs because it's often not obvious what the set of trigger events is (the negative of the triggers implied by the specified conditions) that could cause the program's Else branch to execute. By using the two-program approach, you can define a explicit set of trigger events in the first program that allow the program to run, and have a testable set of state conditions in the second program to determine whether you want the Then branch or Else branch to execute. There are several users in these forums that utilize the two-program approach for just about everything.

This is solved by using two programs, the first enabled and executing the other, disabled program. This approach is discussed in many (many) places in these forums.

There hasn’t been any (other) reason to rollout a new version, so it’s always been a “if it ain’t broke…” sort of thing. If it becomes necessary to get rid of server.json, I will change it. As far as future support, I no longer use this plugin (I have a Honeywell panel) so I don’t notice problems and will have to rely on posts from users to be informed of issues.

Let me know what you find. And if you are still having troubles, please turn on Debug-level logging and send new log files. The Bond Plugin is due some love and if we can find out exactly what's going on here maybe we can get some stability changes in the next release.

Got your log files. At first blush it looks like your Bond Bridge is periodically disconnecting. I will have to circle back into the code and see how long it waits to retry. A couple of questions: - did you recently update the firmware on your Bond Bridge? What version firmware are you running? - what is with all the on then off within a couple of seconds? Appears to have happened many times. Is this normal usage or are you stress testing to tease out the problem(s)? I can tell you that plugins generally have problems with sequence of actions requiring sub-second latency, and the more plugins you have, the worst that the latency can be.

Can you send log files?

Bond Plugin does not use MQTT. It uses TCP sockets to communicate with the Bond bridge. Let's see how other issues with 3.2.20 settle and then we can debug any Bond Plugin issues.

Isn't it necessary to provide an unlock code to "open" devices in Alexa? Perhaps your Lincoln Alexa doesn't support that? You may want to check with @bmercier on issues with Alexa. AFAIK, if the "Open" button works in the Admin Console, then the "open" command should work with Alexa, assuming everything is mapped correctly in your Portal configuration.

Ok, as soon as I posted the above, something occurred to me: the bytes of data read from the socket are converted to Python strings (Unicode) before the message data is parsed. Maybe there’s something in that conversion that’s causing a first message to be truncated and then combined with the subsequent message. For example, since Python is written C, if one of the bytes was null, perhaps, it could terminate the string and the cr/lf from the socket read would never be received and it would just read into the next message. Of course, it seems like this would all be handled by the Python socket libraries or string conversion libraries. Or maybe it’s just something in the EnvisaLink messaging format that wouldn’t be a problem in C or node.js but is inherently incompatible with Python. But maybe something to look at.

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).