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
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
Da gruselts mich mal wieder. Alarmanlagendaten in der Cloud. :o
Da Du bereits mit mqtt.fx empfängst, kannst Du Dir ein mqtt2-client-device anlegen. Weiteres sollte dann per autocreate relativ einfach gehen.
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
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
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
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
ZitatFuer 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:
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:
deleteattr MQTT2_deMQTT2_Client readingListJetzt 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...
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
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
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.
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:
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
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):
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
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
Hallo Beta-User
ich habe noch mal eine Frage zu deinen Code-Vorschlag von gestern:
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:
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:
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
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:
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.
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.
##############################################################################
# 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):
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:
###################################################################################
#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"):
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:
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
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...
Zitat von: deeb am 11 Juni 2020, 00:04:04
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).
ZitatIm 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.
ZitatFü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.
Hallo Beta-User,
danke für deine Geduld mit mir. "list -r" habe ich jetzt auch verinnerlicht! Der Unterschied mit den langen Readingsnamen ist mir beim Testen nicht aufgefallen. Habe ich jetzt umgestellt.
zu Frage 1:
Habe ich jetzt auf der Sende-Seite umgestellt. Alle "timestampRT"-Bezüge gelöscht. Auch mit MQTT.fx werden diese nicht mehr angezeigt und ich habe jetzt auch weniger Ereignisse/Logfileeinträge (nur noch 2 statt 4-6 pro Ereignis).
zu Frage 2:
Alle überflüssigen, sich wiederholende Zeilen habe ich jetzt mit dem Attribut "ignoreRegexp" aus dem LogFile verbannt.
zu Frage 3:
Durch das Attribut "stateFormat" bekomme ich jetzt den/einen Status angezeigt:
define MQTT2_msh_mk6_balkontuer_og_211 MQTT2_DEVICE msh_mk6_balkontuer_og_211
attr MQTT2_msh_mk6_balkontuer_og_211 IODev fehm_mqtt2
attr MQTT2_msh_mk6_balkontuer_og_211 readingList msh/d_mk6_balkontuer_og_211:.* { json2nameValue($EVENT) }
attr MQTT2_msh_mk6_balkontuer_og_211 room MQTT2_DEVICE
attr MQTT2_msh_mk6_balkontuer_og_211 stateFormat { ReadingsVal($name, "details", "") }
setstate MQTT2_msh_mk6_balkontuer_og_211 opena
setstate MQTT2_msh_mk6_balkontuer_og_211 2020-06-12 19:12:30 associatedWith MEDION_Alarm
setstate MQTT2_msh_mk6_balkontuer_og_211 2020-06-13 00:01:54 details opena
setstate MQTT2_msh_mk6_balkontuer_og_211 2020-06-13 00:01:54 mac 907065F2E9A1
setstate MQTT2_msh_mk6_balkontuer_og_211 2020-06-13 00:01:54 name MK6_Balkontuer_OG_211
setstate MQTT2_msh_mk6_balkontuer_og_211 2020-06-13 00:01:54 rssivalue -92.0
setstate MQTT2_msh_mk6_balkontuer_og_211 2020-06-13 00:01:54 source 13-derpi3
setstate MQTT2_msh_mk6_balkontuer_og_211 2020-06-13 00:01:54 type 4
setstate MQTT2_msh_mk6_balkontuer_og_211 2020-06-13 00:01:54 value 1
Leider aktualisiert sich der Status aber nicht in der WEB-Anzeige, wenn sich der das Status für das Device ändert, d.h. es wird immer der Status angezeigt, der beim öffnen des Fensters gerade aktuell war. Mit den Attribut "event-on-change-reading" konnte ich das auch nicht verbessern (falscher Aufruf?).
Auf der "Sende-Seite" habe ich jetzt noch weitere Geräte (Alarmzentrale, Funksteckdose, Fernbedienung, Außensignal) versucht einzubinden. Ist mir bisher aber nur für das Außensignal gelungen.
Dort könnte ich jetzt noch versuchen einen Alarm durch einen MQTT-Publish-Befehl auszulösen. Ist natürlich nicht so wichtig wie z.B. das Schalten der Funksteckdose oder die Funktionen der Fernbedienung. Dazu habe ich schon den Author der Python msh-Tools angeschrieben. Würde noch gern 2/3 Wochen abwarten ob er antwortet bzw. reagiert. Ansonsten könnten wir hier dieses Thema aus meiner Sicht erstmal schließen oder wäre es besser, nochmal den finalen Code zu posten?
Nochmals viele Dank für alle Hilfestellungen und Hinweise!!!!!!!!
MfG
deeb
Vielleicht noch ein paar Hinweise vorab:
attr MQTT2_msh_mk6_balkontuer_og_211 stateFormat { ReadingsVal($name, "details", "") }
müßte auch so geschrieben werden können:
attr MQTT2_msh_mk6_balkontuer_og_211 stateFormat detailsWenn wir doch $JSONMAP verwenden würden, wäre das auch ohne stateFormat machbar:
attr MQTT2_msh_mk6_balkontuer_og_211 readingList msh/d_mk6_balkontuer_og_211:.* { json2nameValue($EVENT,'',$JSONMAP) }attr MQTT2_msh_mk6_balkontuer_og_211 jsonMap details:state
Hier würde ich aber eher das komische "opena" in was gängigeres übersetzen. Falls es nicht im Script geht, ginge das z.B. via stateFormat (ungetestet):
attr MQTT2_msh_mk6_balkontuer_og_211 stateFormat { my $value= ReadingsVal($name, "details", ""); $value eq "opena" ? "tilted" : $value eq "openb" ? "open" : "closed" }(Kann man ähnlich auch als userReadings-Eintrag in state schreiben).
Dass "ständig alles" gesendet wird, halte ich für einen Designfehler: Alles außer dem Öffnungszustand und dem RSSI-Wert ist doch statisch? Sendet man bestenfalls einmalig beim "Bekanntmachen" (ggf. über einen anderen Topic-Branch)...
Wegen des Sendens von Kommandos müßte man halt wissen, was auf welchen Topic geschubst werden muß.
Hallo zusammen,
lese hier interessiert mit, da ich auch mal mit FHEM starten möchte und auch die genannte Alarmanlage im Einsatz habe. Gibt es mittlerweile eine "Anleitung", was zum EInbinden der Anlage in FHEM zu tun ist? Gerne für einen Anfänger...
Vielen Dank für die Hilfe.
Gruß
Marco
Hallo Marco,
bin zur Zeit auch wieder auf dieser Baustelle unterwegs. Bereits 2018 gab es eine Anfrage zur Kopplung der Aldi/Medion Alarmanlage mit Fhem:
Wenn du diese Medion-Alarmanlage hast, wäre es der erste Schritt, das du die Bluetooth Kommunikation zwischen den Meldern und der Zentrale auswerten/ nutzen kannst.
Zur Zeit funktionieren bei mir die Magnetkontakte, die Bewegungsmelder und die Alarmsirene. Weiterhin sollen auch die Rauchmelder funktionieren, habe ich aber nicht im Einsatz.
Ich nutze dafür bei mir zwei Raspi. Auf einem (Raspi4) läuft neben NextCloud u.a. auch FHEM und auf den anderen Raspi 3b ein MQTT Server.
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
Wenn du mit diesen Anleitungen über das Windowsprogramm MQTT.fx die BT-Kommunikation mitlesen kannst bist du schon bald am Ziel (geschätzte 60-70%).
Der letzte Schritt ist dann die Einbindung in FHEM. Dann eröffnen sich dir viele neue Möglichkeiten. Z.B. kannst du dann mit den Medion-Bewegungsmeldern auch andere Verbraucher schalten und bewegst dich nicht mehr nur im Medion-Universum.
Wenn es irgendwo klemmt auf dem Wege, dann melde dich gern nochmal. Eine komplette Anleitung für die FHEM-Installation + Medion Einbindung gibt es eines Wissens nach nicht.
VG und bleibt gesund
DEEB
Zitat von: deeb am 10 Februar 2021, 19:55:42
[...] und die Daten an einen MQTT-Server weiterleiten.
[...] Wenn du mit diesen Anleitungen über das Windowsprogramm MQTT.fx die BT-Kommunikation mitlesen kannst bist du schon bald am Ziel (geschätzte 60-70%).
Wenn du dafür gleich einen MQTT2_SERVER nutzt, solltest du die Daten direkt in FHEM sehen. Dann ist es "nur" eine Frage der Aufbereitung in FHEM. Sollte aber über ein spezielles "Sortierdevice" (Stichwort: bridgeRegexp) kein Problem sein, dass vollends aufzubereiten...
ZitatDer letzte Schritt ist dann die Einbindung in FHEM.
...würde also empfehlen, gleich die "Abkürzung" zu nehmen, dann kommst du direkt von der Aktivierung der beiden Python-Scripte nach FHEM...
Hallo zusammen,
seit 2 Tagen läuft nun mein RP4 mit FHEM und ich wollte mich nun mal dem "Projekt" Medion zuwenden. Das Script zum Auslesen der Geräte habe ich manuell ausgeführt. In der JSON-Datei sind alle meine Geräte enthalten. Das BLE-Script habe ich nicht ausgeführt, weil das ja im Standard mit dem MQTT kommuniziert und ich mir den "Umweg" sparen möchte, um die Daten in FHEM zu haben.
- Wie macht man es in FHEM, dass diese Scripte automatisiert ablaufen?
- Wie bekomme ich die Kommunikation mit dem MQTT2 des FHEM hin?
VG
Marco
Die scripte sind extern, von daher würde ich dazu tendieren, die auch extern zu starten (z.B. indem du eine entsprechende service-Datei für systemd erstellst).
Dann wäre "ganz normal" ein MQTT2_SERVER zu definieren, und an den dann die Daten vom script aus zu publishen (wenn auf demselben Rechner: an localhost):
define m2server MQTT2_SERVER 1883 global
Danach die Anleitung mit der bridgeRegexp wie von deeb am 11.06. gepostet.
Da muss ich wohl zu meinem 2-tägigen Wissen noch Einiges lernen :-( ... Habe gelesen, dass man das eine Script nur zum einmaligen Auslesen der Geräte benötigt. Wer lesen kann...
- Habe die Scripte nach /home/pi/code/ kopiert.
- Dann habe ich mir eine CheckBLE.service mit folgendem Inhalt gebastet:
[Unit]
Description=Check BLE
[Service]
Type=simple
ExecStart=/home/pi/code/SH_CheckBLE.py
[Install]
WantedBy=multi-user.target
- Kann ich in der SH_CheckBLE.py die Parameter, die übergeben werden, direkt schreiben ("-n -mqtt2 192.168.0.110") oder in der Service hinter den Script-Namen?
- Wie wird die Service-Datei nun regelmäßig ausgeführt?
- Brauche ich das SH_Lib.py, welches mitgeliefert wird (https://gitlab.com/shd290/mshtools/-/blob/master/README.md) auch?
Vielleicht bekommen wir es hin, dass aus dem Thread eine Anleitung für alle entstehen kann.
Viele Grüße
Marco
Direkt die py ändern finde ich keine so glorreiche Idee: Was machst du beim nächsten update...?
In der .service müsste es möglich sein, den Aufruf beliebig anzupassen. Dann mußt du noch dafür sorgen, dass das sauber eingebunden ist, Hilfe dazu sollte bei Ubuntuusers zu finden sein, z.B. https://wiki.ubuntuusers.de/Howto/systemd_Service_Unit_Beispiel/
Bitte keine zu detaillierten Anleitungen für sowas ins Wiki stellen, das veraltet gerne und dann fühlt sich keiner mehr zuständig. Wer "sowas" haben will, sollte sich mit dem Stichwort "systemd" eigentlich die notwendigen Infos beschaffen können, um das dann auch automatisch zu starten (die File selbst ist aber ggf. was anderes...).
ok. Schaue ich mir an...
Mein erstes Ziel, die Scripte lokal manuell aufzurufen mit Ergebnissen hat schon einmal geklappt.
Habe mir das Script, welches die regelmäßige Abfrage der Geräte macht, mal angesehen. Leider steht dort fest MQTT drin. Geht das dann mit dem MQTT2 von FHEM gar nicht?
import time
import json
import argparse
import os
import subprocess
import paho.mqtt.publish as publish
import paho.mqtt.subscribe as subscribe
import threading
import re
from bluepy import btle
from SH_Lib import DecryptBLE, EncryptBLE, EncryptSD
import warnings
warnings.filterwarnings("ignore")
dictKeys = {}
dictNames = {}
dictType = {}
dictRXCount = {}
dictRXLevel = {}
dictLast = {}
listSD = []
DictBuffer = []
startfound = 0
endfound = 0
datafound = 0
debuginfo = False
usemqtt = False
cputs = 0
process_hcitool = None
process_btmon = None
process_started = False
alarmList = []
raspiname = "unusedName"
stopProcess = False
sdMac = ""
sdStart = False
hostadr = ""
def checkSubscribeMSGs():
global stopProcess, raspiname, listSD, sdMac, sdStart, hostadr, debuginfo
while (not stopProcess):
try:
msg = subscribe.simple("msh/{0}/ctrl".format(raspiname), qos=0, msg_count=1, retained=False, hostname="{0}".format(hostadr))
msg = msg.payload.decode()
if debuginfo:
print(msg)
msg_dict = json.loads(msg)
if msg_dict['cmd'] == 'SD':
if msg_dict['mac'].upper() in listSD:
sdMac = msg_dict['mac'].upper()
sdStart = True
if msg_dict['cmd'] == 'stopProcess':
stopProcess = True
except:
pass
print('Subscribe thread finished')
def processSDrequests():
global sdMac, sdStart, process_started, process_btmon, process_hcitool
if sdStart:
sdStart = False
if process_started:
process_started = False
process_btmon.kill()
process_hcitool.kill()
time.sleep(0.2)
alarmSD(sdMac)
def alarmSD(mac):
global dictKeys, debuginfo
try:
key = dictKeys[mac]
if debuginfo:
print('Alarm')
device = btle.Peripheral(None, addrType=btle.ADDR_TYPE_PUBLIC)
physmac = mac[0:2]+':'+mac[2:4]+':'+mac[4:6]+':'+mac[6:8]+':'+mac[8:10]+':'+mac[10:12]
device.connect(physmac)
readValue = device.readCharacteristic(0x12)
readValue = readValue.hex()[8:]
message = DecryptBLE(readValue.upper(), key, mac)
message = EncryptSD(message, key, mac)
device.writeCharacteristic(0x12, bytearray.fromhex(message), withResponse=True)
readValue = device.readCharacteristic(0x12)
readValue = readValue.hex()[8:]
device.writeCharacteristic(0x21, bytearray.fromhex('0300'), withResponse=True)
device.disconnect()
time.sleep(0.2)
except:
pass
def cputemp():
temp = 0
try:
f = open('/sys/class/thermal/thermal_zone0/temp','r')
for line in f:
temp = int(line)
break
f.close()
except:
temp = 0
return temp*1.0/1000.0
parser = argparse.ArgumentParser()
parser.add_argument("-mqtt", help="mqtt hostname e.g. user@192.168.3.27 follows by -pw or only 192.168.3.27 without pw", type=str)
parser.add_argument("-password", help="mqtt password", type=str)
parser.add_argument('-d', help="print some debug infos", action='store_true')
parser.add_argument('-n', help="set the name of raspberry pi in sensor information", type=str)
args = parser.parse_args()
if args.mqtt and not args.password:
if '@' in args.mqtt:
print(args.mqtt)
print('password is missing')
exit(0)
if args.n:
raspiname = str(args.n)
if args.mqtt:
usemqtt = True
if args.d:
debuginfo = True
auth = None
if usemqtt:
hostadr = args.mqtt
if '@' in args.mqtt:
auth = dict(username=args.mqtt('@')[0], password= args.password)
hostadr = args.mqtt('@')[1]
if debuginfo:
print('CPU Temp: {0}'.format(cputemp()))
adr = '1BSv43wsjcX7C6xfzxnDSV8coCxRAVKrgf'
try:
with open('smarthome.json', 'r') as f:
distros_dict = json.load(f)
for i in range(len(distros_dict)):
if distros_dict[i]['DataDeviceType'] == 10 or distros_dict[i]['DataDeviceType'] == 7 or distros_dict[i]['DataDeviceType'] == 4:
mac = distros_dict[i]['name']
dictKeys[mac] = distros_dict[i]['key']
dictNames[mac] = re.sub('[^A-Za-z0-9_]+', '_', distros_dict[i]['DeviceName']) # get clean name
dictType[mac] = distros_dict[i]['DataDeviceType']
if distros_dict[i]['DataDeviceType'] == 7:
listSD.append(mac.upper())
except:
print('error reading smarthome.json')
exit(0)
if len(dictKeys) == 0:
print('error no sensors found')
exit(0)
print('Willkommen bei den MSH Tools')
print('Diese SW ist eine technische Demonstration und dient ausschliesslich zum Testen.')
print('Verwendung und Benutzung auf eigene Gefahr und Risiko.')
print('Wenn euch meine Arbeit gefaellt oder diese SW benutzt dann unterstuetzt mich\n unter der folgenden Bitcoin Adresse: {0}.'.format(adr))
# start Subscriber Thread
if usemqtt:
subscribe_thread = threading.Thread(target=checkSubscribeMSGs)
subscribe_thread.start()
# Start BLE processes
os.system("hciconfig hci0 down")
time.sleep(0.5)
os.system("hciconfig hci0 up")
time.sleep(0.5)
process_hcitool = subprocess.Popen(['hcitool', 'lescan', '--passive','--duplicate'],
stdout=subprocess.PIPE,
universal_newlines=True)
process_btmon = subprocess.Popen(['btmon'],
stdout=subprocess.PIPE,
universal_newlines=True)
process_started = True
process_cnt = 0
while not stopProcess:
process_cnt = process_cnt + 1
if int(time.time()*1000) > (cputs + 2500) and (process_cnt % 2) == 0:
cputs = int(time.time()*1000)
if cputemp() > 82.0:
print('High Temperature')
exit(0)
processSDrequests()
if not process_started:
process_started = True
os.system("hciconfig hci0 down")
time.sleep(0.2)
os.system("hciconfig hci0 up")
time.sleep(0.2)
process_hcitool = subprocess.Popen(['hcitool', 'lescan', '--passive','--duplicate'],
stdout=subprocess.PIPE,
universal_newlines=True)
process_btmon = subprocess.Popen(['btmon'],
stdout=subprocess.PIPE,
universal_newlines=True)
time.sleep(0.2)
output = process_btmon.stdout.readline()
output = output.strip()
if '> HCI Event: LE Meta Event (0x3e' in output:
startfound = 1
endfound = 0
datafound = 0
debugtext = ''
timestamp = 0.0
timestampRT = int(time.time()*1000)
rssivalue = 0.0
try:
timestamp = float(output.split()[-1])
except:
print(output)
if startfound == 1:
debugtext = debugtext + output +'\n'
if startfound == 1 and 'Address:' in output:
mac = output.split()[1].replace(':','')
if startfound == 1 and 'Data:' in output and 'a0064' in output:
datafound = 1
data = output.split()[1]
data = data.upper()
data = data[10:]
data = data[:32]
if 'RSSI:' in output:
if 'invalid' in output:
startfound = 0
endfound = 0
datafound = 0
debugtext = ''
else:
endfound = 1
if startfound == 1:
try:
rssivalue = float(output.split()[1])
except:
startfound = 0
endfound = 0
datafound = 0
if endfound == 1:
if startfound == 1 and datafound == 1 and mac in dictNames and len(data) == 32 and rssivalue < -10:
# process frame
key = dictKeys[mac]
decrMessage = DecryptBLE(data, key, mac)
if decrMessage.startswith('10') == False or decrMessage.endswith('00000000') == False:
if debuginfo:
print(debugtext)
else:
value_int = 0
intermessage = 'unknown'
printinfo = False
initmsg = False
if mac in dictLast:
if dictType[mac] == 10: # 'motion detector':
if dictLast[mac] != decrMessage:
printinfo = True
value_int = int(decrMessage[4:6]+decrMessage[2:4], 16)
if decrMessage.endswith('10000000000'):
intermessage = 'move'
else:
intermessage = decrMessage
if dictType[mac] == 7: # 'smoke detector':
if dictLast[mac] != decrMessage:
value_int = 1
if decrMessage.endswith('1000000000000000000'):
value_int = 1
intermessage = 'normal'
elif decrMessage.endswith('6000000000000000000'):
intermessage = 'alarm_6'
elif decrMessage.endswith('4000000000000000000'):
intermessage = 'alarm_4'
else:
intermessage = decrMessage
printinfo = True
if dictType[mac] == 4: # 'door contact':
if dictLast[mac][8:] != decrMessage[8:]:
value_int = 1
printinfo = True
if decrMessage.endswith('1000000000000000000'):
value_int = 0
intermessage = 'close'
elif decrMessage.endswith('2000000000000000000'):
intermessage = 'open'
else:
intermessage = decrMessage
dictLast[mac] = decrMessage
else:
initmsg = True
dictLast[mac]=decrMessage
if dictType[mac] == 10: # 'motion detector':
printinfo = True
value_int = int(decrMessage[4:6]+decrMessage[2:4], 16)
if decrMessage.endswith('10000000000'):
intermessage = 'init'
else:
intermessage = decrMessage
if dictType[mac] == 7: # 'smoke detector':
value_int = 1
if decrMessage.endswith('1000000000000000000'):
intermessage = 'normal'
value_int = 0
elif decrMessage.endswith('6000000000000000000'):
intermessage = 'alarm_6'
elif decrMessage.endswith('4000000000000000000'):
intermessage = 'alarm_4'
else:
intermessage = decrMessage
printinfo = True
if dictType[mac] == 4: # 'door contact':
value_int = 1
printinfo = True
if decrMessage.endswith('1000000000000000000'):
intermessage = 'close'
value_int = 0
elif decrMessage.endswith('2000000000000000000'):
intermessage = 'open'
else:
intermessage = decrMessage
dictLast[mac] = decrMessage
dictMessage = {}
dictMessage['mac'] = mac
dictMessage['source'] = raspiname
dictMessage['details'] = intermessage
dictMessage['value'] = value_int
dictMessage['rssivalue'] = rssivalue
dictMessage['timestampRT'] = timestampRT
dictMessage['type'] = dictType[mac]
dictMessage['name'] = dictNames[mac]
if printinfo:
if debuginfo:
print('{0} : {1} : {2} : {3} : {4} : {5} : {6}'.format(mac, intermessage, rssivalue, timestampRT, dictNames[mac], value_int, cputemp()))
if usemqtt:
try:
publish.single("msh/d_{0}".format(dictNames[mac].lower()), "{0}".format(json.dumps(dictMessage)), hostname="{0}".format(hostadr), auth=auth)
except:
pass
startfound = 0
endfound = 0
datafound = 0
debugtext = ''
# Do something else
if usemqtt:
subscribe_thread.join()
Beim Anlegen des Devices
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
erscheint folgender Fehler:
MEDION_Alarm attr readingList: more parameters needed
Zitat von: marboj am 19 Februar 2021, 22:12:42
Leider steht dort fest MQTT drin. Geht das dann mit dem MQTT2 von FHEM gar nicht?
MQTT2 ist nur eine FHEM-interne Bezeichnung der Modul-"Generation". Von außen ist es (ziemlich) egal.
Irgendwie ist es irritieren, dass du da so viel händisch rummachst. Zum einen: cfg-editieren geht gar nicht, erzeugt nur Fehler (falls du das tust), zum anderen sollte zumindest ein Device automatisch erzeugt werden, wenn es sich beim MQTT2_SERVER anmeldet. Da ist also was grundlegendes falsch.
Manuelles Editieren mache ich nicht, ich wollte nur das Script verstehen.
Ich habe jetzt folgendes gemacht:
- Server angelegt in FHEM
defmod m2server MQTT2_SERVER 1883 localhost
attr m2server autocreate complex
- Script gestartet
sudo python3 SH_CheckBLE.py -mqtt localhost &
Jetzt werden Geräte angelegt, Yippieh!!!!
Nun muss ich nur noch das Script automatisieren...
Server darf nicht localhost in der DEF haben, aber die IP fürs script ggf. schon...
einfach localhost beim Server weglassen?
Das State der Geräte wird mit ??? angezeigt. In den Readings steht das: d_arbeitszimmer_fenster_details close.
Kann man das auf State mappen?
Das war mein Vorschlag, für Details bitte die commandref bemühen:
Zitat von: Beta-User am 19 Februar 2021, 14:51:36
define m2server MQTT2_SERVER 1883 global
Was "STATE" angeht: Um eine qualifizierte Antwort zu geben, müßte ich das JSON im Ausgangszustand kennen. Das sieht so aus, als könnte man da erst eine regex drüber laufen lassen, ähnlich wie es in zigbee2tasmota gemacht wird, und dann nur den "inneren JSON" auswerten. Kommt aber auch drauf an, was da sonst noch so kommt...
Dann jsonMap "details"=>"state", oder eben direkt jsonMap mit dem langen Ausgangsnamen.
Zu guter letzt gäbe es noch stateFormat.
(Allgemeine Anmerkung: Du solltest dir ein paar Grundlagen aneignen, das Medion-Alarmanlagen-Ding ist eigentlich keine gute Device-Gruppe, um sich in FHEM einzuarbeiten...).
warum kann wohl das eine Device nicht angelegt werden?
2021.02.20 16:04:08 3: m2server: Unknown code autocreate=complexmsh/d_bad_fenster{"mac": "3C6A9D013F45", "source": "unusedName", "details": "106b1c00c10901370000000000000000", "value": 1, "rssivalue": -80.0, "timestampRT": 1613833448173, "type": 4, "name": "Bad_Fenster"}, help me!
list TYPE=autocreate
Internals:
FUUID 602d8518-f33f-698a-29ac-a27f575eb2bfb878
NAME autocreate
NOTIFYDEV global
NR 8
NTFY_ORDER 50-autocreate
STATE active
TYPE autocreate
Attributes:
filelog ./log/%NAME-%Y.log
room 99_System
Hab aber gar nichts geändert. Verstehe ich nicht...
OK, das ist es also nicht. Bin für den Moment ratlos (auch, warum alle Welt der Ansicht zu sein scheint, "complex" würde die Sache vereinfachen... Kann schon sein, dass am Ende $JSONMAP Sinn macht, aber das kann man dann manuell nachbessern!)
Was kann ich jetzt tun? Kann man das Gerät auch manuell anlegen?
Ja, manuell anlegen geht immer.
Aber mich würde schon auch interessieren, warum es nicht klappt mit autocreate. Irgendwas scheint bei dir generell "speziell" zu sein, auch das mit dem setList-Attribut war schräg...
2021.02.20 16:04:08 3: m2server: Unknown code autocreate=complexmsh/d_bad_fenster{"mac": "3C6A9D013F45", "source": "unusedName", "details": "106b1c00c10901370000000000000000", "value": 1, "rssivalue": -80.0, "timestampRT": 1613833448173, "type": 4, "name": "Bad_Fenster"}, help me!
Fehlt da nicht einfach ein Leerzeichen zwischen autocreate und mehr?
Das ganze läuft ja automatisch. Sehe keinen Ansatzpunkt, warum das nicht klappen sollte, klappt ja sonst auch...
ZitatFehlt da nicht einfach ein Leerzeichen zwischen autocreate und mehr?
Nein, die Teile werden durch ein 0-Zeichen getrennt, und das ist normalerweise im Ausdruck nicht sichtbar.
Z.Zt. bin ich auch ratlos, wie man sowas hinkriegt. Ist FHEM aktuell? Ich hatte unlaengst ein aehnliches Problem gefixt, ausgeloest durch fhem.cfg Editieren und vertauschte Reihenfolge der Definitionen.
Ein "attr global verbose 5" FHEM-Log-Mitschnitt im Problemfall koennte mir evtl. weiterhelfen.
Fhem ist aktuell und eine Änderung direkt in der FHEM.CFG hab ich auch nicht gemacht.
Hier mal das Log mit Verbose 5:
2021.02.21 10:24:25 4: m2server_127.0.0.1_35755 cid: CONNECT V:4 keepAlive:60
2021.02.21 10:24:25 4: m2server_127.0.0.1_35755 PUBLISH msh/d_test:{"mac": "3C6A9D013F45", "source": "unusedName", "details": "10f90300c10902370000000000000000", "value": 1, "rssivalue": -60.0, "timestampRT": 1613899465174, "type": 4, "name": "Test"}
2021.02.21 10:24:25 5: m2server: dispatch autocreate=complex\000\000msh/d_test\000{"mac": "3C6A9D013F45", "source": "unusedName", "details": "10f90300c10902370000000000000000", "value": 1, "rssivalue": -60.0, "timestampRT": 1613899465174, "type": 4, "name": "Test"}
2021.02.21 10:24:25 5: Starting notify loop for m2server, 1 event(s), first is UNKNOWNCODE autocreate=complex\000\000msh/d_test\000{"mac": "3C6A9D013F45", "source": "unusedName", "details": "10f90300c10902370000000000000000", "value": 1, "rssivalue": -60.0, "timestampRT": 1613899465174, "type": 4, "name": "Test"}
2021.02.21 10:24:25 5: End notify loop for m2server
2021.02.21 10:24:25 3: m2server: Unknown code autocreate=complexmsh/d_test{"mac": "3C6A9D013F45", "source": "unusedName", "details": "10f90300c10902370000000000000000", "value": 1, "rssivalue": -60.0, "timestampRT": 1613899465174, "type": 4, "name": "Test"}, help me!
2021.02.21 10:24:25 4: m2server_127.0.0.1_35755 DISCONNECT
Koennte passieren, wenn:
- FHEM/10_MQTT2_DEVICE.pm nicht geladen werden konnte, entweder weil kaputt, oder nicht da
- "attr global autoload_undefined_devices 0" gesetzt ist.
Paket ist da und autoload_undefined_devices =1
Wie kann man das Paket den aktualisieren?
Info für weitere Mitstreiter mit der Medion Anlage:
Es gibt zwei verschiedene Fensterkontakte:
- Bei der Anlage dabei waren MD90803 (FW *.023) - diese melden keinen korrekten Status, es wird eine Zahl hochgezählt
- Nachgekauft habe ich bei Medion MD90703 (FW *.017) - diese melden den Status open/close
Hallo marboj,
mit dem Python Programm SH_CheckBLE.py werden die Daten auch aus den Fenster-/Magnetkontakten kontinuierlich ausgelesen. In diesen Programm ist es gewissermaßen "hart verdrahtet" welches Bit sich wie ändern muss, damit du das Ergebnis "open" oder "close" für die Magnetkontakte angezeigt bekommst. Für die neueren Magnetkontaktmelder hat sich dieses verantwortliche Bit aber geändert. Das "alte" Programm SHCheckBLE.py kennt diese Änderung aber nicht. Du kannst das gerne mal selber checken, indem du das Programm SH_GetCloudData.py mal mit einen offenen Magnetkontakt ausführst, dann die Datei smarhome.json sicherst weil sie sonst überschrieben wird und dann im zweiten Schritt mit geschlossenem Magnetkontakt die Datei SH_GetCloudData.py erneut ausführst. Wenn du dann die neue Datei smarthome.json mit der Datei die du vorher gesichert hast vergleichst, wirst du die unterschiedlichen Änderungen (verschiedene Bits ändern sich) für die Magnetkontakte für "BLEDataPayload" sehen.
Das bedeutet, die Datei SH_CheckBLE.py muss entsprechend geändert/angepasst werden.
MfG deeb
Hallo rudolfkönig, Hallo beta-user, Hallo deep,
erst einmal vielen Dank für die Hilfe. Nachdem ich am WE wieder viel gelesen habe, habt ihr natürlich Recht mit den Änderungen in der FHEM.CFG.
Sorry, dass ich das fälschlicherweise verneint habe.
Bis dann
Marco