Betatester für neues Modul AutoShuttersControl gesucht!

Begonnen von CoolTux, 01 September 2018, 12:10:35

Vorheriges Thema - Nächstes Thema

CoolTux

Zitat von: Karflyer am 28 Oktober 2018, 17:18:10
Hm. Wann fahren dann bei dir morgens die Rolläden, die nicht durch den/die Roommates getriggert sind?

Bei mir ist das eigentlich so. Ich stehe beispielsweise in der Woche zwischen 06:00Uhr und 07:00Uhr auf. Nehmen wir als frühest möglich Zeitpunkt (Time_Up_Early) 06:00Uhr und ich stehe erst um 07:00 Uhr auf, dann wären die meisten Rolläden eine Stunde zu früh oben (unschön in dieser dunklen Jahreszeit). Bei einem Time_Up_Early um 07:00Uhr würde es wiederum nicht passen, wenn ich bereits um 06:00 Uhr aufstehe. Die Rolläden kämen eine Stunde zu spät hoch (wenn ich sie nicht manuell betätige). Daher war für mich immer genau das Roommate-awoken, der ideale Trigger um alle Rolläden hoch zu fahren.

Die Rolläden ohne Roommate fahren wenn es hell wird. Bei mir HORIZON -3
Damit fahren sie dann natürlich eventuell früher wie die Rolläden mit Roommate, aber das ist ja normal.

Vielleicht habe ich auch ein anderes Verständnis oder Wahrnehmung von den Teilen. Mein Verständnis ist das die Rolläden runter fahren sollen wenn es dunkel ist und im Raum Licht an geht wegen reinschauen. Genau so ist es morgens wenn es Hell ist nicht mehr nötig sie unten zu haben ausser da wo noch geschlafen wird.
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

Karflyer

ZitatWas mich an dieser Stelle noch interessieren würde, wie wird der awoken Status denn bei dir gesetzt, bzw. ausgelöst?
Durch Bewegungsmelder, Türkontakte, o.ä.?

Steuerung erfolgt über 'Bett-Sensoren' (kleines Arduino-Projekt vom Matthias Kleine 'abgekupfert')  :D .

Karflyer

ZitatVielleicht habe ich auch ein anderes Verständnis oder Wahrnehmung von den Teilen. Mein Verständnis ist das die Rolläden runter fahren sollen wenn es dunkel ist und im Raum Licht an geht wegen reinschauen. Genau so ist es morgens wenn es Hell ist nicht mehr nötig sie unten zu haben ausser da wo noch geschlafen wird.

Ja, kann man so sehen. Passt ja auch (meistens) auf das Wochenende. Es wird irgenwann hell, die Rollos fahren hoch (außer wo geschlafen wird). In der Woche ist es, zumindest im Winter noch nicht hell, wenn aufgestanden wird...
Ich will aber nicht weiter auf dem Thema rumreiten. Das Modul ist wirklich klasse! Freue mich schon auf die nächsten Erweiterungen.
Stefan

CoolTux

Zitat von: Karflyer am 28 Oktober 2018, 17:51:44
Ja, kann man so sehen. Passt ja auch (meistens) auf das Wochenende. Es wird irgenwann hell, die Rollos fahren hoch (außer wo geschlafen wird). In der Woche ist es, zumindest im Winter noch nicht hell, wenn aufgestanden wird...
Ich will aber nicht weiter auf dem Thema rumreiten. Das Modul ist wirklich klasse! Freue mich schon auf die nächsten Erweiterungen.
Stefan

Ist ja kein rumreiten, zu mindest nicht in meinen Augen. Mich interessieren ja die Hintergründe zu euren Anliegen.
Bisher habe ich versucht so wenig Belastung wie möglich in FHEM rein zu bringen. Habe aber gerade heute mitbekommen das ich doch noch recht viel Luft habe.

Beispiel:
Ich habe es nun so gemacht das auf alle Attributsänderungen reagiert wird die mit der Fahrzeitberechnung zu tun haben. Es wird also beim ändern eines Attributes sofort die neue Zeit berechnet für den einzelnen Rolladen.
Nun habe ich heute morgen ein devspec ausgelöst und auf 10 Rolläden gleichzeitig ein Attribut geändert. Bei allen wurde korrekt die Zeit binnen millisekunden berechnet.

Ich schaue mal das ich die Roommate Fahrten versetzt hin bekomme.



Kurze Zusammenfassung zu aktuellen Entwicklungen:
- Ich habe Regensensor eingebaut. Funktioniert auch super.
- Ich habe die Anzeige und das neusetzen für NOTIFYDEV so gemacht das man die Befehle nur ab verbose > 3 sieht
- Eine Menge Code wurde angepasst und verbessert. Gerade im Bereich Fahrzeiten
- Es wird nun der Residentsstatus bei den Zeitfahrten beachtet wo kein Roommate angegeben ist. So kann man ohne Probleme ASC_Mode_Down und ASC_Mode_Up auf home oder absent setzen und dies wird beachtet durch das Residentsdevice wenn kein Roommate da ist.

offene Punkte:
Was soll gemacht werden wenn die Zeitfahrt nicht geklappt hat wegen Roommate oder Residents Status?
Beispiel. Es soll nur bei home gefahren werden. Nun bin ich abwesend und die Zeitfahrt wäre dran. Er fährt also nicht. Und wenn ich nach Hause komme ist zum Beispiel der Rolladen noch unten. Was soll also mit den Rolladen passieren wenn ich home komme?
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

Karflyer

Zitatoffene Punkte:
Was soll gemacht werden wenn die Zeitfahrt nicht geklappt hat wegen Roommate oder Residents Status?
Beispiel. Es soll nur bei home gefahren werden. Nun bin ich abwesend und die Zeitfahrt wäre dran. Er fährt also nicht. Und wenn ich nach Hause komme ist zum Beispiel der Rolladen noch unten. Was soll also mit den Rolladen passieren wenn ich home komme?

Ich würde sagen, wenn ich vor den 'Abendfahrzeiten' nach Hause komme, sollten die Rolläden noch oben fahren. Möglicherweise könnte man prüfen welche Stellung die Rolläden gehabt hätten, wenn regulär gefahren worden wäre (Beschattung, Regen, Wind...) und die Rolläden in diese Stellung bringen. Komme ich nach den 'Abendfahrzeiten' nach Hause, würde ich die Rollos in der geschlossen Stellung belassen.

CoolTux

Siehste das ist auch noch so eine Sache. Soll später das Beschatten unabhängig von home oder absent geschehen? Ich persönlich bin der Meinung ja
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

Thema Zeitversetztes fahren.
Ich hätte da eine Lösung denke ich, dann würde ich aber die Attribute
ASC_Offset_Minutes_Evening
ASC_Offset_Minutes_Morning
gerne austauschen durch ein allgemeines
ASC_Offset_Minutes
und dann kann man noch drüber nach denken das nicht einfach global zu setzen. Also im ASC Device und nicht pro Rolladen.
Würde aber bedeuten das jeder Fahrbefehl vom Modul entsprechend um eine Zufallszeit innerhalb des offset versetzt passiert.

Was denkt Ihr darüber?
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

Beta-User

Die Zahl der Attribute einigermaßen klein zu halten finde ich gut; aber einen Wert für alle Rollläden nicht.
Habe z.B. im EG den Wunsch, alle praktisch zeitgleich zu fahren, im OG (meist leere Kinderzimmer) würden versetzte Zeiten realistischer Anwesenheit simulieren...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

CoolTux

Nun dann schlage ich vor wir machen ein Attribut für die Rolläden
ASC_Drive_Offset
und ein globales im ASC Device
ASC_shuttersDriveOffset
Angaben in Sekunden

An den Rolläden wo ASC_Drive_Offset nicht eingestellt ist (Wert -1 oder 0 ) wird dann der globale Wert aus dem ASC Device Attribut ASC_shuttersDriveOffset genommen. Ist der nicht gesetzt oder null wird immer sofort gefahren.

Meinungen dazu?
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

Cluni

Bei -1 würde ich vorschlagen, dass du den globalen Wert nimmst. Bei 0 tendiere ich dazu genau zum Zeitpunkt (also ohne Offset) zu fahren.

Cluni

Also ich meine die Einstellung am Rollladen selber.

CoolTux

Hallo Bernd,

-1 nehme ich eigentlich nur weil 0 beim ersten anlegen des Attributes nicht greift und das Attribut dann nicht gesetzt wird.
Wenn man aber einmal einen anderen Wert gesetzt hat und dann wieder zurück will kann man auch 0 nehmen. 0 bedeutet eh das er sofort fährt.

Interessant ist das ganze aber dennoch wie Du es vorgeschalgen hast, da man dann steuern kann das er bei 0 auf keinen Fall den globalen Wert beachten 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

Cluni

So war es auch von mir gedacht. Ich bin kein großer Freund davon, dass man ein Attribut explizit löschen muss, damit eine bestimmte Funktion gegeben ist...

Karflyer

ZitatSiehste das ist auch noch so eine Sache. Soll später das Beschatten unabhängig von home oder absent geschehen? Ich persönlich bin der Meinung ja

Da gebe ich dir 'bedingt' recht. Ausgangslage ist heißes Sommerwetter (wie über einen langen Zeitraum in diesem Jahr). Hier macht es Sinn die Rolläden schon morgens bei Zeiten komplett runter zufahren und den ganzen Tag geschlossen zu lassen. Ich habe das über die Wettervorhersage gelöst. Sind Tageshöchstemperaturen über 25°C angesagt fahren die Rolläden morgens bereits zu, wenn die Roommates das Haus verlassen haben oder spätestens beispielsweise um 09:00 Uhr. Und hier kommt der WAF ins Spiel. Wenn das Roommate 'Frau' zu Hause ist und plötzlich alle Rolläden zu fahren, obwohl man das gerade zu diesem Zeitpunkt gar nicht wollte, hat Mann! ein Problem. Deshalb dann die Regelung, ist ein Roommate zu Hause muss der/die sich um die morgentliche Verdunkelung kümmern. Gehen die Roomates 'absent' greift die Automatik in Verbindung mit der Wettervorhersage.

Karflyer

ZitatNun dann schlage ich vor wir machen ein Attribut für die Rolläden
ASC_Drive_Offset
und ein globales im ASC Device
ASC_shuttersDriveOffset
Angaben in Sekunden

An den Rolläden wo ASC_Drive_Offset nicht eingestellt ist (Wert -1 oder 0 ) wird dann der globale Wert aus dem ASC Device Attribut ASC_shuttersDriveOffset genommen. Ist der nicht gesetzt oder null wird immer sofort gefahren.

Das passt doch super und bietet das Maximum an Flexibilität.