Hallo zusammen!
Ich habe seit einiger Zeit meinen FHEM auf einem RPi2 laufen mit Homeatic-Komponenten und eine Darstellung mit Smart Visu und frontherm. Hier funkioniert alles super. Ich habe auch schon eine Mailbenachrichtigung über den Batteriestand der Geräte eingebaut, aber bis Dato alles nach Anleitungen. Leider bin ich bisher im Scripte schreiben nicht bewandert.
Ich habe einen HM-ES-PMSw1-Pl an einen Abluftventilator angeschlossen der früher für die Abluft in einer Küche da war und würde gerne im Sommer den Ventilator nutzen um die warme Luft aus dem raum nach Draußen zu befördern. Daher würde ich eine Möglichkeit suchen den Ventilator über den Schaltakuator ein zu schalten, wenn die Außentemperatur (Messeinheit schon eingebunden) niedriger ist als die Innentemperatur (Temperaturmesser im Raum vorhanden). Nun wäre das ja aber im Winter auch der Fall. Daher würde ich die Funktion gerne aktiv oder inaktiv setzen können, oder vielleicht nur in gewissen Monaten aktiv schalten.
Kann mir hier ein erfahrener Scriptschreiber von euch weiter helfen ?
VG,
Mark
Ein dummy, um aktiv oder inaktiv zu setzen:
define VentilatorAutomatik dummy
attr VentilatorAutomatik webCmd on:off
set VentilatorAutomatik off
Und ein DOIF zum schalten:
define diVentilator DOIF ( [Aussensensor:temperature] < ([Innensensor:temperature] -2) and [VentilatorAutomatik] eq "on") (set Ventilator on)
DOELSEIF ( [Aussensensor:temperature] > ([Innensensor:temperature]) (set Ventilator off)
Das -2 um eine Hysterese von 2°C zu haben, sonst schaltet das Ding permanent, wenn die Temperaturen vergleichbar sind.
Alternativ zum Dummy kann man im DOIF etwas mit dem Monat bauen:
define diVentilator DOIF ( [Aussensensor:temperature] < ([Innensensor:temperature] -2) and $month > 4 and $month < 10 )
DOELSEIF ( [Aussensensor:temperature] > ([Innensensor:temperature]) (set Ventilator off)
Habe nicht getestet. Das ist wahrscheinlich noch fein anzupassen.
Das Dummy kann man sich auch sparen:attr diVentilator devStateIcon disabl.*:general_aus:enable initi.*|cmd.*:general_an:disable .*rro.*:icoTool
Oder man lüftet nur, wenn die Temperatur draußen >X° und kleiner der Innentemperatur ist. Dann umgeht man gleich auch ggf. unerwünschte nächtliche Lüftungen.
abgekürzte Grüße
Niels
Hi !
Danke Muschepuster :-)
Das liest sich schon mal super. Das Vorgehen im Ersten Post verstehe ich soweit und ist auch mal interessant zu sehen wie das geschrieben wird. Gar nicht so anders als andere Programmiersprachen. Aber wo gebe ich welchen Code ein ? Das verwirrt mich noch oft im FHEM, manches soll in einer Datei eingetragen werden anderes immer in die Commandozeile oben ...
Bei dem Zweiten Post berstehe ich nicht wirklich was da passiert. Kannst du das etwas erklären ?
VG,
Mark
Alles in der FHEM Weboberfläsche.
Beim ersten Post :
define VentilatorAutomatik dummy im Kommandofeld in der FHEM Weboberfläsche.
Dann die attributes setzen mit Felder und Listen auf dem Gerät, immer noch in der FHEM Weboberfläsche
define diVentilator DOIF ## im Kommandofeld in der FHEM Weboberfläsche eingeben, und dann auf "DEF" klicken, und den Rest ergänzen.
( [Aussensensor:temperature] < ([Innensensor:temperature] -2) and [VentilatorAutomatik] eq "on")
(set Ventilator on)
DOELSEIF ( [Aussensensor:temperature] > ([Innensensor:temperature])
(set Ventilator off)
Bei dem Zweiten Post: es wird somit definiert, dass das Device in FHEM Weboberfläsche ein Icon bekommt, abhängig von dem Status, und wenn man darauf klickt, wird das Status entspr. geändert.
Um eine Idee davon zu haben, folgendes im Kommandofeld eingeben:
define dutest dummy
Dann neben "set" im leeren Feld, on eintragen und auf set klicken.
Dann neben attr aus der Liste devStateIcon auswählen und im leeren Feld daneben on:general_an:off off:general_aus:on eintragen und auf attr klicken.
Dann kannst Du oben mit dem Knopt "An" "Aus" spielen.
Das gleiche wird im DOIF benutzt:
- wenn der Status disabl.* ist (sprich "disable", "disabled", disabl<irgendwelche Buchstaben) dann ist die Icon "general_aus", und ein Klick darauf setzt es auf enable
- wenn der Status initi.* ist (insbesondere "initial") oder cmd.* (z.b cmd2 oder cmd3.5), ist die Icon "general_an", und ein Klick darauf setzt es auf disable.
Ja, der Einstieg in FHEM ist nicht ganz einfach. Aber gerade im Einstieg sollte man die Finger von Dateien lassen, auch wenn viele HowTo's darauf verweisen! Eigentlich kann man (fast) alles über das Webinterface regeln. Das ist mächtiger als es aussieht und man muss da nur die richtigen Punkte finden.
Grundsätzlich kann alles hier geschriebene in die Kommandozeile auf dem Webinterface eintragen. Aber nachdem das DOIF definiert ist, kann man ja die Attribute auch unten einstellen.
attr diVentilator devStateIcon | das Attribut devStateIcon wird für das DOIF diVentilator befummelt |
disabl.*:general_aus:enable | wenn der Status disabled ist (über regulären Ausdruck etwas flexibler gestaltet), dann zeige das Icon general_aus an und setzte den Status auf Enabled, wenn das Icon geklickt wird |
initi.*|cmd.*:general_an:disable | wenn der Status enabled oder cmdX ist (ein DOIF zeigt init als State nach seiner Aktivierung bzw. mit cmdX immer das zuletzt ausgeführte Kommando an), dann zeige das Icon general_an und setzte den Status auf Disabled, wenn das Icon geklickt wird |
.*rro.*:icoTool | Dieser Punkt soll Fehlefälle (Error) abfangen. Wenn im Status des DOIF die Zeichenfolge rro auftaucht, dann wird der Schraubenschlüssel angezeigt und man weiß, das es hier etwas zu tun gibt, was natürlich nie vorkommt ;-) |
amenomade hat jetzt im obigen Post das Gleiche für das Dummy-Device gemacht, aber wie gesagt, das kann man machen, braucht man aber nicht. Der Vorteil bei meiner Lösung ist, dass man nicht noch ein DOIF-Device auf der Oberfläche hat, was man ggf. verstecken muss. Das DOIF ist eben gleich der Ein- und Ausschalter für die Automatik.
Zudem verkleinert es die DOIF-Definition etwas:
( [Aussensensor:temperature] < ([Innensensor:temperature] -2))
(set Ventilator on)
DOELSEIF ( [Aussensensor:temperature] > ([Innensensor:temperature])
(set Ventilator off)erklärende Grüße
Niels
Danke noch mal für die Erklärungen.
Ja so ganz intuitiv ist das das FHEM nicht so. Aber wie immer muss man sich langsam heranarbeiten ^^
Ich denke die Varriante 1 wäre vielleicht die bessere Varriante für mich, da ich dann einfach einen 2. Schalter im Smart Visu eintragen kann über den ich dann neben aktiv ein und aus auch die Automatik ein und aus schalten kann, da eigentl. nur ich im FHEM rumbaue aber meine bessere Hälfte (die ja auch das Haus mit kontrolliert ^^) nur über das Handy und Smart Visu eingreift. Und dafür muss ich ja auf ein Attribut Bezug nehmen können.
Zitat von: NemisisSB am 29 Mai 2017, 19:52:07Und dafür muss ich ja auf ein Attribut Bezug nehmen können.
Nun, mit Smart Visu stellt sich in der Tat die Problematik des Versteckens nicht so wie bei mir, den in Sachen Visualisierung bin ich noch recht 'rückständig'.
Es ist aber nicht so, dass Du auf das Attribut Einfluss nehmen musst, das Attribut nimmt Einfluss auf die Darstellung und das Verhalten des Devices! Du stellst also mit dem Attribut nur das Verhalten ein, der Benutzer hat damit nichts mehr zu tun. Am Ende sieht das DOIF eben aus wie das Dummy, nur eben ohne dem Umweg über das Dummy.
minnimalistische Grüße
Niels
Ich bedenke mal Beides. Ich finde es halt immer von Vorteil, dass ich im FHEM alles so leicht einsehbar wie möglich halten kann, weil es eh niemand außer mir sieht und im Smart Visu muss es dann so einfach wie nur irgendwie möglich zu bedienen sein. Also keine Auswahlmöglichkeiten oder Anzeigen die eh keiner braucht. :-)
Zitat von: NemisisSB am 29 Mai 2017, 20:35:09
Ich bedenke mal Beides. Ich finde es halt immer von Vorteil, dass ich im FHEM alles so leicht einsehbar wie möglich halten kann, weil es eh niemand außer mir sieht und im Smart Visu muss es dann so einfach wie nur irgendwie möglich zu bedienen sein. Also keine Auswahlmöglichkeiten oder Anzeigen die eh keiner braucht. :-)
Es ist nicht verwerflich einen Dummy zu nutzen. Bei diversen anderen globalen Attributen, die auch in DOIF nutzbar sind, muss ich auch immer probieren, was sich wie verhält. Es ist natürlich reizvoll alles in einem Modul unterzubringen, weil man dann nur eine Stelle pflegen muss.
DOIF soll aber demnächst eine eigene GUI-Oberfläche bekommen, mit der es viel flexibler sein wird, eigene Buttons, Slider und was man sonst sich an Wigets zusammenstrickt, einzusetzen siehe https://forum.fhem.de/index.php/topic,72072.msg637681.html#msg637681
So ich habe jetzt mal alles eingebaut und es scheint sauber zu funktionieren!
Nur hat eine Klammer im Code für das DOIF gefehlt. So passt es:
( [Aussensensor:temperature] < ([Innensensor:temperature] -2) and [VentilatorAutomatik] eq "on")
(set Schalter_Sw on)
DOELSEIF ( [Aussensensor:temperature] > ([Innensensor:temperature]))
(set Schalter_Sw off)
Etwas verwirrt hat mich anfangs die Reaktion. Also das DOIF reagiert nur, wenn von einem der Sensoren ein neuer Wert übermittelt wird. Daher wird der Ventilator also nur aus geschaltet, wenn bei der Übermittlung des neuen Temperaturwerts eines der Sensoren die Bedingung erfüllt ist. (Nur falls das hier mal Jemand liest uns realtime erwartet)
Ich denke damit wäre das Thema geschlossen und noch mal danke an alle die mir hier so tatkräftig geholfen und mir das Ganze erklärt haben :-)