Hallo,
ich war erfolglos mit dem Herum probieren von expandjson und auch meine Suche hier hat keine entsprechende Hilfe hervorgebracht.
Ich erhalte via MQTT: folgendes JSON in einem Reading des MQTT-DEVICES:
[{"A":"01:23:45:67:89:10","R":"-76","N":""},{"A":"10:98:76:54:32:10","R":"-64","N":""}]
Hier werden alle Bluetoothgeräte aufgelistet samt Name und RSSI-Wert
Die Länge der Liste kann natürlich abhängig von der Anzahl der Geräte varieren.
Kann fhem mit irgendeinem Modul mit so einem JSON Array umgehen?
Oder muss ich in dem Reading jedesmal nach der entsprechenden MAC-Adresse über ein DOIF oder notify suchen?
Gruß fr00sch
Mir sind mehrere Moeglichkeiten bekannt:
- MQTT2_DEVICE statt MQTT_DEVICE zu verwenden (IODev muss auch umgestellt werden), da wird JSON automatisch umgewandelt
- es gibt ein expandJSON Modul
- man kann per userReadings die FHEM/perl Funktion json2reading aufrufen.
Danke für die schnelle Antwort.
Ich verwende ein MQTT2_DEVICE und die JSON-Daten werden nicht autmatisch umgewandelt. Da das aber anscheinend ein JSON Array ist, denn es hat "[]" statt "{}", könnte das ein Problem sein, weswegen die automatische Umwandlung nicht geschieht. Macht das Sinn?
Das expandJSON Modul habe ich nicht ans laufen bekommen, weil ich nicht aus der Beschreibung und aus den Beispielen hier im Forum schlau geworden bin:
Internals:
DEF MQTT2_ESP32_ble1:json:.\{.*}
FUUID yyyyyyyyyyyyyyyyyyyy
NAME ble1
NOTIFYDEV MQTT2_ESP32_ble1
NR 153838
NTFY_ORDER 50-ble1
STATE active
TYPE expandJSON
s_regexp MQTT2_ESP32_ble1:json:.\{.*}
t_regexp .*
version 1.13
Helper:
DBLOG:
state:
logdb_remote:
TIME 1582713470.71557
VALUE active
READINGS:
2020-02-27 21:01:11 state active
helper:
addReadingsPrefix 1
Attributes:
DbLogExclude .*
addReadingsPrefix 1
room MQTT2_DEVICE
mein MQTT2-DEVICE sieht wie folgt aus
Internals:
CID ESP32_ble1
DEF ESP32_ble1
DEVICETOPIC MQTT2_ESP32_ble1
FUUID xxxxxxxxxxxxxxxxxxx
IODev MQTT2_FHEM_Server
LASTInputDev MQTT2_FHEM_Server
MQTT2_FHEM_Server_MSGCNT 1431
MQTT2_FHEM_Server_TIME 2020-02-27 21:01:38
MSGCNT 1431
NAME MQTT2_ESP32_ble1
NR 117660
STATE ???
TYPE MQTT2_DEVICE
JSONMAP:
MQTT2_ESP32_ble1 json
OLDREADINGS:
READINGS:
2020-02-27 21:01:17 ip 192.168.999.999
2020-02-27 21:01:38 json [{"A":"01:23:45:67:89:10","R":"-76","N":""},{"A":"10:98:76:54:32:10","R":"-64","N":""}]
2020-02-27 21:01:33 number 2
2020-02-27 21:01:17 status 1
Attributes:
DbLogExclude .*
IODev MQTT2_FHEM_Server
event-on-change-reading .*
jsonMap MQTT2_ESP32_ble1:json
readingList ESP32_ble1:ble1/status:.* status
ESP32_ble1:ble1/ip:.* ip
ESP32_ble1:ble1/json:.* json
ESP32_ble1:ble1/number:.* number
room MQTT2_DEVICE
Die Möglichkeit mit json2reading habe ich noch nicht getestet, aber was ich gesehen habe scheint mir auch nicht für JSON-Arrays mit [] geeignet zu sein:
https://forum.fhem.de/index.php/topic,55005.msg931672.html#msg931672
Was genau ist das Ziel, bzw wie soll das Ergebnis aussehen?
Ich habe json2nameValue umgebaut, damit auch sowas (array auf toplevel) akzeptiert wird:
fhem> { my $r=json2nameValue('[{"A":"01:23:45:67:89:10","R":"-76","N":""},{"A":"10:98:76:54:32:10","R":"-64","N":""}]');; join("\n", map { "$_=>$r->{$_}" } sort keys %{$r}) }
1_A=>01:23:45:67:89:10
1_N=>
1_R=>-76
2_A=>10:98:76:54:32:10
2_N=>
2_R=>-64
Ich hoffe, dass es keine Nebeneffekte hat, wenn doch, bitte melden.
Seiteneffekte? Damit kann ich dienen :-D
seit dem Update ging mein MQTT2 / EBUS / Vaillant Setup nicht mehr.
Leider verstehe ich die Zusammenhänge nicht genau. Folgendes kommt zum verarbeiten rein:
ebusd/bai/ModulationTempDesired:.* { json2nameValue($EVENT, 'ModulationTempDesired_', $JSONMAP) }
Aber das neue regex (autocreate complex) legt bei mir zum Beispiel folgende neuen Readings an:
MQTT2_ebusd_bai.TempDesired_0_ModulationTempDesired_value
tatsächlich sind alle readings im Eimer.
ich erwarte eigentlich (und die bestehenden readings werden nicht weiter befüllt...):
MQTT2_ebusd_bai.ModulationTempDesired_0_value
BridgeRegex im MQTT2_Device ist (wie im Wiki empfohlen):
(ebus.)[^/]*/(bai|broadcast)/.*:.* "$1_bai"
(ebus.)[^/]*/([\d]+)/.*:.* "$1_$2"
(ebus.)[^/]*[/][^b][a-zA-Z]+[/].*:.* "$1"
Nachdem ich die Änderung manuell zurückgesetzt habe geht wieder alles.
Brauchst du noch weitere Informationen um das nachzuvollziehen?
Ja, das JSON, was die "kaputten" Readings erzeugt.
Bitte mit dem aktuellen fhem.pl pruefen, gestern habe ich noch was gefixt: https://forum.fhem.de/index.php/topic,108828.msg1028044.html#msg1028044
Das heutige update hat den fehler nicht korrigiert.
Mqtt2 wurde heute auch nicht geupdatet - wenn ich mich richtig erinnere.
Wie komme ich denn am einfachsten an die json Daten ran?
Ich kann dir folgenden mitschnitt einer app abbieten:
ZitatMqtt2 wurde heute auch nicht geupdatet - wenn ich mich richtig erinnere.
Die Aenderung war in fhem.pl => Neustart ist erforderlich.
Kannst du bitte die Ausgabe von version anhaengen?
ZitatWie komme ich denn am einfachsten an die json Daten ran?
attr <mqtt_iodev> verbose 5
Mit den Informationen, den ich habe, generiert die aktuelle Version mAn richtige Namen:
fhem> { my $r=json2nameValue('{ "0":{"name":"","value":36.5}}','ModulationTempDesired_');; join("\n", map { "$_=>$r->{$_}" } sort keys %{$r}) }
ModulationTempDesired_0_name=>
ModulationTempDesired_0_value=>36.5
Kannst du bitte eine raw Definition der MQTT2_DEVICE Instanz zeigen?
Ok. Das war dann der entscheidende Hinweis...
Nicht meine Änderung hat alles wieder gangbar gemacht, sondern der Neustart.
Update hatte ich heute vormittag bereits durchgeführt. Aber keinen Neustart.
Dann habe ich versucht die Ursache für mein kaputtes setup zu finden.
Nachdem ich 10_MQTT2_DEVICE geändert habe, habe ich fhem neu gestartet und damit deinen Patch aktiviert.
Danke für die Hilfe! Jetzt geht wieder alles!
ZitatUpdate hatte ich heute vormittag bereits durchgeführt. Aber keinen Neustart.
Nur aus Interesse, um zu verstehen wie Benutzer "ticken", und worauf ich achten soll: hast du nach dem update ein reload gemacht?
Nein, ich hab ja nur schnell mit dem handy geschaut ob mqtt2 korrigiert wurde.
Kann ja keiner ahnen, dass die Korrektur in der fhem.pl liegt. ;D
Aber auch sonst war ich mir bis gerade nicht bewusst, dass ein reload bzw. shutdown restart immer notwendig ist :-[
Vermutlich uebersieht man zu einfach die vorletzte Zeile beim update:
Zitatupdate finished, "shutdown restart" is needed to activate the changes.
beim update über pgm2 öffnet sich ja automatisch der eventmonitor.
wie wäre es, diese zeile dort rot zu färben?
Ein blinkendes ? (neben save config), als Zeichen für Handlungsbedarf, hätte ich als Vorschlag.
also ehrlich. Steht doch da: "update finished, "shutdown restart" is needed to activate the changes.". Lesen und verstehen kann ein system dem Benutzer nicht abnehmen
Es gibt ein Interessenskonflikt:
- Benutzer, die lange mit dem System arbeiten, und keine Fehler (mehr) machen, moegen es, wenn das System nicht nervt. Ich bin zunehmend von (anderen) Systemen genervt, die meinen mir die Verantwortung abnehmen zu muessen, und mich deswegen gaengeln. Ein Popup nach update empfinde ich als Gaengelung.
- Neulinge wissen noch nicht, worauf sie achten sollen, es gibt zu viel Info, was man nicht einordnen kann. Da hilft es, wenn bestimmte Sachen hervorgehoben werden.
Beiden recht zu machen heisst, alles mit Option zum Abschalten implementieren => Code/Doku wird zunehmend unleserlich.
D.h. einer der drei Gruppen (Ehrfahrene, Neulinge oder Maintainer) verliert.
ZitatD.h. einer der drei Gruppen (Ehrfahrene, Neulinge oder Maintainer) verliert.
wenn eine gruppe verliert, muss ja mindestens auch eine andere gruppe gewinnen. jetzt könnte man die grösse der beiden gruppen heranziehen, um einen saldo zu erzielen.
ein gewinn in summe müsste doch alle 3 gruppen erfreuen.
- popups, die man immer bestätigen muss, empfinde ich auch als gängelung. da lese ich die info ziemlich bald auch nicht mehr.
- die popups wie beim löschen von attributen mit option zum abschalten wären allerdings noch ok.
- ein einfärben von "wichtigen" messages würde den eventmonitor auch etwas "aufpeppen", oder wäre das auch schon eine gängelung?
besonders bei einer grossen anzahl "durchrauschender" events können wichtige farbige logmeldungen auch weniger übersehen werden.
Bei der nach wie vor geringen Zahl der Fälle, in denen das usern nicht klar zu sein scheint, wäre meine Meinung: Bitte lassen, wie es ist...
(Wer noch eine kleine Installation hat, sollte die Hinweise auf den restart unter den noch wenigen Meldungen wahrnehmen können, die kommen, nachdem man ein update anschubst).
Ehrlicherweise bin ich nicht grundsätzlich dagegen, ich habe nur Angst das jetzt in einem Schnellschuss irgendwo drei Zeilen Code dran gebastelt werden die dann zwar irgendwie und -wo was anzeigen ohne das Benutzerfreundlichkeit oder Nachhaltigkeit da eine Rolle spielen.
Ich würde mich anbieten _bei Gelegenheit(!)_ ein Modul dafür zu entwickeln. So in der Art wie die Notifikation Bereiche bei mobiles würde mir da vorschweben. Mit der Idee dass erfahrene Benutzer das deaktivieren/deinstallieren können und so das man die einzelnen Mitteilungen selektiv deaktivieren und anpassen kann. So ein modul könnte dann auch die motd Mitteilungen aufnehmen und sollte auch offen für Mitteilungen anderer Module sein.
Wäre so etwas konsensfähig?
Ich haette damit kein Problem.
Wir haben auch noch das notice Modul, aber das ist ungefaehr das Gegenteil davon, was ich mir wuensche.
ZitatIch würde mich anbieten _bei Gelegenheit(!)_ ein Modul dafür zu entwickeln. So in der Art wie die Notifikation Bereiche bei mobiles würde mir da vorschweben.
hört sich vielversprechend an. :)
"cannot fork"-notifications fände ich dann zb auch ganz nützlich.
Auch mein Einwand war nicht so zu verstehen, dass ich prinzipielle Einwände hätte, wenn jemand da was ändert - ich will nur möglichst als user nicht mit Dingen behelligt werden, die eigentlich "klar" sind, wenn man die Mechanismen verstanden hat. Werde mich daher darauf konzentrieren, diese Mechanismen bei Gelegenheit für "noobs" besser verständlich zu machen...
[etwas OT]
Ich habe jüngst in RandomTimer eine Änderung vorbereitet, die ab featurelevel 6.1 dann teils zu einem etwas anderen Verhalten führen kann (und dafür aber z.B. den Umgang mit Gruppen-HUEDevices vereinfacht). Nachdem das jetzt einige Zeit bei mir stressfrei gelaufen zu sein scheint, würde ich das einchecken, aber eben nach Möglichkeit so, dass alle (potentiell betroffenen) User das möglichst einfach mitbekommen, und zwar spätestens aber deutlich bei einem Update, das featurelevel 6.1 zum default macht. Denn dann führt das ggf. (erst) zu Irritationen. Dann sind die Änderungen aber voraussichtlich bereits viele Monate her, und ich habe dann evtl. schon vergessen, dass da was war...
Frage daher: Wo ist der richtige Ort, um "sowas" publik zu machen bzw. für eine Art "changelog zu 6.1" vorzuhalten?
[/OT]
ZitatFrage daher: Wo ist der richtige Ort, um "sowas" publik zu machen bzw. für eine Art "changelog zu 6.1" vorzuhalten?
Es gibt eine UPGRADE Datei im Root-Verzeichnis
Zitat von: rudolfkoenig am 03 März 2020, 13:10:22
Es gibt eine UPGRADE Datei im Root-Verzeichnis
Thx, da hätte ich auch selber draufkommen können... ::)
Zwei Anmerkungen dazu noch:
- Vermutung: Kaum ein User wird da reinsehen, da ist auch kaum Bewegung drin, was aber damit zu tun haben dürfte, dass
- grep nach featurelevel nicht eben viele Ergebnisse liefert. Genauer gesagt war ich tendenziell (in Vorbereitung auf das RandomTimer-Thema) überrascht, wie wenige Developer anscheinend von der Möglichkeit Gebrauch machen, Änderungen erst über dieses feature zunächst testweise einzubringen bzw. für die, die bestimmte features vorab haben wollen. Gerade für potentielle "breaking changes" erscheint mir das aber eine geeignete Vorgehensweise zu sein, oder übersehe ich (mal wieder) was wesentliches? Oder wird die Unterscheidung dann besser wieder ausgebaut, wenn der relevante Update bereits länger durch ist? (Ist ja auch wieder fehleranfällig und verhindert dann ein "downgrade durch software" mit aktiv gesetztem niedrigerem featurelevel).
Vermutlich planen die meisten Entwickler so gruendlich, dass sie nie breaking changes benoetigen.
Oder sie pfeifen einfach auf Kompatibilitaet :)
So, ich habe die letzten 2 Tage die Updates installiert um zu gucken, was ich da verpasse (und warum ich das nicht gelesen habe).
Zum Hintergrund:
Ich nutze FHEM meistens auf dem Smartphone (iPhone) und habe mir daher eine übersichtliche Startseite gebastelt (f18 Style).
die Befehle "update check" und "update" habe ich als Weblinks auf dieser Seite.
bis hier im Eventmonitor etwas passiert (nach ca. 2 Sekunden), hab ich schon ein neues Tab aufgemacht oder den Browser schon wieder geschlossen.
Als Nutzer sagen mir die meisten Meldungen doch eh nix...
Wobei ich auch das Gefühl habe dass hier bei einem Update auch mal keine Eventmeldungen angezeigt werden. Aber das kann ich nicht reproduzieren.
Insofern hätte auch ein Hinweis in rot und blinkend bei mir nichts gebracht...
Mal eine Ketzerische Frage eines ahnungslosen:
Wenn ein Neustart sowieso notwendig ist - wieso macht es FHEM dann nicht automatisch?
Und jetzt steinigt mich bitte nicht...
"Automatisch" shutdown+restart hieße: eventuelle zwischenzeitliche config-Änderungen sind weg...
Weitergedacht: Automatisches "save" vorneweg? MMn. ein "Unding". (Da können auch mal Devices bei "hops gehen", weil irgendwas aus irgendeinem kühnen Grunde nicht ging, z.B. weil ein Modul "kaputt" war, und man das update genau deswegen durchführt...).
Tipp: Updates NIE von "weit weg" machen; meistens ist es kein Problem, aber man sollte nach einem Update immer prüfen bzw. prüfen können (!) ob es ein Problem gibt => ins log schauen => geht nicht "nebenbei".
Just my2ct.
Zitat von: rudolfkoenig am 03 März 2020, 14:04:20Vermutlich planen die meisten Entwickler so gruendlich, dass sie nie breaking changes benoetigen.
YMMD ;D
(Ich sollte wohl den Developer-Status "zurückgeben", weil ich jedenfalls nicht sooooo weitsichtig in der Planung bin...
...bzw. was Randomtimer angeht: nicht verstehe, was Dietmar sich in grauer Vorzeit dazu an Gedanken gemacht hatte oder welchen Vorteil es bot, Value() abzufragen und den user auf stateFormat am abgefragten Device zu verweisen statt ReadingsVal+state zu nehmen... Vermutlich konnte "man" das damals einfach noch nicht wissen, oder man hätte rechtzeitig den fhem.pl-Entwickler fragen sollen, wie es "richtig" und zukunftsweisend ist...
Wie dem auch sei: es ist, wie es ist ;D .)
Zitat von: Beta-User am 03 März 2020, 14:35:33
hieße: eventuelle zwischenzeitliche config-Änderungen sind weg...
Stimmt, das ist ein Argument.
Zitat von: Beta-User am 03 März 2020, 14:35:33
Tipp: Updates NIE von "weit weg" machen; meistens ist es kein Problem, aber man sollte nach einem Update immer prüfen bzw. prüfen können (!) ob es ein Problem gibt => ins log schauen => geht nicht "nebenbei".
das ist für mich kein Problem: Ich kann ja immer noch per ssh (via VPN, kein Portforwarding) auf den Raspi zugreifen.
Die Logs lese ich (auch bei funktionierendem FHEM) lieber in einer anderen APP auf dem Smartphone (App "Documents", greift per SFTP auf den Raspi zu).
Wenn ich mein FHEM abschieße ist es für mich auch kein Drama. Es hängen keine lebenswichtigen Systeme daran :-D - Ich nutze das System ausschließlich zum Daten erheben - nicht zum steuern.
Und das wichtigste: Ich habe in der S-Bahn Zeit (und Nerven) dafür. Zuhause nicht.
Zitat von: HeikoGr am 03 März 2020, 14:46:51
Es hängen keine lebenswichtigen Systeme daran :-D - Ich nutze das System ausschließlich zum Daten erheben - nicht zum steuern.
...wollen wir wetten, das sich das irgendwann ändert...?
ZitatUnd das wichtigste: Ich habe in der S-Bahn Zeit (und Nerven) dafür. Zuhause nicht.
Das ist völlig ok, du "kannst" also "prüfen", mehr hatte ich ja gar nicht als "erforderlich" genannt... Spätestens, wenn du auch was (vielleicht*) wichtiges steuerst, solltest du hin und wieder das log checken. (*vielleicht will sagen: manchmal findet man selbst Dinge nicht so wichtig, die andere als sehr wichtig ansehen, weil sie die Möglichkeiten anders nutzen - wird insbesondere dann lustig, wenn der Nachwuchs etwas größer ist und einen auch zuhause meistens in Ruhe läßt...)
Hat etwas länger gedauert, bis ich es testen konnte. :(
Danke schön für die Anpassung. Es geschieht jetzt genau das was mein Ziel war. ;D
Zitat von: rudolfkoenig am 27 Februar 2020, 23:07:33
Ich habe json2nameValue umgebaut, damit auch sowas (array auf toplevel) akzeptiert wird:
fhem> { my $r=json2nameValue('[{"A":"01:23:45:67:89:10","R":"-76","N":""},{"A":"10:98:76:54:32:10","R":"-64","N":""}]');; join("\n", map { "$_=>$r->{$_}" } sort keys %{$r}) }
1_A=>01:23:45:67:89:10
1_N=>
1_R=>-76
2_A=>10:98:76:54:32:10
2_N=>
2_R=>-64
Ich hoffe, dass es keine Nebeneffekte hat, wenn doch, bitte melden.