Z-Wave Network Stability Adversely Impacted, Seemingly After Having Added Aeotec Home Energy Monitor

thanks, Jason! I reached out to QolSys in the meantime (they thought I was your customer because you also emailed them about the same issue :slight_smile: )

Anyways, indeed it was as you suggested earlier. Too much traffic. There is a patch that can be applied to fix this issue.

Contact admin for details.

Yes, I got a response at the same time. Qolsys has asked to keep the patch tag private. It will only work in specific circumstances.

We will PM our user Tarek.

Per Qolsysā€™ suggestion, you should remove all devices and re-add them all for best results.

Thought I post an update since it been almost 3 days since I updated my Z-wave protocol to the 6.81.03 SDK: the verdict is mixed. It seems the new patch has improved the situation, but iā€™m still getting connectivity issues.

  • locks are still going on/offline (much less times though)
    -and a bit of lag with my z-wave devices

In the cases where the lock goes offline, it could be only momentarily, but the alarm.com servers have to catch up because, my app would say that the lock is malfunctioned, but I can still control it via the app or the panel. And its not a distance issue, one lock that went offline is about 5 ft from the panel.

Another issue I have noticed now is my other Aeon lab product, the Heavy Duty Switch for my Sump Pump. After I removed the z-wave devices, and added them back, my dealer reassigned the sump pump status feature (because that disappeared after I removed the devices). With the notification set up tell me when my sump is running, I tested it by running the sump pump, and didnā€™t get any notifications. The usage does show up in the Sump Pump Activity monitor (after some time), however.

Below are my Z-wave counting stats on the second day (i.e. not today). They were at 20,000 with 22 errors last night. This was reset after the software update.

xeon, thank you for sharing your experiences.

Jason, that you for your follow-up and the PM.

For my part, I have not yet had a chance to implement the recommended software changes. While I can appreciate the technical necessity behind needing to basically reset everything relating to Z-wave, I want to approach this carefully by first documenting the numerous settings, configurations and automation actions already configured, so that I can reconfigure them again after the fact. Maybe I can tackle that this weekend.

Jason, considering xeonā€™s reported experiences with this update, I assume your recommendations (per your PM) continue to stand, and that if any issues remain that weā€™ll just plan to iterate and troubleshoot from there, on basis of the new SDK version? I just want to be sure that this doesnā€™t change your recommendations (or those of Qolsys), as resetting everything Z-wave is not something Iā€™d really like to perform more than onceā€¦ Thanks so much for your support!

I would still recommend trying the update, as there would be no other way of potentially using the HEM at this time without interruption to your Z-wave network, though I cannot say for certain the impact it will have. It appears to have made a difference in the other user case, but there is still a problematic amount of signaling. Ultimately the HEM is the cause and anything Qolsys can provide is a potential work-around rather than a fix, exactly, based on what the problem was described to be.

I wouldnā€™t recommend it if you would rather just remove the HEM from the system, of course.

If it helps, I would still recommend it. Yes, it will take some time to redo everything, but overall it has improved, in fact its been 36 hrs since Iā€™ve had an issue with the exception of my sump pump reporting. Iā€™m working with my dealer on this one. My sump pump was plotting usage before it was paired with the water sensor (and after I updated my z-wave network), it stopped working after my dealer paired it with the water sensor (and thus my sump showing up in my alarm.com account), so, this leads me to believe its a back-end issue. Also, if I click on the usage now button for my sump pump, it communicates and gives me a reading, its just not plotting or sending me sump pump notifications.

Thank you both for your thoughts. I completed the software update and rebuilt my Z-wave mesh this morning. I individually removed all devices, and then ran also ran Remove All Devices, for good measure, before adding back all Z-wave nodes. I added in the HEM first, just to see if it might complicate the joining process of any of my other devices, but I saw no indications of this - certainly good news.

Everything generally seems to be working at this time. Iā€™ll provide an update in the coming days/weeks.

Good to hear be glad to hear how things work out for you. So far I havenā€™t had an offline instance in about 4 days now. That is good news indeed, however there have been times where locks have not been responding to unlock commands or lock commands. For example it used to be when I would push the Away scene button, for example, it would lock all my locks, but now I have to double-check to see that it is indeed locking as sometimes 1 lock does not lock. Does not happen all the time. This might be as good as it gets for me, until they really figure this out with some other future software updates.

To finally provide an update on this after 6+ weeks, I can relay that my experiences after transitioning to the new SDK version are identical to what @xeon reported. Namely:

  1. The good news: Far, far fewer instances of devices falling offline. In all this time, I never once experienced a repeat of either of my door locks going offline. Instead, I had a about two instances where my weakest-signal light switch went offline (which may or may not even be related).

  2. The bad news: Both of my door locks rarely respond to remote commands anymore, and this behavior has been consistent since immediately after updated to the new SDK. Both of these devices are Schlages and were learned in using S2 security. I understand from exchanges with xeon that his are not Schlages, and he learned one of his in using S2 and the other without using S2 (xeon, please correct me if I mis-represented your experiences).

For the door lock remote command problem, the general behavior can be described as follows:

  • While in front of either of the doors I am trying to lock/unlock, I open the ADC app on my phone, issue the applicable Lock or Unlock command and wait

  • App respond with Locking or Unlocking indication, with the pulsing indication

  • While waiting/watching/listening for the door lockā€™s motor, I continue to keep my phone on and the ADC app in focus the entire duration, just to rule out any app/OS related concerns

  • In almost all cases, the command appears to time out (within 2-4 minutes), the lock state doesnā€™t transition, and the ADC lock indication icon goes back to the state it started with (Locked or Unlocked)

  • Issuing commands via the Qolsys panel results in similar behavior (only seemingly with different timeouts)

  • Repeating the same Lock or Unlock command almost immediately after a failed attempt pretty consistently results in success, almost like the command that it failed to respond to immediately prior woke it up after the command had timed out. Interestingly, the same does not appear to be true when issuing the opposite command, after eventual success. In other words, if lock is Locked and I issue Unlock, it times out, and I immediately issue Unlock again, it generally succeeds. However, once Unlocked, if I immediately issue a Lock command again, it generally does not succeed - until I let it time out and then issue a Lock command a second time. Maybe this aspect of the problem is just coincidental from limited testing, but thatā€™s how it feels, at any rate.

  • Prior to the issue with HEM and subsequent SDK update, the commands would cause the locks to Lock or Unlock 100% of the time very consistently within 1-3 seconds.

Since I only plan on building out the Z-wave network from here, and definitely donā€™t want to give up the HEM, what would be the next steps from here? Is there further data (whether provider-supplied or user-supplied) that can be shared with Qolsys and/or Aeotech to troubleshoot current behavior?

I understood from earlier exchanges that HEMs appear to be particularly ā€œchattyā€, but we canā€™t be the only ones in the world with this issue, right? I have to imagine that other users (even of different providers, different hubs/panels, different manufacturers) have somehow managed to avoid similar concurrence problems?

Iā€™d like to echo what Tarek is saying, Iā€™m experiencing the exact same after the software update.

Just to add more details, I have 3, Z-wave locks:

2 Kwiksets 914 (called Weiser here in Canada)
1 Schlage BE469

The Schlage is enrolled as S2 while the Kwiksets are S0. Iā€™m having issues with the Schlage where it only works on the second command to lock/unlock (the first command does nothing). The Kwiksets operate as normal.

Thank you for following up! Iā€™m sorry to hear you are seeing these issues as well, however, with confirmed problems occurring on a system we have access to, we can provide these details and the panel logs to Qolsys for review and hopefully a fast turn-around on a fix.

It sounds like the issue occurring is related to the lockā€™s battery saving feature. They are operating in flirs mode, operating on extremely low power until woken up by a command, it sounds like the command that wakes the device is simply not being processed. Iā€™m not sure how straightforward of a fix that would require, but these details in this thread should be very helpful!

I know Qolsys stated that the 6.81 update to the Z-wave radio can cause issues for existing devices. All Z-wave devices must be removed and re-added after running the update. As long as that was done you should be able to use the system normally.

Iā€™ll send your report to Qolsys and see if they have any suggestions or if this might be a bug.

Thanks, Jason! Just to confirm, I did remove all devices prior to the SDK update, updated the SDK, and then relearned everything back in from scratch. Of course, if thereā€™s any testing that I can do to generate any data to pass along, Iā€™m more than happy to do so!

FWIW, I also excluded (after deleting) the device before including it again (after the software update) starting from the HEM.

And I tried to add the Schlage as an S0, but after it added successfully, it said something like Iā€™m not able to control it because itā€™s unsecured.

Qolsys is going to look at your panel diagnostic logs to see if they can find the cause. I will update here with any troubleshooting suggestions. If the troubleshooting is general and doesnā€™t require dealer specific assistance, xeon should be able to try as well.

This may however just be a bug that needs resolved in software. Iā€™ll follow up here asap.

Qolsys had this to say after looking through the logs:

From the logs, it looks like it might be an association issue. The lock needs to be associated to the panel which should be done automatically at the time of pairing. You can confirm association from the panel screen. First turn on advanced z-wave settings, navigate to the lock under the Association menu and make sure node 1 is in Group 1 lifeline.
There might be some other issues as well, but we would need to go through all the lock/unlock commands to determine where the failure is.

hi, thanks for sharing! just curious, perhaps Tarekā€™s has a different configuration, but my problematic lock (the Schlage) is in Group Name called ā€œLifelineā€, while my other two locks (not giving me issues), is in the group name called ā€œGroup1ā€. Iā€™m a little confused by what the instructions from QolSys (because they mention both Group1 and lifeline", but realize its not my system they are looking at.

So if I access Settings | Advanced Settings | Z-wave Devices | View/Edit Associations, I see that ID 1 (Node 1, I gather) is the Panel itself. If I then click on View, I can see ID 1 with a Group Name of LifeLine.

@xeon, just to compare with your observations, I then reviewed my two Schlage locks (both having the issue), and I click on View for each of them, they also have the LifeLine association (and only the LifeLine association) for each of them.

Whatā€™s the next step?

Thank you for confirming. You should be seeing Group1 in a successful case when looking at the locks in View/Edit associations.

If you edit the association for one of the locks, try unchecking the panel association and saving. Any change?

Well that is very interesting! So, yes, I left Front Door alone and changed Mud Room Door to remove the Panel association (the only association that it started off with). After saving and a couple retries, it appears to be working.

Iā€™ll admit to being skeptical that this would achieve anything, at least not without manually adding an association with some other repeating node (there is presently no association whatsoever, the way that I tested it).

Do you think I should also remove the Panel association from the other lock and just leave them both completely unassociated for longer-term testing? Or should I remove the Panel association but try substituting an association with some other nearby repeating node?

It cannot have zero associations. The lock should automatically re-associate it with the panel. I am curious if this puts it in Group1 and/or resolves the failed association since you are forcing it to reset

Go ahead and try with the other door lock. Go back in and check the Mud Room one as well, what does it report under associations?