Monitoring Die S.USV

  • Einleitung
    (Zurück zum Inhaltsverzeichnis)
    Die S.USV (hier die advanced) ist relativ einfach auszulesen.
    Alle wichtigen Werte kann hier als reinen Zahlenwert bekommen.
    Auf die Real Time Clock wird hier nicht weiter eingegangen.
    Es handelt sich dabei um eine DS1307, die man leider nicht abschalten kann.
    Voraussetzung ist, das SNMP, MRTG und die S.USV bereits eingerichtet sind.


    Insgesamt kann man von der S.USV 5 Werte bekommen, die mit der angehängten "0 " als reiner Zahlenwert zurückgegeben wird.

    • vin 0 Auslesen der Eingangsspannung
    • pwrext 0 Auslesen des externen Stromverbrauchs.
    • pwrbat 0 Auslesen des Stromverbrauchs der Batterie
    • capbat 0 Auslesen der Batteriespannung und der Restkapazität

    Auch hier wird die S.USV alle 5 min mit einem Bash-Script mit Hilfe von Cron ausgelesen und in Einzeldateien in /tmp hinterlegt.
    Das Auslesen der S.USV auf dem Client
    mittels eines (sehr) einfachen Bashscript

    Code
    1. sudo vi /usr/local/bin/SUSV



    Die auskommentierten Zeilen sind nur fürs Debuggen.
    Das Script ist nicht sehr einfallsreich, funktioniert aber bei mir.
    Nicht vergessen ausführbar machen:

    Code
    1. sudo chmod 0755 /usr/local/bin/SUSV


    Die Aufgabe für CRON

    Code
    1. sudo vi /etc/cron.d/SUSV


    und dem Inhalt:

    Code
    1. */5 * * * * root if [ -x /usr/local/bin/SUSV ] ; then /usr/local/bin/SUSV ; fi


    Das erzeugt dann alle 5 min folgende Dateien in /tmp:

    Code
    1. -rw-r--r-- 1 root root 7 Apr 23 01:15 SUSV_CAPBAT.snmp
    2. -rw-r--r-- 1 root root 31 Apr 23 01:15 susv_data.txt
    3. -rw-r--r-- 1 root root 7 Apr 23 01:15 SUSV_PWRBAT.snmp
    4. -rw-r--r-- 1 root root 7 Apr 23 01:15 SUSV_PWREXT.snmp
    5. -rw-r--r-- 1 root root 8 Apr 23 01:15 SUSV_UBAT.snmp
    6. -rw-r--r-- 1 root root 8 Apr 23 01:15 SUSV_VIN.snmp


    Alles mit der Endung .snmp wird mittels der nachfolgenden Scripts ausgelesen:


    Die Scripte für SNMP

    Code
    1. sudo vi /usr/local/bin/snmp-susv-ubat.sh


    Shell-Script
    1. #!/bin/bash
    2. tmp=`cat /tmp/SUSV_UBAT.snmp`
    3. echo .1.3.6.1.2.1.25.1.20
    4. echo gauge
    5. echo $tmp
    6. exit 0


    Code
    1. sudo vi /usr/local/bin/snmp-susv-vin.sh


    Shell-Script
    1. #!/bin/bash
    2. tmp=`cat /tmp/SUSV_VIN.snmp`
    3. echo .1.3.6.1.2.1.25.1.23
    4. echo gauge
    5. echo $tmp
    6. exit 0


    Code
    1. sudo vi /usr/local/bin/snmp-susv-pwrext.sh


    Shell-Script
    1. #!/bin/bash
    2. tmp=`cat /tmp/SUSV_PWREXT.snmp`
    3. echo .1.3.6.1.2.1.25.1.24
    4. echo gauge
    5. echo $tmp
    6. exit 0


    Code
    1. sudo vi /usr/local/bin/snmp-susv-pwrbat.sh


    Shell-Script
    1. #!/bin/bash
    2. tmp=`cat /tmp/SUSV_PWRBAT.snmp`
    3. echo .1.3.6.1.2.1.25.1.25
    4. echo gauge
    5. echo $tmp
    6. exit 0


    Code
    1. sudo vi /usr/local/bin/snmp-susv-capbat.sh


    Shell-Script
    1. #!/bin/bash
    2. tmp=`cat /tmp/SUSV_CAPBAT.snmp`
    3. echo .1.3.6.1.2.1.25.1.26
    4. echo gauge
    5. echo $tmp
    6. exit 0


    Anpassung der snmpd.conf

    Code
    1. sudo vi /etc/snmp/snmpd.conf


    Code
    1. pass .1.3.6.1.2.1.25.1.23 /bin/bash /usr/local/bin/snmp-susv-vin.sh
    2. pass .1.3.6.1.2.1.25.1.24 /bin/bash /usr/local/bin/snmp-susv-pwrext.sh
    3. pass .1.3.6.1.2.1.25.1.25 /bin/bash /usr/local/bin/snmp-susv-pwrbat.sh
    4. pass .1.3.6.1.2.1.25.1.26 /bin/bash /usr/local/bin/snmp-susv-capbat.sh
    5. pass .1.3.6.1.2.1.25.1.20 /bin/bash /usr/local/bin/snmp-susv-ubat.sh


    und den SNMPD neustarten

    Code
    1. sudo service snmpd restart


    Nun sollte bei einem Test folgendes herauskommen (IP und "public" anpassen):

    Code
    1. pi@raspiXX:~ $ snmpget -v1 -c public 192.168.2.14 .1.3.6.1.2.1.25.1.20
    2. iso.3.6.1.2.1.25.1.20 = Gauge32: 4200


    Der Serverteil mit der MRTG-Anpassung

    Code
    1. sudo vi /etc/mrtg/raspi14_mrtg.cfg


    Hier wird die Konfiguration um diesen Teil ergänzt:


    Ich habe hier die Ströme I_ext und I_batt zusammengefasst.
    Die Include-Dateien

    Code
    1. sudo vi /etc/mrtg/raspi-S.USV_-_U_rasp.inc



    Code
    1. sudo vi /etc/mrtg/raspi-S.USV_-_I_ext.inc



    Code
    1. sudo vi /etc/mrtg/raspi-S.USV_-_U_batt.inc



    Code
    1. /etc/mrtg/raspi-S.USV_-_CAP_batt.inc



    Dann noch ein neues Indexfile erstellen:

    Code
    1. sudo indexmaker --output=/var/www/mrtg/raspi14/index.html /etc/mrtg/raspi14_mrtg.cfg


    Und 10 - 15 min warten bis sich die ersten Diagramme aus der rechten Ecke trauen

    Jahrelang wurde gesagt: Das geht nicht, das gibt es nicht und das war schon immer so.
    Und dann kam einer, der wusste das nicht, und hat es dann einfach gemacht.

    Meine Projekte

    Avatar


    Edited once, last by Jürgen Böhm ().

  • Nachdem mir letzte Woche aufgefallen war, das sich meine S.USV nicht mehr auslesen ließ,
    untersuchte ich das Phänomen etwas näher.


    Sehr bald stieß ich auf folgende Fehlermeldung:

    Code
    1. /opt/susvd/susv -capbat
    2. Unable to determine hardware version. I see: Hardware   : BCM2835
    3. ,
    4.  - expecting BCM2708 or BCM2709. Please report this to projects@drogon.net


    Eine Suche bei Google ergab, das die Soft- und Firmware 1.32 nur bis zur
    Kernelversion V4.4.50-v7+ funktioniert.
    Quelle (3. Antwort):
    https://forum.fhem.de/index.php?topic=68487.0


    Mittlerweile habe ich hier:

    Code
    1. pi@raspi14 /opt/susvd $ uname -a
    2. Linux raspi14 4.9.24-v7+ #993 SMP Wed Apr 26 18:01:23 BST 2017 armv7l GNU/Linux


    im Rahmen eines normalen Updates erhalten.


    Daraufhin habe ich Soft- und Firmware (2.20/2.30) upgedatet und die S.USV ließ sich
    auch wieder auslesen.
    Aber nicht lange, spätestens nach der 2. oder 3. Statusabfrage hatte
    die S.USV wohl die Schnauze voll und entfernte selbständig die eigene I2C-Bus Adresse.
    Nach der vollständigen Trennung von aller Stromversorgungsquellen
    funktionierte die S.USV wieder, aber nur für 2-3 Statusabfragen.



    Zudem sind Messwerte und die Firmwareversionen sowie das Model vollkommen daneben.
    Eine kleine Sammlung der Firmwareversionen:

    Code
    1. * Firmware Version: 2.30       *
    2. * Firmware Version: 0.0       *
    3. * Firmware Version: 255.3       *
    4. * Firmware Version: 233.8       *


    Lediglich die Erste stimmt.


    Die WiringPi library hat hier folgende Version:
    wiringpi/stable,now 2.44 armhf [installiert]


    Was noch schlimmer ist, zieht man die Stromversorgung ab, ist der Rasperry (ganz) aus.
    D.h. die S.USV funktioniert so nicht mehr.


    Falls jemand noch ein paar Ideen hat...


    MfG


    Jürgen


    P.S.: Ich habe mal eine Email an: projects@drogon.net geschickt, mal sehen ob jemand antwortet.
    Er hatte geantwortet, nur damit hat er nichts zu tun. Sorry mein Fehler.


    Edit: Fiptehler, P.S. hinzugefügt und ergänzt.

    Jahrelang wurde gesagt: Das geht nicht, das gibt es nicht und das war schon immer so.
    Und dann kam einer, der wusste das nicht, und hat es dann einfach gemacht.

    Meine Projekte

    Avatar


    Edited once, last by Jürgen Böhm ().


  • Ich hatte gestern noch an den Support von S.USV geschrieben und bekam
    heute(!) eine Beta-Version (1.33beta) per Email zugeschickt.
    Seitdem tut die USV wieder das was sie soll.
    Great Work, Danke an das S.USV-Team


    MfG


    Jürgen

    Jahrelang wurde gesagt: Das geht nicht, das gibt es nicht und das war schon immer so.
    Und dann kam einer, der wusste das nicht, und hat es dann einfach gemacht.

    Meine Projekte

    Avatar