[Tutorial][PIUSV+] Alternative zu piupsmon-0.9.deb von CW2

  • (Zurück zum Inhaltsverzeichnis)

    Update: 21.12.2021

    Die alte Software der PIUSV+ von CW2 (piupsmon-0.9.deb) ist mittlerweile in die Jahre gekommen

    und läuft auf Buster/Bullseye unter 64Bit nicht mehr.

    Aber es gibt eine Alternative für die Monitor-Software der PIUSV+.

    Das eröffnet die Möglichkeit, die PIUSV+ weiter zu nutzen.

    Allerdings gibt es die Software nur als Sourcecode.

    Aber nicht abschrecken lassen, es ist leichter als gedacht.

    Am besten man erstellt sich erstmal einen Ordner im Homeverzeichnis für die Sourcen:

    mkdir src und wechselt mit cd src dorthin,

    Die Sourcen findet man hier: https://github.com/dehapama/piupsmonitor-raspberrypi

    Nach dem Aufruf von git clone https://github.com/dehapama/piupsmonitor-raspberrypi.git

    findet man folgenden Ordner vor: piupsmonitor-raspberrypi

    Dort findet man im Verzeichnis src den Sourcecode.

    Zum compilieren benötigt man noch eine Library die man mit

    sudo apt install libi2c-dev installieren muss.

    Ab hier bin ich, im Gegensatz zum README.md, einen etwas anderen Weg gegangen.

    1. Compilieren

    Das sind nur 3 Warnungen, das Programm funktioniert trotzdem.

    2. Konfiguration

    Code
    cd ..
    sudo cp -a etc/piupsmonitor /etc

    Wenn man seine Konfiguration weiter nutzen möchte, kann man mit

    sudo cp /etc/piupsmon/piupsmon.conf /etc/piupsmonitor/piupsmonitor.conf

    seine eigene Konfiguration einfach kopieren, sie sind bis auf den Namen kompatibel.

    Und der neue Ordner ist Voraussetzung für den ersten Test bzw. den weiteren Betrieb.

    3. Erster Test

    Erstmal vergewissern, das der LogLevel in /etc/piupsmonitor/piupsmonitor.conf auf LogLevel=NOTICE steht.

    Dann ein:

    Code
    sudo src/piupsmonitor
    Opening device... OK
    2021-12-21 08:38:09 [NOTICE] Redirection log messages to /var/log/piupsmonitor.log

    Sieht schonmal gut aus, Abbruch mit ^C und in der Log-Datei sollte dann das stehen:

    Zu dem Eintrag ShutdownCmd: /usr/local/bin/allOff.sh komme ich später noch.

    Jetzt kann man das Programm an seinen Bestimmungsort kopieren:

    sudo cp src/piupsmonitor /usr/sbin/


    4. Einrichten systemd

    Auch hier bin ich einen anderen Weg gegangen:

    sudo cp etc/systemd/system/piupsmonitor*.service /lib/systemd/system/

    Danach kann man wieder dem README.md folgen:

    Code
    sudo systemctl daemon-reload
    sudo systemctl enable piupsmonitor.service
    sudo systemctl start piupsmonitor.service
    sudo systemctl enable piupsmonitor-poweroff.service

    Lt. dem README sollte man noch die Übertragungsrate des I2C--Busses in der /boot/config.txt heruntersetzen.

    dtparam=i2c_baudrate=40000

    Nach einem reboot sollte das Monitorprogramm laufen. Überprüfen kann man das mit:

    Jetzt kann man mal probehalber die Versorgungsspannung unterbrechen,

    der Raspberry sollte (mit Akku) weiterlaufen. Die rote LED auf der PIUSV+ sollte jetzt blinken.

    In der Log-Datei erscheinen dann diese Einträge:

    Das hektische Blinken der gelben LED nach dem wiedereinschalten der Betriebsspannung zeigt an, das der AKKU wieder geladen wird.

    5. Die Zeile ShutdownCmd: /usr/local/bin/allOff.sh

    Es handelt sich hier um ein kleines Bash-Script das die PIUSV+ komplett ausschaltet.

    Wenn man den Raspberry herunterfährt geht zwar der Raspberry aus, die PIUSV+ bleibt aber an.

    Ist keine gute Idee wenn man den Raspberry im Gartenhäuschen oder im Auto betreibt

    denn dann saugt die PIUSV+ den Akku leer.

    Um das zu verhindern, kann man mit Hilfe dieses Scripts die PIUSV+ komplett abschalten.

    Quelle: https://raspicarprojekt.de/showthread.php…id=6359#pid6359

    Hier nochmal zur Sicherheit, da das Projekt nicht weiterentwickelt wird.

    Dazu legen wir mit einem Texteditor die Datei mit diesem Inhalt an:

    Dann noch ein sudo chmod 0755 /usr/local/bin/allOff.sh

    Nach dem Herunterfahren des Raspberrys sollten die LEDs der PIUS+ noch

    ein paar Sekunden an sein und dann ausgehen

    Diese Anleitung endstand mit Hilfe eines 3B+ unter Bullseye64,

    unter Buster64 liess sich das Programm kompilieren, aber ich habe im Moment keinen RPi4B zum testen frei.

    Die Test hole ich aber noch nach. Oder Jemand Anderes mit einer PIUSV+

    MfG

    Jürgen

    Edit 01: Buster32 auf RPi4B-4G funktioniert, auch mit der Option: arm_64bit=1

    Edit 02: sudo systemctl status piupsmonitor.service korrigiert

  • [Tutorial][PIUSV+] Alternative zu piupsmon-0.9.deb von CW2? Schau mal ob du hier fündig wirst!

  • Moin,

    zu allererst einmal Danke für die Anleitung. Das Meiste davon funktioniert noch.

    Habe einen neuen Pi 4 mit Raspbian 64 Bit. Was bei mir leider nicht funktioniert ist das allOff.sh Script. Der Pi 4 leuchtet noch rot, sowie die USV mit roter LED und blinkender grüner LED.

    Eine Idee, wie ich das lösen kann?


    Vielen Dank


    LG

  • Was bei mir leider nicht funktioniert ist das allOff.sh Script.

    Wenn Du das über den piupsmonitor-poweroff.service laufen läßt, braucht man das Script nicht mehr.
    Es hat mittlerweile ein paar Updates gegeben.

    GitHub - dehapama/piupsmonitor-raspberrypi: Programm to monitor the PiUPS+ (PiUSV+) module for the Raspberry Pi
    Programm to monitor the PiUPS+ (PiUSV+) module for the Raspberry Pi - GitHub - dehapama/piupsmonitor-raspberrypi: Programm to monitor the PiUPS+ (PiUSV+)…
    github.com

    Hier ist noch eine Sammlung von Scripts, Software und Infos zu finden:

    GitHub - daq-tools/rpi-piusv: Python module for RPI USV+ Raspberry Pi - USV+
    Python module for RPI USV+ Raspberry Pi - USV+. Contribute to daq-tools/rpi-piusv development by creating an account on GitHub.
    github.com

    MfG

    Jürgen

  • Moin,

    Das komische ist, wenn ich diesen poweroff Dienst aktiviere, dann fährt mein Pi laufend von selbst runter, auch mit Stromversorgung an der USV.

    Musste den Dienst erst deaktivieren.

    Nachtrag:

    Hab den Fehler gefunden. Der Knopf an der USV war verklemmt und wurde daher immer gedrückt. Jetzt arbeitet alles wie es soll.


    LG

    Edited once, last by corin.corvus (March 25, 2024 at 10:38 PM).

  • Habe mich strikt an deine Anleitung gehalten.

    Ich hatte mich an die Anleitung dehampa gehalten. Meine PIUSVs laufen alle auf einem 3B.

    Getestet hatte ich den nur mal mit einem RPi5, aber die Kombi mochte sich nicht.
    Einen RPi4B hatte ich noch nicht probiert, aber es könnte sein, das die Spannung nicht reicht.

    Da gibt es aber einen Widerstand, den man ändern kann. Muss ich mal raussuchen.

    MfG

    Jürgen

    Edit: Ich habe das wg. des Kühlkörpers nicht getestet

  • So, es gibt 2 Widerstände die man ändern kann:

    1. den Ladestrom
    von 10kOhm (100mA) auf 2 kOhm (500mA)

    Ich würde aber nicht die kompletten 500mA ausschöpfen, mit 4k7 sollte man auf der sicheren Seite sein.
    Zu finden ist R4 auf der Oberseite:



    2. Die Spannungserhöhung:

    Hier handelt es sich um den Widerstand R18 auf der Unterseite.
    Von 470R auf 1k8. Ist hier zu finden:

    Allerdings ist die PIUSV+ nur für 2000mA spezifiziert.

    Weitere Angaben kann und werde ich hier nicht machen, da ich keine Lust auf eine Copyright-Klage habe.

    Umbau auf eigene Gefahr, die Widerstände sind ziemlich klein.

    Ist nichts für Grobmotoriker!

    MfG

    Jürgen

    Edit: Herzlich Willkommen im Forum

    Edit: R4 korrigiert, Danke fred0815

  • Hallo Jürgen!

    Ja, es ist schon ein paar Jahre her, seit du mir mal 2 aus dem Schrott geborgene PIUSV+ geschenkt hast. Und dieser Thread hier ist auch schon "sehr tot" - aber ich will es trotzdem noch einmal versuchen ... .

    Ich liebe nämlich meine beiden PIUSV+! Zusammen mit einem NUT-Server fahren sie sauber und zuverlässig meine beiden NAS und auch alles sonstige Geraffel runter und vor allem auch meine 3 RasPis.

    Leider bekomme ich sie, nachdem ich bookworm installiert habe, nicht mehr zum Laufen.

    Deshalb meine Frage, ob es da noch irgendeine Möglichkeit für eine neue Firmware gibt?


    vy 73 de Peter aus der Eifel

  • Edit:

    Eine neue Firmware gibt es für die PIUSV+ nicht.
    Mittlerweile wurde die Produktion eingestellt.

    Aber ich habe den oben erwähnten Treiber unter Bookworm zum laufen gebracht, auf einen RPi3B .
    Für einen RPi4 und RPi5 reicht der Strom nicht.

    MfG

    Jürgen

  • Hallo Jürgen,

    und vielen Dank für deine schnelle Antwort!

    Die Frage nach der Firmware war natürlich die falsche - es geht mir um die auf dem RasPi laufende Monitor-Software der PIUSV+.

    Wichtig war für mich deine Aussage, dass du selbige unter Bookworm zum Laufen gebracht hast. Ich weiß zwar noch nicht so richtig, wie ich da vorgehen soll, aber ich werde mich "einarbeiten". Ich darf wohl davon ausgehen, dass deine unter #1 gepostete Anleitung weiterhin funktioniert?

    Meine beiden PIUSV+ liefen all die Jahre an einem meiner zwei Standorte auch erfolgreich auf einem RasPi 4. Da auf diesem nur ein Seafile-Server und ein pihole liefen, reichte der gelieferte Strom völlig aus.


    vy 73 de Peter

  • Wichtig war für mich deine Aussage, dass du selbige unter Bookworm zum Laufen gebracht hast.

    Gerade ein Upgrade gemacht und neu gebootet:

    Code
    cat /etc/os-release 
    PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
    NAME="Debian GNU/Linux"
    VERSION_ID="12"
    VERSION="12 (bookworm)"
    VERSION_CODENAME=bookworm
    ID=debian
    HOME_URL="https://www.debian.org/"
    SUPPORT_URL="https://www.debian.org/support"
    BUG_REPORT_URL="https://bugs.debian.org/"
    Code
    uname -a
    Linux raspi23 6.12.25+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.12.25-1+rpt1 (2025-04-30) aarch64 GNU/Linux

    Also bei mir läufts mit dem 3B.

    Das mit dem kompilieren ist nicht besonders tricky, die Anleitung auf

    GitHub - dehapama/piupsmonitor-raspberrypi: Programm to monitor the PiUPS+ (PiUSV+) module for the Raspberry Pi
    Programm to monitor the PiUPS+ (PiUSV+) module for the Raspberry Pi - GitHub - dehapama/piupsmonitor-raspberrypi: Programm to monitor the PiUPS+ (PiUSV+)…
    github.com

    war selbst für mich einfach nachzuvollziehen.

    Wäre schön wenn die HANZA AG die Unterlagen bei Github einstellen würde,
    wenn sie schon den Vertrieb einstellt.

    MfG

    Jürgen

  • Ich weiß, dass ich ein relativ altes Thema hier wieder ausgrabe, dennoch will ich meine Erfahrungen mit der hier empfohlenen piupsmonitor-Paket wiedergeben und ggf. auch ein Paar Fragen hier los werden.

    Zu meinem System:

    Raspberry Pi 2 Model B Rev 1.1  1 GB  32 BIT
    Raspbian GNU/Linux 13 (trixie)

    Davor hatte ich "Bookworm" drauf, mit dem die Original-Software noch lief. Seit "Trixie" laufen ja bekanntlich die alten init.d-Skripte gar nicht mehr (zumindest hatte ich es so verstanden), deswegen hatte ich mich im Netz entsprechend informiert und bin auf hier zitierte "piupsmonitor" gestoßen. An sich nicht schlecht, weil die Quellen dafür verfügbar sind (im Unterschied zum Original-Pakage) und es ist auch in C geschrieben im Unterschied zu all anderen möchte-gern-Programmierern mit ihrem Python. Also, alles wie hier und auch wie auf GITHUB beschrieben kompiliert und installiert und es läuft, aber (und jetzt kommt das große ABER) es ist meiner Beobachtung nach sehr buggy und instabil. Nun all meine Kritikpunkte nacheinander:

    1. Das neue Package lehnt sich sehr stark an das alte Package und versucht es "nachzuaffen", aber leider nicht komplett. Die Aussagen in der Log-Datei sind z.B. komplett anders, als im Original und sind zum Teil widersprüchlich. Im alten Original war die Meldung im Log einzeilich und im Klartext. Das hat mich damalls dazu animiert ein kleines Shell-Skript zu schriben und es als "StatusChangedCmd" in der config-Datei einzubinden. Im Skript wurde die letzte Zeile aus dem Log ausgelesen und mir per Telegram zugeschickt. Das lässt sich mit "sed", "tail" und sonstigen Shell-Werkzeugen recht leicht ausfiltern und für den Versand präparieren. Die Meldung war dann kurz und knackig und man konnte sofort verstehen, was damit gemeint ist. Beim neuen Package kommen da dagegen manchmal drei manchmal vier Zeilen so in etwa in der Art:

    2025-12-05 23:22:45 [NOTICE] Change in Battery Low: 1
    2025-12-05 23:22:45 [NOTICE] Change in Battery Charge: 0
    2025-12-05 23:22:45 [NOTICE] Change in Battery Full: 0
    2025-12-05 23:22:45 [NOTICE] Change in Button Pressed: 0
    2025-12-05 23:22:45 [NOTICE] Change in Battery Low: 0
    2025-12-05 23:22:45 [NOTICE] Change in Battery Charge: 1
    2025-12-05 23:22:45 [NOTICE] Change in Battery Full: 1
    2025-12-05 23:22:45 [NOTICE] Change in Button Pressed: 1

    Diese Form lässt sich nur schwer verarbeiten und automatisieren. Hatte ich zwar auch versucht, der Aufwand dafür wäre aber hier deutlich höher, um alle Eventualitäten abzufangen.

    2. Mit einem anderen Log-Format (s. Punkt 1) wäre es vielleicht noch halb so schlimm und man hätte damit irgendwie leben können, aber das neue Package verhält sich zumindest in meiner Umgebung sehr, sehr instabil. Hir ist die Aufzählung von diesen Instabilitäten, die mir aufgefallen sind:

    - Wie aus heiterem Himmel kommt plötzlich

    2025-12-06 02:00:22 [NOTICE] Change in Battery Low: 1
    2025-12-06 02:00:22 [NOTICE] Change in Battery Charge: 0
    2025-12-06 02:00:22 [NOTICE] Change in Battery Low: 0
    2025-12-06 02:00:23 [NOTICE] StatusChangedCmd /usr/local/bin/piups_status_changed exited with status 0

    Die Batterie war hier aber keinerfalls "Low", das System lief auf Normalstromversorgung und die wurde hier nicht unterbrochen

    - Mit diesem "Low" hätte man es vielleicht noch als "Schönheitsfehler" deuten können, aber dann kam das hier:

    2025-12-06 07:37:41 [NOTICE] Change in Secondary Power Supply: 1
    2025-12-06 07:37:41 [NOTICE] Change in Battery Charge: 1
    2025-12-06 07:37:41 [NOTICE] Change in Battery Full: 1
    2025-12-06 07:37:41 [NOTICE] Change in Button Pressed: 1
    2025-12-06 07:37:41 [NOTICE] Successfully started Button_PressedCmd systemctl poweroff

    Und ich habe um die Uhrzeit den Taster nicht betätigt! Auffallend sind hier auch alle "1", was eigentlich unlogisch ist und sich widerspricht (abgesehen davon, dass ich die Bedeutung von diesen Statis im Log sowieso nicht so richtig verstanden hatte, wovon ich schon oben geschrieben hatte). Der RPI wird daraufhin sauber runtergefahren. Aber warum zum Teufel? Mit dem alten Original-Binary hatte ich so ein Verhalten noch nie beobachtet.

    Das beschriebene Verhalten (sowohl mit dem "Low" als auch mit dem Herunterfahren) wiederholt sich alle Paar Stunden, sodass es mir mächtig auf die Nerven ging und ich heute nach Alternativen gesucht hatte. Und die Alternative beschreibt der Autor von "piupsmonitor" auf GITHUB selbst, nämlich ein Binary vom alten "piusmon" nutzen und nur die systemd-Skripte entsprechend anpassen. Das hatte ich auch gemacht und seitdem läuft bei mir diese Lösung mit den neuen systemd-Skripten und dem alten "piupsmon"-Binary.

    Nun kommen meine Vermutungen und Fragen:

    a) Ich vermute mal, dass "piupsmonitor" recht instabil bzgl. Störungen sowohl auf dem i2c-Bus als auch z.B. auf der Eingangsleitung von dem on-off-Taster ist. Vermutlich sind die beiden Sachen im Original-Skript besser entprällt

    b) Diese Geschichte mit dem dtparam=i2c_baudrate=40000 hatte ich zwar auch eingebaut, hatte aber den Sinn vom Ganzen nicht verstanden. Denn beim Original-Package lief es bei mir über Jahre ohne diese Anpassung. Außerdem ist sie in der Form für meinen RPI2 nicht ganz korrekt. Es muss nämlich besser als dtparam=i2c_arm=on,i2c_arm_baudrate=40000 zusammen in einer Zeile mit der Aktivierung von i2c definiert werden. Meine Vermutung hier ist die aus dem a): das neue Binary ist nicht so robust wie das alte und braucht daher diese Definition, um die Stabilität auf dem i2c-Bus dadurch zu erhöhen

    c) Hier und auf github wird es behauptet, dass das alte Package mit den neuen Debians nicht läuft. Aber kann man dieser Aussage wirklich pauschal trauen, wie es behauptet wird? Und was genau "läuft nicht"? Das komplette deb-Package, was sich nicht installieren lässt? Die alten init.d-Skripte? Oder was genau? Denn vielleicht reicht es einfach das alte Binary mit den neuen systemd-Skripten zu "verheiraten" und es wird dann lauffähig, wie meine Experimente auf einem 32bit-System zeigen. Hat jemand schon mal das alte Binary aus dem Original-deb-Package auf einem aktuellen System versucht zu starten? Crasht es dann, oder was ist dabei das Problem? Denn wie gesagt, auf einem 32bit-System mit RPI2 ist es lauffähig.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!