MQTT2 Device für MEDION Alarmanlage

[deeb]

Bereits 2018 gab es eine Anfrage zur Kopplung der Aldi/Medion Alarmanlage mit Fhem: https://forum.fhem.de/index.php?topic=82655.0.
Die Kommunikation zwischen den einzelnen Komponenten der Alarmanlage erfolgt über BT.
Im  März 2020 wurde über die Einbindung/Kopplung der verwendeten Sensoren (Magnetkontakte, Bewegungsmelder und Rauchmelder)  mit einen MQTT Server berichtet: https://community.medion.com/t5/Smart-Home/Medion-Smart-Home-Sensoren-über-Raspberry-Pi-direkt-lesen/m-p/90245
Es gibt dazu zwei Python-Scripte, die einmal die Verbindung der Alarmanlage mit dem Internetwebserver/der Cloud auslesen und zum anderen die WLAN-Kommunikation der Komponenten mit der Alarmzentrale mitschneiden und die Daten an einen MQTT-Server weiterleiten.
Details dazu lassen sich hier nachlesen: https://gitlab.com/shd290/mshtools/-/blob/master/README.md
Über MQTT.fx lassen sich diese Datensätze dann im JSON Format anzeigen:
Beispiel Bewegungsmelder :
{
  "mac" : "3CA308B8E3EE",
  "source" : "13-derpi3",
  "details" : "move",
  "value" : 163,
  "rssivalue" : -70.0,
  "timestampRT" : 1591554301403,
  "type" : 10,
  "name" : "BM2_EG_Essen_918"
}
Beispiel Magnetkontakt:
{
  "mac" : "50338B73AD50",
  "source" : "13-derpi3",
  "details" : "open",
  "value" : 1,
  "rssivalue" : -59.0,
  "timestampRT" : 1591552215101,
  "type" : 4,
  "name" : "MK2_Diele_Terrasse_126"
}
Nach meinen Recherchen gibt es für Fhem leider noch kein passendes Template um z.B. ein entsprechendes MQTT2_DEVICE anzulegen.
Meine Programmierkenntnisse sind leider nicht so ausgeprägt um selbst die notwendigen Änderungen/Anpassungen vorzunehmen. Aber gerne würde ich einen Experten mit den notwendigen Input versorgen und testen.
MfG
deeb

[87insane]

Um ggf mehr leser zu erhalten, erwähne mal was du alles schon probiert hast. Auch interessant wäre, ob du einen mqtt2 Server am laufen hast und ggf sogar via autocreate ein Gerät erzeugt wurde..sicher dann sogar mehere. Wenn dem so ist, wäre ein list sehr gut. Dann kann man sehen was in den entsprechenden geräten so ankommt, welche regex man verwenden könnte usw. Also wir brauchen quasi alle Fakten dazu.

Achso - Hallo und viel Erfolg. Ich lese mal mit und versuche zu helfen. Hab selber diese Hardware nicht aber das ist egal. Deswegen ist für jeden von denen, die ggf helfen könnten, wichtig das du die o.g. Dinge abarbeitest oder sogar schon beantworten kannst. Solltest du fragen haben, die spezieller sind als das Wiki es beantworten kann, kannst du ja direkt wieder hier fragen.

Gruß,
87insane

Gesendet von meinem LM-G810 mit Tapatalk

[KölnSolar]

Da gruselts mich mal wieder. Alarmanlagendaten in der Cloud. 

Da Du bereits mit mqtt.fx empfängst, kannst Du Dir ein mqtt2-client-device anlegen. Weiteres sollte dann per autocreate relativ einfach gehen.

[deeb]

Hallo KölnSolar, hallo 87insane,
ich stimme dir zu, eine Alarmanlage in der Cloud ist sicher keine sichere Lösung, aber immer noch besser als keine Lösung. Ich nutze sie ja auch nur privat in einem Einfamilenhaus mit 3 Etagen.
In jeder Etage läuft ein Rasp. Habe mir jetzt ein mqtt2-client angelegt. der auf den Mosquitto-Server zugreift (läuft noch auf den selben Raspi4, wo auch fhem läuft).
Ein mqtt2_device  mosquitto wurde nach einigen probieren mit dem Templeate General Info bzw. MQTT2_Client_general_bridge auch angelegt.
Im Log (vergl. Anhang) bekomme ich jetzt auch die Meldungen, die ich vorher nur über das Programm MQTT.fx lesen konnte.
Allerdings für alle Subscribe und etwas ungeordnet. Vermutlich wegen der Zeile  attr deMQTT2_Client subscriptions #

define deMQTT2_Client MQTT2_CLIENT 192.168.xx.xx:1883
setuuid deMQTT2_Client 5edd5169-f33f-d326-4be0-bef3a97f57cacaa8
attr deMQTT2_Client autocreate 1
attr deMQTT2_Client room test
#attr deMQTT2_Client subscriptions msh/d_bm1_og_flur_220 msh/d_bm2_eg_essen_918 msh/d_bm3_eg_treppe_192 msh/d_mk6_balkontuer_og_211
attr deMQTT2_Client subscriptions #

define mosquitto MQTT2_DEVICE mosquitto
setuuid mosquitto 5edd6206-f33f-d326-91df-2d89e3db9a0362ff
attr mosquitto IODev deMQTT2_Client
attr mosquitto autocreate 1
attr mosquitto bridgeRegexp (tele|cmnd)[/]([^/]+)[/].*:.* "$2"\
  shellies[/]([^/]+)[/].*:.* "$1"\
  (ESPClient_[^/]+)[/].*:.* "$1"\
  valetudo[/]([^/]+)[/].*:.* "$1"\
  [^/]+[/](ems-esp[^/]+)[/].*:.* "$1"\
  wallpanel[/]([^/]+)[/].*:.* "$1"\
  (wled)[/]([^/]+)[/].*:.* "$1_$2"\
  (go-eCharger)[/]([^/]+)[/].*:.* "go_eCharger_$2"\
  (owntracks)[/]([^/:]+)[/]([^/:]+).*:.* "$1_$2$3"
attr mosquitto comment Do not use very open bridgeRegexp expressions! This might lead to irritating results...
attr mosquitto icon mqtt_bridge_2
attr mosquitto model MQTT2_CLIENT_general_bridge
attr mosquitto room test
attr mosquitto setStateList on off

Welchen Teil der Regexp expressions ich jetzt rauslöschen sollte, ist mir noch nicht ganz klar. Schön wäre es, wenn ich für jeden Melder (Magnetkontakte, Bewegungsmelder) ein eigenes Device und auch ein eigenes LogFile hätte.
Wenn das gelöst ist, wäre der nächste Schritt, weitere BT-Melder (schaltbare Steckdosen, die Alarmzentrale selbst, die Aussensirene) einzubinden. Dafür müsste sicherlich aber dann das Python Sript SH_CheckBLE.py noch erweitert werden, damit diese Melder auch auf den Mosquitto-Server angezeigt werden. Denkbar wäre es dann auch mal, auf die Cloud ggf. ganz zu verzichten und alles in fhem auf den Raspi laufen zu lassen.

Danke für jeden weitern Hinweis + mfG

deeb

[KölnSolar]

Benutze bitte code u. quote tags(hashtag-,Sprechblasenzeichen). Dann lässt sich das leichter lesen.

Ich selber habe immer nur eine 1:1-Beziehung, also ohne bridge. Beta meldet sich bestimmt, um da weiterzuhelfen. Als Input helfen ihm bestimmt die messages(topic + payload)
Grüße Markus

[87insane]

Guten Morgen zusammen....

Wenn du auf mqtt2 umstellt geht es einiges einfacher. Sowas wird beta-user vermutlich auch sagen.

Wir sind seid kurzen am Modul sonos2mqtt dran. Dort mussten wir vom weg her das gleiche machen. In der Bridge entsprechende regex setzen usw. Was ich damit sagen will, in dem thread kannst du dir den Weg an sich abgucken.

Gesendet von meinem LM-G810 mit Tapatalk

[Beta-User]

Vorab mal: Herzlich willkommen im FHEM-Forum .

Wie 87insane andeutet, stelle ich mir schon die Frage, warum hier mosquitto genutzt wird, weil man sich grade als Anfänger mit MQTT2_CLIENT doch deutlich schwerer tut wie mit MQTT2_SERVER (OT: An der Antwort wäre ich wirklich interessiert).
Hier ist der Einstieg aber schon mal ganz gut gelungen, und auch die Frage, was an dem General-Bridge-bridgeRegexp zu ändern ist geht m.E. in die richtige Richtung.

Dann mal meine Gedanken der Reihe nach...

Vorbemerkungen:
Es gibt derzeit zwei MQTT2-Devices: Neben der GeneralBridge (hier namens "mosquitto") noch eines mit Namen "MQTT2_deMQTT2_Client", das ist das Device mit der CID des IOs MQTT2_CLIENT. Ich nenne das gerne "Sammeldevice", weil da in dieser Konstellation alles landet, was nicht irgendwie zugeordnet werden kann. Wer MQTT2_CLIENT nutzt, sollte dieses Device immer im Auge behalten und dann versuchen, alles, was er "haben will", in andere Devices umzuleiten. Einen Teil der Arbeit nimmt einem das 2. Device ab, indem es typische Fälle errät/kennt. Das würde ich tendenziell auch so lassen, die dortige bridgeRegexp baue ich über attrTemplate auch bei jeder passenden Gelegenheit "auf Verdacht" aus, so dass es für die meisten einfacher sein dürfte, das einfach auch hin und wieder zu checken, ob es updates gibt, und "andere" Fälle auch an anderer Stelle zu lösen.

bridge-Device
Wie KölnSolar schreibt, braucht man etwas Infos zur Topic-Struktur. Hier war zwar nicht der RAW-MQTT-Verkehr in Auszügen zu sehen (die "ausgepackten" Messages beim MQTT2-Device sind wenig aufschlussreich), aber wenigstens der link auf die Doku zu finden. In
https://gitlab.com/shd290/mshtools/-/blob/master/README.md#mqtt-sensor-ausgaben steht

Fuer jeden Sensor wird in der Cloud einen Namen vergeben. [...] Die uebertragung erfolgt ueber Subscribe mit dem folgenden Topic:
msh/d_{NameSensor)

Also machen wir ein neues Device:

Code Auswählen Erweitern

defmod MEDION_Alarm MQTT2_DEVICE msh
attr MEDION_Alarm bridgeRegexp msh/d_([^/]+).*:.* "msh_$1"
attr MEDION_Alarm readingList msh/([^d][^/]).*:.* {json2nameValue($EVENT,''$JSONMAP)}
und löschen die readingList am "Sammeldevice" (bzw. das ganze Device) - mind. das Löschen der rL muss man IMMER machen, wenn man die derzeit dort vorhandenen Daten woanders haben will:

Code Auswählen Erweitern

deleteattr MQTT2_deMQTT2_Client readingList
Jetzt sollte die bridgeRegexp bei Eintreffen passender Nachrichten für jeden Sensor ein eigenes Device anlegen, und ggf. das, was direkt den Dienst/das Script angeht direkt ab das Device "MEDION_Alarm" schreiben.

Wenn das soweit klappt, wäre eine Rückmeldung nicht schlecht...
(Das log sah aber nach einem unglaublich geschwätzigen Verkehr aus => auf der Client-Seite (im Script) nicht gut gelöst)

Um das Thema Rauchmelder (und Befehle dahin) müßte man sich dann ggf. mal separat kümmern.


OT:
Da die Kommunikation via BT läuft und scheinbar das Auslesen der Werte nicht sooo schwierig zu sein scheint, wäre es ggf. eine Überlegung, das ganze auf eine ganz andere Art anzugehen. Ich sehe zwei Ansätze:
- Es gibt (mind.) zwei Module, die BT-Kommunikation (indirekt) über die Pi-Schnittstelle bzw. gattool erledigen (Xiaomi-irgendwas, das empfängt aber nur (?), und das Modul für die eQ-3-BT-Thermostate, das mind. die Uhrzeit an die Dinger schickt). Evtl. wäre es eine Idee, die betreffenden Maintainer mal anzuschreiben, ob man nicht
-- einen allg. BT-Stack für FHEM aufziehen kann und die betr. Module dann dort einheitlich anflanschen (sofern das technisch notwendig ist, damit die Schnittstelle nicht exklusiv genutzt wird);
-- darauf aufbauend dann jeweils "Gerätespezifischen Code" bauen kann.

- OpenMQTTGateway (dafür würde z.B. ein ESP32 reichen) versteht auch einige generische BT-Geräte. Evtl. kann man das "Medion"-Protokoll da anflanschen (das sendet aber derzeit auch noch nichts, sondern liest nur den BT-Verkehr mit; ich habe den Verdacht, dass da nichts wirklich "verschlüsselt" wird).
Ich würde in jedem Fall mal empfehlen, dass du dir einen ESP32 zulegst und den mit dieser firmware versuchsweise flashst (kostet unter 5 Euro bei Bestellung in Fernost). Dann sähe man zumindest, welcher Teil des Funkverkehrs ganz offen ist...

Hoffe, das hilft erst mal weiter .


OT: "Alarmanlage" und Cloud finde ich auch grenzwertig, aber "Alarmanlage" und Funk ist an sich nochmal ein weiterer Witz, schon gleich, wenn das Frequenzband 2.4GHz genutzt wird. Allerdings dürfte es so sein, dass die so gelabelten Geräte in Fernost günstiger zu bekommen sind als die 20 Steine, die ich auf die Schnelle gefunden hatte, und dann wäre das immerhin eine weitere Variante für Heizungssteuerung, die man mit einem einfachen GW einbinden könnte...

[deeb]

Hallo Beta-User,

danke, dass du dir so viel Arbeit für mich gemacht hast.
Deine erste Frage warum MQTT2_CLIENT und nicht MQTT2_SERVER kann ich gern beantworten.
Ich habe die ganze Aktion (Verbindung FHEM mit Medion-Alarmanlage) nicht von der FHEM-Seite aus gestartet, obwohl ich dazu seit 2 Jahren regelmäßig nach Einstiegsmöglichkeiten gesucht habe.
Mit den Hinweis im MEDION-Forum zu den mshtools habe ich zumindest einen Einstiegspunkt gefunden, auf den ich weiter aufbauen konnte. Das war der Zeitpunkt für die Mosquitto Installation. Nachdem ich dann neben der Putty/Consolenausgabe auch noch zusätzlich mit dem Programm MQTT.fx einen Teil der Datenkommunikation mitlesen konnte erschien es mir dann leichter mit MQTT2_CLIENT weiter zu arbeiten. Ein erster FHEM-Teilerfolg stellte sich dann ja auch gestern mit den Logfileeinträgen ein.
Heute habe ich den Mosquitto Server entfernt und es mal mit folgenden Coding in verschiedenen Varianten (mit und ohne MQTT_GENERIC_BRIDGE) versucht:

define deBroker MQTT2_SERVER 1883 global
setuuid deBroker 5ede8b9c-f33f-d326-1077-547bea6cd437f57b
attr deBroker room test

define mqttGeneric MQTT_GENERIC_BRIDGE
setuuid mqttGeneric 5ede8b9d-f33f-d326-97ba-0916bdf9a5fbb7cf
attr mqttGeneric IODev deBroker
attr mqttGeneric room test

define MEDION_Alarm MQTT2_DEVICE msh
setuuid MEDION_Alarm 5ede8b9d-f33f-d326-048e-f27c3a91eb37e1c0
attr MEDION_Alarm IODev deBroker
#attr MEDION_Alarm autocreate 1
attr MEDION_Alarm bridgeRegexp msh/d_([^/]+).*:.* "msh_$1"
attr MEDION_Alarm readingList msh/([^d][^/]).*:.* {json2nameValue($EVENT,''$JSONMAP)}
attr MEDION_Alarm room test

Vermutlich habe ich was überlesen oder falsch verstanden. Mit dem Programm MQTT.fx kann ich zumindest noch mitlesen, was auf dem MQTT2_SERVER ankommt.
Ein Logfile oder andere hoffnungsvolle Ansatzpunkte konnte ich in FHEM aber nicht finden.
Deshalb werde ich noch mal den anderen Weg von gestern versuchen.
Mit der nachfolgenden Konfiguration habe ich aber leider auch kein Erfolg mehr (selbst das LogFile bringt keine Einträge mehr).

define deMQTT2_Client MQTT2_CLIENT 192.168.66.14:1883
setuuid deMQTT2_Client 5ede9c0e-f33f-d326-c9c8-ed9fa74d4fd4e0e8
attr deMQTT2_Client autocreate 1
attr deMQTT2_Client room test
attr deMQTT2_Client subscriptions #

define mosquitto MQTT2_DEVICE mosquito
attr mosquitto IODev deMQTT2_Client
attr mosquitto autocreate 1
attr mosquitto comment Do not use very open bridgeRegexp expressions! This might lead to irritating results...
attr mosquitto icon mqtt_bridge_2
attr mosquitto model MQTT2_CLIENT_general_bridge
attr mosquitto room test
attr mosquitto setStateList on off

define MQTT2_deMQTT2_Client MQTT2_DEVICE
attr MQTT2_deMQTT2_Client IODev deMQTT2_Client
attr MQTT2_deMQTT2_Client autocreate 1
attr MQTT2_deMQTT2_Client room test

define MEDION_Alarm MQTT2_DEVICE msh
attr MEDION_Alarm IODev msh
attr MEDION_Alarm bridgeRegexp msh/d_([^/]+).*:.* "msh_$1"
attr MEDION_Alarm readingList msh/([^d][^/]).*:.* {json2nameValue($EVENT,''$JSONMAP)}
attr MEDION_Alarm room test

Vermutlich habe ich das MQTT2_deMQTT2_Client falsch definiert.
Für alle drei MQTT2_DEVICE (mosquitto, MQTT2_deMQTT2_Client und MEDION_Alarm) werden mir die drei als State angezeigt.
Soweit ich mich erinnern kann, haben sich gestern das mosquitto-DEVICE  und das MQTT2_deMQTT2_Client-DEVICE nicht selbst generiert.
Ich habe verschiedene Templates einfach mal durchprobiert.
Ok, bin heute nicht mal so weit wie gestern gekommen. Schade!
Zitat von KölnSolar:
Benutze bitte code u. quote tags(hashtag-,Sprechblasenzeichen). Dann lässt sich das leichter lesen.   
Antwort: muss ich mich erst noch einlesen
Auch muss ich mich erst noch schlau machen, wie ich den ,,RAW-MQTT-Verkehr in Auszügen" mitschneiden kann.

Ich wünsche euch noch einen schönen Abend und Gesundheit
MfG
deeb

[87insane]

Guten Morgen. Warum legst du die Geräte manuell an? Du kannst:

1. Mqtt2 server erstellen
2. autocreate in fhem aktivieren
3. es sollte automatisch was angelegt werden. Ab da beginnt dann was du willst. Hier müsste man sich selber die entsprechende regex für eine Bridge bauen. ABER bevor wir direkt dahin springen muss du 1-2 schaffen.

Gesendet von meinem LM-G810 mit Tapatalk

[Beta-User]

Ein paar ergänzende Anmerkungen dazu noch:

- das mit den Code-Tags: das "#" bei den smileys oberhalb des Editor-Felds beim Erstellen der Beiträge.

- Anfänger sollten UNBEDINGT die Finger von der fhem.cfg lassen. Hättest du das über FHEMWEB gemacht, wäre dir aufgefallen, (aktuelles FHEM vorausgesetzt!), dass die IO-Geräte "autocreate 1" nicht (mehr) kennen.

- Noch nicht verstanden habe ich, was bei einem von sich aus MQTT sprechenden Gerät eine MQTT_GENERIC_BRIDGE helfen soll.

- Bitte in der commandref den Abschnitt über list lesen und hier dann "list -r" (aka RAW-Definition => Import von code snippets im Wiki) einstellen.

- Falls die 2. Zeile in der readingList Probleme macht: Die bitte einfach erst mal weglassen und dann posten, was ggf. doch noch im Sammeldevice landet (falls du - warum auch immer - unbedingt Client nehmen willst); kann sein, dass meine regex-Versuche da unwirksam/kotraproduktiv waren.

[deeb]

Hallo 87insane, danke für die Hinweise und deine Geduld,

Mqtt2 Server läuft minimalistisch (mosquitto gelöscht!) und autocreate in der fhem.cfg auch:

Code Auswählen Erweitern


defmod deBroker MQTT2_SERVER 1883 global
attr deBroker autocreate complex
attr deBroker room test

setstate deBroker 2020-06-09 18:14:56 nrclients 3
setstate deBroker 2020-06-09 17:50:45 state Initialized


Code Auswählen Erweitern


define autocreate autocreate
setuuid autocreate 5e701fe6-f33f-d326-f4b6-a783e109f8a31398
attr autocreate filelog ./log/%NAME-%Y.log
attr autocreate room 99_System


an dem Rest arbeite (ist wohl mehr ein try and error) ich noch.

Hallo Beta-User,

danke für die Hinweise, ich hoffe das klappt jetzt mit dem Einfügen der Code-Tags.
Als Anfänger würde ich mich nicht unbedingt mehr bezeichnen.
Habe vor ca. 15 Jahren mit der Hausautomation auf Basis von fli4l (Druckerport an einem PC) angefangen.
Seit ca. 2014 läuft bei mir Fhem auf einem Raspi.
Bisher habe ich immer alle Konfigurationen in der fhem.cfg bzw. in einem meiner angelegte Incliúdes (um mehr Struktur zu bekommen) gemacht.
Aktuell läuft auf einem Raspi4 Nextcloud und FHEM (mosquitto nicht mehr).
An einem Raspi2 läuft ein K8055 Board über das ich verschiedene handverdrahtete Steuerungen realisiere.
Ein weiterer Raspi3 dient z.Z. nur als Empfänger/Repeater für die BT Signale der MEDION-Alarmanlage für MQTT.
Da ich für meine MQTT Gehversuche noch kein passendes Template gefunden habe, taste ich mich langsam an das Thema ran.
Die MQTT_GENERIC_BRIDGE war genau wie die Zeilen mit dem "autocreate 1" in dem MQTT2_DEVICE einer meiner verzweifelten Versuche.
Die Generic_Bridge habe ich jetzt raus genommen. Wobei ich nicht sicher bin, ob die Software (mshtool ste), die mir die encodierten BT-Signale der Medion-Alaramanlage auf einen MQTT-Server sendeen als "MQTT sprechendes Gerät" zu verstehen sind?
Auch das Device MQTT2_deMQTT2_Client habe ich gelöscht, da ich jetzt ja mit den Fhem MQTT2_Server arbeite.

Hier die noch übrig gebliebenen RAW Definitionen (hoffentlich richtig als Code-Tags):

Code Auswählen Erweitern


defmod deBroker MQTT2_SERVER 1883 global
attr deBroker autocreate complex
attr deBroker room test

setstate deBroker 2020-06-09 18:42:26 nrclients 3
setstate deBroker 2020-06-09 18:41:53 state Initialized


Code Auswählen Erweitern


defmod MEDION_Alarm MQTT2_DEVICE msh
attr MEDION_Alarm IODev deBroker
attr MEDION_Alarm bridgeRegexp msh/d_([^/]+).*:.* "msh_$1"
attr MEDION_Alarm readingList msh/([^d][^/]).*:.* {json2nameValue($EVENT,''$JSONMAP)}
attr MEDION_Alarm room test


So weit mein aktueller Stand, ich werde weiter versuchen die Signale der Bewegungsmelder und Magnetkontakte von der MEDION Alarmanlage in Fhem zu nutzen, weil ich mir dadurch die Installation weiterer Melder -die Fhem schon kennt- einsparen kann.

Wünsche noch einen schönen Abend
MfG
deeb

[deeb]

Hallo Beta-User

ich habe noch mal eine Frage zu deinen Code-Vorschlag von gestern:

Code Auswählen Erweitern


defmod MEDION_Alarm MQTT2_DEVICE msh
attr MEDION_Alarm bridgeRegexp msh/d_([^/]+).*:.* "msh_$1"
attr MEDION_Alarm readingList msh/([^d][^/]).*:.* {json2nameValue($EVENT,''$JSONMAP)}

Der Code unterscheidet sich bei den beiden Attributen zwischen " msh/ "  und " .*:.* ". einmal mit "d_" und bei der readingList ist kein Unterstrich.
Hat das etwas zu bedeuten?
Im MQTT.fx werden sie immer mit dem Unterstrich angezeigt z.B. msh/d_mk6_balkontuer_og_211    "msh/d_" ist der konstante Teil, der Rest kommt von den für die Melder vergebenen Namen.

Ich habe für den MQTT2_Server mal das LogLevel auf verbose 5 gestellt und bekomme im Logfile dann auch (mehrfache) Meldungen, wenn ein Melder ausgelöst hat:

Code Auswählen Erweitern


2020.06.09 23:24:12 5: in:  PUBLISH: 0(201)(1)(0)(27)msh/d_mk6_balkontuer_og_211{"mac": "907065F2E9A1", "source": "13-derpi3", "details": "close", "value": 0, "rssivalue": -99.0, "timestampRT": 1591737852386, "type": 4, "name": "MK6_Balkontuer_OG_211"}
2020.06.09 23:24:12 4:   myBroker_192.168.66.13_38509  PUBLISH msh/d_mk6_balkontuer_og_211:{"mac": "907065F2E9A1", "source": "13-derpi3", "details": "close", "value": 0, "rssivalue": -99.0, "timestampRT": 1591737852386, "type": 4, "name": "MK6_Balkontuer_OG_211"}
2020.06.09 23:24:12 5:   myBroker_192.168.66.33_60025 ecf87a177bbe4e3f9b9d8f92f030000e => msh/d_mk6_balkontuer_og_211:{"mac": "907065F2E9A1", "source": "13-derpi3", "details": "close", "value": 0, "rssivalue": -99.0, "timestampRT": 1591737852386, "type": 4, "name": "MK6_Balkontuer_OG_211"}
2020.06.09 23:24:12 5: out: PUBLISH: 0(201)(1)(0)(27)msh/d_mk6_balkontuer_og_211{"mac": "907065F2E9A1", "source": "13-derpi3", "details": "close", "value": 0, "rssivalue": -99.0, "timestampRT": 1591737852386, "type": 4, "name": "MK6_Balkontuer_OG_211"}
2020.06.09 23:24:12 5: myBroker: dispatch autocreate=complex\000\000msh/d_mk6_balkontuer_og_211\000{"mac": "907065F2E9A1", "source": "13-derpi3", "details": "close", "value": 0, "rssivalue": -99.0, "timestampRT": 1591737852386, "type": 4, "name": "MK6_Balkontuer_OG_211"}
2020.06.09 23:24:12 2: autocreate: define MQTT2_msh_mk6_balkontuer_og_211___mac____907065F2E9A1____source____13_derpi3____details____close____value___0___rssivalue____99.0___timestampRT___1591737852386___type___4___name_ MQTT2_DEVICE msh_mk6_balkontuer_og_211:{"mac": "907065F2E9A1", "source": "13-derpi3", "details": "close", "value": 0, "rssivalue": -99.0, "timestampRT": 1591737852386, "type": 4, "name" myBroker
2020.06.09 23:24:12 1: define MQTT2_msh_mk6_balkontuer_og_211___mac____907065F2E9A1____source____13_derpi3____details____close____value___0___rssivalue____99.0___timestampRT___1591737852386___type___4___name_ MQTT2_DEVICE msh_mk6_balkontuer_og_211:{"mac": "907065F2E9A1", "source": "13-derpi3", "details": "close", "value": 0, "rssivalue": -99.0, "timestampRT": 1591737852386, "type": 4, "name" myBroker: wrong syntax for MQTT2_msh_mk6_balkontuer_og_211___mac____907065F2E9A1____source____13_derpi3____details____close____value___0___rssivalue____99.0___timestampRT___1591737852386___type___4___name_: define <name> MQTT2_DEVICE [clientid]
2020.06.09 23:24:12 1: ERROR: wrong syntax for MQTT2_msh_mk6_balkontuer_og_211___mac____907065F2E9A1____source____13_derpi3____details____close____value___0___rssivalue____99.0___timestampRT___1591737852386___type___4___name_: define <name> MQTT2_DEVICE [clientid]
2020.06.09 23:24:12 5: in:  DISCONNECT: (224)(0)
2020.06.09 23:24:12 4:   myBroker_192.168.66.13_38509  DISCONNECT


Auch wird im Logfile registriert, wenn andere Geräte (IP 192.168.66.33 ist mein Laptop auf dem MQTT.fx mitläuft) auf den MQTT2_Server zugriefen (auf MQTT.fx -> Subscride ->subsride to all recent topics). Es werden alle bekannten Geräte angezeigt:

Code Auswählen Erweitern


2020.06.09 23:18:31 5: in:  SUBSCRIBE: (130)(26)(0)(1)(0)(21)msh/d_bm1_og_flur_220(0)
2020.06.09 23:18:31 4:   myBroker_192.168.66.33_60025 ecf87a177bbe4e3f9b9d8f92f030000e SUBSCRIBE
2020.06.09 23:18:31 4:   topic:msh/d_bm1_og_flur_220 qos:0
2020.06.09 23:18:31 5: out: SUBACK: (144)(3)(0)(1)(1)
2020.06.09 23:18:31 5: in:  SUBSCRIBE: (130)(27)(0)(2)(0)(22)msh/d_bm2_eg_essen_918(0)
2020.06.09 23:18:31 4:   myBroker_192.168.66.33_60025 ecf87a177bbe4e3f9b9d8f92f030000e SUBSCRIBE
2020.06.09 23:18:31 4:   topic:msh/d_bm2_eg_essen_918 qos:0
2020.06.09 23:18:31 5: out: SUBACK: (144)(3)(0)(2)(1)
2020.06.09 23:18:31 5: in:  SUBSCRIBE: (130)(28)(0)(3)(0)(23)msh/d_bm3_eg_treppe_192(0)
2020.06.09 23:18:31 4:   myBroker_192.168.66.33_60025 ecf87a177bbe4e3f9b9d8f92f030000e SUBSCRIBE
2020.06.09 23:18:31 4:   topic:msh/d_bm3_eg_treppe_192 qos:0
2020.06.09 23:18:31 5: out: SUBACK: (144)(3)(0)(3)(1)
2020.06.09 23:18:31 5: in:  SUBSCRIBE: (130)(29)(0)(4)(0)(24)msh/d_bm4_wohnzimmer_293(0)
2020.06.09 23:18:31 4:   myBroker_192.168.66.33_60025 ecf87a177bbe4e3f9b9d8f92f030000e SUBSCRIBE
2020.06.09 23:18:31 4:   topic:msh/d_bm4_wohnzimmer_293 qos:0
2020.06.09 23:18:31 5: out: SUBACK: (144)(3)(0)(4)(1)
2020.06.09 23:18:31 5: in:  SUBSCRIBE: (130)(30)(0)(5)(0)(25)msh/d_bm5_flur_keller_117(0)
2020.06.09 23:18:31 4:   myBroker_192.168.66.33_60025 ecf87a177bbe4e3f9b9d8f92f030000e SUBSCRIBE
2020.06.09 23:18:31 4:   topic:msh/d_bm5_flur_keller_117 qos:0
2020.06.09 23:18:31 5: out: SUBACK: (144)(3)(0)(5)(1)
2020.06.09 23:18:31 5: in:  SUBSCRIBE: (130)!(0)(6)(0)(28)msh/d_mk1_wohnz_terrasse_524(0)
2020.06.09 23:18:31 4:   myBroker_192.168.66.33_60025 ecf87a177bbe4e3f9b9d8f92f030000e SUBSCRIBE
2020.06.09 23:18:31 4:   topic:msh/d_mk1_wohnz_terrasse_524 qos:0
2020.06.09 23:18:31 5: out: SUBACK: (144)(3)(0)(6)(1)
2020.06.09 23:18:31 5: in:  SUBSCRIBE: (130)!(0)(7)(0)(28)msh/d_mk2_diele_terrasse_126(0)
2020.06.09 23:18:31 4:   myBroker_192.168.66.33_60025 ecf87a177bbe4e3f9b9d8f92f030000e SUBSCRIBE
2020.06.09 23:18:31 4:   topic:msh/d_mk2_diele_terrasse_126 qos:0
2020.06.09 23:18:31 5: out: SUBACK: (144)(3)(0)(7)(1)
2020.06.09 23:18:31 5: in:  SUBSCRIBE: (130)$(0)(8)(0)(31)msh/d_mk3_wohn_wintergarten_579(0)
2020.06.09 23:18:31 4:   myBroker_192.168.66.33_60025 ecf87a177bbe4e3f9b9d8f92f030000e SUBSCRIBE
2020.06.09 23:18:31 4:   topic:msh/d_mk3_wohn_wintergarten_579 qos:0
2020.06.09 23:18:31 5: out: SUBACK: (144)(3)(0)(8)(1)
2020.06.09 23:18:31 5: in:  SUBSCRIBE: (130) (0)(9)(0)(27)msh/d_mk6_balkontuer_og_211(0)
2020.06.09 23:18:31 4:   myBroker_192.168.66.33_60025 ecf87a177bbe4e3f9b9d8f92f030000e SUBSCRIBE
2020.06.09 23:18:31 4:   topic:msh/d_mk6_balkontuer_og_211 qos:0
2020.06.09 23:18:31 5: out: SUBACK: (144)(3)(0)(9)(1)
2020.06.09 23:18:31 5: in:  SUBSCRIBE: (130)(30)(0)(10)(0)(25)msh/d_mk7_moni_atelier_ug(0)
2020.06.09 23:18:31 4:   myBroker_192.168.66.33_60025 ecf87a177bbe4e3f9b9d8f92f030000e SUBSCRIBE
2020.06.09 23:18:31 4:   topic:msh/d_mk7_moni_atelier_ug qos:0
2020.06.09 23:18:31 5: out: SUBACK: (144)(3)(0)(10)(1)
2020.06.09 23:18:31 5: in:  SUBSCRIBE: (130)(31)(0)(11)(0)(26)msh/d_mk8_wohnungstuer_541(0)
2020.06.09 23:18:31 4:   myBroker_192.168.66.33_60025 ecf87a177bbe4e3f9b9d8f92f030000e SUBSCRIBE
2020.06.09 23:18:31 4:   topic:msh/d_mk8_wohnungstuer_541 qos:0
2020.06.09 23:18:31 5: out: SUBACK: (144)(3)(0)(11)(1)


Da mir ja die Namen der Geräte/Melder die ich in Fhem benötige bekannt sind, könnte es doch eventuell auch möglich sein, diese einzeln / als Liste für die entsprechenden Attribute einzugeben.
Dann wäre das ganze zwar nicht mehr dynamisch aber vielleicht bekäme man dann zumindest erst einmal eine Anzeige in Fhem und wäre einen Schritt weiter?

Wünsche noch einen schönen abend

deeb

[Beta-User]

Moin.

Sicher, man kann das auch manuell machen mit dem vereinzeln. Mein persönlicher Anspruch ist es aber eher, allen potentiellen Usern eine universelle Lösung anzubieten..

Daher beschäfigen wir uns m.E. besser mit der bridgeRegexp. Versuch's mal so:

Code Auswählen Erweitern

attr MEDION_Alarm bridgeRegexp msh/d_([^/:]+):.* "msh_$1"

Falls das nicht klappt: Was ich eigentlich bräuchte, wäre der MQTT-Roh-Datenverkehr. Du kannst das auch selbst weiterentwickeln, indem du die Messages, die via rawEvent-Attribut (.*) im Event-Monitor sichtbar gemacht werden können, in einen der Internet-Parser schickst, z.B. regexr.com.

Und laß' die readingList mal weg.

[deeb]

Hallo Beta-User,

dein Änderungsvorschlag für das Attribut bridgeRegxp war der richtige Hinweis. D a n k e ! Ich habe dies dann auch noch für die readingList übernommen und nun läuft alles, so wie gewollt.

Code Auswählen Erweitern


##############################################################################
# Variante 1 mit fhem eigenen MQTT2_Server;

define fehm_mqtt2 MQTT2_SERVER 1883 global
setuuid fehm_mqtt2 5edfd763-f33f-d326-7784-01028f19965187d3
attr fehm_mqtt2 autocreate complex
attr fehm_mqtt2 room MQTT2_DEVICE

define MEDION_Alarm MQTT2_DEVICE msh
setuuid MEDION_Alarm 5ede8b9d-f33f-d326-048e-f27c3a91eb37e1c0
attr MEDION_Alarm IODev fehm_mqtt2
attr MEDION_Alarm bridgeRegexp msh/d_([^/:]+):.* "msh_$1"
attr MEDION_Alarm icon mqtt_bridge_2
attr MEDION_Alarm readingList msh/([^d][^/]):.* {json2nameValue($EVENT,''$JSONMAP)}
attr MEDION_Alarm room MQTT2_DEVICE


Die Devices werden dann automatisch generiert/angelegt  (Bespiel für einen Bewegungsmelder):

Code Auswählen Erweitern


define MQTT2_msh_bm1_og_flur_220 MQTT2_DEVICE msh_bm1_og_flur_220
setuuid MQTT2_msh_bm1_og_flur_220 5ee102b1-f33f-d326-faeb-a47ef503992d33b5
attr MQTT2_msh_bm1_og_flur_220 IODev fehm_mqtt2
attr MQTT2_msh_bm1_og_flur_220 readingList msh/d_bm1_og_flur_220:.* { json2nameValue($EVENT, 'd_bm1_og_flur_220_', $JSONMAP) }
attr MQTT2_msh_bm1_og_flur_220 room MQTT2_DEVICE
define FileLog_MQTT2_msh_bm1_og_flur_220 FileLog ./log/MQTT2_msh_bm1_og_flur_220-%Y.log MQTT2_msh_bm1_og_flur_220
setuuid FileLog_MQTT2_msh_bm1_og_flur_220 5ee102b1-f33f-d326-8dd5-422c3131ac452521
attr FileLog_MQTT2_msh_bm1_og_flur_220 logtype text
attr FileLog_MQTT2_msh_bm1_og_flur_220 room MQTT2_DEVICE


Bei alternativer Verwendung eines externen MQTT Servers:

Code Auswählen Erweitern


###################################################################################
#Variante 2 mit externen Mosquitto-Server;

define deMqtt MQTT2_CLIENT 192.168.66.14:1883
setuuid deMqtt 5ee01805-f33f-d326-b60e-ed5e160330d31493
attr deMqtt autocreate complex
attr deMqtt clientId deMqtt
attr deMqtt room MQTT2_DEVICE

# Hinweis: mit den o.g. drei Zeilen für den MQTT2_Client werden die nachfolgenden Zeilen
#          (ein Device und ein gemeinsames FileLog für alle Melder) vom System automatisch
#          generiert, aber keine Einzeldevices! 
define MQTT2_deMqtt MQTT2_DEVICE deMqtt
setuuid MQTT2_deMqtt 5ee11bc3-f33f-d326-d2ca-84e4a9f3833f9205
attr MQTT2_deMqtt IODev deMqtt
attr MQTT2_deMqtt room MQTT2_DEVICE

define FileLog_MQTT2_deMqtt FileLog ./log/MQTT2_deMqtt-%Y.log MQTT2_deMqtt
setuuid FileLog_MQTT2_deMqtt 5ee11bc3-f33f-d326-6725-746b72e2627df7a3
attr FileLog_MQTT2_deMqtt logtype text
attr FileLog_MQTT2_deMqtt room MQTT2_DEVICE


Man brauch nur den MQTT2_CLIENT (erster Codeblock) definieren und der zweite Block mit dem MQTT2_deMqtt Device wird dann auch automatisch vom System generiert.
In diesem werden in der ReadingsList alle vorhandenen Melder angezeigt/aufgelistet, sofern diese einmal ausgelöst haben.
Die einzelnen Devices für jeden Melder werden nicht automatisch vom System generiert.
Sofern man jedoch noch das Coding von der ersten Variante mit den fhem MQTT2_SERVER hat (ich hatte es nur auskommentiert) kann man dieses dann auch für diese 2.Variante benutzen.
Der Bezug/ das Attribut "IODev" wird beim abspeichern automatisch geändert ( "fehm_mqtt2" -> "deMqtt"):

Code Auswählen Erweitern


define MQTT2_msh_bm1_og_flur_220 MQTT2_DEVICE msh_bm1_og_flur_220
setuuid MQTT2_msh_bm1_og_flur_220 5ee102b1-f33f-d326-faeb-a47ef503992d33b5
attr MQTT2_msh_bm1_og_flur_220 IODev deMqtt
attr MQTT2_msh_bm1_og_flur_220 readingList msh/d_bm1_og_flur_220:.* { json2nameValue($EVENT, 'd_bm1_og_flur_220_', $JSONMAP) }
attr MQTT2_msh_bm1_og_flur_220 room MQTT2_DEVICE
define FileLog_MQTT2_msh_bm1_og_flur_220 FileLog ./log/MQTT2_msh_bm1_og_flur_220-%Y.log MQTT2_msh_bm1_og_flur_220
setuuid FileLog_MQTT2_msh_bm1_og_flur_220 5ee102b1-f33f-d326-8dd5-422c3131ac452521
attr FileLog_MQTT2_msh_bm1_og_flur_220 logtype text
attr FileLog_MQTT2_msh_bm1_og_flur_220 room MQTT2_DEVICE


Um die Readings für jedes Device angezeigt zu bekommen, muss der entsprechende Melder einmal ausgelöst haben:

Code Auswählen Erweitern


Readings
d_bm2_eg_essen_918_details   move   2020-06-10 22:44:24
d_bm2_eg_essen_918_mac   3CAAAAAAAAAA   2020-06-10 22:44:24
d_bm2_eg_essen_918_name   BM2_EG_Essen_918   2020-06-10 22:44:24
d_bm2_eg_essen_918_rssivalue   -71.0   2020-06-10 22:44:24
d_bm2_eg_essen_918_source   13-derpi3   2020-06-10 22:44:24
d_bm2_eg_essen_918_timestampRT   1591821864309   2020-06-10 22:44:24
d_bm2_eg_essen_918_type   10   2020-06-10 22:44:24
d_bm2_eg_essen_918_value   2675   2020-06-10 22:44:24



Das wäre noch verbesserungswürdig:

In den LogFiles werden für jedes Ereignis die gleichen Einträge mehrfach (3 bis 4 mal) mit der selben Uhrzeit aber einen anderen/unterschiedlichen "timestampRT" (sicherlich mit Millisekunden) eingetragen. 
Frage 1 : Lässt sich die Übertragung dieses Feldes "timestampRT" von den MQTT Server nach fhem unterdrücken? Dann werden vermutlich die Einträge nur einmal ins Log geschrieben.

Im Logfile werden alle Readings jeweils in eine neue Zeile geschrieben. Besser/Übersichtlicher wäre es wenn für jedes Ereignis nur eine Zeile mit der Aufzählung aller Readings erscheinen würde.
Frage 2 : Geht das ohne zusätzlich durch andere Abfragen/Coding und für das Ergebnis dann ein zweites Logfile zu schreiben?

Für den Status jedes Divices werden drei Fragezeichen angezeigt.
Frage 3: Kann man schon während der Übertragung den Feldinhalt eines Readings  (beim Magnetkontakt z.B. "details" -> open/close) auf den Status des Devices mappen?

Die nächste Aufgabe wäre es nun, noch die Signale der anderen MEDION-Melder (Funkstecker, Alarmzentrale, Fernbedienung, Aussensirene usw.) auszuwerten und für den MQTT-Server bereit zu stellen.
Dafür muss ich mich aber erst mal mit Python3 beschäftigen (https://gitlab.com/shd290/mshtools/-/blob/master/README.md)

MfG
deeb

[Beta-User]

Vorab: das cfg-editieren nervt mich gewaltig. Bitte sei einfach so freundlich, hier nur "list -r"-Ausgaben zu posten.
Es geht auch nicht darum, dass das für dich unfallfrei funktioniert, sondern darum, dass andere das nicht unfallfrei hinbekommen und es gleich nach heutigem Stand der Dinge richtig lernen sollen. Daher widerstrebt es mir wirklich, hier ein (in diesem Sinne) schlechtes Beispiel zu supporten (andere kompetente Helfer sind sofort raus, wenn cfg-Edits im Spiel sind, btw...).


Das IO auf "complex" zu stellen, entspricht auch nicht meiner üblichen Arbeitsweise, das macht in der Regel nur die Readingnamen unnötig kompliziert/lang. Wenn wir Präfix oder $JSONMAP brauchen, werde ich dann schon darauf hinweisen .

Die "übliche Vorgehensweise" findet sich in Ansätzen in "meinen" MQTT-Wiki-Artikeln, am besten du überfliegst wenigstens die "Praxisbeispiele" mal...

Das wäre noch verbesserungswürdig:

In den LogFiles werden für jedes Ereignis die gleichen Einträge mehrfach (3 bis 4 mal) mit der selben Uhrzeit aber einen anderen/unterschiedlichen "timestampRT" (sicherlich mit Millisekunden) eingetragen. 
Frage 1 : Lässt sich die Übertragung dieses Feldes "timestampRT" von den MQTT Server nach fhem unterdrücken? Dann werden vermutlich die Einträge nur einmal ins Log geschrieben.

Die korrekte Antwort wäre auf der Sende-Seite zu verorten. MMn. macht das Senden des timestamps wenig Sinn, wir bilden auf der FHEM-Seite sowieso einen. Das könnte man höchstens vergleichen, was aber m.E. eine Art "Expertenmodus" wäre. Würde also empfehlen, das auf der script-Seite deaktivierbar zu machen. Wenn kurz nacheinander mehrere Timestamps kommen, ist dem Gefühl nach was auf der Sendeseite "faul". Man sollte dort konsolidieren, was gesendet werden soll und dann einmal senden, nicht irgendwelche Zwischenzustände (danach klingt es).

In FHEM können wir diese Nachrichten verwerfen, Details dazu in jsonMap (bitte aber erst lösen nachdem wir geklärt haben, ob wir ein Präfix brauchen).

Im Logfile werden alle Readings jeweils in eine neue Zeile geschrieben. Besser/Übersichtlicher wäre es wenn für jedes Ereignis nur eine Zeile mit der Aufzählung aller Readings erscheinen würde.
Frage 2 : Geht das ohne zusätzlich durch andere Abfragen/Coding und für das Ergebnis dann ein zweites Logfile zu schreiben?

Was du loggst, ist a) eine Frage der regex im FileLog-Gerät und b) eine Frage, welche Readings wir erzeugen. Den JSON kann man auch zusätzlich in ein eigenes Reading verfrachten. Da du nach eigener Aussage kein Anfänger bist, gehe ich davon aus, dass du a) ohne weiteres selbst lösen kannst und bei b) der Hinweis reicht, dass wir das z.B. im attrTemplate zum Tasmota-RF so machen.

Für den Status jedes Divices werden drei Fragezeichen angezeigt.
Frage 3: Kann man schon während der Übertragung den Feldinhalt eines Readings  (beim Magnetkontakt z.B. "details" -> open/close) auf den Status des Devices mappen?

Die nächste Aufgabe wäre es nun, noch die Signale der anderen MEDION-Melder (Funkstecker, Alarmzentrale, Fernbedienung, Aussensirene usw.) auszuwerten und für den MQTT-Server bereit zu stellen.

Schau mal in die templates zu den anderen "bridge"-Varianten. Da wird häufig genau das gemacht, dass entweder state geschrieben wird oder ein stateFormat gesetzt.
Dein setup ist m.E. ziemlich nahe an dem, was OpenMQTTGateway macht, da findest du also in den attrTemplates die passenden Bauteilchen.