Supervision of Uplink on Elk?

[LaurentR]

I am confused about how one might supervise an Uplink connected to an Elk using an XSP.:
- The loss of the XSP is supervised by the Elk (no problem there)
- From what I understand from the XSP doc, the loss of link between the Uplink and the NOC is supervisable using the string thingy (uplinkloss/uplinkrest).
- Now, how do I supervise the loss of the RS232 link between the XSP and the Uplink and the loss of functionality of the Uplink itself (like power loss)?

I have programmed the Elk for double reporting (Uplink and landline), and the reporting is totally undistinguishable between Uplink+landline or landline only with Uplink disconnected/unpowered.

Any idea?

Laurent

 

[Spanky]

On page 22 of the M1XSP manual there is a description of how to supervise the Uplink module. The M1XSP sends a text string of "uplinkloss" to the M1 when communication to the Uplink module is lost. A Rule is written to handle what to do with the trouble condition as described in the manual.

 

[LaurentR]

On page 22 of the M1XSP manual there is a description of how to supervise the Uplink module. The M1XSP sends a text string of "uplinkloss" to the M1 when communication to the Uplink module is lost. A Rule is written to handle what to do with the trouble condition as described in the manual.

Thanks for the response.

Hmm, I saw that one and mentioned it in the original message, but the text on page 22 seems to refer to the communication between the Uplink and the NOC as being supervised (which is weird as it's all SMS-based if I am not mistaken).
Anyway, assuming you're correct ;-), the thing I am still not understanding is how the XSP would know it's connected to an Uplink to begin with. Let's say the control just got powered up. There is no way the XSP will send a "uplinkloss"? How does it know if it's supposed to be connected to an Uplink or a thermostat or a PLC...?
So I assume this works only if contact has been established at least once since boot and has since been lost, i.e. the first message ever after power up is a "uplinkrest", and total loss already present at boot time is not supervisable except maybe with a rule that times out if "uplinkrest" hasn't been received n seconds after boot?

Laurent

 

[Spanky]

The M1XSP will have the onboard jumpers set to configure it to the Uplink module. It knows that it is talking to the Uplink module and communicates with it in the proper data format. If the communication link to the Uplink module is lost, the "uplinklost" text string is sent to the M1. A text capture Rule in the M1 must be set to receive the "uplinklost" message and perform whatever trouble indication you desire.

 

[LaurentR]

Thanks to Spanky,
I got some good explanation from Don @ Elk:

"Supervision - The AnyNET transmits a periodic command to the M1XSP. If
the M1XSP doesn't see the command within a certain amount of time it
will transmit the "uplinkloss" text string message to the M1G. This
would be in situations where the cable between the AnyNET and M1XSP
becomes disconnected or the power is turned off to the AnyNET unit. This
allows you to write a rule for the M1G to cause something to happen when
it receives that text string from the M1XSP. The text string is only
used internally by the M1G, it is not sent out serial port 0 (the M1G's
native RS232 serial port).

The AnyNET will also transmit a command to the M1XSP if there is a loss
of wireless service. The M1XSP monitors for this command and will report
to the M1G with the same "uplinkloss" text string message."

I had issues with the uplnkloss/uplinkrest not firing, and we found it was because the text strings should be "uplinkloss^M" and "uplinkrest^M". RP has a note saying that all input strings should finish with a ^M, but I guess I missed that and blindly followed the example rule in the XSP doc.

Finally, the way uplinkloss/rest are triggered: if the XSP/Uplink boot properly, no string is sent. It's only in case of failure, at boot time or later that "uplinkloss" is sent. So one can use a rule that turns an output ON on loss and OFF on rest, and that output basically means "Uplink Fault". I actually wired that output to an input (is wiring the only way of doing this?) to get proper (NextAlarm) reporting.

Note that if the Uplink gets disconnected from the XSP, it takes something like a minute for the XSP to retry and finally give up. The LED flashes for a while, stops, flashes again... Eventually it settles solid ON, and that's when "uplinkloss" gets sent. "uplinkrest" is sent very quickly in reconnection.

Laurent