Rollladensteuerung: Alternativen zu DOIF

[Cluni]

Das habe ich auch. Scheint an der Rückgabe vom Kalender zu liegen. Weiß ich auch noch nicht, wie man das weg bekommt....


Gesendet von iPhone mit Tapatalk

[MarkusHiba]

Hallo,

@ Cluni
ist die Rollladensteuerung nur für HomeMatic Aktoren?

Ich habe leider nur das ROLLO Modul.
Man könnte viel mit DOIF oder notify machen aber das ist viel gerade für so eine Komplexe Steuerung und bei vielen Rollläden (ein Haus).

Ich weis auch das das ROLLO Modul auch schon viel kann.

Könnte man so eine Steuerung für das ROLLO Modul entwickeln und alles über ein Modul steuern lassen, wo man nur noch die anderen Aktoren bzw Sensoren einfügt und dessen Schwellenwerte eingeben muss?

Ihr alle habt schon super Ideen eines fällt mir noch ein was ist mit Unwetter, Sturm, Hagel, usw. oder die Windgeschwindigkeit? 

Grüße
Markus

[Chris8888]

Hallo Bernd,

neue Version ist eingespielt.

Ein paar kurze Anmerkungen:
Im Code taucht öfter der Befehl auf: ELSIF ....das soll sicherlich ELSEIF lauten

Und noch 2 kleine Vertipper:
define Rolllanden.Automatik.Abschattung dummy -> Im Dummy ist ein "n" zuviel...aber im Code ist es auch so, von daher funktioniert es ja

In der Doku Punkt 10 fehlt ein "notify".

Danke für die neuen Features! Sehr cool!

Test läuft!

VG
Christian

[kjmEjfu]

Kann man die Dummys eventuell durch Verweise auf andere Geräte überschreiben?
Ich finde es immer unschön, wenn ich mir ein Dummy für einen Wert erstellen muss, den ich schon als Reading an einem Device habe, also z.B. die Werte vom Twilight-Device.
Eventuell könnte man ja eine Variable mit dem Namen des Twilights-Gerätes anlegen und wenn die leer ist, wird stattdessen ein Dummy abgefragt?

[Cluni]

Ein paar kurze Anmerkungen:
Im Code taucht öfter der Befehl auf: ELSIF ....das soll sicherlich ELSEIF lauten

Nein, das passt schon - bei Perl heißt das so...

Und noch 2 kleine Vertipper:
define Rolllanden.Automatik.Abschattung dummy -> Im Dummy ist ein "n" zuviel...aber im Code ist es auch so, von daher funktioniert es ja

Oh - das passiert durch das ganze copy&pase... Danke - korrigiert!
Wer den Dummy bereits hat:
1. rename Rolllanden.Automatik.Abschattung Rollladen.Automatik.Abschattung
2. in der Routine das 'n' löschen, abscheichern und Routine neu laden

In der Doku Punkt 10 fehlt ein "notify".

Behoben...

Danke für die neuen Features! Sehr cool!
Test läuft!

Freut mich/uns, wenn es dir gefällt und es gut funktioniert! 

[Cluni]

@ Cluni
ist die Rollladensteuerung nur für HomeMatic Aktoren?

Ich habe leider nur das ROLLO Modul.
Man könnte viel mit DOIF oder notify machen aber das ist viel gerade für so eine Komplexe Steuerung und bei vielen Rollläden (ein Haus).

Ich weis auch das das ROLLO Modul auch schon viel kann.

Könnte man so eine Steuerung für das ROLLO Modul entwickeln und alles über ein Modul steuern lassen, wo man nur noch die anderen Aktoren bzw Sensoren einfügt und dessen Schwellenwerte eingeben muss?

Da ich die Routinen nach meinen eigenen Bedürfnissen und Wünschen programmiert habe, ist diese natürlich auf meine Geräte zugeschnitten. Du darfst dir natürlich gerne den Code schnappen und ihn an deine Gegebenheiten anpassen.

Ihr alle habt schon super Ideen eines fällt mir noch ein was ist mit Unwetter, Sturm, Hagel, usw. oder die Windgeschwindigkeit? 

Da habe ich auch bereits dran gedacht, aber hatte bis jetzt noch nicht die Muße mich da dran zu setzen. Kommt aber höchstwahrscheilich noch (vor dem Herbst.... )

Kann man die Dummys eventuell durch Verweise auf andere Geräte überschreiben?
Ich finde es immer unschön, wenn ich mir ein Dummy für einen Wert erstellen muss, den ich schon als Reading an einem Device habe, also z.B. die Werte vom Twilight-Device.
Eventuell könnte man ja eine Variable mit dem Namen des Twilights-Gerätes anlegen und wenn die leer ist, wird stattdessen ein Dummy abgefragt?

Die Sache mit den Dummies für jeweilige Werte habe gewählt, damit bei der Weitergabe die Routine nicht starr an die Namen des jeweiligen Device (der Name für das Twilight Device ist ja frei wählbar) geheftet ist. Und wenn ich schon einen Dummy für die Namen generiere, dann kann ich auch direkt dort den Wert ablegen. Zusätzlich hat das den Vorteil, dass ich diese Dummies in einer Gruppe ablegen kann und auf einen Blick alle Werte (egal wo her sie kommen) in den States habe.

EDIT: Ich sehe grade, dass du den Namen (in der Routine?) in einer Variablen speichern möchtest, richtig?! Das wäre natürlich prinzipiell möglich. Aber dadurch wird jeder Aufruf der Routine eine stärkere Belastung für den Controller. Es muss die Variable ausgelesen werden und immer die Fallunterscheidung für das abzufragende Device gemacht werden. Finde ich nicht schön.

Wenn du das gerne anders hättest, dann darfst du dir natürlich gerne die Routine auf die direkte Abfrage umbauen. Ich gebe dir recht, dass dies für fhem weniger Overhead bedeutet, aber dadurch wird die Sache halt steifer. Man könnte natürlich auch alle benötigten Readings in einem Dummy vereinen, aber dadurch würde der Overhead auch nicht kleiner...

Grüße, Bernd

Ach so, noch die aktuelle Version anhängen....

[Cluni]

Das meinte ich übrigens:

[Chris8888]

Nein, das passt schon - bei Perl heißt das so...

Das sieht FHEM aber anders: lt LOG:
Unknown command elsif, try help.
Unknown command elsif, try help.

[Cluni]

Das kommt aber sicherlich nicht von meiner Routine?!

[Chris8888]

ich denke schon...die hatte ich vorher nicht....

[Cluni]

Wann genau kommt das denn und was steht unmittelbar davor/dahinter? Kannst du mal einen Auszug posten?

[Cluni]

Hast du eine Idee woher das hier kommt?

Code Auswählen Erweitern

2017.06.06 08:01:21 3: Ferien.notify return value: SCALAR(0x95fd928)
2017.06.06 08:01:21 3: Ferien.notify return value: SCALAR(0x54fcc38)
2017.06.06 08:01:21 3: Ferien.notify return value: SCALAR(0xa633d88)
2017.06.06 08:01:21 3: Ferien.notify return value: SCALAR(0x98c8cd0)
2017.06.06 08:01:21 3: Ferien.notify return value: SCALAR(0x547c080)
2017.06.06 08:01:21 3: Ferien.notify return value: SCALAR(0x54f5a50)
2017.06.06 08:01:21 3: Ferien.notify return value: SCALAR(0xa26b088)
2017.06.06 08:01:22 3: Ferien.notify return value: SCALAR(0x5a8a030)
2017.06.06 08:02:54 3: Feiertag.notify return value: SCALAR(0x9677ac0)
2017.06.06 08:02:54 3: Feiertag.notify return value: SCALAR(0x54908a8)
2017.06.06 08:02:54 3: Feiertag.notify return value: SCALAR(0x5c866c0)
2017.06.06 08:02:54 3: Feiertag.notify return value: SCALAR(0x5c8eff0)
2017.06.06 08:02:55 3: Feiertag.notify return value: SCALAR(0xa07bbe0)
2017.06.06 08:02:55 3: Feiertag.notify return value: SCALAR(0x5505690)
2017.06.06 08:02:55 3: Feiertag.notify return value: SCALAR(0xa5cf6f8)
2017.06.06 08:02:55 3: Feiertag.notify return value: SCALAR(0x9defa28)
2017.06.06 08:02:55 3: Feiertag.notify return value: SCALAR(0x99b11a8)

Ich konnte auf Anhieb nichts dazu finden....Danke vorab!

Das liegt an dem Vergleich im Notify, wenn der Kalender gelesen wird. Ich habe das def von:

Code Auswählen Erweitern

NRW_Feiertage { \ fhem "set Feiertag " . (ReadingsVal("NRW_Feiertage", "modeStart", "") =~ "schulferieneu" ? 1: 0) }

zu

Code Auswählen Erweitern

NRW_Feiertage { my $Rueckgabe = ReadingsVal("NRW_Feiertage", "modeStart", ""); my $setval = 0; if (index($Rueckgabe,"schulferieneu") > 0) {$setval = 1;}; fhem ("set Feiertag $setval")}

umgebaut. Seit dem keinen Fehler mehr im log gehabt...

[Cluni]

Noch ein Verbesserungsvorschlag:
Ich würde 2 getrennte Attr für "attr Rol\..* Auto_Abschattung_Wartezeit 20" vorschlagen. Ich fahre bisher recht schnell runter bei Sonne 5 Min, aber erst später wieder hoch bei Wolken 20 Min.

Hi, es ist zwar nicht ganz das, was du wolltest, aber es sollte dem Wunsch etwas entgegen kommen:
Ich habe zwei neue Attribute eingefügt: Auto_Abschattung_schnell_oeffnen und Auto_Abschattung_schnell_schliessen

Um die Funktion zu verstehen, muss man folgendes wissen: Die Wartezeit, die im Attribut Auto_Abschattung_Wartezeit steht, halbiere ich erstmal in der Routine. Dies mache ich, weil vor einer Fahrt der Rollladen erstmal zur Fahrt vorgemerkt wird. Dies geschieht frühestens nach der halben Wartezeit. Eine Vormerkung zu einer Aktion wird durch Überschreitung der jeweils anderen Schwelle wieder gelöscht (ansonsten könnte ich mir die Sache mit der Vormerkung ja auch sparen). Danach wird der Rollladen frühestens nach der weiteren halben Wartezeit gefahren, wenn die Bedingungen stimmen.
Wenn ich einen Rollladen zum Schließen/Öffnen vormerke oder auch wenn ich ihn schließe/öffne, dann speichere ich mir die aktuelle Zeit auf dem Reading "Automatik_Abschattung_letzte_Uhrzeit". Bei der nächtlichen Aktualisierung der ganzen Timer und sonstigen Dinge initialisiere ich dieses Reading mit 00:00:00.

Was mache ich also logischerweise, wenn ich die Wartezeit z.B. vor dem erneuten Schließen halbieren möchte? Dann schreibe ich nach dem Öffnen des Rollladen einfach statt der aktuellen Zeit die Zeit 00:00:00 in das Reading Automatik_Abschattung_letzte_Uhrzeit. Die nächste Vormerkung zum Schließen erfolgt dann direkt bei Überschreitung der Schwelle (weil die Wartezeit ja für den Vergleich bereits abgelaufen ist) und es muss nur noch die halbe Wartezeit gewartet werden, bis zum Schließen.

Bitte ausprobieren, ob das so klappt, wie ich mir das ausgedacht habe. Ist das so ok für dich?

Grüße Bernd

PS: Die neue Routine enthält auch noch ein paar weitere Bugfixes

[Chris8888]

Hallo Bernd,

die Meldung kommt beim Start des Systems:

Code Auswählen Erweitern


.....
2017.06.08 09:05:38 3: bridge_HUEDevice1: I/O device is bridge
2017.06.08 09:05:38 3: bridge_HUEGroup0: I/O device is bridge
2017.06.08 09:05:38 3: bridge_HUEGroup1: I/O device is bridge
2017.06.08 09:05:40 1: HMCCURPC: Device ccu_rpc. Initialized version 0.95 beta
2017.06.08 09:05:40 3: TelegramBot_Define Telegram: called
2017.06.08 09:05:40 3: eq3: Defined with URL http://www.eq-3.de/service/downloads.html and interval 86400
2017.06.08 09:05:40 3: eq3: added hint :text,reading,internal,expression,delete to attr readingMaxAgeReplacementMode in userattr list
2017.06.08 09:05:41 1: Including ./log/fhem.save
2017.06.08 09:05:44 1: ./log/fhem.save: Unknown command if, try help.
Unknown command elsif, try help.
Unknown command elsif, try help.

2017.06.08 09:05:44 3: Device Aussenthermometer added to ActionDetector with 000:10 time
2017.06.08 09:05:44 3: Device BewegungsmelderFlur added to ActionDetector with 000:20 time
2017.06.08 09:05:44 3: Device BewegungsmelderGWC added to ActionDetector with 000:20 time
2017.06.08 09:05:44 3: Device BewegungsmelderKueche added to ActionDetector with 000:20 time
...

In älteren Logs sieht es genauso aus....nur ohne den 09:05:44 1:

Den angepassten Notifier teste ich sofort...
Update: Sieht top aus. Keine FM mehr. Hast du das auch für den Ferien-Notifier gemacht?

Die Halbierung der Wartezeit ist Top! Damit komme ich locker zu recht! Klasse!

Neue Version wird gleich eingespielt....
Update:Im Log taucht nach dem Reload folgende Fm auf:

Code Auswählen Erweitern

2017.06.09 19:50:43 1: PERL WARNING: "my" variable $Tempvar masks earlier declaration in same scope at ./FHEM/99_myUtils_Shutter.pm line 169.

VG
Christian

PS: Und noch eine Frage zu einem Anwendungsszenario. Die Teenager schlafen immer seeeehr lange. D.h. ich würde hier als Hochfahrzeit am WE zB 16:00 Uhr eintragen. Was passiert wenn die Beschattungsregeln vorher eintreten? Bleibt das Rollo unten oder fährt es auf das Beschattungslevel.
-> An der Antwort hängt mein Haussegen

[Cluni]

Also deine Meldungen sagen mir nichts. Ich glaube auch nicht, dass die von der Routine kommen.

Mir ist wohl eingefallen, dass ich eine oder zwei Stellen vergessen habe, wo ich noch was anpassen muss. Werde heute oder morgen nochmal eine neue Version posten. Die jetzige sollte aber funktionieren. Nur wenn eine Abschattung vorgemerkt, aber wegen wolkig wieder abgeblasen wird, ist die Wartezeit noch normal.


Gesendet von iPhone mit Tapatalk