walkman9999

I have started using smart start via the UD iPhone app which lets you scan the QR code, and I choose s2 when I am offered the choice. I have not been able to determine if it joins the device as a p2p link or mesh. I have read Michel comments that there is no official support, I am just trying to understand if there is comm/protocol support for LR since I have a use case that may require it. thanks for feedback and info.

Receipt states: ZMatter USB: Z-Wave+, Zigbee, and Matter Module for eisy (Z-Wave+ Certified - Long Range)i

Apologies if this is covered, my search was inconclusive. My controller appears LR-aware internally and I am able to add using DSK value, but I don’t see any user-facing way to enable or verify LR. Is LR currently supported on eisy, and if not, is it planned? I have a single device that would benefit. TY

Referring to this thread, I was under the impression that TriggerLinks had heartbeat sent once/24h or so. Further reading seems to indicate that the heartbeat behavior is dependent on the version and I have a mix of the v.43 and .42. All sensors expose a "Heartbeat" component but I will report back on behavior. It looks like the original thread (linked above by Guy Lavoie) also relies on a heartbeat, so unless I can leverage that function I don't know how to approach the battery warnings. Some sensors are on rarely used doors so it is a concern. Appreciate the insight so far, any other info welcomed. TY

Is this what you're referring to? If so, this variable is always 1 (set to 1, init is 1). I think it is used to make the program "active". The problem I had with my first iteration was that there was nothing to trigger it. If this isn't what you're referring to, let me know. I'm trying to work thru the possible logic problems.

Well, that wasn't working. I enlisted ChatGPT for an answer and we wrote the following program pairs for Insteon heartbeat-enabled devices: 1) A program to monitor the heartbeat (using control rather than status - this was important) and if heartbeat is received, restart the timer program 2) The timer program that fires the notify if the timer ever expires. Logic seems sound, we'll see how it works in production. _BackDoor-HB - [ID 0064][Parent 0048] If $HB_BackDoor_Armed is 1 Then Wait 25 hours Send Notification to 'Prowl-Normal' content 'Battery-BackDoor' Repeat Every 24 hours Send Notification to 'Prowl-Normal' content 'Battery-BackDoor' Else - No Actions - (To add one, press 'Action') _______________________________________ _BackDoor-Notify - [ID 0064][Parent 0048] If $HB_BackDoor_Armed is 1 Then Wait 25 hours Send Notification to 'Prowl-Normal' content 'Battery-BackDoor' Repeat Every 24 hours Send Notification to 'Prowl-Normal' content 'Battery-BackDoor' Else - No Actions - (To add one, press 'Action')

Still just a framework, I will build this out with some detail but this is my current approach based on u/paulbates. I think the idea below is to not inform if things are OK, but set variable (which informs downstream) if the heartbeat condition is not met. Not exactly sure how to test unobtrusively, so any feedback is welcomed. BackDoor - [ID 005C][Parent 0062] If 'Main House / Sensors / BackDoor / Back Door-Heartbeat' Status is Off Or 'Main House / Sensors / BackDoor / Back Door-Heartbeat' Status is On Then Wait 25 hours Else $Battery_LOW = 1

I do not have much experience with programming on EISY but below is a framework, I know it is incomplete and any pointers are appreciated. Seems like for battery powered device such as TriggerLink, there would have to be some type of additional IF? BackDoor - [ID 005C][Parent 0001] If 'Main House / Sensors / BackDoor' Responding is False Then $Battery_LOW = 1 Else - No Actions - (To add one, press 'Action')

I feel like I've seen a thread that references a solution to this, but search fails me. I don't see a battery status exposed for the triggerlink nodes, but my goal is to receive a notification when it is time to change the battery. Any ideas or links are welcomed. EISY and TriggerLink 2421 .42 TY

I did not reboot between attempts, I will try that. The extra instances just appeared - seems like I'm getting bad interview data maybe. The results of interviews is not predictable. I do not use security, it is not enabled in EISY or on the devices. I do have the issue described in the link you provided. I just assumed it is a "dot zero" type of bug that will be patched. It doesn't seem to affect operations in a direct way. Thanks you for the helpful info. There is a certain "wife window" that I can work on home automation. She is supportive but I sense that that window is closed until the weekend. I will pick it up then.

I don't suspect comms as the problem - the rest of the ZWAVE network works well, and include and remove commands seem "snappy". I understand we're reaching the end of the troubleshooting road, I appreciate the suggestions.

I removed with: EISY-> ZWAVE-> remove a ZWAVE device menu The process work well. I've heard folks refer to "exclude", but I assume that remove is the ESIY equivalent. The reason I use the "Update with interview option" is because the device is "connected", but the subcomponents were not discovered correctly.

I am using the EISY with UDI ZWAVE module that plugs into the device's USB port, model 21100. I performed factory reset on the AEOTEC device each time I exclude. LEDs indicate that the reset was successful. I have repeated the remove/include process multiple times. Both inclusion and removal are quick. Removal works as expected with all components removed from EISY tree. Inclusion triggers the interview and the result is some subset of the total components of the device showing up, sometimes just the alarm and wake-up, other times (as pictured) with everything except the "Alarm Controller" which is the main component that the subs get nested under when present. Is there a separate option for "exclude" (rather than remove)? Any other tips? Happy to keep experimenting, but I've tried any combination of EISY ZWave menu items I can think of. thank you for your input and info

I'm not 100% sure of the terminology, but 337 is the container for the entire network. It is where devices go when I "remove from folder". Edit: screenshot attached

Thanks for quick reply. In this case, I've repeated the procedure 17 times (last device was 033, this one is now 055). I can't really expect any additional iterations to work. Comms don't seem to be a problem, I'm in proximity to the dongle and the add and remove commands seem to be responsive. I've performed factory reset on the sensor multiple times and according to the LED blink sequence, it has been successful. Any idea if factory reset on Z-Wave dongle (ZWAVE->Advanced->Factory reset Dongle) is a good move. Will it remove any devices I have in the network? I also tried the log events during add/remove sequences (ZWAVE->Capture log), but the log was empty of events. Just showing the TAIL commands but zero bytes of logging data. Other than the rubbing belly trick (which I will now try and report back), any other suggestions?