12 replies to this topic

[Linwood]

Have Uplink and M1G, I found the rules to notice trouble (i.e. uplinkloss^M string), but what then? How do I turn this into a trouble report to the central station, same as I would get for supervision of any other device?

I see how to auto arm and disarm, but one doesn't seem to have control over sending any specific alarm signals, triggering an alarm, triggering trouble, etc.

The only thing I could see to do is set an output to a relay and have the relay on an input zone, and the relay action trigger trouble (e.g. short out a EOL resistor). Or maybe (though I haven't tried it) bypass a non-alarm zone normally (on startup), then un-bypass it while violated from a rule. But that's pretty confusing for someone at a keypad (I assume they show as bypassed).

In fact I don't see any way for a rule to cause a report to the central station at all, of any type (other than as an indirect side effect of something like auto-arm or unbypass). Is that right?

I suspsect before I am done I will find other troubles I want to detect by rule also, was just assuming there was some way to do this. I can of course do a voice call or email, but I was trying to route everything through the central station so there was a single mechanism - it could then send mail, call, whatever.

[Lou Apo]

Under the "commincator" section you will see "System RC". In that section you program all your central station reporting codes.

[Linwood]

Under the "commincator" section you will see "System RC". In that section you program all your central station reporting codes.

Yes. But how can I from a rule cause it to report those?

Sorry, perhaps I am being dense.

[Lou Apo]

I don't think you can use a rule to report. If what you want to report isn't found somewhere in that section, then you will need to use a rule to set something that is in there.

I have never tried, but maybe you could set an f-key? Not sure if a programatically activated f-key would initiate a call like an actual press would.

EDIT: Never mind, you can't do a programmatially activated f-key from Elk Rules, I was thinking of my ISY which will do that. You would just have to hunt around in the reporting section and find something that can be activated using a rule.

Edited by Lou Apo, 04 February 2012 - 10:24 AM.

[Linwood]

EDIT: Never mind, you can't do a programmatially activated f-key from Elk Rules, I was thinking of my ISY which will do that. You would just have to hunt around in the reporting section and find something that can be activated using a rule.

No luck that I can see, again other than side effects, something like unbypassing a zone so it goes violated because of a rule.

[wuench]

I thought there was an output on the Uplink to indicate trouble (output1?).

But yeah, I don't see a straightforward way to send an event to the central station via rules either, bypass/unbypass a phantom zone seems easiest to me. That might be a good feature request to send to Elk...

Edited by wuench, 04 February 2012 - 11:03 AM.

[DELInstallations]

There's no software driven event you would be able to set up to send a report to the CS.

I just did an OTA to one of my units and the outputs aren't configurable, only O2 via the dipswitch. IMHO, the easiest and most flexible way to do this is to bridge an output and input on the M1 via rules.

I've typically done this and then use the zone to provide end user notification at the keypad. I did this recently on an account where the 2500 is the primary and the POTS line is the secondary (they live in an area where there's constant grounding issues on the telco's aerials).

[Linwood]

I thought there was an output on the Uplink to indicate trouble (output1?).

Hmm... there is. There's a switch that configures it for normal or trouble. I guess I could configure it to "normal" and then hook to an input. But that's if the uplink dies.

The firmware for the serial adapter is configured to communicate failure to communicate (which thus tests the serial link and that the two can converse), but it only reports it by sending a serial string. Elk's manual says to look for trouble by a rule, then the example shows it setting an output. I guess they must thus depend on that being hard wired to an input zone?

[DELInstallations]

The serial text string rule does a couple things, but doesn't supervise if the cell goes down for a physical reason, such as blowing up or loss of power. I haven't tested the 2500's trouble output if it changes state on loss of power specifically, as I only use the 2500's on M1's and don't connect to that output, I do what I need via the M1's inputs and outputs and supervise power to the 2500 via that route.

The XSP is supervised for connection to the bus, so if that goes down, the bus would know. The only portion that isn't directly supervised is the serial connection via the DB9 to the 2500, which hopefully are located within the same can.

The best way to sum it up is look at pg. 25 of the XSP manual. The string would indicate a loss of cell connectivity at the 2500, not if the 2500 goes down. What happens on recept of that string is dependant on what you have in rules. If you have it annonunce only or similar, show text, etc.

In my specific case, I linked an output/input together to send the backup signal via POTS to the CS and provide for a visual notification at the M1 that would stay until the rule dynamically restored rather than via speaking (voice can always be turned off by an end user) or via text (display until * hit). My case being, the event would be logged in the panel (* to reset text is not) and sent via another method (the specific account I did this at last at has 3 communication routes to the CS with a last ditch being the voice dialer/email direct).

[Lou Apo]

I think your best bet is what you were thinking of initially. Use a rule to set an output on/off which controls a relay which closes/opens a zone. Set the zone type as 24hour alarm and inform your monitoring co as to what the zone indicates.

[Linwood]

The XSP is supervised for connection to the bus, so if that goes down, the bus would know. The only portion that isn't directly supervised is the serial connection via the DB9 to the 2500, which hopefully are located within the same can.

The best way to sum it up is look at pg. 25 of the XSP manual. The string would indicate a loss of cell connectivity at the 2500, not if the 2500 goes down. What happens on recept of that string is dependant on what you have in rules. If you have it annonunce only or similar, show text, etc.

If I unplug the serial cable, I do get the "uplinkloss" message.

If I unscrew the antenna nothing happens. IT may be that I have such strong cell coverage that removal of the antenna doesn't cause a signal loss. I need to experiment sometime (pull potts line, unscrew antenna, and see if I can get a signal through to the CS).

If I reconnect the serial cable, I do not seem to get a "uplinkrest" message.

Is the only way to go from an output to an input through a relay?

[Lou Apo]

Is the only way to go from an output to an input through a relay?

Electrically speaking that all depends on how Elk is wired internally. You would need to ask Elk tech support if it is safe to plug an output directly into a zone or if it would cause damage. When the output is on, you would have 12v pushing against the zones 13v. . .no current and a reading of 13 volts or so on the zone. When the output is off, it may allow backflow to ground and you would see a drop in the voltage, the magnitude of which depending on the resistance of flow to ground. There would be a few milliamps of current "backwards" into the output in this case. If an output that is off does not close to ground or closes to ground but with high resistance, then you would still see 12 or so volts on the zone, which would be no different than off state. . .so it would be of no value.

Again, I would ask Elk tech support if there would be damage before trying anything. My bet is that they will tell you to use a relay.

[DELInstallations]

I'd never recommend feeding voltage into a zone unless you are running an analog zone.

Relay for isolation purposes.

I don't know about the uplinkrest message, might be sent back bidirectional upon a successful transmission to a CS, but I'd ask Elk's engineers about that.