Monitor battery status

In this article, I want to share my experience in developing a system for monitoring the condition of batteries (batteries) in switching cabinets (SC). Also the prospect of implementing a system of proactive protection of the local network using the method of multi-agent segmentation_.

The task is as follows: to know the actual state of the battery in real time, as well as keep records of measurements in the barcode. Since different uninterruptible power supplies (UPS) are used, starting from varieties of APC Smart-UPS and ending with RIP, the task becomes more complicated. Therefore, the decision was made to conduct tests specifically with the battery. In the future, use an individual approach to each UPS using the available source interfaces. But at this stage (demo) a cardinal solution is needed.

So, we have a deployed and debugged Zabbix 6.2 system: on Ubuntu with MySQL, Apache on board and a local network across all cabinets. Each HK has a MIRADA controller, the documentation of which was declared to work via the SNMP protocol, as well as unified ports 4-200 mA and 0-10 V + 4 relay outputs.

To fix the voltage, it was decided to use a resistor divider. The nominal voltage of the 24V battery circuit has been reduced to 10V for the controller input. Based on the presented resources, the following implementation will be described:

• Using the Zabbix functionality, a command is sent to turn on the relay on the controller, which turns off the stationary power supply to the UPS, forcing it to switch to battery operation. Thus, we fix the readings of the voltage drop and the operating time of the barcode from the battery. After the battery is completely discharged, the power supply will be lost and the relay will turn off, and the stationary power supply will be restored. In the future, the return of power supply at the minimum voltage threshold mark on the battery, this will be possible with an individual approach.

Having parameters:

1. – voltage drop amplitude

2. – operating time of the SC from the battery

3. – circuit current (according to the documentation for the bar code)

Based on these data, we calculate the actual capacity of the battery, and also fix the operating time of the barcode from the battery. All this in automatic or manual mode with display on the network map and signaling in case of a critical state of the battery, as well as generating reports, that is, we get all the possible and necessary functionality of the Zabbix system. About how it was, in this article.

Let’s start in order.

There is a controller:

Controller “UMS-M”

With extension module P21X3

It has SNMPv1 on board, I would like to use a more modern version of the protocol and a web interface, but we work with what we have. Let’s skip the nuances of the firmware and settings, since the manufacturer helps to solve these issues and without it, no way.

Watching SNMP

Here we are interested in two inputs and the state of the relay

. We connect the 220V shutdown relay to the dry contact of the controller to break the voltage supply to it with the command:

snmpset -v 1 -c MIRADA $ip 1.3.6.1.4.1.41069.3.0.X.0.1.0i D

where:

X = output index 0 … 3

D = 0 – turn off the output relay, 1 – turn on

Checking the response and status with a query:

snmpget -v1 -c MIRADA $ip 1.3.6.1.4.1.41069.3.0.0.0.1.0

We get the following response:

– the contact is on, which means that the relay is energized, and it opens the power supply contact to the SC.

As you can see in the photo, the relay is powered from the consumer network and is opened by the controller contact, which, when a command is sent, closes the circuit, power is supplied to the relay, which opens the power supply, if the consumer network is lost (i.e., the battery is discharged), the relay switches to the open state, the controller reboots and returns the contact’s default value of open. This is done in order to fix the discharge cycle and not lose the SC.

We connect to the unified input of the battery through a resistor divider calculated by the formula

We form the obtained data into a table, where we compare the readings of the voltage difference using a laboratory power supply for further interpretation in the readings system and the formation of a graph.

The grid step is visible and the multiplier is understandable.

We go to Zabbix and make a connection with the controller via the SNMP protocol using an agent and create a host.

We create a data element and check the received data. We refer to the mapping table and set the custom multiplier in the data element preprocessing to 20 for the usual display of data.

We assemble a bench instance, send a command to the relay and create a graph based on the data element

We see a downward voltage drop.

We create a trigger called DISCHARGE to control the status of the UPS. That is, if the voltage drops, then the external power supply is gone and the UPS is running on battery power. What the trigger will signal on the UPS itself. In this example, SKAT -V.24DC-18 was used. 5000.

We add an element to the network map as a trigger for indication.

At this stage

And now dances with a tambourine begin). It is necessary to start the battery measurement and at the same time fix the end of the measurement, but since the fixation will be built on the basis of the state of the relay, which we learn upon the SNMP request, the trigger will not help us here – there are constant packets in the network and the trigger will not be able to fix and convert the relay operating time.

The solution is to write a Bash script that will be launched through the Zabbix functionality, supporting the macros of this system. What gives us a universal tool for testing any SC using one script, the ability to automate and plan measurements.

Thanks to the {HOST.CONN} macro, we pass the value of the address of the $ip variable to a file (created if it does not exist) with the name as the address of the device under test. The value of the controller contact is written to this file and checked every 200 seconds until $4 changes to 0 i.e. the relay will return to the off state. The script execution time is also recorded in the TIME$ip file in seconds.

In the while loop, you can replace the request for the value of the unified input by setting the threshold voltage on the battery before shutting down the UPS if you cannot allow a short-term loss of communication in the form of a reboot of the equipment. An element of an individual approach, as mentioned earlier.

We return to Zabbix and create a data element in the MIRADA connection node that reads the file, where the state of the relay is recorded:

We do preprocessing to get the value 0 or 1.

Add a trigger based on this item

Now running the script:

Now it is necessary to compare the data and build an alarm system with information about the state of the battery. To do this, we will create a local network node

Data element that reads the contents of the TIME file, in which the script execution time is in seconds.

And we will bind triggers to it, each of which fires in its own value range:

And we add this element to the network map, the measurements of the bench SC show the average value, taking into account a pause in the script of 200 seconds and rounding off the operating time from the battery with an error of 20 minutes / 0.2 Ah.

Conclusion

We received a universal tool for monitoring the state of batteries in perimeter switching cabinets with the prospect of development. For a more critical information infrastructure, as previously mentioned, a more individual approach is required. At this stage, and having current data using a system of dependent triggers, as well as the ability to work with a network map, a more complete network map with the necessary signaling and reporting will be developed. Pro proactive local network protection system using multi-agent segmentation will be in the second part.