"Flasche" Readings im go-eCharger mit MQTT

[Beta-User]

Eigentlich ist die Verbindung über WLAN ziemlich stabil (habe extra einen Access Point im Garten installiert).

qed...

Mal schauen, aber ich hege den leisen Verdacht, dass da schon kürzeste Aussetzer zu Problemen führen. Wäre gut, wir könnten das irgendwie abfangen.

Ich werde jetzt erstmal mit event-xxx Attributen spielen.
Die Links schaue ich mir mal an. Aber ein Text dazu geht schon sehr tief (für mein bescheidenes Perl Wissen)

Wenn du eine Art "Übersetzungs-Matrix" lieferst, kann ich versuchen, das mal in Code zu fassen. Die Matrix sollte so aussehen:

- Name des Readings, wie json2nameValue($EVENT) ihn liefert;
- Name des Readings, wie er sein soll (internationalisiert/englisch!);
- Höchstzeit, nach der getriggert werden soll (auch ohne Änderung, keine Angabe: unendlich)
- Schwelle in %, ab der erst ein Event generiert werden soll (Abweichung zum heutigen Reading-Wert)
- Schwelle als Absolutwertabweichung, ab der erst ein Event generiert werden soll (Abweichung zum heutigen Reading-Wert)

[Mitch]

qed...

Mal schauen, aber ich hege den leisen Verdacht, dass da schon kürzeste Aussetzer zu Problemen führen. Wäre gut, wir könnten das irgendwie abfangen.

Ganz ausschließen möchte ich das nicht, weil die Box nur einen ESP hat und der hat nicht so die WLAN Granate ist 
Im Anhang mal die Werte der letzten Nacht. -75dB sind jetzt nicht der Wahnsinn, aber zumindest ist das Signal stabil.

Wenn du eine Art "Übersetzungs-Matrix" lieferst, kann ich versuchen, das mal in Code zu fassen. Die Matrix sollte so aussehen:

- Name des Readings, wie json2nameValue($EVENT) ihn liefert;
- Name des Readings, wie er sein soll (internationalisiert/englisch!);
- Höchstzeit, nach der getriggert werden soll (auch ohne Änderung, keine Angabe: unendlich)
- Schwelle in %, ab der erst ein Event generiert werden soll (Abweichung zum heutigen Reading-Wert)
- Schwelle als Absolutwertabweichung, ab der erst ein Event generiert werden soll (Abweichung zum heutigen Reading-Wert)

Okay, schau ich mir am WE mal in Ruhe an und schreibe was.

[Mitch]

Hier noch die Antworten von go-e:

Der Charger verwendet MQTT-Version 3.1.1
bzgl. CONNACK: Ein solcher Fehler ist uns nicht bekannt. Wissen Sie bereits wodurch dieser verursacht wird bzw. haben Sie einen Verdacht?

[Mitch]

- Name des Readings, wie json2nameValue($EVENT) ihn liefert;
- Name des Readings, wie er sein soll (internationalisiert/englisch!);

Ich habe mal die API abgetippt und entsprechende mapping gemacht (siehe auch XLS im Anhang):

Code Auswählen Erweitern

version:version rbc:reboot_counter rbt:reboot_timer car:car amp:ampere err:error ast:access_state alw:allow_charging stp:stop_state cbl:cable_code pha:phase tmp:temperature dws:deca_watt_sec dwo:stop_energy adi:adapter_in uby:unlocked_by eto:energy_total wst:wifi_state nrg_1:voltage_l1 nrg_2:voltage_l2 nrg_3:voltage_l3 nrg_4:voltage_n nrg_5:ampere_l1 nrg_6:ampere_l2 nrg_7:ampere_l3 nrg_8:power_l1 nrg_9:power_l2 nrg_10:power_l3 nrg_11:power_n nrg_12:power_total nrg_13:power_factor_l1 nrg_14:power_factor_l2 nrg_15:power_factor_l3 nerg_16:power_factor_n fwv:firmware_version sse:serial_number wss:wifi_ssid wke:wifi_key wen:wifi_enabled tof:time_offset tds:daylight_saving_offset lbr:led_brightness aho:hours_charging afi:time_charging azo:awattar_zone ama:max_ampere al1:ampere_level1 al2:ampere_level2 al3:ampere_level3 al4:ampere_level4 al5:ampere_level5 cid:color_idle cch:color_charging cfi:color_charging_done lse:led_save_energy ust:unlock_state wak:wifi_hotspot_key r1x:flags dto:remaining_time nmo:norway_mode eca:rfid1_energy ecr:rfid2_energy ecd:rfid3_energy ec4:rfid4_energy ec5:rfid5_energy ec6:rfid6_energy ec7:rfid7_energy ec8:rfid8_energy ec9:rfid9_energy ec1:rfid10_energy rca:rfid1_id rcr:rfid2_id rcd:rfid3_id rc4:rfid4_id rc5:rfid5_id rc6:rfid6_id rc7:rfid7_id rc8:rfid8_id rc9:rfid9_id rc1:rfid10_id rna:rfid1_name rnm:rfid2_name rne:rfid3_name rn4:rfid4_name rn5:rfid5_name rn6:rfid6_name rn7:rfid7_name rn8:rfid8_name rn9:rfid9_name rn1:rfid10_name tme:time sch:scheduler sdp:scheduler_double_press upd:update_available cdi:cloud_disabled loe:loadmanagement_enabled lot:loadmanagement_total_ampere lom:loadmanagement_min_ampere lop:loadmanagement_priority log:loadmanagement_group_id lon:loadmanagement_number_charger lof:loadmanagement_fallback_ampere loa:loadmanagement_ampere lch:loadmanagement_seconds_power mce:mqtt_enabled mcs:mqtt_server mcp:mqtt_port mcu:mqtt_username mck:mqtt_key mcc:mqtt_connected

[Beta-User]

Oh yeah, das ist ja gruselig...

Eigentlich sollte man die Jungs da bei go-e fragen, ob die nicht eine etwas weniger gesprächige firmware liefern können, alle 5 Sekunden die WiFi-SSID, das braucht m.E. kein Mensch... Sowas will man doch nur wissen, wenn es sich ändert, und meinetwegen beim Starten der Box oder was auch immer das ist .

Na ja, wie dem auch sei, anbei der Versuch, das, was json2NameValue() mit Hilfe von jsonMap macht, sowie einen Teil der (bisherigen) userReadings in Code zu verlagern - das kommt "ganz normal" in das Modulverzeichnis (typ. opt/fhem/FHEM).

Kann aber sein, dass da ggf. eine ganze Anzahl Denkfehler drin sind, aber zumindest einen kurzen Test hat es überstanden, das passende Device sieht so aus:

Code Auswählen Erweitern

defmod go_echarger MQTT2_DEVICE go-echarger
attr go_echarger IODev m2server
attr go_echarger readingList go-eCharger/002227/status:.* { FHEM::attrT_go_e_Utils::j2rN_extended("go_echarger",$EVENT) }
attr go_echarger room MQTT2_DEVICE

Tendenziell würde ich jetzt ein weiteres Reading anlegen, das den Zeitpunkt der letzten vollständigen Aktualisierung enthält und erst mal alle "Neben-Readings" verwerfen, die jünger sind wie z.B. eine Stunde. Nach Ablauf der Zeit dann einen vollst. Check, ob es Änderungen gab und alles verwerfen, was nicht geändert war (oder von vorneherein gar keinen Wert enthält...) und das "Zeit-Reading" neu setzen.

Für die relativen Vergleiche der Hauptreadings sind ein paar Funktionen vorbereitet, aber die eigentliche Prüfschleife dazu müßte man erst noch bauen. Vielleicht findet sich auch ein Mitstreiter dafür, aus der Ferne ist das nicht so einfach, und über einige interne Abhängigkeiten und Effizienzfragen müßte man auch noch brüten, und die commandref überlasse ich dann definitiv euch...

[Mitch]

Wow, das ging aber schnell! Danke!

Ich werde das heute Abend, oder am WE in meine Testumgebung einbauen und testen.

[ZeitlerW]

Hallo zusammen,

ich hänge mich mal an das Thema ran.

@Beta-User

Vielen Dank für das Script. Das sieht sehr gut aus!

lG
Wolfgang

[Beta-User]

Vielen Dank für das Script. Das sieht sehr gut aus!

Danke für die Rückmeldung

...ist halt noch nicht fertig...

Als erstes sollte man mal den key mit dem WLAN-Passwort löschen (wer versendet denn sowas...?!?).

Ansonsten wäre die Frage, ob ihr das erweitern könnt, oder welche Hilfestellungen wer dazu benötigt?

[Mitch]

So, Test war erstmal positiv.
Einzig "Car" habe ich geändert, ich brauche die Zahlen. Da hängen DOIFs und StateIcon dran.

Aber an der Geschwätzigkeit hat sich (noch) nichts geändert.

Der Key wird ja immer vom Charger mitgeschickt, aber nicht in klar: *************

Ein "Fehler" ist mir mit nrg_16 aufgefallen.
Das gibt es ja eigentlich nicht, aber da nrg nicht mit 0 anfängt, muss das alles nach hinten geschoben werden.

[Beta-User]

OK, dann hier noch eine Iteration weiter:

Code Auswählen Erweitern

attr go_echarger readingList go-eCharger/002227/status:.* { FHEM::attrT_go_e_Utils::j2rN_extended($NAME,$EVENT,1) }
Die "1" bewirkt, dass der Status als Zahl erhalten bleibt...

Ansonsten habe ich den - wg. der Anonymisierung dann sowieso völlig kaum mehr verständlichen - Wifi-key mal rausgeslöscht und eine Schleife eingebaut, die alle keys ignoriert, die einen leeren Value zugeordnet haben. Könnte man bei Bedarf eine Positiv-Liste dazubasteln.

@Rudi: Es wäre nett, wenn du ggf. auch hin und wieder mal einen kritischen Blick auf den Code zwecks Optimierung etc. werfen würdest. Das könnte eine Art Prototyp für eine ganze Anzahl ähnlicher "Problemlöser" werden (Stichworte: ems-esp, ebus und sonos2mqtt).

[Mitch]

sieht gut aus, Danke!

Was man noch machen könnte (ich hatte dazu userreadings) sind Umrechnungen
z.B. time 0911201121 oder reboot_timer 320804491

Wobei mir gerade auffällt, der reboot_timer Wert kommt alle 5 Sek.
Ich denke, den könnte man komplett löschen.

EDIT: nrg_16 ist noch da  da ist ein Tippfehler meinerseits drinnen:     "nerg_16" => "power_factor_n",

[Mitch]

Hier noch ein Logauszug:

Code Auswählen Erweitern

2020.11.09 11:17:31 1: ERROR: Unhandled packet CONNACK, disconneting myBroker_192.168.0.81_61324
2020.11.09 11:17:31 1: PERL WARNING: Argument "" isn't numeric in multiplication (*) at (eval 42172) line 1.
2020.11.09 11:17:31 1: PERL WARNING: Argument "" isn't numeric in multiplication (*) at (eval 42171) line 1.
2020.11.09 11:17:31 1: PERL WARNING: Argument "" isn't numeric in multiplication (*) at (eval 42170) line 1.
2020.11.09 11:16:13 1: ERROR: Unhandled packet PUBREL, disconneting myBroker_192.168.0.81_55590
2020.11.09 11:15:02 1: ERROR: Unhandled packet PUBCOMP, disconneting myBroker_192.168.0.81_63255
2020.11.09 11:14:44 1: PERL WARNING: Subroutine j2rN_extended redefined at ./FHEM/99_attrT_go_e_Utils.pm line 166.
2020.11.09 11:14:44 1: PERL WARNING: Subroutine compRel redefined at ./FHEM/99_attrT_go_e_Utils.pm line 255.
2020.11.09 11:14:44 1: PERL WARNING: Subroutine compAbs redefined at ./FHEM/99_attrT_go_e_Utils.pm line 247.
2020.11.09 11:14:44 1: PERL WARNING: Subroutine Initialize redefined at ./FHEM/99_attrT_go_e_Utils.pm line 35.
2020.11.09 11:14:44 1: PERL WARNING: Subroutine main::attrT_go_e_Utils_Initialize redefined at ./FHEM/99_attrT_go_e_Utils.pm line 32.

[ZeitlerW]

Hallo zusammen,

ich hätte da noch eine Aktualisierung für die %jsonmap

Code Auswählen Erweitern


    "tma_1" => "internal_temperature_sensor_1",
    "tma_2" => "internal_temperature_sensor_2",
    "tma_3" => "internal_temperature_sensor_3",
    "tma_4" => "internal_temperature_sensor_4",
    "amt" => "max_ampere_temperature"


Bei nrg_16 ist ein Typo in der %jsonmap muss heißen:

Code Auswählen Erweitern


    "nrg_16" => "power_factor_n",


lG
Wolfgang

[rudolfkoenig]

Hier noch ein Logauszug:

Das sind mehrere Probleme, und es ist nicht sinnvoll, alles hier zusammen in einem Thread zu diskutieren:
- "unhandled packet": (wie oben geschrieben) Netzwerk-,Firmware-, oder FHEM-Problem. Es hilft nicht sie hier zu wiederholen, ich brauche einen TCP-Log, am besten eine Minute vor dem Problem bis zum Problemfall, um zu entscheiden, ob FHEM Muell baut, oder ob die Daten schon kaputt ankommen.
- "isn't numeric": mit "attr global stacktrace" kriegt man raus, woran da liegt, kann auch was ganz anderes sein.
- "redefined": das ist normal, wenn man ein Modul wieder in FHEM laedt.

[Beta-User]

So, hoffe, (fast) alles aufgegriffen zu haben.
Es spricht aus meiner Sicht nichts dagegen, wenn ihr den Code selbst entsprechend aufbohrt bzw. korrigiert und dann das Ergebnis postet/konsolidiert .

Das mit der Umrechnung wäre z.B. auch kein großes Thema, aber ohne den userReadings-Code habe ich auch nicht die rechte Lust zu raten, wie die Umrechnung denn jetzt korrekterweise vorzunehmen wäre.

Wenn es nach mir geht, wäre das hier vorläufig die letzte Version, die ich hier im Alleingang poste, jetzt wärt ihr mal dran, es sollte in dem "framework" jetzt eigentlich alles an Tools drin sein, was man so braucht, einschließlich der _Vorbereitung_ einer "hourly"-Aktualisierung (kann man auf andere "Schlüsselworte" ausweiten, wenn man das braucht)...