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