Pi USV+ Monitoring Script

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Hallo Zusammen,

    nachdem die Pi USV+ immer wieder und gerne mal zickig ist habe ich mir mal Gedanken über ein besseres Monitoring gemacht. Heraus kam, dass man die internen Register der Pi USV+ mit Python auslesen kann. Damit das funktioniert muss die python-smbus Library installiert sein.

    Also - falls die python-smbus Library noch nicht vorhanden ist:

    Code
    sudo apt-get install python-smbus

    Dann brauchen wir eine neue Datei 'piusv.py'

    Code
    sudo nano piusv.py

    und bescheren ihr diesen Inhalt:

    Nicht vergessen die Adresse eurer Pi USV+ zu prüfen und die Datei zu speichern!

    Ein guter Aufenthaltsort für das Skript ist '/usr/local/bin', daher:

    Code
    sudo mv piusv.py /usr/local/bin/
    sudo chmod 0755 /usr/local/bin/piusv.py


    Ausgabebeispiele:

    Code
    sudo python /usr/local/bin/piusv.py version
    v0.1.6   klu
    Code
    sudo python piusv.py all
    9 | 4.178 U_Batt (V) | 0.261 I_Rasp (A) | 5.083 U_Rasp (V) | 5.089 U_USB (V) | 0.000 U_ext (V)
    StatusByte Bedeutung
    0000.0001 Spannungsversorgung von Micro-USB-Buchse
    0000.1000 Akku wird geladen


    Erklärung zur Ausgabe:

    Bei dem ersten Wert handelt es sich um ein StatusByte, das man bitweise betrachten muss.

    Bit 0 Spannungsversorgung von der Micro-USB-Buchse
    Bit 1 Spannungsversorgung von Uext
    Bit 2 (Zu?) niedrige Akkuspannung
    Bit 3 Akku wird geladen
    Bit 4 (?)
    Bit 5 Taster S1 gedrückt
    Bit 6 (?)
    Bit 7 (?)

    Die nachfolgenden Werte sind:

    U_Batt (V) Akku-Spannung
    I_Rasp (A) Strom, den der Raspberry braucht (Ohne USV)
    U_Rasp (V) Spannung, mit der der Raspberry arbeitet
    U_USB (V) Spannung, die an der Micro-USB Buchse anliegt
    U_ext (V) Spannung, die an der externen Stromversorgung anliegt
    Darunter ist nur die Übersetzung des Statusbytes.

    Folgende Optionen werden ausgewertet:

    python piusv.py all : Wie die Option sagt, alles was es gibt
    python piusv.py status : Nur die Auswertung des Statusbyte
    python piusv.py version : Die Firmwareversion
    python piusv.py log : Schreibt bei jedem Aufruf (als root!) eine Zeile in /var/log/PIUSV.log

    Für eine weitere Auswertung durch Scripte:

    python piusv.py U_Batt : Spannung am Akku
    python piusv.py I_Rasp : Stromaufnahme des Raspberrys
    python piusv.py U_Rasp : Spannungsversorgung des Raspberrys
    python piusv.py U_USB : Spannung an der USB-Buchse
    python piusv.py U_ext : Spannung am externen Anschluss


    Mir bekannte Fehler:

    Mit dem StatusByte (bei Versorgung über den Widerange Power Input der Pi USV+) scheint es noch Probleme zu geben. Selbst wenn ich hier ein 12V Netzteil anstecke gibt die Pi USV+ als Status stur '0000.0001 - Spannungsversorgung von der Micro-USB-Buchse' zurück.

    Code
    sudo python /usr/local/bin/piusv.py all
    9 | 4.099 U_Batt (V) | 0.566 I_Rasp (A) | 5.003 U_Rasp (V) | 0.849 U_USB  (V) | 12.199 U_ext  (V)
    StatusByte Bedeutung
    0000.0001 Spannungsversorgung von Micro-USB-Buchse
    0000.1000 Akku wird geladen


    Viel Spass allen Pi USV+ Besitzern!

    Einmal editiert, zuletzt von doing (10. Oktober 2016 um 22:55)

  • Besser als meine Version, sie war doch (hmm) etwas rudimentärer.

    Nachtrag zum Statusbyte:
    Bit 0 Spannungsversorgung von der Micro-USB-Buchse
    Bit 1 Spannungsversorgung von Uext

    funktioniert wohl zur Zeit nicht.

    MfG

    Jürgen

  • doing: Ein paar Verbesserungsvorschläge:

    - Normalerweise verschachtelt man Funktionen nicht, also nicht so wie du es gemacht hast. In der main() handelt man alles ab aber die anderen Funktionen sollten ausserhalb stehen.

    - exit() nutzt man nur in der interaktiven Python Konsole, in Scripts sollte man sys.exit() nutzen => http://stackoverflow.com/a/6501134 .. Ein Exit Code von -1 ist auch eher untypisch ;) Normalerweise nutzt man 0 bis 127

    - Den Funktionen kannst du ruhig längere Funktionsnamen geben, wie U_Batt() zum Beispiel ;)

    - Netter Trick mit den "par" Lists, aber wieso nutzt du nicht das 'return' ? Also wirklich verwenden nicht nur drin stehn haben ;)

    - Eventuell wäre es sogar besser dein Script als Klasse umzubauen


    Also mein erster Vorschlag wäre: http://codepad.org/0owL0MpS
    Da ist eigentlich kaum was verändert...

    Und der zweite Vorschlag wäre: http://codepad.org/ikK87xgp
    (ungetestet!)


    Da ich keine PiUSV besitze kann ich zum Rest nichts sagen - schaut aber ansonsten gut aus :thumbs1:

  • Jürgen
    Den Fehler mit dem StatusByte hatte ich versucht unter 'Mir bekannte Fehler' zum Ausdruck zu bringen... :)

    meigrafd
    Ja klar - schöner machen kann man das noch... dazu hatte ich aber bisher keinen Anlass, da das Gefummel aus der internen Not mit meinem Pi USV+ Vorserienmodell (tatsächlich von CW2!) entstanden ist... Aber danke für deine Mühe!

    Version 1 - Mit den aus dem main() Aufruf rausgeworfenen Funktionen - lief wie erwartet auf Anhieb.
    Version 2 - Das Ganze mit Klasse - lief nicht... da hast du wohl nicht genau auf init() und die Address geschaut. Auch hast du meinen 'Trick' weggelassen ohne den Rest anzupassen.

    Jetzt ist der 'Trick' erstmal wieder drin und das Pi USV + Monitoring Script läuft auch mit Klasse klasse... :thumbs1:

  • Danke für das Script und die gute Dokumentation. Ich werde das baldmöglichst testen und würde es gerne zum plugin für das smarthome.py framework erweitern, wenn das für Dich OK ist.

    Folgende Fragen habe ich noch:

    • Du schreibst, man soll die Adresse seiner PIUSV überprüfen. Ist diese nicht fest auf 0x18 verdrahtet? Ich hätte sie nämlich wegen des Adresskonflikts mit einem anderen Erweiterungsmodul gerne geändert.
    • ich habe vergeblich nach dem Quellcode von piupsmon V0.9 gesucht. Gibt es den zum Download und kannst Du mir einen Tipp geben, wo ich ihn finde?


    Danke und Gruß
    Wolfram

  • Hallo Wolfram,

    mit dem passenden Link zur Quelle des Scripts bzw. mit den passenden Credits in deinem Plugin habe ich nichts dagegen, wenn du das Script als Grundlage nimmst.

    Zur Adresse: Je nach Pi USV / Firmware Version kann es sein, dass du eine Pi USV erwischt hast, die sich auf einer anderen Adresse meldet (bei den Ersten war das auch gerne mal die 0x30). Den piupsmon v0.9 habe ich leider auch nur als komprimiertes Debian Paket vorliegen.

    Grüsse
    Sebastian


  • Hallo Wolfram,

    mit dem passenden Link zur Quelle des Scripts bzw. mit den passenden Credits in deinem Plugin habe ich nichts dagegen, wenn du das Script als Grundlage nimmst.

    Zur Adresse: Je nach Pi USV / Firmware Version kann es sein, dass du eine Pi USV erwischt hast, die sich auf einer anderen Adresse meldet (bei den Ersten war das auch gerne mal die 0x30). Den piupsmon v0.9 habe ich leider auch nur als komprimiertes Debian Paket vorliegen.

    Grüsse
    Sebastian

    Der aktuellste piupsmon findet sich bei Reichelt, nach piusv suchen.
    In der Dokumentation von CW2 ist 0x30 angegeben, in der von Ritter 0x18.
    In den Beschreibungen von Pollin, Reichelt und Raspiprojekt ist immer noch 0x30 angegeben, das stimmt nicht!
    Meine beiden PIUSV+ haben 0x18.
    Die I2C-Adresse kann man ändern, aber nur bei Fa. Ritter.
    Ich hatte die PIUSV+ schon einmal mit der Adresse 0x15 gesehen, aber nur einmal.

    MfG

    Jürgen

    P.S.: Ich hatte die Doku mit piupsmon v0.9 schon einmal hier im Forum eingestellt, sie wurde aber wieder gelöscht.
    Fa. Ritter hatte nichts dagegen das sie hier auftaucht.

    Edit: Der Quellcode von piusvmon steht leider nicht zur Verfügung.

  • Wenn es kein Quellcode gibt betrachte ich das als nicht vertrauenswürdig, da das gerade in der Linuxwelt ein NoGo ist den Quellcode nicht mit zu veröffentlichen - wer weiß was das Programm sonst noch macht oder welche Schwachstellen es evtl. beinhaltet oder an welchen Stellen es sogar noch optimiert werden könnte etc. Wer aus sowas eher trivialem nen Geheimnis macht schaufelt sich sein eigenes Grab.


  • Wenn es kein Quellcode gibt betrachte ich das als nicht vertrauenswürdig, da das gerade in der Linuxwelt ein NoGo ist den Quellcode nicht mit zu veröffentlichen - wer weiß was das Programm sonst noch macht oder welche Schwachstellen es evtl. beinhaltet oder an welchen Stellen es sogar noch optimiert werden könnte etc. Wer aus sowas eher trivialem nen Geheimnis macht schaufelt sich sein eigenes Grab.

    Ist schon klar, war aber nicht meine Entscheidung, angeregt hatte ich es.
    Ich finde es schon bemerkenswert, das die PIUSV+ ohne Hilfe von Ritter geknackt wurde.
    doing lag sogar bei der Statusbyteauswertung weitgehend richtig.

    Ich hatte schon so etwas ähnliches, durfte es aber nicht veröffentlichen, leider.
    Denn es war mit Hilfe von Ritter entstanden.

    Leider gibt bei der S.USV auch keinen Quellcode, trotzdem setze ich sie ein.

    MfG

    Jürgen

    Edit: Fipptehler

  • Hallo Jürgen,

    wenn ich jetzt noch dahinter steigen würde, warum das Statusbyte bei Stromversorgung über den Wide Range Input der RPi USV+ falsch gesetzt wird... ich vermute ja einen BUG in der Firmware. Ich muss wohl mal bei Ritter Elektronik anfragen...


  • Hallo Jürgen,

    wenn ich jetzt noch dahinter steigen würde, warum das Statusbyte bei Stromversorgung über den Wide Range Input der RPi USV+ falsch gesetzt wird... ich vermute ja einen BUG in der Firmware. Ich muss wohl mal bei Ritter Elektronik anfragen...

    Hatte ich dem Entwickler schonmal gefragt/gesagt, aber noch keine Antwort bekommen.
    Als Beispiel hatte ich dabei die S.USV genannt, die handhaben es wesentlich besser.

    Die Entwickler bei Ritter arbeiten projektbezogen, d.h. sie bekommen eine Aufgabe und lösen sie.
    Danach ist das Projekt abgeschlossen und dann bekommen sie ein anderes Projekt.
    Das kann auch ein Update eines alten Projektes sein, aber die PIUSV+ ist (noch?) nicht an der Reihe.

    MfG

    Jürgen

  • Hallo Zusammen,

    ich bin durch Zufall auf dieses Thema aufmerksam geworden, da ich gerade selbst versuche die PI USV+ mit FHEM abzufragen.

    Unteranderen hatte ich diesbezüglich auch die Firma Ritter Elektronik angeschrieben.
    Und ich habe folgende Antworten bekommen (siehe Anhang)
    Vielleicht helfen diese Infos ja teilweise weiter.


    Bit 4 ist wenn ich es richtig verstehe : Akku geladen (voll)

    Leider bin ich nicht der Programmierer und kenne mit somit nicht mit PHP oder der genauen Abfrage der I2C-Schnittstelle aus.
    Aber im PDF sind vielleicht nützliche Hinweise.

    Gruß

    Aherby


  • Hallo Zusammen,


    Unteranderen hatte ich diesbezüglich auch die Firma Ritter Elektronik angeschrieben.
    Und ich habe folgende Antworten bekommen (siehe Anhang)

    Fa. Ritter hat jetzt eine Email-Adresse für die PIUSV+ eingerichtet:

    Piusv_support(at)ritter.info

    Fehlermeldung und Anfragen können dort gestellt werden.

    MfG

    Jürgen

    P.S.: Dann klappt es vielleicht auch mit einem Update.

  • Hallo Zusammen,

    ich habe das Monitoring Script von Doing um eine Option (SNMP-Abfrage) erweitert:

    Warum?
    Nun, hier werden die Parameter der PIUSV+ in einem Rutsch ausgelesen und in /tmp als Einzeldateien abgelegt.
    Die Alternative wären 5 Aufrufe mit jeweils dem kompletten Auslesen der Register.

    Das ganze kann man in /etc/cron.d/piusv mit dem Inhalt:

    Code
    */5 *   * * *   root    python /usr/local/bin/piusv_2.py snmp 2>&1


    einstellen. Danach hat man alle 5 min neue Werte in mA bzw. in mV.

    Ich nutze diese Option zum Auslesen mittels SNMP und erzeuge dann mit MRTG die entsprechenden Diagramme.

    Das dazugehörige Tutorial befindet sich noch in Arbeit -> coming soon

    MfG

    Jürgen

  • Ich nutze diese Option zum Auslesen mittels SNMP und erzeuge dann mit MRTG die entsprechenden Diagramme.

    Das dazugehörige Tutorial befindet sich noch in Arbeit -> coming soon

    Ab heute hier zu finden: Inhaltsverzeichnis Monitoring

    MfG

    Jürgen

    Edit: Link angepasst

  • An die Bastler unter euch

    Bei der PIUSV+ ist der Ladestrom auf 100mA begrenzt, dabei kann der Ladechip max.(!) 500mA Ladestrom liefern.
    Geregelt wird das durch den Widerstand R4, den ich auf diesem Bild rot markiert habe:

    Eingelötet wird bei Ritter Elektronik ein 10kOhm-Widerstand, laut dieser Tabelle:

    sollte der Ladestrom bei 2kOhm dann 500mA betragen.

    Das Ganze hat aber einen gewaltigen Haken, wenn jemand diesen Widerstand ändert, ist die Garantie weg.

    Und der kleinere Haken: Ich darf leider nicht verraten aus welchen Datenblatt ich die Tabelle kopiert habe ;(

    Sorry, es liegt nicht an mir

    Jürgen

  • ... vielen Dank für den Tip ! Garantie?!? Drauf ge*** ;)

    Gibt es eigentlich unterschiedliche Versionen? Ich habe einen v1.0 .... Am AVR umzu gibt es 1 x 6 (x21) und 1 x 4 (X_RS232...) unbestückte Pin's im 2.54 Raster. Der 6er- Block dürfte ICP sein, aber die 4 anderen? RS232 TTL is klar; aber wo für?

    Einmal editiert, zuletzt von HolyScene31423 (18. August 2017 um 22:57)

  • Hat etwas länger gedauert, aber ich hatte etwas zu tun...

    Code
    X21.1    GND
    X21.2    +5V_LOG
    X21.3    ATMEGA8-16AU  PIN 15 (MOSI/OC2) PB3
    X21.4    ATMEGA8-16AU  PIN 16 (MISO) PB4
    X21.5    ATMEGA8-16AU  PIN 17 (SCK) PB5
    X21.6    ATMEGA8-16AU  PIN RST über einen 0R(R79) an (/RESET) PC6
    X_RS232.1    +5V_LOG
    X_RS232.2    GND
    X_RS232.3    RXD ATMEGA8-16AU PIN 30 (RxD)PD0
    X_RS232.4    TXD ATMEGA8-16AU PIN 31 (TxD)PD1

    Das ist die Belegung der Pins, ich habe zwar Zugriff auf den Schaltplan,
    aber nicht auf das Programmiergerät. Und erst recht nicht auf die Firmware.

    Und nein, den Schaltplan möchte Fa. Ritter nicht veröffentlicht sehen, ich habe schon danach gefragt.

    MfG

    Jürgen

  • Super, vielen Dank ...

    ... naja, Schaltbild ist kein Problem. Da ist nicht all zu viel drauf, so das ein RevEng keine Probleme macht, sollte es mal notwendig werden. Im Moment tut er ja brav seinen Dienst, obwohl zwischendurch mal unmotiviert die Stati springen; da ist wohl das Timing nicht so ganz sauber...

    Code
    2017-08-23 20:16:27 [NOTICE] Shutdown timer: 1 / 300
    2017-08-23 20:16:27 [NOTICE] Status changed from 0 () to 1 (primary power)
    2017-08-23 20:20:31 [NOTICE] Status changed from 1 (primary power) to 0 ()
    2017-08-23 20:20:31 [NOTICE] Status changed from 0 () to 1 (primary power)
    2017-08-23 20:32:34 [NOTICE] Status changed from 1 (primary power) to 0 ()
    2017-08-23 20:32:34 [NOTICE] Shutdown timer: 1 / 300
    2017-08-23 20:32:35 [NOTICE] Status changed from 0 () to 1 (primary power)
    2017-08-23 22:46:24 [NOTICE] Status changed from 1 (primary power) to 0 ()
    2017-08-23 22:46:24 [NOTICE] Status changed from 0 () to 1 (primary power)

    ... wohlgemerkt quasi im IDLE; SSH tail (dafür) und auf dem System selber Anmeldebildschirm der GUI. Passiert also gerade nis auf dem Teil. Dennoch springt der wie o.a. immer hin und her... Komisch... Funktioniert aber ansonsten einwandfrei (neuer 830mAh Handy- Akku (aus der Hülle gepult))

  • Zitat


    Da ist nicht all zu viel drauf, so das ein RevEng keine Probleme macht


    Das Problem sind die ICs, oder weisst Du, von welchem Hersteller z.B. das Lade-IC ist?
    Ich habe es bei Tante Google mit der Bezeichnung nicht gefunden, nur der Schaltplan gab mir die Auskunft.
    Aber mit dem Schaltplan kannst Du ja mal dein Glück versuchen:

    Piusv_support(at)ritter.info

    MfG

    Jürgen

Jetzt mitmachen!

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