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

Support
, ,
41

Ok, so the first time I did this with Mud Room Door, it saved successfully, but when I re-checked it, it had re-associated with the panel (or never fully accepted the removal, despite successful messaging). It was only the second or third I tried this that it actually accepted this, and I exited/rechecked a couple of times before my earlier post. I was second-guessing myself, but I’m sure that I performed the same steps in the same way. It was definitely fully unassociated at the end of my initial sequence of actions.

After 30+ minutes, I just rechecked again, starting all the way from the main home screen, and it is still fully-unassociated. The screen for Mud Room Door that shows LifeLine indicates “0 nodes in group”. If I then click on Edit and review the full list, nothing is checked.

I then completed the exact same sequence with Front Door. It also claimed successful unassociation the first time I tried, but it was only on the 3rd time that it actually took, subsequently indicating “0 nodes in group”, and with a subsequent review of the full list confirming that nothing is checked. Functionally, it too is now accepting Lock/Unlock commands in a consistent and responsive manner, just as I was used to with both locks prior to associating the HEM and subsequent Z-wave SDK upgrade/clear/relearn everything.

By the way, I just noticed that with this no-associations configuration that, while Lock/Unlock commands work great, and while Locked/Unlocked status indication also works fine, this correct indication is specifically limited to when Lock/Unlock commands are issued. In other words, if I issue Lock/Unlock commands, the actuation of the lock is successful and the status indication correctly reflects the current state of the lock. However, if I were to manually lock or unlock the lock, and then manually refresh the Locks screen, this status no longer indicates correctly. I gather that this probably isn’t surprising, since we’ve essentially forced a bad configuration.

I have not tried manually associating with some other repeating node. I wonder if rebooting the panel and/or locks may reforce the association back to the panel, like you were saying (haven’t tried this, either, but can if you’d like).

42

That’s interesting. I’ll see if I can replicate what you are seeing with the removal.

I would try a reboot yes, and I would then try manually adding the panel association again to see if it works after re-assigning (after the reboot).

This is not a commonly needed troubleshooting step, so I appreciate your willingness to try these steps and your responses!

43

No problem at all, I appreciate your thoughts and help with this!

Ok, so I re-checked both locks (again) to confirm a baseline configuration, and there was no panel/node-induced change - both locks remainder unassociated.

From here, I rebooted the Front Door lock: Still no automatic re-association.

I then rebooted the panel: Still no automatic re-association (either lock).

At this point, I re-checked functional behavior with both locks. Behavior was consistent as before: Lock/Unlock commands behaved correctly/immediately, but manual lock/unlocks did not result in correct status updates.

I manually re-associated both locks with the panel, and then retest functional behavior with both locks. Now we’re back to the original problem: Lock/Unlock commands don’t work as expected, but indication status from manual lock/unlock actions work reliably.

44

Alright, thank you very much for trying all this. I am sending these details to Qolsys. I think this will help with understanding the error! Will follow up shortly.

45

for what its worth, I’m also experiencing the same as Tarek. It seems there is no easy way to change the Schlage to “Group1”

46

Thank you, that helps confirm this. I’ll put any recommended steps from Qolsys in this thread. Are you able to provide the date codes on the Schlage locks? Let us know which date codes correspond to ones that work vs don’t work.

The date code is typically on the label with the default codes and bar code. It’ll be an 8 digit number ending 20XX (the year)

47

Yes, all (both) of my locks are Schlage BE469ZPs. Both behave identically. Both have a date code of 01222019.

48

BE469ZP and 04012019

The information for my other locks which are working well as pre-HEM/SDK days are Weiser Smartcode 10 deadbolt GED 1800 SMT ZW 15 VS FD 4LS2, with date codes 20180905 and 20171122.

From what I understand, Kwikset and Wieser have interchangeable parts, and its basically a Kwikset 914.

49

Qolsys is requesting some specific testing so that they can look at the logs, can you please complete the following and let me know when it was done?

  1. Lock the front door lock
  2. Unassociate the front door lock from the panel. Verify the unassociation was successful.
  3. Send an unlock command from panel or ADC.
  4. Wait 2 minutes.
  5. Send a lock command from panel or ADC.
  6. Wait 2 minutes.
  7. Associate the front door lock from the panel. Verify association was successful.
  8. Repeat Steps 3 – 6.
50

Here’s my progression with the requested round of testing:

  1. Manually unlocked Front Door at 5:50pm Eastern (in preparation)

  2. Lock the front door lock: Manually locked Front Door at 5:55pm

  3. Unassociate the front door lock from the panel. Verify the unassociation was successful.: Completed at 5:56pm

  4. Send an unlock command from panel or ADC.: Completed at 5:57pm (via panel) - SUCCESS

  5. Wait 2 minutes.

  6. Send a lock command from panel or ADC.: Completed at 6:00pm (via panel) - SUCCESS

  7. Wait 2 minutes.

  8. Associate the front door lock from the panel. Verify association was successful.: Completed at 6:02pm

  9. Send an unlock command from panel or ADC.: Completed at 6:03pm (via panel) - FAILED

  10. Wait 2 minutes.: Manually unlocked at 6:05pm, given failure in previous unlock command

  11. Send a lock command from panel or ADC.: Completed at 6:06pm (via panel) - SUCCESS

  12. Wait 2 minutes.

  13. Given unexpected / unusual success in previous lock command, waited another two minutes and sent an unlock command at 6:08pm - FAILED

  14. Test concluded at 6:10pm

51

Thank you very much, I’m uploading the diagnostic logs from the panel to Qolsys so they can look through it.

52

Hi, Jason, any update on this from Qolsys…?

53

I do not have an official update at this time yet, however we recently discovered that the new firmware version 2.5.2 resolved a separate issue which affected S2 devices pairing properly (the T3000 specifically). Z-wave updates were made in 2.5.2.

Can you try updating to 2.5.2 via these instructions and test? Any change?

54

I actually did this last night - no difference to the issue at hand.

55

Alright, well that is unfortunate but good to know. I will follow up with Qolsys to see where they are on this and let them know it is unchanged in 2.5.2

56

Qolsys indicated that this is indeed device specific, with regard to Schlage locks. They were able to confirm the cause and have reached out to Schlage to try to resolve.

I’m not sure what that means for existing locks. I am checking on that, but I wanted to confirm that this shouldn’t be an issue on other models.

57

thanks, Jason. I’m sure this will be resolved with software, soon!

58

Thanks for the update, Jason, I’m happy to hear that the root cause is now understood! I look forward to hearing more about path towards resolution…

59

I noticed on the alarm.com website that for the Schlage BE469ZP it now says “(Only models manufactured in December 2019 or later)”. I guess older locks are now not compatible. Bummer.

60

I didn’t get specifics from Qolsys yet, but that sounds suspicious and is likely connected to this issue. It is likely a change in device firmware that occurred at that time. Prior production runs are likely defective.