Modul-Diskussion/Hilfe: MQTT_GENERIC_BRIDGE

hexenmeister · 29 November 2018, 13:02:00

Wird natürlich gehen. Z.B. könnte man mit einem userReading eine neue Reading aus anderen Readings so befüllen, dass dort JSON-String sntsteht. Die Bridge wird ihn, falls erwünscht, brav transportieren. Oder man nimmt 'expression' (s. Commandref zu der GenricBridge) und modifiziert ein zu übertragendes Reading-Inhalt 'on the fly'.

HomeAlone · 06 Dezember 2018, 09:31:50

Zitat von: hexenmeister am 29 November 2018, 13:02:00
Wird natürlich gehen. Z.B. könnte man mit einem userReading eine neue Reading aus anderen Readings so befüllen, dass dort JSON-String sntsteht. Die Bridge wird ihn, falls erwünscht, brav transportieren. Oder man nimmt 'expression' (s. Commandref zu der GenricBridge) und modifiziert ein zu übertragendes Reading-Inhalt 'on the fly'.

Ich tue mich gerade schwer damit, eine JSON-konforme Message mit der MQTT_GENERIC_BRIDGE zu generieren.

Was ich möchte: Ich möchte einen JSON-konformen Output für die Message erhalten. Dieser soll so aufgebaut sein, dass das Topic einem bestimmten Präfix (fhempub/<Gerätename>) entspricht. In der Nachricht soll JSON-konform das Setting und dessen Wert als Paar übertragen werden. In plain MQTT würde das z.B. so aussehen: {"state":"on"}.

Zunächst ist mir aufgefallen, dass, wenn ich die Variable $base benutze, gar kein Output am Broker ankommt. Habe das mit den letzten beiden Beispielen von mqttPublish ausprobiert. Hier sollte entweder darauf hingewiesen werden, dass $base bei Verwendung dringend definiert sein muss oder aber $base sollte einfach durch einen Leerstring ersetzt werden, so dass ein $base/$name einfach nur als /$name aufgelöst wird. In der MQTT_GENERIC_BRIDGE habe ich lediglich

Weiter in meinen Versuchen. Ändere ich also das topic, bekomme ich auch Output, aber ich verstehe nicht, wie die Definition zum Output passt:

Code Auswählen

*:topic={"fhempub/$device/$name"} reading:expression={$value="message: $value"}

Ich würde erwarten, dass in der Message nun der $value um den Text "message: " ergänzt wird - dies passiert aber nicht. Die Message ist weiterhin dim 0 oder dim 99. Ich hätte hier wie gesagt "message: dim 0" bzw. "message dim 99" erwartet.

Um zu überprüfen ob das "message: " nicht als Keyword zu interpretieren sei, habe ich sicherheitshalber wie folgt definiert:

Code Auswählen

*:topic={"fhempub/$device"} reading:expression={$value="message: $name/$value"}

Aber auch hier bleibt die Message bei "dim 0" bzw "dim 99" wenn ich den Schalter betätige.

Da ich an dieser Stelle schon ein Verständnisproblem bzgl. der Syntax habe (oder vielleicht ist es ja auch ein Fehler

) würde ich mich über eine Hilfestellung freuen.

Eine Syntax a la:

Code Auswählen

*:topic={"fhempub/$device"} message={"$name":"$value"}
wäre für diesen Anwendungsfall toll - gerne aber auch anders, nur ich bekomme es auch nach vielem Herumprobieren leider nicht hin.

Schon einmal vielen Dank im Voraus für das Erhellen des aktuell tief schwarzen Dunkels...

hexenmeister · 06 Dezember 2018, 16:12:06

Problem verstanden. Muss zuhause ausprobieren. Versuche heute dazu zu kommen. Bin ein wenig gestresst

hexenmeister · 06 Dezember 2018, 22:56:29

$base Problem gelöst. Morgen per Update.
Den Rest schaue ich mir später (morgen?) an.

HomeAlone · 10 Dezember 2018, 11:06:59

Zitat von: hexenmeister am 06 Dezember 2018, 22:56:29
$base Problem gelöst. Morgen per Update.

Habe es überprüft und jetzt werden auch messages bei nicht definiertem $base verschickt - das $base wird sinnigerweise durch einen Leerstring ersetzt. Danke schon mal dafür.

Zitat von: hexenmeister am 06 Dezember 2018, 22:56:29
Den Rest schaue ich mir später (morgen?) an.

Das wäre klasse!

Bei der weiteren Suche nach einer Lösung bin ich auf folgende Antwort von Dir in einem anderen Thread gestoßen:
https://forum.fhem.de/index.php/topic,93175.msg857755.html#msg857755

Das dortige Beispiel habe ich einmal auf das reading state angewandt:

Code Auswählen

state:topic={"fhempub/$device"} state:expression={"{\"$reading\":\"$value\"}"}
und siehe da, ich bekomme für ein bestimmtes Reading (hier: state) die gewünschte Antwort als sauberes JSON-Objekt, das auch von Node-Red nicht mehr bemeckert wird.

Das klappt so auch wunderbar, wenn ich diesen Ausdruck in der Bridge unter globalPublish hinterlege.

In meiner Naivität, habe ich das Ganze veralgemeinern wollen:

Code Auswählen

*:topic={"fhempub/$device"} *:expression={"{\"$reading\":\"$value\"}"}
Was aber leider nicht matched.

Aber ich bin schon mal wieder ein Stückchen weiter.

Mühsam ernährt sich das Eichhörnchen...

hexenmeister · 10 Dezember 2018, 21:30:27

Bin bis Mittwoch im Ausland. Kann mich leider erst dann damit beschäftigen.
Ich denke ich erstelle eine Hilfsfunktion zum bequemen verpacken von Readings in json. Etwa sowas expression={tojson({"name" => "reading"}).

HomeAlone · 13 Dezember 2018, 10:23:15

Zitat von: hexenmeister am 10 Dezember 2018, 21:30:27
Bin bis Mittwoch im Ausland. Kann mich leider erst dann damit beschäftigen.
Ich denke ich erstelle eine Hilfsfunktion zum bequemen verpacken von Readings in json. Etwa sowas expression={tojson({"name" => "reading"}).

Keine Eile - nur Ungeduld

Habe mal ein wenig recherchiert: Es gibt bereits eine Perl-Library für JSON, die alle notwendigen Funktionen enthält: https://www.tutorialspoint.com/json/json_perl_example.htm
Die könntst Du vermutlich verwenden, um den Aufwand gering zu halten.

Eventuell könnte man die JSON-Funktionen global als Modul/Erweiterung/Library? in fhem zur Verfügung stellen. In einer ersten Version die Funktionen des Moduls 1:1 wrappen und dann um sinnvolle Funktionen erweitern - wie z.B. readings<->[JSON|JSON-String]. Dann müsste nicht jeder Modulentwickler das Rad neu erfinden.

Habe zudem gesehen, dass bereits an einigen Stellen teilweise Funktionaltitäten für JSON-Support geschaffen wurden, wenn ich das richtig sehe aber überwiegend im Rahmen zu bestimmten Modulen:

expandJSON() -> https://forum.fhem.de/index.php?topic=69067.0 Wrappen der Werte eines JSON Strings in individuelle Readings
toJSON() und Diskussion über Gegenpart dazu (der wohl auch schon in MQTT2_... implementiert ist?) -> https://forum.fhem.de/index.php/topic,90208.15.html
JsonList2 aus der commandref -> https://fhem.de/commandref.html#JsonList2 -> Scheint spezifisch für irgendwelche Buderus Geräte zu sein?
Und dann bin ich auf diesen Thread gestoßen -> https://forum.fhem.de/index.php/topic,90208.0.html der sich mit der Fragestellung beschäftigt, ob die Funktionen des Perl-Moduls für JSON oder native Implementierungen sinniger seien...

Ich könnte mir vorstellen, dass die Nutzung des Perl JSON-Moduls den geringsten Aufwand bedeutet.

Hoffe, ich konnte ein wenig Recherchearbeit abnehmen - beim Programmieren kann ich leider nicht so viel helfen.

Viele Grüße
Sascha

hexenmeister · 13 Dezember 2018, 10:34:33

entsprechende Funktionalität gibt es bereits in fhem.pl und kann eig. genutzt werden. Es geht hier nur darum, die Verwendung möglichst einfach unf bequem zu gestallten.

Maui · 14 Dezember 2018, 13:50:51

Moin Alex, ich versuch grad mal meine Blocking Calls zu vermindern (mit perfmon und apptime). Hab schon viele Bösewichte abgesägt, aber aktuell ist mqtt bzw. MQTT Gen.Bri. mein größter Blocker mit häufig über 1s.
Bei mir kommen zwar so um die 30 incoming-counts in der Minute, aber das sollte ja nicht mqtt in fhem ausreizen. Liegt es vielleicht an dem json2Name?
Ich werde mal eine minimal-FHEM Instanz nehmen, dort die Bridge einrichten und nur 1 Gerät Messages hinschicken lassen. Und dann halt mit und ohne json Auswertung.

Hat jemand anders ähnliche Erfahrungen mit apptime gemacht? Ich bin mir allerdings auch nicht sicher, wie gut man apptime trauen kann bzw. ob es nicht manchmal mehr zu interpretieren gibt als man direkt sieht. Sowas wie nachgeschaltete Events.

EDIT: am json liegt es nicht. Im minimal FHEM braucht es Max 100ms

EDIT2: Hab mir das mal im Event Log angeschaut.
Ist es normal, dass das Verarbeiten von ca. 10 Reading 400ms braucht?

Code Auswählen

2018-12-14 17:43:44.805 MQTT_GENERIC_BRIDGE mqqtGB transmission-state: incoming publish received
2018-12-14 17:43:44.832 MQTT_GENERIC_BRIDGE mqqtGB incoming-count: 54
2018-12-14 17:43:44.845 dummy Swi_Heizung ENERGY_Current: 0.304
2018-12-14 17:43:44.857 MQTT_GENERIC_BRIDGE mqqtGB updated-reading-count: 426
2018-12-14 17:43:44.867 dummy Swi_Heizung ENERGY_TotalStartTime: 2018-11-22T15:23:08
2018-12-14 17:43:44.880 MQTT_GENERIC_BRIDGE mqqtGB updated-reading-count: 427
2018-12-14 17:43:44.890 dummy Swi_Heizung ENERGY_Voltage: 223
2018-12-14 17:43:44.902 MQTT_GENERIC_BRIDGE mqqtGB updated-reading-count: 428
2018-12-14 17:43:44.927 dummy Swi_Heizung ENERGY_Total: 73.867
2018-12-14 17:43:44.940 MQTT_GENERIC_BRIDGE mqqtGB updated-reading-count: 429
2018-12-14 17:43:44.949 dummy Swi_Heizung ENERGY_ApparentPower: 68
2018-12-14 17:43:44.962 MQTT_GENERIC_BRIDGE mqqtGB updated-reading-count: 430
2018-12-14 17:43:44.996 dummy Swi_Heizung ENERGY_Yesterday: 1.233
2018-12-14 17:43:45.011 MQTT_GENERIC_BRIDGE mqqtGB updated-reading-count: 431
2018-12-14 17:43:45.023 dummy Swi_Heizung ENERGY_Factor: 0.75
2018-12-14 17:43:45.037 MQTT_GENERIC_BRIDGE mqqtGB updated-reading-count: 432
2018-12-14 17:43:45.047 dummy Swi_Heizung Time: 2018-12-14T17:43:43
2018-12-14 17:43:45.060 MQTT_GENERIC_BRIDGE mqqtGB updated-reading-count: 433
2018-12-14 17:43:45.089 dummy Swi_Heizung ENERGY_Today: 0.899
2018-12-14 17:43:45.103 MQTT_GENERIC_BRIDGE mqqtGB updated-reading-count: 434
2018-12-14 17:43:45.113 dummy Swi_Heizung ENERGY_Period: 1
2018-12-14 17:43:45.126 MQTT_GENERIC_BRIDGE mqqtGB updated-reading-count: 435
2018-12-14 17:43:45.155 dummy Swi_Heizung ENERGY_Power: 51
2018-12-14 17:43:45.168 MQTT_GENERIC_BRIDGE mqqtGB updated-reading-count: 436
2018-12-14 17:43:45.179 dummy Swi_Heizung ENERGY_ReactivePower: 45
2018-12-14 17:43:45.192 MQTT_GENERIC_BRIDGE mqqtGB updated-reading-count: 437

Fuchsbau · 14 Dezember 2018, 15:58:06

Kämpfe gerade mit MQTT_GENERIC_BRIDG,
habe es mit:

Code Auswählen

defmod mqttGeneric MQTT_GENERIC_BRIDGE Mqtg
attr mqttGeneric IODEV myBroker

angelegt.
Device-List:

Code Auswählen

Internals:
   CFGFN      
   DEF        Mqtg
   IODev      myBroker
   NAME       mqttGeneric
   NR         171
   NTFY_ORDER 50-mqttGeneric
   STATE      ???
   TYPE       MQTT_GENERIC_BRIDGE
   devspec    .*
   prefix     Mqtg
   Helper:
     DBLOG:
       device-count:
         DBLogging:
           TIME       1544794672.56157
           VALUE      0
       transmission-state:
         DBLogging:
           TIME       1544794672.60464
           VALUE      IO device initialized (mqtt)
   READINGS:
     2018-12-14 14:37:52   device-count    0
     2018-12-14 14:37:15   incoming-count  0
     2018-12-14 14:37:15   outgoing-count  0
     2018-12-14 14:37:52   transmission-state IO device initialized (mqtt)
     2018-12-14 14:37:15   updated-reading-count 0
     2018-12-14 14:37:15   updated-set-count 0
   devices:
   globalDeviceExcludes:
   globalReadingExcludes:
   globalTypeExcludes:
     pub:
       FHEMWEB    *
       Global     *
       MQTT       transmission-state
       MQTT_BRIDGE transmission-state
       MQTT_DEVICE transmission-state
       MQTT_GENERIC_BRIDGE *
       telnet     *
     sub:
       FHEMWEB    *
       Global     *
       MQTT       transmission-state
       MQTT_BRIDGE transmission-state
       MQTT_DEVICE transmission-state
       MQTT_GENERIC_BRIDGE *
       telnet     *
   subscribe:
   subscribeExpr:
   subscribeQos:
Attributes:
   IODev      myBroker

myBroker ist eine MQTT-Serverinstanz auf dem Raspberry. Die läuft auch. Hab auch einige MQTT-Devices im Fhem laufen.
Müsste nicht MQTT_GENERIC_BRIDGE jetzt selbständig relevante Devices 'einsammeln' und in seine Readings (Counter) anzegen?
Oder verstehe ich das Modul falsch?

Maui · 14 Dezember 2018, 20:50:12

Bevor ich jetzt ein 3. edit aufmache.
Hab mir das nochmal in Ruhe angeschaut und mit dem json2... braucht das Auswerten grob 400ms.
Nehme ich expandjson schafft FHEM es unter 100ms

hexenmeister · 14 Dezember 2018, 22:33:25

Zitat von: Fuchsbau am 14 Dezember 2018, 15:58:06
Müsste nicht MQTT_GENERIC_BRIDGE jetzt selbständig relevante Devices 'einsammeln' und in seine Readings (Counter) anzegen?
Oder verstehe ich das Modul falsch?

Due Bridge sammelt nichts selbständig, sondern stellt in den Devices einige zusätzliche Attribute, mit deren Hilfe die MQTT-Transport konfiguriert werden kann. Erst dann werden diese gezählt. Steht alles in Commandref beschrieben.

hexenmeister · 14 Dezember 2018, 22:41:34

Also 10 Readings alleine zu aktualisieren ist nicht die Welt, auch 30 pro minute ist gar nichts. Ich habe mehr Last, ohne 'Hänger'. Allerding verwende bischer JSON fast gar nicht. Ich denke, das Problem liegt genau daran. Ich sehe zwei Lösungsansätze: 1. die performantere JSON-Implementierung suchen/wählen uind 2. Parsen von JSON als 'BlockingCall' implementieren. Lösung 2 ist programmiertechnisch etwas auwendiger.

Ich werde Zeit suchen, mit eine JSON-Infrastruktur zum Testen aufzubauen. Irgendwo liegt sogar ein neuer Sonoff, den ich bestellt aber nie verwendet hatte.

Maui · 14 Dezember 2018, 23:41:09

Zitat von: hexenmeister am 14 Dezember 2018, 22:41:34
Also 10 Readings alleine zu aktualisieren ist nicht die Welt, auch 30 pro minute ist gar nichts. Ich habe mehr Last, ohne 'Hänger'. Allerding verwende bischer JSON fast gar nicht. Ich denke, das Problem liegt genau daran. Ich sehe zwei Lösungsansätze: 1. die performantere JSON-Implementierung suchen/wählen uind 2. Parsen von JSON als 'BlockingCall' implementieren. Lösung 2 ist programmiertechnisch etwas auwendiger.

Ich werde Zeit suchen, mit eine JSON-Infrastruktur zum Testen aufzubauen. Irgendwo liegt sogar ein neuer Sonoff, den ich bestellt aber nie verwendet hatte.

Genieß lieber die Feiertage.

Ich werde erstmal wieder zurück auf expandjson gehen.
Hab jetzt mal die längeren jsons umgestellt und komme in apptime auf ein average von grob 100 statt 400. Das deckt sich ja auch ganz gut mit meinen Event Monitor Forschungen.

EDIT: Ich seh grad, dafür braucht ej3 jetzt 60ms avg.
Ist zusammen allerdings immer noch unter 200ms

jvollmer · 16 Dezember 2018, 12:57:05

Guten Morgen, ich habe das tolle Modul Generic Bridge installiert, habe jedoch bei Einbindung über MQTT2_CLIENT (an mosquito) immer folgende Fehlermeldung erhalten:

Code Auswählen

2018.12.16 12:07:49 1: IOT.vollmer2: ERROR: Ignoring function subscribe
Das Subscribe wurde auch nicht ausgeführt.
Nach Code Änderung in MQTT2_CLIENT (Z 411 in MQTT2_CLIENT_Write) von

Code Auswählen


  } elsif($function eq "subscriptions" ) {

auf

Code Auswählen


  } elsif($function eq "subscriptions" || $function eq "subscribe") {

kann ich endlich aus ein subscribe absetzen.
Ich habe jedoch die Module noch nicht durchschaut. Ist es vielleicht ein Fehler in meiner Implementation oder ist es tatsächlich ein Modulfehler?
...
Client:

Code Auswählen

Internals:
   CFGFN      /media/usb0/fhem/FHEM/00_Utils_Vo_MQTT.cfg
   DEF        192.168.100.60:1883
   DeviceName 192.168.100.60:1883
   NAME       IOT.vollmer2
   NR         571
   STATE      opened
   TYPE       MQTT2_CLIENT
   clientId   fhemIOT2
   connecting 1
   READINGS:
     2018-12-16 12:23:44   state           opened
Attributes:
   autocreate 1
   clientId   fhemIOT2
   devStateIcon (opened):rc_dot  .*:rc_dot@red
   disable    0
   group      MQTT
   keepaliveTimeout 1200
   lwt        fhem/Zentralen/IOT2 offline
   lwtRetain  1
   msgAfterConnect -r fhem/Zentralen/IOT2 online
   room       Zentralen
   subscriptions setByTheProgram

Bridge:

Code Auswählen

Internals:
   CFGFN      /media/usb0/fhem/FHEM/00_Utils_Vo_MQTT.cfg
   DEF        mqtt (TF|House)Open.warn
   IODev      IOT.vollmer
   NAME       mqtt2_Open.warn
   NR         694
   NTFY_ORDER 50-mqtt2_Open.warn
   STATE      outgoing publish sent
   TYPE       MQTT_GENERIC_BRIDGE
   devspec    (TF|House)Open.warn
   prefix     mqtt
   READINGS:
     2018-12-16 12:31:41   device-count    2
     2018-12-16 12:34:41   incoming-count  1
     2018-12-16 12:34:41   outgoing-count  4
     2018-12-16 12:34:41   transmission-state outgoing publish sent
     2018-12-16 12:31:00   updated-reading-count 0
     2018-12-16 12:34:41   updated-set-count 1
   devices:
     :global:
       :defaults:
         pub:base   {"fhem/Zentralen"}
         pub:retain 0
         sub:base   {"fhem/Zentralen"}
         sub:retain 0
     HouseOpen.warn:
       :publish:
         state:
           last       1544959971.87915
           mode       R
           topic      {"$base/HouseOpen"}
       :subscribe:
         HASH(0x3e00168)
     TFOpen.warn:
       :publish:
         state:
           last       1544960081.22187
           mode       R
           topic      {"$base/TFOpen"}
       :subscribe:
         HASH(0x411d860)
         HASH(0x3e07978)
   globalDeviceExcludes:
   globalReadingExcludes:
   globalTypeExcludes:
     pub:
       FHEMWEB    *
       Global     *
       MQTT       transmission-state
       MQTT_BRIDGE transmission-state
       MQTT_DEVICE transmission-state
       MQTT_GENERIC_BRIDGE *
       telnet     *
     sub:
       FHEMWEB    *
       Global     *
       MQTT       transmission-state
       MQTT_BRIDGE transmission-state
       MQTT_DEVICE transmission-state
       MQTT_GENERIC_BRIDGE *
       telnet     *
   message_ids:
   subscribe:
     fhem/Zentralen/HouseOpen/check
     fhem/Zentralen/TFOpen/check
     fhem/Zentralen/TFOpen/open
   subscribeExpr:
     ^fhem\/Zentralen\/HouseOpen\/check$
     ^fhem\/Zentralen\/TFOpen\/check$
     ^fhem\/Zentralen\/TFOpen\/open$
   subscribeQos:
     fhem/Zentralen/HouseOpen/check 0
     fhem/Zentralen/TFOpen/check 0
     fhem/Zentralen/TFOpen/open 0
Attributes:
   IODev      IOT.vollmer
   globalDefaults base={"fhem/Zentralen"} retain=0
   group      MQTT,helperNotifyer
   room       Alarm
   stateFormat transmission-state