Autor Thema: "Flasche" Readings im go-eCharger mit MQTT  (Gelesen 2625 mal)

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16259
Antw:"Flasche" Readings im go-eCharger mit MQTT
« Antwort #30 am: 09 November 2020, 12:43:43 »
Sorry, in der Vorversion war noch ein Rest von einem etwas anderen Ansatz des Löschens drin; bitte an den einen, der das schon runtergeladen hatte, die neue aus dem Vorpost zu nehmen...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline Mitch

  • Hero Member
  • *****
  • Beiträge: 2568
  • Give more - Expect less
Antw:"Flasche" Readings im go-eCharger mit MQTT
« Antwort #31 am: 09 November 2020, 13:06:56 »
Danke!

Ich habe noch zwei Werte rausgenommen:
  "always"  => ["wifi_key","reboot_timer","loadmanagement_seconds_power","time"],
Was noch genial wäre, wenn man irgendwo ein Wert für die Readings eingeben könnte. So wie jetzt always und hourly.
Leider sind meine Perl-Kenntnisse dazu nicht gut genug  :-[

z.B. würde es reichen, die Werte für voltage_lx nur alle 5 Minuten zu schreiben.
FHEM im Proxmox Container

https://ts.la/markus34522

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16259
Antw:"Flasche" Readings im go-eCharger mit MQTT
« Antwort #32 am: 09 November 2020, 14:29:23 »
Hmm, also...

Jetzt habe ich noch zwei "Zeitschleifen" dazu gebastelt, und hoffe, damit haben wir das Spielmaterial jetzt wirklich beieinander:
- Die Zeiten sollten einstellbar sein, das war die Absicht hinter dem %toCompare und dem Ergänzen dieses Hashes mit Parametern aus dem Funktionsaufruf (default sind 10 Minuten);
- bei den "stündlichen" habe ich das weiter dahingehend eingeschränkt, dass nur Events kommen, wenn es da Änderungen gab, die Kombination ist aber ein logisches UND, was für diese Art Readings ok ist, aber nicht einfach so für andere übernommen werden sollte;
- erstmals berücksichtigt sind absolute bzw. relative Vergleiche in der "voltage"-Schleife. Falls das aus eurer Sicht tauglich ist, müßte man das dann noch für die anderen Typen ergänzen bzw. ändern, indem man die Verweise auch in %toCompare ergänzt. Hier ist es ein logisches "oder", womit sich die Frage stellt, ob man das für den anderen Fall (Zeit ist abgelaufen) ganz oder in Teilen dann weiter mit einer "eocr"-Logik einschränken möchte oder nicht.

Sieht zwar recht abstrakt aus, aber ich hoffe, ihr könnt euch halbwegs in dem Code orientieren...?
« Letzte Änderung: 05 August 2021, 09:16:40 von Beta-User »
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 24676
Antw:"Flasche" Readings im go-eCharger mit MQTT
« Antwort #33 am: 09 November 2020, 21:50:20 »
Zitat
@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.
Bin nicht sicher, ob ich fuer solche Aufgaben der Richtige bin.
Es ist vermutlich noch Work-in-Progress, sonst waere die letzte Schleife nicht ganz leer.
Ansonsten habe ich nichts zu bemaengeln, nur dass die Doku nicht zum Code passt. :)

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16259
Antw:"Flasche" Readings im go-eCharger mit MQTT
« Antwort #34 am: 10 November 2020, 10:57:00 »
Danke auf alle Fälle für's feedback, und Doku hatte ich ja schon angemerkt, dass das bitte dann jemand anderes machen sollte - sonst wird es eben nicht eingeckeckt...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline ZeitlerW

  • Full Member
  • ***
  • Beiträge: 176
Antw:"Flasche" Readings im go-eCharger mit MQTT
« Antwort #35 am: 17 November 2020, 14:46:28 »
Hallo Beta-User,

ich werde mich um die Optimierung (oder auch Weiterentwicklung) für das Modul kümmern, soweit dies um die Funktion der Ladebox geht. Für die Json / MQTT2 spezifischen Themen und dem Check in würde ich mich freuen  wenn Du mich unterstützen könntest.

Viele Grüße
Wolfgang

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16259
Antw:"Flasche" Readings im go-eCharger mit MQTT
« Antwort #36 am: 17 November 2020, 14:53:35 »
Gerne, klingt nach einer guten Arbeitsteilung :) .

Was mir im Nachgang noch eingefallen war: vor den Checks auf Veränderung sollte man vermutlich noch einen auf "identisch" einbauen; wenn der "zuschlägt", braucht man nämlich gar nicht mehr rechnen, was (im Ergebnis häufig) deutlich schneller sein dürfte.

Ansonsten liest hier ja auch Rudi mit, falls spezifische Fragen auftreten; ich bin eigentlich auch nicht der Experte, was "hash-Schubsen" angeht...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

 

decade-submarginal