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

kpwg · 27 April 2023, 16:26:48

Ich habe die Versionen mal zum Testen parat gelegt. Es gibt hier mit der v1.0 seit meiner letzten Meldung noch keinen Logeintrag, obwohl jetzt auch der zweite Laderegler viel leisten muss

Als wichtige Basis sehe ich immer noch einen funktionierenden USB-Seriell-TTL-Wandler. Hier wären noch weitere Erfahrungen interessant, auch mit dem originalen Kabel (sofern das überhaupt jemand besitzt

)

MadMax-FHEM · 27 April 2023, 17:48:27

Zitat von: kpwg am 27 April 2023, 16:26:48Ich habe die Versionen mal zum Testen parat gelegt. Es gibt hier mit der v1.0 seit meiner letzten Meldung noch keinen Logeintrag, obwohl jetzt auch der zweite Laderegler viel leisten muss

Freut mich

Macht nix, ich bastle trotzdem weiter

Eben mal das mit der HEXChecksum gerade gezogen (so ich denke)...
Die verbose-Version wäre dann um Fehler bzgl. "Skalierung" zu finden (isn't numeric) aber die habe ich ganz selten, daher: "Schönheitsfehler"
Je nachdem welche Daten da so kommen/abgerufen werden kann das nat. schon mal einige Logeinträge produzieren.
Wenn sie anfangen sich zu wiederholen, kann man die Version ohne "v" einspielen (oder auch V1.0) und einfach die Ausgaben hier posten.

Für meinen "Fehler" mit "isn't numeric" bei "type: MPPT id: 0x104F" habe ich beschlossen enfach mal eine Skalierung von "0" anzugeben, wie bei "History_today" (ich dachte "Total_history" und "History_today" liegen nicht so weit auseinander

).

Ich habe gemerkt, dass (bei mir) die get-Kommandos nicht funktionieren und weiß auch warum...
...aber ich habe nur mal die "Fehlstellen" auskommentiert, kann aber nicht die Lösung sein, muss erst mal verstehen...
Wenn weiterhin Zeit bleibt, dann geht es weiter (und wenn nur für mich: auch ok

)...
...habe auch einige Dokumente gefunden, mal sehen...

Ich habe meinem MPPT 70/15 heute mal ein FW-Update verpasst

Dazu auch mal auf dem PC die VictronConnect-App genutzt: bin richtig froh das Geld ausgegeben zu haben

EDIT: wobei ich zunächst erschrocken bin, da manches was ich machen wollte/mir wichtig war plötzlich nicht mehr ging $:-\$ Gut, geht nun anders... Dabei sind mir noch ein paar Fehler aufgefallen, eieieiei... Wenn man mal was anfängt...

Zitat von: kpwg am 27 April 2023, 16:26:48Als wichtige Basis sehe ich immer noch einen funktionierenden USB-Seriell-TTL-Wandler. Hier wären noch weitere Erfahrungen interessant, auch mit dem originalen Kabel (sofern das überhaupt jemand besitzt )

Hmm, war/ist bei mir ganz einfach hiernach: https://obenschlaefer.com/low-budget-energiemonitor-victron-venus-os-mit-raspberry-pi-obenschlaefer/ gemacht mit folgenden Kabeln: https://www.amazon.de/dp/B07BMVVPPF und einem USB/TTL den ich noch rumliegen hatte

Aktuell sogar mittels TTL-LAN-Adapter (https://wiki.fhem.de/wiki/Serial_TTL_to_Ethernet_Module) und den sogar noch per WLAN-Bridge

Soll später mal nur per LAN, also ohne WLAN eingebunden werden.
Aber für aktuelle Tests ist das so einfacher...
Dabei habe ich eben bemerkt, dass da wohl schon mal Pakete "verstümmelt" ankommen...
...drum meine "Aktivitäten"...

Gruß, Joachim

kpwg · 06 Mai 2023, 12:22:37

Die 1.1 (aktuell noch ohne "v") läuft nun- gewohnt unauffällig

Der Start von FHEM sieht im Log so aus:

Code Auswählen

2023.05.06 12:01:58 1: Including ./log/fhem.save
2023.05.06 12:01:58 0: Featurelevel: 6.2
2023.05.06 12:01:58 0: Server started with 56 defined entities (fhem.pl:27410/2023-04-07 perl:5.032001 os:linux user:fhem pid:550)
2023.05.06 12:02:18 1: PERL WARNING: Argument "" isn't numeric in multiplication (*) at ./FHEM/00_VEDirect.pm line 1209.
2023.05.06 12:02:53 2: AttrTemplates: got 271 entries

Also erst mal entspannt. Ich hatte schon die letzten Tage keine Logeinträge mehr, auch der Sonnenaufgang "funktionierte" mit der 1.0

Jetzt hatte ich mal die Set Kommandos probiert, aber es ging zumindest aus der Weboberfläche nicht fehlerfrei. Ich wollte den Regler neu starten, da mir die Kiste zu zeitig in "Float" ging, ohne wirklich die Konstanstspannungsphase durchlaufen zu haben.
Ein "set <device> Restart" über die Weboberfläche bringt

Code Auswählen

unknown argument Restart, choose one of Restart Charger_mode Relay_battery_low_voltage_set Relay_battery_low_voltage_clear Relay_battery_high_voltage_set Relay_battery_high_voltage_clear Relay_minimum_enabled_time Clear_history RX_Port_operation_mode Load_switch_low_level Load_switch_high_level TX_Port_operation_mode Load_output_control Relay_operation_mode Charger_maximum_current Battery_low_temperature_level Low_temperature_charge_current Battery_maximum_current Battery_type Battery_temp_compensation Battery_equalization_voltage Battery_float_voltage Battery_absorption_voltage Automatic_equalization_mode

wobei auch nichts passiert. Von der Kommandozeile die selbe Reaktion. Nun stelle ich mir gerade die Frage, ob die MTTP Regler das überhaupt können. Ich schaue da mal nach... evtl gibt es Unterschiede

Viele Grüße, Ricardo

MadMax-FHEM · 06 Mai 2023, 12:52:27

Ich habe mal schnell in den Code geschaut und es gibt 3 Stellen wo bei "set" (sub VEDirect_Set($$@)) die "usage" ausgegeben wird:

1. wenn $cmd == "" oder "?" (also "leeres" Kommando oder "Kommando-Hilfe") -> ist ja eher nicht der Fall
EDIT: Zeile 1635

2. wenn der Typ nicht gefunden wird, also MPPT, BMV, ... oder kein Register für $cmd existiert, z.B.:

Code Auswählen

    elsif($type eq "MPPT" && defined($mppt_reg{$cmd}))

ich konnte für Restart in den Regsiter-Hashes nichts finden?
Könnte also hier rausfallen...
EDIT: Zeile 1649

3. wenn das Register zu $cmd nicht defined ist (also ein Sub-Anteil von 2. ?), weil diese Zeile ja nie durchlaufen wird?

Code Auswählen

    elsif($reg eq "-" && $cmd eq "Restart")

EDIT: Zeile 1722
weil ja zuvor schon ein Durchlauf ist, wenn $reg defined ist (egal welchen Inhalts?), daher würde das ja gar nicht mehr abgeprüft, sondern gleich vorher "abgebogen"?
Also hier:

Code Auswählen

 ## Informationen aus dem %Register zum Befehl holen und verarbeiten
    if(defined($reg))

EDIT: Zeile 1673

Ich denke aber (bzw. konnte nichts finden), dass $reg nicht definiert ist, weil zu Restart keines da ist?

Funktioniert das Restart denn bei BMV oder anderen Typen?

Man könnte ja mal "quick&dirty" das hier "erzwingen", indem mal einfach nur auf $cmd eq "Restart" ändert, also das mit $reg eg "-" weglässt?

Code Auswählen

    elsif($reg eq "-" && $cmd eq "Restart")
    {
      DevIo_SimpleWrite($hash, ":64F", 2, 1) ;
    }     
    else

EDIT: ab Zeile 1722
EDIT: bzgl. "quick&dirty", es muss nat. auch erst mal 2. "umschifft" werden, wobei wir wieder bei einem Eintrag für Restart wären? Oder für wirklich "quick&super-dirty" auch noch das hier anpassen, also z.B. die "Abfrage" bzgl. defined($reg) rausnehmen:

Code Auswählen

    elsif($type eq "MPPT" && defined($mppt_reg{$cmd}))

oder einfach(er) das else am "Ende" dieser "Abfrage-Orgie" einfach lassen

Code Auswählen

    else{return $usage;}

EDIT: Zeile 1669
EDIT: Sauberer wäre (verm.) einen Eintrag für Restart in mppt_reg usw. zu machen?

EDIT: Zeilennummern bzgl. V1.1 (ohne v) ergänzt...

Gruß, Joachim

kpwg · 06 Mai 2023, 13:38:04

Sorry, musste erst mal zu Tisch. Da hab ich wenig Argumente dagegen

Der Fehler tritt in der 1636 auf:

Code Auswählen

2023.05.06 12:17:22 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/00_VEDirect.pm line 1636.

Ich teste das mal, welche Geräte überhaupt das Kommando unterstützen.

MadMax-FHEM · 06 Mai 2023, 13:55:15

1636?
Welche Version?
Schon was angepasst?

Bei mir ist da nur eine Logausgabe mit verbose 5 (Version V1.1 ohne v):

Code Auswählen

    return $usage if(($cmd eq "" || $cmd eq "?")); 
    Log3 $name, 5, "VEDirect ($name) - Set command: $cmd Arguments $args[0]"; <- 1636
    my ($reg,$scale,$unit,$setitm,$spezSetGet,$payload);

Gut, kann nat. sein, dass da eine der Variablen nicht initialisiert ist/wurde...
Evtl. würde man was "sehen", wenn der verbose dort mal auf 1 gestellt wird:

Code Auswählen

    return $usage if(($cmd eq "" || $cmd eq "?")); 
    Log3 $name, 1, "VEDirect ($name) - Set command: $cmd Arguments $args[0]";
    my ($reg,$scale,$unit,$setitm,$spezSetGet,$payload);

Sollte ja nicht weiter stören, wird ja nur bei set durchlaufen...

EDIT: ich muss dann auch mal weg

Gruß, Joachim

kpwg · 06 Mai 2023, 16:43:50

Ja genau, die 1.1 ohne "v" und ohne Anpassungen

MadMax-FHEM · 06 Mai 2023, 17:25:32

Zitat von: kpwg am 06 Mai 2023, 16:43:50Ja genau, die 1.1 ohne "v" und ohne Anpassungen

Ok, dann halt bei Restart wird (nat.) Arguments $args[0] nicht initialisiert sein, weil ja ohne Argumente...

Um die Meldung wegzukriegen, entweder die args nicht ausgeben oder vorher prüfen, ob args definiert ist

Oder einfach ignorieren

Wenn ich mal Zeit habe werde ich mal versuchen neben der get-Logik auch das mit dem set zu verstehen und (falls notwendig) "korrigieren"...
...aber aktuell bin ich noch beim get zugange...

Gruß, Joachim

kpwg · 07 Mai 2023, 17:01:51

Zitat von: MadMax-FHEM am 06 Mai 2023, 17:25:32Wenn ich mal Zeit habe werde ich mal versuchen neben der get-Logik auch das mit dem set zu verstehen und (falls notwendig) "korrigieren"...
...aber aktuell bin ich noch beim get zugange...

Der aktuelle Zustand des Modules ist ja auch schon ordentlich, ich nutze das wie gesagt bereits länger produktiv. Bisher habe ich unplausible Werte zB mit readingsChange korrigiert, was zwar das Problem löst, aber nicht die Ursache behebt. Aktuell ist auch die 1.1 ohne "v" störungsfrei in Betrieb, einzig der Sonnenaufgang hat sich heute nach Tagen wieder mal gemeldet, was ich aber für "kosmetisch" halte. Die set-Funktion ist hier mit dem Phoenix Wechselrichter (24/375) gut kompatibel (nutze ich am häufigsten), lediglich ein "Restart" gibt es bei dem WR gar nicht. Recht gut lässt sich das überprüfen, indem man die Demo-Bibliothek der Victron App nutzt und schaut, was die Geräte überhaupt können. Es würde mich wundern, wenn die App selbst kein Set unterstützt, das VE.Direct-Interface dieses aber trotzdem kennt.