Modul für Victron BMV600 / BMV602 / BMV700 / BMV702 / MPPT / Inverter

[MadMax-FHEM]

Hallo in die Runde

Ich habe mir auch einen MPPT Laderegler 75/15 zugelegt, in der Annahme ihn hierüber steuern zu können...

Mein Aufbau:

Netzteil -> MPPT -> Akku
(ja nicht direkt aus Solar laden / evtl. ändert sich das aber noch)

Ich habe auch schon mit Venus-OS rumgespielt, da kann/könnte ich zwar einstellen was ich will aber irgendwie nicht über fhem (auch nicht per mqtt: zu doof?   ).

Ich habe mir so ein USB-VEDirect-Kabel gebastelt: geht prima
(aktuell auch ein LAN-TTL, da der Laderegler nicht direkt an mein fhem kommt, geht auch prima / ESP-Bridge ging nicht, vermute mal wegen Latenz?)

Also ich kann mit dem Modul Werte lesen
(es gibt noch ein paar Warnings, evtl. schaue ich mir das mal an oder setze verbose   )

Was ich steuern kann: an/aus

Leider kann ich keinen Ladestrom etc. einstellen
Das ginge über VenusOS, allerdings nur indirekt (so sieht es aus), es begrenzt einfach "generell"...

Achja, Frage: kann ich das beim 75/15 generell nicht einstellen bzw. was kann ich einstellen (bzw. sollte ich können) und was nur "sehen"?
(also ja: get vs. set aber wie geschrieben machen bei mir die set nicht wirklich was [bzw. "merke" ich davon nichts"], außer eben charge on/off)
EDIT: gibt es eine Doku, wo ich das rauslesen könnte?

EDIT: so ich habe mich ein wenig damit beschäftigt. Klasse! Was ich will/wollte geht! Allerdings fehlt beim setzen von Battery_maximum_current ein Eingabefeld. Es wird wohl der gerade aktive Strom genommen. Allerdings führt wohl ein "manuelles" set VictronMPPT Battery_maximum_current 10 dazu, auch andere Werte nehmen zu können

Danke, Joachim

[kpwg]

Hallo Joachim,

ein paar kleine Ecken und Kanten hat das Modul noch, aber in der jetzigen Form ist es zuverlässig nutzbar, alles Wichtige funktioniert. Venus-OS hatte ich kurz getestet, konnte aber für mich keinen Mehrwert entdecken. Zum selbst gebauten VE.Direct-Kabel hatte ich in #85 was geschrieben, das war bei mir entscheidend. Ich habe bei allen VE-Direct-Komponenten einen RasPi in "serieller Reichweite", wodurch die LAN-Kopplung noch kein Thema war. Bis zu fünf ungültige Pakete im Monat hatte ich jetzt trotzdem noch im Log

Nutzt Du einen BlueSolar oder SmartSolar Regler? Ich habe nur noch "Smart" im Einsatz, um parallel zur seriellen Verbindung per Bluetooth an die Komponente zu gelangen, Einstellungen zu kontrollieren/abzurufen, Firmware-Update per App zu machen und die Vernetzung über BT einzurichten. Vieles macht man nur einmal, aber es ist eben schön bequem. Den Ladestrom kann man auch dort begrenzen; an dem Parameter war ich aber noch nicht dran.

Den Schaltausgang kann man prima separat nutzen, habe mir dafür ein readingsProxy erstellt:

Code Auswählen Erweitern

define LR_Out_G1 readingsProxy LR_G1:Load_output_state
attr LR_Out_G1 devStateIcon ON:FS20.on:off ONPID:FS20.orange:off OFF:FS20.off:on
attr LR_Out_G1 setFn {($CMD eq "on")?fhem("set $DEVICE Load_output_control on"):fhem("set $DEVICE Load_output_control off");; return undef}
attr LR_Out_G1 setList on off
Beim loggen der Victron-Komponenten muss man reichlich filtern, sonst wird die Datenmenge ziemlich üppig. Ich habe mir damit beholfen, alle wichtigen Dinge in ein userReading zu schreiben und nur noch Dieses zu loggen. Klappt gut, ist aber abhängig vom ersten Wert in der Zeile. Erst kürzlich habe ich "acceptedRange" beim FileLog entdeckt, womit man auch Ausreißer bei den Werten sehr einfach ausschließt. bisher hatte ich mir dafür ein readingsChange erstellt, welches nicht plausible Werte unterdrückt.

Ursprünglich hatte ich ein 12V-System, habe aber gleich nach der ersten Saison auf 24V umgebaut. Der 75/15 kann im 12V-System nur bis 220W aus dem Panel holen, bei 24V ist es entsprechend das Doppelte. Ich wandle dann lieber im Nachgang 24V => 12V zentral für die Verbraucher. Für die Dimensionierung von Panel/Laderegler kann ich den MPPT Calculator von Victron empfehlen. Erstaunlich bei der Berechnung ist dabei der Einfluss des Temperatur-Koeffizienten bei Ganzjahres-Betrieb an sonnigen Wintertagen. Da ist die Leerlaufspannung der Module schnell im kritischen Bereich, wenn man vorher bereits knapp dimensioniert hatte.

Viele Grüße,

Ricardo

[MadMax-FHEM]

Hallo Ricardo,



Ich bin ja heilfroh, dass es das Modul gibt!
Mit Ecken und Kanten kann ich leben
"Fehlende" Eingabefelder auch, arbeite (verm.) eh mit "Scripten" und dann kann ich das set-Kommando ja so absetzen wie es soll/muss

Nach ein wenig "auseinandersetzen" mit dem Modul kann ich alles tun, was ich will

Anbindung per LAN-Adapter klappt eigentlich, wenn nicht, dann muss dort halt ein PI hin (läge ja "bereit"   )...

Venus-OS hab ich mir auch angeschaut und kam zum selben Ergebnis wie du.

Äh, ich nutze "nur" MPPT-Laderegler (75/15) ohne BT, also nur seriell. Reicht mir (solange er tut was er soll).

Das mit dem ReadingsProxy sieht interessant aus

Danke (dafür und das Modul)!

Gruß, Joachim

[MadMax-FHEM]

Moin zusammen...

so, nach langer Zeit hatte ich mal wieder ein bisschen Zeit und Ruhe das Modul nochmal zu überarbeiten.
Es handelt sich derzeit um ein noch nicht ganz fehlerfreies MAJOR Update!
D.h.: Die alten Reading-Namen gehören der Vergangenheit an (Ich habe mich jetzt an den Registernamen der Geräte orientiert)
Feature update: Nahezu alle möglichen Werte für alle Geräte zu setzen und auszulesen.
Bug-Fix: Mehrfach auftretende Readings mit gleichen Namen beseitigt
Bug-Fix: hohe CPU-Last --> hier gab es etwas Verbesserung

Die jeweils aktuelle Version ist jetzt in GIT zu finden: https://github.com/Askie666/VE.Direct.git

läuft bei mir derzeit mit einem MPPT 75/15 und einem Phönix Iverter 12V 500VA

Wie immer: Festgestellte Fehler gerne melden. Ich versuche mich zeitnah darum zu kümmern

Hallo,

dann melde ich mal

Ich habe ein wenig rumgespielt und da ich ja vorhabe den Victron per LAN (TTL-LAN-Adapter, aktuell sogar noch mit WLAN-Strecke dazwischen ) einzubinden, hatte ich (gerade wenn ich den Akku lade) immer wieder Meldungen im Log.

Habe herausgefunden, dass wohl die Implementierung bzgl. VEDirect_ChecksumTXT fehlerhaft ist.
Anbei meine gepatchte Version (sofern ich rauskriege wie ich mit dem neuen Forumsformat Dateien anhängen kann   )...
EDIT: done

Es werden zwar jetzt in meiner Konstellation (beim Laden) so einige Telegramme verworfen aber wenigstens stehen keine "komischen" Daten mehr in den Readings und auch die Meldungen wegen "isn't numeric usw." sind weg

EDIT: einzig sehr, sehr selten habe ich noch folgende Meldung:

Code Auswählen Erweitern

2023.04.07 17:27:44 1: PERL WARNING: Argument "" isn't numeric in multiplication (*) at ./FHEM/00_VEDirect.pm line 1209.
aber da bin ich noch nicht dahinter gekommen...
EDIT: bzw. gerade gesehen, dass die "neu" ist bzw. (doch) nicht die, wegen der ich schon mal geschaut hatte... (evtl. ist die auch weg, weil keine "ungültigen" Telegramme mehr "verarbeitet" werden)...
Mal sehen...

EDIT: wenn (noch mehr) Zeit ist, vielleicht "repariere" ich auch das mit den fehlenden Eingabemöglichkeiten

Achja: noch mal vielen Dank für das Modul!

Im Einsatz mit einem Victron MPPT 75/15

Gruß, Joachim

[MadMax-FHEM]

EDIT: wenn (noch mehr) Zeit ist, vielleicht "repariere" ich auch das mit den fehlenden Eingabemöglichkeiten

So hatte eben noch mal ein paar Minuten

Code Auswählen Erweitern

my $MPPTSets = "Restart:noArg Charger_mode:off,on Relay_battery_low_voltage_set:slider,9,0.1,95 Relay_battery_low_voltage_clear:slider,9,0.1,95 Relay_battery_high_voltage_set:slider,9,0.1,95 ".
               "Relay_battery_high_voltage_clear:slider,9,0.1,95 Relay_minimum_enabled_time:slider,0,1,500 Clear_history:noArg RX_Port_operation_mode:Remote_On_off,Load_output_configuration,".
               "Load_output_on_off_remote_control_inverted,Load_output_on_off_remote_control_normal Load_switch_low_level Load_switch_high_level TX_Port_operation_mode:Pulse_every".
               "0_01kWh,Lighting_control_pwm_normal,Lighting_control_pwm_inverted,Virtual_load_output Load_output_control:off,auto,alt1,alt2,on,user1,user2,automatic_energy_selector ".
               "Relay_operation_mode:off,PV_V_high,int_temp_high,Batt_Voltage_low,equalization_active,Error_cond_present,int_temp_low,Batt_Voltage_too_high,Charger_in_float_or_storage,".
               "day_detection,load_control Charger_maximum_current Battery_low_temperature_level:noArg Low_temperature_charge_current:noArg Battery_maximum_current:noArg ".
               "Battery_type:TYPE_1_GEL_Victron_Long_Life_14_1V,TYPE_2_GEL_Victron_Deep_discharge_14_3V,TYPE_3_GEL_Victron_Deep_discharge_14_4V,TYPE_4_AGM_Victron_Deep_discharge_14_7V,".
               "TYPE_5_Tubular_plate_cyclic_mode_1_14_9V,TYPE_6_Tubular_plate_cyclic_mode_2_15_1V,TYPE_7_Tubular_plate_cyclic_mode_3_15_3V,TYPE_8_LiFEPO4_14_2V,User_defined ".
               "Battery_temp_compensation:noArg Battery_equalization_voltage Battery_float_voltage Battery_absorption_voltage:noArg Automatic_equalization_mode:multiple,disabled";

Ich habe mal bei folgenden "Settern" das :noArg weggenommen, weil mir da Eingabemöglichkeiten fehlten (per set MPPT Charger_maximum_current 10 direkt geht ja / reicht mir eigentlich auch, weil ich es es [nur] per Programm setze aber so ist es "richtiger"?   ):
Charger_maximum_current
Load_switch_low_level
Load_switch_high_level

Ob da noch mehr eigentlich ohne .noArg sein sollten/müssten etc.: keine Ahnung
Mir reicht das erst mal
Ich habe mal keine neue "Patch-Datei" angehangen, ich hoffe es geht auch per "Code-Ausschnitt"...
...falls es überhaupt jemanden interessiert...
Das andere war ja (so ich das sehe) ein Fehler, das hier ist ja "nur" Optik

Gruß, Joachim

[kpwg]

...falls es überhaupt jemanden interessiert...

Hallo Joachim,
scheinbar nutzen das mittlerweile nur noch SEHR wenige Leute. Ich merke es im Umkreis meiner Kollegen: entweder Billigware ohne jede Steuerung (oder China-Cloud) auf der einen Seite, fertig installierte Anlage mit xx kW Peak und x kWh Speicher auf der anderen Seite.
Der eine Download war ich, allerdings habe ich mein Modul schon an ein paar Stellen angepasst, was ich wiederrum erst mal suchen muss. Dein Modul hatte ich noch nicht getestet, sorry.

Gerade die CRC-Prüfung juckt mich schon, da ich hier ganz oft falsche Werte bekomme, wodurch die Regelung einen Schluckauf bekommt.

[MadMax-FHEM]

scheinbar nutzen das mittlerweile nur noch SEHR wenige Leute. Ich merke es im Umkreis meiner Kollegen: entweder Billigware ohne jede Steuerung (oder China-Cloud) auf der einen Seite, fertig installierte Anlage mit xx kW Peak und x kWh Speicher auf der anderen Seite.

Hallo Ricardo,

ja, hatte ich auch erst überlegt und gegenüber den Billig-China-Dingern sind die Victron schon "teuer"...
...aber: gut dokumentiert und offene Schnittstelle OHNE Cloud
Und: das "muss" man unterstützen (finde ich)!
Ausserdem: es hat mich "gejuckt"

Der eine Download war ich, allerdings habe ich mein Modul schon an ein paar Stellen angepasst, was ich wiederrum erst mal suchen muss. Dein Modul hatte ich noch nicht getestet, sorry.
...
Gerade die CRC-Prüfung juckt mich schon, da ich hier ganz oft falsche Werte bekomme, wodurch die Regelung einen Schluckauf bekommt.

Kein Ding bzw. besteht ja keine "Pflicht" das zu nehmen oder zu teseten
Ich hab es ja erst mal (nur) für mich "verbessert", weil es eben gerade in meiner Konstellation mit "remote" per LAN (und aktuell noch schlimmer mit WLAN-Strecke zum testen dazwischen) so gar nicht gut wollte bzw. eben immer wieder "komische Zeichen" in den Readings standen...
Habe dabei gemerkt, dass der CRC-Check bei Text-Messages immer "gut geht" und dann eben gemerkt, dass er (mMn) fehlerhaft ist...
Ich habe also gar nicht viel geändert:
die CRC für TextMessage Sub komplett neu und den Aufruf des crc-Checks für Textmessages, weil dort die gesamte empfangene Nachricht rein muss (inkl. "führender" \r\n statt wie im Original-Code mit entfernten \r\n zu Beginn, so ich das richtig interpretiert habe)...
Also nur diese beiden "Stellen"...

Wenn es dann doch noch jemand anders brauchen kann: umso besser

...allerdings habe ich mein Modul schon an ein paar Stellen angepasst, was ich wiederrum erst mal suchen muss.

Wo hast du angepasst?
Funktional oder (wie mein letzter Post) nur/eher "kosmetisch"?

Gruß, Joachim

[Sprocki62]

Moin..
ich oute mich auch mal als ein Noch-Nutzer dieses Moduls, da mich der Ertag der Solarzelle auf meinem Wohnmobil schon interessiert (wenn ich da schon eine FHEM-Instanz auf nem Raspi 24/7 betreibe )
 
Hatte hier auch schon mal einen Beitrag geschrieben, wo ich gehofft hatte, dass sich der Modul-Ersteller mal drauf meldet..
Aber gut.. ich hab dann beschlossen, mit dem "Fehler" zu leben und hab das beste draus gemacht.

Werd' den Patch mal ausprobieren..
Danke, Joachim, dass Du das mal angefasst hast.

Grüße
Sprocki62

[MadMax-FHEM]

Hatte hier auch schon mal einen Beitrag geschrieben, wo ich gehofft hatte, dass sich der Modul-Ersteller mal drauf meldet..

Was für ein Problem war das?
Evtl. ja jetzt gefixt oder ich kann auch mal versuchen zu schauen...
...oder vielleicht hat es auch Ricardo behoben...

Gruß, Joachim

[Sprocki62]

Hatte hier auch schon mal einen Beitrag geschrieben, wo ich gehofft hatte, dass sich der Modul-Ersteller mal drauf meldet..

Was für ein Problem war das?
Evtl. ja jetzt gefixt oder ich kann auch mal versuchen zu schauen...
...oder vielleicht hat es auch Ricardo behoben...

Gruß, Joachim

Danke, dass Du nachfragst..
Hier nochmal der Fehler von 2021.. sieht aber heute nicht anders aus..

Code Auswählen Erweitern

2021.09.30 12:06:38 1: PERL WARNING: "my" variable %MPPT masks earlier declaration in same scope at ./FHEM/00_VEDirect.pm line 532, <$fh> line 382.
2021.09.30 12:06:38 3: Opening MPPT75_15 device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A702Q1IB-if00-port0
2021.09.30 12:06:38 3: Setting MPPT75_15 serial parameters to 19200,8,N,1
2021.09.30 12:06:38 3: MPPT75_15 device opened
...
2021.09.30 12:06:39 1: PERL WARNING: Illegal hexadecimal digit '
' ignored at ./FHEM/00_VEDirect.pm line 1436.
2021.09.30 12:06:39 1: PERL WARNING: Argument "" isn't numeric in numeric ne (!=) at ./FHEM/00_VEDirect.pm line 1248.
2021.09.30 12:06:39 1: PERL WARNING: Use of uninitialized value $lastMin in numeric ne (!=) at ./FHEM/00_VEDirect.pm line 1039.
2021.09.30 12:06:39 1: PERL WARNING: Use of uninitialized value within @e in index at ./FHEM/00_VEDirect.pm line 1061.
2021.09.30 12:07:21 1: PERL WARNING: Argument "" isn't numeric in multiplication (*) at ./FHEM/00_VEDirect.pm line 1206.
2021.09.30 12:07:21 1: PERL WARNING: Filehandle $fh opened only for input at ./FHEM/00_VEDirect.pm line 1222, <$fh> line 32.

Vielleicht hast Du ja eine Idee... bin leider nicht soo tief drin im Programmieren..

Danke + Gruß
Sprocki62

[MadMax-FHEM]

2021.09.30 12:06:39 1: PERL WARNING: Use of uninitialized value $lastMin in numeric ne (!=) at ./FHEM/00_VEDirect.pm line 1039.
2021.09.30 12:06:39 1: PERL WARNING: Use of uninitialized value within @e in index at ./FHEM/00_VEDirect.pm line 1061.

Die 2 Meldungen könnten/sollten mit meinem Fix weg sein.
Hatte ich auch bzw. ist der "Bereich" dort wo es bei falschn Inhalten zu "Prolemen" kommen kann und da zuvor falsche Nachrichen nicht korrekt aussortiert wurden...
...könnte es jetzt klappen ohne diese Meldungen

Die erste Meldung:

2021.09.30 12:06:39 1: PERL WARNING: Use of uninitialized value $lastMin in numeric ne (!=) at ./FHEM2021.09.30 12:06:38 1: PERL WARNING: "my" variable %MPPT masks earlier declaration in same scope at ./FHEM/00_VEDirect.pm line 532, <$fh> line 382.

da bin ich (auch) überfragt bzw. kommt die bei mir nicht, gut ich habe auch verbose=0
Evtl. ändere ich das mal und schaue (noch mal)...
...bzw. versuche zu verstehen was die Meldung "will"/"meint"...
EDIT: ok, ich denke ich weiß warum sie kommt. Aber wie ich das ändere, mal sehen...
EDIT: hmmm, so ich das richtig deute ist diese Definition "überflüssig" weil ja danach erneut ANDERS definiert wird, also "überdefiniert" (wie ja die Meldung "sagt"), daher kann man den Teil:

Code Auswählen Erweitern

my %MPPT =    ('0'=>"Off",
               '1'=>"Voltage_or_current_limited",
               '2'=>"MPP Tracker active");
eigentlich einfach löschen (oder die Meldung ignorieren   Sollte ja nur beim Laden/Starten kommen?)...
Zeilen 250-252...

Bzgl. dem hier:

2021.09.30 12:06:39 1: PERL WARNING: Use of uninitialized value $lastMin in numeric ne (!=) at ./FHEM2021.09.30 2021.09.30 12:07:21 1: PERL WARNING: Filehandle $fh opened only for input at ./FHEM/00_VEDirect.pm line 1222, <$fh> line 32.

sollte wohl das helfen:

Code Auswählen Erweitern

              open(my $fh, '<', $logFile) or die $!;
gegen

Code Auswählen Erweitern

              open(my $fh, '+<', $logFile) or die $!;
ersetzen. Zeile: 1214
Also öffnen lesend und schreibend, weil in Zeile 1222 eben geschrieben wird/werden soll(te)...

Habe ich so nicht, da ich ohne "LogHistoryToFile" arbeite...

Bei den Meldungen müsste ich auch mal verbose wieder hoch drehen und schauen, ob ich die auch habe:

2021.09.30 12:06:39 1: PERL WARNING: Use of uninitialized value $lastMin in numeric ne (!=) at ./FHEM2021.09.30 2021.09.30 12:06:39 1: PERL WARNING: Argument "" isn't numeric in numeric ne (!=) at ./FHEM/00_VEDirect.pm line 1248.
2021.09.30 12:07:21 1: PERL WARNING: Argument "" isn't numeric in multiplication (*) at ./FHEM/00_VEDirect.pm line 1206.

Da das eigentlich in der Verarbeitung von HEX-Nachrichten ist, muss ich da (auch) mal schauen.
Evtl. kann aber auch sein, dass es mit meiner Änderung gar nicht erst so weit kommt und auch diese Meldungen weg sind...
Kannst du ja mal ausprobieren

Wenn sie bleiben schaue ich (vielleicht) noch mal...

EDIT: evtl. hänge ich die Tage mal eine neue Patch-Version an, mit den ganzen hier genannten Änderungen. Wenn weitere Dinge sind, dann mal melden, ich schau dann (vielleicht) mal...

Gruß, Joachim

[Sprocki62]

Moin Joachim,

Danke, dass Du Dir die Zeit nimmst, dich mit MEINEN Problem zu beschäftigen..
Also.. ich hab deinen Patch nun installiert.. aber leider sind die Meldungen immer noch da, allerdings immer zwei oder drei Zeilen später.
Hatte vorher schon mal selbst ne Änderung gemacht, und um die Zeilen nicht zu verlieren, hab ich sie mit "#" auskommentiert stehen lassen.

Code Auswählen Erweitern

....
2023.04.15 10:04:08 1: PERL WARNING: "my" variable %MPPT masks earlier declaration in same scope at ./FHEM/00_VEDirect.pm line 532, <$fh> line 400.
2023.04.15 10:04:08 3: Opening MPPT75_15 device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A702Q1IB-if00-port0
2023.04.15 10:04:08 3: Setting MPPT75_15 serial parameters to 19200,8,N,1
2023.04.15 10:04:08 3: MPPT75_15 device opened
2023.04.15 10:04:08 3: HUEDevice2: I/O device is deCONZ
2023.04.15 10:04:09 3: geolocation: URL is none, periodic updates will be limited to explicit GetXXPoll attribues (if defined)
2023.04.15 10:04:09 3: geolocation: interval is 0, no periodic updates will done.
2023.04.15 10:04:09 3: geolocation: Defined without URL featurelevel 6.2
2023.04.15 10:04:10 3: ESPEasy ESPBridge: Bridge v2.18 port [TCP:IPV4:8383] opened.
2023.04.15 10:04:11 2: deCONZ: autocreate: created 0/0/0 devices (ignored 0/0/0)
.... (ein paar Zeilen gelöscht)
2023.04.15 10:04:11 1: PERL WARNING: Illegal hexadecimal digit '
' ignored at ./FHEM/00_VEDirect.pm line 1440.
2023.04.15 10:04:11 1: PERL WARNING: Argument "" isn't numeric in numeric ne (!=) at ./FHEM/00_VEDirect.pm line 1252.
2023.04.15 10:04:11 1: PERL WARNING: Use of uninitialized value $lastMin in numeric ne (!=) at ./FHEM/00_VEDirect.pm line 1042.
2023.04.15 10:04:13 1: PERL WARNING: Use of uninitialized value within @e in index at ./FHEM/00_VEDirect.pm line 1064.
2023.04.15 10:04:30 1: PERL WARNING: Argument "" isn't numeric in multiplication (*) at ./FHEM/00_VEDirect.pm line 1209.
2023.04.15 10:04:39 3: telnetForBlockingFn_1681545879.2156: port 41417 opened

Was allerdings geholfen hat, war die Änderung ..

sollte wohl das helfen:

Code Auswählen Erweitern

              open(my $fh, '<', $logFile) or die $!;
gegen

Code Auswählen Erweitern

              open(my $fh, '+<', $logFile) or die $!;
ersetzen. Zeile: 1214
Also öffnen lesend und schreibend, weil in Zeile 1222 eben geschrieben wird/werden soll(te)...

Die entsprechende Meldung trat beim Neustart nicht mehr auf.

Und mit der Meldung

Code Auswählen Erweitern

2023.04.15 10:04:08 1: PERL WARNING: "my" variable %MPPT masks earlier declaration in same scope at ./FHEM/00_VEDirect.pm line 532, <$fh> line 400. kann ich gut leben..   die kommt wirklich nur beim Start.. und %MPPT wird ja später noch mal richtig deklariert.

Danke nochmal/schon mal..   

Was ich Dir/Euch nicht vorenthalten möchte, ist die Änderung, die ich selbst schon mal gemacht habe.. ist zwar nur "Kosmetik", aber mir war es wichtig.

Irgendwo zwischen Zeile 70 und 73 habe ich die Zeile

Code Auswählen Erweitern

"H22"=>{"ReadingName"=>"Yield_yesterday","Unit"=>"-","Scale"=>"1"},gegen

Code Auswählen Erweitern

"H22"=>{"ReadingName"=>"Yield_yesterday","Unit"=>"kWh","Scale"=>"0.01"},
getauscht, weil ich die Maßeinheit richtig haben wollte.

Vielleicht hilfts ja dem einen oder anderen auch...

Schönes Wochenende
Johannes (aka Sprocki62)

[MadMax-FHEM]

Hallo Johannes,

danke für's Testen.
Hmm, dann werde ich evtl. mal noch mal schauen.

Solange keine "Verbindungsprobleme" (TTL-LAN-Adapter geht grad noch aber dann mit WLAN-Strecke dazwischen, naja) waren hatte ich (mit verbose 0 beim VEDirect-Device) hatte ich keine/kaum Meldungen.
Ganz schlimm war es dann, wenn geladen wurde, dann hat es das Log vollgehagelt (trotz verbose 0 am Device).

Mit meiner aktuellen Anpassung (und wie ich denke korrekte Implementierung von CRC bei Text) habe ich keine Meldungen mehr im Log...

Kommen die Meldungen regelmäßig oder "nur" beim Start?
(gut sehe ich ja dann vielleicht auch, wenn ich mal verbose wieder hoch setze/lösche)

Allerdings geht der Urlaub zu Ende (oder ist es ja eigentlich schon), daher weiß ich nicht (genau) wann ich dazu komme...

EDIT:
eben habe ich mal das unnötige my @MPPT rausgeworfen
Bei einem reload bekomme ich dann (auch) folgendes:

Code Auswählen Erweitern

2023.04.15 10:56:19 1: PERL WARNING: Use of uninitialized value within @e in index at ./FHEM/00_VEDirect.pm line 1061.
2023.04.15 10:56:23 1: PERL WARNING: Illegal hexadecimal digit '
' ignored at ./FHEM/00_VEDirect.pm line 1436.
2023.04.15 10:56:23 1: PERL WARNING: Argument "" isn't numeric in numeric ne (!=) at ./FHEM/00_VEDirect.pm line 1248.
Aber so wie es aussieht eben nur beim Start (bzw. reload)...
Hmmm, mal sehen

Gruß, Joachim

[Sprocki62]

Moin Joachim,

wenn ich kann, helfe ich gerne mit.. und wenn's nur beim Testen ist..

Kommen die Meldungen regelmäßig oder "nur" beim Start?

Sieht so aus, als wenn die nur beim Start kämen..

Und das my %MPPT hab' ich gerade auch rausgeworfen.. es funktioniert noch alles.  

Hier nochmal MEINE Fehlermeldungen (sind ja ein paar mehr als bei dir):

Code Auswählen Erweitern

2023.04.15 11:19:22 1: PERL WARNING: Illegal hexadecimal digit '
' ignored at ./FHEM/00_VEDirect.pm line 1440.
2023.04.15 11:19:22 1: PERL WARNING: Argument "" isn't numeric in numeric ne (!=) at ./FHEM/00_VEDirect.pm line 1252.
2023.04.15 11:19:22 1: PERL WARNING: Use of uninitialized value $lastMin in numeric ne (!=) at ./FHEM/00_VEDirect.pm line 1042.
2023.04.15 11:19:23 1: PERL WARNING: Use of uninitialized value within @e in index at ./FHEM/00_VEDirect.pm line 1064.
2023.04.15 11:19:32 1: PERL WARNING: Argument "" isn't numeric in multiplication (*) at ./FHEM/00_VEDirect.pm line 1209.

Aber gut.. 
Wenn Dir oder Ricardo noch was dazu einfällt, ok..  wenn nicht, auch ok.
Daaanke soweit!

Bis demnääähx
Johannes

[kpwg]

Ich habe mal auf die Schnelle meine bisherigen Anpassungen gesucht und "visualisiert". Klar geht das besser, aber das hier geht halt schnell 
Dabei sind ansich nur zwei Fehlerbehebungen, eine Schönheitskorrektur (Idle, Bulk, Absorb, Float, ...) und einmal sehe ich keinen Unterschied.
Die CRC-Prüfung kann ich eventuell heute abend testen, vorher müssen noch neue VE.Direct Kabel mit CH340 her. Es motiviert schon, wenn hier wieder Bewegung ins Thema kommt.