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

[Dattel01]

Hi zusammen,
ich bräuchte mal etwas versierte Unterstützung, da ich mit den Readings und Co nicht ganz warm werde..

Ich habe ein OpenMQTTGateway auf einem ESP mit 433MHZ Sender/Empfänger am Laufen und diesen in FHEM eingebunden.
Ich steuere damit Funksteckdosen auf 433Mhz Basis mit einer Fernbedienung, die Rolling-Codes erzeugt. Pro Taste sind es 4 unterschiedliche Codes. Diese habe ich bereits alle fein säuberlich dokumentiert.

Meine erste Umsetzung hierfür habe ich mit Mosquitto realisiert und möchte jetzt (weil alle anderen Geräte auch schon auf mqtt2 laufen) auf mqtt2 umstellen.

Bei der alten Mosquitto Umsetzung habe ich ein MQTTDevice kreiert (namentlich sc_remote) , welches einfach nur den Code der Fernbedienung in ein Reading geschrieben hat.
Auf diesem Reading hatte ich ein Notify gehängt, welches dann aufwendig alle Codes geprüft hat.
Für jedes Tastenpaar der Fernbedienung hab es dann ein weiteres MQTT-Device. Das Notify hat dann praktisch aus dem Reading von sc_remote ein setstate auf den MQTT-Devices für die Tastenpaare gemacht.

Code Auswählen Erweitern

sc_remote:KeyCode:.*  {
  if ($EVTPART1 eq 13027392 || $EVTPART1 eq 13519216 || $EVTPART1 eq 12585648 || $EVTPART1 eq 13349168)
    {fhem("setstate PoolPumpe on")}   

  if ($EVTPART1 eq 13381408 || $EVTPART1 eq 13226144 || $EVTPART1 eq 13381408 || $EVTPART1 eq 13599888)
    {fhem("setstate PoolPumpe off")}   
}


Ich bin quasi auf der Suche nach einer eleganteren Lösung, dass das neue MQTT2 Device sozusagen seine eigenen Codes kennt und selber seinen "state" korrekt setzen kann.

Das beigefügte Bild beschreibt mal ein TestDevice auf, welches auf dem MQTT2-IODev läuft.

• Schalten der Steckdose aus FHEM funktioniert soweit wunderbar -> die SetList tut also ihren Dienst. Ich muss hier keine rollenden Codes senden, sondern EINER reicht um das Gerät zuverlässig zu schalten.
• Ebenfalls funktioniert die ReadingList, die aus einem Empfangenen Signal der Fernbedienung den JSON-String wieder in Readings parst.

Was leider nicht so einfach funktioniert, ist das setzen des "State" für das FHEM-Device, wenn man die Fernbedienung nutzt. Ich will quasi das Reading "value" auf die 4 bekannten Werte parsen und entsprechend "state" auf "on" oder "off" setzen.

Wahrscheinlich ist das für den einen oder anderen hier Basic-Stuff und ihr könnt damit einem FHEM-Newbie einen schnellen Kniff erklären...
Gerne auch komplett andere Umsetzungsideen.

Danke und Gruß

[rudolfkoenig]

Eine Alternative waere

Code Auswählen Erweitern

attr PoolPumpe stateFormat {\
  my $kc = ReadingsVal("PoolPumpe", "KeyCode", "");;\
  $kc =~ m/13027392|13519216|12585648|13349168/ ? "on" :\
  $kc =~ m/13381408|13226144|13381408|13599888/ ? "off" : "unknown"\
}als "Raw Definition" Input

[Beta-User]

...etwas näher an der "Quelle" wäre, direkt in "state" zu schreiben.
Ich gehe mal davon aus, dass "KeyCode" das ist, was als "Data" im JSON steht? Dann müßte das in der readingList (eine Zeile daraus, TELETOPIC ist anzupassen) etwa so aussehen:

Code Auswählen Erweitern

TELETOPIC/RESULT:.* { $EVENT =~ m,..RfReceived....Sync..([A-Za-z0-9]+)..Low..([\d]+)..High..([\d]+)..Data...(13027392|13519216|12585648|13349168)...RfKey...([^"]+)..., ? {"state"=>"on"} :  $EVENT =~ m,..RfReceived....Sync..([A-Za-z0-9]+)..Low..([\d]+)..High..([\d]+)..Data...(13381408|13226144|13381408|13599888)...RfKey...([^"]+)..., ? {"state"=>"off"}:undef }Kann man vermutlich kürzen.

[Dattel01]

Hallo,
vielen Danke schon mal für die Rückmeldung..
Bitte nicht so sehr auf mein altes CodeSnippet achten, da es sich hier um die alte Umsetzung mit Mosquitto als MQTT Server handelt...
Wichtiger ist mein angefügtes Bild, welches meinen IST-Zustand mit dem neuen Device und den aktuellen Readings zeigt.

In der neuen Umsetzung hat jedes Device (pro Fernbedienung 4 Devices, da jeweils 1x An und 1x Aus vorhanden) selber den KeyCode im Reading "Value" gespeichert...
Ich habe das StateFormat für mich nochmal angepasst, da KeyCode in der neuen Variante "value" heißt..

Vorteil bei meiner Variante: Wenn ich ein anderes Tastenpaar drücke, dann bleibt der Status vom ersten Tastenpaar erhalten und wird nicht auf unbekannt gesetzt..

Code Auswählen Erweitern

attr PoolPumpe_2 stateFormat {\
  my $oldState = ReadingsVal("PoolPumpe_2", "state", "");;\
  my $value = ReadingsVal("PoolPumpe_2", "value", "");;\
  $value =~ m/13027392|13519216|12585648|13349168/ ? "on" :\
  $value =~ m/13381408|13226144|13381408|13599888/ ? "off" : $oldState\
}


Die Variante mit der ReadingList habe ich ebenfalls probiert... das gefällt mir auch ganz gut... Ich werde das beides nochmal testen und schaue mal, was mir besser gefällt..

Code Auswählen Erweitern

home/OpenMQTTGateway/433toMQTT:.* { $EVENT =~ m,..value..(13027392|13519216|12585648|13349168)..protocol..\d..length..\d+..delay..\d+.,? {"state"=>"on"} :  $EVENT =~ m,..value..(13381408|13226144|13381408|13599888)..protocol..\d..length..\d+..delay..\d+., ? {"state"=>"off"}:undef }

Vielen Dank schonmal im voraus...

[Beta-User]

Moin,

schon irgendwelche Info, was "besser" ist?
Hier mal der Versuch, das ganze als attrTemplate zu fassen:

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
#Atm there are no furter commands to be set to the esp itself
name:OpenMQTTGateway_simple_RF433
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 }
attr DEVICE autocreate 1
attr DEVICE setStateList on off
attr DEVICE readingList\
  BASE_ID/OpenMQTTGateway/LWT online\
  BASE_ID/OpenMQTTGateway/433toMQTT:.* { $EVENT =~ m,..value..(13027392|13519216|12585648|13349168)..protocol..\d..length..\d+..delay..\d+.,? {"state"=>"on"} : $EVENT =~ m,..value..(13381408|13226144|13381408|13599888)..protocol..\d..length..\d+..delay..\d+., ? {"state"=>"off"}:undef }\
  BASE_ID/OpenMQTTGateway/433toMQTT:.* { $EVENT =~ m,..value..([\d]+)..protocol..\d..length..\d+..delay..\d+.,? {"received_code"=>"$1"}:undef }
attr DEVICE setList\
  on:noArg BASE_ID/OpenMQTTGateway/commands/433toMQTT {"value":"13027392","protocol":4,"length":24,"delay":350}\
  off:noArg BASE_ID/OpenMQTTGateway/commands/433toMQTT {"value":"13381408","protocol":4,"length":24,"delay":350}
attr DEVICE stateFormat online\
state\
Version: version
attr DEVICE devStateIcon Online:10px-kreis-gruen Offline.*:10px-kreis-rot
attr DEVICE model OpenMQTTGateway_simple_RF433
Kommt bei Gelegenheit als update, ein vorheriger Test wäre nicht schlecht. Du darfst mir auch gerne eine RAW-Definition von dem Teil geben, und an sich scheint mir das auch so eine Art "Brückendevice" zu sein, für das man eine (oder mehrere) bridgeRegexp-Attribute definieren könnte. Da bräuchte ich aber mehr Info bzw. ein paar "vereinzelte" Devices.

Gruß, Beta-User

[Dattel01]

Das ist ja mal geil.... !!!
Dickes Danke an dieser Stelle

Also ich habe tatsächlich die Variante mit der RegEx-Reading Liste hier eingebunden und diese gefällt mir auch besser.
Allerdings habe ich bis heute "nur" eine Taste abgebildet, da ich die anderen noch nicht wieder benötigt habe. Außerdem hatte ich noch ein paar Optimierungsmöglichkeiten im Kopf, die ich aber in Ermangelung an Wissen nicht umzusetzen in der Lage war. Hier nochmal "dumm" nachzufragen hab ich mich dann nicht mehr getraut...

Insgesamt liegen allerdings hier 3 Fernbedienungen davon rum und zur Weihnachtszeit werden die auch wieder eingesetzt. Ich habe auch im Sommer wieder schmerzhaft erfahren dürfen, dass diese alten 433Mhz Steckdosen fehlerunanfälliger sind, als die ESP Modelle. Ich habe im Garten eine Poolpumpe damit steuern wollen und die Induktive Last hat die ESP-Teile ALLE in einen Reboot geschickt.

Folgende Ideen hatte ich noch im Kopf (wahrscheinlich ist das aber Klagen auf hohem Niveau):
-den RexEx Ausdruck mit einer Variable versehen .... z.B ValueOn & ValueOff... In diese Variable schreibt man dann einfach die passenden Codes rein (also z.B. "13027392|13519216|12585648|13349168"). Somit kann der "komplizierte" RegEx auf allen Geräten gleich bleiben und man muss nur die "einfache" UserAttr pro Device anpassen.. Allerdings ist das aufgrund des JSON-Strings bei der SetList dann eigentlich schonwieder Blödsinn, denn da muss man ja sowieso pro Device immer wieder ran :-/
-Die Fernbedienung kann 4 Geräte steuern (jeweils AN/AUS). Zusätzlich gibt es eine Master Taste (AN/AUS)... d.h die einzelnen Devices lauschen auf die 4 eigenen Codes sowie die 4 Master Codes...
d.h jedes Device bekommt nochmal einfach 4 Codes dazu...

Was an Deinem Template derzeit nicht korrekt ist:
-die SetList geht auf das Topic: home/OpenMQTTGateway/commands/MQTTto433
-schaltet man über die FB, dann gibt's ein anderes ICON, als wenn man über FHEM schaltet.

Ansonsten funktioniert das mit dem Template super und spart beim Einrichten der anderen Tasten dann eine Menge Zeit :-D....

Aber wahrscheinlich bin ich wohl der Einzige, der das nutzt und du baust hier gleich die ultimative Nieschenprodukt-Universallösungen für mich zusammen ....
Also nochmal dickes Danke, für die Zeit und Energie...

Für Deine "bridgeRegexp" Geschichte müsstes du sagen, was du brauchst... hab ich nicht so ganz verstanden....


Update: ach, das Stateformat funktioniert auch nicht... das wird nur angezeigt, wenn man die FB zum schalten nutzt.. Wenn man über FHEM schaltet, werden nur Icon's angezeigt. "Online" und "Version" sollten wahrscheinlich Readings sein?  Die gibts aber bei mir nicht.
Update2: wenn ich SetStateList lösche, dann ist der Status identisch bei FHEM/FB-Schaltaktion

[Beta-User]

Danke für das positive Feedback.

Wäre nicht das erste Mal, dass ein "Nieschenprodukt" erst mal bekannt sein mußte, bevor sich andere getraut haben . Und dein Dingens hat den Vorteil, dass es scheinbar mit manchen BT-Devices "kann". Habe mich damit nur kurz beschäftigt, aber das ist evtl. eine Sache, die für ganz viele Leute interessant ist, die heute glauben, dass man dafür einen Pi (oder Hersteller-GW's) braucht .

Außerdem hatte ich noch ein paar Optimierungsmöglichkeiten im Kopf, die ich aber in Ermangelung an Wissen nicht umzusetzen in der Lage war. Hier nochmal "dumm" nachzufragen hab ich mich dann nicht mehr getraut...

Mach' ruhig; ich habe nur das Problem, dass ich die Hardware nicht habe und daher nicht weiß, was zurückkommt (oder besser: Ich werde meinen Ersatz-Wemos nicht mit der firmware flashen). Erfahrungsgemäß klappt das aber schon, wenn du mir RAW-Infos liefern magst und deine Ideen versuchst zu verklickern...

(Ich habe auch einen ESP32 hier rumliegen, fällt mir beim Schreiben auf; ist evtl. doch interessant wegen der BT-Geschichte (kann der doch auch, wenn ich mich recht entsinne); mal sehen...)

Insgesamt liegen allerdings hier 3 Fernbedienungen davon rum und zur Weihnachtszeit werden die auch wieder eingesetzt. Ich habe auch im Sommer wieder schmerzhaft erfahren dürfen, dass diese alten 433Mhz Steckdosen fehlerunanfälliger sind, als die ESP Modelle. Ich habe im Garten eine Poolpumpe damit steuern wollen und die Induktive Last hat die ESP-Teile ALLE in einen Reboot geschickt.

Gegen Elektrosmog kann ich wenig machen, wir können nur versuchen, den irgenwie "sinnvoll" in FHEM verarbeitbar zu machen .

Folgende Ideen hatte ich noch im Kopf (wahrscheinlich ist das aber Klagen auf hohem Niveau):
-den RexEx Ausdruck mit einer Variable versehen .... z.B ValueOn & ValueOff...

Finde ich im Moment overdone und schwierig. Wer sowas nutzt, wird um eine individuellere Konfiguration kaum rumkommen bzw. darum, sich mit ein paar Grundlagen zu beschäftigen. Wir können aber versuchen, dazu eine Anleitung (comment und desc) zu liefern samt Readings, die einem dann das Leben erleichtern.

Was an Deinem Template derzeit nicht korrekt ist:
-die SetList geht auf das Topic: home/OpenMQTTGateway/commands/MQTTto433
-schaltet man über die FB, dann gibt's ein anderes ICON, als wenn man über FHEM schaltet.

Ansonsten funktioniert das mit dem Template super und spart beim Einrichten der anderen Tasten dann eine Menge Zeit :-D....

Die Fehlerchen usw. bügle ich gerne noch raus, wollte dir erst mal eine Basis liefern (du kannst das auch selbst weiterentwickeln und mir dann das Ergebnis/ein diff liefern, siehe "contributing") .

Für Deine "bridgeRegexp" Geschichte müsstes du sagen, was du brauchst... hab ich nicht so ganz verstanden....

Ist nicht ganz selbsterklärend. Aber du unterscheidest hier auch zwischen dem ESP (Online, wenn LWT übermittelt wird - ggf. mal neu starten ) und den einzelnen Dosen, die via 433MHz geschaltet werden (oder IR, oder ....). Eigentlich macht es Sinn, für den ESP und alle Endgeräte jeweils ein eigenes FHEM-Device zu haben, deswegen würde ich z.B. wenigstens alles, was über den 433toMQTT-Pfad reinkommt in ein eigenes Device umzuleiten, entsprechendes für IR, BT, ....
Wenn du Beispiele suchst: zigbee2mqtt und MiLight-Hub machen das ähnlich (aber prinzipbedingt weniger flexibel). Hier könnte man z.B. eine Art "Sammeldevice für 433MHz" anlegen, das erst mal alle Codes "roh" bekommt. Darauf könnte man dann ein template anwenden, das dann in einem Dialogfeld die Regex für die on/off-Befehle abfragt und die 4/8 Codes für die Auswertung der JSON-Blobs.

Ist aber - na ja - ziemlich fortgeschritten und evtl. etwas fancy für ein Nieschenprodukt .

[Dattel01]

Danke für das positive Feedback.

Gerne... ist ja in meinem Interesse, von meiner unqualifizierten Bastelimplementierung weg zu kommen :-D

Wäre nicht das erste Mal, dass ein "Nieschenprodukt" erst mal bekannt sein mußte, bevor sich andere getraut haben . Und dein Dingens hat den Vorteil, dass es scheinbar mit manchen BT-Devices "kann". Habe mich damit nur kurz beschäftigt, aber das ist evtl. eine Sache, die für ganz viele Leute interessant ist, die heute glauben, dass man dafür einen Pi (oder Hersteller-GW's) braucht .
Mach' ruhig; ich habe nur das Problem, dass ich die Hardware nicht habe und daher nicht weiß, was zurückkommt (oder besser: Ich werde meinen Ersatz-Wemos nicht mit der firmware flashen). Erfahrungsgemäß klappt das aber schon, wenn du mir RAW-Infos liefern magst und deine Ideen versuchst zu verklickern...

Das Thema sollte ja für meinen Fall eigentlich schon durch sein, denn die RegEx für "ReadingList" sowie "SetList" tun ja schon ihren Dienst. Manchmal ist das noch etwas wackelig, da OpenMQTTGateway auf MQTT2 scheinbar nicht alle Tasten zuverlässig durchzureichen scheint, oder meine Antenne/RF-Receiver nicht optimal ist/sind.

Gegen Elektrosmog kann ich wenig machen, wir können nur versuchen, den irgenwie "sinnvoll" in FHEM verarbeitbar zu machen .

Das sollte auch nur meine Begründung sein, warum ich in Zeiten von WLAN Steckdosen ala Shelly oder Gosund weiterhin das alte Zeug an bestimmten Stellen betreiben möchte.

Finde ich im Moment overdone und schwierig. Wer sowas nutzt, wird um eine individuellere Konfiguration kaum rumkommen bzw. darum, sich mit ein paar Grundlagen zu beschäftigen. Wir können aber versuchen, dazu eine Anleitung (comment und desc) zu liefern samt Readings, die einem dann das Leben erleichtern.

Agree!

Die Fehlerchen usw. bügle ich gerne noch raus, wollte dir erst mal eine Basis liefern (du kannst das auch selbst weiterentwickeln und mir dann das Ergebnis/ein diff liefern, siehe "contributing") .

Da ich das Gateway derzeit "NUR" mit dem 433Mhz Sender/Receiver und einem BME280 Temperaturfühler betreibe, werde ich zu den anderen Möglichkeiten wenig Input liefern können... Aber ansonsten - klar... Ich weiß nur nicht, ob z.B andere RollingCode Devices auch so gnädig sind, und zum Schalten (wie in meinem Fall) immer den selben Code aus FHEM akzeptieren.

Ist nicht ganz selbsterklärend. Aber du unterscheidest hier auch zwischen dem ESP (Online, wenn LWT übermittelt wird - ggf. mal neu starten ) und den einzelnen Dosen, die via 433MHz geschaltet werden (oder IR, oder ....). Eigentlich macht es Sinn, für den ESP und alle Endgeräte jeweils ein eigenes FHEM-Device zu haben, deswegen würde ich z.B. wenigstens alles, was über den 433toMQTT-Pfad reinkommt in ein eigenes Device umzuleiten, entsprechendes für IR, BT, ....
Wenn du Beispiele suchst: zigbee2mqtt und MiLight-Hub machen das ähnlich (aber prinzipbedingt weniger flexibel). Hier könnte man z.B. eine Art "Sammeldevice für 433MHz" anlegen, das erst mal alle Codes "roh" bekommt. Darauf könnte man dann ein template anwenden, das dann in einem Dialogfeld die Regex für die on/off-Befehle abfragt und die 4/8 Codes für die Auswertung der JSON-Blobs.

Wenn ich das richtig verstanden habe, dann gibts anschließend nur noch ein 433toMqtt-Master-Device mit einer ReadingList auf dem Topic und die Einzeldevices sind dann quasi "Kinder" dieses Master-Devices, erben gewisse Sachen, nur dass bestimmte Readings/Properties über das Template bestimmt werden (im konkreten Fall dann wohl die KeyCodes)....
Das wäre schon geil, aber in der Tat wohl für die Nische...

[Beta-User]

Was nicht erhaltene Messages angeht, würde ich auch eher die Hardware als Ursache sehen, nach meinen Erfahrungen geht MQTT-seitig nie was verloren.

Eine Begründung, warum man NICHT WLAN nimmt, brauche ich nicht, WLAN ist Begründung genug (ich nehme lieber andere Übertragungsmethoden und Protokolle, in der Regel nur nicht grade "klassisches" 433MHz) .

Interessant ist das GW vor allem wegen der BT-Sache, und da macht dann das mit passenden bridgeRegexp deutlich mehr Sinn. Werde ich bei Gelegenheit mal austesten (auch wenn die ESP32 ihre Daten via WLAN übertragen ). Wäre aber eh' nur für die Verbesserung der Anwesenheitserkennung; aber das kann auch manches Xiaomi-BT-Protokoll dekodieren und ist daher für deutlich mehr Leute interessant, als du jetzt evtl. mit Blick auf 433MHz denkst . Würde mich nicht wundern, wenn das Ding bald eine Ordnungsnummer deutlich weiter vorne bekäme . (und der eine oder andere als "Abfallprodukt" seinen 433MHz-Gruscht auf dieses GW umzieht...)

[Dattel01]

dann hab ich mit dem Verweis auf "OpenMqttGateaway" hier wohl was ins rollen gebracht :-D

ich habe das Template noch mal geringfügig verändert:
Ich hoffe, ich habe keine Typo's drin

• readingList um LWT und version erweitert/korrigiert. Ich weiß nicht, ob das notwendig ist, aber jetzt werden die Werte in ein Reading geschrieben, das war vorher irgendwie nicht der Fall
• setStateList raus, da das nicht zu funktionieren scheint??!
• devStateIcon auf online offline geändert

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
#Atm there are no furter commands to be set to the esp itself
name:OpenMQTTGateway_simple_RF433
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 }
attr DEVICE autocreate 1
attr DEVICE readingList\
  BASE_ID/OpenMQTTGateway/LWT:.* LWT
  BASE_ID/OpenMQTTGateway/version:.* version
  BASE_ID/OpenMQTTGateway/LWT online\
  BASE_ID/OpenMQTTGateway/433toMQTT:.* { $EVENT =~ m,..value..(13027392|13519216|12585648|13349168)..protocol..\d..length..\d+..delay..\d+.,? {"state"=>"on"} : $EVENT =~ m,..value..(13381408|13226144|13381408|13599888)..protocol..\d..length..\d+..delay..\d+., ? {"state"=>"off"}:undef }\
  BASE_ID/OpenMQTTGateway/433toMQTT:.* { $EVENT =~ m,..value..([\d]+)..protocol..\d..length..\d+..delay..\d+.,? {"received_code"=>"$1"}:undef }
attr DEVICE setList\
  on:noArg BASE_ID/OpenMQTTGateway/commands/433toMQTT {"value":"13027392","protocol":4,"length":24,"delay":350}\
  off:noArg BASE_ID/OpenMQTTGateway/commands/433toMQTT {"value":"13381408","protocol":4,"length":24,"delay":350}
attr DEVICE stateFormat online\
state\
Version: version
attr DEVICE devStateIcon online:10px-kreis-gruen offline.*:10px-kreis-rot
attr DEVICE model OpenMQTTGateway_simple_RF433

[Beta-User]

Wow, für einen ersten Wurf sehr gut!

(Nur ein paar fehlende "\").

Habe das mal wg. der BT-Geschichte/breidgeRegexp auf zwei templates aufgebohrt (naturgemäß noch nicht getestet). Könnte dann so aussehen:

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
#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
attr DEVICE bridgeRegexp\
  BASE_ID/OpenMQTTGateway/BTtoMQTT/([0-9A-Z]+):.* "oMQTTgw_BT_$1"\
  BASE_ID/OpenMQTTGateway/433toMQTT:.* "oMQTTgw_433"
attr DEVICE readingList\
  BASE_ID/OpenMQTTGateway/LWT:.* LWT\
  BASE_ID/OpenMQTTGateway/version:.* version\
  BASE_ID/OpenMQTTGateway/LWT online
attr DEVICE setList\
  BT_scan_now:noArg BASE_ID/OpenMQTTGateway/commands/MQTTtoBT/set {"interval":0}\
  BT_scan_interval:textField BASE_ID/OpenMQTTGateway/commands/MQTTtoBT/set {"interval":$EVTPART1}\
  BT_blacklist:textField BASE_ID/OpenMQTTGateway/commands/MQTTtoBT/set {"black-list":[$EVTPART1]}\
  BT_whitelist:textField BASE_ID/OpenMQTTGateway/commands/MQTTtoBT/set {"white-list":[$EVTPART1]}
attr DEVICE stateFormat online\
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
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_02a
par:BASE_ID;BASE_ID typically is home;{ AttrVal("DEVICE","readingList","") =~ m,([^:]+)[/]OpenMQTTGateway[/].*:, ? $1 : undef }
attr DEVICE autocreate 1
attr DEVICE readingList\
  BASE_ID/OpenMQTTGateway/433toMQTT:.* { $EVENT =~ m,..value..(13027392|13519216|12585648|13349168)..protocol..\d..length..\d+..delay..\d+.,? {"state"=>"on"} : $EVENT =~ m,..value..(13381408|13226144|13381408|13599888)..protocol..\d..length..\d+..delay..\d+., ? {"state"=>"off"}:undef }\
  BASE_ID/OpenMQTTGateway/433toMQTT:.* { $EVENT =~ m,..value..([\d]+)..protocol..\d..length..\d+..delay..\d+.,? {"received_code"=>"$1"}:undef }
attr DEVICE setList\
  on:noArg BASE_ID/OpenMQTTGateway/commands/433toMQTT {"value":"13027392","protocol":4,"length":24,"delay":350}\
  off:noArg BASE_ID/OpenMQTTGateway/commands/433toMQTT {"value":"13381408","protocol":4,"length":24,"delay":350}
attr DEVICE model OpenMQTTGateway_simple_RF433_switch

Alles, was via 433 reinkommt, landet in einem Device. Für einzelne 433-er dann den RAW-Code dieses Devices kopieren, dann Namen und die CID ändern, dann kannst du das 433-er Template anwenden (könnte man auch gleich per template machen mit der Kopie, ist eigentlich eine gute Idee, braucht aber noch Zeit zum reifen).

Alles, was via BT kommt, landet ebenfalls jeweils in einem Device (wie bei zigbee2mqtt, hoffe ich jedenfalls).

Über den MCU-Code kann man die Listen verwalten und einen BT-Scan anstoßen usw..

Topics usw. habe ich von hier: http://docs.openmqttgateway.com/#/use/ble (ist auch für mich selbst zum wiederfinden...)

[Dattel01]

Jetzt bin ich raus. 

Und dann stelle ich jetzt doch dumme Fragen.
Vielleicht kannst du mir da mal unter die Arme greifen:

In meinem Fall funktioniert das ganze aber auch, wenn ich NUR mit dem RF433 Template arbeite... wofür genau brauche ich das MCU-Device?
Sowohl MCU als auch RF433 haben eine ReadingList.. Also wozu muss MCU da was forwarden, wenn RF433 ja selber Readings hat.
Konkret versteh ich gerade nicht, wo es das Ganze vereinfacht.

Alles, was via 433 reinkommt, landet in einem Device. Für einzelne 433-er dann den RAW-Code dieses Devices kopieren, dann Namen und die CID ändern, dann kannst du das 433-er Template anwenden.

Vielleicht versteh ich das Gesamte auch, wenn ich das hier verstehe.. Gerade die Passage mit dem Namen/CID erschließt sich mir nicht... Meinst du den kompletten RAW Code der im Topic kommt? Das ist ein JSonString, den kann ich doch mit den Klammern und Freizeichen nicht als Namen für ein DEvice verwenden.

Anmerkung für das MCU-Template: hier fehlt die Abfrage des BASE_ID Parameter beim Anwenden des Templates
Anmerkung für das RF433-Template: set List muss an MQTTto433 senden und nicht an 433toMQTT

[Beta-User]

 

Sorry, wenn ich dich etwas verwirre...

Also: Solange du nur ein einziges 433-er Device hast, wird das immer "seltsam" erscheinen, warum man für ein paar Readings, die sich mit einem Blick erfassen lassen so viele Devices "braucht".

ABER: Der code auf dem Microcontroller (MCU, bei dir: der ESP8266) ist eine universelle "Relaisstation" für ganz unterschiedliche Dinge.

Da möchte ich gerne den ESP (mcu) separat sehen, und damit nur den Zustand des ESP's visualisieren und ggf. Einstellungen daran vornehmen.

Für den 433-er Zweig würde ich dann ein weiteres Hilfsdevice sehen, das z.B. den letzten empfangenen RF-Code in seinen Einzelteilen zeigt, die man dann z.B. dafür nutzen kann, die eigentlichen 433-er-Geräte zu bauen (bei dir z.B. weitere 4 Geräte, drei für die einzelnen on/off, eines für die Gruppe).

Das "Zwischendevice" muß ich noch bauen, hier aber mal ein Vorschlag, wie man durch das Anwenden eines Templates auf das "Zwischendevice" ein neues baut und Parameter abfragt, dann wird das ganze evtl. etwas klarer...

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
#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 }
attr DEVICE bridgeRegexp\
  BASE_ID/OpenMQTTGateway/BTtoMQTT/([0-9A-Z]+):.* "oMQTTgw_BT_$1"\
  BASE_ID/OpenMQTTGateway/433toMQTT:.* "oMQTTgw_433"
attr DEVICE readingList\
  BASE_ID/OpenMQTTGateway/LWT:.* LWT\
  BASE_ID/OpenMQTTGateway/version:.* version\
  BASE_ID/OpenMQTTGateway/LWT online
attr DEVICE setList\
  BT_scan_now:noArg BASE_ID/OpenMQTTGateway/commands/MQTTtoBT/set {"interval":0}\
  BT_scan_interval:textField BASE_ID/OpenMQTTGateway/commands/MQTTtoBT/set {"interval":$EVTPART1}\
  BT_blacklist:textField BASE_ID/OpenMQTTGateway/commands/MQTTtoBT/set {"black-list":[$EVTPART1]}\
  BT_whitelist:textField BASE_ID/OpenMQTTGateway/commands/MQTTtoBT/set {"white-list":[$EVTPART1]}
attr DEVICE stateFormat online\
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
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:BASE_ID;BASE_ID typically is home;{ AttrVal("DEVICE","readingList","") =~ m,([^:]+)[/]OpenMQTTGateway[/].*:, ? $1 : undef }
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;undef
defmod DEVICE_NEW MQTT2_\DEVICE
attr DEVICE_NEW autocreate 0
attr DEVICE_NEW readingList\
  BASE_ID/OpenMQTTGateway/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/OpenMQTTGateway/433toMQTT:.* { $EVENT =~ m,..value..([\d]+)..protocol..\d..length..\d+..delay..\d+.,? {"received_code"=>"$1"}:undef }
attr DEVICE_NEW setList\
  on:noArg BASE_ID/OpenMQTTGateway/commands/MQTTto433 {ON_COMMAND}\
  off:noArg BASE_ID/OpenMQTTGateway/commands/MQTTto433 {OFF_COMMAND}
{ fhem "trigger $FW_wname JS:location.href='$FW_ME?detail=DEVICE_NEW'" if($cl && $cl->{TYPE} eq "FHEMWEB") }
farewell:template has been applied successfully.
attr DEVICE_NEW model OpenMQTTGateway_simple_RF433_switch
(Ich hoffe, jetzt die beiden Fehler auch ausgebügelt zu haben...)
Später evtl. mehr, muß mal sehen, ob ich den ESP32 geflasht bekomme (Neuland ).

[Dattel01]

Hab's eingespielt und den aktuellen Stand getestet.....
Auch die Parameterabfrage tut es super..

Eine kleine Anmerkung:

Anstelle

Code Auswählen Erweitern

attr DEVICE stateFormat online\
Version: version
noch

Code Auswählen Erweitern

attr DEVICE stateFormat LWT\
Version: version

dann klappt es ohne Nacharbeiten..

Wenn du beim Flashen irgendwie einen Gedankenanstoß brauchst, dann sag bescheid...
Ich hab das Teil mittlerweile mehrfach geflashed mit ArduinoIDE oder VS-Code auf NODEMCU-V3 und ESP01s..
Hier bei mir laufen 3 OpenMQTT-Boards. 2 davon nur mit BME280 Chip für Temperatur/Luftdruck/Feuchtigkeit und der dritte mit eine Kombination aus RF433 und BME280.
Für RF habe ich viele andere Gateways probiert und OpenMQTTgateway hat sich echt als einfach/stabil erwiesen.

[Beta-User]

Nach den ersten rudimentären Gehversuchen mit dem ESP32 habe ich jetzt mal folgenden Stand:

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
#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"
attr DEVICE readingList\
  BASE_ID/DEVNAME/LWT:.* LWT\
  BASE_ID/DEVNAME/version:.* version
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://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
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; { ReadingVal("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

Mal schauen, wie sich das weiterentwickelt und was da an BT so geht...