Hallo,
hab ich so verstanden das Readingname Status01_0_value durch IST-Vorlauf ersetzt wird.
Überlese oder sehe ich den Fehler einfach nicht ?
defmod MQTT2_Test_Ebusd MQTT2_DEVICE
attr MQTT2_Test_Ebusd IODev MQTT2_CLIENT
attr MQTT2_Test_Ebusd jsonMap Status01_0_value:IST-Vorlauf\
attr MQTT2_Test_Ebusd model E_01_eBus_Test
attr MQTT2_Test_Ebusd readingList ebusd/bai/Status01:.* { json2nameValue($EVENT, 'Status01_', $JSONMAP) }
setstate MQTT2_Test_Ebusd 2019-02-17 00:58:42 Status01_0_name temp1
setstate MQTT2_Test_Ebusd 2019-02-17 00:58:42 Status01_0_value 64.0
setstate MQTT2_Test_Ebusd 2019-02-17 00:58:42 Status01_1_name temp1
setstate MQTT2_Test_Ebusd 2019-02-17 00:58:42 Status01_2_name temp2
setstate MQTT2_Test_Ebusd 2019-02-17 00:58:42 Status01_2_value 6.000
setstate MQTT2_Test_Ebusd 2019-02-17 00:58:42 Status01_3_name temp1
setstate MQTT2_Test_Ebusd 2019-02-17 00:58:42 Status01_3_value 0.0
setstate MQTT2_Test_Ebusd 2019-02-17 00:58:42 Status01_4_name temp1
setstate MQTT2_Test_Ebusd 2019-02-17 00:58:42 Status01_4_value 52.0
setstate MQTT2_Test_Ebusd 2019-02-17 00:58:42 Status01_5_name pumpstate
setstate MQTT2_Test_Ebusd 2019-02-17 00:58:42 Status01_5_value off
Gruß
Thomas
Hallo,
ich könnte mir vorstellen, dass der abschließende \ beim jsonMap-Attribut hier zu Fehlinterpretationen führt ...
Zitat von: OdfFhem am 17 Februar 2019, 07:46:19
Hallo,
ich könnte mir vorstellen, dass der abschließende \ beim jsonMap-Attribut hier zu Fehlinterpretationen führt ...
Daran lags nicht der wird mitgeschrieben wenns denn geht aber ja der gehört dort nicht hin, hatte durch copy and paste und nachträglichem editieren des Posts hier das falsche Reading mappen wollen, Status01_1_value, und das gibt es hier im Beispiel aber gar nicht, mit allen anderen gehts, Sry.
Das klingt so, als ob das Problem nicht mehr existiert.
Wenn doch, bitte genau beschreiben.
Mir kommt die nächste Frage auf.
Gibt es auch ein Attribute welches das anlegen von Readings verhindert ?
Die Status01_x_name Readings sind überflüssig nachdem jsonMap nun greift.
defmod MQTT2_Test_Ebusd MQTT2_DEVICE
attr MQTT2_Test_Ebusd IODev MQTT2_CLIENT
attr MQTT2_Test_Ebusd devStateStyle style="text-align:right"
attr MQTT2_Test_Ebusd event-on-change-reading .*
attr MQTT2_Test_Ebusd icon icoTempHeizung
attr MQTT2_Test_Ebusd jsonMap Status01_0_value:IST-Vorlauf
attr MQTT2_Test_Ebusd model E_01_eBus_Test
attr MQTT2_Test_Ebusd readingList ebusd/bai/Status01:.* { json2nameValue($EVENT, 'Status01_', $JSONMAP) }
setstate MQTT2_Test_Ebusd 2019-02-17 10:31:56 IST-Vorlauf 62.0
setstate MQTT2_Test_Ebusd 2019-02-17 10:31:56 Status01_0_name temp1
setstate MQTT2_Test_Ebusd 2019-02-17 10:31:56 Status01_1_name temp1
setstate MQTT2_Test_Ebusd 2019-02-17 10:31:56 Status01_2_name temp2
setstate MQTT2_Test_Ebusd 2019-02-17 10:31:56 Status01_2_value 6.438
setstate MQTT2_Test_Ebusd 2019-02-17 10:31:56 Status01_3_name temp1
setstate MQTT2_Test_Ebusd 2019-02-17 10:31:56 Status01_3_value 0.0
setstate MQTT2_Test_Ebusd 2019-02-17 10:31:56 Status01_4_name temp1
setstate MQTT2_Test_Ebusd 2019-02-17 10:31:56 Status01_4_value 53.0
setstate MQTT2_Test_Ebusd 2019-02-17 10:31:56 Status01_5_name pumpstate
setstate MQTT2_Test_Ebusd 2019-02-17 10:31:56 Status01_5_value off
Versuchs mal mit Status01_x_name:
Zitat von: rudolfkoenig am 17 Februar 2019, 10:45:42
Versuchs mal mit Status01_x_name:
Status01_0_name:
->
jsonMap: Odd number of elements
Zweiter Versuch: Status01_0_name:0
:) Danke
Wenn du mir jetzt noch verrätst wie das $JSONMAP hier (https://forum.fhem.de/index.php/topic,79600.msg906792.html#msg906792) wieder mitkommt oder zumindest erklärst weshalb es nicht mehr kommt, hätte ich für heute keine offenen Fragen mehr :P
Verstehe die Frage nicht.
Reinhart meinte bei seinen ersten Tests vor längerem wäre ein automatisch erstelltes MQTT2_Device noch mit zusätzlichem $JSONMAP erstellt worden und kann es heute nicht mehr nachstellen.
Beispiel:
attr MQTT2_Test_Ebusd readingList ebusd/bai/Status01:.* { json2nameValue($EVENT, 'Status01_', $JSONMAP) }
Heute wird es so automatisch erstellt:
attr MQTT2_Test_Ebusd readingList ebusd/bai/Status01:.* { json2nameValue($EVENT) }
Beta-User hat mich ueberredet bei autocreate den Prefix wegzulassen, weil es im Normalfall unnoetig lange Readingnamen generiert, was manche verwirrt. JSONMAP war "Kollateralschaden". Wenn jemand diese Parameter vermisst, muss readingList anpassen.
Na dann hab ich ja unwissend alles richtig gemacht denke ich, Danke Dir für die Aufklärung
Na ja, das "Überreden" bestand in einer vorsichtigen Frage...
Zu dem EBUS-Dingens: Da war eigentlich schon immer klar, dass da etwas mehr an Konfiguration sein sollte (und JSONMAP sehr hilfreich!). @TomLee: Es wäre m.E. super, wenn wir das irgendwie in's Wiki bekämen (unter die Praxisbeispiele zu MQTT2 oder separat).
Magst du das ggf. übernehmen?
(Ich mache das notfalls auch selbst in "Trockenübung", würde dann aber etwas mehr benötigen als die wenigen Bruckstücke hier...)
Ich hab eine Frage zu diesem Thema:
Zitat von: rudolfkoenig am 17 Februar 2019, 11:01:09
Zweiter Versuch: Status01_0_name:0
Man kann so einzelne Readings wegblenden, das geht. Aber ist es auch möglich, im JSONMAP mit regulären Ausdrücken zu arbeiten? Ich würde z.B. gerne alle Readings, die sich automatisch anlegen und auf _name enden, ausblenden, ohne alle separat aufführen zu müssen, also z.B. diese:
ccTimer.Monday_0_name
ccTimer.Monday_1_name
ccTimer.Monday_2_name
ccTimer.Monday_3_name
ccTimer.Monday_4_name
ccTimer.Monday_5_name
ccTimer.Monday_6_name
Habs mit
ccTimer.*=*name:0versucht, geht aber nicht. Mach ich was falsch oder gehts wirklich nicht?
Nach meinem evtl. begrenzten Verständnis geht das nicht bzw. nicht direkt:
jsonMap (3. Argument) vergleicht "key"-Namen in zwei Hashes (mit "eq") und reagiert (nur) dann, wenn es 1:1 paßt (mit 0 als value => nicht übernehmen, sonst value => neuer key-Name).
Indirekt könnte es gehen, wenn man das (bisher afaik nicht in der praktischen Anwendung angekommene) 4. Argument "filter" verwendet. Das ist zwar eigentlich als Positivliste konzipiert, aber technisch gesehen (soweit ich mich entsinne) eine regex, und da könnte man auch einen "aber nicht"-Ausdruck formulieren.
Ohne "Spielmaterial" zur besseren Einbettung der Antwort schwierig, aber versuch's mal mit:
json2nameValue($EVENT,'',$JSONMAP,'(?!ccTimer.*name)')Btw.:
Du hattest ein paar Fragen gestellt, allerdings mAn. am falschen Ort. Eventuell hilft es dir weiter bzw. magst du das aufgreifen...
Zitat von: Beta-User am 16 Juni 2021, 13:59:50
Nachdem an anderer Stelle Fragen aufgetaucht sind:
Danke für den Tipp! Hab es probiert, allerdings scheint der 4. Parameter nichts zu bewirken, oder der Ausdruck passt noch nicht. Es werden jedenfalls immer noch beide Readings (_name und _value) angelegt. Da stehe ich jetzt etwas auf dem Schlauch, denn ich finde auch kein Beispiel/Erläuterung, wie dieser Parameter zu verwendet ist. Ich habe es so in der ReadingList probiert:
ebusd/f47/ccTimer.Monday:.* { json2nameValue($EVENT,'ccTimer.Monday_',$JSONMAP,'(?!ccTimer.*name)') }
Hat jemand ne Idee, was falsch sein könnte?
Zitat von: beaune am 08 Juli 2021, 10:40:37
Hat jemand ne Idee, was falsch sein könnte?
Na ja, um helfen zu können, wäre weiter "Spielmaterial" hilfreich:
Zitat von: Beta-User am 24 Juni 2021, 16:41:10
Ohne "Spielmaterial" zur besseren Einbettung der Antwort schwierig
Du kannst das generieren, wenn du entweder den MQTT-Verkehr mitschneidest (mit mosquitto_sub, z.B.), oder einfach wenigstens das "rohe" JSON einfängst durch einen _zusätzlichen_ readingsList-Eintrag:
ebusd/f47/ccTimer.Monday:.* ccTimer_Monday
ZitatHat jemand ne Idee, was falsch sein könnte?
Ich tippe auf dem Regexp.
?! war mir schon immer suspekt, und wenn ich die Doku (https://perldoc.perl.org/perlre) richtig verstehe, ist in diesem Fall nicht anwendbar.
fhem> { "ccTimer01_name" =~ m/^(ccTimer.*name)$/ }
1
fhem> { "ccTimer01_name" =~ m/(?!ccTimer.*name)/ }
1
fhem> { "ccTimer01_name" =~ m/^(?!ccTimer.*name)$/ }
fhem> { "bla" =~ m/^(?!ccTimer.*name)$/ }
Was funktionieren koennte (ungetestet):
ebusd/f47/ccTimer.Monday:.* { my $v=json2nameValue($EVENT,'ccTimer.Monday_',$JSONMAP);; my %nv;; map { $nv{$_}=$v->{$_} if($_ !~ m/^ccTimer.*name$/) } keys %{$v};; \%nv }
:) Trotzdem wäre es vermutlich auch nicht verkehrt, mal ein Filter-Argument praktisch anzuwenden...
Wenn ich
Zitat von: beaune am 08 Juli 2021, 10:40:37
immer noch beide Readings (_name und _value)
richtig interpretiere, könnte man dann auch schlicht die "Positiv-Variante" verwenden und '_value' als 4. Argument übergeben...?
Ich bin begeistert! Hab das einfach mal ausprobiert, ohne den Ausdruck zu verstehen, und er tut was er soll. Vielen Dank dafür! Kannst Du vielleicht noch ein paar Erläuterungen dazu machen, wie es funktioniert?
Zitat von: rudolfkoenig am 08 Juli 2021, 11:17:02
Was funktionieren koennte (ungetestet):
ebusd/f47/ccTimer.Monday:.* { my $v=json2nameValue($EVENT,'ccTimer.Monday_',$JSONMAP);; my %nv;; map { $nv{$_}=$v->{$_} if($_ !~ m/^ccTimer.*name$/) } keys %{$v};; \%nv }
Erst wird die Rückgabe von j2nv() in eine Variable kopiert und dann über eine verdeckte Schleife (map) aussortiert und in einen neuen Hash kopiert, was bestimmten Kriterien (nicht) entspricht... Der neue Hash wird dann zurückgegeben und dann durch die "allgemeinen Routinen" in MQTT2_DEVICE in Readings umgewandelt.
(Sowas gibt es an einigen wenigen Stellen in mqtt2.template).
(Mich hätte trotzdem interessiert, wie die Messages aussehen und ob die positive Filterei nicht zum selben Ergebnis geführt hätte...)
Hab auch das nochmal probiert...und auch die Positivliste geht. Ist in der Tat übersichtlicher. Wieder mal was gelernt. Vielen Dank Euch!
ebusd/f47/ccTimer.Monday:.* { json2nameValue($EVENT, 'ccTimer.Monday_', $JSONMAP, '_value') }
Danke für die Rückmeldung.
Zitat von: Beta-User am 24 Juni 2021, 16:41:10
Btw.:
Du hattest ein paar Fragen gestellt, [...]
Das Angebot, die attrTemplate für ebus (v.a., soweit sie den MQTT-Teil betreffen) ggf. nochmal einem Review zu unterziehen steht ;) . (Kann auch bedueten, einfach eine Musterlösung für einen einzelnen User zu erstellen...)
Danke für das Angebot, vielleicht komme ich darauf nochmal zurück. Allerdings hab ich mich von den Templates inzwischen auch schon ein gutes Stück entfernt. Sie sind sicher ganz gut, um Dinge zu verstehen, so als Beispiel. Ich hatte da vielleicht zuviel erwartet; auf den ersten Blick wirkt das alles "fertig", da wurde offenbar schon sehr viel Aufwand und Mühe rein gesteckt, aber wenn man tiefer einsteigt merkt man schnell, dass es dann doch zu der jeweiligen Anlage nicht so ganz passt. Und die Optik ist vielleicht auch ein bisschen zu bunt geraten... Vielleicht wäre es wirklich schlauer, lieber einfache überschaubare Beispiele für einzelne eBUS-Readings zu machen, die sich leicht erweitern lassen. Und sicher helfen für komplexe Funktionen auch spezielle Templates, wie z.B. das für das Zeitprogramm eBus_Calormatic_TimeProgramm. Aber genau das führt z.B. zu Fehlern wegen der Verwendung des Minus-Zeichens in der Setlist. Und ich finde es auch unglücklich, dass man dort nur Halbstundenwerte auswählen kann; ist etwas anderes eingestellt, wird einfach nichts angezeigt. Man kann hier das Prinzip erkennen, aber die Lösung scheint mir unfertig zu sein. Liegt aber vielleicht einfach daran, dass ein geeignetes Eingabecontrol für Uhrzeit in fhem fehlt. Da komme ich sicher nochmal drauf zurück. Kann aber noch was dauern.
Zitat von: beaune am 08 Juli 2021, 15:35:22
Allerdings hab ich mich von den Templates inzwischen auch schon ein gutes Stück entfernt.
Das glaube ich gerne, und meine Vermutung ist auch, dass
ZitatSie sind sicher ganz gut, um Dinge zu verstehen,
- bezogen auf die ebus-attrTemplate - NICHT zutrifft.
Nach meinem Eindruck werden viele Optionen (für MQTT2_DEVICE), die zwischen "meinen" Erstlingen und heute liegen leider nicht (gut) genutzt, was ziemlich schade ist (ohne über Farbgebung geredet zu haben). Grade das mit dem Zeitprogramm müßte eigentlich mit dem Modul "weekprofile" super-elegant lösbar sein - und dann auch noch nahtlos zu dem passen, was man mit (vielen) Thermostaten (bzw. WeekdayTimer) machen kann...
Zitat
aber die Lösung scheint mir unfertig zu sein.
Danke für die Bestätigung meiner Vermutung...
Also falls du Interesse hast,
Zitateinfache überschaubare Beispiele für einzelne eBUS-Readings
zu entwickeln: feel free und mach' am besten einen entsprechenden neuen Thread (im MQTT-Bereich, da sehe ich es eher) auf. (Etwas mehr an Infos wäre dann aber wünschenswert, evtl. können wir auch mal per Videokonferenz deinen Server anzapfen, da kann ich ggf. schneller/einfacher erklären, wo m.E. die Ansatzpunkte wären, und evtl. hat ja auch sonst jemand Interesse, sich mal damit (unterstützt) zu beschäftigen).
Zitat von: Beta-User am 08 Juli 2021, 16:22:11
Nach meinem Eindruck werden viele Optionen (für MQTT2_DEVICE), die zwischen "meinen" Erstlingen und heute liegen leider nicht (gut) genutzt, was ziemlich schade ist
stimmt absolut! Bestes Beispiel ist das Modul weekprofile, dass ich bis eben noch gar nicht kannte. Im Template eBus_Calormatic_TimeProgramm wird sowas noch mit diversen Dummys in einer Readingsgroup zusammengebastelt. Das geht sicher viel eleganter mit weekprofile, ohne dass ich das im Detail schon durchschaue. Aber genau das wäre mal so ein Beispiel, das helfen könnte.
Ausgangslage: Das MQTT-Device für den Heizungsregler hat folgende Readings:
hcTimer.Monday_0_value 04:00
hcTimer.Monday_1_value 08:00
hcTimer.Monday_2_value 15:00
hcTimer.Monday_3_value 22:00
hcTimer.Monday_4_value 22:00
hcTimer.Monday_5_value 22:00
hcTimer.Monday_6_value selected
hcTimer.Friday_0_value 04:00
hcTimer.Friday_1_value 08:00
hcTimer.Friday_2_value 15:00
hcTimer.Friday_3_value -:-
hcTimer.Friday_4_value -:-
hcTimer.Friday_5_value -:-
hcTimer.Friday_6_value selected
Für die anderen Tage analog. Wie verwendet man jetzt die Module weekProfile und weekDayTimer optimalerweise, um diese vom Heizungsregler empfangenen Daten darzustellen und verändern zu können? Das wäre so ein Beispiel, was glaube ich sehr vielen helfen würde. Zumindest wenn sie eine Vaillant-Heizung haben ;)
Und die Antwort auf diese Frage ist wahrscheinlich wirklich in einem anderen Thread besser aufgehoben...
Zitat von: beaune am 08 Juli 2021, 16:53:23
Bestes Beispiel ist das Modul weekprofile, dass ich bis eben noch gar nicht kannte.
...kannte ich auch lange nicht, bis mal jemand gefragt hat, ob WDT (=WeekdayTimer) eigentlich auch so ein tolles Interface bekommen könnte. Da ich mich nicht in der Lage gesehen hatte, sowas zu programmieren, war die einfache Überlegung, die Daten aus weekprofile heraus abzugreifen und weekprofile praktisch zur Steuerung des WDT verwenden zu können...
Zitat
Im Template eBus_Calormatic_TimeProgramm wird sowas noch mit diversen Dummys in einer Readingsgroup zusammengebastelt.
Hatte ich neulich erst wahrgenommen und fand das ziemlich "unelegant" im Vergleich zu weekprofile+WDT. War - neben der "Kleinigkeit", dass manche ZigBee-Thermostate auch Wochenprogramme "können" - einer der Gründe, warum ich @Risiko angefragt hatte, direkten Support auch für MQTT2_DEVICE bereitzustellen, was er gerne gemacht hat - und noch toller: es gibt da jetzt die Möglichkeit, "Klartexte" zu hinterlegen bzw. übermittelt zu bekommen (ist auch Neuland für mich). (Ergo und zur Klarstellung: WDT brauchen wir hier gar nicht!)
ZitatAusgangslage: Das MQTT-Device für den Heizungsregler hat folgende Readings:
Wir sollten einen Schritt zurückgehen... MAn. ist die "Ausgangslage", dass ebusd via MQTT einen JSON-String sendet und empfängt, in dem bestimmte Werte (-paare) "vercodet" sind. Das überhaupt auseinanderzunehmen, ist nicht zwingend, und wird z.B. bei den zigbee2mqtt-Thermostaten auch nicht (vollständig) gemacht; weiter ist die Methode vermutlich universell und nicht auf Vaillant-Hardware begrenzt (oder es ist ggf. nicht schwierig, den "Zwischencode" so zu gestalten, dass man einfach die Variante angibt)...
Ergo: Bitte neuen Thread aufmachen und ggf. vorab mal den zigbee2mqtt-Thermostat-Thread suchen und lesen, dann wird vielleicht manches klarer...
Und bitte Info liefern, wie die Wertepaare zu verstehen sind; ich vermute: 04:00 Uhr an, 8:00 Uhr aus, dann wieder ab 15-22 Uhr an. "selected" bedeutet? (Die dummy-Lösung fügt das immer dazu, wenn ich das richtig interpretiere).
(Vermutlich ist der ebusd-Autor auch wieder sehr hilfsbereit, wenn wir ihn "richtig" (=qualifiziert) fragen...)