[73_AutoShuttersControl.pm] Rolllos automatisiert steuern - Version 0.10

Begonnen von CoolTux, 22 Juni 2020, 12:38:36

Vorheriges Thema - Nächstes Thema

ThomasReu

Hallo CoolTux,

zu Deiner Unterstützung bei der weiteren Entwicklung und Optimierung möchte ich Dir gern noch meine Beobachtungen der letzten Tage zum ASC weitergeben.

Ich habe vor ca. 2 Jahren 10 Rollladen-Devices im ASC eingebunden, vier davon mit Fensterkontakten. Alle Rollladen sind im Grunde so eingerichtet, dass sie Morgens und Abends per ASC anwesensheits- und jetzt helligkeitsabhängig (früher per astro) gefahren werden und auch die Beschattung ist eingerichtet. Unabhängig davon greifen wir aber nach eigenem belieben manuell (per Taster oder Alexa) gern schon mal ein. Ich bin im wesentlichen sehr zufrieden, auch wenn es ab und an mal unerwartete Effekte gibt.

Was mir aktuell auffällt, das stets bei mindestens einem, oft auch mehr, der Devices der Wert 'ASC_ShuttersLastDrive' nicht korrekt gesetzt ist. Scheint so als wäre es der Wert des Zustandes eins zuvor.

2 Bsp.:

Ich habe gestern Abend einen Rolladen nach dem autom. abendlichen Herunterfahren noch einmal manual geöffnet und wieder geschlossen (die Status im FHEM habe ich leider nicht beobachtet). Er ist, wie gewollt und erwartet, heute Morgen autom. heraufgefahren und steht aber jetzt im "ASC_ShuttersLastDrive" = manual. Ich würde "maximum brightness threshold exceeded" erwarten.

Ein anderer Rollladen ist ausschliesslich autom. gefahren, wie gewollt und erwartet. Steht aber aktuell in "ASC_ShuttersLastDrive = minimum brightness threshold fell below". Auch hier würde ich ehr "maximum brightness threshold exceeded" erwarten.

Die "Lüftungssteuerung" funktioniert weiterhin nicht, allerdings gibt es (eine nicht nachvollziehbare :-) Beobachtung innerhalb der Familie, das ein Rollladen wohl dieser Tage doch gefahren sein soll. Mir scheint da im Moment irgendwo der "Wurm" drin zu sein.

Beste Grüße und Danke für Deine tolle Arbeit
Thomas

CoolTux

Zitat von: kjmEjfu am 07 Dezember 2020, 07:54:05
meintest du mich? Naja, ich habe nur die relevanten Attribute ins Listing gepackt.
ASC selbst funktioniert ja, auch die Abschattung, schon seit Ewigkeiten und hat bis zu deinem ASC_Time_Up_WE_Holiday-Umbau auch keine (kaum) Probleme gemacht ;-)

Nein den Thomas   :)
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

eurofinder

Hallo,

hat noch jemand das Problem, dass obwohl bei einigen Rollläden ASC_Adv = on gesetzt wurde, diese zum Zeitpunkt heruntergefahren werden, als ob dieses nicht gesetzt wäre und nicht erst über "set advDriveDown" aus dem ASC-Device heraus?

Ist bisher zweimal hier so passiert. Kann das aber noch nicht reproduzieren. Im Log finde ich dazu nichts.

Ich werde für heute das System nochmals neu Starten und mal sehen wie es reagiert. Version ist v0.10.10.

Gruß
eurofinder


RPI3+; Raspbian Buster Lite; RPI-RF-MOD; piVCCU3, HMIP-eTRV-2, HmIP-SWDO, HmIP-SRH, HmIP-STHO, HmIP-SLO

Klaus Heynen

Gibt es eine Erklärung was die verschiedenen Astro-Modes bedeuten und was beim Modus Horizon die Werte -9 .. 0 .. 9 bewirken?

CoolTux

Zitat von: Klaus Heynen am 08 Dezember 2020, 18:03:55
Gibt es eine Erklärung was die verschiedenen Astro-Modes bedeuten und was beim Modus Horizon die Werte -9 .. 0 .. 9 bewirken?

Wikipedia
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Dr. Ulfi

Zitat von: Klaus Heynen am 08 Dezember 2020, 18:03:55
Gibt es eine Erklärung was die verschiedenen Astro-Modes bedeuten und was beim Modus Horizon die Werte -9 .. 0 .. 9 bewirken?

Ich habe ein bisschen herumprobiert und habe folgende Erkenntnisse gezogen:

REAL und HORIZON = 0 sind identisch, die Sonne steht genau im theoretischen Horizont. Die anderen benötige ich nicht, da ich mit HORIZON alles abdecken kann, -9 bedeutet die Sonne steht 9 Grad unter dem Horizont, ist also bereits untergegangen und 9 bedeutet 9 Grad über dem Horizont, es ist also schon viel heller.
Raspi
CUBE/CUNO a-culfw, Signalduino 433Mhz, Sonoff/Tasmota, EnOceanPI, Meross Smart Plug (IFTTT), ESP8266 Projekte,
MAX!-Heizungssteuerung, Intertechno IT-1500-Steckdosen, Velux KLF200 mit Somfy io

christoph.kaiser.in

Hallo,
eurofinder schrieb:

Zitat von: eurofinder am 08 Dezember 2020, 13:57:31
Hallo,

hat noch jemand das Problem, dass obwohl bei einigen Rollläden ASC_Adv = on gesetzt wurde, diese zum Zeitpunkt heruntergefahren werden, als ob dieses nicht gesetzt wäre und nicht erst über "set advDriveDown" aus dem ASC-Device heraus?

[...]

Gruß
eurofinder

ich habe bei einigen (... die mit Beleuchtung im Fenster...) ausgewählten Rollos in meinem Haus testweise "attr <devicename> ASC_Adv on" gesetzt.

Dann werden bei mir alle automatischen Fahrten für jedes Fenster ab diesem Zeitpunkt verhindert.

Leider hängt sich mein System beim Versuch den Befehl

set <asc_Device_Name> advDriveDown

auszuführen auf.

Der Befehl wird damit nicht ausgeführt. Am nächsten Morgen wird dann auch das automatische Öffnen für alle Fenster nicht mehr ausgeführt. Erst nachdem ich die Konfiguration in den einzelnen Roolos wieder zurückgesetzt habe wird die nächste automatische Fahrt (Beschattung, Türöffnen, Zeitöffnen/~schliessen) wieder ausgeführt.

Grüße
Christoph

christoph.kaiser.in

#1177
Hallo,
ich habe jetzt eine Idee warum FHEM bei mir sich aufhägt. Ich finde im Log den folgenden Eintrag, wenn ich in einem Rolladen Device dasAttribut "Attr ASC_Adv on" gesetz habe und "set <ASC device Name> advDriveDown" aufrufe.


[...]
2020.12.09 22:50:59 4: AutoShuttersControl (Rollladensteuerung) - Shading Processing, Rollladen: Essbereich.Rollladen.Links Azimuth: 318.7 Elevation: -58.9 Brightness: 0 OutTemp: 2.68
2020.12.09 22:50:59 4: AutoShuttersControl (Rollladensteuerung) - Shading Processing, Rollladen: Essbereich.Rollladen.Links Nach dem return
2020.12.09 22:50:59 4: AutoShuttersControl (Rollladensteuerung) - Shading Processing, Rollladen: Essbereich.Rollladen.Links In der Out Abfrage, Shadingwert: out, Zeitstempel: 1607550029
2020.12.09 22:50:59 4: AutoShuttersControl (Rollladensteuerung) - Shading Processing - In der Routine zum fahren der Rolll�den, Shading Wert: out
2020.12.09 22:50:59 4: AutoShuttersControl (Rollladensteuerung) - Devname: Essbereich.Rollladen.Links Name: Rollladensteuerung Notify: $VAR1 = [
          'ASC_ShadingMessage: INFO: current shading status is \'out\' - next check in 10m'
        ];

Undefined subroutine &HTTP::Date::str2time called at lib/FHEM/Automation/ShuttersControl/Helper.pm line 1173.

- RESET -

2020.12.09 22:51:02 1: Including fhem.cfg
2020.12.09 22:51:02 1: Including ./FHEM/fhem_1_interfaces.cfg
[...]


Mir fehlt also entweder das PERL Modul oder es wird nicht gefunden, oder es wird nicht richtig aufgerufen. Nachdem es bei Anderen funktioniert, denke ich eher an eine der ersten beiden Fehlerursachen.
Ich bleibe dran und berichte...

Grüße
Christoph

christoph.kaiser.in

Hallo,

meine Lösung ist zweistufig:

1) Das Perl Modul HTTP::Date hat auf meinem FHEM Server gefehlt - ich habe es manuell via CPAN installiert. Hier fehlt evtl. eine dependency bei der Installation von ASC.
2) Der Aufruf im Modul Helper.pm in Zeile 1173 funktioniert bei mir so nicht - ich musste folgende Änderungen im Modul Helper.pm ausführen:


## unserer packagename
package FHEM::Automation::ShuttersControl::Helper;

use strict;
use warnings;
use POSIX qw(strftime);
use utf8;
# missing use declaration  - seems to be ?
use HTTP::Date;

[...]

Ab Zeile 1163:

sub IsAdv {
    my ( undef, undef, undef, $monthday, $month, $year, undef, undef, undef ) =
      localtime( gettimeofday() );
    my $adv = 0;
    $year += 1900;

    if ( $month < 1 ) {
        if ( $monthday < 7 ) {
            $adv = 1;
        }
    }
    else {
        # my $time = HTTP::Date::str2time( $year . '-12-25' );
my $time = str2time( $year . '-12-25' );
        my $wday = ( localtime($time) )[6];
        $wday = $wday ? $wday : 7;
        $time -= ( $wday + 21 ) * 86400;
        $adv = 1 if ( $time < time );
    }

    return $adv;
}


Damit habe ich nach einem Neustart von FHEM keinen Systemhänger mehr - evtl. reicht auch schon das Einfügen von "use HTTP::Date;" und ein anschliessender Neustart.

Jetzt kann ich mich an die weitere Analyse der Funktionalität machen.

Grüße
Christoph

CoolTux

Zitat von: christoph.kaiser.in am 09 Dezember 2020, 23:59:30
Hallo,

meine Lösung ist zweistufig:

1) Das Perl Modul HTTP::Date hat auf meinem FHEM Server gefehlt - ich habe es manuell via CPAN installiert. Hier fehlt evtl. eine dependency bei der Installation von ASC.
2) Der Aufruf im Modul Helper.pm in Zeile 1173 funktioniert bei mir so nicht - ich musste folgende Änderungen im Modul Helper.pm ausführen:


## unserer packagename
package FHEM::Automation::ShuttersControl::Helper;

use strict;
use warnings;
use POSIX qw(strftime);
use utf8;
# missing use declaration  - seems to be ?
use HTTP::Date;

[...]

Ab Zeile 1163:

sub IsAdv {
    my ( undef, undef, undef, $monthday, $month, $year, undef, undef, undef ) =
      localtime( gettimeofday() );
    my $adv = 0;
    $year += 1900;

    if ( $month < 1 ) {
        if ( $monthday < 7 ) {
            $adv = 1;
        }
    }
    else {
        # my $time = HTTP::Date::str2time( $year . '-12-25' );
my $time = str2time( $year . '-12-25' );
        my $wday = ( localtime($time) )[6];
        $wday = $wday ? $wday : 7;
        $time -= ( $wday + 21 ) * 86400;
        $adv = 1 if ( $time < time );
    }

    return $adv;
}


Damit habe ich nach einem Neustart von FHEM keinen Systemhänger mehr - evtl. reicht auch schon das Einfügen von "use HTTP::Date;" und ein anschliessender Neustart.

Jetzt kann ich mich an die weitere Analyse der Funktionalität machen.

Grüße
Christoph

Ich werde das use die Tage einbauen. Werde es aber direkt in der Funktion einbauen.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

CoolTux

Zitat von: ThomasReu am 08 Dezember 2020, 09:47:41
Hallo CoolTux,

zu Deiner Unterstützung bei der weiteren Entwicklung und Optimierung möchte ich Dir gern noch meine Beobachtungen der letzten Tage zum ASC weitergeben.

Ich habe vor ca. 2 Jahren 10 Rollladen-Devices im ASC eingebunden, vier davon mit Fensterkontakten. Alle Rollladen sind im Grunde so eingerichtet, dass sie Morgens und Abends per ASC anwesensheits- und jetzt helligkeitsabhängig (früher per astro) gefahren werden und auch die Beschattung ist eingerichtet. Unabhängig davon greifen wir aber nach eigenem belieben manuell (per Taster oder Alexa) gern schon mal ein. Ich bin im wesentlichen sehr zufrieden, auch wenn es ab und an mal unerwartete Effekte gibt.

Was mir aktuell auffällt, das stets bei mindestens einem, oft auch mehr, der Devices der Wert 'ASC_ShuttersLastDrive' nicht korrekt gesetzt ist. Scheint so als wäre es der Wert des Zustandes eins zuvor.

2 Bsp.:

Ich habe gestern Abend einen Rolladen nach dem autom. abendlichen Herunterfahren noch einmal manual geöffnet und wieder geschlossen (die Status im FHEM habe ich leider nicht beobachtet). Er ist, wie gewollt und erwartet, heute Morgen autom. heraufgefahren und steht aber jetzt im "ASC_ShuttersLastDrive" = manual. Ich würde "maximum brightness threshold exceeded" erwarten.

Ein anderer Rollladen ist ausschliesslich autom. gefahren, wie gewollt und erwartet. Steht aber aktuell in "ASC_ShuttersLastDrive = minimum brightness threshold fell below". Auch hier würde ich ehr "maximum brightness threshold exceeded" erwarten.

Die "Lüftungssteuerung" funktioniert weiterhin nicht, allerdings gibt es (eine nicht nachvollziehbare :-) Beobachtung innerhalb der Familie, das ein Rollladen wohl dieser Tage doch gefahren sein soll. Mir scheint da im Moment irgendwo der "Wurm" drin zu sein.

Beste Grüße und Danke für Deine tolle Arbeit
Thomas

Das die Lüftenfunktion bei Dir nicht geht verstehe ich nicht. Einzig mir bekannter Grund wäre das vorher manuell gefahren wurde oder das ASC denkt das manuell gefahren wurde und dann die Blocking Time eingehalten wird. Daher meine Bitte mal die manuelBlockingTime auf 5s oder so stellen und dann probieren. Du kannst das Rollo auch am Tag manuell schließen und das Fenster öffnen. Das Rollo sollte dann in die Lüften oder Komfor Position fahren.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

eldrik

Hi,

welche ASC_Drive_Delay, ASC_DriveDelayStart Attribute müssen in welchem Device gesetzt werden, damit nicht alle Rollläden gleichzeitig angesteuert werden?

Ich habe im ASC Device ASC_Drive_Delay auf 45 gesetzt im Rollladendevice auf -1 und ASC_DriveDelayStart auf 5 dennoch wird im ASC Device für die Geräte dieselbe Fahrzeit angezeigt. Muss dass so?

Greetz
Eldrik

christoph.kaiser.in

#1182
Hallo,

folgendes Verhalten habe ich bei gesetzem Attribut ASC_Adv in meinem System beobachtet:

1) bei allen Rollläden mit gesetzem Attribut wird die "Schließfahrt" ( ... schreibt man das so ?) bis zum Aufruf des Befehls "...advDriveDown" ausgesetzt. - OK
2) bei den Rollläden ohne gesetzem Attribut wird zum durch Sonnenstand definiertem Zeitpunkt geschlossen - OK
3) beim Aufruf des Befehls set <ASC Device Name> advDriveDown zu einem späteren Zeitpunkt, werden alle Rolläden mit gesetzem Attribut geschlossen. - WIE ERWARTET
4) Ein durch Fenstergriff (Komfortöffnung) geöffneter Rolladen wird dabei nicht geschlossen, erst später nach Rücknahme der Öffnung des Fenstergriffs - WIE ERWARTET
5) Eine nachträglich manuell geöffneter Rolladen OHNE gesetzes Attribut wird auch später nicht geschlossen. - WIE ERWARTET
6) Das automatische Öffnen hat heute für alle Rollläden funktioniert. - OK

Bislang würde ich keine Auffälligkeiten sehen - wie sehen das die Experten ?

Ich schaue mir noch das Verhalten für manuellen Fahrten von Rollläden mit gesetzem Attribut vor dem Zeitraum der Unterdrückung und während des Delays der automatischen Schliessung.

In Kombination mit dem Attribut "ASC_ExternalTrigger" und der Funktion "WeekdayTimer" kann ich mir vorstellen die meisten Szenarien der Adventsbeleuchtung abzudecken.

Grüße
Christoph

eurofinder

Ich habe (nachdem meine Probleme mit ASC_adv = on bei einigen Rollläden auftraten) ja ein Systemneustart durchgeführt - bis alles OK.

Gruß
eurofinder
RPI3+; Raspbian Buster Lite; RPI-RF-MOD; piVCCU3, HMIP-eTRV-2, HmIP-SWDO, HmIP-SRH, HmIP-STHO, HmIP-SLO

no_Legend

Ich hab mal eine Frage,

habe einen neunen Homematic Rolladen Aktor angelernt, diesen auch ASC auf 2 gesetzt.
Aber die Attribute werden nicht angelegt, ist das verhalten so korrekt?

Version ist 10.10

Danke und Gruß Robert
Docker FHEM immer aktuell,4x HMLAN, CUL443, CUL868 -homekit/siri -tablet ui -homebridge
Device, diverse:
Homematic, Shelly, Tasmota, MQTT, Unifi Network usw.