S.USV Daten und Befehle per FHEM

[Grinsekatze]

Hm, ich habe mal ein Firmwareupdate gemacht auf Version 2.20. "./susv -status" läuft nun durch. Lediglich zeigt er mir nicht an, wie Stark die Batterie ist:

Power Battery: 000.00 mA

Ich habe jedoch 3000 mA verbaut.

[Grinsekatze]

Hm, ich werde hier nicht schlau.   

Kann bitte mal Jemand posten, wie ich das Device in FHEM anlegen kann?

Soweit ich verstanden habe, muss ich zunächst in der Konsole diese zwei Kommandos eingeben um die Rechte zu gewähren:

Code Auswählen Erweitern

sudo adduser fhem i2c
sudo adduser fhem gpio

Danach muss in FHEM das Repository hinzugefügt werden und das Modul heruntergeladen werden:

Code Auswählen Erweitern

update add http://www.wallmeier.net/fhem/controls_I2C_SUSV.txt
update
shutdown restart

Nach dem Neustart habe ich jedoch noch kein SUSV Device.
Wenn ich es von Hand definiere (define SUSV I2C_SUSV), dann bekomme ich nur diese Internals:

Code Auswählen Erweitern

CHANGED
I2C_Address 15
NAME SUSV
NR 718
STATE defined
TYPE I2C_SUSV
und ein Reading:

Code Auswählen Erweitern


Pinlevel low 2017-04-02 20:02:10

Auch ein "get SUSV updateValues" hilft da nicht weiter. Irgend etwas übersehe ich also.

[Wallmeier]

Wie bei allen Modulen, die mit I2C_ anfangen, kommunizieren diese nicht direkt mit dem I2C-Bus sondern über das Modul RPII2C. Somit muss erst eine Instanz von RPII2C erzeugt/definiert werden. Wenn diese Instanz erst nach der Definition I2C_SUSV gemacht wird, muss noch das Attribut IODev passend gesetzt werden.

Zu beachten ist weiterhin, dass das RPII2C-Modul im Modus IOCTL betrieben wird. Dies kann man erzwingen, indem man bei der RPII2C-Instanz das Attribut useHWLib auf IOCTL setzt.

[Grinsekatze]

Danke,
das IODev hatte ich inzwischen eingerichtet (define RPII2C_1 RPII2C 1). Die 1 zu finden war zunächst etwas schwierig, wenn man noch nie mit dem I2C-Bus gearbeitet hat.

Anschließend hatte ich auch das IODev angegeben (attr SUSV IODev RPII2C_1). Das wurde mir aber mit einem Fehler quittiert: "Undefined subroutine &main::I2C_SUSV_Init called". Vermutlich, weil ich nicht den IOCTL-Modus fürs IODev benutzt habe. Ich hatte zwar bereits hier gelesen, dass der Modus notwendig ist, jedoch noch nicht gewusst, wie ich ihn erzwinge.

Meine RPII2C-Instanz kennt das Attribut useHWLib leider nicht.

[Wallmeier]

Anschließend hatte ich auch das IODev angegeben (attr SUSV IODev RPII2C_1). Das wurde mir aber mit einem Fehler quittiert: "Undefined subroutine &main::I2C_SUSV_Init called".

Das war noch ein Fehler im Modul. Ist jetzt gefixed.

Meine RPII2C-Instanz kennt das Attribut useHWLib leider nicht.

Aus der Hilfe von RPII2C:
useHWLib
Ändern der Methode des Hardwarezugriffs.
Dieses Attribut existiert nur, wenn beide Zugriffsmethoden verfügbar sind
Standard: IOCTL, gültige Werte: IOCTL, SMBus

Somit wird vermutlich die Methode IOCTL benutzt.

[Grinsekatze]

Nachdem ich nochmal in der Commandref geguckt habe, dachte ich das auch schon, da ich ja beim einrichten der SUSV die i2c-tools installiert habe, nicht aber das SMBUS PERL-Modul.

Kann es vielleicht daran liegen, dass ich die Firmware 2.20 benutze?


Edit:
Ich habe im Log noch eine Fehlermeldung gefunden:

2017.04.02 21:43:52 1: PERL WARNING: Use of uninitialized value in numeric gt (>) at ./FHEM/52_I2C_SUSV.pm line 307.

[Wallmeier]

Das ist ein Folgefehler der durch den anderen Fehler entstanden ist. Am besten die Instanz vom I2C_SUSV noch einmal löschen und neu anlegen.

[Grinsekatze]

Ich hab sowohl das IO-Device als auch das SUSV-Device neu angelegt.

Beim SUSV-Device findet er nun immerhin schon mal die neuen Internals Model (Basic), Firmware (1.2) und CFGFN (ist leer). Wobei die Firmware falsch angezeigt wird. Ich habe auf 2.20 aktualisiert. Der Rest wird weiter nicht angezeigt (auch nur die Readings ChargingCircuit, ChargingCurrent und Pinlevel, wie bereits gehabt). STATE ist opened.

Als ich eben nochmal das RPII2C-Device angeguckt habe, habe ich gesehen, dass dort ein Internals Namens CFGFN ist, welches leer ist. Auf einigen Screenshots hier war dort eine CFG eingetragen. Muss ich da noch was nachholen? STATE ist OK.

Edit:
Im Log finde ich diese Einträge:

2017.04.02 23:32:37 3: SUSV: using I2C Address 15
2017.04.02 23:32:37 3: SUSV: Consider upgrading the firmware to 1.32 or greater
2017.04.02 23:32:37 1: SUSV: Test

Auch hat sich der Server eben kurz verabschiedet. Die SUSV LEDs leuchteten kurz rot und jetzt grün und orange (vorher nur 2 grüne). Die Batterie wird also wieder geladen.

Nach dem Crash sind die SUSV Internals nunModel (Advanced), Firmware (1.0) und CFGFN (ist leer). Ich habe aber eine Basic, wie gesagt mit FW 2.20.


Edit 2:
Inzwischen habe ich ein paar neue Readings bekommen: BatteryState (unknown battery state 212), PowerBattery (0), PowerExtern (n/a), PowerSource (RPI) und VoltageIn (0.51).
Jedoch stimmen die Werte hinten und vorne nicht. Laut ./susv -satus ISt das Model Basic (und nicht, wie in FHEM angegeben Advanced), Firmware ist 2.20 (und nicht 1.2), BatteryState weiss ich nicht, was damit abgebildet werden soll, VoltageIn ist 4.86 V.
Offenbar sind die Abfragen des Moduls  also fehlerhaft.

[Burny4600]

Status mit V11.3

Code Auswählen Erweitern

2017.04.04 09:12:15 3: SUSV: using I2C Address 15
2017.04.04 09:12:15 3: SUSV: Consider upgrading the firmware to 1.32 or greater
2017.04.04 09:12:15 1: SUSV: Test
2017.04.04 09:12:15 5: im init client fuer SUSV
2017.04.04 09:12:15 5: SUSV: 15 read 3 Byte from Register 53
2017.04.04 09:12:15 5: SUSV Rx, Reg: 53, Data: 53 2 20
2017.04.04 09:12:15 5: SUSV: Consider upgrading the firmware to 1.32 or greater
2017.04.04 09:13:08 5: SUSV: 15 read 3 Byte from Register 53
2017.04.04 09:13:08 5: SUSV Rx, Reg: 53, Data: 53 1 2
2017.04.04 09:13:08 5: SUSV: Consider upgrading the firmware to 1.32 or greater
2017.04.04 09:13:11 5: SUSV: 15 read 3 Byte from Register 53
2017.04.04 09:13:11 5: SUSV Rx, Reg: 53, Data: 53 1 2
2017.04.04 09:13:11 5: SUSV: Consider upgrading the firmware to 1.32 or greater
2017.04.04 09:13:12 5: SUSV: 15 read 3 Byte from Register 53
2017.04.04 09:13:12 5: SUSV Rx, Reg: 53, Data: 53 1 2
2017.04.04 09:13:12 5: SUSV: Consider upgrading the firmware to 1.32 or greater
2017.04.04 09:13:16 5: SUSV: 15 read 3 Byte from Register 53
2017.04.04 09:13:16 5: SUSV Rx, Reg: 53, Data: 53 1 2
2017.04.04 09:13:16 5: SUSV: Consider upgrading the firmware to 1.32 or greater
2017.04.04 09:13:59 5: SUSV: 15 read 3 Byte from Register 53
2017.04.04 09:13:59 5: SUSV Rx, Reg: 53, Data: 53 1 2
2017.04.04 09:13:59 5: SUSV: Consider upgrading the firmware to 1.32 or greater
2017.04.04 09:14:04 5: SUSV: 15 read 3 Byte from Register 53
2017.04.04 09:14:04 5: SUSV Rx, Reg: 53, Data: 53 1 2
2017.04.04 09:14:04 5: SUSV: Consider upgrading the firmware to 1.32 or greater
2017.04.04 09:14:17 5: SUSV: 15 read 3 Byte from Register 53
2017.04.04 09:14:17 5: SUSV Rx, Reg: 53, Data: 53 1 2
2017.04.04 09:14:17 5: SUSV: Consider upgrading the firmware to 1.32 or greater
2017.04.04 09:15:16 5: SUSV: 15 read 3 Byte from Register 53
2017.04.04 09:15:16 5: SUSV Rx, Reg: 53, Data: 53 1 2
2017.04.04 09:15:16 5: SUSV: Consider upgrading the firmware to 1.32 or greater
2017.04.04 09:15:17 5: SUSV: 15 read 3 Byte from Register 53
2017.04.04 09:15:17 5: SUSV Rx, Reg: 53, Data: 53 1 2
2017.04.04 09:15:17 5: SUSV: Consider upgrading the firmware to 1.32 or greater
2017.04.04 09:15:18 5: SUSV: 15 read 3 Byte from Register 53
2017.04.04 09:15:18 5: SUSV Rx, Reg: 53, Data: 53 1 2
2017.04.04 09:15:18 5: SUSV: Consider upgrading the firmware to 1.32 or greater
2017.04.04 09:15:18 5: SUSV: 15 read 3 Byte from Register 53
2017.04.04 09:15:18 5: SUSV Rx, Reg: 53, Data: 53 1 2
2017.04.04 09:15:18 5: SUSV: Consider upgrading the firmware to 1.32 or greater
2017.04.04 09:16:19 5: SUSV: 15 read 3 Byte from Register 53
2017.04.04 09:16:19 5: SUSV Rx, Reg: 53, Data: 53 1 2
2017.04.04 09:16:19 5: SUSV: Consider upgrading the firmware to 1.32 or greater
2017.04.04 09:17:08 5: SUSV: 15 read 3 Byte from Register 53
2017.04.04 09:17:08 5: SUSV Rx, Reg: 53, Data: 53 1 2
2017.04.04 09:17:08 5: SUSV: Consider upgrading the firmware to 1.32 or greater
2017.04.04 09:17:10 5: SUSV: 15 read 3 Byte from Register 53
2017.04.04 09:17:10 5: SUSV Rx, Reg: 53, Data: 53 1 2
2017.04.04 09:17:10 5: SUSV: Consider upgrading the firmware to 1.32 or greater
2017.04.04 09:17:20 5: SUSV: 15 read 3 Byte from Register 53
2017.04.04 09:17:20 5: SUSV Rx, Reg: 53, Data: 53 1 2
2017.04.04 09:17:20 5: SUSV: Consider upgrading the firmware to 1.32 or greater

FHEM Anzeige der S.USV

Code Auswählen Erweitern

USV Status: NETZBETRIEB
RPI maximaler Ladestrom: 300 mA
Spannungsversorgung durch: 0 mit 0.00 V
Batterie Status: 0
Batterie Kapazität: 0 %
Batterie Spannung: 0.00 V
Batterie Ladestrom extern: 0.00 mA
Internals

Code Auswählen Erweitern

CFGFN             /media/hdd/fhem/mycfg/USV/usv_rasp06.cfg
CHANGED
Firmware                   1.2
I2C_Address             15
IODev                        RPII2C_1
Model                        Advanced
NAME                        SUSV
NR                             323
RPII2C_1_SENDSTAT Ok
STATE                       USV Status: NETZBETRIEB <br> RPI maximaler Ladestrom: 300 mA <br> Spannungsversorgung durch: 0 mit 0.00 V <br> Batterie Status: 0 <br> Batterie Kapazität: 0 % <br> Batterie Spannung: 0.00 V <br> Batterie Ladestrom extern: 0.00 mA
TYPE                         I2C_SUSV

[Grinsekatze]

Ich habe gestern das device erneut angelegt. Firmware wird weiter falsch ausgegeben (1.2). Aber es wird nun die Basic erkannt.

Mal sehen, ob die Readings hinzu gekommen sind, wenn ich nachher wieder zuhause bin.


Edit:
Nein, leider hat das System dieses Mal keine neuen Readings über Nacht angelegt.
Auch ist mir aufgefallen, dass die PSU-LED grün blinkt. LAut Handbuch also die Firmware initialisiert - nun jedoch bereits seit mind. 8 Stunden. Das Blinken war gestern noch nicht der Fall.

Langsam gehen mir die Ideen aus.

[Grinsekatze]

Ich habe testweise einmal ein weiteres Device, namens test angelegt.

Dabei bin ich über diesenLogeintrag gestolpert:

2017.04.04 21:00:22 3: test: using I2C Address 15
2017.04.04 21:00:22 3: SUSV: Consider upgrading the firmware to 1.32 or greater
2017.04.04 21:00:22 1: test: Test
2017.04.04 21:00:22 1: PERL WARNING: Use of uninitialized value in numeric gt (>) at ./FHEM/52_I2C_SUSV.pm line 311.

[Grinsekatze]

Nachdem ich nun mal wieder das Device gelöscht habe, den kompletten Pi dann neu gestartet habe, blinkte die LED nicht mehr. Nun leuchtet sie grün - es ist also alles ok.

Daraufhin habe ich das Device, zunächst unter einem neuen Namen, angelegt. Ein List ergibt dies:

Internals:
   CFGFN
   CHANGED
   Firmware   2.20
   I2C_Address 15
   IODev      RPII2C_1
   Model      Basic
   NAME       SUSV
   NR         740
   RPII2C_1_SENDSTAT Ok
   STATE      opened
   TYPE       I2C_SUSV
   Readings:
     2017-04-04 21:08:27   BatteryState    unknown battery state 212
     2017-04-04 21:11:27   ChargingCircuit 71
     2017-04-04 21:09:27   ChargingCurrent 19
     2017-04-04 21:08:27   Pinlevel        low
     2017-04-04 21:11:27   PowerBattery    0
     2017-04-04 21:11:27   PowerExtern     n/a
     2017-04-04 21:08:27   PowerSource     RPI
     2017-04-04 21:11:27   VoltageIn       4.94
Attributes:
   IODev      RPII2C_1
   poll_interval 60
   room       System

BatteryState verwirrt mich noch etwas.

Auch hät ich gern die Ausgabe in deutsch, wie bei Bunny4600. @Bunny4600: Wie hast Du die deutsche Ausgabe hinbekommen?

[dieter114]

Also ich hab mit Nicos Hilfe endlich die richtigen Treiber für die Version 2.20 drauf.

Das Auslesen der Werte funktioniert zuverlässig aber sie scheinen nicht zu stimmen bzw. sich ständig zu ändern:
Der Batterie-Status ändert sich bei fast jedem Auslesen von "charged" auf unknown battery state 212
und die Eingangsspannung ändert sich von 0.51V auf 5.12V.

Gruß Wolfdieter

[Wallmeier]

Das Modul unterstützt aktuell noch nicht die Revision 2 der S-USV.

Da ich mittlerweile eine Revision 2 vom Hersteller zur Verfügung gestellt bekommen habe, bin ich dran an dem Thema. Mein aktueller Entwicklungsstand sieht schon bedeutend besser aus als der veröffentliche Stand. Allerdings habe ich noch ganz vereinzelte Peaks/Abweichungen - das muss ich noch näher untersuchen, bevor ich die Version veröffentlichen werde.

[Wallmeier]

Insgesamt scheint die I2C-Kommunikation mit der Revision ein bisschen "wackliger" zu sein als bei der Revision 1. Wie ich schon im letzten Beitrag geschrieben, lese ich teilweise falsche Werte aus. Damit in den Graphen keine unschönen Peaks entstehen, passiert jetzt noch eine Plausibilitätsprüfung im Modul, um diese Situationen zu identifizieren und die ungültigen Werte zu verwerfen.

Generell funktioniert das Auslesen der Batteriespannung bei der Revision 2 noch gar nicht. Das Hersteller-Tool susv benutzt dafür nicht dokumentierte I2C-Register und nicht das dokumentierte Register 0xD3. Ich habe das Problem bereits dem Hersteller geschildert und gehe davon aus, zeitnah eine Antwort zu erhalten.

Den aktuellen Stand des Moduls habe ich gerade auf meinen Update-Server gelegt...