USV für Raspberry Pi

rainer1962 · 01 Februar 2016, 20:03:23

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

alpha1974 · 01 Februar 2016, 20:40:58

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..."

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

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

rainer1962 · 01 Februar 2016, 21:51:57

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

alpha1974 · 02 Februar 2016, 08:12:35

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) 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"

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).

rainer1962 · 02 Februar 2016, 09:09:53

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.

Code Auswählen


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.

rainer1962 · 02 Februar 2016, 09:20:24

hier noch mal die meldungen wenn ich die 0x59 versuche zu installieren:

Code Auswählen


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 ..

alpha1974 · 02 Februar 2016, 14:52:02

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 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.

rainer1962 · 03 Februar 2016, 12:29:02

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.

Code Auswählen


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

alpha1974 · 03 Februar 2016, 16:24:03

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:

Code Auswählen

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

rainer1962 · 03 Februar 2016, 18:31:29

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

alpha1974 · 03 Februar 2016, 18:58:15

Probleme mit der Stromversorgung? Hast du es mal mit einem anderen Netzteil versucht?

rainer1962 · 03 Februar 2016, 19:30:13

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

rainer1962 · 04 Februar 2016, 21:10:03

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

alpha1974 · 04 Februar 2016, 22:20:07

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...

Bytechanger · 23 Februar 2016, 10:21:28

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

Code Auswählen

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.

Code Auswählen


 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