[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

CoolTux

Das tut mit leid, aber das wird so nicht gehen.

Was Du bräuchtest wäre sowas wir

set Rolladen_Tim_rechts position 30


oder auch


set Rolladen_Tim_rechts pct 30


Also so in der Art.
gleichzeitig müsste es auch Readings geben namens pct oder eben position oder irgendwas was funktioniert wo dann die position des Rolladen hinterlegt ist.
Also

pct 30

als Beispiel.
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

majestro84

Prinzipiell funktioniert die Steuerung ein Rollo ist wie geplant in Sichtschutz Position gefahren und zu der civil Zeit komplett geschlossen. Das zweite Rollo ist nur zu der civil Zeit runtergefahren. Erste Rollo habe ich heute vormittag eingestellt und danach fhem noch mal neu gestartet im Laufe des Tages. beim zweiten Rollo nicht. kann das sein dass du das dann erst bei der neuen Berechnung also für morgen berücksichtigt. Wenn ich die Fahrzeiten von Real auf civil umstelle wird es ja sofort berücksichtigt
Server: Fujitsu ESPRIMO Q920 - aktuellen FHEM-Docker Image:Z-Wave (RollerShutter,DoorWindow,Socket,PIR,....) | ENIGMA2 | EGPM2LAN | BLE-Tag(PRESENCE) | HUE | alexa-fhem | Shelly | MQTT2
1.Pi-Zero:Viessmann(optolink) mit 89_VCONTROL300.pm
2.Pi3 Dongle Server: Zigbee2MQTT(CC1352P-2), Z-Wave(UZB1), BT

CoolTux

Zitat von: majestro84 am 24 Januar 2019, 18:12:26
Prinzipiell funktioniert die Steuerung ein Rollo ist wie geplant in Sichtschutz Position gefahren und zu der civil Zeit komplett geschlossen. Das zweite Rollo ist nur zu der civil Zeit runtergefahren. Erste Rollo habe ich heute vormittag eingestellt und danach fhem noch mal neu gestartet im Laufe des Tages. beim zweiten Rollo nicht. kann das sein dass du das dann erst bei der neuen Berechnung also für morgen berücksichtigt. Wenn ich die Fahrzeiten von Real auf civil umstelle wird es ja sofort berücksichtigt

Das ist in der Tat so. Ich werde das Event für das Attribut setzen noch anfangen müssen damit er dann die Zeitberechnung neu startet.
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

stonev

Zitat von: CoolTux am 24 Januar 2019, 17:18:41
Das tut mit leid, aber das wird so nicht gehen.

Was Du bräuchtest wäre sowas wir

set Rolladen_Tim_rechts position 30


...


Man kann für "setG4" einen Alias vergeben. Ich habe ihn "position" genannt und nun fährt der Rolladen auch mit dem Befehl
set Rolladen_Tim_rechts position 30
Soweit so gut. Fehlt mir noch das Reading.

Muss das Reading zwingend auch <position> heißen?

majestro84

Was mir jetzt noch aufgefallen zu der Version aus dem git ist folgendes.
Wenn ich die Rolllade manuell zur Hälfte zum Beispiel hoch fahre nach dem night close und dann das Fenster öffne wird in die comfort Position gefahren soweit alles wie vorher. Was sich jetzt geändert hat ist das wenn ich das Fenster wieder schließe die Rolllade in der comfort Position bleibt und nicht wie vorher wieder komplett schließt. Es greift die BlockingAftermanuell Zeit. Anschließend muss ich die Rolllade von Hand wieder schließen.
Oder fährt sie nach der Zeit(BlockingAftermanuell)alleine zu?
Ist das so von dir gewollt gewesen?
Wenn ja wäre es dann nicht schöner wenn sie nach dem schließen in die vorher manuell eingestellte Position fährt?
Server: Fujitsu ESPRIMO Q920 - aktuellen FHEM-Docker Image:Z-Wave (RollerShutter,DoorWindow,Socket,PIR,....) | ENIGMA2 | EGPM2LAN | BLE-Tag(PRESENCE) | HUE | alexa-fhem | Shelly | MQTT2
1.Pi-Zero:Viessmann(optolink) mit 89_VCONTROL300.pm
2.Pi3 Dongle Server: Zigbee2MQTT(CC1352P-2), Z-Wave(UZB1), BT

CoolTux

Cool.
Ja muss es, aber das ist ja das kleinste Problem. Einfach ein userReadings machen und auf getG4 oder so triggern lassen. Stimmt den die Position vom Reading getG4 mit der tatsächlichen Position?
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: majestro84 am 24 Januar 2019, 19:52:16
Was mir jetzt noch aufgefallen zu der Version aus dem git ist folgendes.
Wenn ich die Rolllade manuell zur Hälfte zum Beispiel hoch fahre nach dem night close und dann das Fenster öffne wird in die comfort Position gefahren soweit alles wie vorher. Was sich jetzt geändert hat ist das wenn ich das Fenster wieder schließe die Rolllade in der comfort Position bleibt und nicht wie vorher wieder komplett schließt. Es greift die BlockingAftermanuell Zeit. Anschließend muss ich die Rolllade von Hand wieder schließen.
Oder fährt sie nach der Zeit(BlockingAftermanuell)alleine zu?
Ist das so von dir gewollt gewesen?
Wenn ja wäre es dann nicht schöner wenn sie nach dem schließen in die vorher manuell eingestellte Position fährt?

Weder noch. Eigentlich hätte das Teil gar nicht fahren sollen innerhalb der blockingAfterManual Zeit.
Weder noch noch runter. Das war von den Usern so gewünscht. Muss ich mir noch einmal anschauen wieso er hoch gefahren ist.
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

Habe eben mal geschaut. In der Tat wird nur beim schließen der Fenster das blockingAfterManual beachtet. Wie ist da das Gefühl, der Wunsch? Kann mich erinnern das gewünscht würde das innerhalb der Zeit gar nichts reagieren soll.
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

majestro84

OK keine Ahnung wie das die anderen sehen für mich wäre es jetzt das optimale wenn die Manuel eingestellte Position unterhalb der comfort ist, soll beim öffnen auf comfort gefahren werden. Dann wenn innerhalb der BlockingAftermanuel geschlossen wird wieder in die vorher Manuel eingestellte Position. Wenn die BlockingAftermanuel abgelaufen ist und dann erst das Fenster geschlossen wird, Rolllade komplett schließen.
Server: Fujitsu ESPRIMO Q920 - aktuellen FHEM-Docker Image:Z-Wave (RollerShutter,DoorWindow,Socket,PIR,....) | ENIGMA2 | EGPM2LAN | BLE-Tag(PRESENCE) | HUE | alexa-fhem | Shelly | MQTT2
1.Pi-Zero:Viessmann(optolink) mit 89_VCONTROL300.pm
2.Pi3 Dongle Server: Zigbee2MQTT(CC1352P-2), Z-Wave(UZB1), BT

CoolTux

Das wird so nicht zu realisieren sein. Wir können es so lassen wie es jetzt ist, was in meinen Augen ein Fehlverhalten ist da blockingAfterManual bedeutet blockiere alle Befehle oder ich setze das blockingAfterManual für alle Fensterevents um.
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

diki

Also ASC_BlockingTime_afterManual stelle ich mir so vor, dass für die eingestellte Zeit nach einem manuellen Hochfahren alle automatischen Fahrten blockiert sind - bis die Zeit abgelaufen ist. (Das hat schon mal gut funktioniert. Gestern habe ich festgestellt, dass nach dem Schließen des Fensterkontaktes trotz "ASC_BlockingTime_afterManual" der Rollladen geschlossen wurde (VERSION 0.2.3.3).

CoolTux

Zitat von: diki am 25 Januar 2019, 07:55:33
Also ASC_BlockingTime_afterManual stelle ich mir so vor, dass für die eingestellte Zeit nach einem manuellen Hochfahren alle automatischen Fahrten blockiert sind - bis die Zeit abgelaufen ist. (Das hat schon mal gut funktioniert. Gestern habe ich festgestellt, dass nach dem Schließen des Fensterkontaktes trotz "ASC_BlockingTime_afterManual" der Rollladen geschlossen wurde (VERSION 0.2.3.3).
Das schaue ich mir heute an.
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

majestro84

Zitat von: CoolTux am 24 Januar 2019, 20:35:59
Das wird so nicht zu realisieren sein. Wir können es so lassen wie es jetzt ist, was in meinen Augen ein Fehlverhalten ist da blockingAfterManual bedeutet blockiere alle Befehle oder ich setze das blockingAfterManual für alle Fensterevents um.
Ich denke dann ist es am besten es für alle Fenster Events zu setzen. Wie du ja schon sagst, so wie es in der git Version ist, ist es ein Fehlverhalten
Server: Fujitsu ESPRIMO Q920 - aktuellen FHEM-Docker Image:Z-Wave (RollerShutter,DoorWindow,Socket,PIR,....) | ENIGMA2 | EGPM2LAN | BLE-Tag(PRESENCE) | HUE | alexa-fhem | Shelly | MQTT2
1.Pi-Zero:Viessmann(optolink) mit 89_VCONTROL300.pm
2.Pi3 Dongle Server: Zigbee2MQTT(CC1352P-2), Z-Wave(UZB1), BT

stonev

Zitat von: CoolTux am 24 Januar 2019, 19:54:05
Cool.
Ja muss es, aber das ist ja das kleinste Problem. Einfach ein userReadings machen und auf getG4 oder so triggern lassen. Stimmt den die Position vom Reading getG4 mit der tatsächlichen Position?

Läuft wunderbar jetzt. Ich kann gar nicht genug danken, das Modul ist klasse!!!
Mir ist nur nicht ganz klar, was die Readings <Rolladen_Tim_links_PosValue> und <Rolladen_Tim_links_lastPosValue> im ASC Device bedeuten? Beide stehen auf dem Wert "0".
Lass ich mir die Infos über <get showShuttersInformations> anzeigen, werden die aktuelle und die vorletzte Position korrekt angezeigt.

Noch eine zweite (hoffentlich nicht zu blöde Frage):
Im Wiki stehen die Definitionen für die ReadingGroups, um z. B. die Zeiten einzustellen. Das habe ich auch gemacht, aber mir werden im Webinterface nicht die DropDown-Auswahlfelder angezeigt. Die Einstellung der Werte ist daher nicht möglich. Es werden nur die aktuell eingestellten Werte ausgelesen. Auf die Schnelle ne Idee, was falsch sein könnte?

Das Mapping ist definiert wie im Wiki:
{level => 'pct:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100', \
ASC_Mode_Down => 'ASC_Mode_Down:always,absent,off',\
ASC_Mode_Up => 'ASC_Mode_Up:always,absent,off',\
ASC_Time_Down_Early => 'ASC_Time_Down_Early:15:00,15:15,15:30,15:45,16:00,16:15,16:30,16:45,17:00,17:15,17:30,17:45,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00', \
ASC_Time_Down_Late  => 'ASC_Time_Down_Late:20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30',\
ASC_Time_Up_Early => 'ASC_Time_Up_Early:05:00,05:05,05:30,05:45,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00', \
ASC_Time_Up_Late =>'ASC_Time_Up_Late:06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00',ASC_Time_Up_WE_Holiday => 'ASC_Time_Up_WE_Holiday:06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00'}