OpenMQTTGateway -> MQTT und RollingCode .... mal wieder

[Dattel01]

Ich habe gesehen, dass heute ein Update des mqtt2.template gekommen ist, die noch älterer Stand ist, als dein letztes Template.

Das aktuelle "OpenMQTTGateway_simple_RF433_switch" bringt aber beim Apply dann ein Error:

Code Auswählen Erweitern

Error checking template regexp: Undefined subroutine &main::ReadingVal called at (eval 528) line 1.

[Beta-User]

Kurze Info:
- ich habe eben etwas "Werbung" für das Teil gemacht, nicht wundern, wenn hier bald was los sein sollte. Wenn dich das stört: Melden, dann machen wir einen separaten Thread dazu...

- Was den BME280 angeht: Wenn du mir eine RAW-Definition von einem Device lieferst (bitte drübersehen, da steht leider auch die SSID drin usw.; mit RAW gemeint ist sowas hier), kann ich gerne versuchen, den BME-Teil vom MCU-Template zu lösen und in ein separates Device umzuleiten (ist für die STATE-Anzeige einfacher...).

- Das RF-"Zwischendevice" könnte man auch "vertemplaten", allerdings habe ich da noch keine Ahnung, was da wie Sinn macht, die Inspiration kommt evtl. mit deinem RAW-Code...

- Hast du eine Ahnung, ob man das Web-Interface noch erreichen kann, wenn der ESP im eigenen WLAN hängt? Da paßt im Moment zwar die IP-Adresse, aber das war's auch schon.

- Mein aktueller Plan ist, damit IR zu machen, der ESP32 könnte mein 360°-IR-Gateway@Tasmota ablösen (damit bliebe die Zahl der WLAN-Geräte unverändert ). Da ich auch noch einen RXB6 und einen 433MHz-Sender hier rumliegen habe, kommt das vermutlich mit drauf auf eine Lochrasterplatine.
Ich habe jetzt nicht groß rumgesucht, aber weißt zu zufällig, ob es für das Dinge eine Platine gibt, auf der das alles schön Platz findet?
(Sonst wäre das was, was man hier mal anleiern könnte, wenn größeres Interesse bestehen sollte...).


Danke für die Fehlermeldung, das muß "ReadingsVal" heißen, hab's eben ins svn geschubst. (Das kommt dann mit dem update morgen, du hast heute via update den Stand von irgendwann gestern bekommen, das hier bzw. svn ist atueller).

[Dattel01]

da stimmt scheinbar auch noch anderer Kleinkram nicht..

OpenMQTTGateway_MCU hat keine ReadingList mehr?!?, und damit auch keinen Reading mehr für den Onlinestatus.
das rfDevice sendet und empfängt gerade auch nischt mehr... da bin ich aber nochnicht dazu gekommen, zu schauen warum... Kind springt hier ständig durchs Büro :-D

Zu deiner Frage: Nein, es gibt kein WebInterface - den Link mit der IP kannst du also wieder rausnehmen...

mqtt Readings für den BME280 Sensor sollst du gerne haben. Hier hab ich mqtt-spy bemüht:
In den SYStoMQTT solltest du zu deiner Version zusätzlich noch den BME280 in dem Modul-String haben... Ist aber sicher für die Auswertung irrelevant... Nur zu Info, das hier die genutzten MOdule gelistet werden

Code Auswählen Erweitern


home/OpenMQTTGateway/SYStoMQTT    {"uptime":1800,"freeMem":44880,"rssi":-74,"SSID":"xxxx","ip":"192.168.xxx.xxx","mac":"xx:xx:xx:xx:xx:xx","modules":"RFBME280"}
home/OpenMQTTGateway/CLIMAtoMQTT/bme    {"tempc":21.18,"tempf":70.124,"hum":50.24414,"pa":100160.9,"altim":100.6837,"altift":330.3755}

Ich würde dann beim nächsten Template nochmal testen...... weiß aber nicht, ob ich da heute noch dazu komme....
Also ganz entspannt - ich leb schon lange ohne Template :-D... Die Wetterdaten landen derzeit in einem MQTT2_device mit entsprechenden Readings bei mir und da hängt ein LogWriter mit SVG Diagrammen drauf für die Visualisierung...


Falls dich hier die RAW-Definition interessiert: Ich habe hier versucht, die WetterDaten/RFDaten zu trennen indem ich beim "json2nameValue" einen Prefix nutze... Ist nur der schnelleren Lesbarkeit..

Code Auswählen Erweitern

defmod MQTT2_OpenMQTTGateway MQTT2_DEVICE OpenMQTTGateway
attr MQTT2_OpenMQTTGateway IODev MQTT2_FHEM_Server
attr MQTT2_OpenMQTTGateway devStateIcon online:10px-kreis-gruen offline.*:10px-kreis-rot
attr MQTT2_OpenMQTTGateway group Wettersensoren
attr MQTT2_OpenMQTTGateway readingList home/OpenMQTTGateway/LWT online\
home/OpenMQTTGateway/LWT:.* LWT\
home/OpenMQTTGateway/version:.* version\
home/OpenMQTTGateway/CLIMAtoMQTT/bme:.* { json2nameValue($EVENT, 'BME_') }\
home/OpenMQTTGateway/SYStoMQTT:.* { json2nameValue($EVENT,'Sys_')}\
home/OpenMQTTGateway/433toMQTT:.* { json2nameValue($EVENT,'RF_') }
attr MQTT2_OpenMQTTGateway room 1-Erdgeschoss,MQTT2_DEVICE,SD_WS07
attr MQTT2_OpenMQTTGateway stateFormat LWT\
Arbeitszimmer: BME_tempc °C - BME_hum % - BME_hpa hPa
attr MQTT2_OpenMQTTGateway userReadings BME_hpa {ReadingsVal("MQTT2_OpenMQTTGateway","BME_pa",0)/100}

setstate MQTT2_OpenMQTTGateway online\
Arbeitszimmer: 21.36 °C - 51.69824 % - 1001.602 hPa
setstate MQTT2_OpenMQTTGateway 2019-09-28 18:06:29 BME_altift 330.5322
setstate MQTT2_OpenMQTTGateway 2019-09-28 18:06:29 BME_altim 100.7462
setstate MQTT2_OpenMQTTGateway 2019-09-28 18:09:29 BME_hpa 1001.602
setstate MQTT2_OpenMQTTGateway 2019-09-28 18:06:29 BME_hum 51.69824
setstate MQTT2_OpenMQTTGateway 2019-09-28 18:06:29 BME_pa 100160.2
setstate MQTT2_OpenMQTTGateway 2019-09-28 18:06:29 BME_tempc 21.36
setstate MQTT2_OpenMQTTGateway 2019-09-28 18:06:29 BME_tempf 70.448
setstate MQTT2_OpenMQTTGateway 2019-09-28 17:40:48 LWT online
setstate MQTT2_OpenMQTTGateway 2019-09-28 18:00:42 RF_delay 103
setstate MQTT2_OpenMQTTGateway 2019-09-28 18:00:42 RF_length 24
setstate MQTT2_OpenMQTTGateway 2019-09-28 18:00:42 RF_protocol 3
setstate MQTT2_OpenMQTTGateway 2019-09-28 18:00:42 RF_value 13599892
setstate MQTT2_OpenMQTTGateway 2019-09-28 18:09:29 Sys_SSID XXXX
setstate MQTT2_OpenMQTTGateway 2019-09-28 18:09:29 Sys_freeMem 45552
setstate MQTT2_OpenMQTTGateway 2019-09-28 18:09:29 Sys_ip 192.168.XX.XX
setstate MQTT2_OpenMQTTGateway 2019-09-28 18:09:29 Sys_mac XX:XX:XX:XX:XX:XX
setstate MQTT2_OpenMQTTGateway 2019-09-28 18:09:29 Sys_modules RFBME280
setstate MQTT2_OpenMQTTGateway 2019-09-28 18:09:29 Sys_rssi -75
setstate MQTT2_OpenMQTTGateway 2019-09-28 18:09:29 Sys_uptime 2280
setstate MQTT2_OpenMQTTGateway 2019-09-28 17:40:48 version 0.9.2


[Beta-User]

Hmmm, das ist wirklich ein interessantes (und ziemlich komplexes) Dingens...

Bin ein paar Schritte weiter, aber noch nicht sicher, ob das der Weisheit allerletzter Schluß ist (eher nicht ).

Code Auswählen Erweitern

###############
#OpenMQTTGateway
#use this with an OpenMQTTGateway. For further details visit https://github.com/1technophile/OpenMQTTGateway/wiki
#recommended structure of the topic pattern home/OpenMQTTGateway.*/.*
#as set in the settings section in the GW's web interface
#
#OpenMQTTGateway - Microcontroller
#Atm there are no furter commands to be set to the esp itself
name:OpenMQTTGateway_MCU
filter:TYPE=MQTT2_DEVICE
desc:use this with an OpenMQTTGateway. For further details visit https://github.com/1technophile/OpenMQTTGateway/wiki<br>Recommended structure of the topic pattern home/OpenMQTTGateway/.*.<br>NOTE: Initial version, not yet tested, just build according to https://forum.fhem.de/index.php/topic,103737.0.html<br>Adopt
order:X_02
par:BASE_ID;BASE_ID typically is home;{ AttrVal("DEVICE","readingList","") =~ m,([^:]+)[/]OpenMQTTGateway[^/]*[/].*:, ? $1 : undef }
par:DEVNAME;BASE_ID typically is home;{ AttrVal("DEVICE","readingList","") =~ m,([^:]+)[/](OpenMQTTGateway[^/]*)[/].*:, ? $2 : undef }
par:DEVCID;CID of the device as written in the DEF; { InternalVal(AttrVal("DEVICE","IODev",""),"clientId","mosquitto") eq InternalVal("DEVICE","DEF","mosquitto") ? "oMQTTgw_MCU" : InternalVal("DEVICE","DEF","mosquitto")}
deletereading -q DEVICE (?!associatedWith).*
attr DEVICE bridgeRegexp\
  BASE_ID/DEVNAME/BTtoMQTT/([0-9A-Z]+):.* "oMQTTgw_BT_$1"\
  BASE_ID/DEVNAME/433toMQTT:.* "oMQTTgw_433"\
  BASE_ID/DEVNAME/IRtoMQTT:.* "oMQTTgw_IR"\
  BASE_ID/DEVNAME/CLIMAtoMQTT/(.*):.* "DEVNAME_$1"
attr DEVICE readingList\
  BASE_ID/DEVNAME/LWT:.* LWT\
  BASE_ID/DEVNAME/version:.* version\
  BASE_ID/DEVNAME/SYStoMQTT:.* { json2nameValue($EVENT,'Sys_')}\
  homeassistant/[^/]*sensor/[^/]+/config:.* { $EVENT =~ m,DEVNAME, ? json2nameValue($EVENT,"HASS_") : undef }
attr DEVICE setList\
  BT_scan_now:noArg BASE_ID/DEVNAME/commands/MQTTtoBT/set {"interval":0}\
  BT_scan_interval:textField BASE_ID/DEVNAME/commands/MQTTtoBT/set {"interval":$EVTPART1}\
  BT_blacklist:textField BASE_ID/DEVNAME/commands/MQTTtoBT/set {"black-list":[$EVTPART1]}\
  BT_whitelist:textField BASE_ID/DEVNAME/commands/MQTTtoBT/set {"white-list":[$EVTPART1]}
attr DEVICE stateFormat <a href="http://Sys_ip" target="_blank">\
LWT\
</a>Version: version
attr DEVICE devStateIcon online:10px-kreis-gruen offline.*:10px-kreis-rot
attr DEVICE model OpenMQTTGateway_MCU

name:OpenMQTTGateway_simple_RF433_switch
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*OpenMQTTGateway.*
desc:use this with an OpenMQTTGateway. For further details visit https://github.com/1technophile/OpenMQTTGateway/wiki<br>Recommended structure of the topic pattern home/OpenMQTTGateway/.*.<br>NOTE: Initial version, not yet tested, just build according to https://forum.fhem.de/index.php/topic,103737.0.html<br>Adopt settings to your needs.<br>NOTE: this might create a new device!
order:X_02a
par:ONCOMMANDREGEX;ONCOMMANDREGEX typically is one or more Codes like 13027392|13519216|12585648|13349168;undef
par:ON_COMMAND;ON_COMMAND typically is a set of parameters like "value":"13027392","protocol":4,"length":24,"delay":350;undef
par:OFFCOMMANDREGEX;OFFCOMMANDREGEX typically is one or more Codes like 13381408|13226144|13381408|13599888;undef
par:OFF_COMMAND;ON_COMMAND typically is a set of parameters like "value":"13381408","protocol":4,"length":24,"delay":350;undef
par:BASE_ID;BASE_ID typically is home;{ AttrVal("DEVICE","readingList","") =~ m,([^:]+)[/]OpenMQTTGateway[^/]*[/].*:, ? $1 : undef }
par:DEVNAME;BASE_ID typically is home;{ AttrVal("DEVICE","readingList","") =~ m,([^:]+)[/](OpenMQTTGateway[^/]*)[/].*:, ? $2 : undef }
par:DEVCID;CID of the new device - try to read the last RF value; { ReadingsVal("DEVICE","value","unknown") }
par:NEWDEVROOM;Room of the calling device; {AttrVal("DEVCID","room","MQTT2_\DEVICE" )}
defmod OMG_DEVCID MQTT2_\DEVICE DEVCID
deletereading -q OMG_DEVCID (?!associatedWith).*
defmod OMG_DEVCID MQTT2_\DEVICE DEVCID
attr OMG_DEVCID autocreate 0
attr OMG_DEVCID readingList\
  BASE_ID/DEVNAME/433toMQTT:.* { $EVENT =~ m,..value..(ONCOMMANDREGEX)..protocol..\d..length..\d+..delay..\d+.,? {"state"=>"on"} : $EVENT =~ m,..value..(OFFCOMMANDREGEX)..protocol..\d..length..\d+..delay..\d+., ? {"state"=>"off"}:undef }\
  BASE_ID/DEVNAME/433toMQTT:.* { $EVENT =~ m,..value..([\d]+)..protocol..\d..length..\d+..delay..\d+.,? {"received_code"=>"$1"}:undef }
attr OMG_DEVCID setList\
  on:noArg BASE_ID/DEVNAME/commands/MQTTto433 {ON_COMMAND}\
  off:noArg BASE_ID/DEVNAME/commands/MQTTto433 {OFF_COMMAND}
{ fhem "trigger $FW_wname JS:location.href='$FW_ME?detail=OMG_DEVCID'" if($cl && $cl->{TYPE} eq "FHEMWEB") }
farewell:template has been applied successfully.
attr OMG_DEVCID room NEWDEVROOM
attr OMG_DEVCID model OpenMQTTGateway_simple_RF433_switch

name:OpenMQTTGateway_bme
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*OpenMQTTGateway.*
desc:use this with an OpenMQTTGateway. For further details visit https://github.com/1technophile/OpenMQTTGateway/wiki<br>Recommended structure of the topic pattern home/OpenMQTTGateway/.*.<br>NOTE: Initial version, not yet tested, just build according to https://forum.fhem.de/index.php/topic,103737.0.html<br>Adopt settings to your needs.<br>NOTE: this might create a new device!
order:X_02b
par:BASE_ID;BASE_ID typically is home;{ AttrVal("DEVICE","readingList","") =~ m,([^:]+)[/]OpenMQTTGateway[^/]*[/].*:, ? $1 : undef }
par:DEVNAME;BASE_ID typically is home;{ AttrVal("DEVICE","readingList","") =~ m,([^:]+)[/](OpenMQTTGateway[^/]*)[/].*:, ? $2 : undef }
deletereading -q DEVICE (?!associatedWith).*
defmod DEVICE MQTT2_\DEVICE DEVCID
attr DEVICE autocreate 0
attr DEVICE readingList\
  BASE_ID/DEVNAME/CLIMAtoMQTT/bme:.* { json2nameValue($EVENT, 'BME_') }
attr DEVICE stateformat BME_tempc °C - BME_hum % - hpa hPa
attr DEVICE userReadings hpa:BME_hpa.* {ReadingsVal($name,"BME_pa",0)/100}
attr DEVICE model OpenMQTTGateway_bme
Es gibt jetzt ein drittes template nur für den BME-Teil (der wird auch via bridgeRegex an ein anderes Device weitergegeben), die Präfix-Geschichte finde ich in dem Zusammenhang auch ganz praktisch (das wird Rudi freuen ).

Den unnützen IP-Link habe ich noch drin, würde vermuten, dass da auch irgendwann noch eine Webseite zu finden sein wird.

Für das Zwischendevice weiß ich grade nicht, das sieht mir so aus, als müßten da immer die letzten Code schon ausgepackt da sein, viel mehr macht m.E. auch keinen Sinn, wir könnten höchstens den JSON auch unausgepackt darstellen. Aber ob es das bringt? (Vermutlich im Moment eher nicht).

Was mir auf die Schnelle noch Schwierigkeiten macht, ist der Umgang mit dem homeassistant-Autodiscovery. Wird jetzt auf ein eigenes Device umgeleitet, aber das macht so m.E. noch nicht den großen Sinn, muß mich da erst eindenken (das scheinst du auskommentiert zu haben, ich habe schlicht das binary genommen, das samt esptool.py in ein Verzeichnis gepackt und unter Linux via

Code Auswählen Erweitern

./esptool.py --chip esp32 --port /dev/ttyUSB0 --baud 921600 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 80m --flash_size detect 0xe000 *boot_app0.bin 0x1000 *bootloader_dio_80m.bin 0x10000 *BLE.bin 0x8000 *BLE_partitions.bin
draufgebeamt...

Das home-Assistant Device sieht dann so aus

Code Auswählen Erweitern


defmod MQTT2_homeassistant MQTT2_DEVICE homeassistant
attr MQTT2_homeassistant IODev MQTT2_FHEM_Server
attr MQTT2_homeassistant readingList homeassistant/binary_sensor/3C71BF79856C/config:.* { json2nameValue($EVENT) }\
homeassistant/sensor/3C71BF79856CgatewayBT/config:.* { json2nameValue($EVENT) }
attr MQTT2_homeassistant room MQTT2_DEVICE

setstate MQTT2_homeassistant 2019-09-29 09:31:03 associatedWith OpenMQTTGateway_ESP32
setstate MQTT2_homeassistant 2019-09-29 09:41:03 dev_cla connectivity
setstate MQTT2_homeassistant 2019-09-29 09:41:03 device_identifiers_1 3C71BF79856C
setstate MQTT2_homeassistant 2019-09-29 09:41:03 device_manufacturer OMG_community
setstate MQTT2_homeassistant 2019-09-29 09:41:03 device_name OpenMQTTGateway_ESP32_BLE
setstate MQTT2_homeassistant 2019-09-29 09:41:03 device_sw_version 0.9.2
setstate MQTT2_homeassistant 2019-09-29 09:41:03 name gatewayBT
setstate MQTT2_homeassistant 2019-09-29 09:41:03 pl_avail online
setstate MQTT2_homeassistant 2019-09-29 09:41:03 pl_not_avail offline
setstate MQTT2_homeassistant 2019-09-29 09:41:03 pl_off offline
setstate MQTT2_homeassistant 2019-09-29 09:41:03 pl_on online
setstate MQTT2_homeassistant 2019-09-29 09:41:03 stat_t home/OpenMQTTGateway_ESP32_BLE/BTtoMQTT/
setstate MQTT2_homeassistant 2019-09-29 09:41:03 uniq_id 3C71BF79856CgatewayBT
setstate MQTT2_homeassistant 2019-09-29 09:41:03 val_tpl {{ value_json.id }}
Scheint also im wesentlichen (nur) weitere Angaben zur BT-Schnittstelle zu liefern; die wären aber am MCU-Device eigentlich besser aufgehoben.

Kann die BT-Devices kaum mehr zählen, die der ESP eingesammelt hat; das ist irgendwie noch suboptimal...

EDIT: eben Code oben geändert und ins svn geschoben, der auch die homeassistant-Meldungen "schluckt" .

Jetzt geht's ans Löten...

Nachtrag zur "verlorenen" readingList: Das ist das normale Verhalten, wenn man eine bridgeRegex setzt/ändert.

[Dattel01]

Hmmm, das ist wirklich ein interessantes (und ziemlich komplexes) Dingens...

Ja das ist schon geil, das Teil... ich bin am Überlegen, ob ich da auch einen MergeRequest einkippe, denn in meiner Kombination mit RF und BME musste ich für den BME die Pins ändern können. Vielleicht macht's das für andere auch einfacher, wenn openMQTTGateway das per Parameter schon kann ohne dass man sich durch den kompletten Code wühlen muss und das bei jedem Update wieder nacharbeiten muss.

Bin ein paar Schritte weiter, aber noch nicht sicher, ob das der Weisheit allerletzter Schluß ist (eher nicht ).

Ich kopiere mir hier immer dein Template, und mache mir da eine custom.template in FHEM, benenne die 3 Devices noch um, damit ich die von den bereits im Repository befindlichen unterscheiden kann und lege auf der grünen wiese die Geräte immer neu an...

Es gibt jetzt ein drittes template nur für den BME-Teil (der wird auch via bridgeRegex an ein anderes Device weitergegeben), die Präfix-Geschichte finde ich in dem Zusammenhang auch ganz praktisch (das wird Rudi freuen ).

Das MCU-Device lässt sich wunderbar anlegen und funktioniert direkt.
Für das RF und BME Template muss ich diese jeweils immer auf dem vorher angelegten MCU-Device nochmals anwenden?
Bei dem RF wird dann ja jedes mal gleich ein neues Device im mqtt2_device room angelegt... Beim BME wird das nicht gemacht, anstelle dessen wird das Tempalte beim aktuellen Device angewendet... Das empfinde ich als inkonsistent... Entweder immer neues Device anlegen oder nie..

Bei dem BME bitte aus stateformatstateFormat machen, sonst gehts nicht...
Hast du irgendwo mal eine Referenz, wo man das Attribute bridgeRegexp mal erklärt bekommt? Ich versteh's nämlich absolut nicht und finde da auch keine EinsteigerDoku zu.


Für das Zwischendevice weiß ich grade nicht, das sieht mir so aus, als müßten da immer die letzten Code schon ausgepackt da sein, viel mehr macht m.E. auch keinen Sinn, wir könnten höchstens den JSON auch unausgepackt darstellen. Aber ob es das bringt? (Vermutlich im Moment eher nicht).

Was mir auf die Schnelle noch Schwierigkeiten macht, ist der Umgang mit dem homeassistant-Autodiscovery. Wird jetzt auf ein eigenes Device umgeleitet, aber das macht so m.E. noch nicht den großen Sinn, muß mich da erst eindenken (das scheinst du auskommentiert zu haben, ich habe schlicht das binary genommen, das samt esptool.py in ein Verzeichnis gepackt und unter Linux via

Code Auswählen Erweitern

./esptool.py --chip esp32 --port /dev/ttyUSB0 --baud 921600 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 80m --flash_size detect 0xe000 *boot_app0.bin 0x1000 *bootloader_dio_80m.bin 0x10000 *BLE.bin 0x8000 *BLE_partitions.bin
draufgebeamt...

korrekt... das wollte ich nicht haben und das schmeißt bei mir im FHEM auch böse Fehler im Log:

Code Auswählen Erweitern

2019.09.28 17:42:25 3: Bad line >< for MQTT2_OpenMQTTGateway

Jetzt geht's ans Löten...

Nachtrag zur "verlorenen" readingList: Das ist das normale Verhalten, wenn man eine bridgeRegex setzt/ändert.

Dann viel Spaß dabei.. bei mir lümmeln die 3 noch alle fein auf einem Breadboard rum..


Update: das Userreading funktioniert beim BME leider auch nicht und abhängig davon auf das Stateformat nicht.

Meine Variante hierzu war beim UserReading:

Code Auswählen Erweitern

BME_hpa {ReadingsVal($name,"BME_pa",0)/100}
und dann beim StateFormate:

Code Auswählen Erweitern

BME_tempc °C - BME_hum % - BME_hpa hPa

[Beta-User]

Danke für die Rückmeldung.

Sieht ja interessant aus mit den Steckbrettern, bei mir ist das in der Regel noch unordentlicher verstöpselt . Aber auch ein ESP32 ist zu sehen, gerne kannst das mit dem BT dann ja auch mal testen.

Zum Löten bin ich nicht gekommen, ich mußte erst mal meine Arduino IDE auf den aktuellen Stand bringen, aber irgendwie bekomme ich den Code damit nicht übersetzt (ich will RF, IR und BT haben, und das ist im Default nicht alles aktiviert, doof eigentlich, ähnlich der seltsamen Sache mit dem BME; da du das umlegen kannst, scheint es nicht mit der Hardware zusammenzuhängen...). Wie dem auch sei, ich muß mich da erst mal wieder einfinden und dann nochmal einen Versuch unternehmen.

(Wenn wir bei Verbesserungsvorschlägen sind: eine Serielle Schnittstelle einfach zusätzlich via WLAN weiterzureichen (für ein HM-Pi-PCB oder einen CUL) wäre auch noch eine gute Sache; wenn das mit der internen Verarbeitung der Zigbee-Geschichte klappen würde, wäre das auch eine coole Lösung, v.a., wenn man dann auch noch via USB "auf MQTT" mit dem GW sprechen könnte (empfangsseitig geht das... ; dann könnte man auf WLAN verzichten ).)

Zur bridgeRegexp: Speicher mal deine vorhandenen Devices weg und lösche dann mal alles .

Kurzer Erläuterungsversuch (will ich irgendwann auch im Wiki noch näher erläutern): gibt es noch keinen "Abnehmer", der eine passende readingList hat, versucht autocreate@mqtt2_device, das passende Device zu finden. Dabei wird als erstes geschaut, ob es bridgeRegexp-Ausdrücke gibt, die passen (passen mehrere, wird per Zufall entschieden...), und dann ergibt das, was "hinten" steht die CID für den Empfänger. Gibt's den noch nicht, wird er erstellt.

Ergo: erst mal landet alles in dem "Sammeldevice" (so wie du das bisher hattest). Wendet man das "MCU"-template an, werden verschiedene Topic-Zweige auf andere Devices umgeleitet, die ggf. erst erstellt werden müssen:
Im Moment (mit den templates unten) landen der RF-Zweig, der BT-Zweig, der IR-Zweig (?) und der CLIMA-Zweig (?, bme) jeweils in einem neuen Device. In dem aktualisierten Setup landen also auch alle BT-Geräte "nur" als Readings in einem (eigenen) Großdevice, fand ich besser als ständig neue Devices, von denen ich noch nicht weiß, was damit anfangen . Ggf. gibt's dann später noch ein template, um einzelne BT-Geräte zu eigenen Geräten zu machen (ähnlich wie die RF-Devices).

Dass man dann mit dem RF-template weitere Devices erzeugt, ist also die logische Ausnahme, nicht - wie von dir angenommen - die Regel .

Code Auswählen Erweitern

###############
#OpenMQTTGateway
#use this with an OpenMQTTGateway. For further details visit https://github.com/1technophile/OpenMQTTGateway/wiki
#recommended structure of the topic pattern home/OpenMQTTGateway.*/.*
#as set in the settings section in the GW's web interface
#
#OpenMQTTGateway - Microcontroller
#Atm there are no furter commands to be set to the esp itself
name:OpenMQTTGateway_MCU
filter:TYPE=MQTT2_DEVICE
desc:use this with an OpenMQTTGateway. For further details visit https://github.com/1technophile/OpenMQTTGateway/wiki<br>Recommended structure of the topic pattern home/OpenMQTTGateway/.*.<br>NOTE: Initial version, not yet tested, just build according to https://forum.fhem.de/index.php/topic,103737.0.html<br>Adopt
order:X_02
par:BASE_ID;BASE_ID typically is home;{ AttrVal("DEVICE","readingList","") =~ m,([^:]+)[/]OpenMQTTGateway[^/]*[/].*:, ? $1 : undef }
par:DEVNAME;BASE_ID typically is home;{ AttrVal("DEVICE","readingList","") =~ m,([^:]+)[/](OpenMQTTGateway[^/]*)[/].*:, ? $2 : undef }
par:DEVCID;CID of the device as written in the DEF; { InternalVal(AttrVal("DEVICE","IODev",""),"clientId","mosquitto") eq InternalVal("DEVICE","DEF","mosquitto") ? "oMQTTgw_MCU" : InternalVal("DEVICE","DEF","mosquitto")}
deletereading -q DEVICE (?!associatedWith).*
attr DEVICE bridgeRegexp\
  BASE_ID/DEVNAME/BTtoMQTT/([0-9A-Z]+):.* "oMQTTgw_BT"\
  BASE_ID/DEVNAME/433toMQTT:.* "oMQTTgw_433"\
  BASE_ID/DEVNAME/IRtoMQTT:.* "oMQTTgw_IR"\
  BASE_ID/DEVNAME/CLIMAtoMQTT/(.*):.* "DEVNAME_$1"
attr DEVICE readingList\
  BASE_ID/DEVNAME/LWT:.* LWT\
  BASE_ID/DEVNAME/version:.* version\
  BASE_ID/DEVNAME/SYStoMQTT:.* { json2nameValue($EVENT,'Sys_')}\
  homeassistant/[^/]*sensor/[^/]+/config:.* { $EVENT =~ m,DEVNAME, ? json2nameValue($EVENT,"HASS_") : undef }
attr DEVICE stateFormat <a href="http://Sys_ip" target="_blank">\
LWT\
</a>Version: version
attr DEVICE devStateIcon online:10px-kreis-gruen offline.*:10px-kreis-rot
attr DEVICE model OpenMQTTGateway_MCU

name:OpenMQTTGateway_BT_scanner
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*OpenMQTTGateway.*
desc:use this with an OpenMQTTGateway. For further details visit https://github.com/1technophile/OpenMQTTGateway/wiki<br>Recommended structure of the topic pattern home/OpenMQTTGateway/.*.<br>NOTE: Initial version, not yet tested, just build according to https://forum.fhem.de/index.php/topic,103737.0.html<br>Adopt settings to your needs.
order:X_02b
par:BASE_ID;BASE_ID typically is home;{ AttrVal("DEVICE","readingList","") =~ m,([^:]+)[/]OpenMQTTGateway[^/]*[/].*:, ? $1 : undef }
par:DEVNAME;BASE_ID typically is home;{ AttrVal("DEVICE","readingList","") =~ m,([^:]+)[/](OpenMQTTGateway[^/]*)[/].*:, ? $2 : undef }
attr DEVICE readingList\
  BASE_ID/DEVNAME/BTtoMQTT/([0-9A-Z]+):.* { $TOPIC =~ m,BTtoMQTT/([0-9A-Z]+),;;json2nameValue($EVENT,"$1"."_") }\
  BASE_ID/home_presence/DEVNAME:.* { return undef unless $EVENT =~ m,(..)..)..)..)..)..),;; json2nameValue($EVENT,"BT_".uc($1.$2.$3.$4.$5.$6)."_");; {"last"=>uc($1.$2.$3.$4.$5.$6)}}
attr DEVICE setList\
  BT_scan_now:noArg BASE_ID/DEVNAME/commands/MQTTtoBT/set {"interval":0}\
  BT_scan_interval:textField BASE_ID/DEVNAME/commands/MQTTtoBT/set {"interval":$EVTPART1}\
  BT_blacklist:textField BASE_ID/DEVNAME/commands/MQTTtoBT/set {"black-list":[$EVTPART1]}\
  BT_whitelist:textField BASE_ID/DEVNAME/commands/MQTTtoBT/set {"white-list":[$EVTPART1]}
attr DEVICE stateFormat Last: last
attr DEVICE model OpenMQTTGateway_BT_scanner

name:OpenMQTTGateway_simple_RF433_switch
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*OpenMQTTGateway.*
desc:use this with an OpenMQTTGateway. For further details visit https://github.com/1technophile/OpenMQTTGateway/wiki<br>Recommended structure of the topic pattern home/OpenMQTTGateway/.*.<br>NOTE: Initial version, not yet tested, just build according to https://forum.fhem.de/index.php/topic,103737.0.html<br>Adopt settings to your needs.<br>NOTE: this might create a new device!
order:X_02a
par:ONCOMMANDREGEX;ONCOMMANDREGEX typically is one or more Codes like 13027392|13519216|12585648|13349168;undef
par:ON_COMMAND;ON_COMMAND typically is a set of parameters like "value":"13027392","protocol":4,"length":24,"delay":350;undef
par:OFFCOMMANDREGEX;OFFCOMMANDREGEX typically is one or more Codes like 13381408|13226144|13381408|13599888;undef
par:OFF_COMMAND;ON_COMMAND typically is a set of parameters like "value":"13381408","protocol":4,"length":24,"delay":350;undef
par:BASE_ID;BASE_ID typically is home;{ AttrVal("DEVICE","readingList","") =~ m,([^:]+)[/]OpenMQTTGateway[^/]*[/].*:, ? $1 : undef }
par:DEVNAME;BASE_ID typically is home;{ AttrVal("DEVICE","readingList","") =~ m,([^:]+)[/](OpenMQTTGateway[^/]*)[/].*:, ? $2 : undef }
par:DEVCID;CID of the new device - try to read the last RF value; { ReadingsVal("DEVICE","value","unknown") }
par:NEWDEVROOM;Room of the calling device; {AttrVal("DEVCID","room","MQTT2_\DEVICE" )}
defmod OMG_DEVCID MQTT2_\DEVICE DEVCID
deletereading -q OMG_DEVCID (?!associatedWith).*
defmod OMG_DEVCID MQTT2_\DEVICE DEVCID
attr OMG_DEVCID autocreate 0
attr OMG_DEVCID readingList\
  BASE_ID/DEVNAME/433toMQTT:.* { $EVENT =~ m,..value..(ONCOMMANDREGEX)..protocol..\d..length..\d+..delay..\d+.,? {"state"=>"on"} : $EVENT =~ m,..value..(OFFCOMMANDREGEX)..protocol..\d..length..\d+..delay..\d+., ? {"state"=>"off"}:undef }\
  BASE_ID/DEVNAME/433toMQTT:.* { $EVENT =~ m,..value..([\d]+)..protocol..\d..length..\d+..delay..\d+.,? {"received_code"=>"$1"}:undef }
attr OMG_DEVCID setList\
  on:noArg BASE_ID/DEVNAME/commands/MQTTto433 {ON_COMMAND}\
  off:noArg BASE_ID/DEVNAME/commands/MQTTto433 {OFF_COMMAND}
{ fhem "trigger $FW_wname JS:location.href='$FW_ME?detail=OMG_DEVCID'" if($cl && $cl->{TYPE} eq "FHEMWEB") }
farewell:template has been applied successfully.
attr OMG_DEVCID room NEWDEVROOM
attr OMG_DEVCID model OpenMQTTGateway_simple_RF433_switch

name:OpenMQTTGateway_bme
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*OpenMQTTGateway.*
desc:use this with an OpenMQTTGateway. For further details visit https://github.com/1technophile/OpenMQTTGateway/wiki<br>Recommended structure of the topic pattern home/OpenMQTTGateway/.*.<br>NOTE: Initial version, not yet tested, just build according to https://forum.fhem.de/index.php/topic,103737.0.html<br>Adopt settings to your needs.<br>NOTE: this might create a new device!
order:X_02b
par:BASE_ID;BASE_ID typically is home;{ AttrVal("DEVICE","readingList","") =~ m,([^:]+)[/]OpenMQTTGateway[^/]*[/].*:, ? $1 : undef }
par:DEVNAME;BASE_ID typically is home;{ AttrVal("DEVICE","readingList","") =~ m,([^:]+)[/](OpenMQTTGateway[^/]*)[/].*:, ? $2 : undef }
deletereading -q DEVICE (?!associatedWith).*
defmod DEVICE MQTT2_\DEVICE DEVCID
attr DEVICE autocreate 0
attr DEVICE readingList\
  BASE_ID/DEVNAME/CLIMAtoMQTT/bme:.* { json2nameValue($EVENT, 'BME_') }
attr DEVICE stateFormat BME_tempc °C - BME_hum % - hpa hPa
attr DEVICE userReadings hpa:BME_pa.* {ReadingsVal($name,"BME_pa",0)/100}
attr DEVICE model OpenMQTTGateway_bme

Fehler habe ich bei der Discovery nicht gesehen, aber auch nicht ernsthaft gesucht.


Das mit dem userReading habe ich leider zu spät gesehen. So müßte es gehen (oben korrigiert, im svn noch nicht):

Code Auswählen Erweitern

attr DEVICE userReadings hpa:BME_pa.* {ReadingsVal($name,"BME_pa",0)/100}
Bei userReadings sollte man m.E. immer darauf achten, dass der Trigger sauber gesetzt wird, und da war bei mir der "Wunschlesemodus" aktiviert, was den Readingnamen angeht. Über den Namen kann man steiten, ich wollte optisch etwas anderes haben als das, was das JSON-Auspacken liefert, ist aber zugegebenermaßen Geschmackssache .

EDIT: Typo im BT-Template

[Dattel01]

Sieht ja interessant aus mit den Steckbrettern, bei mir ist das in der Regel noch unordentlicher verstöpselt . Aber auch ein ESP32 ist zu sehen, gerne kannst das mit dem BT dann ja auch mal testen.

Da scheinst du dich verguckt zu haben... das vorne ist ein ESP8266 auf einem NodeMCU Board und das hintere ist ein ESP01 (also auch 8266).. Demnach bräuchte ich entweder eine ESP32 oder einen BT-Adapter, der passt.

Zum Löten bin ich nicht gekommen, ich mußte erst mal meine Arduino IDE auf den aktuellen Stand bringen, aber irgendwie bekomme ich den Code damit nicht übersetzt (ich will RF, IR und BT haben, und das ist im Default nicht alles aktiviert, doof eigentlich, ähnlich der seltsamen Sache mit dem BME; da du das umlegen kannst, scheint es nicht mit der Hardware zusammenzuhängen...). Wie dem auch sei, ich muß mich da erst mal wieder einfinden und dann nochmal einen Versuch unternehmen.

Als ich die Devices auf Mqtt2 umgestellt habe, musste ich die hier alle nochmal neu compilieren, da ich den 1883 Port noch auf Mosquitto habe und MQTT2 auf 1884 läuft. Es hat mich tierisch angenervt, jedes mal eine Verzeichnis-Kopie anzulegen, Namen zu ändern, neu zu kompilieren. Gerade auch, weil die Arduino-IDE den Verzeichnisnamen immer identisch mit der INO haben will. Seither habe ich Visual-Studio-Code mit PIO am laufen und werde (wenn möglich) um die Arduino IDE einen Bogen machen. VSCode hat viele Plugins, GIT-Anbindung, SyntaxHighlighting, Eingebauten !GUTEN! Library-Manager, der auch mit unterschiedlichen Versionen einer LIB umgehen kann.. OpenMQTT Gateway liefert eine vorgefertige Konfiguration (platformio.ini) mit, die schon beispiele enthält, wie man einfach über Compilerschalter entsprechene Module abschalten/einschalten kann auch die Namen des Gateways ändern kann. Für den ESP01 und das NodeMCU Board hab ich mir entsprechende User-Configs angelegt.
Auch wenn die Lernkurve am Anfang mit VS-Code etwas steil ist, lohnt es sich trotzdem auf jeden Fall.
Aber wie pflege ich immer zu sagen: bei Fragen einfach fragen.... Ich hab's mit OpenMqttGateway jetzt durch, wenn bedarf, kann ich dir eine Beispielconfig schicken, damit's am Anfang einfacher ist.
Oder du schaust einfach https://community.openmqttgateway.com/t/feature-suggest-customizeable-pins-e-g-for-bme280/652 hier -> da habe ich heute meine Anpassung für den ESP-01 dokumentiert, in der Hoffnung, dass der auf die Kompatiblitätsliste aufgenommen wird :-D


Das wollte ich einfach mal schnell noch loslassen...

jetzt hab ich erstmal alle betroffenen Devices gelöscht, warte ab und lese ich mir den Part mit der "bridgeRegExpr" nochmal durch und versuche es zu verstehen... :-D

[Dattel01]

Also nochmal zum BridgeRegEx...
Mal schauen, ob ich das verstanden habe.

Ich hab alles vorher gelöscht.
Jetzt lege ich ein MQTT2_device an, welchem ich dann das MCU Template anwende.. (für den DEVNAME und BASE_ID)

Über die BridgeRegExpr werden dann, wenn nötig, die entsprechenden Geräte für meine verwendeten Module automatisch angelegt... also in meinem Fall sollte es dann kurze Zeit später zwei weitere Devices geben (oMQTTgw_433, OpenMQTTGateway_$irgendwas$)...  (in meinem Fall müsste ich dann da nochmal ran, denn bei meinen mehreren Gateways ist lediglich DEVNAME anders.. der Rest des Topics ist bei mir identisch... also: home/OpenMQTTGateway/CLIMAtoMQTT/ und home/OpenMQTTGateway2/CLIMAtoMQTT/, home/OpenMQTTGateway3/CLIMAtoMQTT/)

Das tut es aber nicht... trotz autocreate 1 auf dem MQTT2_FHEM_Server sowie dem MCU-MQTT2_DEVICE

Also eigentlich ist dieser MCU-Proxy nur dafür gut, die SUB-Geräte anzulegen und denen gleich korrekten DEVNAME und BASE_ID mit reinzureichen?

[Beta-User]

Wg. der bridgeRegexp:

Das "neue" Device sollte automatisch angelegt werden, sobald irgendwas von dem jeweiligen ESP kommt (mit SERVER: je eines pro ESP). Dafür sollte es ausreichen, eine RF-Taste (an der FB) zu drücken.
Wenn du darauf dann das MCU-template anwendest, sollte das ohne Abfrage durchlaufen und dann bei dem nächsten Tastendruck das 433-er-Device erscheinen usw.. (Bzw. bei einem Wert vom BME der BME-Zweig). Das "MCU"-Device ist in der Tat nur dazu da, alle eingehenden (neuen) Topic-Pfade zu "sortieren".

Die groß geschriebenen Angaben in den templates sollten (abgesehen von den 433-er on/off-Geräten) eigentlich automatisiert aufgelöst werden können, das hat mit dem "sortieren" also eigentlich nichts zu tun.

Wenn das Vorsortieren nicht tut wie beschrieben: bitte melden, ich habe derzeit nur den BLE-Zweig, und mit dem funktioniert das.



Für VS bräuchte man eine Wind.*s-Kiste, oder? Muß so gehen, das Zweit-OS starte ich nur im Notfall (also nie) ... Mal schauen, ich meine, irgendwo fliegt noch Atom rum, aber habe ich mich auch nicht recht eingearbeitet, wird wohl mal Zeit .
Wenn das für dich easy ist, wäre es evtl. die Frage, ob du mir eine fertige binary (@ESP32) für die drei genannten Dinge gleichzeitig zur Verfügung stellen magst?

[Dattel01]

Ah jetzt ja... Langsam macht es "Klick" bei mir... Feini,Feini...

Ich weiß nicht wieso, aber ich habe ja vorher schon mit eigenen FHEM-Definitionen zu den OpenMediaGateways gearbeitet und entsprechende SVG-Diagramme angelegt.
Hier waren jetzt von 3 Definitionen plötzlich 2 defekt und da Log voll mit Fehlern. Scheint, als wenn sich meine alten Devices mit denen der neuen Template-Definitionen plötzlich gebissen haben.

Code Auswählen Erweitern

Bad line >< for MQTT2_OpenMQTTGateway3
Nachdem ich diese jetzt komplett gelöscht habe, geht das auch mit dem automatischen Anlegen....

Die Namensgebung für die BME's ist aber derzeit etwas unglücklich, da hier über den regulären Ausdruck auch der gepostete-Content mit aufgenommen wird. Hier mal eine RAW-Beispieldefinition:

Code Auswählen Erweitern

defmod MQTT2_OpenMQTTGateway3_bme___tempc__24.38__tempf__75.884__hum__45.19043__pa__98851.61__altim__207.9557__altift_ MQTT2_DEVICE OpenMQTTGateway3_bme:{"tempc":24.38,"tempf":75.884,"hum":45.19043,"pa":98851.61,"altim":207.9557,"altift"
attr MQTT2_OpenMQTTGateway3_bme___tempc__24.38__tempf__75.884__hum__45.19043__pa__98851.61__altim__207.9557__altift_ IODev MQTT2_FHEM_Server
attr MQTT2_OpenMQTTGateway3_bme___tempc__24.38__tempf__75.884__hum__45.19043__pa__98851.61__altim__207.9557__altift_ readingList home/OpenMQTTGateway3/CLIMAtoMQTT/bme:.* { json2nameValue($EVENT) }
attr MQTT2_OpenMQTTGateway3_bme___tempc__24.38__tempf__75.884__hum__45.19043__pa__98851.61__altim__207.9557__altift_ room MQTT2_DEVICE

setstate MQTT2_OpenMQTTGateway3_bme___tempc__24.38__tempf__75.884__hum__45.19043__pa__98851.61__altim__207.9557__altift_ 2019-09-30 11:03:29 altift 675.1387
setstate MQTT2_OpenMQTTGateway3_bme___tempc__24.38__tempf__75.884__hum__45.19043__pa__98851.61__altim__207.9557__altift_ 2019-09-30 11:03:29 altim 205.7823
setstate MQTT2_OpenMQTTGateway3_bme___tempc__24.38__tempf__75.884__hum__45.19043__pa__98851.61__altim__207.9557__altift_ 2019-09-30 10:58:29 associatedWith MQTT2_OpenMQTTGateway3
setstate MQTT2_OpenMQTTGateway3_bme___tempc__24.38__tempf__75.884__hum__45.19043__pa__98851.61__altim__207.9557__altift_ 2019-09-30 11:03:29 hum 45.52441
setstate MQTT2_OpenMQTTGateway3_bme___tempc__24.38__tempf__75.884__hum__45.19043__pa__98851.61__altim__207.9557__altift_ 2019-09-30 11:03:29 pa 98877.2
setstate MQTT2_OpenMQTTGateway3_bme___tempc__24.38__tempf__75.884__hum__45.19043__pa__98851.61__altim__207.9557__altift_ 2019-09-30 11:03:29 tempc 24.24
setstate MQTT2_OpenMQTTGateway3_bme___tempc__24.38__tempf__75.884__hum__45.19043__pa__98851.61__altim__207.9557__altift_ 2019-09-30 11:03:29 tempf 75.632


Ebenfalls noch das stateFormat für den BME in einer Form ähnlich:

Code Auswählen Erweitern

BME: tempc °C - hum % - hpa hPa

dazu dann och das userReading für die Umrechnung

Code Auswählen Erweitern

hpa {ReadingsVal($name,"pa",0)/100}

Wenn das für dich easy ist, wäre es evtl. die Frage, ob du mir eine fertige binary (@ESP32) für die drei genannten Dinge gleichzeitig zur Verfügung stellen magst?

Klar, kann ich versuchen.. Also du brauchst ein Binary für den ESP32 mit RF,BME und BT?
Update: probier mal das angehängte BIN File hierfür

Attached mal ein Bild, was dein Werk hier so alles feines bei mir angelegt hat :-D
Ebenfalls dein gewünschter Build für die 3 Module am ESP32

[Beta-User]

  Schön, wenn der Groschen fällt (und du keinen Anlass (mehr) siehst, das Prinzip nicht gut zu finden?) .

Danke für das binary. Leider hatte ich das wohl nicht klar genug kommuniziert: gemeint war BT, IR und RF (@ESP32). Vielleicht magst/kannst du nochmal ? (Zum Thema BME: "Meiner" hängt in einem Wetterschutzgehäuse an der Nordseite draußen, gelesen wird von einer MySensors-Node. Direkt beim Microcontroller ergibt der sowieso für temp/hum keine vernünftigen Werte, dafür strahlt der ESP-Chip zu viel Wärme ab; wenn ich in die Richtung noch was brauche, mache ich das vermutlich via zigbee/Aqara. Ist überraschend, dass das mit dem BME draußen recht gut funktioniert, ich hatte dem eigentlich keine lange Lebensdauer prognostiziert).

Bezgl. der Regex, könntest du mal versuchen, das in folgendes zu ändern:

Code Auswählen Erweitern

BASE_ID/DEVNAME/CLIMAtoMQTT/([a-zA-Z0-9]+):.* "DEVNAME_$1"

Was stateFormat und hpa für den bme angeht: Es gibt dazu ein eigenes template (via update oder im letzten Beitrag), das bitte mal testen, wenn die bridgeRegex eine deutlich kürzere Benennung/CID erzeugt hat . Eventuell könnten wir auch das userReading noch obsolet machen, indem wir direkt das $EVENT mit einer Regex auswerten und da rechnen (ist fast gleich von der Belastung her, aber besser "templatefähig").

Woher das mit den SVG's kommt, kann ich derzeit nicht sagen, eigentlich sollte das passen, wenn die Readingnamen/Devicenamen auch passen.

[Dattel01]

Danke für das binary. Leider hatte ich das wohl nicht klar genug kommuniziert: gemeint war BT, IR und RF (@ESP32). Vielleicht magst/kannst du nochmal ?

Hab ich wohl verpeilt.. Anbei das neue Binary.

(Zum Thema BME: "Meiner" hängt in einem Wetterschutzgehäuse an der Nordseite draußen, gelesen wird von einer MySensors-Node. Direkt beim Microcontroller ergibt der sowieso für temp/hum keine vernünftigen Werte, dafür strahlt der ESP-Chip zu viel Wärme ab; wenn ich in die Richtung noch was brauche, mache ich das vermutlich via zigbee/Aqara. Ist überraschend, dass das mit dem BME draußen recht gut funktioniert, ich hatte dem eigentlich keine lange Lebensdauer prognostiziert).

Im Garten hängt bei mir ein handelsüblicher Low-Budget-Sensor mit 2xAA Batterien, der ein Gegenstück mit Display bei mir in der Küche hat. Als ich vor 2 Jahren mal mit der RF-Idee auf ESP angefangen habe, habe ich fälschlicherweise zuerst einen CC1101 Sender/Empfänger gekauft, der allerdings wohl nur über SPI angebunden werden kann. Auf dem dazugehörigen ESP läuft ein SignalESP. Als ich den damals in's FHEM eingebunden habe, tauchten plötzlich Wettersensoren auf. Auch die kommunizieren mit Rohdaten, die ohne den ESP als Interpreter keinen Sinn ergeben. Für meine Funksteckdosen taugt dieser CC1101 mit SignalESP leider nicht, deshalb setzte ich hier auf openmqttgateway mit den BME Sensoren. Die liegen dann aber bei mir auch nicht draußen sondern per 3.3V Netzteil irgendwo in der Ecke. Für Batteriebetrieb sind die nicht geeignet, dafür sind sie aber kostengünstig.

Bezgl. der Regex, könntest du mal versuchen, das in folgendes zu ändern:

Code Auswählen Erweitern

BASE_ID/DEVNAME/CLIMAtoMQTT/([a-zA-Z0-9]+):.* "DEVNAME_$1"

Klappt. Hätte ich auch selber drauf kommen können, aber ich weiß bei FHEM noch nicht so genau, was wann wo möglich ist und was nicht... Steile Lernkurve, wenn man da nicht täglich dran schraubt

Was stateFormat und hpa für den bme angeht: Es gibt dazu ein eigenes template (via update oder im letzten Beitrag), das bitte mal testen, wenn die bridgeRegex eine deutlich kürzere Benennung/CID erzeugt hat . Eventuell könnten wir auch das userReading noch obsolet machen, indem wir direkt das $EVENT mit einer Regex auswerten und da rechnen (ist fast gleich von der Belastung her, aber besser "templatefähig").

Meine Anmerkung dazu kannst du ignorieren. Ich hatte 2 konkurierende template definitionen in der "mqtt2.template" und meiner "custom.template".. den relevanten Teil aus der mqtt2.template habe ich erstmal gelöscht und arbeite mit deinen Upates nur aus der custom.template - dann ersetze ich bei neuen Versionen hier aus dem Forum immer den kompletten Inhalt der custom.template. Wenn du das Reading obsolet machen willst, dann fühl dich frei - hier funktioniert es aber so auch super.

[Dattel01]

Ich möchte hier nochmal anmerken, dass wir lange nicht mehr NUR bei dem RollingCode sind, sondern dass ich deine Beiträge hier sehr dankbar als Grundlagenlehrgang für bestimmte Sachen in FHEM ansehe


Dafür mal ein fettes Danke

[Beta-User]

Danke für ein nettes feedback und auch das geduldige Austesten der Teile, die du im Moment ja eigentlich gar nicht brauchst.

MQTT2_DEVICE ist wirklich ein super Lernobjekt hinsichtlich der Frage, wie man welche Info hin- und herschieben und umverpacken kann und wie man was dann zweckmäßigerweise darstellt (in FHEMWEB). Ich selbst habe auch sehr viel gelernt, seit mich Rudi dazu überredet hat, die mqtt2.template's zu "maintainen", manches feature - wie dieses (in der Tat für "Ungeübte" sehr verwirrende) Dingens mit der bridgeRegexp - ist da erst im Dialog miteinander entstanden, da "mußte" ich halt auch die Lernkurve mitnehmen ... Für "dein" OpenMQTTGateway war dann der "ebus" das ultimative Testfeld; da wußte am Anfang auch noch keiner so richtig, wie man was eigentlich sinnvoll automatisiert zusammensortieren soll, und ich hatte keine Vorstellung, wie/was sich eigentlich so alles an so einem ebus tummeln kann . Jetzt scheinen dort alle soweit glücklich zu sein .

[OT] Meine MySensors-Nodes sind derzeit alle verkabelt (RS485), die Übertragung ist also vom BME her bei mir kein Funk, sondern (recht langes Kabel für) BME@I2C <---> MySensors-Node <--RS485--> MySensors-GW <--USB--> FHEM-Server. An dem MySensors-Netz hängen dann noch diverse DS18B20 an diversen Nodes, v.a. für Vor- und Rücklauftemperaturen/Heizung/Warmwasser usw..

Für Innentemperaturen usw. habe ich grade nur noch diverse HM-RT-DN und einen HM-TC im Einsatz, dazu einen Aqara (zigbee); die letzteren sind so günstig, ich meine, da lohnt selberbauen kaum noch.

Signalduino finde ich für die meisten Fälle auch super, bin mal auf die Ergebnisse aus dem Binary gespannt, was ein bestimmtes Vergleichsobjekt angeht (Dunstabzugshaube).[/OT]

Und eben auf den IR-Teil (im Vergeich zu Tasmota).

[Dattel01]

Also bisher habe ich nur das getestet, was ich auch brauche. BT kann ich ja nun leider schlecht testen, da hier bei mir logischerweise keine Geräte angelegt werden.

Falls du das schon runtergeladen hast, dann bitte löschen und aus meinem obigen Post nochmal herunterladen - ich hatte da noch Config-Fragmente meines MQTT-Servers drin, die du nicht haben willst.

Die Aqara Temperatur-Sensoren kannte ich gar nicht... da lohnt es sich tatsächlich mal ein Auge drauf zu halten..Da brauch man dann aber auch wieder ein separates Gateway für, richtig?