Emizon

[downunderdan]

I'm enjoying the discussion of the various 'what if' scenarios, however there's one which is all too often overlooked.

Your client's polling fails (for whatever reason).

Then what?

Once upon a time, when only high-security (read: Top Dollar) customers used systems such as Securitel, it was reasonably simple: Treat it as an alarm. E.g. send a patrol. Now, with the proliferation of polled systems, I believe people need to start thinking about this. All the discussion about different network paths is well and good, but ultimately, if a panel is unreachable, what are you going to do about it? Similarly, if a low-security panel traditionally polled once per day (e.g. a typical dialler) would you action a poll failure of less than 24hrs? If so, how?

Discuss.

[keef82]

I'm enjoying the discussion of the various 'what if' scenarios, however there's one which is all too often overlooked.

Your client's polling fails (for whatever reason).

Then what?

Once upon a time, when only high-security (read: Top Dollar) customers used systems such as Securitel, it was reasonably simple: Treat it as an alarm. E.g. send a patrol. Now, with the proliferation of polled systems, I believe people need to start thinking about this. All the discussion about different network paths is well and good, but ultimately, if a panel is unreachable, what are you going to do about it? Similarly, if a low-security panel traditionally polled once per day (e.g. a typical dialler) would you action a poll failure of less than 24hrs? If so, how?

Discuss.

IP Monitored products are simple also, same principal, on a different path.
Dont know about other companies, but poll failures are actioned as per the customers request.

Usually a patrol is sent, unless requested otherwise.

[SCT]

As PSTN dialler monitoring is still available (and still widely used), I would have thought that the purpose of utilising the more secure formats of GPRS/IP was to know (and action) straight away if a poll is missed thus indicating a possible tamper condition. Otherwise, whats the point of having it?

[keef82]

As PSTN dialler monitoring is still available (and still widely used), I would have thought that the purpose of utilising the more secure formats of GPRS/IP was to know (and action) straight away if a poll is missed thus indicating a possible tamper condition. Otherwise, whats the point of having it?

Exactly what happens, well, should happen i know it does with us.
So i'm unsure why that comment was posted lol

[SCT]

.
So i'm unsure why that comment was posted lol

It was a response to

Originally Posted by downunderdan
I'm enjoying the discussion of the various 'what if' scenarios, however there's one which is all too often overlooked.

Your client's polling fails (for whatever reason).

Then what?

Once upon a time, when only high-security (read: Top Dollar) customers used systems such as Securitel, it was reasonably simple: Treat it as an alarm. E.g. send a patrol. Now, with the proliferation of polled systems, I believe people need to start thinking about this. All the discussion about different network paths is well and good, but ultimately, if a panel is unreachable, what are you going to do about it? Similarly, if a low-security panel traditionally polled once per day (e.g. a typical dialler) would you action a poll failure of less than 24hrs? If so, how?

Discuss.

[Paulypudding]

As PSTN dialler monitoring is still available (and still widely used), I would have thought that the purpose of utilising the more secure formats of GPRS/IP was to know (and action) straight away if a poll is missed thus indicating a possible tamper condition. Otherwise, whats the point of having it?

Have been in discussion with guy from Emizon and finally got out of him that the GPRS will check itself after 24 hours (pretty crap that) I;ve asked if they can program the TCD so that it self monitors its own signal strength and reports this via the IP. That way, the secondary is checked regularly without affecting the payment plan. If the signal strength indicator can show when the aerial has been disconnected or gone bad, surely it can report this via the Primary path.

[IPAlarms]

Have been in discussion with guy from Emizon and finally got out of him that the GPRS will check itself after 24 hours

Impressive.

If the signal strength indicator can show when the aerial has been disconnected or gone bad, surely it can report this via the Primary path.

Maybe the interval that the GPRS "checks itself" is related to the polling interval of the relevant payment plan ?

[IPAlarms]

Similarly, if a low-security panel traditionally polled once per day (e.g. a typical dialler) would you action a poll failure of less than 24hrs?

In my opinion, there is no such thing as daily polling - you may as well continue to call it a daily test signal and at least you can verify the dialler is still working too. What's the point of polling daily ?

There is no way anyone should ever action a "network failure" on a system polling only once a day. How is anyone supposed to know if the connection was "cut" 5 minutes ago and the burglar is still on site, or if the connection dropped out 23 hours ago and nobody has noticed until now ?

I think on dualpath solutions polled at 90 second intervals on both paths, and both paths fail - the answer is obvious.... treat it as an alarm.

On single path solutions, there is a certain interval where it becomes pointless as treating the poll failure as an alarm. I would suggest anything over 3-5 minutes should not be referred to as polling, but as a system trouble instead. Event 356 - Loss of Central Polling.

When using GPRS, it costs money to send each poll, so there is a valid reason for a device not to poll at 90 second intervals.

Broadband solutions can take advantage of free polling, so there is absolutely no reason why an IP device should poll at any more than 90 second intervals. That's not to say that the CMS would receive a Loss of Central Polling event if the device did not poll for 90 seconds as each device has a configurable setting at the server end to determine at what interval an event should be raised.

There seems to be a misconception that whatever the polling interval the signalling device is set on - it matches the threshold for raising an event at the CMS. This is simply not the case.

Fred's IP device may be set to poll at 90 second intervals, yet if Fred's record in the IP Solution supervision settings is set on say 5 minutes, then an event will not be raised unless Fred's adapter has failed to send a poll for at least 15 minutes.

In the above scenario, Fred's ADSL connection could drop out for 3 or 4 minutes and although a few polls would be missed - an event would not be raised.

My 2 Bahts....

[kiwitech]

There seems to be a misconception that whatever the polling interval the signalling device is set on - it matches the threshold for raising an event at the CMS. This is simply not the case.

IP you better go back and re-read your copy of AS/NZS 2201.5.2008

[downunderdan]

I think on dualpath solutions polled at 90 second intervals on both paths, and both paths fail - the answer is obvious.... treat it as an alarm.

One of the challenges of the typical GPRS/Ethernet IP systems, is that the typical Australian internet connection is flakey, and so is the mobile network to varying degrees.

If you set the threshold too low, you will inevitably get occasions when both paths are inaccessible, albeit for a few seconds or so, because the mobile network is crap, and the Internet connection is cactus.

I'm just saying...

[Paulypudding]

Impressive.


Maybe the interval that the GPRS "checks itself" is related to the polling interval of the relevant payment plan ?

It probably is. My point is that it doesn't have to be because there is the ability for self checking within the TCD itself so why can't this be checked and reported via the IP Primary path. That way we still have a cost effective solution and a fully monitored dual path reporting solution.

[IPAlarms]

IP you better go back and re-read your copy of AS/NZS 2201.5.2008

I can't - I flushed it down the pan as soon as I read the bit where class 1 & 2 systems had to go over a private network

I feel even more justified now though

[IPAlarms]

One of the challenges of the typical GPRS/Ethernet IP systems, is that the typical Australian internet connection is flakey, and so is the mobile network to varying degrees.

If you set the threshold too low, you will inevitably get occasions when both paths are inaccessible, albeit for a few seconds or so, because the mobile network is crap, and the Internet connection is cactus.

....but the private SCSI network is reliable isn't it? .....and the private network provided by Telstra for their "Telstra Secure" ?

If a customer requires 90 second polling then they have no choice but to use one of those certified solutions anyway - so there is not really a problem.

The problem only arises when you start to use the public networks, in which case the polling interval requirement is not as strict, so you can up the threshold.

If the Internet and mobile networks are as bad as you say they are, then it really does make you wonder what sort of a mess this will become when people start to use it in large numbers.

What about the 3G networks - how reliable are they ?

[IPAlarms]

It probably is. My point is that it doesn't have to be because there is the ability for self checking within the TCD itself so why can't this be checked and reported via the IP Primary path. That way we still have a cost effective solution and a fully monitored dual path reporting solution.

....but that way they don't get any more money out of you !

The industry is paying through the back teeth for that Australian Standards certificate. If your customers don't need the certification - you really should look at alternative solutions.

The way I see it with the Emizon daily polling plan, you are pretty much paying for a fixed line IP solution, because with daily polling you may as well have a GSM dialler on there.

IP Monitoring is not rocket science because at the end of the day an alarm signal arrives at the CMS, just as it has done for decades over PSTN without any fuss.

Cost has not been an issue to date because solutions are only being used to replace Securitel systems. What the majority of you guys are not ready for yet is the dialler upgrade market. It is at least ten times larger than the Securitel market, but to my knowledge - untapped.

If you think you can install an Emizon board and charge your PSTN dialler customers the same amount as you are charging your Securitel customers - then you better think again.

[downunderdan]

....but the private SCSI network is reliable isn't it? .....and the private network provided by Telstra for their "Telstra Secure" ?

If a customer requires 90 second polling then they have no choice but to use one of those certified solutions anyway - so there is not really a problem.

At 90 seconds, you'd tend to be okay. When you start to look at 20 second or 60 second poll-rates you may be asking for headaches.

Non-wireless IP only monitoring would be okay for an organisation with multiple IP connections and plenty of redundancy. Short of very IT-heavy firms, datacenters and ISPs, I've seldom seen organisations who have an Internet connection more than about 95% availability. The GPRS backup is a very useful adjunct. Ironic when you consider it should be wireless signals that are the problem, not the solution.

This will change over time surely, and I hope people will upgrade to better technology as time progresses. I see too many people loath to replace their 10-15 year old alarm panels, as they haven't died yet. Nor will they, for many years...

We are at the point on small jobs where it's often cheaper for us to rip out an old panel and install a new one, than it is to spend time trying to remember how to hack the old system. As much fun as that often is.

[Paulypudding]

....but that way they don't get any more money out of you !

The way I see it with the Emizon daily polling plan, you are pretty much paying for a fixed line IP solution, because with daily polling you may as well have a GSM dialler on there.

I agree totally, but it is not being marketed as such. It is being sold as a Primary and Secondary reporting device. The secondary side of things at present is not satisfactory. The primary seems to be quite suitable. I know the cost is quite low, but for the control rooms they can't, as you said, sell it for the same cost. Not only does each control room have to pay Emizon (similar to Securitel) but they also have to add a bit for the loss of the phone rebate. It's an alternative solution but it's far from perfect. The cost makes it attractive.

[WIDEMR]

Do control rooms get call rebates? do you mean from securitel or 1345 numbers?

Im a bureau and i get rebates from my 1345 number, but didnt know the control room gets any for receving the call?

There is deff a loss of money from call rebates when going to IP or GPRS as primary, but it works out in the end due to higher inflated monotoring costs.

[Paulypudding]

Do control rooms get call rebates? do you mean from securitel or 1345 numbers?

Im a bureau and i get rebates from my 1345 number, but didnt know the control room gets any for receving the call?

There is deff a loss of money from call rebates when going to IP or GPRS as primary, but it works out in the end due to higher inflated monotoring costs.

Sorry, I was talking about the 1345 rebates.

[IPAlarms]

There is deff a loss of money from call rebates when going to IP or GPRS as primary, but it works out in the end due to higher inflated monotoring costs.

....but be careful on the "inflated" monitoring costs with dialler upgrades or you will kill the Customers reason to upgrade to IP in the first place.

They will do it to save money. If CMS's and Bureaus try to eat into those savings too much - they will not upgrade and a lot may even terminate their monitoring.