Hallo zusammen,
Ich habe meiner Markise eine Erweiterung spendiert, so dass sie bei zu viel Wind, Böen stärker 7m/s einfährt. Der Wind wird per Wetterstation WH1080 erfasst die auch von Fhem ausgewertet wird. Es gibt verschiedene Readings, u. a. auch windgust. Über eine Notify setze ich den Windwarner aktiv. Dieses ist über Internals:
CFGFN
DEF (WetterWH1080:windgust.*) {
if ($EVTPART1 > 7) {
fhem('setstate Windwarner on');
} else {
fhem('setstate Windwarner off');
}
}
NAME Windwarnung
NOTIFYDEV WetterWH1080
NR 258049
NTFY_ORDER 50-Windwarnung
REGEXP (WetterWH1080:windgust.*)
STATE 2018-05-13 17:51:10
TYPE notify
Helper:
DBLOG:
state:
logmysql:
TIME 1526207384.64587
VALUE active
READINGS:
2018-05-13 12:29:44 state active
Attributes:
definiert. Ich bin mir nicht sicher, ob das so richtig ist. Der Windwarner triggert wiederum andere Aktionen, z. B. Markise einfahren.
Ich habe auch einen Forstwarner eingerichtet. Dieser ist ganz ähnlich definiert:
Internals:
DEF (WetterWH1080:temperature.*) {
if ($EVTPART1 <= 0) {
fhem('setstate Frostwarner on');
} else {
fhem('setstate Frostwarner off');
}
}
NAME Frostwarnung
NOTIFYDEV WetterWH1080
NR 74
NTFY_ORDER 50-Frostwarnung
REGEXP (WetterWH1080:temperature.*)
STATE 2018-05-13 17:50:10
TYPE notify
Helper:
DBLOG:
state:
logmysql:
TIME 1526188401.17759
VALUE active
READINGS:
2018-05-13 07:13:21 state active
Attributes:
Wie gesagt, ich bin mir nicht sicher, ob dass passt. Über eine Rückmeldung würde ich mich sehr freuen.
Danke
Martin
OK, ich habe es mit anderen Werten testen können. Es funktioniert.
Grüße Martin
Dass das irgendwie funktioniert, ist eigentlich klar.
Als ganz optimal würde ich das aber nicht ansehen:
- Um indirekt durch solche Konstruktionen eventuell verursachtes "Dauerfeuer" bei den Logikteilen, die wieder darauf zugreifen durch Setzen immer desselben Status zu vermeiden, sollte entweder noch eine Abfrage nach dem derzeitigen Status der Dummys rein (wenn schon "on", dann nicht nochmal setzen; so man den Dummy überhaupt benötigt und nicht die Schaltbefehle direkt auslöst und den Zustand nur intern in ein Reading des notify schreibt), oder der Dummy dann auf "event-on-change..." gesetzt sein.
- Bei solchen Schwellwert-Betrachtungen ist zu überlegen, ob man das noch mit einer Hysterese versieht, also z.B. hier die Frostwarnung erst wieder zu deaktivieren, wenn z.B. +4°C erreicht bzw. überschritten sind.
Just my2ct.
Gruß, Beta-User
Hallo Beta-User,
Danke für die Tipps. Das mit Hysterese hatte ich mir auch schon überlegt, wollte ich aber erst im nächsten Schritt umsetzten. Werde ich hier auch posten.
Warum ich über die Dummys gehe hat mehrere Gründe:
- Ich möchte mit den einzelnen Wetterwarnungen auch verschiedene Dinge tun:
- optische Rückmeldung jeweils über ein farbiges Symbol (Wind, Frost, Regen, Gewitter; rot=aktiv, grün=inaktiv)
- von den unterschiedlichen Warnungen abhängig auch unterschiedliche Aktionen ausführen
Daher möchte ich das abstrakt trennen. Direkt das Device schalten stünde dem im Weg.
- Wenn ein Notify (z.B. Wind) getriggert hat und die Markise sich deswegen gerade schließt und dann ein weiteres Notify triggert (z.B. Regen oder Gewitterwarner), die Kombination kann ja bei einem aufziehenden Gewitter vorkommen, wird der Einfahrbefehl erneut gesendet. Dies hat aber zur Folge dass die Markise dann stehen bleibt und nicht wie gewünscht schließt. Eine Möglichkeit wäre natürlich zu prüfen ob die Markise gerade fährt. Das ist jedoch nur indirekt über das Fhem-Device möglich, da der Somfy-Antrieb keine Rückmeldung gibt.
Zu bedenken gilt auch, die Markise kann man auch über eine Fernbedienung steuern. Dann weiß FHEM aber nix davon. Da sollte man prophylaktisch den Einfahrbefehl senden. Aber vorher prüfen ob der Status schon wie gewünscht gesetzt kann natürlich nicht schaden. Die Wetterreadings haben schon das event-on-change Attribut gesetzt.
Grüße Martin
Hi Martin,
kein Thema, das kann man ja auch mit Dummy's machen ;) .
Zu den Alternativen:
Für die optische Darstellung nehme ich ggf. readingsGroup, da geht das mit rot/grün genauso, nur dass eben nicht direkt ein state abgegriffen wird.
Und um - abhängig vom jeweiligen Zustandswechsel - Aktionen auszulösen, benötigt man nicht zwingend einen Dummy, man kann notify ja auch auf readings setzen oder direkt code aus dem "Ursprungsnotify" ausführen lassen.
Damit gingen dann auch komplexere Abfragen von wechselnden Abhängigkeiten wie von dir geschildert.
Was somfy angeht: Es könnte sein, dass ein Signalduino helfen könnte, den Status aktuell zu halten. Damit kann man nach meiner Kenntnis auch Fernbedienungssignale erkennen. Allerings habe ich keine Sofy-Devices, ist also ungetestet.
Gruß, Beta-User
Ich habe den SIGNALduino, jedoch dass er die Signale der Fernbedienung auswerten kann, wusste ich nicht. Ich hatte schon mal geschaut, ob der SIGNALduino was empfängt, wenn ich Die Fernbedienung betätige. War aber nix zu sehen... Aber keine Ahnung wie man es richtig macht bzw. Was die Voraussetzungen sind. Ansonsten machen beide SIGNALduinos was sie sollen.
Die restlichen Punkte schau ich mal an. Aber ich bin erst mal froh, dass es so funktioniert. ;D aber was nicht ist kann noch werden.
ein bisschen lesestoff :)
https://wiki.fhem.de/wiki/SOMFY
https://wiki.fhem.de/wiki/Somfy_via_SIGNALduino
ja das kenne ich beides, da steht aber nicht, wie Signale einer richtigen Fernbedienung in den Signalduino reinkommen und diese auszuwerten sind. Der Signalduino ist ja selber eine "Fernbedienung".
Wenn ich das richtig verstanden habe: richtige Frequenz einstellen (geht nur mit der CC1101-Variante), dann die Rolläden (bzw. die genutzten Fernbedienungen) (auch) via autocreate anlegen lassen.
Der Trick scheint das recht neue Attribut "rawDevice" zu sein. Das gehört vermutlich zu den manuell in FHEM angelegten Devices und dürfte mit dem zugehörigen Namen des "autocreate"-Devices zu füllen sein. Dadurch wird die logische Verbindung zwischen beiden Fernbedienungsvarianten hergestellt.
Wenn das paßt, sollte man ggf. das Wiki entsprechend ergänzen, das ist m.E. nicht selbsterklärend...
Also ich hatte das mehrmals erfolglos versucht. Die Daten der Fernbedienung werden nicht erkannt. Ist aber auch nicht weiter schlimm.
Schlimmer ist jedoch, dass der notify der auf den ON state des Gewitterwarners triggern soll genau dies nicht getan hat. Wenn ich ihn mit über den trigger Befehl triggere funzt es... Woran kann das liegen? Ich befürchte, dass das mit den anderen auch nicht funktioniert.
Kann man das besser machen? Und zwar so, dass man verschiedene Reaktionen auslösen kann, ohne Spaghetti Code zu brauchen.
Grüße Martin
So, wenn die Dummy devices über die Kommandozeile mit set Gewitterwarner onauf on setzte funzt das mit dem notify. Warum nicht, wenn das notify des GPIO Interrupts den Status setzt? ???
Grüße Martin
M.E. paßt der Event nicht.
ON != on != On...
Was liefert der Event-Monitor bzw. das entspr. Device-log?
@Beta-user: Ich habe nicht ganz verstanden, was du meinst. Aber um Missverständnissen vorzubeugen beschreibe ich das Ganzen mal im Detail:
Gewitterwarner:
Es gibt zwei notifys, GW1_Warnung und GW1_Entwarnung. Das deswegen, weil der Gewitterwarner (GW1 von ELV) zwei separate open-collector Ausgänge für Warnung und Entwarnung hat. Daher habe ich zwei GPIO Eingänge. Das Listing für GW1_Warnung ist dieses:
Internals:
DEF 13
EXCEPT_FD 25
GPIO_Basedir /sys/class/gpio
GPIO_Nr 13
NAME GW1_Warnung
NR 75
STATE on
TYPE RPI_GPIO
WiringPi_gpio /usr/local/bin/gpio
READINGS:
2018-06-09 15:07:13 Counter 120
2018-05-23 16:49:29 Dblclick on
2018-06-11 08:32:15 Pinlevel high
2018-06-09 15:07:13 Toggle on
2018-06-10 20:56:07 state on
fhem:
interfaces switch
Attributes:
direction input
interrupt falling
pud_resistor up
Für GW1_Entwarnung ist das entsprechend gleich.
Es wird jeweils ein notify verwendet. Listing für Gewitterwarnung:
Internals:
DEF GW1_Warnung:off setstate Gewitterwarner on
NAME Gewitterwarnung
NOTIFYDEV GW1_Warnung
NR 86
NTFY_ORDER 50-Gewitterwarnung
REGEXP GW1_Warnung:off
STATE active
TYPE notify
READINGS:
2018-06-11 08:14:45 state active
Attributes:
Bei Gewitterentwarnung wird der Dummy Gewitterwarner wieder auf off gesetzt.
Die Aktion Markise zu schaut so aus:
Internals:
DEF Gewitterwarner:on set Markise up
NAME GW_Markise_zu
NOTIFYDEV Gewitterwarner
NR 127
NTFY_ORDER 50-GW_Markise_zu
REGEXP Gewitterwarner:on
STATE active
TYPE notify
READINGS:
2018-06-11 08:14:51 state active
Attributes:
Wie gesagt: Wenn ich den dummy Gewitterwarner per set Gewitterwarner setstate on klappt das.
Und während ich so darüber nachdenke und das Geschriebene nochmals rekapituliere, kommt mir doch, dass mit setstate ein notify gar nicht getriggert werden kann! :o
Also das werde ich als nächste versuchen... Ich berichte!
Grüße Martin
So, jetzt geht es!
Vielen Dank für Antworten!
Richtig ist so:
Internals:
DEF GW1_Warnung:off set Gewitterwarner on
NAME Gewitterwarnung
NOTIFYDEV GW1_Warnung
NR 86
NTFY_ORDER 50-Gewitterwarnung
REGEXP GW1_Warnung:off
STATE active
TYPE notify
READINGS:
2018-06-11 08:14:45 state active
Attributes:
GRüße Martin