Verständnisfrage zum Attribute jsonMap

Beta-User · 24 Juni 2021, 16:41:10

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:

Code Auswählen

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:

beaune · 08 Juli 2021, 10:40:37

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:

Code Auswählen

ebusd/f47/ccTimer.Monday:.* { json2nameValue($EVENT,'ccTimer.Monday_',$JSONMAP,'(?!ccTimer.*name)') }
Hat jemand ne Idee, was falsch sein könnte?

Beta-User · 08 Juli 2021, 10:59:24

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:

Code Auswählen

ebusd/f47/ccTimer.Monday:.* ccTimer_Monday

rudolfkoenig · 08 Juli 2021, 11:17:02

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.

Code Auswählen


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):

Code Auswählen

ebusd/f47/ccTimer.Monday:.* { my $v=json2nameValue($EVENT,'ccTimer.Monday_',$JSONMAP);; my %nv;; map { $nv{$_}=$v->{$_} if($_ !~ m/^ccTimer.*name$/) } keys %{$v};; \%nv }

Beta-User · 08 Juli 2021, 11:37:28

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...?

beaune · 08 Juli 2021, 11:38:57

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):
Code Auswählen Erweitern
ebusd/f47/ccTimer.Monday:.* { my $v=json2nameValue($EVENT,'ccTimer.Monday_',$JSONMAP);; my %nv;; map { $nv{$_}=$v->{$_} if($_ !~ m/^ccTimer.*name$/) } keys %{$v};; \%nv }

Beta-User · 08 Juli 2021, 11:56:24

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...)

beaune · 08 Juli 2021, 15:08:45

Hab auch das nochmal probiert...und auch die Positivliste geht. Ist in der Tat übersichtlicher. Wieder mal was gelernt. Vielen Dank Euch!

Code Auswählen

ebusd/f47/ccTimer.Monday:.* { json2nameValue($EVENT, 'ccTimer.Monday_', $JSONMAP, '_value') }

Beta-User · 08 Juli 2021, 15:17:44

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...)

beaune · 08 Juli 2021, 15:35:22

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.

Beta-User · 08 Juli 2021, 16:22:11

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).

beaune · 08 Juli 2021, 16:53:23

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:

Code Auswählen


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...

Beta-User · 08 Juli 2021, 17:39:42

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...)