ebusd.mqtt2.template: Fragen, Anregungen

Begonnen von TomLee, 28 Februar 2019, 17:04:14

Vorheriges Thema - Nächstes Thema

Reinhart

Nachdem ich im Hauptsystem MQTT2_Client aktiviert habe, habe ich mir die Logs angeschaut und dabei festgestellt wenn noch ein expandJson mit "ebus.*" in Fhem aktiv ist, dann kommt es offensichtlich aus dem Modul zu Fehler.

2019.03.09 21:00:11 2: expandJSON ej3: Bad JSON: ebusMQTT ebusd/bai/Status01:{
     "0": {"name": "temp1", "value": 27.0},
     "1": {"name": "temp1", "value": 27.0},
     "2": {"name": "temp2", "value": 7.750},
     "3": {"name": "temp1", "value": 29.0},
     "4": {"name": "temp1", "value": 31.0},
     "5": {"name": "pumpstate", "value": "off"}}
2019.03.09 21:00:11 2: expandJSON ej3: garbage after JSON object, at character offset 32 (before ",\n     "1": {"name"...") at ./FHEM/98_expandJSON.pm line 179.

2019.03.09 21:00:16 2: expandJSON ej3: Bad JSON: ebusMQTT ebusd/bai/SetMode:{
     "hcmode": {"value": "auto"},
     "flowtempdesired": {"value": 22.0},
     "hwctempdesired": {"value": null},
     "hwcflowtempdesired": {"value": null},
     "disablehc": {"value": 0},
     "disablehwctapping": {"value": 0},
     "disablehwcload": {"value": 1},
     "remoteControlHcPump": {"value": 0},
     "releaseBackup": {"value": 0},
     "releaseCooling": {"value": 0}}
2019.03.09 21:00:16 2: expandJSON ej3: garbage after JSON object, at character offset 17 (before ",\n     "flowtempdes...") at ./FHEM/98_expandJSON.pm line 179.

2019.03.09 21:00:16 2: expandJSON ej3: Bad JSON: ebusMQTT ebusd/430/Hc1HeatCurve:{
     "curve": {"value": 0.20}}
2019.03.09 21:00:16 2: expandJSON ej3: garbage after JSON object, at character offset 15 (before "}") at ./FHEM/98_expandJSON.pm line 179.

2019.03.09 21:00:17 3: netatmo_aussen: poll (MODULE)
2019.03.09 21:00:17 3: netatmo_aussen: requestDeviceReadings (Temperature,Humidity)
2019.03.09 21:00:17 5: publish received for tele/sonoff_electrodragon2/SENSOR, {"Time":"2019-03-09T21:00:16","DHT11":{"Temperature":9.0,"Humidity":26.0},"BH1750":{"Illuminance":0},"TempUnit":"C"}
2019.03.09 21:00:17 3: netatmo_aussen: next dynamic update from device (Temperature,Humidity) at 2019-03-09 21:10:18
2019.03.09 21:00:21 2: expandJSON ej3: Bad JSON: ebusMQTT ebusd/bai/Status01:{
     "0": {"name": "temp1", "value": 27.0},
     "1": {"name": "temp1", "value": 27.0},
     "2": {"name": "temp2", "value": 7.750},
     "3": {"name": "temp1", "value": 29.0},
     "4": {"name": "temp1", "value": 31.0},
     "5": {"name": "pumpstate", "value": "off"}}
2019.03.09 21:00:21 2: expandJSON ej3: garbage after JSON object, at character offset 32 (before ",\n     "1": {"name"...") at ./FHEM/98_expandJSON.pm line 179.

2019.03.09 21:00:21 2: expandJSON ej3: Bad JSON: ebusMQTT ebusd/bai/Status02:{
     "0": {"name": "hwcmode", "value": "auto"},
     "1": {"name": "temp0", "value": 60},
     "2": {"name": "temp1", "value": 70.0},
     "3": {"name": "temp0", "value": 70},
     "4": {"name": "temp1", "value": 54.0}}
2019.03.09 21:00:21 2: expandJSON ej3: garbage after JSON object, at character offset 36 (before ",\n     "1": {"name"...") at ./FHEM/98_expandJSON.pm line 179.

2019.03.09 21:00:26 2: expandJSON ej3: Bad JSON: ebusMQTT ebusd/bai/SetMode:{
     "hcmode": {"value": "auto"},
     "flowtempdesired": {"value": 22.0},
     "hwctempdesired": {"value": null},
     "hwcflowtempdesired": {"value": null},
     "disablehc": {"value": 0},
     "disablehwctapping": {"value": 0},
     "disablehwcload": {"value": 1},
     "remoteControlHcPump": {"value": 0},
     "releaseBackup": {"value": 0},
     "releaseCooling": {"value": 0}}
2019.03.09 21:00:26 2: expandJSON ej3: garbage after JSON object, at character offset 17 (before ",\n     "flowtempdes...") at ./FHEM/98_expandJSON.pm line 179.

2019.03.09 21:00:31 2: expandJSON ej3: Bad JSON: ebusMQTT ebusd/bai/SetMode:{
     "hcmode": {"value": "auto"},
     "flowtempdesired": {"value": 22.0},
     "hwctempdesired": {"value": null},
     "hwcflowtempdesired": {"value": null},
     "disablehc": {"value": 0},
     "disablehwctapping": {"value": 0},
     "disablehwcload": {"value": 1},
     "remoteControlHcPump": {"value": 0},
     "releaseBackup": {"value": 0},
     "releaseCooling": {"value": 0}}
2019.03.09 21:00:31 2: expandJSON ej3: garbage after JSON object, at character offset 17 (before ",\n     "flowtempdes...") at ./FHEM/98_expandJSON.pm line 179.

2019.03.09 21:00:31 2: expandJSON ej3: Bad JSON: ebusMQTT ebusd/bai/DateTime:{
     "dcfstate": {"value": "nosignal"},
     "btime": {"value": "13:03:11"},
     "bdate": {"value": "-.-.-"},
     "temp2": {"value": 7.750}}
2019.03.09 21:00:31 2: expandJSON ej3: garbage after JSON object, at character offset 21 (before ",\n     "btime": {"v...") at ./FHEM/98_expandJSON.pm line 179.

2019.03.09 21:00:31 2: expandJSON ej3: Bad JSON: ebusMQTT ebusd/bai/Status01:{
     "0": {"name": "temp1", "value": 27.0},
     "1": {"name": "temp1", "value": 27.0},
     "2": {"name": "temp2", "value": 7.750},
     "3": {"name": "temp1", "value": 29.0},
     "4": {"name": "temp1", "value": 31.0},
     "5": {"name": "pumpstate", "value": "off"}}
2019.03.09 21:00:31 2: expandJSON ej3: garbage after JSON object, at character offset 32 (before ",\n     "1": {"name"...") at ./FHEM/98_expandJSON.pm line 179.

2019.03.09 21:00:31 2: expandJSON ej3: Bad JSON: ebusMQTT ebusd/430/Hc1HeatCurve:{
     "curve": {"value": 0.20}}
2019.03.09 21:00:31 2: expandJSON ej3: garbage after JSON object, at character offset 15 (before "}") at ./FHEM/98_expandJSON.pm line 179.

2019.03.09 21:00:41 2: expandJSON ej3: Bad JSON: ebusMQTT ebusd/bai/SetMode:{
     "hcmode": {"value": "auto"},
     "flowtempdesired": {"value": 22.0},
     "hwctempdesired": {"value": null},
     "hwcflowtempdesired": {"value": null},
     "disablehc": {"value": 0},
     "disablehwctapping": {"value": 0},
     "disablehwcload": {"value": 1},
     "remoteControlHcPump": {"value": 0},
     "releaseBackup": {"value": 0},
     "releaseCooling": {"value": 0}}
2019.03.09 21:00:41 2: expandJSON ej3: garbage after JSON object, at character offset 17 (before ",\n     "flowtempdes...") at ./FHEM/98_expandJSON.pm line 179.

2019.03.09 21:00:41 2: expandJSON ej3: Bad JSON: ebusMQTT ebusd/bai/Status01:{
     "0": {"name": "temp1", "value": 27.0},
     "1": {"name": "temp1", "value": 27.0},
     "2": {"name": "temp2", "value": 7.750},
     "3": {"name": "temp1", "value": 29.0},
     "4": {"name": "temp1", "value": 31.0},
     "5": {"name": "pumpstate", "value": "off"}}
2019.03.09 21:00:41 2: expandJSON ej3: garbage after JSON object, at character offset 32 (before ",\n     "1": {"name"...") at ./FHEM/98_expandJSON.pm line 179.

2019.03.09 21:00:41 2: expandJSON ej3: Bad JSON: ebusMQTT ebusd/430/Hc1HeatCurve:{
     "curve": {"value": 0.20}}
2019.03.09 21:00:41 2: expandJSON ej3: garbage after JSON object, at character offset 15 (before "}") at ./FHEM/98_expandJSON.pm line 179.


Die Definition von ej3 war dabei so:
(Sonoff.*|ebus.*|robonect.*:.*:.{.*.*{.*.*}})
Ich habe jetzt ebus entfernt und das Log ist wieder ok.

Eigentlich ist es auch sinnlos, beide Varianten gleichzeitig zu betreiben, man darf es nur nicht vergessen zu entfernen.

LG
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

Beta-User

Zitat von: Reinhart am 09 März 2019, 17:49:13
Es gibt schon diverse Inbetriebnahme Threads wo ich schon einmal kurz auf das Thema MQTT2 eingegangen bin. Das werde ich demnächst auf letzten Stand bringen. Ebenso plane ich im eBusWiki das Thema MQTT2 mit Installation und Beispielen noch zu erweitern und auf MQTT2 zu verlinken.
Klingt gut, bei Gelegenheit werde ich dann nur kurz in den Praxisbeispielen den ebus erwähnen und erst mal auf den Thread hier und deine Einrichtungsanleitung im Forum verlinken. Dann kannst du das dann "umbiegen" oder ergänzen, wenn mehr im Wiki zu finden ist.
ZitatDas Thema alles in einen Pott zu werfen finde ich nicht gut weil das mehrere Hundert bis Tausend Datenpunkte sein können!
Hmm, vielleicht reden wir da aneinander vorbei:
Auf der MQTT-Seite sollte eine +/+/get-Anfrage alles liefern, was der jeweilige Client eben liefern kann/darf. Das geschieht bei bai, da werden dann aber nur die Datenpunkte geliefert, die der Client dazu verfügbar hat. Sollte eigentlich bei 430 genauso sein (in deiner Konfiguration eben mit den 2 Werten, die man einzeln abfragen kann).
Ob er intern dazu pollen muß, ist eine ganz andere Frage. Dass das ggf. nicht sinnvoll ist, ist ebenso klar, wie dass es keinen Sinn macht, durch so eine Methode plötzlich zusätzliche Datenpunkte "aufzumachen". Das betrifft aber die Programmierung/Konfiguration des Clients (also des ebus-Daemon).

ZitatUnd ja du hast recht, ich werde noch einige Beispiele aus dem Template rausnehmen weil die sich eh überschneiden. Eigentlich ist so ein Template ja ein extrem hoher Komfort, aber etwas Raum für die eigenen Ideen der Anwender sollte man hier offen lassen.
Hmm, sehr viele sind einfach froh, wenn sie mit dem Tool click+play hinbekommen. Wir werden sehen, wie die Nutzergemeinde dazu wächst.
Persönlich finde ich den "MQTT2"-Weg extrem komfortabel und würde (auch wegen der asynchronen Kommunikation) keine anderen Methoden mehr nutzen, wenn der jeweilige entfernte Dienst MQTT anbietet (und ggf. entsprechend abzusichern ist).

Geht bestimmt noch mehr Usern so, aber dazu vielleicht eine kleine Anekdote:
Ich habe mal vor Jahren auf Bitten des Autors die MQTT-Einführungsartikel Korrektur gelesen. In der Antwort auf die Bitte stand sinngemäß: "ist schon irgendwie nett mit dem MQTT, aber bitte verschone mich, ich will das nicht in meiner Installation haben, solange es irgendwie anders geht...!"
Erst mit der sidoh-MiLight-Bridge hatte ich einen sinnvollen Anwendungsfall, aber das war auch noch ein Riesenkrampf mit JSON-Blob-Erstellung in Senderichtung und expandJSON?!? Da habe ich nie verstanden, warum das notwendig ist und wie das eigentlich funktioniert... Dann irgendwelche cpan-Dinge, die mal nicht mal mit apt-get (ohne weiteres) installiert bekommt?!? War mir alles suspekt...

Aber jetzt?
Erlebe ich fast täglich die Rückmeldung: Was, so einfach geht das  :o ;D ? Super!

Und wer die (an sich doch einfachen) Zusammenhänge mal geschnallt hat, hat einen superflexiblen Baukasten.

Von daher: Jeder wie er mag, aber ihr dürft davon ausgehen, dass mehr neue User den MQTT-Weg gehen werden.
Und ein (noch entsprechend auszubauendes) gutes Beispiel für JSONMAP sollte es obendrein sein. Aber da seid ihr jetzt am Zug :P !
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

Reinhart

Da bin ich ganz auf deiner Seite, ich bin auch der Meinung das MQTT sich immer mehr zum Protokoll im Smarthome Bereich entwickeln wird. Wenn man beim Ali schaut, so bietet fast jedes Smarthome fähige Gerät MQTT an, Wifi und HTTP ist da schon eher die Ausnahme.

Zum Thema expandJson, das war lange Zeit der einzige komfortable Weg so einen verschachtelten Json String (siehe Status01) in einzelne Readings aufzudröseln und hat dem leidgeplagten gute Dienste verrichtet. Genau diese Umstände haben besonders Neueinsteiger vor dem Thema MQTT abgeschreckt und genau das hat jetzt Rudolf mit der Implementierung der Templates komplett entschärft und noch ein Zuckerl draufgegeben.

Nur leider, viele wissen das noch nicht und das ist jetzt unsere Aufgabe das zu publizieren!

LG
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

rudolfkoenig

ZitatAllerdings geht MQTT2CLIENT bei sowas ganz kurz auf disconnected?
MQTT2_CLIENT geht auf disconnected, falls einer der folgenden Attribute _nach_ Einlesen der fhem.cfg geaendert wird: clientId, lwt, lwtRetain, subscriptions, SSL, username. Auch wenn per set Passwort gesetzt wird, oder MQTT2_GENERIC_BRIDGE die subscriptions aendert. Und natuerlich bei Kommunikationsproblemen, mit Fehlermeldung.
Falls ich was uebersehen habe, bitte es mit einem verbose 5 Log belegen.

ZitatWas ich - jedenfalls mal als ersten Gedanken - an sich nicht schlecht fände, wäre eine Option, die Zahl der jeweils angezeigten templates etwas reduzieren zu können
Bisher konnte filter nur auf die Gleichheit mit einem Internal pruefen, wir verwenden aktuell auch nur TYPE=XXX. Ich habe filter umgebaut auf devspec Syntax (siehe https://fhem.de/commandref_modular.html#devspec), damit duerfte man auf so ziemlich alles pruefen, auf Kosten der Performance. Ich hoffe das Problem durch Caching zu minimieren, allerdings muss man nach (relevanter) Attributaenderung FHEM neu starten oder {AttrTemplate_Initialize()} ausfuehren.


Reinhart

@Beta-User

habe soeben das Wiki erweitert und um die eBus Praxisbeispiele erweitert (Punkt 6 eBus)
Da du der Autor der Wiki Seite bist ersuche ich das zu kontrollieren und gegebenenfalls zu korrigieren oder mir sagen.
Ich glaube es passt hier besser rein als im allgemeinen eBus Wiki wo es eigentlich um den eBus selbst geht. Ich kann es ja von dort auf den Praxisbeispiele Artikel verlinken.

LG
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

Beta-User

Zitat von: rudolfkoenig am 10 März 2019, 12:47:14
Bisher konnte filter nur auf die Gleichheit mit einem Internal pruefen, wir verwenden aktuell auch nur TYPE=XXX. Ich habe filter umgebaut auf devspec Syntax (siehe https://fhem.de/commandref_modular.html#devspec), damit duerfte man auf so ziemlich alles pruefen, auf Kosten der Performance. Ich hoffe das Problem durch Caching zu minimieren, allerdings muss man nach (relevanter) Attributaenderung FHEM neu starten oder {AttrTemplate_Initialize()} ausfuehren.
Danke!
Ich teste das mal und "verstecke" dann, was jeweils m.E. nicht paßt. Sollte halt im Wiki dann erwähnt werden, nicht, dass jemand was vermisst ;D ...
(Ich gehe aber davon aus, dass es sich um ein reines Anzeigethema handelt und man "mit Gewalt" immer noch "jedes" template anwenden kann? Bitte ggf. nicht ändern, geht nur darum, wie man das den usern erklärt....).

Zitat von: rudolfkoenig am 10 März 2019, 12:47:14
MQTT2_CLIENT geht auf disconnected, falls einer der folgenden Attribute _nach_ Einlesen der fhem.cfg geaendert wird: clientId, lwt, lwtRetain, subscriptions, SSL, username. Auch wenn per set Passwort gesetzt wird, oder MQTT2_GENERIC_BRIDGE die subscriptions aendert. Und natuerlich bei Kommunikationsproblemen, mit Fehlermeldung.
Falls ich was uebersehen habe, bitte es mit einem verbose 5 Log belegen.
Das teste ich bei Gelegenheit ggf. nochmal und liefere auch die logs, aber beobachtet hatte ich das wie geschrieben bei einem simplen publish mit "ebusd/+/+/get" im Event-Monitor.


@Reinhart:
Danke für den Wiki-Teil. Ich bin noch etwas drübergegangen und habe zunächst mal "nur" manches umsortiert und leicht geändert (du hattest noch ein MQTT-Gerät definiert ;) ), für einen nochmaligen kritischen Blick wäre ich aber dankbar, nicht, dass jetzt was wesentliches fehlt.
M.E. müßte man da aber noch in mehrfacher Hinsicht drüber:
- zu einen, was die Verlinkung im Wiki angeht (Bsp: myUtils-Code, readingsGroup);
- zum anderen, was den Gesamtzusammenhang angeht. Dieser Teil ist nach meinem Geschmack im Moment _an dieser Stelle_ "zu ausführlich"; was attrTemplates sind, steht z.B. weiter unten bzw. wird bei den vorhergehenden Beispielen erläutert; ganz vorne im Artikel steht, dass man MQTT2_SERVER nutzen soll bzw. sich alle Beispiele darauf beschränken (was dann hier aber durchbrochen wird) usw..
Da es m.E. schon Sinn macht, die ebus-spezifische Darstellung tatsächlich ausführlich zu machen, habe ich das erst mal so ausführlich gelassen, damit man es ggf. einfacher in einen eigenständigen Artikel (ebusd mit MQTT2) auslagern kann; wenn das hier bleiben soll, würde ich die "allgemeinen" Themen deutlich kürzen.
Spezielle Dinge, die nur für MQTT2_CLIENT gelten, könnten ggf. in eine Infobox oder so verlagert werden, oder es gibt einen Passus im Artikel zu diesem Modul, in der entsprechende Erkenntnisse landen.

Hätte aber gerne vorher Rückmeldungen dazu, vielleicht denke ich da auch zu "betriebsblind"...
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

Reinhart

beim Thema eBus habe ich schon gelernt möglichst nicht zu technisch aber dafür Schritt für Schritt mit vielen Codebeispielen vorzugehen. Da wir gerade eine Sammelbestellung von 250 Adaptern beendet haben, waren hier eindeutig der Großteil der Besteller Newcomer. Ich schätze es haben sich gut 200 User neu im Forum registriert um die Bestellung durchführen zu können. Viele davon installieren sich jetzt Fhem nur um ihr Heizgerät auslesen zu können und da kommen jetzt die Templates ins Spiel was ihr Vorhaben erleichtert. Einige koppeln dann mit Loxone oder anderem, aber dafür ist ja Fhem auch sehr gut beschaffen.

Das nur als Hintergrund warum der Artikel was die einzelnen Schritte betrifft sehr genau ausgeführt ist, aber andererseits nicht genauer eingeht was eigentlich Unterschied zwischen Server und Client ist. Immerhin geht es um das Thema Praxisbeispiele, deshalb glaube ich das es in diesem Wiki der Praxisbeispiele besser aufgehoben ist als im eBus Wiki, kann man aber mit geringem Aufwand ändern.

Auf jeden Fall war mein Ziel, von oben nach unten lesen ( Bilder anschauen ) und Klick klack und alles läuft obwohl der Anwender selbst noch keine Erfahrung mit Fhem mitbringt. Ich denke da an mich selbst als ich vor einigen Jahren auch so begonnen habe, ich wollte einfach einen Strom und Gaszähler auslesen und bin durch Zufall auf Fhem gestoßen. Erst in der Praxis habe ich das Potential von Fhem entdeckt und so geht es den meisten Neueinsteigern.

Und ja, verlinken muss ich noch nacharbeiten, da hast du völlig recht, da dies ja wertvolle Informationsquellen sind wenn jemand mehr daraus machen möchte.  Man kann sich aber auch überlegen den Teil komplett zu aus dem Wiki zu verbannen und in einen der zahlreichen Inbetriebnahmethreads in reduzierter Form zu posten, dann wird zumindest das Wiki nicht so überladen und dort lesen auch die Neueinsteiger fleißig mit.

Sage mir einfach wie du das handhaben willst.

LG
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

Beta-User

Sorry, da haben wir uns mal wieder mißverstanden :) :

Der Artikel an sich ist gut! Auch die Bebilderung paßt! Und er gehört m.E. auch ins FHEM-Wiki und nicht "verbannt" (wie kommst du drauf, dass das meine Intension sein könnte :o ?)

Deswegen habe ich ihn auch in Schritt 1 nur dort geändert, wo es m.E. her vom Ablaufverständnis, Wording uä. her Bedarf gab. Da hoffe ich, dass diese Änderungen auch in deinen Augen passen und für Anfänger hilfreich sind.

Dass es auch aus ebus-Sicht ein separates Thema ist, sehe ich auch so. Habe eben auch kurz einen Blick in die Wiki-Seite zum ebus geworfen (https://wiki.fhem.de/wiki/EBUS). Spontan würde ich denken, dass die einfachste Vorgehensweise die wäre, das wie folgt zu machen:
- Aus dem Ebus-Artikel die Visualisierung und Steuerung hinsichtlich des ECMD-Teils ausgliedern in einen separaten Artikel. An der ursprünglichen Stelle nur die Überschrift belassen und eine Summary (wie aktuell zu gaebus).
- Dort im EBUS-Artikel die Option mit MQTT(2) ergänzen (wenn es insgesamt einfacher ist als ECMD und denselben Funktionsumfang (demnächst) haben kann: Vor ECMD. Wieder nur die Überschrift und eine summary.
- Den jetzigen ebus-Teil in den dort (ebus-Wiki) verlinkten eigenen Artikel (komplett "as is"; nur die Überschriften-Level wären anzupassen (und ggf. die Lobhudelei vorneweg weglassen, jedenfalls ich lege auf sowas keinen gesteigerten Wert :P )
- An der Stelle in den Praxisbeispielen würde ich dann eine sehr straffe Fassung belassen (quasi eine Kurzanleitung für Leute, die mit templates schon gearbeitet haben bzw. eine Idee davon haben, wie MQTT tickt), die dann auf den Detailartikel verlinkt, der dann der Schritt-für-Schritt-Einführung von Neulingen dient und weiter hinten (oder einem 2. Teil) dann auch die Details für die bereithält, die in die Steuerungsdetails einsteigen wollen und das mit MQTT2 umsetzen.

Ich hoffe, das ist halbwegs verständlich erklärt...
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

Beta-User

Zitat von: rudolfkoenig am 10 März 2019, 12:47:14
Bisher konnte filter nur auf die Gleichheit mit einem Internal pruefen, wir verwenden aktuell auch nur TYPE=XXX. Ich habe filter umgebaut auf devspec Syntax (siehe https://fhem.de/commandref_modular.html#devspec), damit duerfte man auf so ziemlich alles pruefen, auf Kosten der Performance. Ich hoffe das Problem durch Caching zu minimieren, allerdings muss man nach (relevanter) Attributaenderung FHEM neu starten oder {AttrTemplate_Initialize()} ausfuehren.
Ich hatte gestern die MQTT2-templates entsprechend ergänzt (eigentlich hatte ich vorher geglaubt, auch erfolglose Versuche mit der CID (=Internal) gemacht zu haben).

Heute gab es jetzt die erste Beschwerde wg. Performance-Einbußen:
https://forum.fhem.de/index.php/topic,98465.0.html

Für mein Anliegen würde vermutlich für die meisten Fälle die Filterung mit CID genügen, da müßte ich wohl nur mit den shellies und tasmotas was anders machen, aber das sind auch sehr verbreitete Geräte.
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

Beta-User

Zitat von: Beta-User am 11 März 2019, 20:23:50
[...]
Ich hoffe, das ist halbwegs verständlich erklärt...
Scheint so :) .

Hoffentlich finde nicht nur ich  das Ergebnis ganz gelungen...

Eigentlich war ich da grade nur im Wiki, weil ich mir die ReadingsGroup-Dinge nochmal ansehen wollte und kurz zeigen, was ich zwischenzeitlich für meine MySensors-Node als devStateIcon ausgedacht habe:

{my $alivecolor = 'lan_rs485@red';$alivecolor='lan_rs485@green' if (ReadingsVal($name, "state", "dead") eq "alive"); my $pumpcom = ReadingsVal($name, "status1", "on") eq "on" ? "off":"on"; my $relaystate = 'sani_pump'; $relaystate = 'sani_pump@red' if ($pumpcom eq "off"); "<div style=\"text-align:right\" >" . FW_makeImage("$alivecolor","lan_rs485") . " <a href=\"/fhem?cmd.dummy=set $name status1 $pumpcom&XHR=1\">". FW_makeImage("$relaystate","off") . "</a> " .  FW_makeImage("sani_boiler_temp","sani_boiler_temp") . " " . ReadingsVal($name,"temperature20","0") . "°C<br>" . FW_makeImage("sani_supply_temp","sani_supply_temp") . " " . ReadingsVal($name, "temperature21", "discon") ."°C " . FW_makeImage("sani_water_hot","sani_water_hot") . " " . ReadingsVal($name, "temperature22", "discon")  . "°C</div>"}

Das zeigt (farbig) an, ob die Node regelmäßig sendet (rot, wenn nicht), ob die Umwälzpumpe für das Warmwasser an ist (rot/normal; sie kann auch darüber geschaltet werden) und mal exemplarisch drei von den erfaßten Temperaturen (am Ausgang des Kessels, Vorlauf Warmwasser und Rücklauf (an der Pumpe, die die Node (nicht das devStateIcon ::) ) auch wieder ausschaltet, wenn der Rücklauf auch warm ist).

Bei Gefallen können wir gerne schauen, ob und wie sich das für eBus-MQTT2-Zwecke erweitern und umbasteln läßt...
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

Reinhart

Ja, ich habe gestern etwas nach deinen Vorschlägen um- und aufgeräumt muss aber in den nächsten Tagen noch Feintuning machen.
Das mit deinem devStateIcon schaue ich mir beim eBus noch an.

LG
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

TomLee

Zitat von: Reinhart am 13 März 2019, 12:47:45
Das mit deinem devStateIcon schaue ich mir beim eBus noch an.

LG

Hallo Reinhart,

wenn du dich bezüglich Beta-Users Beispiel mit devStateIcon beschäftigt kommt man um die Status0x_x_name und- value Readings ja nicht rum.
Genau hier würde sich jetzt mal anbieten, wie Beta-User auch schon mal zur Optimierung angemerkt hat, jsonMAP mal mit in eines deiner Beispiele  aufzunehmen.
Bin der Meinung die Status0x_x_name Werte kann man sich sparen, darum hatte ich sie in meinen geposteten Beispielen immer ausgeblendet und für die Status0x_x_value könnte ich mir vorstellen das man hier geläufige, einheitliche Namen in einem Template schon mal festhält/vorgibt, darauf war ich damals mit dieser Frage aus.

Gruß

Thomas

Beta-User

Zitat von: TomLee am 13 März 2019, 15:26:46
Genau hier würde sich jetzt mal anbieten, [...] jsonMAP mal mit in eines deiner Beispiele  aufzunehmen.
Ich wäre euch sehr verbunden, wenn das klappen würde; gerne nehme ich auch ein "bai"-Device (mit 2 Status-Geräten) in die allgemeinen templates auf, dann findet das auch jemand, der eigentlich mit ebus ggf. nicht viel am Hut hat, aber ein ähnliches Problem ;) ; ich würde das dann sogar nicht mal "wegfiltern" wollen, sondern im Hinweistext auf die Beispielfunktion zu JSONMAP hinweisen :) . In devStateIcon würde ich allerdings dann nur den ersten Status aufnehmen, verbunden mit dem Hinweis, dass es ggf. Sinn macht, die Geräte (händisch oder via template) zu trennen, das ist sonst in der optischen Darstellung unnötig aufgebläht und sollte eigentlich ohne größere Anstrengungen dann auch für weitere Devices übertragen werden können.

ZitatBin der Meinung die Status0x_x_name Werte kann man sich sparen, darum hatte ich sie in meinen geposteten Beispielen immer ausgeblendet und für die Status0x_x_value könnte ich mir vorstellen das man hier geläufige, einheitliche Namen in einem Template schon mal festhält/vorgibt, darauf war ich damals mit dieser Frage aus.
Nochmal der Hinweis: wenn es geläufige Bezeichnungen (z.B. aus Handbüchern) gibt, bietet es sich an, diese zu verwenden...



Was evtl. noch sinnvoll sein könnte, wäre das ebus-Dämon-Device (den splitter) auch mit einer netten Statusanzeige zu versehen; das sollte eigentlich für alle einheitlich sein (uptime usw.) bzw. ggf. auch einer offline-Meldung als "last-will", wenn der Dämon sowas unterstützt.



Da die templates sich jetzt filtern lassen, wäre es eigentlich keine große Sache, auch die ebus-templates via svn zu verteilen; als Filter würde ich die CID nehmen, die mit "ebus" beginnen muß (siehe zigbee-Beispiele). Allerdings wäre es mir recht, wenn die in einer separaten File enthalten wären, für die es einen anderen Verantwortlichen gibt (ich mache gerne eine Zeitlang den 2. Mann, aber eigentlich sind wir, was gewisse Standards angeht - jedenfalls nach meiner Wahrnehmung - auf einem Stand, der einigermaßen paßt).



Ohne damit je groß gearbeitet zu haben, würde ich vom Gefühl her dazu neigen, die myUtils für den ebus in contib zu verwalten; vielleicht kann Rudi oder sonst wer, der da mehr Erfahrung damit hat, einen Rat dazu geben, ob das sinnvoll ist oder eher nicht?



@TomLee:
Wenn der devStateIcon-Code sehr komplex ist oder sich häufig wiederholt, könnte es auch eine Idee sein, das in die myUtils (@contrib) mit reinzunehmen. Als myUtils lief das am Anfang auch mit den zigbee-(und MiLight)-bulbs; auf die Spitze getrieben könnte der devStateIcon-Code sogar feststellen, welcher "Typ" Device es ist und dann das passend zusammenstellen. Auf den Beispielcode für die Homematic-Thermostate hatte ich ja schon mal verlinkt, der "tickt" unterschiedlich, je nachdem, ob es ein Heizkörperthermostat oder ein Wandthermostat ist. Könnte mir gut vorstellen, dass das hier auch ähnlich ist (v.a., wenn die Status-Geräte getrennt werden und sich dann nur im Präfix oder gar nicht mehr in den Readings unterscheiden).

Grundgedanke für den Codeablauf:
Bau ein icon und eine Werteangabe nur dazu, wenn überhaupt das entsprechende Reading vorhanden ist, ansonsten lass es weg...

Bitte melden, wenn meine Anmerkungen zu kurzgefaßt sein sollten oder ich irgendwas sonst konstruktiv beitragen kann.
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

Reinhart

das mit den Statusmeldungen ist so eine fiese Sache, ich möchte das daher jetzt einmal näher erklären warum ich da keine Übersetzung mit JSONMAP machen möchte.

Die Statusmeldungen haben den großen Vorteil alle paar Sekunden über den Bus zu kommen, weil ja auch intern am Bus damit gearbeitet wird. Das erspart dem Anwender die Abfrage mit get". Der Nachteil ist, das hier keine Nachkommastellen (außer der Außentemp) ausgegeben werden.

Hier zur Veranschaulichung eine direkte Busabfrage.
pi@raspberrypi:~ $ ebusctl r -f status01
54.0;46.0;2.250;39.0;43.0;on

pi@raspberrypi:~ $ ebusctl r -f flowtemp
54.44;ok

pi@raspberrypi:~ $ ebusctl r -f returntemp
46.19;64796;ok


Die Zuordnung der einzelnen Werte im Status steht im hcmode.inc File.
r,,Status01,Vorlauftemperatur/Rücklauftemperatur/Aussentemperatur/WW Temperatur/Speichertemperatur/Pumpenstatus,,,,01,,,temp1;temp1;temp2;temp1;temp1;pumpstate,,,


Der Originaltext aus der Datenbank heißt beim Vorlauf "FlowTemp" und befindet sich im Register d.40 und findet man im entsprechenden CSV File.
Wenn wir nun hergehen und den Wert Status01_0_value mit einem Jsonmapping durch "Flowtemp" ersetzen, besteht einerseits wieder die Gefahr das wir uns den echten "Flowtemp" eventuell überschreiben, bzw. weiß kein Mensch mehr um was für einen Wert es sich handelt. Genau das möchte ich mit solchen Umbenennungen vermeiden, ist auch egal weil durch die Templates wird das ja automatisch geregelt und richtig dargestellt. Da kann dann stehen was jeder User haben will. Der Ersteller der Templates sollte sich Gedanken über die korrekte Zuordnung machen, nicht der Anwender.

Ich hoffe ich habe meine Bedenken euch nun näher gebracht.

Zum Thema devStateIcon sollten wir doch jedem Anwender selber entscheiden lassen, das ist im Prinzip das selbe Thema wie "notify" und "doif". Einfach ein paar Beispiele mit devStateIcon dazu machen und gut ist es, der User soll dann entscheiden mit was er besser zurecht kommt. Es gibt eben viele Wege die nach Rom führen.

Ich benutzte das devStateIcon bis jetzt zur Darstellung von verschieden farbigen Schaltflächen und das wars, deshalb tu ich mir da etwas schwerer um einen schönen dynamischen Output zu erhalten. Habe heute etwas experimentiert was aber bei mir nicht unbedingt von schnellem Erfolg gekrönt ist.

Was mich bei den readingsGroups etwas stört, ist die Tatsache das man meist in der 99_myUtils mit etwas Code nachhelfen muss. Aber das ist eh bei dem devStateIcon auch so.

LG

FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

Reinhart

betreffend dem devStateIcon, ich habe hier ein weiteres Anwendungsbeispiel mit readingsGroup erstellt. Es geht dabei um den internen Pumpenstatus und den Ventilator zur Brenngasmischung.

Mit readingsGroup geht das relativ einfach, mich würde jetzt interessieren wie man sowas mit dem devStatIcon hinbekommt. Braucht man mehr Code oder weniger? Ziel ist es, je nach Leistung oder Drehzahl das Icon und die Farbe zu ändern (auch unbekannte Zwischenstufen), den Wert in Klammer dazuschreiben und die Texte mit Überschrift zu formatieren. Und das Ganze sollte per Template verteilt werden können.

define eBusPumpe readingsGroup <>,<Vaillant>,<&nbsp;;Leistung>\
MQTT2_ebusd_bai:<%measure_power>,<Heizungspumpe>,WPPWMPower_percent0_value\
MQTT2_ebusd_bai:<%vent_ventilation_level_automatic>,<Ventilatordrehzahl>,FanSpeed_0_value
attr eBusPumpe cellStyle { "r:1"=>'style="font-weight:bold;;;;font-size:16px"'}
attr eBusPumpe nameStyle style="color:yellow"
attr eBusPumpe room eBus
attr eBusPumpe valueIcon { if($READING eq "WPPWMPower_percent0_value" &&  $VALUE >= 0 &&  $VALUE <= 60){ 'sani_pump@lightgreen' }\
elsif($READING eq "WPPWMPower_percent0_value" && $VALUE >= 61 && $VALUE <= 449){ 'sani_pump@green' }\
elsif($READING eq "WPPWMPower_percent0_value" && $VALUE >= 500 && $VALUE <= 4449){ 'sani_pump@orange' }\
elsif( $READING eq "FanSpeed_0_value" && $VALUE >= 0 && $VALUE <= 10){ 'vent_ventilation_level_0@grey' }\
elsif( $READING eq "FanSpeed_0_value" && $VALUE >= 11 && $VALUE <= 500){ 'vent_ventilation_level_0@lightgreen' }\
elsif( $READING eq "FanSpeed_0_value" && $VALUE >= 501 && $VALUE <= 1699){ 'vent_ventilation_level_1@green' }\
elsif( $READING eq "FanSpeed_0_value" && $VALUE >= 1700 && $VALUE <= 3000){ 'vent_ventilation_level_2@orange' }\
elsif( $READING eq "FanSpeed_0_value" && $VALUE >= 3001){ 'vent_ventilation_level_3@red' } \
else{  'file_unknown@grey' }}
attr eBusPumpe valueSuffix {"WPPWMPower_percent0_value"=>" &nbsp;;&nbsp;;&nbsp;;&nbsp;;(".ReadingsVal($DEVICE,$READING,0)."  Watt)",\
"FanSpeed_0_value"=>" &nbsp;;&nbsp;;&nbsp;;&nbsp;;(".ReadingsVal($DEVICE,$READING,0)."  Upm)" }


Bei der Pumpe habe ich es jetzt zum Test für die Bilder auf die Schnelle nicht geschafft, dass sie die Leistung in der Heizung spontan ändert, funktioniert aber. Beim Ventilator war es einfach, da habe ich nur die Heizkurve verstellt und schon bläst er mehr. Bei der Pumpe, muss sich auch die Vorlauftemperatur mit ändern, daher kommt die verzögert erst hoch.

LG
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa