Hallo zusammen,
seit einiger Zeit steckt ein HAT-konformes USV-Modul "UPS PIco" von http://www.pimodules.com/ (http://www.pimodules.com/) auf meinem rpi 2.
Erfüllt seinen Zweck eigentlich recht gut >>> Absicherung des Filesystems, RTC, ...
Habe mich mal entschlossen das Teil über I2C ein fhem einzubinden.
Im Nachhinein muß ich sagen - leider nicht über RPII2C, sondern direkt über smBus.
Device::SMBus muß also installiert sein.
Vielleicht kann jemand was damit anfangen ...
(Dateien im Anhang)
Gruß, Peter
Hey,
cool, endlich jemand, der das Ding auch hat.
Wie hast du deine zum laufen bekommen?
Habe die USV bei mir angeschlossen, sie ist geladen und wird auch erkannt. Schalte ich sie dann ein, blinkt es eine Weile und dann geht sie wieder aus.
Leider hatte die Dokumentation damals nicht geholfen.
Benutze selbst einen RPi Modell B+.
Bin für jede Hilfe dankbar.
Viele Grüße
Tino
Hallo Ascos,
eigentlich ohne große Schwierigkeiten.
Habe zunächst auf dem rpi b+ gestartet und auch die Einbindung in fhem gemacht und später auf rpi2 b portiert (SD-Karte kopiert und apt-get update / ~upgrade / rpi-update).
Beim Portieren wurde mir die Kernel-Änderung im devicetree vom Frühjahr zum Verhängnis (Probleme mit GPIO, I2C). Ließ sich aber beheben.
Kernelversion finden: uname -a (ab 3.18.x+ sollte man etwas abweichend von der Herstelleranweisung konfigurieren)
Grundsätzlich müßte die USV-Funktionalität ohne zutun arbeiten. (Akku anschließen, Modul aufstecken, Power einschalten)
Nach dem Einschalten muß die "CHG"-LED leuchten >>> es wird geladen. Es ist ein LIPO-Ladechip auf der Platine. Der funktioniert "für sich selbst" (ohne SW).
Wenn man dann mit dem Teil kommunizieren will, sollten die Jumper richtig gesetzt sein.
Per RS232 kann man dann schon mal die FW und den Status herausfinden.
Für das richtige Runterfahren müßte das fssd-Script (FileSafeShutdown) auf dem rpi laufen. Dann blinkt die grüne "UPS"-LED.
Dann könnte man I2C prüfen/einrichten.
Wo blinkt es denn bei Deiner PIco?
Kannst Du per RS232 (minicom) auf das Teil zugreifen?
Gruß, Peter
Zitat von: DerPeter am 16 Juni 2015, 20:45:37
Hallo Ascos,
eigentlich ohne große Schwierigkeiten.
Habe zunächst auf dem rpi b+ gestartet und auch die Einbindung in fhem gemacht und später auf rpi2 b portiert (SD-Karte kopiert und apt-get update / ~upgrade / rpi-update).
Beim Portieren wurde mir die Kernel-Änderung im devicetree vom Frühjahr zum Verhängnis (Probleme mit GPIO, I2C). Ließ sich aber beheben.
Kernelversion finden: uname -a (ab 3.18.x+ sollte man etwas abweichend von der Herstelleranweisung konfigurieren)
Grundsätzlich müßte die USV-Funktionalität ohne zutun arbeiten. (Akku anschließen, Modul aufstecken, Power einschalten)
Nach dem Einschalten muß die "CHG"-LED leuchten >>> es wird geladen. Es ist ein LIPO-Ladechip auf der Platine. Der funktioniert "für sich selbst" (ohne SW).
Wenn man dann mit dem Teil kommunizieren will, sollten die Jumper richtig gesetzt sein.
Per RS232 kann man dann schon mal die FW und den Status herausfinden.
Für das richtige Runterfahren müßte das fssd-Script (FileSafeShutdown) auf dem rpi laufen. Dann blinkt die grüne "UPS"-LED.
Dann könnte man I2C prüfen/einrichten.
Wo blinkt es denn bei Deiner PIco?
Kannst Du per RS232 (minicom) auf das Teil zugreifen?
Gruß, Peter
Hi,
also als Kernel-Version hab ich 3.18.9+
Standartmäßig leuchtet bei meiner USV garnichts. Wenn ich auf UPSR drücke, blinkt UPS ca. 5 Sekunden grün, ebenso ebenso die rote und blaue im Wechsel.
Sobald die wieder aus sind, leuchtet CHG kurz auf und geht dann aus.
Habe, wie in der Anleitung beschrieben I2C installiert und kann bei den ganzen Abfragen der Variablen mir auch etwas anzeigen lassen, aber mehr nicht.
Wenn nun aber der Strom weg ist, springt die USv nicht an, sondern mein PI geht sofort aus. Somit macht das Ding eigentlich nichts.
Was mache ich falsch bzw. was fehlt mir?
Viele Grüße
Tino
Moin,
tja -soweit ist das beschriebene Verhalten OK.
ZitatStandartmäßig leuchtet bei meiner USV garnichts. Wenn ich auf UPSR drücke, blinkt UPS ca. 5 Sekunden grün, ebenso ebenso die rote und blaue im Wechsel.
Das ist das Booten der PIco. Sieht man nach einem Reset (UPSR) oder z.B. nach dem Flashen der FW.
ZitatSobald die wieder aus sind, leuchtet CHG kurz auf und geht dann aus.
Wenn der Akku nicht beansprucht wird, gibts auch nicht viel (nach)zuladen.
Das Problem schein mir, daß die UPS-LED der PIco nicht ins Blinken geht.
Die Interaktion zwischen rpi und PIco läuft über 2 GPIO-Pins und ein Script (picofssd.py) das auf dem rpi läuft. Genaugenommen gehört natürlich auch der Zustand der Betriebsspannung des rpi mit dazu, die ja auch über die Steckerleiste geht.
Der rpi gibt an GPIO22 (OUT) einen Impuls an die PIco aus. Für die PIco ist das das Zeichen, daß der rpi noch lebt. Auf GPIO27(IN) quittiert sie dies dem rpi mit einem high-Signal. Wird GPIO27=0 dann führt das Script das Runterfahren (shutdown) des rpi aus (z.B wenn auf der PIco der FSSD-Button gedrückt wird). Bei laufendem Script ergibt sich an GPIO22 eine Pulsfolge (pulsetrain) >>> UPS-LED blinkt. Bricht die Pulsfolge ab (rpi hat sich z.B. erhängt), kann die PIco einen HardReset des rpi ausführen. Dazu muß der "goldplated pin" eingelötet sein.
Die Dateien, die Du zum Betrieb der PIco brauchst findest Du beim Hersteller: PiForum FW0x25 (http://www.forum.pimodules.com/viewtopic.php?f=12&t=205)
Ob das Script bereits läuft, kannst Du folgendermaßen prüfen:
ps -ax | grep picofssdWenn nicht, kannst Du das Python-Script auch zunächst per Hand starten (Speicherort: /home/pi/) und sehen was passiert.
python /home/pi/picofssd.py Wenn die UPS-LED ins Blinken kommt, solltest Du das Netzteil absteckern können und die USV müßte übernehmen. Müßte dann in den Autostart des rpi aufgenommen werden.
Falls etwas anderes passiert - mal kurz beschreiben.
Im Anhang habe ich mal ein kleines Perl-Script angehängt, mit dem Du schnell die FW/Status der PIco ermitteln kannst (spart den minicom-aufwand).
perl /home/pi/upsstatus.plWenn's klappt, kannst Du das Ergebnis ja mal posten.
Viel Erfolg... Peter
Hi Peter,
vielen Dank für deine ausführliche Hilfe.
Habe mich gleich mal ans testen gemacht und kann nun Folgendes berichten.
Mir fehlte bisher die picofssd.py
Zwar hat dein Befehl zum nachsehen, ob das Skript läuft nicht funktioniert:
pi@raspberrypi ~ $ ps -ax | grep picofssd
warning: bad ps syntax, perhaps a bogus '-'?
See http://gitorious.org/procps/procps/blobs/master/Documentation/FAQ
2581 pts/0 S+ 0:00 grep --color=auto picofssd
Doch ich habe es mir dann von deinem Link geladen und manuell ausgeführt (musste es mit sudo starten, ohne ging es nicht) und siehe da, die UPS-LED blinkte.
Strom abgezogen und auch das ging :)
Habe dann das Skript noch in den Autostart gepackt, was nun auch super funktioniert :)
Habe auch dein Skript gestartet, leider kam da nichts bei raus:
pi@raspberrypi ~ $ sudo perl /home/pi/upsstatus.pl
pi@raspberrypi ~ $
Auch ein Sudo half hier nichts.
Vielen, vielen Dank auf jeden Fall für deine Hilfe.
Liebe Grüße
Tino
Hallo,
schön das es funktioniert.
Man kommt bei dem Teil wohl nicht um "read-the-fucking-manual" vorbei. Schade das die Homepage des Herstellers etwas grottig ist. Der Link oben war ja aus dem Forum. Auf der Homepage gibt es noch ein kleines Manual zu FSSD und Bootloader: http://www.pimodules.com/_pdf/_pico/UPS_PIco_BL_FSSD_V1.0.pdf (http://www.pimodules.com/_pdf/_pico/UPS_PIco_BL_FSSD_V1.0.pdf) und auch zu dem Reset-Pin. Man muß sich alles zusammenklaubern ...
Das mein Perl-Script nicht funktionierte könnte vielleicht an den Settings für "/dev/ttyAMA0" liegen. Einfach die Anweisungen aus den Manual's abarbeiten und dann nochmal probieren.
Wichtig wäre den Parameter "fssd_batime" zu setzen (per I2C-Kommando). Ich nehme meist 180sec >> 3min nach Stromausfall fährt die Pico den rpi runter. In alten FW-Versionen war der Parameter auf 0 = ohne Funktion. Dann wurde der "kleine" Akku bis zur Abschaltgrenze entladen - das will man ja nicht wirklich. Für ca 10min reicht die Kapazität. In FW 0x25 sind die 180sec Standard.
Ich würde auf jeden Fall empfehlen auf die aktuelle FW 0x25 zu gehen.
Damit könntest du auch die Einbindung in fhem probieren (und PIco-Parameter und die User-LED per WebInterface steuern).
Nacht ... Peter
Hey,
also irgendwo ist bei mir der Wurm drin.
Habe es versucht, aber er sagt immer, das er ein Problem in der Kommunikation mit dem Bootloader hat, obwohl er eigentlich gestartet ist (angezeigt durch die rote LED).
pi@raspberrypi ~ $ sudo i2cset -y 1 0x6B 0x00 0xff && python picofu.py -f pico.hex
Validating firmware: OK
Checking communication with bootloader: KO
ERROR: Failed to establish communication with bootloader in PIco. Is the PIco in the bootloader mode? (Red LED lid on PIco)
Habe es sowohl mit der manuellen, als auch mit dem automatischen Update versucht, beides brachte das gleiche Ergebnis.
Zumindest weiß ich nun, das ich Firmware 0x10 drauf habe, also recht alt.
Habe die fssd_time auch auf 180 gesetzt, zuvor testweise auf 30 und der shutdown klappte problemlos.
Habe auf dieses minicom installiert, wie in der Anleitung beschrieben, aber als ich die pico dann resettete, wurde nichts angezeigt.
Hallo Ascos,
so einen dicken Wurm gibt's doch gar nicht!
Offensichtlich klappt die serielle Kommunikation nicht. (minicom + mein perl-script + das bootload-script haben es bewiesen)
Der Bootloader funktioniert über den seriellen Port "/dev/ttyAMA0".
Das sind die GPIO_GEN15 (RX) und GPIO_GEN14(TX). Ich unterstelle mal, daß diese bei Deinem konkreten rpi-Stetting nicht anderweitig benutzt werden.
Alle Jumper (außer HATWP) müssen auf der PIco gesteckt sein.
Die Anweisungen der Doku "UPS_PIco_BL_FSSD_V1.0.pdf" zur serielle Kommunikation sollten abgearbeitet sein:
a) Datei: /boot/cmdline.txt
b) Datei: /etc/inittab
Dann fällt mir noch die "Kernel-serial-message-shell-Geschichte" ein:
- Das Tool "raspi-config" ausführen.
- Unter "8 Adv. Options" den Punkt "A8 Serial" anwählen und auf "NEIN/NO" setzen.
- Reboot
Wenn Dir noch was anderes einfällt, was den seriellen Verkehr behindert, müßtes Du das zumindest fürs FW-Update "umbiegen/deaktivieren"
Ich mache das FW-Update immer so:
- UPSR drücken und HALTEN > KeyA drücken und HALTEN > UPSR loslassen > danach KeyA loslassen ==> jetzt sollte die rote User-LED leuchten
- das BootLoad-Scrpit starten: "python picofu.py -f UPS_PIco.hex"
PS: ich habe meist kein "sudo" davor, sondern gehe vorher immer gleich mit "sudo bash" auf's höhere Level.
Viel Erfolg ... Peter
Hi Peter,
man, du hast echt Geduld mit mir, ich weiß garnicht, wie ich dir danken soll.
So langsam gehts auch voran.
Alles, was in der UPS_PIco.pdf war, hatte ich schon gemacht.
Der Fehler lag an der raspi-config, da war A8 Serial anscheinend an, nachdem ich es deaktiviert hatte, testete ich dein Skript und es lief.
Auch der Minicom-Test hat nun endlich geklappt.
Nun das Firmwareupdate angeworfen und es lief beim ersten Mal problemlos durch.
Nun nochmal dein Skript gestartet und nun sieht es so aus:
pi@raspberrypi ~ $ perl /home/pi/upsstatus.pl
UPS PIco Hardware Release: V1.00
Firmware Release: V1.0 XBMC 20.05.2015 0x25
Powering Source:RPI
UUPS PIco RTC Date:2000:01:01
UPS PIco RTC Time:00:01:00
RPi Voltage:05.50 V
BAT Voltage:04.24 V
Low Power Restart Time (LPRSTA) is 5 seconds
File Safe Shutdown when Power loose Time is: 120 Seconds
Real Time Clock Correction Factor value is: 0x00
Werde mich nun dran machen, mir dein Skript anzusehen und einzubinden :)
Viele Grüße
Tino
Edit:
Ich fürchte, ich muss nochmal deine Hilfe in Anspruch nehmen.
Habe versucht, die USV einzubinden, aber es kam folgende Fehlermeldung:
$name error: Device::SMBus not installed
Habe aber eigentlich SMbus installiert, oder gibt es da noch einen?
sudo apt-get install python-smbus
Hi nochmal,
es gibt nur einen SMBus im System - aber unterschiedliche Möglichkeiten ihn anzusprechen.
Device::SMBus ist ja ein Perl-Modul.
Das Modul kann mit folgendem Befehl installiert werden.
root@fhemsrv:/home/pi/# perl -MCPAN -e 'install Device::SMBus'
Dabei wird gleich alles notwendige für CPAN mitinstalliert.
Dauert etwas. Hatte bei meinen 2 rpi's keine Probleme. Aber es ist schon ein größerer Brocken. Ggf sicherheitshalber vorher ein Image der SD-Karte ziehen.
In der commandref gibt es beim Device "RPII2C" unter Optional auch einen Hinweis.
Über CPAN kann man später auch ein Update für Device::SMBus ziehen, um aktuell zu bleiben. Mal in die Doku gucken.
Gruß, Peter
Hi,
ok, die Installation hat geklappt.
Dauerte wirklich ne Weile, aber scheint problemlos funktioniert zu haben.
Zumindest konnte ich nun die USV anlegen, aber er bekommt keine Infos.
Wenn ich auf Get State klicke, geht das Fenster auf, aber nirgends ist ein Wert eingetragen.
Dauert das etwas, bis der Infos bekommt, oder hängt es wieder bei mir?
Viele Grüße
Tino
Hi,
ich nochmal. Habe gerade mal in mein Log gesehen und da ist einiges aufgelaufen seid gestern Abend:
015.06.18 23:37:05 1: USV:
2015.06.18 23:37:05 1: USV:
2015.06.18 23:37:05 1: USV:
2015.06.18 23:37:05 1: USV:
2015.06.18 23:37:05 1: USV:
2015.06.18 23:37:05 1: PERL WARNING: Use of uninitialized value $ErrCode in sprintf at ./FHEM/98_UPSPICO.pm line 434.
2015.06.18 23:37:05 1: USV:
2015.06.18 23:37:05 1: USV:
2015.06.18 23:37:05 1: USV:
2015.06.18 23:38:07 1: USV:
2015.06.18 23:38:07 1: USV:
2015.06.18 23:38:07 1: USV:
2015.06.18 23:38:07 1: USV:
2015.06.18 23:38:07 1: USV:
2015.06.18 23:38:07 1: USV:
2015.06.18 23:38:07 1: USV:
2015.06.18 23:38:07 1: USV:
2015.06.18 23:38:07 1: USV:
2015.06.18 23:39:07 1: USV:
2015.06.18 23:39:07 1: USV:
2015.06.18 23:39:07 1: USV:
2015.06.18 23:41:28 1: PERL WARNING: Use of uninitialized value $year in numeric gt (>) at ./FHEM/98_UPSPICO.pm line 296.
2015.06.18 23:41:28 1: PERL WARNING: Use of uninitialized value $year in addition (+) at ./FHEM/98_UPSPICO.pm line 297.
2015.06.18 23:41:28 1: PERL WARNING: Use of uninitialized value $day in concatenation (.) or string at ./FHEM/98_UPSPICO.pm line 299.
2015.06.18 23:41:28 1: PERL WARNING: Use of uninitialized value $month in concatenation (.) or string at ./FHEM/98_UPSPICO.pm line 299.
2015.06.18 23:41:28 1: PERL WARNING: Use of uninitialized value $hour in concatenation (.) or string at ./FHEM/98_UPSPICO.pm line 299.
2015.06.18 23:41:28 1: PERL WARNING: Use of uninitialized value $min in concatenation (.) or string at ./FHEM/98_UPSPICO.pm line 299.
2015.06.18 23:41:28 1: PERL WARNING: Use of uninitialized value $sec in concatenation (.) or string at ./FHEM/98_UPSPICO.pm line 299.
2015.06.18 23:41:28 1: PERL WARNING: Use of uninitialized value $VBAT in concatenation (.) or string at ./FHEM/98_UPSPICO.pm line 377.
2015.06.18 23:41:28 1: PERL WARNING: Use of uninitialized value $VRPI in concatenation (.) or string at ./FHEM/98_UPSPICO.pm line 377.
2015.06.18 23:41:28 1: PERL WARNING: Use of uninitialized value $TBAT in concatenation (.) or string at ./FHEM/98_UPSPICO.pm line 377.
2015.06.18 23:41:28 1: PERL WARNING: Use of uninitialized value $TFAN in concatenation (.) or string at ./FHEM/98_UPSPICO.pm line 377.
2015.06.18 23:41:28 1: PERL WARNING: Use of uninitialized value $led_blue in concatenation (.) or string at ./FHEM/98_UPSPICO.pm line 377.
2015.06.18 23:41:28 1: PERL WARNING: Use of uninitialized value $led_red in concatenation (.) or string at ./FHEM/98_UPSPICO.pm line 377.
2015.06.18 23:41:28 1: PERL WARNING: Use of uninitialized value $sta_counter in concatenation (.) or string at ./FHEM/98_UPSPICO.pm line 377.
2015.06.18 23:41:28 1: PERL WARNING: Use of uninitialized value $fssd_batime in concatenation (.) or string at ./FHEM/98_UPSPICO.pm line 377.
2015.06.18 23:41:28 1: PERL WARNING: Use of uninitialized value $FSSD_tout in concatenation (.) or string at ./FHEM/98_UPSPICO.pm line 377.
2015.06.18 23:41:28 1: PERL WARNING: Use of uninitialized value $lprsta in concatenation (.) or string at ./FHEM/98_UPSPICO.pm line 377.
2015.06.18 23:41:28 1: PERL WARNING: Use of uninitialized value $btto in concatenation (.) or string at ./FHEM/98_UPSPICO.pm line 377.
2015.06.18 23:41:28 1: PERL WARNING: Use of uninitialized value $bmode in concatenation (.) or string at ./FHEM/98_UPSPICO.pm line 377.
2015.06.18 23:41:28 1: PERL WARNING: Use of uninitialized value $fmode in concatenation (.) or string at ./FHEM/98_UPSPICO.pm line 377.
2015.06.18 23:41:28 1: PERL WARNING: Use of uninitialized value $fspeed in concatenation (.) or string at ./FHEM/98_UPSPICO.pm line 377.
2015.06.18 23:41:28 1: PERL WARNING: Use of uninitialized value $XBMC in concatenation (.) or string at ./FHEM/98_UPSPICO.pm line 377.
Diese leeren USV-Meldungen habe ich seid gestern Abend minütlich.
Hallo Ascos,
war die letzten Tage außerlandes, darum erst heute eine Antwort.
Wenns nicht läuft und das Log zumüllt, das Device zunächst mal wieder löschen.
Anhand des Log kann ich noch nicht definitiv sagen was los ist.
1) was lieferti2cdetect -y 1 oder manchmal auch i2cdetect 1
2) mal das perl-script lt. Anhang zum Test des SMBus mit UPS PIco ausführenperl testpicosmbus.pl
Gruß, Peter
Hey Peter,
kein Problem, geht mir manchmal auch so :)
Hier die ausgeführten Befehle:
pi@raspberrypi ~ $ sudo i2cdetect -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- UU 69 6a 6b -- -- -- --
70: -- -- -- -- -- -- -- --
pi@raspberrypi ~ $ sudo i2cdetect 1
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-1.
I will probe address range 0x03-0x77.
Continue? [Y/n] y
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- UU 69 6a 6b -- -- -- --
70: -- -- -- -- -- -- -- --
pi@raspberrypi ~ $ sudo perl /home/pi/testpicosmbus.pl
===========================
Testing SMBus with UPS PIco
0x69 ->UPS PIco Module Status Registers Specification
1) mode: 1, vbat: 1040, vrpi: 1360, tbat: 51
2) mode: 1, vbat: 4.1 V, vrpi: 5.5 V, tbat: 33 °C
0x6A -> UPS PIco RTC Registers Direct Access Specification
1) 35, 6, 21, 24, 69, 8
2) 23.06.2015 18:45:08
0x6B -> UPS PIco Module Commands
1) ErrCode: 0, fssd_batime: 120, bmode: 2
= the end =================
pi@raspberrypi ~ $
Hallo Ascos,
ooh - da weiß ich auch nicht weiter oder sollte ich sagen Herzlichen Glückwunsch?
Die Testergebnisse würde ich so interpretieren:
1) i2cdetect:
alle für die PIco relevanten Adressen 68-6b sind vorhanden und der RTC-Treiber arbeitet (uu) = OK
2) Script testpicosmbus.pl:
Hier hatte ich alle 3 Adressen über Perl via "Device::SMBus" angesprochen und jeweils ein paar Beispielwerte ausgelesen + ausgegeben. Das heißt die CPAN-Installation hat geklappt (sagtes Du ja) und funktioniert auch. Weiterhin wurden die gelesenen Werte formatiert ausgegeben - klappte auch.
Das fhem-Script macht nichts anderes. Warum es nicht zieht, ist die Frage ...
Hattest Du nach Installation von "Device::SMBus" das Device in fhem gelöscht und noch einmal neu angelegt?
Auf solche Tipps wie fhem / rpi durchstarten bist Du sicher schon selbst gekommen.
Dateirechte des Scripts halte ich für unwahrscheinlich, kann aber auch geprüft werden.
Mein Startwert für das Polling-Interval ist 60sec (So kamen ja die Fehlermeldungen im Log). Kann aber zum Test auch z.B auf 5sec runtergestellt werden. Die Readings müssen nach dem Pollen sofort angezeigt werden.
Soweit erstmal...
Peter
Hi,
also ich hab noch ein bisschen rungetestet.
Ich glaube, es ist wirklich ein Rechte Problem. Dein SKript zeigt nur etwas an, wenn ich es mit SUDO ausführe. Ohne kommt nur eine Fehlermeldung. Könnte sein, das FHEM das gleiche Problem hat?
Eigentlich hat mein FHEM-Benutzer schon Root-Rechte.
Das hier meinte dein SKript, als ich es ohne SUDO ausführte:
pi@raspberrypi ~ $ perl /home/pi/testpicosmbus.pl
===========================
Testing SMBus with UPS PIco
0x69 ->UPS PIco Module Status Registers Specification
Unable to open I2C Device File at Device::SMBus=HASH(0xaec7d0)->I2CBusDevicePath at (eval 14) line 18
(in cleanup) Unable to open I2C Device File at Device::SMBus=HASH(0xaec7d0)->I2CBusDevicePath at (eval 14) line 18
Hallo Ascos,
ZitatIch glaube, es ist wirklich ein Rechte Problem.
Ja, da wird das Problem liegen. Auf meinem rpi funktioniert das Script auch als User "pi".
Laut Deiner Fehlermeldung fehlt der Zugriff auf die Ressource: '
/dev/i2c-1' (I2CBusDevicePath => '/dev/i2c-1' in Zeile 18)
'/dev/i2c-1' müßte für den jeweiligen User (pi, fhem, ...) zugänglich sein bzw gemacht werden.
Meine fhem-Installation ist User-mäßig Standard.
Gruß, Peter
Hallo Ascos,
nach einigem Grübeln ist mir wieder eingefallen, wie ich das mit den Rechten für I2C damals auf meinem System geregelt hatte.
Hatte ich schon wieder vergessen ...
Ich bin über "udev" gegangen. Man legt im Verzeichnis /etc/udev/rules.d eine Datei "98-i2c.rules" an und trägt 'SUBSYSTEM=="i2c-dev", MODE="0666"' ein.
echo 'SUBSYSTEM=="i2c-dev", MODE="0666"' > /etc/udev/rules.d/98_i2c.rules
reboot
Alternativ kann man natürlich auch den/die gewünschten User der Gruppe "i2c" hinzufügen.
Hinweise gibts auch hier: Link (http://www.netzmafia.de/skripten/hardware/RasPi/RasPi_I2C.html) bischen runter, kurz vor dem Abschnitt "Konfiguration"
Gruß, Peter
ES GEHT!!!! :)
Vielen Dank :)
Hab es hinbekommen, habde dem User die entsprechenden Rechte gegeben.
Vielen, vielen Dank für deine Hilfe und Gebuld :)
Kleiner Hinweis:
Aus grundsätzlichen Sicherheitsüberlegungen würde ich HW grundsätzlich nicht für alle Schreibbar machen!
Die Idee mit UDEV ist gut, besser aber, wenn man dann eine passende Gruppe anlegt, also z.B.
SUBSYSTEM=="i2c-dev", MODE="0664", GROUP="i2c"
Gruppe muß natürlich existieren .. und dann fhem in der Gruppe i2c hinzufügen. Hatte mal etwas Ähnliches hir für USB gepostet. Zum Vergleich:
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", MODE="0664", GROUP="usb"
Grundsätzlich:
Nur soviel rechte vergeben wie nötig.
Hallo Wernieman,
ZitatAus grundsätzlichen Sicherheitsüberlegungen würde ich HW grundsätzlich nicht für alle Schreibbar machen!
...
Grundsätzlich: Nur soviel rechte vergeben wie nötig.
Stimmt ...
Das Vorgehen mit
udev hatte ich damals aus einer Installationsanleitung für bmp180 in fhem übernommen und dann auch so belassen.
fhem in die Gruppe i2c aufnehmen ist eindeutiger und sicherer.
Gruß, Peter
Hallo Leidensgenossen,
Ihr seit ja schon weiter wie ich.
Ich habe jungfräulich ein Raspbain auf meinen Pi2 gespielt und versuche die USV zum laufen zu bringen.
Leider ohne jeglichen Erfolg.
Gerade startet der Pi2 das dritte mal. Das geordnete Herunter fahren ist das einzige was gerade mal klappt.
Dabei leuchten die CHG und BAT Led immer. UPS Led blinkt nach dem Start von picofssd.py. und CHG geht aus.
Ich habe zwei Terminalfenster offen. In dem wo ich picofssd.py. gestartet habe geht keine Kommandozeile mehr.
Im anderen Terminalfenster gucke ich ob die SW läuft.
Da steht :
2544 pts/0 S+ 0:00 sudo python /home/pi/picofssd.py
2545 pts/0 S+ 0:00 python /home/pi/picofssd.py
2546 pts/0 S+ 0:00 Grey --color=auto picofssd.py
Und es blinkt UPS sowie die BAT leuchtet immer.
Ziehe ich jetzt den USB Stecker raus geht alles aus.
Was ist hier grundsätzlich falsch???
Ich bin Ratlos und bitte um Hilfe
Gruß
Eckhard
So wie es aussieht (BAT dauerlicht) ist der Akku leer. Gemessen etwa 2,7V im Leerlauf.
Unter Last an der PicoUSV nur noch 1,6V. Wie wird der Akku eigentlich geladen und wie lange dauert das?
Nun habe ich auch mal die USB-Spannung gemessen und mußte feststellen das die gerade mal 4,8V hat.
Anderes Netzteil benutzt und die Spannung hatte 5,2V unter Last! Jetzt wird entlich der Akku auch geladen (CHG an).
Gruß
Eckhard
Hallo zusammen,
ich bin auch mit der PIco USV "gesegnet" aber mittlerweile etwas ratlos, warum das Ding einfach nicht will.
Mein System: Pi2 mit Raspbian (2015-05-05, Kernel 3.18), PIco USV, Firmware 0x25 ( http://www.pimodules.com/_zip/PIco_Firmware_Update_Pack_0x25.zip (http://www.pimodules.com/_zip/PIco_Firmware_Update_Pack_0x25.zip) )
Bevor ich den Thread hier mit dem zumülle, was ich schon alles versucht habe besser zurück auf Anfang. Deshalb erst eine einfache aber grundsätzliche Frage.
Ist eine Installation mit oder ohne Device Tree sinnvoller? Hab schon beide Wege versucht aber funktionert hats nicht wirklich.
Vielleicht kann mir da jemand helfen.
Alter Thread, aber immer noch aktuelles Thema (jedenfalls bei mir ;D)
Inzwischen gibt es ja die Hardware-Version 1.1 des UPS-Pico-Moduls mit der derzeit aktuellen Firmware 0x59. Mit dieser Firmware kann man u.a. auslesen, ob der Batterie-Charger aktiviert ist (siehe hier (http://www.forum.pimodules.com/viewtopic.php?f=19&t=375), ACHTUNG: CHG ist auch ON, wenn die Lade-LED aus und der Akku voll ist).
Ich habe das Modul aus dem ersten Post entsprechend erweitert und außerdem noch Readings für die beiden Hardware-Keys des Moduls (Key A und Key B) eingebaut. Da die Buttons nach ihrer Betätigung jeweils durch ein I2C-Write von 0x01 auf 0x00 zurückgesetzt werden müssen, habe ich außerdem noch entsprechende SET-Möglichkeiten eingebaut.
Vermutlich sind meine Erweiterungen nicht besonders schön gelöst, aber ich habe mich mangels ausreichender Programmierkenntnisse einfach an dem schon vorhandenen Code orientiert und eigentlich nur per Copy-/Paste die meiner Ansicht nach passenden Ergänzungen / Änderungen vorgenommen.
Wer es brauchen kann, findet meine Version im Anhang.
Gruß
alpha1974
ich glaub in der neuen 98_USVPICO.pm sind die register für den charger falsch :
Added variable that can be read by user (remotely) to see if charger is activated or not
sudo i2cget -y 1 0x69 0x10
0x01 - means Charger is ON
If the CHG LED is not lit, means that charger is ON, but battery is fully charged
0x00 - means Charger is OFF
ich glaub die angegebne 16 ist falsch ..
Gruss Rainer
Bei meinen Versuchen sah es so aus, als ob es funktioniert. Ich ging davon aus, dass 0x10 hex = 16 dezimal sei.
Werde es die Tage aber nochmals testen (zur Zeit habe ich leider wenig ebensolche für technische Spielereien :'().
bei nur 16 kommt als ergebnis immer nur null ...
irgendwie läuft die Schnittstelle beim SMBus etwas anders was die Parameter betrifft.
Siehe auch Modul 'RPII2C'
LG Rainer
Sehr merkwürdig, ich habe gerade nochmals nachgesehen: CHG LED ist an (dauergrün).
Hardware ist ein RPI2 mit UPS Pico in der HW Rev. 1.1 (direkt von pimodules, mit eingelötetem Buzzer und Reset-Pin).
pi@raspberrypi:~ $ sudo i2cget -y 1 0x69 0x10
0x01
pi@raspberrypi:~ $ sudo i2cget -y 1 0x69 16
0x01
State der USV unter FHEM:
USV Actual state of UPS_PIco
Firmware: 0x59
RealTimeClock (UTC): 01.02.2016 18:18:39
PoweringSource: RPI
Charger: on
Battery Voltage: 4.2 V
Raspberry Voltage: 4.97 V
Battery Temperature: 31 °C
Fan Temperature: 0 °C (only valid if Fan installed)
User LED blue: 0
User LED red: 0
KeyA: 0
KeyB: 0
ErrorCode: 00000000
UPS PIco variables (see manual):
sta_counter: 255 (StayAliveCounter)
fssd_batime: 69 sec (FileSaveShutdownTime on powerloss)
fssd_tout: 32 sec (Timeout needed for the FSSD procedure)
lprsta: 3 sec (Low Power Restart Time)
btto: 3 sec (Battery Powering Testing Timeout)
bmode: 2 (Integrated Buzzer Mode)
fmode: 0 (Integrated Fan Running Mode)
fspeed: 0 (Integrated Fan Speed)
xbmc: 0 (XBMC Mode)
ich habe die version 0x4A drauf ...
mit der 0x58 bekomme ich bei der red led einen fehler ...
die 0x59 fängt sich beim booten leider nicht mehr ...
HV ist 1.1 ....
lg rainer
Zitat von: rainer1962 am 01 Februar 2016, 20:03:23
ich habe die version 0x4A drauf ...
Das könnte es vielleicht erklären, warum bei dir 0x10 immer 0 ist. Wenn ich die Release-Notes zu Firmware 0x59 richtig interpretiere, wurde die Charger-Variable erst mit dieser Version implementiert.
Das Update auf Version 0x59 war bei mir auch abenteuerlich, klappte aber letztlich nach vielen Versuchen und Werks-Resets der USV. Die griechischen Entwickler haben auch fleißig, versucht mir zu helfen, wobei man dort zunächst eine eher sportliche Einstellung hatte: "However on my opinion you have done something wrong in the setup..." ;D
Fazit für mich: Wenn es läuft, läuft es ganz gut und ansonsten ist viel Rumprobieren angesagt. Jetzt bin ich mal auf den nächsten "Ernstfall" (Stromausfall) gespannt. Ironie des Schicksals: Bei uns gab es letzte Woche einen einstündigen Stromausfall, weil sich ein Baggerführer verbaggert hatte. Und wann kam die USV Pico? Nachmittags, ca. 1/2 Stunden, nachdem der Strom wieder da war :o Zum Glück hielt sich der Schaden (und damit der Groll der Familie) in Grenzen: Meinem 24/7-Server hat es zwar das Dateisystem zerschossen (ein Hoch auf Backups: Hoch!) und der Raspi fand seine SD-Karte erst wieder lesenwert, nachdem ich das Backup-Image zurückgeschrieben hatte. Aber jetzt wird dank der USV sicher alles besser ;D
ich habe die die 0x58 und 0x59 noch nicht zum laufe gebracht. die einzige die läuft ist 0x4a ...
da gibt es aber , wie du schon sagst die charger variable noch nicht ...
bin gespannt wann eine funktionierende (99%) stabile firmware verfügbar ist ...
wie hast du geschafft die 0x59 zu installieren...
Update läuft durch aber danach ist der i2c bus weg und nicht mehr ansprechbar ...
ansonsten ein geiles teil die ups !!!!
gruss rainer
Zitat von: rainer1962 am 01 Februar 2016, 21:51:57
wie hast du geschafft die 0x59 zu installieren...
Entscheidend war bei mir wohl, dass das UPS Module NACH dem Update auf Factory Settings zurückgesetzt werden muss. Ich habe für das Update leider zuerst ein altes Update-Script genutzt, das den Factory Reset nicht miterledigt hat. Das aktuelle Update-Script (im Supporting-Files-ZIP, siehe hier (http://www.forum.pimodules.com/viewtopic.php?f=19&t=375)) macht das nun. Nach einem Neustart des Raspberry (mit dem aktuellen rc.local und picofssd.py) lief alles prima.
Ein Firmware-Update steht offenbar unmittelbar bevor, wobei "unmittelbar" relativ ist. Die Jungs von pimodules schrieben Mitte letzter Woche: "
Please wait 1-2 days maximum to fix it by our side" ;D Nun ja, ein paar Tage mehr sind ja auch kein Beinbruch (es ging um das Problem, dass der fabrikneue und sehr leeren Akku nicht geladen wurde, Ladevorgang hing zwischen 2,4 und 2,5 V... laut pimodules-Forum bin ich da nicht der einzige... hat sich bei mir aber nach einem kurzzeitigen Downgrade auf Firmware 0x53 erledigt).
leider habe ich das auch alles durch ....
das neue script (picofy3.py) bricht nach dem upload der firmware mit fhelern ab. ein händisches setzen der werkseinstellungen findet zwar statt (leuchten der red und blue und piepsen des buzzers).
aber ich bekomme danach mit 'sudo i2cdetect –y 1' kein ergebnis angezeigt.
pi@FHEM-zu-Hause-Raspi ~ $ sudo i2cdetect –y 1
Error: I2C bus name doesn't match any bus present!
Usage: i2cdetect [-y] [-a] [-q|-r] I2CBUS [FIRST LAST]
i2cdetect -F I2CBUS
i2cdetect -l
I2CBUS is an integer or an I2C bus name
If provided, FIRST and LAST limit the probing range.
mit der Firmware 0x4a geht es aber.
hier noch mal die meldungen wenn ich die 0x59 versuche zu installieren:
root@FHEM-zu-Hause-Raspi:/home/pi# sudo i2cset -y 1 0x6b 0x00 0xff && python picofu3.py -v -f firmware_0x59.hex
Validating firmware: OK
Checking communication with bootloader: OK
Uploading firmware: 0% ................................................................................... 4.0% .................................................................................... 9.0% .................................................................................... 14.0% .................................................................................... 19.0% .................................................................................... 23.0% .................................................................................... 28.0% .................................................................................... 33.0% .................................................................................... 38.0% .................................................................................... 43.0% .................................................................................... 47.0% .................................................................................... 52.0% .................................................................................... 57.0% .................................................................................... 62.0% .................................................................................... 67.0% .................................................................................... 71.0% .................................................................................... 76.0% .................................................................................... 81.0% .................................................................................... 86.0% .................................................................................... 91.0% .................................................................................... 95.0% ...................................................................... Done uploading...
Invoking factory reset of PIco...
Traceback (most recent call last):
File "picofu3.py", line 546, in <module>
FWUpdate()
File "picofu3.py", line 192, in __init__
self.factory_reset()
File "picofu3.py", line 532, in factory_reset
i2c.write_byte_data(0x6b, 0x00, 0xdd)
IOError: [Errno 5] Input/output error
keine ahnung was da schief läuft .. :-(
Sehr merkwürdig, denn bei mir lief es schon mehrfach problemlos durch (Down- und Upgrades...).
Ob der berühmte gelbe Jumper, dessen Zweck mehr als geheimnisvoll (http://www.forum.pimodules.com/viewtopic.php?f=12&t=376) ist, vielleicht eine Rolle spielt? Ich kann mich leider nicht mehr daran erinnern, ob er gesteckt oder ab war, als ich die 0x59-Firmware geflasht habe.
In pimodules-Forum wurde auch schon mal die Stromversorgung für I2C-Kommunikationsprobleme verantwortlich gemacht, siehe hier (http://www.forum.pimodules.com/viewtopic.php?f=12&t=280).
hallo,
so, habe nun endlich die 0x59 installiert bekommen.
allerdings hat das updatescript beim firmwarereset auch wieder abgebrochen, so dass ich den nachträglich nochmal machen musste.
Ich glaube es hing irgendwie mit der übertacktung zusammen. haben den raspi nun nur noch mit 700mhz core 250, sdram 450 laufen.
Wenn ich noch mal viel zeit habe teste ich den ganzen kram auf einer anderen kiste mit der übertacktung.
so noch ein kleines problemchen:
das script für die ups in fhem läuft ja über den sm-bus.
Es werden ab und zu mal (1-30 mal am tag) fehlerhafte (unsinnige) werte ausgegeben.
2016-02-03_12:10:41 USV VoltageBAT: 0
2016-02-03_12:10:41 USV VoltageRPI: 0
2016-02-03_12:10:41 USV BatTemp: ffffffffffffffff
2016-02-03_12:10:41 USV FanTemp: ffffffffffffffff
2016-02-03_12:10:41 USV ErrorCode: 1111111111111111111111111111111111111111111111111111111111111111
2016-02-03_12:10:41 USV FanSpeed: -1
2016-02-03_12:10:56 USV PowerSource: RPI
2016-02-03_12:10:56 USV VoltageBAT: 4.22
2016-02-03_12:10:56 USV VoltageRPI: 5.05
2016-02-03_12:10:56 USV ErrorCode: 00000000
2016-02-03_12:10:56 USV FanSpeed: 0
woran kann das liegen?
Das Phänomen hatte ich auch bei jeder anderen Firmware
LG Rainer
Das mit den unsinnigen Werten ist mir bislang noch nicht aufgefallen, aber ich habe auch keine Logs aktiviert bzw. mit DbLogExclude .* alle Logs ausgeschaltet. Bisher läuft das FHEM-Device nur "nebenher", um die Einbindung der USV in FHEM mal auszuprobieren. Die Logs interessierten mich bislang nicht (zumal bei einem Polling von 15s auch viel zusammen kommt).
Wenn ich mal mehr Zeit habe, schalte ich aber mal das DbLog an und sehe nach, ob es auch bei mir passiert.
Eigentlich finde ich die Polling-Variante auch nicht so gelungen. Lieber wäre mir eine Interrupt-Lösung. Im Manual der Pico USB steht dazu auch etwas, aber ohne nähere Erläuterung:
In order to support the File Safe Shutdown procedure, a simple script should be stored on
the RaspberryPi®. There are many simple scripts concerning this matter, which can be easily
found over the internet; however, we provide one example that can be easily implemented.
Scripts could be divided into two basic categories:
Interrupt based
Loop based.
Das mitgelieferte Script picofssd.py scheint wohl loop based zu sein. Zumindest das Ereignis "Strom weg, jetzt hänge ich am Akku" (und alarmiere über FHEM den Rest der Welt) kann man aber vielleicht auch über Interrupts erkennen lassen. FHEM hat ja RPI_GPIO mit Interrupt-Attribut. Auf jeden Fall noch viel zum Herumprobieren :D
so,
also die 0x59 läuft bei mir nur wenn ich den raspi mit 950mhz, core_freq 250, sdram_freq 450 und over_voltage 6 betreibe.
wenn die corefrequenz höher wird (450mhz) dann wird die ups-pico auf dem i2c bus nicht mehr erkannt ..
ein reset der ups hilft nur kurzzeitig, dann ist die ups auf dem bus wieder verschwunden.
kann jemand dieses phänomen erklären ?
LG Rainer
Probleme mit der Stromversorgung? Hast du es mal mit einem anderen Netzteil versucht?
ich habe nur 2A netzteile da ... bei allen dreien das gleiche bild ...
vielleicht hängt es auch damit zusammen dass ich zwei usb sticks drin habe.
1xCUL und 1x HM-CFG-USB
aber wenn ich die anderen firmwares (0x38 oder 0x4a) nehme funtioniert das ganze.
ist da irgendetwas anders gemacht bei den firmwares ?
Leider ist mein englisch nicht so gut , so daaa ich immer auf onkel google zurück greifen muss und da kommen manchmal die dinge nicht ganz soo rüber wie es sein sollte :-\
na ich warte mal auf mein neues Netzteil welches wol 3A liefern soll ... dann gehts nochmal ans probieren.
Was ich gesehen habe dass die RPI spannung beim nichtladen immer so um die 5.05 volt ist (sollte ausreichen, oder )
beim laden des Akkus sackt die ab auf min 4,88 volt .. reicht das auch noch aus ?
lg rainer
vielleicht hat noch einer mehr ahnung von der UPS-PIco.
irgendwie piepst die ab und zu einmal . mal nach ne haöben stunde mal nach einigen stunden.
Leider kann ich im log oder an den LED's nichts erkennen warum der buzzer einmal piepst.
Gibt es irgendwo eine Übersicht bei welchen Zuständen der Buzzer piepst wenn er auf automatic steht ?
LG Rainer
Ich habe zu der Buzzer-Automatik-Logik auch schon erfolglos nach einer Dokumentation gesucht... Daher kann ich nur soviel sagen: Bei mir gibt der Buzzer im laufenden Betrieb keinen Pieps von sich, bis die Netzspannung weg ist und er auf Battery-Mode umschaltet (und beim Umschalten/Neustart, wenn die Netzspannung wieder da ist).
Kann es sein, dass du Spannungsschwankungen im normalen Netzteil-Betrieb hast und die Pico UPS dann aus dem Tritt kommt und für einen Sekundenbruchteil auf Batterie-Modus umschaltet? Möglicherweise passiert das genau während des Polling-Intervals, so dass im log nichts steht.
Ist aber auch nur Spekulation. Hier läuft alles ohne jeglichen Mucks und Pieps...
Hallo,
ich habe das gleiche Modul. Es funktioniert auch. Kann es über Scripte in der Shell ansprechen und es gibt mir entsprechende Rückmeldungen.
Jetzt habe ich die 98_UPSPICO.pm aus dem Post
Zitat29 Januar 2016, 18:36:05
eingespielt und fhem.cfg laut pdf bestückt.
Dann neu gestartet. Leider bleiben die Readings leer. Im Log steht immer nur
2016.02.23 10:05:52 1: USV:
2016.02.23 10:05:52 1: USV:
2016.02.23 10:06:07 1: USV:
2016.02.23 10:06:07 1: USV:
2016.02.23 10:06:07 1: USV:
2016.02.23 10:06:07 1: USV:
2016.02.23 10:06:07 1: USV:
2016.02.23 10:06:07 1: USV:
2016.02.23 10:06:07 1: USV:
2016.02.23 10:06:07 1: USV:
2016.02.23 10:06:07 1: USV:
2016.02.23 10:06:07 1: USV:
2016.02.23 10:06:07 1: USV:
2016.02.23 10:06:07 1: USV:
2016.02.23 10:06:10 1: USV:
2016.02.23 10:06:10 1: USV:
2016.02.23 10:06:10 1: USV:
2016.02.23 10:06:10 1: USV:
2016.02.23 10:06:10 1: USV:
2016.02.23 10:06:10 1: USV:
2016.02.23 10:06:10 1: USV:
2016.02.23 10:06:10 1: USV:
2016.02.23 10:06:10 1: USV:
2016.02.23 10:06:10 1: USV:
2016.02.23 10:06:10 1: USV:
2016.02.23 10:06:10 1: USV: usw.
perl /root/testpicosmbus.pl
===========================
Testing SMBus with UPS PIco
0x69 ->UPS PIco Module Status Registers Specification
1) mode: 1, vbat: 1058, vrpi: 1287, tbat: 39
2) mode: 1, vbat: 4.22 V, vrpi: 5.07 V, tbat: 27 °C
0x6A -> UPS PIco RTC Registers Direct Access Specification
1) 1, 1, 0, 18, 1, 9
2) 01.01.2000 12:01:09
0x6B -> UPS PIco Module Commands
1) ErrCode: 0, fssd_batime: 69, bmode: 2
= the end =================
Was mache ich falsch?
Greets
Byte
Was sagt "list usv"? Ist Device::SMBus installiert?
Internals:
CHANGED
NAME USV
NR 100
SMBus_exists 1
STATE PowerSource / VoltageBAT V / VoltageRPI V / BatTemp °C
TYPE UPSPICO
Readings:
Attributes:
poll_interval 15
room BASIS,Server,USV
stateFormat PowerSource / VoltageBAT V / VoltageRPI V / BatTemp °C ZitatIst Device::SMBus installiert?
Ich denke, sonst gäbe es ja eine Fehlermeldung. Kann man hier etwas falsch konfigurieren?
Wie gesagt, testpicosmbus.pl ergibt ja sinnvolle Werte! (siehe Vorpost)
Greets
Byte
Vielleicht ein Rechte-Problem? Wenn du als Root-User mittels Kommandozeilen-Script auf das USV Modul zugreifen kannst, muss das nicht zwangsläufig auch für den FHEM-User gelten.
Bei mir sieht das so aus:
pi@raspberrypi:~ $ groups fhem
fhem : dialout mail i2c gpio
Hi,
bei mir ähnlich
Zitatgroups fhem
fhem : dialout i2c
su -l fhem
fhem@raspberrypi:~$ perl /tmp/testpicosmbus.pl
===========================
Testing SMBus with UPS PIco
0x69 ->UPS PIco Module Status Registers Specification
1) mode: 1, vbat: 1058, vrpi: 1288, tbat: 40
2) mode: 1, vbat: 4.22 V, vrpi: 5.08 V, tbat: 28 °C
0x6A -> UPS PIco RTC Registers Direct Access Specification
1) 1, 1, 0, 33, 53, 41
2) 01.01.2000 21:35:29
0x6B -> UPS PIco Module Commands
1) ErrCode: 0, fssd_batime: 69, bmode: 2
= the end =================
ging auch, also vermutlich kein Zugriffsproblem.
Wo ist denn die aktuellste 98_UPSPICO.pm oder wie erkenne ich sie?
(in meiner steht v1.009 14.06.2015 by pbo )
Greets Byte
Kannst du denn als FHEM-User über die Linux-Kommandozeile auf das USV-Modul zugreifen? Ich meine mich zu erinnern, irgendwo gelesen zu haben, dass es bei manchen Distributionen nicht reicht, den FHEM-User in die entsprechenden Gruppen zu stecken. Ansonsten würde ich nochmal die python-SMbus-Installation überprüfen.
Hi,
wie oben beschrieben, als fhem-user angemeldet und das "testpicosmbus.pl" gestartet und entsprechende Werte erhalten!
Greets
Byte
Im Log sind allerdings einige Warnungen:
2016.02.23 20:32:09 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/98_UPSPICO.pm line 138.
2016.02.23 20:32:09 1: USV:
2016.02.23 20:32:09 1: PERL WARNING: Use of uninitialized value $rawPwrSrc in numeric lt (<) at ./FHEM/98_UPSPICO.pm line 428.
2016.02.23 20:32:09 1: PERL WARNING: Use of uninitialized value $rawPwrSrc in numeric eq (==) at ./FHEM/98_UPSPICO.pm line 430.
2016.02.23 20:32:09 1: PERL WARNING: Use of uninitialized value $rawPwrSrc in numeric eq (==) at ./FHEM/98_UPSPICO.pm line 431.
2016.02.23 20:32:09 1: USV:
2016.02.23 20:32:09 1: PERL WARNING: Use of uninitialized value $rawCharg in numeric lt (<) at ./FHEM/98_UPSPICO.pm line 435.
2016.02.23 20:32:09 1: PERL WARNING: Use of uninitialized value $rawCharg in numeric gt (>) at ./FHEM/98_UPSPICO.pm line 435.
2016.02.23 20:32:09 1: PERL WARNING: Use of uninitialized value $rawCharg in numeric eq (==) at ./FHEM/98_UPSPICO.pm line 437.
2016.02.23 20:32:09 1: PERL WARNING: Use of uninitialized value $rawCharg in numeric eq (==) at ./FHEM/98_UPSPICO.pm line 438.
2016.02.23 20:32:09 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/98_UPSPICO.pm line 156.
2016.02.23 20:32:09 1: USV:
2016.02.23 20:32:09 1: USV:
2016.02.23 20:32:09 1: USV:
2016.02.23 20:32:09 1: USV:
2016.02.23 20:32:09 1: USV:
2016.02.23 20:32:09 1: PERL WARNING: Use of uninitialized value $ErrCode in sprintf at ./FHEM/98_UPSPICO.pm line 458.
2016.02.23 20:32:09 1: USV:
2016.02.23 20:32:09 1: USV:
2016.02.23 20:32:09 1: USV:
2016.02.23 20:32:09 1: USV:
2016.02.23 20:32:09 1: USV:
Hi,
jetzt läuft es, habe ein Firmware update auf die 0x59 gemacht, jetzt stehen dort readings!
Super, danke!
Wie wäre eine elegante Möglichkeit auf das Umschalten auf Batteriebetrieb zu triggern?
Ein notify gibt es hierfür nicht, oder?
Mir fiele nur ein timer ein, der ständig das Reading ausliest (at)...
Greets
Byte
Ich habe es noch nicht ausprobiert, aber geht ein Notify auf PowerSource wirklich nicht? Im Eventmonitor erzeugt das Device doch regelmäßige Events.
Hi,
habe ich gerade auch bemerkt, habe es wie folgt gelöst:
USV:.* {
if("$EVENT" =~ m/PowerSource:\sBAT/) {
if ( Value("USV_Batteriebetrieb") eq "off") {
#-- Hier ist ein Zustandswechsel sicher, da zuvor gegenteiliger Zustand!
SendSMS(1,'FHEM Stromausfall!', 'WARNUNG:'); }
if ( Value("USV_Batteriebetrieb") ne "on") {
#-- Zustand war zuvor off oder ???
fhem "set USV_Batteriebetrieb on";
Log3 undef,3,"USV ist auf Batteriebetrieb gewechselt!";
}
}
if("$EVENT" =~ m/PowerSource:\sRPI/) {
if ( Value("USV_Batteriebetrieb") eq "on") {
#-- Hier ist ein Zustandswechsel sicher, da zuvor gegenteiliger Zustand!
SendSMS(1,'FHEM Strom ist wieder da!', 'Hinweis:'); }
if ( Value("USV_Batteriebetrieb") ne "off") {
#-- Zustand war zuvor on oder ???
fhem "set USV_Batteriebetrieb off";
Log3 undef,3,"USV ist auf Normalbetrieb gewechselt!";
}
}
}
Habe gesehen, in der neuesten Firmware von Januar (0x59 26.01.2016) gibt es ein "Zählregister" was anzeigt, ob die Firmware noch aktiv ist oder abgestürtzt ist.
http://www.pimodules.com/_zip/UPS_PIco_Firmware_Update.zip
Ist einfach ein Zähler, der hochgezählt wird, also bei 2 nacheinanderfolgenden Abfragen verschiedene Werte geben sollte.
Könnte man doch einfach noch einbauen. Ich möchte hier kein Copyright verletzten, daher die Anfrage an den Modulersteller...
Im Falle eines Absturzes der USV könnte man eine Nachricht bekommen (ein Neustart geht vermutlich nur per Taster am Gerät)...
Eine Frage noch:
Habe den 3000mAh Akku, seit Tagen steht dort Charging ON und die Spannung auf ca 4.22 V
Ist das normal, oder sollte er irgendwann voll sein und Chargin OFF ??
Greets
Byte
Zitat von: Bytechanger am 25 Februar 2016, 14:21:34
Habe den 3000mAh Akku, seit Tagen steht dort Charging ON und die Spannung auf ca 4.22 V
Ist das normal, oder sollte er irgendwann voll sein und Chargin OFF ??
Eher nicht, siehe hier (http://www.forum.pimodules.com/viewtopic.php?f=19&t=375). Vielleicht wird das in künftigen Firmwares mal etwas geschickter gelöst:
0x01 - means Charger is ON
If the CHG LED is not lit, means that charger is ON, but battery is fully charged
0x00 - means Charger is OFF
Was bedeutet
Zitateher nicht
?
Eher nicht normal, oder ist es normal, dass chargin immer auf on steht?
Die Pico_run Geschichte hab ich mal in die Readings eingebaut und teste damit mal...
Greets
Byte
Charger ist eigentlich immer on, solange die USV nicht auf Akku läuft (und nix kaputt ist). Wenn der Akku voll ist, bleibt CHG on, aber die LED erlischt.
Hallo,
seit dem ich den I2C Bus nutze - mit dem UPSPICO Modul und dem Modul von FHEM erscheinen bei mir im Log unerklärliche Fehlermeldungen.
2016.02.07 21:42:15.432 1: Including /opt/fhem/fhem.save
2016.02.07 21:42:19.739 2: FB_CALLMONITOR (FritzCallMon) - read 32 contacts from remote phonebook "Telefonbuch"
2016.02.07 21:42:20.038 1: usb create starting
2016.02.07 21:42:26.131 1: usb create end
2016.02.07 21:42:26.200 2: SecurityCheck: WEB,WEBK,WEBP,WEB_Selfhost_TabletUI,WEB_andFHEM,WEBphone has no associated allowed device with basicAuth. l
2016.02.07 21:42:26.224 0: Featurelevel: 5.7
2016.02.07 21:42:26.247 0: Server started with 609 defined entities (fhem.pl:10727/2016-02-05 perl:5.014002 os:linux user:fhem pid:2708)
2016.02.07 21:42:26.328 1: PERL WARNING: Use of uninitialized value $rawPwrSrc in numeric eq (==) at ./FHEM/98_UPSPICO.pm line 413.
2016.02.07 21:42:26.351 1: PERL WARNING: Use of uninitialized value $rawPwrSrc in numeric eq (==) at ./FHEM/98_UPSPICO.pm line 414.
2016.02.07 21:42:26.380 1: PERL WARNING: Argument "ffffffffffffffff" isn't numeric in division (/) at ./FHEM/98_UPSPICO.pm line 418.
2016.02.07 21:42:26.408 1: PERL WARNING: Argument "ffffffffffffffff" isn't numeric in division (/) at ./FHEM/98_UPSPICO.pm line 422.
2016.02.07 21:42:26.609 1: Perfmon: possible freeze starting at 21:41:41, delay is 45.609
2016.02.07 21:42:27.592 1: PERL WARNING: Use of uninitialized value $FW_ME in concatenation (.) or string at ./FHEM/01_FHEMWEB.pm line 2165.
Error: Read failed
Error: Read failed
Error: Read failed
2016.02.07 21:42:28.603 1: HMLAN_Parse: HM_USB new condition ok
Error: Read failed
Error: Read failed
Error: Read failed
2016.02.07 21:42:29.879 1: Perfmon: possible freeze starting at 21:42:27, delay is 2.879
Error: Read failed
Error: Read failed
Error: Read failed
2016.02.07 21:42:40.616 1: Perfmon: possible freeze starting at 21:42:32, delay is 8.616
Zudem kommen ab und zu mal unsinnige Werte über den I2C-Bus. habe ich auch schon direkt auf der Konsole provozieren können.
Gibt es eine Einstellung für I2C welche das ganze sicherer macht im Zusammenhang mit der UPSPICO?
habe schon in allen Quelldateien von FHEm nach dem Fehler gesucht, aber nix gefunden.
Weiss jemand woher der Fehlerkommt?
Die üblichen Fehlerquellen (Firmware? Netzteil?) gecheckt? Wenn es nur "ab und zu" unsinnige Werte gibt, hat vielleicht das Netzteil Probleme mit Spannungsschwankungen und die USV ist verwirrt....
BTW: Es gibt seit gestern für die UPS Pico eine neue Firmware (0x5C), die man im pimodules-Forum (http://www.forum.pimodules.com/viewtopic.php?f=19&t=375) herunterladen kann.
Hallo,
ich hatte gestern auch das Erlebnis, dass die Pico Firmware gesponnen hat. Sie meldete bei einem Reading plötzlich, dass Batteriebetrieb vorläge und die Firmware würde hängen (Pico_run gleich).
Daher habe ich mein Notify angepasst, dass es mehrere Readings geben muss, bis Alarm ausgelöst wird.
USV:.* {
if (Value("USV_Batteriebetrieb")!~ /^\d+$/) {
fhem "set USV_Batteriebetrieb 0";
}
my $bat=int(Value("USV_Batteriebetrieb"));
if("$EVENT" =~ m/PowerSource:\sBAT/) {
$bat=$bat+1;
fhem "set USV_Batteriebetrieb $bat";
if ($bat==3) { SendSMS(0,'FHEM Verdacht des Stromausfalls!', 'Verdacht:'); }
}
if("$EVENT" =~ m/PowerSource:\sRPI/) {
fhem "set USV_Batteriebetrieb 0";
if ($bat>=3) { SendSMS(1,'FHEM Strom ist wieder da!', 'Hinweis:'); }
}
if("$EVENT" =~ m/VoltageBAT:/) {
#Zustand Batterie, bei 3.15 V wird der Raspi automatisch heruntergefahren !! ---
if (ReadingsVal("USV", "VoltageBAT", "99") < 3.3 && ReadingsVal("USV", "PowerSource", "99") eq "BAT")
{
if ( Value("USV_BatterieCritical") eq "off") { SendSMS(1,'FHEM: Notstromversorgung wird kritisch schwach!', 'WARNUNG:'); }
if ( Value("USV_BatterieCritical") ne "on") { fhem "set USV_BatterieCritical on"; }
}
else {
if ( Value("USV_BatterieCritical") ne "off") { fhem "set USV_BatterieCritical off"; }
}
}
if("$EVENT" =~ m/Pico_run:/) {
if (Value("USV_FirmwareRunning")!~ /^\d+$/) {
fhem "set USV_FirmwareRunning 0";
}
my $run=int(Value("USV_FirmwareRunning"));
if (ReadingsVal("USV", "Pico_run", "99") eq "running") {
fhem "set USV_FirmwareRunning 0";
}
if (ReadingsVal("USV", "Pico_run", "99") ne "running") {
$run=$run+1;
fhem "set USV_FirmwareRunning $run";
if ($run==3) { SendSMS(1,'FHEM: Notstromversorgung Fehler in der Firmware!', 'WARNUNG:'); }
}
}
}
Greets
Byte
Guter Ansatz, setzt aber voraus, dass das USV-Device bei jedem poll ein Event erzeugt? Mir war das zu viel "Geplauder", weshalb ich dem USV-Device ein event-on-change-reading-Attribut verpasst habe, so dass es nur dann ein (einmaliges) Event erzeugt, wenn sich ein Reading auch ändert.
Das (bei mir nur einmalige) Event bei einer Änderung von PowerSource auf BAT will ich mit DOIF mit den Attributen wait und do resetwait entsprechend zeitverzögert auswerten (also Alarm erst, wenn sich innerhalb der wait-Zeitspanne PowerSource nicht wieder ändert). Bin aber gerade noch im Lernstadium, was die Leistungsfähigkeit von DOIF angeht. Meine ersten Versuche in anderem Kontext (Heizungssteuerung) sind aber vielversprechend.
Hallo, hört sich gut an, wie hast Du es gelöst?
Wäre das ein Ansatz, oder habe ich da einen Denkfehler drin, mit DOIF habe ich noch nicht so viel gearbeitet!
define do_USV_BattBetrieb DOIF ([USV:PowerSource] eq "BAT") (\
{\
SendSMS(0,'FHEM Verdacht des Stromausfalls!', 'Verdacht:');;\
fhem "set USV_Batteriebetrieb on";;\
})\
DOELSEIF ([USV:PowerSource] eq "RPI")(\
{\
if ( Value("USV_Batteriebetrieb") eq "on") { SendSMS(1,'FHEM Strom ist wieder da!', 'Hinweis:');; }\
fhem "set USV_Batteriebetrieb off";;\
})
attr do_USV_BattBetrieb wait 30:30
define do_USV_Firmware DOIF ([USV:Pico_run] ne "running") (\
{\
SendSMS(1,'FHEM: Notstromversorgung Fehler in der Firmware!', 'WARNUNG:');;\
fhem "set USV_FirmwareRunning off";;\
})\
DOELSEIF ([USV:Pico_run] eq "running")(\
{\
fhem "sset USV_FirmwareRunning on";;\
})
attr do_USV_Firmware wait 30:30
define do_USV_BatVolt DOIF ([USV:VoltageBAT] < 3.3 AND [USV:PowerSource] eq "BAT") (\
{\
SendSMS(1,'FHEM: Notstromversorgung wird kritisch schwach!', 'WARNUNG:');;\
fhem "set USV_BatterieCritical on";;\
})\
DOELSE (\
{\
fhem "set USV_BatterieCritical off";;\
})
attr do_USV_BatVolt wait 10:10
Greets
Byte
Wozu ist denn das Device USB_Batteriebetrieb und dessen Abfrage innerhalb von DOIF? Ergibt sich nicht schon aus USV:PowerSource = "BAT", dass das Device auf Batteriebetrieb ist? Nur als Bedingung für die Meldung "Strom wieder da" (nur, wenn PowerSource=RPI und USB_Batteriebetrieb=on) scheint mir das entbehrlich zu sein, weil das DOIF ja ohnehin nur bei PowerSource=RPI oder BAT triggert.
Um zu verhindern, dass "Strom wieder da" zu früh gesendet wird, also z.B. wenn der Strom zwar kurz wieder da ist, aber dann wieder weg ist (innerhalb der 30 Sekunden-Zeitspanne des wait-Attributs), kann man auch das repeatsame-Attribut verwenden. Dann wird beim Event "BAT" einmalig die Nachricht "Strom weg!" geschickt, wenn sich innerhalb von 30 Sekunden nichts ändert. Die nächste Nachricht kommt dann erst wieder (nämlich "Strom wieder da!"), wenn das Event "RPI" länger als 30 Sekunden bestehen bleibt.
Bei mir sieht das so aus (mit event-on-change-reading .*-Attribut im USV-Device):
DEF
([USV:PowerSource] eq "BAT") (set jabber msg xxxx@xxxx.xxx FHEM: Pico USV seit 30 Sek. auf BAT)
DOELSEIF
([USV:PowerSource] eq "RPI") (set jabber msg xxxx@xxxx.xxx FHEM: Pico USV seit 30 Sek. auf RPI)
Attributes:
do resetwait
repeatsame 1:1
wait 30:30
Hallo,
danke für die Infos. Die Dummys sind noch aus der alten Zeit, damit eine Nachricht nur einmal, bei Zustandswechsel raus geht.
Ist bei DOIF nicht mehr erforderlich.
Ich programmiere zwar in anderen Sprachen, finde die Doku aber etwas un-/missverständlich, was die DOIF Attribute angeht.
Könntest Du mir die hier erklären:
wait ist klar: bei notify wird die Wartezeit gewartet, dann geprüft, ob Bedingung erfüllt ist...
do resetwait ??
repeatsame ??
Auf welchen Pollintervall hast Du die USV Abfrage?
Ist meine Kontrolle der Batteriespannung OK, oder kann man sie verbessern (Hintergrund ist, dass ich eine Nachricht bekomme, bevor Gerät endgültig aus geht)...
Greets
Byte
Zitat von: Bytechanger am 29 Februar 2016, 18:05:52
danke für die Infos. Die Dummys sind noch aus der alten Zeit, damit eine Nachricht nur einmal, bei Zustandswechsel raus geht.
Ist bei DOIF nicht mehr erforderlich.
Ah, dachte ich mir doch.
Zitat
Ich programmiere zwar in anderen Sprachen, finde die Doku aber etwas un-/missverständlich, was die DOIF Attribute angeht.
Könntest Du mir die hier erklären:
wait ist klar: bei notify wird die Wartezeit gewartet, dann geprüft, ob Bedingung erfüllt ist...
do resetwait ??
repeatsame ??
Nun ja, ich programmiere eigentlich überhaupt nicht, sondern wusele mich so durch, das meiste eher nach trial and error... Macht aber nichts, da ich mir des Risikos, dass etwas nicht so läuft, wie es soll, bewusst bin und ich mich da sehendes Auges, aber erhobenen Hauptes hineinstürze (würde mich zwar ärgern, wenn ich mal z.B. versehentlich die Heizung via ebus schrotte, weil ich einen Parameter unwissentlich falsch einstelle und das Teil abraucht, aber... no risk no fun :-)).
Meine Interpretation der o.g. DOIF-Attribute: do resetwait setzt den Timer zurück, wenn dasselbe Event nochmals kommt.
Interessanter ist repeatsame. Im o.g. Beispiel "1:1" führt es dazu, dass jedes der beiden Kommandos (Nachricht "BAT" / Nachricht "RPI") immer nur ein einziges Mal ausgeführt wird, egal wie oft das dazugehörige Event eintritt, und dann erst wieder, wenn zwischenzeitlich das andere Kommando einmal ausgeführt worden ist. Ich habe das mühselig herausgefunden, als ich die eigentlich sehr simple Aufgabenstellung lösen wollte "Wohnzimmertür 30 Sek. lang auf = eingestelltes Heizprogramm speichern und Heizung aus" + "Wohnzimmertür 30 Sek. lang zu = Heizung mit vorherigem Heizprogramm wieder an".
Auslösendes Event ist ein Magnetschalter, der auf 0 oder 1 geht, wenn die Tür geöffnet bzw. geschlossen wird. Das Problem bestand trotz (oder eher wegen) "wait 30" darin, dass das Event "Tür auf" auch dann triggert, wenn die offene Tür nach dreißig Sekunden mal kurz geschlossen wird und dann wieder geöffnet wird und offen stehen bleibt. Im Grunde ist das ja egal, wenn dann der Befehl "Heizung aus" nochmals ausgeführt wird, allerdings merkt sich das DOIF beim ersten Tür-Auf-Event das zuvor eingestellte Heizungsprogramm... Würde das dann zweimal hintereinander ausgeführt, bleibt es auf "Standby" stehen.
Ich habe lange mit Dummy-Variablen rumprobiert, bis ich auf das ziemlich geniale repeatsame gestoßen bin. Dadurch wird derselbe Befehl immer nur (höchstens) x-Mal hintereinander ausgeführt = bei repeatsame 1:1 geht es zwangsweise immer nur abwechselnd. Hat sich in der Praxis als sehr hilfreich erwiesen, weil das Heizprogramm, das vor dem Lüften eingestellt war, auch dann wieder zuverlässig gesetzt wird, wenn der Wind (oder - wahrscheinlicher - die Kinder) die Tür beim Lüften mal kurz zuschlagen und dann innerhalb von 30 Sekunden wieder öffnen... Nun ja, viel Aufwand für wenig Nutzen, aber der Fun-Faktor und meine Begeisterung über repeatsame waren es mir wert :-)
Zitat
Auf welchen Pollintervall hast Du die USV Abfrage?
15 Sekunden. Aber ich habe auch nur einen 450er-Akku. Das Poll-Intervall sollte daher tunlichst kürzer sein als dessen Laufzeit :-)
Insgesamt gefällt mir das ganze Gepolle aber auch nicht so richtig. Über event-on-change-reading kann man zwar etwas Ruhe in die Log-Files bringen, aber lieber wäre mir eine Interrupt-Lösung. "Ioannis", der nach meinem Eindruck der einzige Entwickler bei pimodules ist, hat mir geschrieben, er fände das auch besser und wolle es künftig mal umsetzen. Wann das sein wird, weiß aber keiner.
Zitat
Ist meine Kontrolle der Batteriespannung OK, oder kann man sie verbessern (Hintergrund ist, dass ich eine Nachricht bekomme, bevor Gerät endgültig aus geht)...
Habe ich nicht getestet (und kann ich "auf dem Papier" mangels ausreichender Programmierkenntnisse leider auch nicht ohne Test beurteilen). Für mich besteht da wegen des kleinen Akkus auch kein richtiger Nutzwert. Sobald die Stromversorgung länger als 30 Sek. weg ist, soll der Raspi das Nötige schnellstmöglich veranlassen: Nachricht schicken, vielleicht vorher noch prüfen, ob andere Geräte noch Strom haben... z.B. Abfrage bei den Z-Wave Wall Plugs und das Ergebnis mitteilen... dann kann und soll er erstmal runterfahren. Die UPS Pico fährt ihn ja wieder hoch, wenn wieder Strom da ist. Eine großartige Wartezeit muss der kleine Akku dann nicht überbrücken.
Naja, wie schon an anderer Stelle gesagt: Nette Spielereien, eine Herz-Lungen-Maschine würde ich da aber nicht dranhängen.
Danke für die ausführliche Antwort.
Mit der Tür/Fenster hört sich interessant an und könnte ich, wenn ich es richtig verstanden habe, auch für meinen "EinbruchAlarm" verwenden.
Szenario ist folgendes: Habe eine Terrassentür mit Griffkontakt und Öffnungskontakt.
Der Griffkontakt meldet etwa 3 Sekunden zeitverzögert seinen Zustand.
Wenn nun der Öffnungskontakt "offen" meldet, sollte der Türkontakt auf "offen" sein, sonst wurde die Tür aufgehebelt!
Das würde ich gerne mit DOIF lösen. Also Öffnungskontakt>"offen"->10 Sekunden warten->Griffkontakt prüfen...
Sollte in der Zwischenzeit die Tür nochmals geschlossen und wieder geöffnet werden, 10 Sekunden erneut warten...
(Kinder)
Greets
Byte