JSON: Wie den Inhalt aus HSBColor in 3 Readings ?

Begonnen von TomLee, 25 Februar 2020, 18:48:40

Vorheriges Thema - Nächstes Thema

TomLee

Und sonst gibts doch nur noch "updates" beim schalten, mehr kommt bei mir nicht in regelmäßigen Abständen.

15:03:02 MQT: stat/sonoffs20/RESULT = {"POWER1":"on"}
15:03:02 MQT: stat/sonoffs20/POWER1 = on
15:03:04 MQT: stat/sonoffs20/RESULT = {"POWER1":"off"}
15:03:04 MQT: stat/sonoffs20/POWER1 = off

rudolfkoenig

ZitatEs geht also darum, genau diese unnötigen update-Infos (ohne Änderung) zu verwerfen
Diese Infos sind aber fuer _mich_ nicht unnoetig.

Mein Beispiel mit der Temperatur war unvollstaendig: wenn ich nicht weiss, wann zuletzt die Temperatur noch 8 Grad war, dann muss ich annehmen, dass bis kurz vor der 9 Grad Meldung das war. Es kann aber auch sein, dass ich seit Tagen keine Nachrichten bekomme, und ich will das nicht mit zusaetzlicher LWT-Logik pruefen, sondern das Problem _einfach_ im Plot sehen.
Das Entfernen von Events bewirkt zusaetzlich, dass man in den SVG-Plots Workarounds (aka. Luege) einbauen muss, wie letzten Wert vor dem Zeitraum finden, weiterhin muss man statt Linien Steps verwenden, etc.

Ich will nicht sagen, dass man nie Filtern soll, allerdings sollte das der Benutzer entscheiden, und nicht das Modul, und schon gar nicht alternativlos. Meiner Ansicht nach ist das hier beobachtete Bestreben der Benutzer nur Aenderungen als Event weiterzugeben falsch, ich selbst habe keinen einzigen event-on- Attribut im Einsatz.

Beta-User

OK, das mit dem erweiterten Temperaturbeispiel leuchtet ein, das könnte in der Tat schlicht ein echter und erwünschter Meßwert sein. Den wollte ich auch haben, wenn ich mir das recht überlege...

Was mich stört, sind die Art von updates, die (für mich) gar keinen Mehrwert haben, wie das POWER1 in der tele-Message (da haben wir das aber mit jsonMap bereits "gelöst") und ähnliche Effekte, die es bei Shelly gibt (meine diesbezügliche Frage an die Runde, ob und wie man das ggf. dort ausschalten könnte wurde nicht beantwortet, jedenfalls soweit ich das überblicke: https://forum.fhem.de/index.php/topic,94060.msg1020431.html#msg1020431 (da ist auch der Link zu dem Thread drin, in dem das das erste Mal intensiver Thema war).). Und auch dazu, ob man das bei Tasmota via Backlog ganz ausschalten sollte, habe ich noch keine Meinung, eben weil nicht klar ist, ob man damit zu viel unterdrückt (das bezieht sich auf TomLee's Frage).

Vielleicht noch zur Vervollständigung des Bilds, wo das die Dinge noch vereinfachen könnte:
- Wir hatten es bei dem 8-fach-LAN-Modul (dort aber prinzipbedingt nicht ausschaltbar; aber da kommt der Grundcode her, den TomLee hier modifiziert hat).
- Es würde weiter den wled_controller deutlich vereinfachen, weil man den ganzen Hash übergeben könnte.

Hm, auf die Schnelle fällt mir keine überzeugende Lösung ein.
Eventuell doch ein weiteres Attribut, dann aber im Stile der "event-on-..."-Attribute? "event-on-change-json"? (oder: "noevent-on-update-json"?)
Funktion: Wenn
- gesetzt = alles, was dort auf die dort als space-separated regex angegebenen Argumente paßt, wird an "Bulk-updateIfChanged" übergeben, was nicht paßt an "normales Bulk-update" ? Ein .* würde dann Auswirkungen auf alle Readings haben, mit "state" (bzw. ohne jsonMap/bei den mehrkanaligen "POWER.") könnte man (mAn.) "false positives" rausfiltern...
- nicht gesetzt = "as is" = ReadingsBulkUpdate

Der Name mit "json" wäre dann etwas verengend, aber da json2nameValue() der Hauptanwendungsfall bleiben dürfte, wäre es evtl. verständlich, und die Erweiterung, dass es auf alle Hash-Rückgaben wirkt, kann man ja dazuschreiben?

Muß vermutlich darüber nochmal nachdenken...
Server: HP-elitedesk@Debian 12, 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: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rudolfkoenig

Ich verstehe immer noch nicht, warum das Modul ein Extra event-on-change Attribut anbieten soll.
Wenn jemand sowas haben will (und ich habe noch keinen Beispiel gesehen, was mich ueberzeugt), der kann den globalen event-on-change verwenden.

Beta-User

Ich schau mir bei Gelegenheit das mit den Zeitstempeln iVm. event-on-change noch mal an, irgendwie werde ich das Gefühl nicht los, was übersehen zu haben...
Server: HP-elitedesk@Debian 12, 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: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

TomLee

In der Definition von #21 ist noch ein Beispiel für fade, mode und speed, das mein ich gibts auch noch in keinem Template und dachte wird eventuell auch übernommen, egal mit welchem Widget umgesetzt ?