Unable to Set User Codes and get Lock Status Updates when XTI is Secondary

I noticed this issue with my Simon XTI/alarm.com not updating certain things. As the topic indicates, I am using my Simon XTI as a Secondary Panel. Reason why is that I use a Vera as a primary controller for my advanced scene integration. Two issues I am noticing here. One is when I give a user lock access, the codes never reach the lock. They just get stuck saying “Pending” and I think it eventually errors out.

The other issue is that the status for the locks don’t get updated either. Here is what I mean. If I lock/unlock the door either through Vera or manually, the status doesn’t get updated. So let’s say my door is unlocked right now. I go into alarm.com and the status says locked. I hit the unlock button and it immediately says unlocked (since the door was already unlocked.) Now if I hit lock in alarm.com, I see that the door does lock. But on alarm.com, it says that the panel did not receive the command.

I suspect that there is some issue here with the panel being a secondary controller. I heard that locks do not work at all when a panel is secondary. However, that is not the case as I can lock/unlock within the alarm.com app and the lock does response.

Wondering if you could look into the logs and find out what’s going on in the backend. I just duplicated both of these actions about 15 minutes ago.

I suspect that there is some issue here with the panel being a secondary controller. I heard that locks do not work at all when a panel is secondary. However, that is not the case as I can lock/unlock within the alarm.com app and the lock does response.

Locks do indeed work in most secondary situations, but there are some caveats. Primary Secondary panel and controller interactions are not really tested or strictly supported by manufacturers, so the integration can sometimes see things like this like the status delay.

More importantly though, I do not believe that the Secondary panel interaction should have an effect on transfer of users data. My experience is largely with 2GIG and additional controllers, but there shouldn’t be much different in that process here.

One thing I do see is that some update requests have a bit of a lag, and signaling is actually on the low side of the strength scale, below what we would recommend for automation use. Are you able to adjust the antenna at all in effort to improve signaling? This may be having an effect.

A good test may be to remove the Simon, remove the lock from the Vera controller, then learn just the lock into the XTi. Do you see an immediate improvement, or do codes still have trouble sending?

I know this is an old post and I apologize ahead of time if it’s messing with anyone’s posts sorted by update time. But I figured this would be important reference in case anyone encountered this same scenario.

I got my locks to work properly with the status being updated whenever I press the lock/unlock button in alarm.com. Plus I can also push codes over with no problem. It takes a good few minutes to push a code, but I’m pretty sure that when I managed codes directly through alarm.com, I had the same response times.

Anyway I resolved the problem by deleting and re-adding my lock into Vera. Then re-syncing with my Simon XTi. I’m pretty sure that this is a Vera issue. Vera causes lots of issues for me and actually looking to move to Homeseer or maybe home assistant. My Vera literally took a few pushes (and yes literally only 3 feet from the panel in all instances,) just so I can get the locks added in.

Anyway I resolved the problem by deleting and re-adding my lock into Vera. Then re-syncing with my Simon XTi. I’m pretty sure that this is a Vera issue. Vera causes lots of issues for me and actually looking to move to Homeseer or maybe home assistant. My Vera literally took a few pushes (and yes literally only 3 feet from the panel in all instances,) just so I can get the locks added in.

Locks in particular may have a little trouble in some secondary controller interactions due to the security keys which must be relayed. Troubleshooting does often boil down to move the devices closer and try a couple more times, unfortunately. There is typically less manufacturer support and documentation for multiple controller networks.