Betatester für neues Modul AutoShuttersControl gesucht!

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

Vorheriges Thema - Nächstes Thema

Cluni

Zitat von: Beta-User am 09 Oktober 2018, 14:08:32
Also frühestens, wenn die Mindestzeit durch ist und der Helligkeitswert bereits paßt, dann Reaktion auf Helligkeit, es sei denn, die späteste Zeit würde erreicht (dann Zwangsfahrt).

Dabei wird es dann aber tricky bei der spätesten Zeit, wenn man nicht alle Rollladen gleichzeitig fahren lassen will. Man könnte das dann ggf. so machen, dass man bei Überschreitung des spätesten Zeitpunks nochmal die eingestellte Zufallszeit oben drauf rechnet. Oder man zieht vorher die maximale Zufallszeit von der spätesten Zeit ab. Ich hoffe ihr wisst, was ich meine?!  :o *crazy*

Beta-User

Mist, das muß ja pro Rollladen sein ??? . Dann müßte man statt der Fahrt erst die Bedingung prüfen und dann ggf. einen weiteren Timer (alle 5 Min oder so) setzen, der wieder dasselbe macht (es sei denn, die max-Zeit würde zwischendurch erreicht, dann halt die)...
Frickelei, damische ::) .
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

Cluni

Nein, das kann man auch reihum bei jedem neuen Helligkeiwert machen. So läuft bei mir die Abschattung...


Gesendet von iPhone mit Tapatalk

Beta-User

Auch eine Möglichkeit.
Wenn man Helligkeit eh' im notifydev hat, bräuchte man der Auswertelogik nur noch zu sagen, dass sie eben den aktuellen Modus (Öffnen, Abschatten oder Schließen) mit berücksichtigt. Ist vermutlich einfacher.
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

Cluni

Zitat von: Beta-User am 09 Oktober 2018, 14:23:03
Auch eine Möglichkeit.
...bräuchte man der Auswertelogik nur noch zu sagen...

Na ja - ganz so einfach ist das alles ja nicht. Erstens läuft aktuell morgendliches Öffnen und abendliches Schließen ja über Timer (bei mir im Skript werden normale Timer erzeugt, im Modul sind das m.W. interne Timer). Diese würden bei einer Helligkeitssteuerung ja komplett entfallen und die darin programmierte Logik muss dann an ganz anderer Stelle (im Helligkeits-Notify) passieren. Es wird da schon einiges an Hirnschmalz reinzustecken sein, dass das dann statt nach Zeit auf Helligkeit läuft...

Ich weiß nicht, wie CoolTux das intern aufgebaut hat. Am einfachsten wäre das wahrscheinlich, wenn es eine eigene Routine fürs Öffnen und eine fürs Schließen gäbe, die alle anderen Parameter selber aus den Attributen einließt und überprüft. Dann ist es wahrscheinlich egal, ob die Routine in einem Timer oder im Helligkeitsnotify aufgerufen wird...

CoolTux

So schwer sollte das nicht sein. Für jeden Rolladen setzt man eine feste Zeit. Hier sollten wir noch überlegen ob wir die frühste oder die späteste nehmen.
Persönlich denke ich die späteste. Ist diese Erreicht fährt der Rolladen auf jeden Fall.
Ansonsten ist das Prinzip triggern (Helligkeit) und Abfragen (ist es schon dunkel genug zum runter fahren) ein Timer läuft auf jeden Fall mit der Zeit für spätestes fahren und dieser Timer wird gelöscht wenn früher gefahren wird.

Da ich nun alles auf OOP umgestellt habe habe ich unendliche Auswahl an Objektabfragen ohne das ich doppelten Code verwenden muss.
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

Hmmm, an sich fände ich auch den späteren logisch. Aber dann müßtest du immer bei jedem Event prüfen, ob die frühesten Zeiten schon um sind. Kann nicht sagen, ob es nicht resourcenschonender wäre, den ersten Timer zu nehmen, um einen internen Merker für den Modus zu setzen und dann erst den späteren Timer zu setzen. Die Modusabfrage wäre in meinen Augen einfacher als ein Zeitenvergleich (und das braucht man ja für jeden Rollladen separat...).
Die reine Abfrage, ob der Timer vorhanden ist, geht sonst ja schon sehr früh auf positiv, nämlich vor der frühesten Fahrzeit und hat dann wenig Aussagekraft.
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

Nein nein, falsch verstanden. Es wird nur einer der beiden verwendet. Also nicht wie bei Astro wo die Zwischenzeit ermittelt und wenn drüber oder drunter die Grenzen genommen werden, sondern eine feste Zeit für Schicht im Schacht. Das dynamische kommt ja durch die Helligkeit.
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

Das erst mal nur einer relevant sein kann, hatte ich schon verstanden. Aber die Frage ist doch trotzdem, ob es auch eine früheste Zeit geben soll(te) (oder nur eine späteste). Vermutlich soll es schon sowas geben wie bei Astro, nur, dass eben das "Dazwischen" nicht durch Astro vorher festgelegt wird, sondern durch Helligkeit at runtime "getriggert" werden soll.

Bei Astro hast du halt gleich bei der Erstellung des Timers nur einen Wert. Das geht hier nicht, sondern "dazwischen" muß auf Helligkeit reagiert werden (davor und danach - jedenfalls außerhalb der Beschattung - nicht). Dafür muß bei einem Helligkeitsevent geprüft werden, ob es relevant ist - was nach dem geschilderten Modell ja erst der Fall ist, wenn die früheste Zeit um ist; hier würde ich eben statt des kompletten Durchlaufs, ob es denn schon spät genug ist, nur ein Internal/ein intern verwaltetes Arrat oder irgend sowas abscannen und dann die relevanten Rollläden bearbeiten/fahren.
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

Guten Morgen

Ich habe soeben eine neue Version 0.1.76 ins Git hochgeladen. Neu hinzugekommen ist SelfDefense Mode und die Umstellung des gesamten Modules auf OOP (Objektorientierte Programmierung).
Außer dem habe ich die get Ausgaben etwas angepasst. Bitte mal schauen ob es so schön ist  :)


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

C0mmanda

Sehe ich das richtig, der SelfDefense Modus arbeitet grundsätzlich bei allen Fenstern (Mit Fensterkontakten natürlich), ich kann keine davon ausschliessen?

Danke!
grtz
C0mmanda

CoolTux

Ich sehe da keinen Grund einen aus zu schließen. Entweder ich will das Haus schützen oder nicht. Ist wie bei einer Alarmanlage, alles oder gar nichts.

Wäre übrigens nicht schlecht wenn das mal einer testen könnte. Ich kann das immer nur simulieren.
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

C0mmanda

Zitat von: CoolTux am 10 Oktober 2018, 19:50:04
Ich sehe da keinen Grund einen aus zu schließen. Entweder ich will das Haus schützen oder nicht. Ist wie bei einer Alarmanlage, alles oder gar nichts.

Wäre übrigens nicht schlecht wenn das mal einer testen könnte. Ich kann das immer nur simulieren.

Würde da auch nicht unbedingt widersprechen, wenngleich es bei mir am Haus Rolläden gibt wo dies nicht zwingend nötig wäre...

Kann es frühestens morgen testen.
Werde berichten.

Gruss

CoolTux

So ein Mist, in der letzten Version hat sich ein Bug eingeschlichen. Damit fahren zu mindest bei mir die Rolläden nicht wo es kein roommate Device gibt.  :(
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

Ich habe eben ein Fix hochgeladen. Version 0.1.78.
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