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

Begonnen von CoolTux, 30 Oktober 2018, 17:29:46

Vorheriges Thema - Nächstes Thema

dancatt

Ich meine damit wie zum Beispiel beim DOIF Modul.
So dass eben nichts mehr triggert und ausgeführt wird.
Hoffe das ist etwas klarer.
Cubietruck: FHEM-Server 6.0

Homematic: HM-USB-CFG2, HM-CFG-LAN, HM-LC-SW1-FM, HM-LC-Sw1-Pl-DN-R1, HM-CC-RT-DN, HM-TC-IT-WM-W-EU, HM-SEC-SC-2, HM-SEC-SD, HM-PB-6-WM55

CoolTux

Jepp,

Also ausführen tut das Modul jetzt schon nicht wenn Du ASC 0 setzt, triggern würde es aber ohne Auswirkungen. Aber wie gesagt es wird ein disable geben.
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

Prof. Dr. Peter Henning

OK, bekenne mich eines Reloads für schuldig.

Feature request:
Wenn ASC_Up oder ASC_Down auf "time" stehen, wird eine feste Zeit genommen. Es wäre m.E. genausogut möglich, als Wert des Attributes ASC_Time_Up_Early einen beliebigen Perl-Ausdruck zu setzen, der einen Zeitwert zurückliefert.

Ich habe in meinen Weckroutinen ein Öffnen der Rollläden direkt nach dem Weckvorgang eingebaut - könnte also hier eine Perl-Funktion einsetzen, die das entsprechende Device nach der aktuellen Weckzeit abfragt. Außerdem müsste dokumentiert werden, was man machen muss, um in ASC die Neuberechnung der Timer zu starten.

LG

pah

CoolTux

Zitat von: Prof. Dr. Peter Henning am 27 Februar 2019, 20:58:45
OK, bekenne mich eines Reloads für schuldig.

Feature request:
Wenn ASC_Up oder ASC_Down auf "time" stehen, wird eine feste Zeit genommen. Es wäre m.E. genausogut möglich, als Wert des Attributes ASC_Time_Up_Early einen beliebigen Perl-Ausdruck zu setzen, der einen Zeitwert zurückliefert.

Ich habe in meinen Weckroutinen ein Öffnen der Rollläden direkt nach dem Weckvorgang eingebaut - könnte also hier eine Perl-Funktion einsetzen, die das entsprechende Device nach der aktuellen Weckzeit abfragt. Außerdem müsste dokumentiert werden, was man machen muss, um in ASC die Neuberechnung der Timer zu starten.

LG

pah

Den Fehler mit evaluation habe ich beseitigt. Da hast Du einen ganz üblen Bug gefunden. Danke.
Deinen Feature request notiere ich mir. Kann mich erinnern das zu mindest noch ein weiterer ein ähnliches Anliegen hatte.

Die Timer neu Berechnung startet sich eigentlich von selbst nach dem man die entsprechenden Attribute gesetzt hat. Also nach jedem setzen eines passenden Attributes.
Alternativ kann man mit

renewSetSunriseSunsetTimer - erneuert bei allen Rollläden die Zeiten für Sunset und Sunrise und setzt die internen Timer neu.

neu einlesen und Berechnen lassen.

Ich habe das aus der deutschen Doku. Kann sein das die englische etwas hinter her hingt.


Grüße
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

Wir hatten ja letztens das Thema Durchschnittswert bei Brightness. Oder das kann man glaube auch Werteglättung nennen, oder?
Af jeden Fall würde ich das gerne einbauen das nicht gleich beim sofortigen überschreiten eines Wertes gefahren wird sondern das ein Durchschnitt der letzten Werte genommen wird. Frage, wie viele Werte sollte ich dafür so in etwa ran ziehen? 3 oder 5?


Grüße
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

Prof. Dr. Peter Henning

Schau Dir mal den Code für movingAverage an, den habe ich irgendwann 2014 oder so geschrieben:
https://wiki.fhem.de/wiki/Gleitende_Mittelwerte_berechnen_und_loggen#Gleitender_Mittelwert_f.C3.BCr_beliebige_Readings

Kann unmittelbar verwendet werden, benötigt neben Devicename einen Readingnamen und eine Zeitspanne, würde also gut in ASC passen.

LG

pah

stefanpf

Die Glättung müsste bitte konfigurierbar / abschaltbar sein (ist schon wieder Wunschkonzert :-) ).
- Sendet ein Sensor in sehr kurzen Abständen würde der gewünschte Effekt bei wenigen Werten sonst vermutlich verpuffen.
- Bei meinem Temperaturdifferenzsensor-zu-Brightness Sensor, der nur alle 15min aufwacht, wäre ein Mittelwert über 5 Werte vermutlich oft bereits zu viel.

Aus dem Bauch heraus würde ich die Werteglättung eigentlich nicht im ASC Device sehen.
Für maximale Flexibilität sollte das entweder im Sensor geschehen oder in einem Dummy Hilfsdevice.

Vielleicht ein Kompromiss:
Ist es möglich, dass man das entsprechende Sensor Attribut  etwas flexibler macht und optional Funktionsaufrufe erlaubt ?
Also entweder DEVICE / READING oder avgWertBerechnung( DEVICE, READING)

Dann könnte der Anwender wahlweise
- mit den Rohdaten des Sensors arbeiten
- eine von dir mitgelieferte Basisfunktion nutzen
- eine eigene Funktion in der 99_myutils nutzen

Edit: gerade beim Duschen noch einmal drüber nach gedacht... bei dem Funktionsaufruf fehlt dir ja das Event  >:(

CoolTux

Gerade entschieden das solche Glättungen am besten im Sensordevice getätigt werden sollten. eine myUtils oder ein userReadings. Gerade bei Wind finde ich das selbst unglücklich gewählt wenn die Daten pur reinkommen bei einer Windböe. Aber da wir das ganze eh noch mal anfassen kann man das auch auf später verlegen.
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

@Beta-User

'ASC_Wind_Sensor_minMaxSpeed'     => '30:50',


Ich trau mich jetzt  ;D ein erster kleiner Schritt.
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

jsChris

Moin,

vielen Dank für dieses Modul, das ich (ab gestern) jetzt in Betrieb genommen habe :)

Ein paar Einstellungen sind mir noch nicht ganz klar und ich kann auch nichts darüber finden. Ich würde gerne in 2 Räumen die Rolladen nicht ganz schließen, bzw. nicht ganz öffnen. Ich dachte, ich könnte das mit ASC_Open_Pos und ASC_Closed_Pos bestimmen. Aber es scheint nicht so zu funktionieren, wie ich dachte :).

Gibt es diese Möglichkeit gar nicht, so wie ich es mir vorstelle oder braucht es dafür noch eine andere Einstellungen?

Vielen Dank
Chris

CoolTux

Hallo Chris,

Das sollte eigentlich genau damit funktionieren. Du müsstest nur bisschen drauf achten nicht die selben Positionen zu nehmen wie für Fenster offen oder Beschattung oder welche Möglichkeiten Du da noch nutzt an Attributen.
Aber im groben sollte ein openPos 95 oder closedPos 5 keine Probleme machen.

Grüße
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

Kai-Alfonso

Zitat von: CoolTux am 28 Februar 2019, 08:07:28

Aber im groben sollte ein openPos 95 oder closedPos 5 keine Probleme machen.

Grüße

95 kann ich bestätigen, dass das ohne Problem läuft.
Raspi2|nanoCul433|nanoCul868|CCU2
Energie-USBZähler|homebrew HM Devices
DBLog|DBRep|Homematic|Baumarktsteckdosen
Hue|Webcams mit DS-Station (Synology)|Bewegungsmelder|Rollladen|Schalter (IT|HM)

CoolTux

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

FunkOdyssey

Zitat von: CoolTux am 28 Februar 2019, 07:42:38
Gerade entschieden das solche Glättungen am besten im Sensordevice getätigt werden sollten. eine myUtils oder ein userReadings. Gerade bei Wind finde ich das selbst unglücklich gewählt wenn die Daten pur reinkommen bei einer Windböe. Aber da wir das ganze eh noch mal anfassen kann man das auch auf später verlegen.

Zustimmung.

Ich hatte mir anfänglich im Beta-Thread auch so eine Funktion gewünscht. Aber das würde die Komplexität des Moduls einfach sprengen.
Es gibt diverse Zusatzmodule, eigene DOIFs oder userreadings-Modifier, die einem diese Arbeit abnehmen. Wer bereits ein DOIF z.B. für die Mittelwertsbildung verschiedener Helligkeitssensoren nutzt, kann nun neuerdings sogar DOIF-interne Median und/oder Average-Features benutzen. Ich habe selbst noch nie gemacht. Meine Homematic-Bewegungsmelder lassen sich glücklicherweise nicht vom Scheinwerfer-Licht täuschen. Aber spätestens mit den Lux-Werten für die Sommerbeschattung muss ich mir selbst auch etwas einfallen lassen.

Die Dinge sind nur so individuell, dass es vom "Lieferanten" abgefangen werden sollte. ASC sollte sich aufs Wesentlich konzentrieren.

dk3572

Zitat von: CoolTux am 16 Januar 2019, 10:20:41

sub calendarEvents($) {
    my $calDev  = shift;
    my $value = 0;
    my $start = CommandGet(undef,$calDev.' events format:custom="$S $t2" filter:mode=="start"');
    my $upcoming = CommandGet(undef,$calDev.' events format:custom="$S $t2" filter:mode=="upcoming"');

    CommandSet(undef,'dummy'.AttrVal($calDev,'alias',undef).' '.(length($start) > 0 ? 1 : 0) );

    $value = 1 if ( (length($start) > 0 and int((split('\s',$start))[1] / 86400) != int(time() / 86400 )) or length($upcoming) > 0 );
    CommandSet(undef,'dummy'.AttrVal($calDev,'alias',undef).' tomorrow '.$value);
}


Hallo Dieter,
Verwende bitte mal den Code hier.

Hallo CoolTux,

hat sich evtl. bei dem Calendar Modul etwas geändert und dein code funktioniert dadurch nicht mehr?
Bei meinem dummy bleibt das reading tomorrow immer auf 1 stehen, egal ob Termin vorhanden oder nicht.
Der state zeigt wenn morgen Termin vorhanden, tomorrow 1, wenn morgen kein Termin, tomorrow 0.

defmod notifySetCalendarDummys notify Google_Arbeitsfrei:triggered { calendarEvents($NAME) }

setstate notifySetCalendarDummys 2019-02-28 16:21:52
setstate notifySetCalendarDummys 2019-02-27 18:47:12 state active


defmod dummyGoogle_Arbeitsfrei dummy
attr dummyGoogle_Arbeitsfrei alias Google Arbeitsfrei
attr dummyGoogle_Arbeitsfrei event-on-change-reading state,tomorrow
attr dummyGoogle_Arbeitsfrei icon hue_room_garden
attr dummyGoogle_Arbeitsfrei readingList tomorrow,state
attr dummyGoogle_Arbeitsfrei setList tomorrow:0,1 state:0,1

setstate dummyGoogle_Arbeitsfrei tomorrow 0
setstate dummyGoogle_Arbeitsfrei 2019-02-28 16:21:52 state tomorrow 0
setstate dummyGoogle_Arbeitsfrei 2019-02-20 03:57:10 tomorrow 1


VG Dieter