BAT CDMA (CBAT) dual path bug....

[ano]

That is not the case for mine.  subsequent messages seem to go directly out cellular after the one-time discovery delay.  In the alarmdealer site do you see the "Connection Changed to CDMA" message?

I think the key is not if it can switch from IP to cellular, although that is important, the important part is does it monitor the cellular connection constantly? On my TG-1 Express, if I disconnect the antenna on the unit, within 30 seconds I get a message on the panel & an email telling me it has lost connectivity.  Try that with your IPDataTel even if its in cellular-only mode. I had the IPDataTel initially and don't remember it monitoring either the IP connection or the cellular connection particularly well.
 
The TG-1 does an excellent job of constantly monitoring its ability to communicate with the central office, and if there is a problem, both ends know it within 30 seconds. Does the IPDataTel?

 

[madas]

The IPDataTel takes a long time before i get a message saying the cellular is down.  I powered the device down the other day and i got a call about 1h30m after saying it was offline.
 
I don't think it has a supervisor zone that I can connect to the alarm panel either.

 

[SterlingDonnelly]

The TG-1 does an excellent job of constantly monitoring its ability to communicate with the central office, and if there is a problem, both ends know it within 30 seconds. Does the IPDataTel?

 
How exactly would your central station know that your cellular path is down if the system can only communicate via the path that is currently down?
 
As far as I know the Telguard units don't have constant supervision of the cellular path. You can certainly get it to cause a local keypad trouble with the relay setup but that's not going to notify your central station if there's no alternative path to tell the central station that the cellular path has failed.
 
Have you actually received a call from central station within 30 seconds of disconnecting your antenna letting you know that they see a communication issue?

 

[sorka]

That is not the case for mine.  subsequent messages seem to go directly out cellular after the one-time discovery delay.  In the alarmdealer site do you see the "Connection Changed to CDMA" message?

 
Mine does too as long as the CBAT doesn't have an IP address from the router. If the internet goes down but the intranet stays up which it will if you're router has power, then this is what happens with this device on the LATEST firmware. If you happen to have a router where you can configure a MAC address to have the router pull the IP if it also loses contact with the outside world, then you won't have this problem.
 
Alarm Relay transferred over my EVL4 to their dealer website for Eyezon and are now monitoring my EVL4 directly. I've disconnected the ethernet from the CBAT. The tech said they are aware that there is still an issue with the CBAT and are working with ipdatatel to resolve it. Once they do, they'll let me know so that we can remove the EVL4 from being monitored by them and let the CBAT go back to being a dual path device. If they never fix the issue, Alarm Relay will continue to monitor both.

 

[sorka]

How exactly would your central station know that your cellular path is down if the system can only communicate via the path that is currently down?

That can be accomplished with a periodic watchdog but then the cellular path would have constant data use 24 hours a day even if its only a few bytes every minute or so to get a ping the service that it's alive. If that stops, then the service know it's no longer getting a ping and assumes the notification path is down.

 

[madas]

sorka,
 
Your setup is acting quite different to mine.  in order to test this I stop ALL data from the IPDataTel device going through my firewall (the same as if my cable modem is down).
 
The ip still exists on the IPDataTel and I still see it making attempted requests (when I do a packet capture on the firewall interface).
 
2:53:30pm - KILLED SESSION ON FIREWALL
2:53:35pm - ARMED/DISARMED ALARM
2:56:14pm - ARM RECEIVED BY ALARMDEALER
2:56:29pm - DISARM RECEIVED BY ALARMDEALER
2:56:33pm - CHANGED TO CDMA (ON ALARMDEALER)
 
Then doing another arm/disarm cycle
 
2:58:00pm - ARMED ALARM
2:58:20pm - ARM RECEIVED BY ALARMDEALER
2:58:25pm - DISARM RECEIVED BY ALARMDEALER
 
You can see the first message after the internet outage takes a few minutes (3 minutes isn't to bad) and any subsequent messages are sent out immediately through the cellular.

 

[madas]

Another discovery.  I see the device doing DNS queries over and over again.  Maybe its stupid enough to not go "down" while its still able to resolve the DNS entry.  
 
What DNS server do you use on your DHCP scope for the network that you are connecting the IPDataTel device to? you might want to make sure the IPDataTel uses an internet DNS (8.8.8.8 for example) rather than your firewalls caching DNS server.  The TTL on the record it is resolving is 180 minutes so its likely that the IPDataTel will continue to be able to resolve the host for up to 180 minutes after your internet is down if your firewall is caching the record.  Maybe the lack of DNS resolution is their primary indicator for a "down" connection? I see occasional pings as well (10-30 seconds)
 
Here is the DNS host it keeps resolving over and over (every second)
 
XXXXX.MPA.ROOT.HMWNET.COM (REPLACED THE FIRST PART INCASE THIS IS RELATED TO MY DEVICE)
 
UPDATE:
 
I told my firewall to block all traffic but allow access to the DNS cache and now the IPDatatel device doesn't seem to fail over (like sorka's issue).  It has been 15 minutes and still no failover.  So that is most likely your issue.  I'll write alarmrelay a detailed email and ask them to pass onto IPDatatel
 
UPDATE2:
 
Finally it failed over after about 20 minutes.  So the DNS seems to make a big difference.

 

[ano]

How exactly would your central station know that your cellular path is down if the system can only communicate via the path that is currently down?
 
As far as I know the Telguard units don't have constant supervision of the cellular path. You can certainly get it to cause a local keypad trouble with the relay setup but that's not going to notify your central station if there's no alternative path to tell the central station that the cellular path has failed.
 
Have you actually received a call from central station within 30 seconds of disconnecting your antenna letting you know that they see a communication issue?

When the TG-1 is plugged in, it connects to the Telguard monitoring center, and if the TG-1 and the monitoring center have both verified each other, an LED lights on the TG-1.  This indicates the TG-1 IS being monitored.  Until Alarm Relay notified Telguard about my account, the LED did not light. After that, the cellular connection stays up, and the connection is constantly monitored.  Its just like if you type "google.com" into the web browser on your phone.  Your phone and Google both know if there is a connection or there isn't. Telguard is connected to Alarm Relay so they always know the status of your connection with Telguard.

 

[SterlingDonnelly]

That can be accomplished with a periodic watchdog but then the cellular path would have constant data use 24 hours a day even if its only a few bytes every minute or so to get a ping the service that it's alive. If that stops, then the service know it's no longer getting a ping and assumes the notification path is down.

 
Yes I'm familiar with how servers could supervise the connection and my point was more that I really don't think the Telguard units are supervised at the intervals that Ano believes.

 

[SterlingDonnelly]

When the TG-1 is plugged in, it connects to the Telguard monitoring center, and if the TG-1 and the monitoring center have both verified each other, an LED lights on the TG-1.  This indicates the TG-1 IS being monitored.  Until Alarm Relay notified Telguard about my account, the LED did not light. After that, the cellular connection stays up, and the connection is constantly monitored.  Its just like if you type "google.com" into the web browser on your phone.  Your phone and Google both know if there is a connection or there isn't. Telguard is connected to Alarm Relay so they always know the status of your connection with Telguard.

 
It sounds like you are referring to the activation LED which doesn't come on until the unit has successfully sent a signal through to the central station. You should try removing your antenna and waiting to see if/when your central station calls you.

 

[ano]

Yes I'm familiar with how servers could supervise the connection and my point was more that I really don't think the Telguard units are supervised at the intervals that Ano believes.

Yes, it is supervised.  The TG-1 is a UL Listed unit. The IPDataTel isn't.  When I initially ran my testing with Alarm Relay, I disconnected the antenna, and they saw it within about 10 seconds. They even know your signal strength.  Alarm Relay can set it up however you want, to notify you every time the signal drops or not. I didn't want to be notified for short outages, but they can do it if you like.

 

[SterlingDonnelly]

Yes, it is supervised.  The TG-1 is a UL Listed unit. The IPDataTel isn't.  When I initially ran my testing with Alarm Relay, I disconnected the antenna, and they saw it within about 10 seconds. They even know your signal strength.  Alarm Relay can set it up however you want, to notify you every time the signal drops or not. I didn't want to be notified for short outages, but they can do it if you like.

 
I understand it's supervised and if you were on the phone with a rep from your company while testing, I'm sure they could have also pinged the unit and, at that time, verified it was down. 
 
However, if your expectation is that they would get an alert as soon as the cellular fails, I think you should test that without first notifying them that you will be testing to see if/when they do receive a communication failure message.

 

[sorka]

sorka,
 
Your setup is acting quite different to mine.  in order to test this I stop ALL data from the IPDataTel device going through my firewall (the same as if my cable modem is down).
 
The ip still exists on the IPDataTel and I still see it making attempted requests (when I do a packet capture on the firewall interface).
 
2:53:30pm - KILLED SESSION ON FIREWALL
2:53:35pm - ARMED/DISARMED ALARM
2:56:14pm - ARM RECEIVED BY ALARMDEALER
2:56:29pm - DISARM RECEIVED BY ALARMDEALER
2:56:33pm - CHANGED TO CDMA (ON ALARMDEALER)
 
Then doing another arm/disarm cycle
 
2:58:00pm - ARMED ALARM
2:58:20pm - ARM RECEIVED BY ALARMDEALER
2:58:25pm - DISARM RECEIVED BY ALARMDEALER
 
You can see the first message after the internet outage takes a few minutes (3 minutes isn't to bad) and any subsequent messages are sent out immediately through the cellular.

 
Interesting. Wonder if it's firmware version related? I just got a new version a few weeks ago but Alarm Relay said they couldn't tell me which version it is. Is there a way to tell through the ip fob keypad or through DLS on a DSC?

 

[sorka]

Another discovery.  I see the device doing DNS queries over and over again.  Maybe its stupid enough to not go "down" while its still able to resolve the DNS entry.  
 
What DNS server do you use on your DHCP scope for the network that you are connecting the IPDataTel device to? you might want to make sure the IPDataTel uses an internet DNS (8.8.8.8 for example) rather than your firewalls caching DNS server.  The TTL on the record it is resolving is 180 minutes so its likely that the IPDataTel will continue to be able to resolve the host for up to 180 minutes after your internet is down if your firewall is caching the record.  Maybe the lack of DNS resolution is their primary indicator for a "down" connection? I see occasional pings as well (10-30 seconds)
 
Here is the DNS host it keeps resolving over and over (every second)
 
XXXXX.MPA.ROOT.HMWNET.COM (REPLACED THE FIRST PART INCASE THIS IS RELATED TO MY DEVICE)
 
UPDATE:
 
I told my firewall to block all traffic but allow access to the DNS cache and now the IPDatatel device doesn't seem to fail over (like sorka's issue).  It has been 15 minutes and still no failover.  So that is most likely your issue.  I'll write alarmrelay a detailed email and ask them to pass onto IPDatatel
 
UPDATE2:
 
Finally it failed over after about 20 minutes.  So the DNS seems to make a big difference.

 
Confused. What difference would the DNS make I have not internet service? The CBAT won't be able to get to any DNS server unless I hosted my own locally.

 

[madas]

Most routers tell the clients (through DHCP) to use the firewall for dns resolution.  Then you firewall will make the DNS requests to the outside world.  If something has recently been queried then your firewall will cache the DNS resolution and will NOT go out the internet.  This will still return a valid IP to the requesting device for some period of time even when your internet is down.  My IPDataTel seems to failover much quicker when the DNS resolution fails vs when the DNS resolution succeeds but the connection itself fails.
 
It definitely made a difference in my setup.
 
I don't know how to find the firmware version.  I have a HAI panel so its not hooked to my keypads as it would be in a DSC