APC UPS Status Monitoring

nhighton

Firstly, in your experience is it advisable/preferable to keep the TCP channel open at all times, or to open & close it as and when needed?

I need to query 4 x UPSs every 10 seconds for their power status and am apprehensive about constantly having the channel open.

The network isn't terribly stressed or overloaded so network traffic or similar won't be an issue. What has brought the best results in your experience(s)?

Nick

ericmedley

A lot depends upon the device and how it handles being poked on repeatedly. Some devices will eventually lock up if you hit them too much. Others will lock up if connected for too long. Still others force a connection to close after a certain period of time.

UPSs can be very chatty devices. There's really no need to keep the connection alive if you're just polling for periodic status.

However, if you're relying upon or wanting the unsolicited feedback that happens, then you'll need to keep the connection alive. Otherwise you might miss an event that you need to see.

nhighton

Ideally I'd like to use SNMP to talk to the UPS, but AMX seems to lack the support of this. That said, the requirements aren't that great so strings back and forth will cover it.

Every 10 seconds I query the UPS's eventlog which returns its latest 'news'. If the date matches the NI-4100's date and time, and the string contains UPS: Running on battery. Then start a countdown (whilst monitoring power status) for the projectors' shutdown.

In testing, yes the UPS is very chatty. For some reason though, the only way to access the info sent by the UPS is from data.text, the buffer I've created isn't fed anything:

CHAR UPS1_BUFFER[]
...
CREATE_BUFFER dvUPS1, UPS1_BUFFER

Any ideas?

jimmyw

nhighton wrote: »

the buffer I've created isn't fed anything:

CHAR UPS1_BUFFER[]
...
CREATE_BUFFER dvUPS1, UPS1_BUFFER

Any ideas?

CHAR UPS1_BUFFER[1000+?]
your buffer is large enough?

test it,
data_event[chattyUPS]
text:{
send_string 0, data.text
send_string 0, UPS1_BUFFER
}