[Gelöst] Markise schließen bei starkem Wind / Frostwarner

[maddinthebrain]

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

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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

[maddinthebrain]

OK, ich habe es mit anderen Werten testen können. Es funktioniert.

Grüße Martin

[Beta-User]

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

[maddinthebrain]

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

[Beta-User]

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

[maddinthebrain]

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.  aber was nicht ist kann noch werden.

[nils_]

ein bisschen lesestoff

https://wiki.fhem.de/wiki/SOMFY
https://wiki.fhem.de/wiki/Somfy_via_SIGNALduino

[maddinthebrain]

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".

[Beta-User]

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...

[maddinthebrain]

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

[maddinthebrain]

So, wenn die Dummy devices über die Kommandozeile mit

Code Auswählen Erweitern

set Gewitterwarner onauf on setzte funzt das mit dem notify. Warum nicht, wenn das notify des GPIO Interrupts den Status setzt?

Grüße Martin

[Beta-User]

M.E. paßt der Event nicht.
ON != on != On...
Was liefert der Event-Monitor bzw. das entspr. Device-log?

[maddinthebrain]

@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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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!   

Also das werde ich als nächste versuchen... Ich berichte!

Grüße Martin

[maddinthebrain]

So, jetzt geht es!

Vielen Dank für Antworten!

Richtig ist so:

Code Auswählen Erweitern

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