ReadingsVal - leere Variable auslesen

Begonnen von cocojambo, 06 September 2019, 13:47:47

Vorheriges Thema - Nächstes Thema

Beta-User

UPS,   Tastatur gehangen...? Hinten ist es überflüssig...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

cocojambo

Habe die hinteren 2 "Errors" entfernt und jetzt kommen wieder die Error Meldungen.

Batt_State { my %rets = ("Error"  => "Error","0" => "ist aus","1" => "Standby","2" => "initialisiert","3" => "wird geladen","4" => "wird entladen","5" => "Fehler","6"  => "Leerlauf","7"  => "Leerlauf",);; $rets{$val};;}

Zuviel geändert? oder zuviel gekürzt?

Gruß
Norbert
FHEM6.2 FB7490 FB7430 3xraspi2+3+4 2xHM-LAN-CFG 2xESP CUL868 CUNO868 HUE-Bridge Harmony-Hub 5xHM-LC-Sw-PI-2 3xHM-WDS30-T2-SN 1xHM-LC_Sw4-DR 3xHM-ES-PMSw1-PI 7xFS20SIG2 6xFS20KSE 2xHM-ES-PMSW1-PL 5xS300TH 1xASH2200 1xEM1000

cocojambo

Ich habe die erste Version in der "Error"  im Reading stand wieder eingespielt.
Leider steht im LOG folgende Fehlermeldung. Scheint also doch noch nicht so wirklich zu funktionieren:

2019.09.06 20:08:16 1: PERL WARNING: "my" variable $val masks earlier declaration in same scope at (eval 27016) line 1.
2019.09.06 20:08:16 3: eval: { my %rets = ("Error"  => "Error","0" => "ist aus","1" => "Standby","2" => "initialisiert","3" => "wird geladen","4" => "wird entladen","5" => "Fehler","6"  => "Leerlauf","7"  => "Leerlauf",);; my $val = ReadingsVal("SolarEdge", "Batt_State", "Error");; my $val = ReadingsVal("SolarEdge", "Batt_State", "Error");; $rets{$val};;}


und kann man da was machen?

Gruß
Norbert
FHEM6.2 FB7490 FB7430 3xraspi2+3+4 2xHM-LAN-CFG 2xESP CUL868 CUNO868 HUE-Bridge Harmony-Hub 5xHM-LC-Sw-PI-2 3xHM-WDS30-T2-SN 1xHM-LC_Sw4-DR 3xHM-ES-PMSw1-PI 7xFS20SIG2 6xFS20KSE 2xHM-ES-PMSW1-PL 5xS300TH 1xASH2200 1xEM1000

Beta-User

Du hattest schon recht, da war was zu viel - ziemlich genau das sagt auch die Fehlermeldung.

Hab's entfernt, den "Ersatzrückgabewert" etwas umbenannt und die Reihenfolge umgedreht, dann wird vielleicht klarer, was da passiert:
Batt_State { my $val = ReadingsVal("SolarEdge", "Batt_State", "Err");; my %rets = ("Err"  => "Error","0" => "ist aus","1" => "Standby","2" => "initialisiert","3" => "wird geladen","4" => "wird entladen","5" => "Fehler","6"  => "Leerlauf","7"  => "Leerlauf",);; $rets{$val};;}
Bedeutet:
1. ReadingsVal = Aktuellen Zustand (in eine Variable) holen, gibt's da ein Problem (Device oder Reading existiert nicht oder ist undef), wird "Err" zurückgeliefert.
2. HASH definieren, der die effektiven Rückgabewert-MÖGLICHKEITEN enthält.
3. Rückgabewert für die Variable aus dem HASH holen...

Hab's zwar nicht nochmal getestet, sollte aber funktionieren.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Wzut

Jungs ihr seid zwar wohl schon recht weit, aber für mich liest sich das alles als ob ihr das Symptom statt der Ursache behandelt.
Ursache ist doch wohl das Modbus ein leeres bzw gar kein Reading für die Registerabfrage 57734 liefert ?
Also warum nicht im Modbus Device ein userReading mit Namen Batt_State erstellen und das aus dem Registerwert von 57734 bilden.
D.h liefert  57734 einen Wert 0-7 geht dieser direkt im userReading durch, ist es nicht vorhanden ist der Returnwert eben ein beliebiger andere String/Wert.
Trigger ist bestimmt auch einfach zu definieren, cocojambo hat das list gekürzt aber da sind wahrscheinlich noch mehr Registerwerte die auch im dem Fehlerfall eine gültige Antwort liefern.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

cocojambo

Das ist richtig, es werden noch mehr Werte ausgelesen. Diese machen aber keinen "Ärger" wenn sie nicht da sind, weil sie nicht weiter bearbeitet werden, sondern 1:1 in die Ausgabe übernommen werden. Es wird ja bei der Abfrage der Werte kein Error ausgelöst. Der Modbus gibt "opened" raus, die Adresse scheint auch abgefragt zu werden, hat aber keinen Inhalt. Ich habe SolarEdge diesbezüglich schon angeschrieben, da einige Adressen weiterhin funktionieren. Habe nur noch keine Stellungsnahme dazu bekommen.
Die Idee das "leere Reading" mit einem Wert zu füllen, hatte ich ja auch, indem man einfach immer zu jeder Ausgabe +1 dazu addiert und die Abfrage dann entsprechend ändert. Dadurch käme immer mindestens der Wert 1 an. Habe es aber nicht hinbekommen und deshalb verworfen.

Gruß
Norbert
FHEM6.2 FB7490 FB7430 3xraspi2+3+4 2xHM-LAN-CFG 2xESP CUL868 CUNO868 HUE-Bridge Harmony-Hub 5xHM-LC-Sw-PI-2 3xHM-WDS30-T2-SN 1xHM-LC_Sw4-DR 3xHM-ES-PMSw1-PI 7xFS20SIG2 6xFS20KSE 2xHM-ES-PMSW1-PL 5xS300TH 1xASH2200 1xEM1000

Wzut

na also wenn es Register gibt die immer einen Wert liefern hat man schon mal einen Trigger für das userReading.
Das Geräte via Modbus gar keinen Wert liefert ist ärgerlich, aber vom User wohl ersteinmal kaum zu ändern.
Man kann allerdings noch einen Schritt weitergehen und mal mit dem Autor von ModbusAttr (StefanStrobel) reden :
a. warum löscht er bereits vorhandene Readings ? (finde ich persönlich etwas unglücklich und wenn nötig dann kann man dem User ggf. auch die Wahl lassen)
b. ob es nicht möglich wäre wenn ein Register bei der Abfrage keinen Wert mehr liefert es mit irgend einem default Wert zu besetzen.
Allerdings solltest du sicher sein das wirklich kein Wert vom WR kommt, oder kommt vllt. doch einer nur fällt er bei der Auswertung durchs Raster ?
(da sollte ein verbose 5 Log für Aufklärung sorgen)
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

cocojambo

Ich frage alle 30sek 23 Adressen des Inverters ab nach dem gleichen Schema. Davon bekomme ich 14 Readings mit den richtigen Werten zurück. Der Rest betrifft nur die storage-Daten, die alle vor 3 Tagen Mittags plötzlich gleichzeitig keine Readings mehr lieferten. Die kompletten Energy Daten liefen weiter bis einschließlich heute. Deshalb vermute ich, das der Hersteller SolarEdge über ein "Fernupdate" diese Abfragen gesperrt hat. Deshalb habe ich bei SolarEdge bereits angefragt. Meine Anfrage ist bereits vom techn.Support hier in Deutschland weitergeleitet worden zum techn.Support in Israel. Leider habe ich noch keine Stellungnahme.

Das mit dem verbose 5 LOG werde ich auf jeden Fall trotzdem mal versuchen.

Gruß
Norbert
FHEM6.2 FB7490 FB7430 3xraspi2+3+4 2xHM-LAN-CFG 2xESP CUL868 CUNO868 HUE-Bridge Harmony-Hub 5xHM-LC-Sw-PI-2 3xHM-WDS30-T2-SN 1xHM-LC_Sw4-DR 3xHM-ES-PMSw1-PI 7xFS20SIG2 6xFS20KSE 2xHM-ES-PMSW1-PL 5xS300TH 1xASH2200 1xEM1000

cocojambo

So, die Adressen die ich auslesen möchte sind mittlerweile in meinem Inverter wieder von SolarEdge freigeschaltet worden und es kommen wieder alle Werte so wie Vorher. Aber jetzt wo die Zahlenwerte für den Zustand der Batterie wieder ausgelesen werden, kommt zwar keine "Error" Anzeige mehr, dafür aber nur die Zahlenwerte und nicht die entsprechenden "Zustände".

attr mySL_now userReadings Pac_S0_now {if (ReadingsVal("mySL_now", "S0_now", "0")+ ReadingsVal("SolarEdge", "Batt_Watt", "0") > ReadingsVal("mySL_now", "Pac_now", "0")) {return '0'} else {ReadingsVal("mySL_now", "Pac_now", "0") - ReadingsVal("mySL_now", "S0_now", "0")- ReadingsVal("SolarEdge", "Batt_Watt", "0")}},Co2_all {ReadingsVal("mySL_now", "Pac_all", "0")*0.70},S0_Pac_now {if (ReadingsVal("mySL_now", "Pac_now", "0") - ReadingsVal("SolarEdge", "Batt_Watt", "0") > ReadingsVal("mySL_now", "S0_now", "0")) {return '0'} else {ReadingsVal("mySL_now", "S0_now", "0") - ReadingsVal("mySL_now", "Pac_now", "0") + ReadingsVal("SolarEdge", "Batt_Watt", "0")}},Batt_State { my $val = ReadingsVal("SolarEdge", "Batt_State", "Err");; my %rets = ("Err"  => "Error","0" => "ist aus","1" => "Standby","2" => "initialisiert","3" => "wird geladen","4" => "wird entladen","5" => "Fehler","6"  => "Leerlauf","7"  => "Leerlauf",);; $rets{$val};;},Pac_S0_now_avg {ReadingsVal("mySL_now", "Pac_now_avg", "0")- ReadingsVal("mySL_now", "S0_now_avg", "0")},Baum_all {ReadingsVal("mySL_now", "Co2_all", "0")}
attr mySL_now verbose 5


verbose=5 gibt auch keine Auskunft darüber warum das so ist:

2019.09.27 17:43:47 4: Solarlog_getupdate
2019.09.27 17:43:47 4: avg_count: 10
2019.09.27 17:43:47 4:   currentvalues: 388, 2686, 7927, 200425, 2637489, 77129426, 26939, 754603, 8248650, 35667041
2019.09.27 17:43:47 4:     count_avg: 100
2019.09.27 17:43:47 4:     avg_count: 10
2019.09.27 17:43:47 4:     reg_count: 10
2019.09.27 17:43:47 4:     add reg  : 3502 Pac_now 3518 S0_now 3520 S0_Day 3524 S0_Mon 3526 S0_Year 3516 Pac_all 3508 Pac_Day 3512 Pac_Mon 3514 Pac_Year 3528 S0_all
2019.09.27 17:43:47 4:   shift 0
2019.09.27 17:43:47 4:   shift 1
2019.09.27 17:43:47 4:   shift 2
2019.09.27 17:43:47 4:   shift 3
2019.09.27 17:43:47 4:   shift 4
2019.09.27 17:43:47 4:   shift 5
2019.09.27 17:43:47 4:   shift 6
2019.09.27 17:43:47 4:   shift 7
2019.09.27 17:43:47 4:   shift 8
2019.09.27 17:43:47 4:   shift 9
2019.09.27 17:43:47 4:     --------------------
2019.09.27 17:43:47 4:     new avg_values: 413, 737, 7793, 200291, 2637355, 77129398, 26911, 754575, 8248622, 35666907, 401, 737, 7793, 200291, 2637355, 77129401, 26914, 754578, 8248625, 35666907, 390, 761, 7805, 200303, 2637367, 77129404, 26917, 754581, 8248628, 35666919, 383, 761, 7805, 200303, 2637367, 77129407, 26920, 754584, 8248631, 35666919, 369, 2758, 7840, 200338, 2637402, 77129411, 26924, 754588, 8248635, 35666954, 374, 2758, 7840, 200338, 2637402, 77129414, 26927, 754591, 8248638, 35666954, 389, 2647, 7883, 200381, 2637445, 77129417, 26930, 754594, 8248641, 35666997, 398, 2647, 7883, 200381, 2637445, 77129421, 26934, 754598, 8248645, 35666997, 386, 2686, 7927, 200425, 2637489, 77129424, 26937, 754601, 8248648, 35667041, 388, 2686, 7927, 200425, 2637489, 77129426, 26939, 754603, 8248650, 35667041
2019.09.27 17:43:47 4:     Pac_now - 0
2019.09.27 17:43:47 4:     S0_now - 1
2019.09.27 17:43:47 4:     S0_Day - 2
2019.09.27 17:43:47 4:     S0_Mon - 3
2019.09.27 17:43:47 4:     S0_Year - 4
2019.09.27 17:43:47 4:     Pac_all - 5
2019.09.27 17:43:47 4:     Pac_Day - 6
2019.09.27 17:43:47 4:     Pac_Mon - 7
2019.09.27 17:43:47 4:     Pac_Year - 8
2019.09.27 17:43:47 4:     S0_all - 9


Woran kann das denn jetzt liegen? Ich finde eigendlich keinen direkten Fehler.

Gruß
Norbert
FHEM6.2 FB7490 FB7430 3xraspi2+3+4 2xHM-LAN-CFG 2xESP CUL868 CUNO868 HUE-Bridge Harmony-Hub 5xHM-LC-Sw-PI-2 3xHM-WDS30-T2-SN 1xHM-LC_Sw4-DR 3xHM-ES-PMSw1-PI 7xFS20SIG2 6xFS20KSE 2xHM-ES-PMSW1-PL 5xS300TH 1xASH2200 1xEM1000