EnvisaLink and Alula Module LngRng 103 - 0000

[theixl]

I have a Vista20P panel with firmware 10.23.
I have been using an IPDatatel BAT module for years. It was upgraded to an Alula module about a year ago.
https://alula.com/communicators/bat-connect/
I have it connected via physical ethernet and via cell service for monitoring.

I recently added the Envisalink4. Everything was working, but one of my normal keypads was down with "Open Ckt". I think I messed up the addressing when adding the EnvisaLink4, so I disabled them all and re-enabled.
I updated the addressing:
16 - Primary Keypad
17 - Keypad
18 - Keypad
21 - EnvisaLink with Shadow Enabled
AUI2 - Alula
20 - Was my old ipdatatel-bat, which I have since disabled

Both the Alula and EnvisaLink work and I can connect to either via the internet web pages and also through my phone apps.
But, now my keypad keeps providing:
LngRng 103 - 0000.
0000 - Control panel lost communication with the communicator

I have disconnected and reset power twice including battery. I went through all the programming options of both and they are all set with no conflicts.
I disconnected the ethernet cable and the cell signal ramped up and I could access the device remotely through the Alula.

So, I don't know if the 103 error is the EnvisaLink or the Alula or neither. I'm not sure what else to check. I do have shadow enabled on the EnvisaLink. I tried it without and it still occurred. Any ideas?

[theixl]

I think I may have messed up the *29 ip/GSM programming. I'll call my alula dealer tomorrow and have them help reprogram it.

[GrandWizard]

You should turn shadowing off. You only use shadowing if you have another Honeywell IP/GSM communicator installed. If the other device isn't an ECP communicator, like the Envisalink, then shadowing should be off.

To clear the 103 turn off shadowing, then enter your user code + 1, twice.

[theixl]

Grandwizard, thanks. I gave it a try and it's still showing up. I think the Alula is a communicator too since the setup is nearly identical to the Envisalink. For example, *29 is enabled for Alula too and many reporting codes are enabled. I didn't get a chance to call the Alula tech today.
Both have *29 enabled, but once 29 is enabled you have to program it but neither state how to do that.

[GrandWizard]

Ok, if your other module requires *29 then you do need shadowing. In this case, the "alula" is in charge so any 103 errors would be a fault with that module's communications. I'm not familiar with this company, do they have something similar to our shadow mode? If so, you could put that one in shadow mode and the Envisalink as primary and see if that helps.

[theixl]

I called today and found out more info. The Alula supports both *29 mode and tip phone dialing for events. Apparently, it rarely works in *29 mode, so alarm companies all recommend using the phone line approach with a dummy number.

It has no way to be put into a shadow mode and has no way to disable the communicator support. So, if *29 is enabled, it attempts to do it's thing and fails. I had to disable *29 and have it send events through the phone method.

The Envisalink still works for remote keypad and Alexa. It just has an error that *29 is disabled. I primarily wanted it for Alexa.

Too bad the vista doesn't allow you to choose which address the communicator is on. It would also be nice if the Alula had a way to disable it's ip mode.

The strange part is it worked for a day in ip mode. Only after I fixed the addressing issue did it start whining.

[GrandWizard]

Just remove the yellow and green wires from this alula thing and it will no longer be able to affect other devices on the bus. It will still be connected to tip and ring so it will still dial out.

Do that and then you can re-enable the *29 for the Envisalink and get your alerts back.