WORKSHOP: MQTT und Sonoffbridge in Verbindung mit Bewegungsmeldern - 433Mhz

[Beta-User]

Also:
Teil 1a ist gelöst und dein Eventhandler funktioniert scheinbar auch "wieder" so wie du das haben wolltest.

Wie ist es mit Teil 1b und/oder der Optimierung deines "Hauptdevices" im Hinblick auf die Gesamtzahl der Events?

Interesse daran, wie man die Querbeziehung zwischen dem Haupt- und den Nebendevices für FHEMWEB transparent machen kann?

Es gab doch mal attr timeout sek. Gibt es den nicht mehr? Weil damit konnte man wohl devices zurücksetzen. Habe ich so gelesen.

Taucht sowas denn  in der commandref auf oder gibt es das  in der Auswahlliste in FHEMWEB?

Es ist alles so einfach 

Aha...

[Kuehnhackel]

Mahlzeit 

Taucht sowas denn  in der commandref auf oder gibt es das  in der Auswahlliste in FHEMWEB?

es gibt einen Thread dazu
https://forum.fhem.de/index.php?topic=73001.0

Wie ist es mit Teil 1b und/oder der Optimierung deines "Hauptdevices" im Hinblick auf die Gesamtzahl der Events?
Interesse daran, wie man die Querbeziehung zwischen dem Haupt- und den Nebendevices für FHEMWEB transparent machen kann?

Kommt drauf an wie "schwer" die Kost ist 

[Kuehnhackel]

Eine Frage habe ich dann noch
es gibt ja die readinglist für die Kontakte - hier closed

Code Auswählen Erweitern

tele/SonoffBridge/RESULT:.* { $EVENT =~ m,..RfReceived....Sync..([A-Za-z0-9]+)..Low..([\d]+)..High..([\d]+)..Data...D2210E...RfKey...([A-Za-z0-9]+)..., ? { state=>"closed"} : undef }

kann ich für open auch das reading mit state bennenen

Code Auswählen Erweitern

tele/SonoffBridge/RESULT:.* { $EVENT =~ m,..RfReceived....Sync..([A-Za-z0-9]+)..Low..([\d]+)..High..([\d]+)..Data...D2210A...RfKey...([A-Za-z0-9]+)..., ? { state=>"open"} : undef }
oder muss es state1 heißen?

Code Auswählen Erweitern

tele/SonoffBridge/RESULT:.* { $EVENT =~ m,..RfReceived....Sync..([A-Za-z0-9]+)..Low..([\d]+)..High..([\d]+)..Data...D2210A...RfKey...([A-Za-z0-9]+)..., ? { state1=>"open"} : undef }

[Beta-User]

Vielleicht erst mal noch etwas Theorie: am Ende jeder readingList-Zeile steht entweder ein Perl-Aufruf oder "Klartext" für den Readingnamen, in den die payload rein soll (oder man kann statt payload auch $EVENT sagen).
Diese beiden Zeilen bewirken also im Ergebnis dasselbe:

Code Auswählen Erweitern

  tele/SonoffBridge/RESULT:.* { { tele_RESULT => $EVENT } }

Code Auswählen Erweitern

  tele/SonoffBridge/RESULT:.* tele_RESULT
Verwendet man Perl (erste Variante), muss ein Hash zurückgegeben werden (oder "nichts"), dann wird der Hash (eine Liste mit "Name"=>"Wert"-Zuweisungen) in Readings aufgedröselt.

Da in der "doppelten" Sensor-readingList jeweils nur entweder das eine oder das andere zutreffen kann, ist das völlig ok mit dem doppelten "state".

Schwieriger wäre es, wenn beide topics gematcht werden könnten, dann ist es nämlich zufällig, welche der beiden Zeilen zuerst bzw. zuletzt aufgerufen/ausgeführt wird.

es gibt einen Thread dazu
https://forum.fhem.de/index.php?topic=73001.0

Habe kurz reingesehen, aber auf die Schnelle ging es da um Jeelink, und das ist was ganz anderes...

Kommt drauf an wie "schwer" die Kost ist 

Eigentlich mAn. nicht besonders schwer, eher Grundlagen, und mit obigen Ausführungen und dem, was bereits hier geschrieben war, sollte zumindest eine "Basislösung" für dich machbar sein. Die Kür wäre, für das "Beseitigen" beider Zweige nur eine Zeile zu "verschwenden"... Auch dazu findet sich in diesem Thread schon das Baumaterial, wenn auch etwas versteckter .

[Kuehnhackel]

Hierüber sollten wir auch noch mal sprechen, weil zu "benannten sleeps" finde ich nicht viel 

Man könnte es auch zurücksetzen, hier ggf. "am einfachsten" mit einem userReadings, das ein (benanntes) sleep anlegt und dann nach Zeitablauf state auf "nomotion" setzt. Benanntes sleep deswegen, weil das dann ein ggf. laufendes erneuern sollte, wenn nochmal motion gemeldet wird (trigger passend setzen)...

Auf die Gefahr, dass ich mich wieder zum Gespött mache, dann mal los.

[Beta-User]

Na ja, ihr seid doch durchaus auch ohne mich weitergekommen in dem anderen Thread dazu...

Von daher: macht doch erst mal weiter, wobei ich dazu folgendes anmerken würde:
- ich würde in einen "Pseudoreading-Namen" für das userReading vergeben und den trigger wirklich auf "state.motion" begrenzen. Pseudo-Namen deswegen, weil wir das nur brauchen, damit wir eine definierte Stelle haben, um "unseren" Perl-Code in die Eventverarbeitung einzuschleusen.
- Es handelt sich um eine Sache, die hart an der Grenze zum "Missbrauch" von userReadings liegt, von daher muss das nicht unbedingt so klappen, wie ich vermute; ich weiß auch nicht alles und muss es ggf. auch austesten...

Und bisher ist kein Popcorn-Zug hier vorgefahren, was aber vermutlich irgendwann passiert, sollte ich nicht weiter nach Teil 1b) der Aufgabe betr. der Eliminierung der unnötigen Trigger fragen... Also: Wie schaut es damit aus ?

[Kuehnhackel]

Auf die Gefahr, dass ich mich wieder zum Gespött mache, dann mal los.

s.oben

[Beta-User]

...dann also zum dritten...

[...]
- die "discovery"-Zweige kannst du direkt auschalten ({}) und am besten dafür eine ignoreRegexp am IO setzen.

Das mit der ignoreRegexp hatten wir schon, dann also nochmal mit dem Klammerinhalt und gleich universell für beide Zweige die betreffende eine Zeile für die readingList:

Code Auswählen Erweitern

tasmota/discovery/2CF432BF00E2/(config|sensors):.* {}
Es wird also für alles, was über diese beiden Zweige kommt einfach leerer Perl-Code aufgerufen, der nichts zurückgibt, also insbesondere keinen Hash .

[Kuehnhackel]

dann also nochmal mit dem Klammerinhalt und gleich universell für beide Zweige die betreffende eine Zeile für die readingList:

Code Auswählen Erweitern

tasmota/discovery/2CF432BF00E2/(config|sensors):.* {}
Es wird also für alles, was über diese beiden Zweige kommt einfach leerer Perl-Code aufgerufen, der nichts zurückgibt, also insbesondere keinen Hash .

das heißt die beiden Zeilen müssen dafür in der readingslist gelöscht werden?

Code Auswählen Erweitern

tasmota/discovery/2CF432BF00E2/config:.* { { discovery_config => $EVENT } }
tasmota/discovery/2CF432BF00E2/sensors:.* { { discovery_sensors => $EVENT } }

[Beta-User]

Genau. Wir brauchen das nicht, was darüber kommt, daher wird es nach "nirwana" umgeleitet, that's all...
(für Mitleser: das wäre mein genereller Vorschlag für attrTemplate zu Shelly betr. den Fahrenheit-Wert, und wer mitliest, bekommt jetzt wohl auch eine ignoreRegexp dafür an sein IO gebastet, was noch besser ist...)

[Kuehnhackel]

Wie ist es mit Teil 1b und/oder der Optimierung deines "Hauptdevices" im Hinblick auf die Gesamtzahl der Events?
Interesse daran, wie man die Querbeziehung zwischen dem Haupt- und den Nebendevices für FHEMWEB transparent machen kann?

Wie geht es weiter?

[Beta-User]

Querbeziehungen:
es gibt dafür ein "spezielles" Reading , nennt sich "associatedWith". Da muss man einfach die Namen des jeweils anderen Devices reischreiben.
Wie: siehe setreading in der commandref.

Für den Rest: bitte mal den "Haupt-" Workshop zum Thema jsonMap durchforsten und etwas mit event-on-change-reading und Co rumspielen...

Wir machen weiter, wenn du dazu ein RAW-listing lieferst, das die bisherigen Erkenntnisse am Hauptdevice vollständig wiederspiegelt und Ansätze von jsonMap und event-on-.* erkennen läßt?

[Kuehnhackel]

Okay. Bis später