[73_AutoShuttersControl.pm] Neues Modul zum automatisierten steuern von Rolläden

[CoolTux]

Guten Morgen CoolTux,

hattest du Gestern die Gelegenheit dir das mal anzusehen?

VG Dieter

Leider noch nicht. Der Code dürfte soweit passen. Habe aber da noch mal was gemacht gehabt das schaue ich mir noch mmal an

[CoolTux]

Thema Brightness: Ist bei mir die an einem Sensor der PV-Anlage gemessene Globalstrahlung.

Thema Shading: Meine eigene Beschattungssteuerung war deutlich komfortabler als das, was bisher in ASC integriert ist. Denn dabei habe einerseits ich auch die Sonnenhöhe berücksichtigt, um die Targetposition des Rollladens zu bestimmen. Hier könnte man also beim Attribut ASC_Shading_Pos statt des festen Zahlenwertes einen Perl-Ausdruck angeben, der im Modul als solcher erkannt wird und dann ausgewertet wird.

Code Auswählen Erweitern

sub getShadingPos {
    my $self    = shift;
    my $default = $self->{defaultarg};

    $default = 10 if ( not defined($default) );
    my $av =  AttrVal( $self->{shuttersDev}, 'ASC_Shading_Pos', $default );
   
    if( $av !~ /\d\d/ ){
      $av = eval{$av};
      $av = $default
         if($av !~ /\d\d/ );
    } 
}

Außerdem habe ich die Positionsänderung bei einer Änderung der Beschattungsbedingungen auf 10% beschränkt - damit der Rollladen schrittweise bewegt wird.

Hallo Pah,

Ich verstehe das so das Du nicht Nachlauf meinst sondern tatsächlich einmalig wenn es zur Beschattung kommt Du die Sonnenhöhe ein liest und dann das Rollo in eine entsprechende Position fährst. Aber das Rollo da dann auch bleibt und nicht weiter hoch oder runter fährt.

Ach ja, und noch etwas zum Code am Beispiel Shading: Dadurch, dass bei der Berechung mehrfach $shutters->getShadingPos aufgerufen wird, wird der Code ziemlich langsam. Hast Du irgendeinen Grund, das nicht in einer lokalen Variable zu cachen?

LG

pah


P.S::
@mobiljoe123: Unsinn. Bitte keine Nebelkerzen zünden, sondern erst einmal die Einsteigerdokumentation von FHEM lesen.

Dadurch das ich durch die Abfragen eigentlich eh das $shutters->getShadingPos nur einmal aufrufe dachte ich es würde aus reichen. Jetzt im Nachhinein betrachtet habe ich vergessen zu überlegen wie den der Interpreter das behandelt.
Beachtet der wirklich alle $shutters->getShadingPos?


Grüße

[coolice]

Guten Morgen zusammen, zu meinem Verständniss möchte ich eine Frage stellen.

Ist es richtig, das die Rollos immer herunterfahren wenn ASC_Shading_Mode auf always steht wenn
1. die eingestellten Parameter zur Beschattung
2. der letzte das Haus verlässt durch das ASC_residentsDevice ?

Gibt es keine Möglichkeit nur in Beschattung anhand der äußeren Gegebenheiten wie Temperatur, Sonnenstand und Co zu fahren ?

Gruß Coolice

[CoolTux]

Guten Morgen zusammen, zu meinem Verständniss möchte ich eine Frage stellen.

Ist es richtig, das die Rollos immer herunterfahren wenn ASC_Shading_Mode auf always steht wenn
1. die eingestellten Parameter zur Beschattung
2. der letzte das Haus verlässt durch das ASC_residentsDevice ?

Gibt es keine Möglichkeit nur in Beschattung anhand der äußeren Gegebenheiten wie Temperatur, Sonnenstand und Co zu fahren ?

Gruß Coolice

Hallo,

Nur bei ersteres. Die Rollos fahren immer in die Beschattung wenn die Werte entsprechend erreicht sind.
Zu 2. Ein Rollo würde komplett zu fahren, also nicht Beschattung, wenn der letzte das Haus verlässt durch das ASC_residentsDevice ein Fenster offen geblieben ist und selfdefense aktiv ist.


Grüße

[Prof. Dr. Peter Henning]

Beachtet der wirklich alle $shutters->getShadingPos?

Ja, weil er jedes Mal die Funktion aufruft, und diese jedes Mal AttrVal. Und das ist das Langsame. Man könnte das schon beschleunigen, indem man nicht jedesmal über diese Funktion geht, sondern direkt den Attributehash abfragt.

Hallo Pah,

Ich verstehe das so das Du nicht Nachlauf meinst sondern tatsächlich einmalig wenn es zur Beschattung kommt Du die Sonnenhöhe ein liest und dann das Rollo in eine entsprechende Position fährst. Aber das Rollo da dann auch bleibt und nicht weiter hoch oder runter fährt.

Äh - nö. Bei jeder Neuberechnung der Beschattung wird nicht nur die Bedingung überprüft, sondern auch die Zielposition berechnet. Die kann sich also jedes Mal ändern (muss aber nicht). Dadurch, dass die tatsächliche Fahrbewegung auf 10% in Richtung der neuen Zielposition begrenzt ist, kann es schon mal etwas dauern, bis diese erreicht ist. Hat sich aber sehr gut bewährt.

Ich bin heute morgen noch über etwas Anderes gestolpert.
1. Rollläden zu Sonnenaufgang 7:08 hochgefahren, OK
2. Danach hat offenbar die Kiste irgendwie als nächste DriveTime 8:30 gesetzt, meine ASC-Wochenendfahrzeit (obwohl Wochenende erst morgen ist)
3. Um 7:30 hat meine ursprüngliche Weckroutine dann alle Rollläden nochmal hochgefahren (was natürlich keinen Effekt hatte, aber bei ASC als "manual" vermerkt wurde).
4. Dann hat meine Frau die Terrassentür geöffnet, um die Katze rauszulassen. Nach dem Schließen der Tür ist der Rollladen wieder zugefahren.

Klar, denn die nächste Fahrzeit war als 8:30 gesetzt und es wurde der Türsensor betätigt. Und um 8:30 wurde ganz brav der Rollladen auch wieder hochgefahren.

LG

pah

[CoolTux]

Ja, weil er jedes Mal die Funktion aufruft, und diese jedes Mal AttrVal. Und das ist das Langsame. Man könnte das schon beschleunigen, indem man nicht jedesmal über diese Funktion geht, sondern direkt den Attributehash abfragt.

Äh - nö. Bei jeder Neuberechnung der Beschattung wird nicht nur die Bedingung überprüft, sondern auch die Zielposition berechnet. Die kann sich also jedes Mal ändern (muss aber nicht). Dadurch, dass die tatsächliche Fahrbewegung auf 10% in Richtung der neuen Zielposition begrenzt ist, kann es schon mal etwas dauern, bis diese erreicht ist. Hat sich aber sehr gut bewährt.

Ah das dachte ich mir. Genau das wurde von den Usern nicht gewünscht. Ok Ausnahme, ein User hatte den Wunsch. Da viele richtige Rollo Panzer haben ist das störend und belastet wohl auch ziemlich die Motoren.

Ich bin heute morgen noch über etwas Anderes gestolpert.
1. Rollläden zu Sonnenaufgang 7:08 hochgefahren, OK
2. Danach hat offenbar die Kiste irgendwie als nächste DriveTime 8:30 gesetzt, meine ASC-Wochenendfahrzeit (obwohl Wochenende erst morgen ist)
3. Um 7:30 hat meine ursprüngliche Weckroutine dann alle Rollläden nochmal hochgefahren (was natürlich keinen Effekt hatte, aber bei ASC als "manual" vermerkt wurde).
4. Dann hat meine Frau die Terrassentür geöffnet, um die Katze rauszulassen. Nach dem Schließen der Tür ist der Rollladen wieder zugefahren.

Klar, denn die nächste Fahrzeit war als 8:30 gesetzt und es wurde der Türsensor betätigt. Und um 8:30 wurde ganz brav der Rollladen auch wieder hochgefahren.

LG

pah

Das ist in der Tat noch ein Bug. Oder besser gesagt fehlende Kenntnis meiner seits. Ich habe noch Probleme beim erstellen der neuen Timer. Einmal müßen diese ja auch nach einem morgendlichen Neustarten von FHEM noch erkennen das heute noch nicht Tag ist und andererseits muß aber auch nach einer Sunrise Fahrt erkannt werden das wenn der neuberechnete Wert auf einen späteren Zeitpunkt des selben Tages fällt er dann diese Uhrzeit für den Folgetag nehmen muß.
Grund ist ja das die Sunrise Zeit sich wieder nach vorne verlegt.



Bei $shutters->getShadingPos meintest Du bestimmt das es ja pro Rolladen passiert. Wenn ich also 8 Rolladen habe welche durch die Schleife gehen dann wird 8x $shutters->getShadingPos gemacht. Glaube jetzt verstehe ich was Du meinst. Über den Device Hash ginge es schneller, aber eigentlich ist es ja gewünscht das wir die API Funktionen verwenden. Sprich die FHEM Funktionen zum auslesen der Attribute.
Ich könnte diesen Wert höchstens noch in mein eigenes Objekt zwischen speichern. Müsste dann aber bei Änderung auch erkannt werden und neu eingelesen werden.

[Beetle2003]

Guten Morgen,

Ich habe in den letzten Wochen festgestellt, dass Freitags die Rollos die Fahrzeiten vom Wochenende benutzen.
Das ist sicherlich ein Linux Thema, doch habe ich keinen Hinweis gefunden wie ich dieses ändere.

Wäre für einen Hinweis dankbar.

Gruss

[dancatt]

Folgende Fragen:

1.
Folgende Werte der Attribute im Rollladen Device:

Code Auswählen Erweitern


ASC_Time_Up_Early = 06:45
ASC_Time_Up_Late = 08:30
ASC_Time_Up_WE_Holiday = 08:00

Folgender Wert des Readings im Rollladen Device:

Code Auswählen Erweitern


ASC_Time_DriveUp = 2.03.2019 - 07:01

=> Sollte da nicht 08:00 stehen da morgen Wochenende ist? Hängt das auch mit dem aktuellen "Wochenendeproblem" zusammen?

2. holiday2we sind bei mir nur die Feiertage enthalten. Ich nutze das Modul Calendar noch für die Schulferien. Ist vielleicht noch geplant das Modul Calendar in irgendeiner Form anzubinden?

3. Ist es möglich im ASC-Device das Attribut "ASC_temperatureSensor" mit einem Proplanta (oder ähnliches) Device zu belegen?
Wenn ja dann wäre es praktisch wenn "ASC_temperatureReading" den Mittelwert "AVG(fc0_tempMax,fc0_tempMin)" (oder ähnliches) berechnen könnte. Perl-Code wäre an der Stelle auch ok.

Vielen Dank.

[Beta-User]

Zu 1: Was steht in der Liste, wenn du am ASC-Device das get ..Info ausführst?

Zu 2: Wir haben hier schon mehrfach diskutiert, wie man aus der Calendar-Info eine sinnvolle WE-Info für ASC ableitet. Ich mache das z.B. mit einer automatisiert erstellten .holiday-Datei, andere nehmen einen Dummy. Code für Dummy ist hier irgendwo verlinkt, mein Calendar2holiday-Code steht irgendwo im Kalenderbereich, auch mit link hier irgendwo.
M.E. ist es nicht erforderlich, da was automatisiertes direkt in das Modul einzubauen, da es sowieso jeder anders haben will und dann die holiday2we-Funktionalität nutzen kann (oder das entsprechende Attribut-Device, da gab es doch eines, oder)...

Zu 3.: Es müßte jedes FHEM-Device gehen, das einen nummerischen Wert enthält. Sowas mit der Mittelwertbildung usw. kann man sicher machen, aber warum nicht einfach außerhalb von ASC und dann das Ergebnis schlicht in ASC verwenden?

Hoffe, die Kurzfassung hilft weiter.

[CoolTux]

Zu 1. Im ASC Device mittels set Command sunriseTimeWeHoliday das ganze aktivieren.

[Prof. Dr. Peter Henning]

$shutters->getShadingPos

pro Rollladen ist ok - aber hier wir die Funktion ja innerhalb der einen Berechung

Code Auswählen Erweitern

if (    $shutters->getShading eq 'in'
            and $shutters->getShadingPos != $shutters->getStatus )
        {
            my $queryShuttersShadingPos = (
                  $shutters->getShuttersPosCmdValueNegate
                ? $shutters->getStatus > $shutters->getShadingPos
                : $shutters->getStatus < $shutters->getShadingPos
            );

            $shutters->setLastDrive('shading in');
            ShuttersCommandSet( $hash, $shuttersDev, $shutters->getShadingPos )
              if ( not $queryShuttersShadingPos );
        }
        elsif ( $shutters->getShading eq 'out'
            and $shutters->getShadingPos == $shutters->getStatus )
        {
            $shutters->setLastDrive('shading out');
            ShuttersCommandSet( $hash, $shuttersDev, $shutters->getLastPos );
        }

5 Mal aufgerufen. Das sollte nicht sein, sondern am Anfang dieses Blockes einmal der Wert geholt und dann in einer lokalen Variablen gespeichert werden.

Belastung der Rollladenmotoren durch schrittweises Fahren alle 5 Minuten ? Glaube ich nicht.

LG

pah

[CoolTux]

pro Rollladen ist ok - aber hier wir die Funktion ja innerhalb der einen Berechung

Code Auswählen Erweitern

if (    $shutters->getShading eq 'in'
            and $shutters->getShadingPos != $shutters->getStatus )
        {
            my $queryShuttersShadingPos = (
                  $shutters->getShuttersPosCmdValueNegate
                ? $shutters->getStatus > $shutters->getShadingPos
                : $shutters->getStatus < $shutters->getShadingPos
            );

            $shutters->setLastDrive('shading in');
            ShuttersCommandSet( $hash, $shuttersDev, $shutters->getShadingPos )
              if ( not $queryShuttersShadingPos );
        }
        elsif ( $shutters->getShading eq 'out'
            and $shutters->getShadingPos == $shutters->getStatus )
        {
            $shutters->setLastDrive('shading out');
            ShuttersCommandSet( $hash, $shuttersDev, $shutters->getLastPos );
        }

5 Mal aufgerufen. Das sollte nicht sein, sondern am Anfang dieses Blockes einmal der Wert geholt und dann in einer lokalen Variablen gespeichert werden.

Belastung der Rollladenmotoren durch schrittweises Fahren alle 5 Minuten ? Glaube ich nicht.

LG

pah

Ok das mit dem shutters->getShadingPos habe ich verstanden. Werde ich entsprechend ändern. Danke Dir

Zu der Belastung kann ich nichts sagen, aber es ging ja auch um die Geräusche.

[stefanpf]

2. holiday2we sind bei mir nur die Feiertage enthalten. Ich nutze das Modul Calendar noch für die Schulferien. Ist vielleicht noch geplant das Modul Calendar in irgendeiner Form anzubinden?

Vielleicht hilft dir die Definition unten weiter.
Ich nutze diese CALVIEW um unsere beiden privaten Kalender nach Terminen mit den Wörtern "Ferien", "urlaub" oder "krank" im Betreff auszuwerten.
Zusätzlich werden noch die Einträge aus dem Feiertagskalender eingefügt.
Die Userreadings und das Stateformat sorgen dafür, dass das CALVIEW Device dann im holiday2we Attribut genutzt werden kann.

Code Auswählen Erweitern


defmod cv_UrlaubFT CALVIEW cal_Google_Vanessa,cal_Google_Stefan,cal_NRW_Feiertage
attr cv_UrlaubFT filterSummary .*:(?i)(Ferien|Urlaub|Krank),cal_NRW_Feiertage:.*
attr cv_UrlaubFT modes next
attr cv_UrlaubFT stateFormat today
attr cv_UrlaubFT userReadings today:c-today.* { \
if (ReadingsVal($name,"c-today",0) > 0 ) { return "ja"} \
else { return "none"}\
},\
tomorrow:c-tomorrow.* {\
if (ReadingsVal($name,"c-tomorrow",0) > 0 ) { return "ja"} \
else { return "none"}\
}

Im Calview ist das zwar alles etwas komprimiert, ich konnte damit aber zwei DOIFs und einen Dummy wegrationalisieren

[CoolTux]

Hallo Dieter,

Nicht das ich wüsste. Hatte es denn mal funktioniert mit tomorrow?
Ich schaue heute Abend gerne einmal.

Hallo Dieter,
Bin gerade dazu gekommen einmal zu schauen.
Ich verwende selbst genau die selbe Routine 1 zu 1, bei mir klappt alles soweit.

Grüße

[Wuppi68]

Moin Marko,

ich hatte mir gestern nach dem Webinar Dein AutoShootersControll angeschaut.

Bei der Einrichtung überschreibst Du alle Userattribute bei den Rollo Devices

Mich hat es nicht sonderlich getroffen, aber vielleicht wird es ggfl. irgendjemand anderes treffen. Kannst Du ja bei einen Deiner nächsten Versionen entsprechend anpassen.

vergiss den gestrichenen Bug ... beim 2. Start mit nur einer Rolladen hat problemlos funktioniert

Liebe Grüße

Ralf