Flankensteuerung (trigger?) in Verbindung mit DOIF?

[M_I_B]

Hallo liebe Leute,

ich habe mich aus beruflichen und familiären Gründen lange Zeit nicht mehr mit FHEM beschäftigt. Seinerzeit hatte ich einige Sachen rausgeschmissen, die nicht zuverlässig funktionierten (GeoFancy, Präsenz, ...) und war mit dem zufrieden, wie es lief.

Nun habe ich zwischendurch etwas mehr Zeit und wollte mal so ein paar Dinge umschreiben, die aus den gemachten Erfahrungen nicht so gut funktionieren. Dabei bin ich auf ein Problem gestoßen, für das es sicherlich eine Lösung gibt, ich diese Lösung allerdings hier nicht wirklich finden konnte resp. übersehen habe...

Ich lege mal los...

Basis ist ein Slider- Dummy der folgenden Art, der als Beispiel gelten soll:

Code Auswählen Erweitern

define 321l_au dummy
attr 321l_au alias Automatik Licht (Decke, Fenster, frei, Morgenlicht)
attr 321l_au group Automatik
attr 321l_au readingList a b c d
attr 321l_au room 321 - Büro
attr 321l_au setList a:slider,-1,1,2 b:slider,-1,1,2 c:slider,-1,1,2 d:slider,-1,1,2
attr 321l_au sortby 31
attr 321l_au stateFormat {' ;'}
attr 321l_au webCmd a:b:c:d
define set_321l_au DOIF (["321l_au"]) (set 321l_au [321l_au:a] - [321l_au:b] - [321l_au:c] - [321l_au:d] )
attr set_321l_au do always

Ist der Wert kleiner Null, soll das Zielgerät immer aus sein, ist er Null, ist die Automatik in betrieb. Ist er 1 soll die manuelle Steuerung aktiv sein, bei 2 ist das Gerät immer an.

Ziel dieses Dummy's ist z.B. eine IT- Steckdose:

Code Auswählen Erweitern

define set_321l_au_b DOIF ([321l_au:b] < 0) (set IT1SW24 off) DOELSEIF ([321l_au:b] == 2) (set IT1SW24 on) \
DOELSEIF ([321l_au:b] == 0 and [TGZ] == 2 and [321l_sl:b] > 0 and [LUM:state] < [321l_sl:b] and [LUM:T] < 0 and [IT1SW24] eq "off") (set IT1SW24 on) \
DOELSEIF ([321l_au:b] == 0 and [TGZ] != 2 and [321l_sl:b] > 0 and [LUM:state] > [321l_sl:b] and [LUM:T] > 0 and [IT1SW24] eq "on") (set IT1SW24 off) \
DOELSEIF ([321l_au:b] == 0 and [TGZ] >= 2 and [PTV] == 1 and [321l_tv:state] != 0 and [IT1SW24] eq "on") (set IT1SW24 off)
attr set_321l_au_b do always
attr set_321l_au_b wait 0:0:0:0:[321l_tv:state]*60

Hier spielen noch andere Werte eine Rolle, wie z.B. die Tageszeit (TGZ), Außenhelligkeit (LUM) und Helligkeits- Schwellwerte (321l_sl:). Zudem spielt auch "Präsenz" des TV eine Rolle, aber nur nebensächlich.


Nun zum Problem:
Diese ganze Steuerung funktioniert so weit seit Monaten, hat aber einen eklatanten Haken. Die ganze Befehlskette ist durchweg zustandsgesteuert und nicht flankengeteuert. Heißt im Klartext, das es z.B. am Tage nicht möglich ist, im Automatikbetrieb die Steckdose einzuschalten; sie wird i.d.R. sofort wieder abgeschaltet (klick...klack). Wenn alle  Automatik- Bedingungen zum Einschalten erfüllt sind, natürlich anders herum; lässt sich nicht ausschalten. Das führt u.a. zu solch merkwürdigen Effekten, das im Frontend das ICON der Steckdose den Status OFF behält, obwohl die Steckdose eingeschaltet wurde (oder umgekehrt).

Was ich erreichen möchte:
Das Zielgerät, in diesem Fall der IT-Aktor, soll nur auf Flanken reagieren. In Anlehnung an die Digitaltechnik erhält der Aktor derzeit einen Zustand übergeben. Ist dieser Zustand ON, habe ich keine Chance, aus anderer Quellen diesen Zustand zu ändern; er wird sofort wieder auf ON gesetzt. Ich könnte lediglich den Zustand des gerade befehlenden Gerätes/Dummy's/... was auch immer... ändern. Das wiederum würde letztlich aber zu fast undurchschaubaren, verketteten Strukturen führen, die m.E. nicht zielführend sind.  Wenn ich aber mit Flanken arbeiten könnte, der Aktor z.B. von einem DOIF oder Dummy ein ON erhält (steigende Flanke), kann ich jederzeit den Aktor aus anderer Quelle mit einer fallenden Flanke (OFF) wieder abschalten (oder umgekehrt natürlich).


Frage ist nun, wie man so etwas am schlausten regelt? Ich will nicht in Abrede stellen, das ich hier schon vom Ansatz her vollkommen falsch liege. Wenn dem so ist, finde ich den gedanklichen Ausgang nicht, um einen vollkommen anderen Lösungsansatz zu generieren.

Daher meine Bitte an die Forengemeinde, mir mal auf den richtigen Weg zu helfen und ggf. meine gedankliche Endlosschleife zu durchbrechen...

[Ellert]

Ohne alles nachvollzogen zu haben, denke ich, dass das, was Du als Flankensteuerung bezeichnest in FHEM Eventsteuerung heisst.

Eine Flanke existiert nur im Moment ihres Auftretens, das gilt auch für ein Event oder Ereignis.

Auf DOIF bezogen

[device:reading] löst zustandsbezogen aus, sofern irgendein Event von "device" auftritt.
[<device>:"<regex>"] löst nur bei einem bestimmten Ereignis aus.

[Brockmann]

Das konkrete Problem scheint mir in dem Fall zu sein, dass der Zustand des Aktors eine triggernde Bedingung ist. Dadurch lösen manuelle Änderungen am Aktor das DOIF aus und das schaltet den Aktor dann wieder um.
Aber muss der Aktor denn eine triggernde Bedingung sein? Wenn Du mit [?...] arbeitest, bleibt der Zustand des Aktors als Bedingung, aber Änderungen triggern nicht mehr. Dann würde das DOIF manuelles Eingreifen ignorieren.

[M_I_B]

... erst mal meinen Dank Euch beiden! Beide Informationen könnten zielführend sein ...

@Ellert:
Die Sache mit den Events, also wann ein Zustand (statisch) und wann ein Event (Flanke) (weiter)gegeben wird, war mir noch nie wirklich klar, da ich die Logik dahinter nie erfassen konnte. SO ganz ist mir das immer noch nicht klar, aber ich habe erkannt , worauf Du hinaus willst. Ich werde also mal ein bisschen umschreiben und probieren like "learning by doing".

@Brockmann:
Stimmt; Du hast vollkommen recht! Auf die Idee wäre ich nie im Leben gekommen. Über so was liest man irgendwie immer drüber, wenn man's selbst verbrochen hat... Probiere ich aus...


Noch mal eine Frage im Zusammenhang mit Trigger o.ä. ...
In diesem Beispiel wird der Wert in LUM aus den Werten der Lichtsensoren mehreren HM- Bewegungsmelder verwurstet (gleitende Mittelwertbildung). Das funktioniert eigentlich perfekt nebst Generierung einer Tendenz (über alle für den Mittelwert gespeicherten Werte). Einen Haken hat die Sache dennoch:
Wenn der Mittelwert sagt, das die Sensoren die Außenbeleuchtung einschalten darf, dann kommt es in der Nähe des Schwellwertes zu unschönen Effekten, das z.B. das Licht im Haus abgeschaltet wird; es ist ja draußen heller geworden und somit ein Schwellwert überschritten... Die Schwellwerte für diverse Räume und Aktoren sind vollkommen unabhängig voneinander...
Ich hatte das mal so gelöst, das ich in diesem Fall die Mittelwerte eingefroren habe, so lange die Außenbeleuchtung in Betrieb ist. Das erforderte aber bei meiner Infrastruktur ein kreuz- und quer - Triggern, wann eingefroren und wann wieder freigegeben werden soll. Sehr unübersichtlich und fehlerträchtig.
Gibt es denn irgend eine Möglichkeit, solche Werte direkt im Device einzufrieren und den "Froster" mit einem Trigger bei "Licht draußen ist wieder ausgegangen" abzuschalten?

... ja sorry, etwas wirr geschrieben... Aber ich hoffe, es lässt sich erkennen, was mein Problem ist?!?

[Brockmann]

Meinst Du mit Beispiel das aus dem ersten Post oder wolltest Du hier noch Code einfügen?

Ich hatte das mal so gelöst, das ich in diesem Fall die Mittelwerte eingefroren habe, so lange die Außenbeleuchtung in Betrieb ist. Das erforderte aber bei meiner Infrastruktur ein kreuz- und quer - Triggern, wann eingefroren und wann wieder freigegeben werden soll. Sehr unübersichtlich und fehlerträchtig.
Gibt es denn irgend eine Möglichkeit, solche Werte direkt im Device einzufrieren und den "Froster" mit einem Trigger bei "Licht draußen ist wieder ausgegangen" abzuschalten?

Wenn Du mit Device die Bewegungsmelder meinst, geht das meines Wissens nach nicht. Es gibt bei HM-Bewegungsmeldern das Register brightFilter, mit dem man kürzere Helligkeitspeaks ausbügeln kann. Aber wenn die Außenbeleuchtung länger an ist, wird das nicht helfen. Ein DOIF hingegen könntest Du jederzeit disablen, solange die Außenbeleuchtung an ist. Aber das könnte auch wieder unschöne Seiteneffekte haben.
Das grundlegende Problem ist, dass Du für Deine Steuerung Sensoren nutzt, die unter bestimmten Bedingungen "falsche" Werte liefern. Da kannst Du zwar in der Logik dann in gewissen Grenzen "drumrum" programmieren, aber wie Du selbst schreibst, ist das aufwändig und fehleranfällig.

Ich verwende selbst auch einen HM-Bewegungsmelder für meine Lichtsteuerung. Allerdings habe ich den bewusst an einer Stelle montiert, wo er als Bewegungsmelder völlig unsinnig ist. Aber ich habe diese Stelle nach reiflicher Überlegung ausgewählt, weil er dort geschützt ist und von künstlichen Lichtquellen höchstens minimalst beinflusst werden kann. Dadurch bekomme ich einen zuverlässige Wert für die Umgebungshelligkeit, den ich ohne weitere Vorsichtsmaßnahmen an verschiedenen Stellen meiner Haussteuerung verwenden kann.

Ist sicher auch eine Kostenfrage, aber mir war es das wert. Mittlerweile würde ich es kostengünstiger mit einem Arduino und ESPEasy umsetzen, aber damals war ich mit meinem Wissen und dem Vertrauen in meine Lötfähigkeiten noch nicht soweit... 

[M_I_B]

... nope, der Code aus dem ersten Beitrag hat damit nur sekundär was zu tun.
Letztlich nehme ich die Werte bei Eintreffen und  schreibe die in die insg. 10 Readings eines Dummys, Diese Werte schiebe ich bei Auflaufen eines neuen Wertes durch  (FIFO). Nun gehe ich hin und ermittle aus allen gespeicherten Readings des Dummy's einen Mittelwert, wobei ich vorher schaue, ob ein Ausreißer dabei ist (Einzelwert >/< 10% des vorher ermittelten Gleitwertes), welcher dann ignoriert wird.
Bin gerade auf Arbeit, aber wenn's interessiert, reiche ich den Snippet nach... Ist aber eigentlich trivial...

Tja, das es mit den HM's nicht klappt, dachte ich mir schon. Hätte aber ja sein können, das ich mangels (Fach-) Wissen eine Option schlichtweg übersehen habe. Aber wenn Du auch sagst, das so was nicht so ohne weiteres geht, hatte ich ja schon die richtige Ahnung. Und das mit dem DOIF abschalten hatte ich auch schon mal versucht... vergiss es... Da kommt alles Mögliche bei raus, aber i.d.R. nicht das, was man erwarten sollte; ich zumindest habe es damit nicht wirklich sinnvoll umsetzen können...

Arduino und ESPEasy

? Hasse ma'n Link ? Ist die Sache in der Lage, 4 Sensoren (4 Quadranten) zu verwursten? Dann würde ich so was mal versuchen umzusetzen und den ganzen Trum auf's Dach packen nebst Lichtschirm nach unten. Dann sollte tatsächlich nur noch das vom Himmel einfallende Licht ausgewertet werden (wenn Jener uns nicht auf den Kopf fällt...)... hmmm... Je mehr ich darüber nachdenke, um so sympathischer finde ich das, vor allem weil diese Lösung nix mit HM/EQ3/ELV zu tun hat 

[Brockmann]

Letztlich nehme ich die Werte bei Eintreffen und  schreibe die in die insg. 10 Readings eines Dummys, Diese Werte schiebe ich bei Auflaufen eines neuen Wertes durch  (FIFO). Nun gehe ich hin und ermittle aus allen gespeicherten Readings des Dummy's einen Mittelwert, wobei ich vorher schaue, ob ein Ausreißer dabei ist (Einzelwert >/< 10% des vorher ermittelten Gleitwertes), welcher dann ignoriert wird.

Wenn Du den Zustand der Außenbeleuchtung kennst, könntest Du schon vermeiden, dass bei eingeschaltetem Licht neue Messwerte von dadurch betroffenen Sensoren einfließen. So würdest Du das Problem an der Quelle aussortieren.

ESPEasy:
https://www.letscontrolit.com/wiki/index.php/ESPEasy

Ist erstmal das Wesentliche. Passende Hardware kannst Du nach Geschmack wählen.
Dann schauen, welche Lichtsensoren ESPEasy von Hause aus unterstützt und die an die Hardware anschließen.

Dann flasht Du das Device mit ESPEasy per USB oder evtl. sogar OTA.
Ab da kannst Du das Device dann einfach per WebUI konfigurieren.
In FHEM benötigst Du das ESPEasy-Modul, dass die Daten entgegennimmt.

Ich bin mir nicht sicher, ob Du verschiedene Sensorwerte in ESPEasy selbst verrechnen kannst. Aber es gibt da "Rules", mit denen das eventuell möglich ist. So tief bin ich da selbst noch nicht drin.
Aber in jedem Fall bekommst Du die einzelnen Sensorwerte in FHEM reingereicht und kannst sie dort beliebig verrechnen.
Ansonsten kannst Du für Arduino auch andere Firmware verwenden. Ist zwar aufwändiger, aber eben auch flexibler. Da kannst Du Dir sicher dann eine beliebige Logik reinprogrammieren.
Wobei ich es ohnehin vorziehen würde, die einzelnen Sensorwerte in FHEM zu haben. Alleine schon um nicht jedes Mal Änderungen an der Logik im Device selbst vornehmen oder das Teil womöglich jedes Mal neu flashen zu müssen...

[M_I_B]

... erst mal Danke für den Link; das schaue ich mir mal genauer an ...

Den direkte Eingriff in die Wertebildung "an der Wurzel" hatte ich auch schon mal probiert; hat nicht wirklich hingehauen... Haken daran ist die zeitlich nicht wirklich kalkulierbare Abfolge:
Sensoren liefern nicht synchron ihre LUM- Werte. Kommt ein Wert (event) wird neu berechnet. Parallel dazu löst ein PIR- Event den jeweiligen Timer aus (nebst logischer Verkettung der einzelnen Lichtgruppen). In diesem Moment müsste ich eigentlich die Werte einfrieren. Aber durch die Laufzeiten bedingt kann man an der Stelle nicht wirklich sagen, ob in den LUM- Werten bereits ein Falschwert durch die Lichtgruppen detektiert wurde oder nicht, und wenn, an welcher Stelle der im FIFO steht. Das wiederum führte dann zu weiteren Effekten, die zudem zeitverzögert auftraten. Ein zeitlicher Nachgriff (Mittelwert vom aktuellen Zeitpunkt minus Timerzeit minus Sicherheitsspanne) war auch nicht zielführend, da dann in der Folgekette unakzeptable Verzögerungen auftraten, wobei ich im Moment nicht weiß, ob das an meinem Unvermögen lag, die Sache richtig zu programmieren oder nicht...

Daher ist Deine Idee mit dem Fremdlicht- resistenten Sensor an potenter Stelle sicherlich die beste Lösung. Vielleicht kann ich auch einen unserer Programmierer mit Bölkstoff o.ä. dazu animieren, die Sache an 4 Quadranten anzupassen. Zudem spricht m.E. nichts dagegen, die Auswertung (Mittelwert) direkt in der FW zu machen, wenn man zeitgleich auch die RAW- Werte an FHEM weiter gibt. Dann ist man in alle Richtungen flexibel genug... Das Ding muss ja nicht mit Batterien laufen. Eine direkte Stromversorgung oder bestenfalls Solar/Li-Ion als autarke Versorgung tut's ja auch ...

EDIT sagt:
Ich habe mal ein bisschen quer gelesen... Mehrere Sensoren sind kein Thema. Da ich sowieso I²C- Lichtsensoren bevorzuge, kann ich davon ja problemlos 4 Stück auf einen Bus hängen, so lange ich am gewählten Bauteil insg. 4 unterschiedliche Adressen vorgeben kann (müssten hier noch ein paar rumliegen...). Ein paar "WeMOS'se" liegen auch noch irgend wo rum... also hätte ich theoretisch alles da, um damit mal rumzufrickeln
Wenn ich das richtig verstanden habe, ist die FW auf insg. 12 Geräte/Sensoren begrenzt. Also dann (für mich) 4 x LUM, 1 x UV, 2 x TMP, 1 x HUM ... perfekt! Und Ausgänge hat#s ja auch noch einige, die, wenn dann auf dem Dach montiert, eine LightShow für Alarmmeldungen, Weihnachten oder Silvester generieren könnte (hoher WAF)
UV fällt erst mal flach. Die Masse der mir bekannten UV- Sensoren mit I²C sind abgekündigt, die noch Erhältlichen haben nur eine Adresse, die genau im Bereich meiner Tageslicht- Sensoren (OPT3001-Q1) liegen... doof...

[M_I_B]

Kleines Update:

Mit meinen vorhandenen Wemos Mini gab es ein Problem: Auf dem Dach hatten die kaum noch Kontakt zum WLAN im Haus. Die metallisierte Dämmung im Dach und auch die PV- Anlage schirmt zu stark. Daher habe ich mir noch 5 Mini+ besorgt, an welche man eine ext. TanteEnne anschließen kann; das haut prima hin

Das Flashen des EasyESP war überhaupt kein Problem; ziemlich geniales Stück Software! Ich habe gleich überall die 2.0.0 "normal" geflasht, die doch um einiges besser ist als das offizielle Release. Außerdem habe ich alle gleich auf MQTT umgestellt. Also ein paar LED dran (mit Treiber-FET), Akku dran, in transparente Tupperdose und probehalber mal auf's Dach gestellt (war Sonnabend ganz schön glitschig da oben...). Perfekt!

Nun warte ich noch auf das Eintreffen der Tageslichtsensoren (OPT3001) und der Kombisensoren von Bosch (BME280: Luftdruck, Luftfeuchte, Temperatur) so wie auf ein paar Solarzellen, die in Verbindung mit einer LiION dann das Teil autark versorgen soll (Sleepmode, WakeUp alle 60 Sekunden, absetzen der Werte per MQTT, Sleepmode). Ob das mit der LiION auch im Sommer funktioniert, wird sich zeigen. Da oben wird's doch ziemlich heiß...

Im Zusammenhang mit den WEMOS bastel ich auch gerade an einer Platine/Schaltung, um die Teile als bidirektionalen Mehrkanal- Schalter für z.B. Steckdosenleisten zu verwenden...

Bin ja mal gespannt, ob das nachher alles so funktioniert, wie ich mir das gedacht habe. Einen Haken habe ich jetzt schon gefunden: Mir gehen die IP- Adressen langsam aus. Wenn ich die also in Zukunft exzessiver einsetzen möchte, muss ich wohl ein weiteres WLAN aufspannen, was dann ausschließlich für solche Dinge zuständig ist. Hätte den Vorteil, das ich direkt dort das "nach Hauses telefonieren" für alle WLAN- Teile (habe noch einige RGBW- Ufo's u.ä. in Betrieb) zentral unterbinden kann...

Nun gut... schauen wir mal...

[M_I_B]

Ok, die Tagelslichtsensoren sind da ebenso wie der Bosch Temp/HUM/PRESS - Sensor ...

Ich sage es mal so: Für den geneigten Nachbauer nicht unbedingt geeignet... Ohne IR BGA Rework- Station und Mikroskop kaum zu machen ... Gugst Du ...

Oben die Tageslicht- Sensoren (6 Pin's 4PIN), unten die Bosch (4Pin's6PIN, jeweils seitwärts nicht erreichbar, ähnlich BGA)