Monitoring Die S.USV

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • 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
    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
    sudo chmod 0755 /usr/local/bin/SUSV


    Die Aufgabe für CRON

    Code
    sudo vi /etc/cron.d/SUSV


    und dem Inhalt:

    Code
    */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
    -rw-r--r-- 1 root root    7 Apr 23 01:15 SUSV_CAPBAT.snmp
    -rw-r--r-- 1 root root   31 Apr 23 01:15 susv_data.txt
    -rw-r--r-- 1 root root    7 Apr 23 01:15 SUSV_PWRBAT.snmp
    -rw-r--r-- 1 root root    7 Apr 23 01:15 SUSV_PWREXT.snmp
    -rw-r--r-- 1 root root    8 Apr 23 01:15 SUSV_UBAT.snmp
    -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
    sudo vi /usr/local/bin/snmp-susv-ubat.sh
    Bash
    #!/bin/bash
    tmp=`cat /tmp/SUSV_UBAT.snmp`
    echo .1.3.6.1.2.1.25.1.20
    echo gauge
    echo $tmp
    exit 0
    Code
    sudo vi /usr/local/bin/snmp-susv-vin.sh
    Bash
    #!/bin/bash
    tmp=`cat /tmp/SUSV_VIN.snmp`
    echo .1.3.6.1.2.1.25.1.23
    echo gauge
    echo $tmp
    exit 0
    Code
    sudo vi /usr/local/bin/snmp-susv-pwrext.sh
    Bash
    #!/bin/bash
    tmp=`cat /tmp/SUSV_PWREXT.snmp`
    echo .1.3.6.1.2.1.25.1.24
    echo gauge
    echo $tmp
    exit 0
    Code
    sudo vi /usr/local/bin/snmp-susv-pwrbat.sh
    Bash
    #!/bin/bash
    tmp=`cat /tmp/SUSV_PWRBAT.snmp`
    echo .1.3.6.1.2.1.25.1.25
    echo gauge
    echo $tmp
    exit 0
    Code
    sudo vi /usr/local/bin/snmp-susv-capbat.sh
    Bash
    #!/bin/bash
    tmp=`cat /tmp/SUSV_CAPBAT.snmp`
    echo .1.3.6.1.2.1.25.1.26
    echo gauge
    echo $tmp
    exit 0


    Anpassung der snmpd.conf

    Code
    sudo vi /etc/snmp/snmpd.conf
    Code
    pass .1.3.6.1.2.1.25.1.23  /bin/bash /usr/local/bin/snmp-susv-vin.sh
    pass .1.3.6.1.2.1.25.1.24 /bin/bash /usr/local/bin/snmp-susv-pwrext.sh
    pass .1.3.6.1.2.1.25.1.25 /bin/bash /usr/local/bin/snmp-susv-pwrbat.sh
    pass .1.3.6.1.2.1.25.1.26 /bin/bash /usr/local/bin/snmp-susv-capbat.sh
    pass .1.3.6.1.2.1.25.1.20 /bin/bash /usr/local/bin/snmp-susv-ubat.sh


    und den SNMPD neustarten

    Code
    sudo service snmpd restart


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

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


    Der Serverteil mit der MRTG-Anpassung

    Code
    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
    sudo vi /etc/mrtg/raspi-S.USV_-_U_rasp.inc
    Code
    sudo vi /etc/mrtg/raspi-S.USV_-_I_ext.inc
    Code
    sudo vi /etc/mrtg/raspi-S.USV_-_U_batt.inc
    Code
    /etc/mrtg/raspi-S.USV_-_CAP_batt.inc


    Dann noch ein neues Indexfile erstellen:

    Code
    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

  • 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
    /opt/susvd/susv -capbat
    Unable to determine hardware version. I see: Hardware   : BCM2835
    ,
     - 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
    pi@raspi14 /opt/susvd $ uname -a
    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
    * Firmware Version: 2.30       *
    * Firmware Version: 0.0       *
    * Firmware Version: 255.3       *
    * 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.


  • 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
    /opt/susvd/susv -capbat
    Unable to determine hardware version. I see: Hardware   : BCM2835
    ,
     - 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

    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

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!