FHEM Forum

FHEM => Automatisierung => Thema gestartet von: CoolTux am 01 September 2018, 12:10:35

Titel: Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 01 September 2018, 12:10:35
Hallo,
Der Bernd (Cluni) und ich schreiben seit 2 Monaten an einem neuen Modul.
Das Modul soll Rolläden automatisch nach bestimmten Kriterien steuern. Zum Beispiel Sonnenaufgang und Sonnenuntergang, oder Bewohnerstatus.
Ziel ist es das von Bernd geschriebene 99_myUtils Skript sauber in einem FHEM Modul zu implementieren.
Nun suchen wir für die ersten Funktionen Betatester.
Was solltet Ihr dazu haben? Rolläden, Fensterkontakte und Bewohnerstatus auf Basis von Residents/Roomates in englisch. Es können auch Dummys sein welche home,asleep,gotosleep und awoken setzen. Wichtig wäre noch ein Reading lastState. Aber sowas kann man schnell zaubern, ich helfe da gerne.
Was solltest Ihr nicht haben? Bernd sein Skript im Einsatz. Am besten Ihr habt einfach eigene Sachen mit DOIF oder at und Notify gemacht.
Wichtig ist auch das zum jetzigen Zeitpunkt nur Sonnenaufgang, Sonnenuntergang und Bewohnerstatus funktioniert. Ihr solltest also keinen hohen Anspruch haben.

Grüße
Leon


!!!ACHTUNG!!! Pre Beta - Für erfahrende User und/oder Entwickler gedachte Version!

Ihr benötigt ein aktuelles FHEM. Update ab dem 04.09.2018 Voraussetzung!

Na dann wollen wir einfach mal anfangen. Unten seht Ihr eine kleine Hilfe wie Ihr das Modul einrichten könnt. Bitte erschreckt nicht, das Modul verteilt sehr viele Attribute an die Rollädendevices auf Basis von userattr in den Rolläden. Die userattr Liste wird dabei erweiter, habt Ihr also schon was da drin stehen kommen die Modulattribute hinzu. Genau so verhält es sich beim löschen des Moduldevices. Dabei werden sämtliche Attribute aus den Rollädendevices gelöscht und die userattr liste geleert bis auf das was vorher schon drin stand.

Als erstes empfiehlt es sich im Device der Rolladensteuerung selbst die Attribute an zu passen. Danach muß jedes Rolladendevice durchgegangen werden und die Attribute überprüft und/oder gesetzt werden. Das Roommate Attribut wird da weg gelassen wo kein Bewohner im Raum schläft.

Fügt bitte jedem Rolladen der in die automatische Steuerung rein soll nach dem define von AutoShuttersControl das Attribut AutoShuttersControl 1 oder 2 ein.

Eine ausführliche Anleitung bekommt Ihr über die Commandref des Modules. Wenn Ihr also das Modul kopiert habt dann führt bitte folgendes aus

cd /opt/fhem/
/usr/bin/perl contrib/commandref_join.pl


Und hier noch ein Raw Import zum anlegen eines Dummy Roommates/Bewohner.

defmod rr_Maria dummy
attr rr_Mann readingList state
attr rr_Mann room Test
attr rr_Mann setList state:home,gotosleep,awoken,absent,asleep
attr rr_Mann userReadings lastState:(home|awoken|asleep|gotosleep|absent) { OldValue($name) }



Nun habt Ihr alles durchgelesen und könnt los legen.
Das Modul findet Ihr hier (https://github.com/LeonGaultier/fhem-AutoShuttersControl/archive/devel.zip)
Entpacken und das pm File nach FHEM kopieren Bsp.(/opt/fhem/FHEM/)
Eigentümer und Rechte nicht vergessen an zu passen Bsp.(chmod 755 73_AutoShuttersControl.pm)


Ich wünsche Euch ganz viel Spaß
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: Loredo am 01 September 2018, 12:18:54
Ich würde es mir mal ansehen und Feedback geben.
Ich wollte meine eigenen Notifies auch überarbeiten, vielleicht erübrigt sich das ja.

Ich kenne das myutils Script nicht, ist da auch schon Steuerung anhand des Sonnenstandes (Elevationswinkel + Himmelsrichtung) mit drin?
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: Prof. Dr. Peter Henning am 01 September 2018, 12:21:15
To keep me informed
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: CoolTux am 01 September 2018, 12:28:34
Zitat von: Loredo am 01 September 2018, 12:18:54
Ich würde es mir mal ansehen und Feedback geben.
Ich wollte meine eigenen Notifies auch überarbeiten, vielleicht erübrigt sich das ja.

Ich kenne das myutils Script nicht, ist da auch schon Steuerung anhand des Sonnenstandes (Elevationswinkel + Himmelsrichtung) mit drin?

So weit war ich noch nicht. Wenn ich mich Recht entsinne ist der Azimut zur Bestimmung des Sonnenstandes in der myUtils enthalten. Für die Beschattung. Elevation ist nicht enthalten denke ich. Werde ich aber im Modul einbauen später um Winter und Sommer Sonnenstand zu unterscheiden.
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: Prof. Dr. Peter Henning am 01 September 2018, 13:59:00
Warum nicht die Daten aus Astro nehmen ?

LG

pah
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: CoolTux am 01 September 2018, 14:08:35
Zitat von: Prof. Dr. Peter Henning am 01 September 2018, 13:59:00
Warum nicht die Daten aus Astro nehmen ?

LG

pah

Das war eine Idee, oder Twilight. Die User können da selbst entscheiden und ein Device auswählen.
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: Loredo am 01 September 2018, 14:37:07
Cool! Wie ich mich revanchiere, weiß ich schon, wird aber nicht verraten ;-)
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: CoolTux am 01 September 2018, 15:19:31
Zitat von: Loredo am 01 September 2018, 14:37:07
Cool! Wie ich mich revanchiere, weiß ich schon, wird aber nicht verraten ;-)

Na mein lieber Julian da bin ich aber mal gespannt. Ist ja bald Weihnachten  ;D
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: Beta-User am 01 September 2018, 15:20:12
Vorab ein riesiges DANKE, dass ihr beiden (bzw. drei, nehme ich an) das in Angriff genommen habt!

Wäre dabei, auch wenn anderes Vorrang hat; aber das script in Modulform stand eh' auf meiner ToDo...
Zitat...Bewohnerstatus auf Basis von Residents/Roomates in englisch. Es können auch Dummys sein welche home,asleep,gotosleep und awoken setzen. Wichtig wäre noch ein Reading lastState. Aber sowas kann man schnell zaubern, ich helfe da gerne.
... habe ich, aber bisher keine Bewohner, kannst den Zauberstab rausholen :) .

Freut mich sehr, dass es mit dem "Vermodulen" was wird!

Gruß, Beta-User
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: DS_Starter am 01 September 2018, 15:31:32
Hi Leon und Bernd !,

dein euer Modul kommt gerade zur rechten Zeit.
Ich baue gerade an meinen Rolladen und wollte soeben beginnen ein eigenes Modul dafür zu schreiben.
Da setze ich mich gerne dazu  8)
Residents nutze ich nicht, müsste ich simulieren. Kein Problem wahrscheinlich. Sonnenaufgang/Untergang habe ich bis jetzt mit Sunset/Sunrise abgebildet. Hat für mich ausreichend funktioniert.
Für die Abschattungssteuerung habe ich für jedes Rollo frei konfigurierbare Sensoren sowie Angaben zu deren spezifischen Readings vorgesehen. Das können Helligkeitssensoren (z.B. HM-Sen-MDIR-O-2) sein, aber auch Werte der PV-Anlage. In jedem einzelnen Rollo konnten dann die Schwellenwerte angegeben werden die zum Anfahren der Abschattungsstellung führen. Eine Zeitkomponente komm auch noch hinzu um ein ständiges hoch/Runterfahren zu vermeiden.
Zu guter Letzt wäre noch zu erwähnen dass ein manuelles Betätigen am Rolloschalter dazu führt dass die Automatik abgeschaltet wird und erst beim Hochfahren auf 0% (ganz offen) die Automatik wieder aktiviert wird.

Bin gespannt wie das Modul aufgebaut sein wird.  :)

LG,
Heiko
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: Chris8888 am 01 September 2018, 15:33:38
Hallo Leon, Hallo Bernd,

tolle Nachrichten und jetzt schon vielen Dank für euer Engagement!
Da ich das Script von Bernd einsetzte - sehr erfolgreich! - kann ich ja leider nicht teilnehmen.

Aber ich werde fleißig mitlesen und bin gespannt auf das Modul!

Viele Grüße
Christian
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: CoolTux am 01 September 2018, 17:17:29
Wow, mit soviel Zuspruch hätte ich jetzt nicht gerechnet. Gerade von so einigen FHEM-Mitentwicklern.
Vielleicht findet sich der ein oder andere der Code beisteuert. Natürlich sind auch Ideen erwünscht oder besser sogar noch Schaltlogiken.
Aber immer eines nach dem anderen. Im Moment geht es um Grundfunktionen. Der Rest kommt dann.
Als letztes wollte ich Anfang nächsten Jahres die Beschattung machen, Sommer ist ja nun mal so gut wie vorbei.

Zitat von: Beta-User am 01 September 2018, 15:20:12
...... habe ich, aber bisher keine Bewohner, kannst den Zauberstab rausholen :) .

Gruß, Beta-User

Das ist doch kein Problem. Du legst Dummys an. Atttribut setList mit state:home,awoken,asleep,gotosleep,absent als Attribut readingList nimmst state.
Danach baust noch einen userReadings mit lastState.
So in etwa

Internals:
   CFGFN     
   NAME       rr_Maria
   NR         120
   STATE      home
   TYPE       dummy
   OLDREADINGS:
     2018-09-01 17:13:59   state           gotosleep
   READINGS:
     2018-09-01 17:14:04   lastState       gotosleep
     2018-09-01 17:14:04   state           home
Attributes:
   oldreadings state
   readingList state
   room       Test
   setList    state:home,gotosleep,awoken,absent,asleep
   userReadings lastState:(home|awoken|asleep|gotosleep|absent) { OldReadingsVal($name,'state','none') }




Zitat von: DS_Starter am 01 September 2018, 15:31:32
Hi Leon und Bernd !,

dein euer Modul kommt gerade zur rechten Zeit.
Ich baue gerade an meinen Rolladen und wollte soeben beginnen ein eigenes Modul dafür zu schreiben.
Da setze ich mich gerne dazu  8)
Residents nutze ich nicht, müsste ich simulieren. Kein Problem wahrscheinlich. Sonnenaufgang/Untergang habe ich bis jetzt mit Sunset/Sunrise abgebildet. Hat für mich ausreichend funktioniert.
Für die Abschattungssteuerung habe ich für jedes Rollo frei konfigurierbare Sensoren sowie Angaben zu deren spezifischen Readings vorgesehen. Das können Helligkeitssensoren (z.B. HM-Sen-MDIR-O-2) sein, aber auch Werte der PV-Anlage. In jedem einzelnen Rollo konnten dann die Schwellenwerte angegeben werden die zum Anfahren der Abschattungsstellung führen. Eine Zeitkomponente komm auch noch hinzu um ein ständiges hoch/Runterfahren zu vermeiden.
Zu guter Letzt wäre noch zu erwähnen dass ein manuelles Betätigen am Rolloschalter dazu führt dass die Automatik abgeschaltet wird und erst beim Hochfahren auf 0% (ganz offen) die Automatik wieder aktiviert wird.

Bin gespannt wie das Modul aufgebaut sein wird.  :)

LG,
Heiko


Hallo Heiko,
Sunset und Sunrise verwende ich auch, es gibt aber die Möglichkeit pro Rolladen zu sagen ob REAL,CIVIL oder was sunset und sunrise halt anbieten.
Wie gesagt die Abschattungslogik kommt als letztes.


Grüße
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: FunkOdyssey am 01 September 2018, 17:28:50
Ich begrüße eure Idee. Das fehlt uns echt und ist eigentlich ja auch recht elementar. Meine DOIF-Sammlung zu diesem Thema ist wahnsinnig komplex mit zig Abhängigkeiten. Ich wollte mir Bernds aktuelle Umsetzung sowieso schon immer anschauen. Jetzt warte ich aufs Modul.

Mein persönlich - aber leider sehr individueller - Wunsch:
Unterschiedliche Abschattung je nach Stärke der Sonneneinstrahlung bzw. sogar unter Berücksichtigung der Wettervorhersage. Warum soll ich eine Jalousie morgens hochfahren, wenn die Sonne sowieso gleich stark einstrahlt und die Außentemperaturen bereits > 30 Grad sind.

Dies wird sicherlich nicht oder nur sehr spät kommen. 😄
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: Prof. Dr. Peter Henning am 01 September 2018, 17:29:34
Zitathome,asleep,gotosleep und awoken

Hm - die Logik verstehe ich nicht. "Aufwecken" ist immer etwas, das automatisch zeitgesteuert ablaufen sollte (oder manuell, wenn der Wecker ausgeschaltet war). Das Herunterfahren der Rollläden ist viel komplizierter. In meinem TimeHelper für YAAHM habe ich das wie folgt realisiert:

"wakeup" => Fährt Rollläden hoch.
"night"     => Fährt Rollläden herunter, aber nur wenn a.) nicht durch Roll.block manuell blockiert UND b.) nicht im Party-Modus
"sleep"    => Manueller Event, hat mit Rollläden nur dann etwas zu tun, wenn diese beim "night"-Event wegen des Party-Modus nicht heruntergefahren wurden.

Klar ist, dass der Party-Modus nicht während des Absence-Modus eingeschaltet werden kann.

LG

pah

Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: Prof. Dr. Peter Henning am 01 September 2018, 17:31:28
@FunkOdyssey: YAAHM ansehen.

Betreffend die Wettervorhersage: Die ist niemals so genau, dass man daraus das lokale Wetter ablesen kann. Da helfen nur echte Messwerte.


LG

pah
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: CoolTux am 01 September 2018, 17:39:03
Zitat von: Prof. Dr. Peter Henning am 01 September 2018, 17:29:34
Hm - die Logik verstehe ich nicht. "Aufwecken" ist immer etwas, das automatisch zeitgesteuert ablaufen sollte (oder manuell, wenn der Wecker ausgeschaltet war). Das Herunterfahren der Rollläden ist viel komplizierter. In meinem TimeHelper für YAAHM habe ich das wie folgt realisiert:

"wakeup" => Fährt Rollläden hoch.
"night"     => Fährt Rollläden herunter, aber nur wenn a.) nicht durch Roll.block manuell blockiert UND b.) nicht im Party-Modus
"sleep"    => Manueller Event, hat mit Rollläden nur dann etwas zu tun, wenn diese beim "night"-Event wegen des Party-Modus nicht heruntergefahren wurden.

Klar ist, dass der Party-Modus nicht während des Absence-Modus eingeschaltet werden kann.

LG

pah

Das ganze ist noch viel flexibler gelöst.
Aber erst mal zu asleep und awoken und home und so. awoken gibt es bei mir zum Beispiel nur wenn mein Wecker gestellt ist. Am Wochenende geht es direkt von asleep zu home. Nur zur Erklärung.

Nun zum flexibleren. Die Roommate/Bewohner Sache ist pro Rolladen ein zu stellen. Es geht also um die Bewohner des jeweiligen Zimmers. Wenn meine Tochter bis 11 Uhr schlafen will soll bei Sonnenaufgang ihr Rollo nicht hochfahren. Wenn meine Freundin und ich aufstehen soll unser Rollo hochfahren. Alle anderen Rollos in Küche, Bad, Wohnzimmer können schon bei Sonnenaufgang hoch fahren.
So ist mein Gedanke.


Bin gerade dabei eine kurze Anleitung zu schreiben. Viel zu beachten gibt es ja noch nicht.
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: enno am 01 September 2018, 17:42:23
Moin zusammen,

klingt interessant.
ZitatWas solltet Ihr dazu haben? Rolläden, Fensterkontakte und Bewohnerstatus auf Basis von Residents/Roomates in englisch. Es können auch Dummys sein welche home,asleep,gotosleep und awoken setzen. Wichtig wäre noch ein Reading lastState. Aber sowas kann man schnell zaubern, ich helfe da gerne.

- Rolläden (Somfy)
- Fensterkontakte (1-Wire)
- Bewohnerstatus (noch nicht, schnell gemacht auf Basis Bewegungsmelder und diversen Lichtschaltern (alles Homematic))

Mache das zur Zeit mit DOIF, ASTRO,Dummys, wenn es mit eurem Modul eleganter geht dann schaue ich mir das mal an. Ich habe aber die Befürchtung dass das Produkt für mich als nicht Informatiker wieder zu komplex wird. An pahs YAAHM und Alarmanlage bin ich schon erfolgreich gescheitert.

Gruss
  Enno
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: Beta-User am 01 September 2018, 17:59:12
Zitat von: CoolTux am 01 September 2018, 17:17:29Wow, mit soviel Zuspruch hätte ich jetzt nicht gerechnet.
Warum nicht?

Brauchst die nur den Thread von cluni und den Vorgänger-Thread dazu anzusehen, dass weißt du, wie viele darauf gewartet haben ;D 8) ::) . (cluni mag zusätzlich schmunzeln, er dürfte sich noch an den eigentlichen Anlaß erinnern, da war uns beiden was zu kompliziert, wir haben es einfach nicht verstanden.... Jetzt programmieren wir halt Perl ;D ;D ;D ).

@enno und andere:
Nur Mut, cluni hat sehr viele "Normaluser" erfolgreich beim Einrichten unterstützt, das ist kein Hexenwerk (auch wenn ich selbst auch nicht sooo begeistert bin, dass scheinbar zwingend eine An- und Abwesenheitserkennung erforderlich sein soll. Aber notfalls mach ich mir dazu ein paar weekdaytimer oder einen separateren Kalender, dann wird das zwar wieder starr, aber evtl. hilft es auch zukünfitgen Neueinsteigern, erst mal eine Basis zu schaffen und dann erst Bewohner für Bewohner wirklich "zu verfolgen"...

Zitat von: CoolTux am 01 September 2018, 17:17:29So in etwa

Für den Fall, dass es jemand ohne weitere Zauberei mit raw-Import haben will ;) :
defmod rr_Maria dummy
attr rr_Mann readingList state
attr rr_Mann room Test
attr rr_Mann setList state:home,gotosleep,awoken,absent,asleep
attr rr_Mann userReadings lastState:(home|awoken|asleep|gotosleep|absent) { OldValue($name) }

Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: CoolTux am 01 September 2018, 17:59:50
Zitat von: enno am 01 September 2018, 17:42:23
Moin zusammen,

klingt interessant.
- Rolläden (Somfy)
- Fensterkontakte (1-Wire)
- Bewohnerstatus (noch nicht, schnell gemacht auf Basis Bewegungsmelder und diversen Lichtschaltern (alles Homematic))

Mache das zur Zeit mit DOIF, ASTRO,Dummys, wenn es mit eurem Modul eleganter geht dann schaue ich mir das mal an. Ich habe aber die Befürchtung dass das Produkt für mich als nicht Informatiker wieder zu komplex wird. An pahs YAAHM und Alarmanlage bin ich schon erfolgreich gescheitert.

Gruss
  Enno

Hallo Enno,

Na ich hoffe ja nicht das es zu komplex zum einrichten ist. Aber auch gerade das gilt es zu überprüfen. Ich bin bekannt dafür Anwenderfreundlich zu entwickeln. Siehe AMAD und den Installationsassistenten.
Und noch ist es klein und überschaubar.
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: CoolTux am 01 September 2018, 18:02:45
Zitat von: Beta-User am 01 September 2018, 17:59:12
@enno und andere:
Nur Mut, cluni hat sehr viele "Normaluser" erfolgreich beim Einrichten unterstützt, das ist kein Hexenwerk (auch wenn ich selbst auch nicht sooo begeistert bin, dass scheinbar zwingend eine An- und Abwesenheitserkennung erforderlich sein soll. Aber notfalls mach ich mir dazu ein paar weekdaytimer oder einen separateren Kalender, dann wird das zwar wieder starr, aber evtl. hilft es auch zukünfitgen Neueinsteigern, erst mal eine Basis zu schaffen und dann erst Bewohner für Bewohner wirklich "zu verfolgen"...

Es wird später keine Voraussetzung sein. Aber zum testen wäre es super.
Und ich denke mal so verkehrt ist das auch nicht. Warum soll in den Schlafräumen der Rolladen bei Sonnenaufgang fahren wenn dort noch geschlafen wird.
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: CoolTux am 01 September 2018, 18:21:04
ACHTUNG!!

Ich habe den ersten Post angepasst.
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: Prof. Dr. Peter Henning am 01 September 2018, 18:46:40
ZitatAber erst mal zu asleep und awoken und home und so. awoken gibt es bei mir zum Beispiel nur wenn mein Wecker gestellt ist. Am Wochenende geht es direkt von asleep zu home. Nur zur Erklärung.

Ist aber nicht ganz konsistent - denn "home" ist ein Zustand, "awoken" auch - aber der Übergang löst doch das Event aus. Beispielsweise wird bei mir auch das Teewasser aufgesetzt.

LG

pah
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: CoolTux am 01 September 2018, 18:53:37
Zitat von: Prof. Dr. Peter Henning am 01 September 2018, 18:46:40
Ist aber nicht ganz konsistent - denn "home" ist ein Zustand, "awoken" auch - aber der Übergang löst doch das Event aus. Beispielsweise wird bei mir auch das Teewasser aufgesetzt.

LG

pah

Ich denke das ist für jeden unterschiedlich. Bei mir wird schon beim Übergang von asleep zu awoken der Kaffee gekocht. Von awoken zu home brauche ich keinen Kaffee oder mache ihn später (Wochenende) zusammen mit einer Durchsage wie das Wetter ist, wird und wo Fenster auf sind.
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: Prof. Dr. Peter Henning am 01 September 2018, 19:25:05
Zitatawoken zu home

Oben hast du geschrieben, dass es am Wochenende direkt von asleep nach home wechselt. Das zeigt m.E., dass Eure Begriffe noch genauer definiert werden könnten  ;)

Wenn mein (FHEM-)Wecker ausgestellt ist, gibt es natürlich den Zustandsübergang zu "Morgen" - aber ohne dass die Aufwachaktionen durchgeführt werden. Das Event "Wakeup" kann (gerne auch später ...) einfach ausgelöst werden, indem man einem der Stimmenerkennungsdevices (3 Tablets und das Weckerdisplay auf einem festmontierten Handy) "Guten Morgen" wünscht. Vorher werden weder Rollläden, noch Teewasser in Bewegung gesetzt.

Genaue Definition der verschiedenen Typen von Übergängen hier: https://wiki.fhem.de/wiki/Modul_YAAHM#Tages-Profil.

Die Flexibilisierung ist gut. Geht bei YAAHM auch, indem für einen anderen Nutzer ein eigenes Wochenprofil angelegt wird. Das betrifft aber nicht die astronomischen Zeiten, sondern nur die manuellen Events.

LG

pah
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: Beta-User am 02 September 2018, 08:51:47
So, ersten Test gemacht, und gleich Anmerkungen und Wünsche:

- Mein Raw-Vorschlag war nicht durchgängig ;) : Entweder "Mann" oder "Maria", gemischt ist naja...
- zu chmod: Habe das Modul mit sudo+mcedit erstellt und dann - wie üblich - einfach user+gruppe angepaßt (chown fhem:dialout). Dann das define durchgeführt => Fehlermeldung, Modul angeblich nicht vorhanden. Reload veranlaßt => geht nicht... chmod wie vorgeschlagen durchgeführt => selbes Ergebnis... Erst nach einem Neustart wollte es.
Vorschlag: Hinweis, dass chown auf (idR.) fhem:dialout + Neustart erforderlich ist.

- das mit "auto" ist ja nett, aber meine Rolladen heißen zwar alle Roll.*, aber eben nicht die Jalousien :( . Habe noch nicht in den Code gesehen, aber evtl. wäre es ja möglich, zwei set-Varianten dazuzufügen: "set bla addShutter <devspec>" und das Gegenteil "removeShutter"?
Dann könnte man z.B. mit Filter auf alle passenden HM-Typen arbeiten. (Die Luxus-Variante wäre zum klicken wie bei der Raum-Auswahl).

Dann mach' ich jetzt mal weiter...

Gruß, Beta-User

Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: CoolTux am 02 September 2018, 09:04:00
Vielen Dank für's testen. Eigentlich sollte es auch ohne restart klappen. Schaue ich mir mal an. Eventuell liegt es an der Art wie ich das Modul aufgebaut habe. Ich arbeite das erste mal mit package Namen.


Wie fangen denn Deine Jalousien an mit Namen? Eventuell kann ich da was machen.
Auswahl per Checkbox ist eine gute Idee. Lege ich ganz unten auf die To-Do Liste.



Grüße
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: der-Lolo am 02 September 2018, 09:14:39
Guten Morgen Julian & Bernd,
mit begeisterung nehme ich wahr das hier ein neues Modul entsteht... Gerne würde ich das in Zukunft einsetzen - bei mir sind aber sicher noch einige "Grundvorraussetzungen" zu treffen. Welche Informationen werden von den jeweiligen Rollos benötigt? Zur Zeit habe ich nur eine simple Tasterschaltung realisiert - kurzer druck nach oben fährt obere Endlage an, kurzer Druck nach unten fährt untere endlage an. Langer druck bringt die Steuerung in Handbetrieb und öffnet oder schliest solange wie betätigt wird...
Denkbar ist hier auch eine rückmeldung der Position von meiner zentralen Steuerung aus.

Wäre also toll wenn Ihr darstellt welche informationen von den jeweiligen Rollo Devices genutzt und verarbeitet werden...

Danke!
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: CoolTux am 02 September 2018, 10:31:36
Zitat von: der-Lolo am 02 September 2018, 09:14:39
Guten Morgen Julian & Bernd,
mit begeisterung nehme ich wahr das hier ein neues Modul entsteht... Gerne würde ich das in Zukunft einsetzen - bei mir sind aber sicher noch einige "Grundvorraussetzungen" zu treffen. Welche Informationen werden von den jeweiligen Rollos benötigt? Zur Zeit habe ich nur eine simple Tasterschaltung realisiert - kurzer druck nach oben fährt obere Endlage an, kurzer Druck nach unten fährt untere endlage an. Langer druck bringt die Steuerung in Handbetrieb und öffnet oder schliest solange wie betätigt wird...
Denkbar ist hier auch eine rückmeldung der Position von meiner zentralen Steuerung aus.

Wäre also toll wenn Ihr darstellt welche informationen von den jeweiligen Rollo Devices genutzt und verarbeitet werden...

Danke!

Hallo,

Das Modul benötigt Devices worüber die Rollos gesteuert werden. Diese Devices müssen Befehl unterstützen über diesen Du in Prozent die Rollos fahren kannst. 0 oben 100 unten oder auch umgekehrt. Dieser Befehl muss auch 1 zu 1 als Reading vorhanden sein.

Beispiel:
set Rolloname position 80

Reading position 80

oder

set Rolloname pct 20

Reading pct 20

Wie im ersten Post geschrieben. Mehr ist nicht nötig.
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: Beta-User am 02 September 2018, 10:42:20
Was das "erste Mal" angeht: "Eigentlich" ist schon richtig, aber es hat halt nicht funktioniert...

Was die Jalousien angeht: Fangen alle mit "Jalou" an, alle passenden Devices kämen mit "list TYPE=CUL_HM:FILTER=subType=blindActuator". Warum macht ihr die Initialisierung bei "auto" nicht mit dem und weiteren TYPE-Filtern (ROLLO, somfy...), soweit das bisher unterstützt wird?

Was "unten" auf der Todo-Liste angeht: Manches geht hinterher schwer wieder zu ändern; evtl. wäre es eine Idee, die eingebundenen Devices in einer internen Liste zu speichern, das sollte dann aber evtl. gleich überall berücksichtigt werden (ohne in den code gesehen zu haben, kann auch sein, dass das nachträglich noch leicht geht). Aber was das aufhübschen angeht, bin ich voll bei dir...
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: CoolTux am 02 September 2018, 11:02:21
Zitat von: Beta-User am 02 September 2018, 10:42:20
Was das "erste Mal" angeht: "Eigentlich" ist schon richtig, aber es hat halt nicht funktioniert...

Was die Jalousien angeht: Fangen alle mit "Jalou" an, alle passenden Devices kämen mit "list TYPE=CUL_HM:FILTER=subType=blindActuator". Warum macht ihr die Initialisierung bei "auto" nicht mit dem und weiteren TYPE-Filtern (ROLLO, somfy...), soweit das bisher unterstützt wird?
Das ist mir viel zu speziell. Meine Rollo Devices haben zum Beispiel keines Deiner Filter. Vielleicht hat auch einer nur Dummys und steuert damit GPIOs an. Jalou baue ich gerne noch ein.
Man sieht ja in den Readings wunderbar welche Devices erwischt wurden. Sollten noch Feinheiten nötig sein so kann man das später ohne Probleme noch machen.

Zitat von: Beta-User am 02 September 2018, 10:42:20
Was "unten" auf der Todo-Liste angeht: Manches geht hinterher schwer wieder zu ändern; evtl. wäre es eine Idee, die eingebundenen Devices in einer internen Liste zu speichern, das sollte dann aber evtl. gleich überall berücksichtigt werden (ohne in den code gesehen zu haben, kann auch sein, dass das nachträglich noch leicht geht). Aber was das aufhübschen angeht, bin ich voll bei dir...

Es gibt eine interne ARRAY List aller Rollos. Wir haben versucht weitestgehend flexibel zu entwickeln.
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: Beta-User am 02 September 2018, 17:24:22
Zitat von: CoolTux am 02 September 2018, 11:02:21
Es gibt eine interne ARRAY List aller Rollos. Wir haben versucht weitestgehend flexibel zu entwickeln.
War naheliegend; wenn später alles über dieses Array läuft (im Sinne von foreach bei der Umsetzung irgendwelcher "erstelle Timer"-Aktionen usw.), ist es in der Tat egal, wie man zunächst mal auf die Array-Elemente kommt.

Zitat von: CoolTux am 02 September 2018, 11:02:21
Das ist mir viel zu speziell. Meine Rollo Devices haben zum Beispiel keines Deiner Filter. Vielleicht hat auch einer nur Dummys und steuert damit GPIOs an.
Was speziell ist, hängt individuell an der Installation;  jemand, der in USA, Frankreich, Polen oder Indien seine Devices benennt, findet evtl. "Roll.*" sehr speziell ;) . Eigentlich könnte man diverse Standard-Devspecs bei "auto" nacheinander durchloopen (was du ja vermutlich für die beiden bisherigen Vorgaben auch machst), und dann halt nur in das Array pushen, was nicht schon durch einen vorherigen Filter drin war. So eine Logik würde dann auch das Hinzufügen einzelner Devices ggf. vereinfachen (bzw. die "Reparatur", wenn jemand notwendige Atribute, Readings etc. an seinen shutter-Devices versehentlich gelöscht haben sollte.
Aber du hast recht: Das ist Kosmetik und ist ggf. auch nachträglich schnell gemacht ::) ...

EDIT:
(wieder gelöscht und in Folgebeitrag aufgenommen)
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: Beta-User am 02 September 2018, 17:34:01
Nachtrag:

Zwei Punkte noch:
- Der Thread-Titel ist nicht besonders aussagefähig; wie wäre es mit "Betatester für AutoShutterControl gesucht!"
- Ich hoffe, es ist geplant, diesen Dummy (Rolladendummy) asap abzuschaffen? Eigentlich sollte es ohne weiteres möglich sein, die ganzen Attribute usw. direkt am Modul-Device zu setzen (dafür scheint der Dummy ja da zu sein, oder?)
EDIT: Und soll die Diskussion zum Modul hier stattfinden, in einem separaten Thread oder auf Github?
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: CoolTux am 02 September 2018, 17:36:07
Zitat von: Beta-User am 02 September 2018, 17:34:01
Nachtrag:

Zwei Punkte noch:
- Der Thread-Titel ist nicht besonders aussagefähig; wie wäre es mit "Betatester für AutoShutterControl gesucht!"
- Ich hoffe, es ist geplant, diesen Dummy (Rolladendummy) asap abzuschaffen? Eigentlich sollte es ohne weiteres möglich sein, die ganzen Attribute usw. direkt am Modul-Device zu setzen (dafür scheint der Dummy ja da zu sein, oder?)

Du meinst jetzt sicherlich den Dummy für das 99_myUtils Skript oder? Sowas gibt es doch gar nicht mehr. Dafür ist doch das Device vom Modul da.
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: Beta-User am 02 September 2018, 17:53:57
Argh, dann ist das noch ein Rest von einem alten Versuch; kommt sofort weg!

Danke!

Anbei noch eine Textfile für das Erstellen einer kompletten Familie samt zweier "Muster-Nichtmitbewohner" - Gast1 und Service1, die für Leute stehen, die nur zu bestimmten Gegebenheiten erwartet werden (Putzfrau). Da gibt es ein zusätzliches set für "xpectedPresence", was so viel bedeuten soll wie: der Besuch ist ok/geplant/bekannt, wenn "1" und außerplanmäßig, wenn "0".


Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: CoolTux am 02 September 2018, 18:01:22
Zitat von: Beta-User am 02 September 2018, 17:53:57
Argh, dann ist das noch ein Rest von einem alten Versuch; kommt sofort weg!

Danke!

Anbei noch eine Textfile für das Erstellen einer kompletten Familie samt zweier "Muster-Nichtmitbewohner" - Gast1 und Service1, die für Leute stehen, die nur zu bestimmten Gegebenheiten erwartet werden (Putzfrau). Da gibt es ein zusätzliches set für "xpectedPresence", was so viel bedeuten soll wie: der Besuch ist ok/geplant/bekannt, wenn "1" und außerplanmäßig, wenn "0".

Konntest Du denn schon erfolgreich etwas testen?
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: Beta-User am 02 September 2018, 18:07:36
Bin noch am Einrichten...

Worüber ich jetzt als erstes gestolpert bin, ist die Vorbelegung der Attribute. Das ist für meine HM's verkehrt rum...

Ist das hier das Muster für die Lösung:
attr TYPE=CUL_HM:FILTER=subType=blindActuator AutoShuttersControl_Closed_Pos 0
Oder muß man irgendeine Option setzen, damit das Modul das invertiert?

Btw.: ich habe auch einen Rolladenaktor für meine Leinwand. Die sollte nach Möglichkeit also direkt rausgeworfen werden können, wenn man das Array über den (Sub-) TYPE erstellt ;) .
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: CoolTux am 02 September 2018, 18:13:31
Eigentlich sollten Vorbelegungen gegeben sein. Siehe ersten Post

AutoShuttersControl_Closed_Pos 100                  in 10 Schritten von 0 bis 100
    AutoShuttersControl_Ventilate_Pos 80      in 10 Schritten von 0 bis 100
    AutoShuttersControl_Open_Pos 0
    AutoShuttersControl_Pos_Cmd pct                     der set Befehl um den Rolladen in Prozent Angaben zu fahren.

Bei dir also closed auf 0 und Open auf 100 und ventilate auf 20 oder 30

Hast du von gestern Abend die Version gezogen?
Hätte noch Änderungen drin.
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: CoolTux am 02 September 2018, 18:14:59
Version 0.0.48 solltest Du bitte verwenden.
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: Beta-User am 02 September 2018, 18:36:19
Als Version wird 0.0.48 angezeigt, war heute morgen kurz nach 8, als ich das vom github geholt habe.

Die Vorbelegung an sich ist auch vorhanden, nur paßt die eben für HM-Aktoren nicht ;) - ein weiteres Argument, um "auto" vorrangig über den TYPE zu steuern. Dann können nämlich hardwarespezifische Standards besser berücksichtigt werden... (geht natürlich auch anders).

Habe jetzt folgende Vorgaben:

attr TYPE=CUL_HM:FILTER=subType=blindActuator AutoShuttersControl_Closed_Pos 0
attr TYPE=CUL_HM:FILTER=subType=blindActuator AutoShuttersControl_Open_Pos 100
attr TYPE=CUL_HM:FILTER=subType=blindActuator AutoShuttersControl_Ventilate_Pos 30
attr TYPE=CUL_HM:FILTER=subType=blindActuator AutoShuttersControl_Shading_Pos 55

Und dann noch für meine Drehgriffe:
attr TYPE=CUL_HM:FILTER=subType=blindActuator AutoShuttersControl_WindowRec_subType threeStateSensor
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: CoolTux am 02 September 2018, 18:40:02
Shading und Drehgriff Attribute werden noch nicht berücksichtigt. Der Rest ist aber korrekt so eingestellt.
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: CoolTux am 02 September 2018, 18:42:28
Mag sein das man über Type Hardware spezifische Standards besser berücksichtigen kann, aber dann programmieren wir uns dumm und dämlich und aus 20000 Zeilen werden 50000.
Genau dafür gibt es die Attribute pro Rolladen.
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: CoolTux am 02 September 2018, 18:54:24
Ich habe noch bisschen was in die Beschreibung im ersten Post geschrieben.
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: Beta-User am 02 September 2018, 20:07:20
Agreed, was die Vorgaben angeht, war ja auch recht einfach zu korrigieren.

Vielleicht wäre/wird es einfacher, wenn man das ganze zweistufig aufbaut: Erst das Basis-Device. Darin kann man dann die eigenen Defaults festlegen - meistens dürfte es ja reichen, wenn man die "Offen"-Position benennt. Dann erst die Devices hinzufügen. Häufig dürfte es ja so sein, dass dass in einer Installation einheitlich ist.

Ansonsten bin ich jetzt mal gespannt, wann meine diversen Rolläden zu- und wieder auf gehen....
Was das Zugehen angeht, war das gerade eben - gefühlt zu früh, da muß ich also dann gleich was umkonfigurieren. Wird aber dauern.

Habt ihr zufällig schon ein Muster für eine passende ReadingsGroup um die ganzen Zeiten usw. schön zentral einstellen zu können?

Danke jedenfalls nochmal bis dahin, vorbildlicher Support :) .

Schönen Abend noch,
Beta-User
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: CoolTux am 02 September 2018, 20:11:33
Zitat von: Beta-User am 02 September 2018, 20:07:20.

Habt ihr zufällig schon ein Muster für eine passende ReadingsGroup um die ganzen Zeiten usw. schön zentral einstellen zu können?

Danke jedenfalls nochmal bis dahin, vorbildlicher Support :) .

Schönen Abend noch,
Beta-User

Du bist zu schnell mein Lieber. Ein Schritt nach dem anderen. Aber wenn Du magst kannst Du eine zusammenstellen. Weiß nur gerade nicht was Du da alles einstellen willst. Die Attribute stellt man einmalig ein und dann sollte es gut sein. So die Idee.


Danke Dir
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: CoolTux am 02 September 2018, 23:01:53
Zitat von: Beta-User am 02 September 2018, 20:07:20
Was das Zugehen angeht, war das gerade eben - gefühlt zu früh, da muß ich also dann gleich was umkonfigurieren. Wird aber dauern.

Ich habe soeben noch dem HORIZON einen Wert für die Höhe über dem Horizont verpasst. Siehe ersten Post.
Desweiteren Beachtung der Attribute AutoShuttersControl_Mode_Down und AutoShuttersControl_Mode_Up



Grüße
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: Prof. Dr. Peter Henning am 03 September 2018, 07:54:25
ZitatWas speziell ist, hängt individuell an der Installation;  jemand, der in USA, Frankreich, Polen oder Indien seine Devices benennt, findet evtl. "Roll.*" sehr speziell

Warum nicht allen Rollläden, die gesteuert werden sollen, ein globales Attribut geben ? So habe ich das im Alarm-Modul ebenso wie bei Babble gelöst.

LG

pah
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: Beta-User am 03 September 2018, 08:12:41
Thx, meine Jalousien sind jetzt auch da, wenn auch wieder mit den "falschen" defaults :) !

Hatte dann auch gestern noch an der Automatik "CIVIL" eingestellt (so war das bei meiner bisherigen Steuerung auch, allerdings mit anderen Zeitgrenzen).

Rechte am Modul stehen seit eben auf 644 (wie bei allen anderen Modulen; das scheint auch zu reichen, jedenfalls ist das Device auch nach einem Neustart da ;) ).

Mit den Roommates und ihrer Steuerung muß ich mich erst noch etwas beschäftigen, wie gesagt, das war bisher nicht da, da müssen jetzt (ausnahmsweise) dummy-Devices herhalten, und die wollen ja auch ihren Status ändern ??? .

Kann man eigentlich mehrere Roommates pro Raum definieren bzw. hätte das Auswirkungen?

Was die RG angeht: Gemach, gemach... Mach' ich notfalls schon selbst ;) . Ziel sollte sein, damit die Geräte direkt bedienen und ggf. die hin und wieder veränderlichen Attribute und  Zeiten einstellen zu können. War nur die Frage, ob jemand da schon was hat. V.a. das mit den Zeiten wäre interessant, aber da gibt es auch Beispiele im Wiki und ggf. im "Urvater-Thread" von HugoMcKinnley. Muss mal suchen.

Aber keine Hektik, das ist eine Riesen-Sache und muß nicht in einer Woche stehen :) .

Zitat von: Prof. Dr. Peter Henning am 03 September 2018, 07:54:25
Warum nicht allen Rollläden, die gesteuert werden sollen, ein globales Attribut geben ?
Kann ich nicht beurteilen, aber an Attributen an den Rolläden mangel es nicht; das Array mit den Devicen steht ja auch im zentralen Gerät. Aber eine Möglichkeit, Rolladen-Devices einzeln dazu- bzw. herauszunehmen wäre m.E. nicht schlecht.
Nach meinem (subjektiven) Eindruck wird mit der "auto"-Angabe gleich beim "define" zu viel auf einmal verursacht. Das wird bei vielen Einsteigern ein Gefühl der Überforderung geben. Aber wie gesagt: Just my2ct.
Vielleicht komme ich dazu, mir den Code mal anzusehen, dann gibt es ggf. einen Vorschlag für "set ... addDevices" usw.. Die Routinen im Hintergrund scheinen ja vorhanden zu sein.

Gruß, Beta-User
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: CoolTux am 03 September 2018, 08:27:06
Guten Morgen


Zitat von: Beta-User am 03 September 2018, 08:12:41
Thx, meine Jalousien sind jetzt auch da, wenn auch wieder mit den "falschen" defaults :) !

Kannst Du mir das mit den "falschen" defaults versuchen Näher zu bringen? Sind sie für Dich falsch und ist der ganze default Unsinn? Meinst Du die Attribute für up und down fahrten? Also 0 und 100?
Darüber können wir gerne reden. Was denkst Du/Ihr welche Werte eher vertreten sind in der Anzahl. Hoch 0 und runter 100 oder umgekehrt. Wir können das gerne an passen.

Zitat von: Beta-User am 03 September 2018, 08:12:41
Kann man eigentlich mehrere Roommates pro Raum definieren bzw. hätte das Auswirkungen?

Aktuell noch nicht, wird aber kommen, war in der Planung einer der Voraussetzungen für mich, da ich 2 Kinder im selben Raum habe und natürlich das Schlafzimmer auch von 2 benutzt wird.


Zitat von: Beta-User am 03 September 2018, 08:12:41
Nach meinem (subjektiven) Eindruck wird mit der "auto"-Angabe gleich beim "define" zu viel auf einmal verursacht. Das wird bei vielen Einsteigern ein Gefühl der Überforderung geben. Aber wie gesagt: Just my2ct.

Oft sind es genau diese Just my2ct.welche gute Ideen ein bringen.
Kannst Du mir dieses "gefühlte zu viel" etwas genauer erklären? Zu viel zum einstellen?




Zitat von: Prof. Dr. Peter Henning am 03 September 2018, 07:54:25
Warum nicht allen Rollläden, die gesteuert werden sollen, ein globales Attribut geben ? So habe ich das im Alarm-Modul ebenso wie bei Babble gelöst.

LG

pah

Ich fand die Idee gut, für genau 20 Sekunden. Bis ich kurz nachgedacht habe und der Meinung war/bin das es egal ist ob ich ein globales Attribut an alle Rolläden verteile oder alle Rolläden zur Not in meiner define mit angebe. Der Aufwand wird wohl identisch sein. Was denkt Ihr?
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: DS_Starter am 03 September 2018, 08:42:36
ZitatBis ich kurz nachgedacht habe und der Meinung war/bin das es egal ist ob ich ein globales Attribut an alle Rolläden verteile oder alle Rolläden zur Not in meiner define mit angebe. Der Aufwand wird wohl identisch sein. Was denkt Ihr?

Die Attribut-Lösung halte ich für besser. Weniger wegen des Aufwands, sondern wegen der Flexibilität.
Idee - hat man ein Attribut (ich habe bei mir sogar ein Reading "Rollo_Automatic" verwendet), kann man es z.B. durch programmtechnische Maßnahmen "von außen", z.B. durch Schalter mit notifies oder MyUtils-Routinen usw. in den Automatic/Manuell-Mode schalten. Ich mache das z.B. mit einem Command-Icon in der Readingsgroup für die Rollos.

LG
Heiko
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: CoolTux am 03 September 2018, 08:53:53
Zitat von: DS_Starter am 03 September 2018, 08:42:36
Die Attribut-Lösung halte ich für besser. Weniger wegen des Aufwands, sondern wegen der Flexibilität.
Idee - hat man ein Attribut (ich habe bei mir sogar ein Reading "Rollo_Automatic" verwendet), kann man es z.B. durch programmtechnische Maßnahmen "von außen", z.B. durch Schalter mit notifies oder MyUtils-Routinen usw. in den Automatic/Manuell-Mode schalten. Ich mache das z.B. mit einem Command-Icon in der Readingsgroup für die Rollos.

LG
Heiko

Bitte nicht vergessen, es geht hier in erster Linie um das finden aller relevanten Rolladen Devices beim define einer Modulinstanz.


ansonsten!
Mann sollte also mal drüber nachdenken ob man
Zitat von: CoolTux am 02 September 2018, 23:01:53
Desweiteren Beachtung der Attribute AutoShuttersControl_Mode_Down und AutoShuttersControl_Mode_Up
nicht lieber als Reading pro Rollo macht? Das Reading müsste aber wenn dann im Modul Device stehen, für Jedes einzelne Rollo. Ich will nicht mehr wie nötig in fremde Devices schreiben.
Idee finde ich erstmal nicht verkehrt.
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: DS_Starter am 03 September 2018, 09:32:21
ZitatBitte nicht vergessen, es geht hier in erster Linie um das finden aller relevanten Rolladen Devices beim define einer Modulinstanz.

Achso.... wenn es darum geht schlage ich im auto-define die Verwendung von devspec mit einem Filter auf den TYPE bzw. bei HM auf den Subtype vor. So mache ich es bei mir (habe allerdings nur HM) und dadurch ist automatisch jedes neu definierte Device mit den Filterkriterien mit in der Steuerung, es sei denn man schaltet es in den manuellen mode wie vorhin geschrieben.

Lg
Heiko
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: CoolTux am 03 September 2018, 09:56:50
Zitat von: DS_Starter am 03 September 2018, 09:32:21
Achso.... wenn es darum geht schlage ich im auto-define die Verwendung von devspec mit einem Filter auf den TYPE bzw. bei HM auf den Subtype vor. So mache ich es bei mir (habe allerdings nur HM) und dadurch ist automatisch jedes neu definierte Device mit den Filterkriterien mit in der Steuerung, es sei denn man schaltet es in den manuellen mode wie vorhin geschrieben.

Lg
Heiko

Siehe dazu.
Zitat von: CoolTux am 02 September 2018, 11:02:21
Das ist mir viel zu speziell. Meine Rollo Devices haben zum Beispiel keines Deiner Filter (weder Type noch Subtype). Vielleicht hat auch einer nur Dummys und steuert damit GPIOs an. Jalou baue ich gerne noch ein.
Man sieht ja in den Readings wunderbar welche Devices erwischt wurden. Sollten noch Feinheiten nötig sein so kann man das später ohne Probleme noch machen.

Es gibt eine interne ARRAY List aller Rollos. Wir haben versucht weitestgehend flexibel zu entwickeln.
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: FunkOdyssey am 03 September 2018, 10:08:21
Ich hoffe, dass ich das hier alles richtig verstanden habe.
Es geht einmal um die individuelle Konfiguration der Jalousien in deren Attributen.
Und weiterhin um das Finden der Jalousien in FHEM, oder?

Kann man dann nicht per devspec einfach nach den Jalousien suchen?
Also sobald ein Attribut namens AutoShuttersControl.* gesetzt ist, dann ist es ein zu steuerndes Device?
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: Beta-User am 03 September 2018, 10:16:26
Zitat von: CoolTux am 03 September 2018, 08:27:06
Kannst Du mir das mit den "falschen" defaults versuchen Näher zu bringen?
Es dürfte auch mit den Vorgaben, die das Modul derzeit macht funktionieren, allerdings eben "levelInverse", also morgens gingen die Rolläden zu, abends auf ;D .
Wie bereits geschrieben, kann man das wie folgt drehen:
attr TYPE=CUL_HM:FILTER=subType=blindActuator AutoShuttersControl_Closed_Pos 0
attr TYPE=CUL_HM:FILTER=subType=blindActuator AutoShuttersControl_Open_Pos 100
Dasselbe gilt für die Shading-Position usw.. Ob insgesamt ein Drehen der defaults die Lösung ist? Ich fände es nach wie vor besser, wenn man die Presets vorab auswählen könnte, dann muß man nicht nacharbeiten.

Ergänzend eine Frage. Wenn ihr (für was auch immer) mal wissen wollt, ob eine aktuelle Position z.B. offener oder geschlossener ist als ein neues "Soll": Woher weiß das die Steuerung? (Früher gab es zu diesem Zweck (vermutlich) das Attribut LevelInverse.)

Zitat von: CoolTux am 03 September 2018, 08:27:06
Aktuell noch nicht, wird aber kommen, war in der Planung einer der Voraussetzungen für mich, da ich 2 Kinder im selben Raum habe und natürlich das Schlafzimmer auch von 2 benutzt wird.
Kein Ding, dann gibt es eben (ggf. übergangsweise) eine structrure.

Zitat
Kannst Du mir dieses "gefühlte zu viel" etwas genauer erklären? Zu viel zum einstellen?
Also mal "Otto Normaluser" als gedanklicher Ausgangspunkt. Der versucht erfahrungsgemäß, es sich erst mal einfach zu machen. "auto" klingt so, als wäre damit die meiste Arbeit schnell zu erledigen.
Gedacht, getan. Dann muß ich in meiner Installation "ganz schnell" >10 Rolläden konfigurieren, dabei eine ganze Anzahl von Parametern richtig setzen (mind. 6 pro Rolladen, oder?) und diverse Abhängigkeiten beachten, deren Auswirkungen ich noch nicht kenne.
Klar, man kann das umgehen, indem man das define nach und nach erweitert, aber die Vermutung liegt nahe, dass das in der Regel eben nicht so gemacht werden wird.

Zitat von: CoolTux am 03 September 2018, 08:53:53Bitte nicht vergessen, es geht hier in erster Linie um das finden aller relevanten Rolladen Devices beim define einer Modulinstanz.
Genau diesen Ansatz würde ich aus diesem Grund auch (nochmal) in Frage stellen: Wieso muß das über das "define" laufen?

Stelle daher nochmal folgenden Ablauf aus Usersicht zur Diskussion:
1. Zunächst definiert man das Steuerungsdevice _ohne_ irgendwelche Rolläden zu benennen, die gesteuert werden sollen:define Rolladensteuerung AutoShuttersControl

2. Dann stellt man defaults für diverse Dinge ein, sofern gewünscht.
3. Dann erweitert "Normaluser" die Steuerung, indem er einzelne oder mehrere Rolladendevices mit sowas in der Art hier set <AutoShutterControl> addShutter <Shuttername> [<Fensterkontakt>] [<ClosedPosition:0,100>] hinzufügt. Dann kann das Modul gleich sinnvolle Presets für die diversen Positionen ableiten und kennt auch die logische Fahrtrichtung.
Der User kann Raum für Raum vorgehen und sich erst mal mit einem oder zwei Rolläden einarbeiten, ohne erst durch "auto" in die falsche Richtung geschickt worden zu sein...

(4. Nach updates wäre ggf. zu prüfen, ob alle Devices auch alle Attribute haben => "set ... updateCheck")
(5. Die umgekehrte Richtung für Devices, die - aus welchen Gründen auch immer - nicht mehr gesteuert werden sollen würde dann auch benötigt. Anektdote dazu: Mein versehentlich noch vorhandener Rolladendummy war im Array gespeichert; ob er durch einen simplen Neustart wieder verschwunden wäre: keine Ahnung).

ZitatMan sollte also mal drüber nachdenken ob man [...] Beachtung der Attribute AutoShuttersControl_Mode_Down und AutoShuttersControl_Mode_Up nicht lieber als Reading pro Rollo macht
Fände ich eigentlich auch - jedenfalls auf den ersten Blick - ganz gut; allerdings sind die Rolladendevices jetzt schon unübersichtlich.

Zitat von: DS_Starter am 03 September 2018, 09:32:21
Achso.... wenn es darum geht schlage ich im auto-define die Verwendung von devspec mit einem Filter auf den TYPE bzw. bei HM auf den Subtype vor. So mache ich es bei mir (habe allerdings nur HM) und dadurch ist automatisch jedes neu definierte Device mit den Filterkriterien mit in der Steuerung, es sei denn man schaltet es in den manuellen mode wie vorhin geschrieben.
So dachte ich auch erst, aber ich habe wie gesagt auch meine Leinwand an so einem Aktor. Den jedes Mal wieder rauszuwerfen, wenn FHEM gestartet wird, ist mühsam. Das einmalig zu machen, nachdem man mit "addDevice" die Devspec verwendet hat, ist dagegen easy...

Und wie gesagt: Nur mein Eindruck...

EIDT: Formatierung.
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: CoolTux am 03 September 2018, 10:40:55
Ich war schon dran mit Subtype und Type zu arbeiten bis Du das mit dem Leinwandmotor geschrieben hast. Ist also wieder ein Argument dagegen.

Deine Argumente bezüglich über Set den Rolladen hinzu zu fügen und dann auch die Vorgaben für Attribute im Modul Device zu machen sind einleuchtend und gut. ABER! Es ist ein großer Aufwand für den Entwickler.
Was ich aber gut finde und womit ich leben könnte ist, ein globales Attribut AutoShuttersControl mit Wert 1 welcher nach dem anlegen des Moduldevices und vor dem set autoScanShutters an alle Rolläden eingestellt werden muss.
Was sagt Ihr dazu?

Dennoch wird es für den User Pflicht sein jeden Rolladen noch mal an zu fassen um die für ihn passenden Attribute mit korrekten Werten zu setzen. Das kann man ja in einem Reading im Moduldevice noch mal explizit mit geben und auch vom User bestätigen lassen, sonst läuft gar nichts.


Von einem Smart Home Kollegen habe ich auch geade eine super tolle Logikidee bekommen
Zitat
Self Defence, wenn beim Verlassen des letzten Bewohners noch ein Fenster gekippt ist, wird der Rolladen an diesem Fenster automatisch geschlossen.
Ich finde das ist eine super tolle Idee.
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: Beta-User am 03 September 2018, 10:58:47
Zitat von: CoolTux am 03 September 2018, 10:40:55
ABER! Es ist ein großer Aufwand für den Entwickler.
Zitat von: Beta-User am 03 September 2018, 08:12:41Vielleicht komme ich dazu, mir den Code mal anzusehen, dann gibt es ggf. einen Vorschlag für "set ... addDevices" usw.. Die Routinen im Hintergrund scheinen ja vorhanden zu sein.
Auch wenn meine Perl-Kenntnisse nicht besonders sind: Du mußt ggf. nicht alles alleine machen; Und: es gibt sicher noch andere, die sich gerne einbringen, die das besser können als ich. In dem Zusammenhang finde ich es nur wichtig, dass man sich über das Ziel einig ist und jetzt nichts baut, was den Umbau noch komlexer macht...
ZitatWas ich aber gut finde und womit ich leben könnte ist, ein globales Attribut AutoShuttersControl mit Wert 1 welcher nach dem anlegen des Moduldevices und vor dem set autoScanShutters an alle Rolläden eingestellt werden muss.
Was sagt Ihr dazu?
Wäre auch eine Lösung für das Problem. Wie wäre es mit Werten 0,1,2? Dann könnte man über die weitere Unterscheidung 1-2 gleich die Defaults definieren, also (1 => pct 100=closed), (2 => pct 0=closed) und könnte das nachfolgend im Bedarfsfall auch verwenden, um die richtige Vergleichsrichtung zu haben (siehe mein letzter Post).

Ergo meine 2ct: sehr guter Kompromiss!

[Wunschmodus ein]Super wäre eine Art Assistent/Dialogbox, in dem man gleich alle passenden Optionen pro Device durchgehen könnte....
[Wunschmodus aus]
Zitat von: CoolTux am 03 September 2018, 10:40:55
Von einem Smart Home Kollegen habe ich auch geade eine super tolle Logikidee bekommen
Finde ich als Option nicht schlecht, einzustellen im Zentalen Device.
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: CoolTux am 03 September 2018, 13:04:19
Zitat von: Beta-User am 03 September 2018, 10:58:47
Auch wenn meine Perl-Kenntnisse nicht besonders sind: Du mußt ggf. nicht alles alleine machen; Und: es gibt sicher noch andere, die sich gerne einbringen, die das besser können als ich. In dem Zusammenhang finde ich es nur wichtig, dass man sich über das Ziel einig ist und jetzt nichts baut, was den Umbau noch komlexer macht...Wäre auch eine Lösung für das Problem. Wie wäre es mit Werten 0,1,2? Dann könnte man über die weitere Unterscheidung 1-2 gleich die Defaults definieren, also (1 => pct 100=closed), (2 => pct 0=closed) und könnte das nachfolgend im Bedarfsfall auch verwenden, um die richtige Vergleichsrichtung zu haben (siehe mein letzter Post).

Ergo meine 2ct: sehr guter Kompromiss!

[Wunschmodus ein]Super wäre eine Art Assistent/Dialogbox, in dem man gleich alle passenden Optionen pro Device durchgehen könnte....
[Wunschmodus aus]Finde ich als Option nicht schlecht, einzustellen im Zentalen Device.

Das mit dem Attribut default Values auf Basis des erkannten Rolladen verteilen ist leider nicht ganz so trivial wenn man nicht doppelt programmieren will. habe da aber eine kleine Idee die ich später mal verfolgen werde.
Die Tage werde ich erstmal die Logik beim anlegen ändern.
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: Beta-User am 03 September 2018, 13:36:26
Eventuell könnte es helfen, hinten in die Zuweisung ein Array zu schreiben, damit wären zwei oder mehr Werte möglich und man müßte nur den Index zutreffend auswählen.
Aber soooo dramatisch wichtig ist es nicht (mehr) die Änderung weg von den defaults durchzuführen, wenn man die Rolläden nacheinander per Attribut dazunehmen kann... Der Punkt ist m.E. ungleich wichtiger.

Danke!
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: CoolTux am 03 September 2018, 19:39:14
Zitat von: Beta-User am 03 September 2018, 13:36:26
Eventuell könnte es helfen, hinten in die Zuweisung ein Array zu schreiben, damit wären zwei oder mehr Werte möglich und man müßte nur den Index zutreffend auswählen.
Aber soooo dramatisch wichtig ist es nicht (mehr) die Änderung weg von den defaults durchzuführen, wenn man die Rolläden nacheinander per Attribut dazunehmen kann... Der Punkt ist m.E. ungleich wichtiger.

Danke!

Manchmal fehlen einfach nur Ideen. Danke. Das schaue ich mir genauer an.


Ich habe soeben den Umbau abschließen können, hat etwas gedauert. Aber nun wird nach dem define der state entsprechend gesetzt mit dem Hinweis ein set Befehl auszuführen nachdem in allen Rolläden das Attribut AutoShuttersControl auf 1 gesetzt wurde.
Das mit 2 machen wir dann später.



Grüße
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: Prof. Dr. Peter Henning am 03 September 2018, 21:41:38
Lustig wäre aus meiner Sicht ein Modell für das Mapping auf den tatsächlichen Stand des Rollladen. Auf welchen (fiktiven) Prozentwert muss man den Rollladenaktor stellen, um den Rollladen tatsächlich auf 50% zu bekommen ? Ich habe ein solches Modell für meine motorisierte TV-Wandhalterung geschrieben - ist auf +/- 3% genau im Bereich zwischen 0° und 90°.

Außerdem hier noch eine Idee:

Rollladen ist oben, aber Haus ist im Zustand gesichert. Bewegungsmelder registriert Bewegung vor dem Rollladen => Rollladen wird 10% herunter gefahren. Wenn danach für 10 Minuten keine Bewegung mehr, wird der Rollladen wieder hoch gefahren. Wenn die Bewegung nicht aufhört, wird der Rollladen ganz herunter gefahren und eine Warnungsmeldung abgesetzt. Ich bin gerade dabei, solche Bedingungen in das Alarm-Modul einzubauen - es ist sinnvoller, diese Alarmfunktionalität nicht auch noch in das Rollladenmodul einzubauen. Nützlich wäre aber eine Funktion, die einen Rollladenfür eine definierte Zeit um ein Stück weiter herunter fährt.

LG

pah
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: CoolTux am 03 September 2018, 22:14:55
Fertig!

Das Modul ist nun komplett auf das neue Define-Konzept angepasst. Ausserdem wird nun für das Attribut AutoShutterControl die Werte 0,1,2 angegeben.
1 = 0% oben und 100% unten, Pos_Cmd position
2 = 100% oben und 0% unten, Pos_Cmd pct

Es wird dafür ein aktuelles FHEM Update von morgen früh benötigt da ich ein Patch bei Rudi eingereicht habe.
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: Beta-User am 03 September 2018, 22:42:16
WOW!

Das geht ja voran! Herzlichen Dank!

kurze Rückmeldung: Mit CIVIL war die SchließZeit heute auch ganz ok :) .

Hier hätte ich auch einen ersten Wurf für zwei ReadingsGroups anzubieten (RAW-Import), mit denen sich die diversen Level und Zeiten ziemlich userfreundlich einstellen lassen würden, kann man auch recht leicht auf weitere Attribute erweitern.

Allerdings ist die für die Zeiten im Moment noch auf HH:MM-Format; kann das Modul damit umgehen? Die RG kann man auch ändern, das wäre kein Problem (dto. für 5-er-Schritte usw.). "Userfreundlicher" fände ich es aber, wenn man das bei den Zeiten ohne Sekunden machen könnte ;) .

defmod rg_ASC_Rollaeden_Level readingsGroup <Gerät>,<Closed_Pos>,<Open_Pos>,<Shading_Pos>,<Ventilate_Pos> (Rolladen_.*|Jalousie_.*)..:?AutoShuttersControl_Closed_Pos,?AutoShuttersControl_Open_Pos,?AutoShuttersControl_Shading_Pos,?AutoShuttersControl_Ventilate_Pos
attr rg_ASC_Rollaeden_Level commands { AutoShuttersControl_Closed_Pos => 'AutoShuttersControl_Closed_Pos:0,10,20,30,40,50,60,70,80,90,100',AutoShuttersControl_Open_Pos => 'AutoShuttersControl_Open_Pos:0,10,20,30,40,50,60,70,80,90,100',AutoShuttersControl_Shading_Pos => 'AutoShuttersControl_Shading_Pos:0,10,20,30,40,50,60,70,80,90,100',AutoShuttersControl_Ventilate_Pos => 'AutoShuttersControl_Ventilate_Pos:0,10,20,30,40,50,60,70,80,90,100'}


defmod rg_ASC_Rollaeden_Times readingsGroup <Gerät>,<Stand>,<Time_Up_Early>,<Time_Up_Late>,<Time_Down_Early>,<Time_Down_Late>,<Mode_Down>,<Mode_Up> (Rolladen_.*|Jalousie_.*)..:level,?AutoShuttersControl_Time_Up_Early,?AutoShuttersControl_Time_Up_Late,?AutoShuttersControl_Time_Down_Early,?AutoShuttersControl_Time_Down_Late,?AutoShuttersControl_Mode_Down,?AutoShuttersControl_Mode_Up
attr rg_ASC_Rollaeden_Times commands {level => 'pct:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100', \
AutoShuttersControl_Mode_Down => 'AutoShuttersControl_Mode_Down:always,absent,off',\
AutoShuttersControl_Mode_Up => 'AutoShuttersControl_Mode_Up:always,absent,off',\
AutoShuttersControl_Time_Down_Early => 'AutoShuttersControl_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', \
AutoShuttersControl_Time_Down_Late  => 'AutoShuttersControl_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',\
AutoShuttersControl_Time_Up_Early => 'AutoShuttersControl_Time_Up_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', \
AutoShuttersControl_Time_Up_Late =>'AutoShuttersControl_Time_Up_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'}


Bildchen von der Level-Einstellerei:

Und nochmal: Wäre es nicht an der Zeit, den Thread-Titel zu ändern? Ist im Moment inhaltlich nicht so vielsagend...
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: CoolTux am 04 September 2018, 09:19:14
Zitat von: Beta-User am 03 September 2018, 22:42:16
WOW!

Das geht ja voran! Herzlichen Dank!

kurze Rückmeldung: Mit CIVIL war die SchließZeit heute auch ganz ok :) .

Hier hätte ich auch einen ersten Wurf für zwei ReadingsGroups anzubieten (RAW-Import), mit denen sich die diversen Level und Zeiten ziemlich userfreundlich einstellen lassen würden, kann man auch recht leicht auf weitere Attribute erweitern.

Allerdings ist die für die Zeiten im Moment noch auf HH:MM-Format; kann das Modul damit umgehen? Die RG kann man auch ändern, das wäre kein Problem (dto. für 5-er-Schritte usw.). "Userfreundlicher" fände ich es aber, wenn man das bei den Zeiten ohne Sekunden machen könnte ;) .

defmod rg_ASC_Rollaeden_Level readingsGroup <Gerät>,<Closed_Pos>,<Open_Pos>,<Shading_Pos>,<Ventilate_Pos> (Rolladen_.*|Jalousie_.*)..:?AutoShuttersControl_Closed_Pos,?AutoShuttersControl_Open_Pos,?AutoShuttersControl_Shading_Pos,?AutoShuttersControl_Ventilate_Pos
attr rg_ASC_Rollaeden_Level commands { AutoShuttersControl_Closed_Pos => 'AutoShuttersControl_Closed_Pos:0,10,20,30,40,50,60,70,80,90,100',AutoShuttersControl_Open_Pos => 'AutoShuttersControl_Open_Pos:0,10,20,30,40,50,60,70,80,90,100',AutoShuttersControl_Shading_Pos => 'AutoShuttersControl_Shading_Pos:0,10,20,30,40,50,60,70,80,90,100',AutoShuttersControl_Ventilate_Pos => 'AutoShuttersControl_Ventilate_Pos:0,10,20,30,40,50,60,70,80,90,100'}


defmod rg_ASC_Rollaeden_Times readingsGroup <Gerät>,<Stand>,<Time_Up_Early>,<Time_Up_Late>,<Time_Down_Early>,<Time_Down_Late>,<Mode_Down>,<Mode_Up> (Rolladen_.*|Jalousie_.*)..:level,?AutoShuttersControl_Time_Up_Early,?AutoShuttersControl_Time_Up_Late,?AutoShuttersControl_Time_Down_Early,?AutoShuttersControl_Time_Down_Late,?AutoShuttersControl_Mode_Down,?AutoShuttersControl_Mode_Up
attr rg_ASC_Rollaeden_Times commands {level => 'pct:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100', \
AutoShuttersControl_Mode_Down => 'AutoShuttersControl_Mode_Down:always,absent,off',\
AutoShuttersControl_Mode_Up => 'AutoShuttersControl_Mode_Up:always,absent,off',\
AutoShuttersControl_Time_Down_Early => 'AutoShuttersControl_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', \
AutoShuttersControl_Time_Down_Late  => 'AutoShuttersControl_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',\
AutoShuttersControl_Time_Up_Early => 'AutoShuttersControl_Time_Up_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', \
AutoShuttersControl_Time_Up_Late =>'AutoShuttersControl_Time_Up_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'}


Bildchen von der Level-Einstellerei:

Und nochmal: Wäre es nicht an der Zeit, den Thread-Titel zu ändern? Ist im Moment inhaltlich nicht so vielsagend...

Super. Danke Dir

Ich habe nun eine neue Version ins Git geladen. Bitte beachtet den ersten Post dieses Threads. Version 0.1.1
Es wurde schon so einiges implementiert. Als nächstes mache ich mich an den Partymodus. Dadurch das wir sehr modular aufgebaut haben sind das nur 3 Zeilen zusätzlicher Code. Soviel zur Theorie  ;D


Grüße
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: HoTi am 04 September 2018, 11:40:22
Hallo CoolTux,

Ich bin zwar als Tester ausgeschlossen ;-) da ich den Code von Cluni benutze, habe aber trotzdem eine Frage:

Denkt ihr bei dem Modul an das Rollomodul? Wenn da dann Änderung nötig sind muss ich schauen ob ich das kann, oder jemanden fragen.

Viele Grüße
Tim

Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: CoolTux am 04 September 2018, 11:53:24
Zitat von: HoTi am 04 September 2018, 11:40:22
Hallo CoolTux,

Ich bin zwar als Tester ausgeschlossen ;-) da ich den Code von Cluni benutze, habe aber trotzdem eine Frage:

Denkt ihr bei dem Modul an das Rollomodul? Wenn da dann Änderung nötig sind muss ich schauen ob ich das kann, oder jemanden fragen.

Viele Grüße
Tim

Hallo Tim,
Das sollte eigentlich nicht nötig sein. Das Rollomodul muss lediglich einen set Befehl haben wo man in Prozent angeben kann wie weit das Rollo fahren soll. Ausserdem muß es ein Reading geben welches gleich lautet wie der set Befehl und die Prozentangabe und damit die Position des Rollos wieder gibt.
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: FunkOdyssey am 04 September 2018, 11:53:58
Eine kleine Sammlung:




Dein Quote im ersten Post ist nicht vollständig. Es fehlt die richtige Define-Zeile:

define Rolladensteuerung AutoShuttersControl




Kleiner Typo in L212: https://github.com/LeonGaultier/fhem-AutoShuttersControl/blob/devel/73_AutoShuttersControl.pm#L212
Sollte "controlled" heißen.




a) Warum sind die Attribute mal groß- und mal kleingeschrieben? AutoShuttersControl vs. autoShutterControl.*
b) Warum mal mit Präfix "auto" und mal ohne "brightnessMinVal"?




Sind die Readings korrekt? Die Räume-Readings sehen irgendwie merkwürdig aus?

   READINGS:
     2018-09-04 11:47:31   room_Homekit,Jalousien jal_buegeln
     2018-09-04 11:47:31   state           active
     2018-09-04 11:47:31   userAttrList    rolled out






Errors:

2018.09.04 11:47:31.862 3: Please define Homekit first
2018.09.04 11:47:31.864 3: Please define Homekit first
2018.09.04 11:47:34.865 1: ERROR: empty name in readingsBeginUpdate
2018.09.04 11:47:34.865 1: stacktrace:
2018.09.04 11:47:34.865 1:     main::readingsBeginUpdate           called by ./FHEM/73_AutoShuttersControl.pm (651)
2018.09.04 11:47:34.865 1:     AutoShuttersControl::CreateSunRiseSetShuttersTimer called by ./FHEM/73_AutoShuttersControl.pm (676)
2018.09.04 11:47:34.865 1:     AutoShuttersControl::RenewSunRiseSetShuttersTimer called by /opt/fhem/fhem.pl (3134)
2018.09.04 11:47:34.865 1:     main::HandleTimeout                 called by /opt/fhem/fhem.pl (649)
2018.09.04 11:47:34.866 1: PERL WARNING: Use of uninitialized value $name in concatenation (.) or string at /opt/fhem/fhem.pl line 4597.
2018.09.04 11:47:34.866 1: readingsUpdate(,AutoShuttersControl_Time_Sunset,20:08:28) missed to call readingsBeginUpdate first.
2018.09.04 11:47:34.866 1: stacktrace:
2018.09.04 11:47:34.866 1:     main::readingsBulkUpdate            called by ./FHEM/73_AutoShuttersControl.pm (653)
2018.09.04 11:47:34.866 1:     AutoShuttersControl::CreateSunRiseSetShuttersTimer called by ./FHEM/73_AutoShuttersControl.pm (676)
2018.09.04 11:47:34.866 1:     AutoShuttersControl::RenewSunRiseSetShuttersTimer called by /opt/fhem/fhem.pl (3134)
2018.09.04 11:47:34.866 1:     main::HandleTimeout                 called by /opt/fhem/fhem.pl (649)
2018.09.04 11:47:34.867 1: readingsUpdate(,AutoShuttersControl_Time_Sunrise,06:52:44) missed to call readingsBeginUpdate first.
2018.09.04 11:47:34.867 1: stacktrace:
2018.09.04 11:47:34.867 1:     main::readingsBulkUpdate            called by ./FHEM/73_AutoShuttersControl.pm (654)
2018.09.04 11:47:34.867 1:     AutoShuttersControl::CreateSunRiseSetShuttersTimer called by ./FHEM/73_AutoShuttersControl.pm (676)
2018.09.04 11:47:34.867 1:     AutoShuttersControl::RenewSunRiseSetShuttersTimer called by /opt/fhem/fhem.pl (3134)
2018.09.04 11:47:34.867 1:     main::HandleTimeout                 called by /opt/fhem/fhem.pl (649)
2018.09.04 11:47:34.867 1: PERL WARNING: Use of uninitialized value $d in hash element at /opt/fhem/fhem.pl line 4357.
2018.09.04 11:47:34.867 1: ERROR: empty name in readingsBeginUpdate
2018.09.04 11:47:34.867 1: stacktrace:
2018.09.04 11:47:34.867 1:     main::readingsBeginUpdate           called by /opt/fhem/fhem.pl (4742)
2018.09.04 11:47:34.867 1:     main::readingsSingleUpdate          called by ./FHEM/73_AutoShuttersControl.pm (664)
2018.09.04 11:47:34.867 1:     AutoShuttersControl::CreateSunRiseSetShuttersTimer called by ./FHEM/73_AutoShuttersControl.pm (676)
2018.09.04 11:47:34.867 1:     AutoShuttersControl::RenewSunRiseSetShuttersTimer called by /opt/fhem/fhem.pl (3134)
2018.09.04 11:47:34.867 1:     main::HandleTimeout                 called by /opt/fhem/fhem.pl (649)
2018.09.04 11:47:34.867 1: readingsUpdate(,.AutoShuttersControl_InternalTimerFuncHash,HASH(0x56076d7bb8a0)) missed to call readingsBeginUpdate first.
2018.09.04 11:47:34.867 1: stacktrace:
2018.09.04 11:47:34.867 1:     main::readingsBulkUpdate            called by /opt/fhem/fhem.pl (4743)
2018.09.04 11:47:34.867 1:     main::readingsSingleUpdate          called by ./FHEM/73_AutoShuttersControl.pm (664)
2018.09.04 11:47:34.867 1:     AutoShuttersControl::CreateSunRiseSetShuttersTimer called by ./FHEM/73_AutoShuttersControl.pm (676)
2018.09.04 11:47:34.867 1:     AutoShuttersControl::RenewSunRiseSetShuttersTimer called by /opt/fhem/fhem.pl (3134)
2018.09.04 11:47:34.867 1:     main::HandleTimeout                 called by /opt/fhem/fhem.pl (649)





Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: CoolTux am 04 September 2018, 11:59:15
@all

Ich habe soeben den Partymodus implementiert.
Bei den Rolläden wird dazu das Attribut "AutoShuttersControl_Partymode" entsprechend gesetzt so das der Rolladen beachtet wird im Partymode oder nicht.
Desweiteren wird dann der Partymode über den set Befehl im Moduldevice entsprechend aktiviert. Sollten in dieser Zeit Fahrkommandos kommen werden diese zwischengespeichert und das letzte Kommando wird dann beim off setzen des Partymodus an das jeweilige Rollo gesendet.

Beachtet bitte immer den ersten Post!!
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: FunkOdyssey am 04 September 2018, 12:12:06
Wäre es möglich, deine PM per "update add" einbindbar zu machen?
Per Copy&Paste in nem FORM geht hin und wieder etwas schief und man hat nicht immer und überall SSH-Zugang.
Du bist halt zu schnell mit den Commits. :-)
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: CoolTux am 04 September 2018, 12:14:57
Zitat von: FunkOdyssey am 04 September 2018, 11:53:58
Eine kleine Sammlung:




Dein Quote im ersten Post ist nicht vollständig. Es fehlt die richtige Define-Zeile:

define Rolladensteuerung AutoShuttersControl

Hatte ich kurz vorher korrigiert. Danke


Zitat von: FunkOdyssey am 04 September 2018, 11:53:58



Kleiner Typo in L212: https://github.com/LeonGaultier/fhem-AutoShuttersControl/blob/devel/73_AutoShuttersControl.pm#L212
Sollte "controlled" heißen.

Danke ist gefixt

Zitat von: FunkOdyssey am 04 September 2018, 11:53:58



a) Warum sind die Attribute mal groß- und mal kleingeschrieben? AutoShuttersControl vs. autoShutterControl.*
b) Warum mal mit Präfix "auto" und mal ohne "brightnessMinVal"?

Weil die die wo der Anfangsbuchstabe klein geschrieben ist zum Moduldevice gehören und die anderen in die Fremddevice gehen.


Zitat von: FunkOdyssey am 04 September 2018, 11:53:58



Sind die Readings korrekt? Die Räume-Readings sehen irgendwie merkwürdig aus?

   READINGS:
     2018-09-04 11:47:31   room_Homekit,Jalousien jal_buegeln
     2018-09-04 11:47:31   state           active
     2018-09-04 11:47:31   userAttrList    rolled out

[/code]

Nein sind sie nicht. Hast Du Leerzeichen in Deinen Raumnamen drin? Wenn ja muss ich das noch abfangen.

Zitat von: FunkOdyssey am 04 September 2018, 11:53:58




Errors:

2018.09.04 11:47:31.862 3: Please define Homekit first
2018.09.04 11:47:31.864 3: Please define Homekit first
2018.09.04 11:47:34.865 1: ERROR: empty name in readingsBeginUpdate
2018.09.04 11:47:34.865 1: stacktrace:
2018.09.04 11:47:34.865 1:     main::readingsBeginUpdate           called by ./FHEM/73_AutoShuttersControl.pm (651)
2018.09.04 11:47:34.865 1:     AutoShuttersControl::CreateSunRiseSetShuttersTimer called by ./FHEM/73_AutoShuttersControl.pm (676)
2018.09.04 11:47:34.865 1:     AutoShuttersControl::RenewSunRiseSetShuttersTimer called by /opt/fhem/fhem.pl (3134)
2018.09.04 11:47:34.865 1:     main::HandleTimeout                 called by /opt/fhem/fhem.pl (649)
2018.09.04 11:47:34.866 1: PERL WARNING: Use of uninitialized value $name in concatenation (.) or string at /opt/fhem/fhem.pl line 4597.
2018.09.04 11:47:34.866 1: readingsUpdate(,AutoShuttersControl_Time_Sunset,20:08:28) missed to call readingsBeginUpdate first.
2018.09.04 11:47:34.866 1: stacktrace:
2018.09.04 11:47:34.866 1:     main::readingsBulkUpdate            called by ./FHEM/73_AutoShuttersControl.pm (653)
2018.09.04 11:47:34.866 1:     AutoShuttersControl::CreateSunRiseSetShuttersTimer called by ./FHEM/73_AutoShuttersControl.pm (676)
2018.09.04 11:47:34.866 1:     AutoShuttersControl::RenewSunRiseSetShuttersTimer called by /opt/fhem/fhem.pl (3134)
2018.09.04 11:47:34.866 1:     main::HandleTimeout                 called by /opt/fhem/fhem.pl (649)
2018.09.04 11:47:34.867 1: readingsUpdate(,AutoShuttersControl_Time_Sunrise,06:52:44) missed to call readingsBeginUpdate first.
2018.09.04 11:47:34.867 1: stacktrace:
2018.09.04 11:47:34.867 1:     main::readingsBulkUpdate            called by ./FHEM/73_AutoShuttersControl.pm (654)
2018.09.04 11:47:34.867 1:     AutoShuttersControl::CreateSunRiseSetShuttersTimer called by ./FHEM/73_AutoShuttersControl.pm (676)
2018.09.04 11:47:34.867 1:     AutoShuttersControl::RenewSunRiseSetShuttersTimer called by /opt/fhem/fhem.pl (3134)
2018.09.04 11:47:34.867 1:     main::HandleTimeout                 called by /opt/fhem/fhem.pl (649)
2018.09.04 11:47:34.867 1: PERL WARNING: Use of uninitialized value $d in hash element at /opt/fhem/fhem.pl line 4357.
2018.09.04 11:47:34.867 1: ERROR: empty name in readingsBeginUpdate
2018.09.04 11:47:34.867 1: stacktrace:
2018.09.04 11:47:34.867 1:     main::readingsBeginUpdate           called by /opt/fhem/fhem.pl (4742)
2018.09.04 11:47:34.867 1:     main::readingsSingleUpdate          called by ./FHEM/73_AutoShuttersControl.pm (664)
2018.09.04 11:47:34.867 1:     AutoShuttersControl::CreateSunRiseSetShuttersTimer called by ./FHEM/73_AutoShuttersControl.pm (676)
2018.09.04 11:47:34.867 1:     AutoShuttersControl::RenewSunRiseSetShuttersTimer called by /opt/fhem/fhem.pl (3134)
2018.09.04 11:47:34.867 1:     main::HandleTimeout                 called by /opt/fhem/fhem.pl (649)
2018.09.04 11:47:34.867 1: readingsUpdate(,.AutoShuttersControl_InternalTimerFuncHash,HASH(0x56076d7bb8a0)) missed to call readingsBeginUpdate first.
2018.09.04 11:47:34.867 1: stacktrace:
2018.09.04 11:47:34.867 1:     main::readingsBulkUpdate            called by /opt/fhem/fhem.pl (4743)
2018.09.04 11:47:34.867 1:     main::readingsSingleUpdate          called by ./FHEM/73_AutoShuttersControl.pm (664)
2018.09.04 11:47:34.867 1:     AutoShuttersControl::CreateSunRiseSetShuttersTimer called by ./FHEM/73_AutoShuttersControl.pm (676)
2018.09.04 11:47:34.867 1:     AutoShuttersControl::RenewSunRiseSetShuttersTimer called by /opt/fhem/fhem.pl (3134)
2018.09.04 11:47:34.867 1:     main::HandleTimeout                 called by /opt/fhem/fhem.pl (649)


Ich wüsste jetzt nicht wie das zu Stande kommt. Da kann ich Dich nur bitten die neuste Version aus dem Git zu nehmen.

Zitat von: FunkOdyssey am 04 September 2018, 11:53:58



Ich habe plötzlich neue Attribute in meinen Geräten:

.devInfo
.stc


Kommt nicht vom Modul würde ich mal behaupten.


Meine Empfehlung. Aktualisiere FHEM heute! Lösche das AutomaticShuttersControl Device. Eigentlich sollten keine weiteren Readings oder Attribute vom Modul mehr in den Rolläden Devices vorhanden sein. Wenn doch lösche sie bitte.
Lösche auch einen eventuellen Verweis im global Modul unter userattr.

Hole Dir die neuste Github Version und installiere sie. definiere dann das Moduldevice neu.



Vielen vielen Dank auf jeden Fall fürs testen. Und Sorry für die Unordnung die Du gerade scheinbar hast  :'(
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: CoolTux am 04 September 2018, 12:19:09
Zitat von: FunkOdyssey am 04 September 2018, 12:12:06
Wäre es möglich, deine PM per "update add" einbindbar zu machen?
Per Copy&Paste in nem FORM geht hin und wieder etwas schief und man hat nicht immer und überall SSH-Zugang.
Du bist halt zu schnell mit den Commits. :-)

Nein. Diesen (entschuldige bitte) Unsinn mache ich mit Absicht nicht mit. Mein Github ist für die Developer Entwicklung und/oder weiter Entwicklung/Bugfixes von FHEM Modulen welche später offiziell werden.
Das Github ist für mich und Tester. Es bringt mir nichts wenn jeder einfach per Knopfdruck das neue Modul laden kann. Die Leute sollen überlegen und wissen was sie da machen. Das machen erfahrende User und nur solche sind in der Lage mir auch entsprechende Fehlerbeschreibungen zu geben.


Grüße
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: FunkOdyssey am 04 September 2018, 12:30:39
Zitat von: CoolTux am 04 September 2018, 12:14:57
Weil die die wo der Anfangsbuchstabe klein geschrieben ist zum Moduldevice gehören und die anderen in die Fremddevice gehen.

Okay. Nachvollziehbar. Aber ich finde es ein wenig verwirrend. Ich würde alle Attribute eines Moduls (egal wo diese gespeichert sind) übereinander in einer Liste vermuten. Und derzeit wird bei den Attributen ja auch die Groß- und Kleinschreibung berücksichtigt. Meine persönlich Meinung.

Zitat von: CoolTux am 04 September 2018, 12:14:57
Nein sind sie nicht. Hast Du Leerzeichen in Deinen Raumnamen drin? Wenn ja muss ich das noch abfangen.

Nein, aber ich habe das Device in zwei Räumen. Homekit und Jalousien. Ich tippe auf das Komma.

Zitat von: CoolTux am 04 September 2018, 12:14:57
Ich wüsste jetzt nicht wie das zu Stande kommt. Da kann ich Dich nur bitten die neuste Version aus dem Git zu nehmen.

Ich gehe davon aus, dass das mit den Mehrfachwerten im Room-Reading zusammenhängt.

Zitat von: CoolTux am 04 September 2018, 12:14:57
Kommt nicht vom Modul würde ich mal behaupten.

Habe ich auch bemerkt. Nur habe ich meinen Post zu spät geändert.


Zitat von: CoolTux am 04 September 2018, 12:14:57
Meine Empfehlung. Aktualisiere FHEM heute! Lösche das AutomaticShuttersControl Device. Eigentlich sollten keine weiteren Readings oder Attribute vom Modul mehr in den Rolläden Devices vorhanden sein. Wenn doch lösche sie bitte.
Lösche auch einen eventuellen Verweis im global Modul unter userattr.

Ich habe sowieso den ganzen Test noch nicht gespeichert. :-)

Zitat von: CoolTux am 04 September 2018, 12:14:57
Hole Dir die neuste Github Version und installiere sie. definiere dann das Moduldevice neu.

Immer. Ich habe dein Repo "watched" :-)

Zitat von: CoolTux am 04 September 2018, 12:14:57
Vielen vielen Dank auf jeden Fall fürs testen. Und Sorry für die Unordnung die Du gerade scheinbar hast  :'(

Dafür brauchst du dich nicht entschuldigen. Das gehört zu ner Beta dazu und ich habe die Entscheidung schließlich selbst getroffen.
Ich will mithelfen, aber ich bin auch noch vorsichtig mit der endgültigen Scharfschaltung.
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: marvin78 am 04 September 2018, 12:34:22
Zitat von: CoolTux am 04 September 2018, 12:19:09
Nein. Diesen (entschuldige bitte) Unsinn mache ich mit [...]

Ob das Unsinn ist oder nicht, hängt tatsächlich vom Anwendungsfall ab, Leon. Ich mache es nur so, da ich meine Module aus guten Gründen nicht ins offizielle SVN einchecke. Wer meine Module dann ausprobiert, weiß hoffentlich, was er da tut...wenn nicht, ist mir das ziemlich wurscht. Die Frage des Users ist legitim. Deine Antwort, bis auf den ersten Teilsatz, auch ;)
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: CoolTux am 04 September 2018, 12:46:16
@FunkOdyssey

Ich habe das mit dem Room und Leerzeichen gerade getestet. Das sollte gehen. Mehrfachräume schaue ich mir gleich mal an. Aber Deine Fehler sollten nicht daher kommen. Diese Raumreadings sind nur zur Übersicht und werden im Modul nicht weiter beachtet.
Das mit dem Klein und Großschreiben überlege ich mir in der Tat noch mal. Es hieß ja auch mal das alle Atribute eines Modules ein Präfix mit Modulnamen tragen sollten. Ich finde das ok. Werde ich denke ich mal machen.

@marvin78
Dann halt "Diesen für mich Unsinn", hihi. Aber ich gebe Dir Recht, es hängt in der Tat vom Anwendungsfall ab.
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: CoolTux am 04 September 2018, 12:51:08
So ich habe das mit den 2 Räumen auch mal getestet. Ist tatsächlich ein Komma dazwischen und kein neuer Raum. Muß ich mir mal anschauen was ich da machen kann oder ob man damit einfach lebt.
Kommt aber viel viel später. Wie gesagt ist nur eine Info. Und man kann es ja auch so lesen das room_1,2 auch Raum eins und zwei diese Rolläden haben  ;D
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: CoolTux am 04 September 2018, 13:01:31
Ich habe in meiner lokalen Version alle Attribute für das Moduldevice nun mit vorgestellten AutoShuttersControl_ versehen. Sieht wirklich viel übersichtlicher aus.
Diese Version wird es aber erst ab morgen geben. Vor dem Update wäre es gut wenn Ihr einfach alle Attribute (ausser room) aud dem Moduldevice löscht. Dann Update machen vom Modul, neu starten und dann die Attribute neu setzen.
Danach vielleicht noch mal die SunrisSunset Timer neu setzen.

DANKE
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: elle am 04 September 2018, 13:19:52
Hallo,

super Sache, das Ganze endlich in ein Modul zu verpacken.

Leider kann ich lt. der Anleitung im Einleitungspost nicht testen, da ich bereits das Script einsetze. Ich denke aber darueber nach, ein komplettes Backup der Installation zu ziehen, das Script rauszuschmeissen und hier mitzutesten, aber leider habe ich im Moment nicht soviel Zeit, mich mit FHEM zu beschaeftigen.

Eine Frage/Anregung haette ich aber bzgl. des AutoShutterControl Attributs: Waere es u.U. nicht sinnvoller statt der Zahlenwerte Strings zu benutzen:
0 -> "Nein" oder "Aus"
1 -> "Homematic"
2 -> "Inverse" oder "Rollo"

M.E. ist dies fuer den Anwender einfacher als sich merken zu muessen, was die Zahlenwerte bedeuten und sollte performancetechnisch keinen oder kaum Impact haben.

Ein anderer Gedanke bzgl. des Setzens der Timer, den ich auch schon beim Script hatte (wobei ich allerdings nicht weiss, wie das hier im Modul implementiert ist), ist der, ob es nicht sinnvoller - und moeglich - ist, nicht die Timer zu einer festen Zeit fuer alles zu setzen, sondern zusaetzlich bei einer Aenderung des Attributs eines Rolladens die Timer fuer diesen auf Basis der neuen Attributwerte gleich neu zu setzen.
Beispiel:
- Im Laufe des Tages stelle ich fest, dass der Runterfahrentimer fuer den Rollladen im Arbeitszimmer unguenstig liegt, weil ich den Rollladen als Zugang zur Terrasse laenger offen halten moechte ohne den Partymodus fuer diesen Raum einzuschalten. Also aendere ich die Zeit und wundere mich (da ich vergessen habe den at manuell zu starten), dass der Rollladen zu frueh runterfaehrt ...

Nur so ein paar Gedanken ...

Ansonsten weiter so!

Gruss

/elle

Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: CoolTux am 04 September 2018, 13:49:26
Vielen Dank für Deine Anregungen.

Das mit dem AutoShutterControl Attribut ist mit Absicht in Zahlen gemacht, da ich diese Zahlen eins zu eins für ein Array nehme. Das erspart viel umschreiben innerhalb des Codes.
Nun könnte man zur Not noch über das umschreiben nachdenken, aber Du kannst nicht komplett fest machen das 1 Homematic ist und 2 der Inverse oder Rollo. Es gibt so viele verschiedene Möglichkeiten. Dann lieber an Hand von Eigenschaften fest machen und es einfach 1 und 2 nennen, denke ich.


Das setzen der Timer wäre im Prinzip automatisch möglich. Müsste ich mir anschauen. Frage ist nur ab wann Du das machen willst? Welches Attribut soll den Event liefern?
Alle wäre ungünstig dann haben wir ein Feuerwerk und was ist mit der Änderung der Attribute im Moduldevice für Sunset Sunrise? Es gibt einfach zu viele Möglichkeiten.
Aber ich werde gerne einmal darüber nachdenken wie man es machen könnte, der Aufwand es später zu implementieren ist minimal. Siehe meinen nächsten Post.


Grüße
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: CoolTux am 04 September 2018, 13:51:25
Ich habe soeben erfolgreich das Value time der Attribute AutoShuttersControl_Down und AutoShuttersControl_Up implementiert. Sind diese Attribute gesetzt werden automatisch die Zeiten aus den Attributen AutoShuttersControl_Time_Down_Early und AutoShuttersControl_Time_Up_Early als Fahrzeiten genommen.

Version kommt aber erst morgen.
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: Beta-User am 04 September 2018, 14:02:31
Zitat von: CoolTux am 04 September 2018, 13:49:26
Welches Attribut soll den Event liefern?
Wie wäre es mit: AutoShuttersControl_Time_.*

Und ob es ein Feuerwerk gibt?
Aber die Vorgehensweise, Attribute zu ändern, wenn was nicht längerfristig wirksam sein soll, finde ich grundsätzlich nicht so toll, das rote ? sollte nach meinem Verständnis/meiner Handhabung eigentlich wirklich eine Warnung darstellen, dass potentiell gewollte Änderungen verlorengehen.

Eine Idee für die Lösung der aufgezeigten Aufgabe habe ich leider nicht wirklich, meine Gedanken gingen in Richtung eines "set <ASC-Device> blockUntil <devspec - kann auch ein room-Filter sein> <HH:MM>"; damit könnte man laufende Timer einfach auf diesen Zeitpunkt verschieben bzw. löschen, wenn zwischenzeitlich ein weiterer Befehl anstünde (und dann stattdessen diesen in den Timer setzen).
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: CoolTux am 04 September 2018, 14:07:00
Zitat von: Beta-User am 04 September 2018, 14:02:31
Wie wäre es mit: AutoShuttersControl_Time_.*

Und ob es ein Feuerwerk gibt?
Aber die Vorgehensweise, Attribute zu ändern, wenn was nicht längerfristig wirksam sein soll, finde ich grundsätzlich nicht so toll, das rote ? sollte nach meinem Verständnis/meiner Handhabung eigentlich wirklich eine Warnung darstellen, dass potentiell gewollte Änderungen verlorengehen.

Eine Idee für die Lösung der aufgezeigten Aufgabe habe ich leider nicht wirklich, meine Gedanken gingen in Richtung eines "set <ASC-Device> blockUntil <devspec - kann auch ein room-Filter sein> <HH:MM>"; damit könnte man laufende Timer einfach auf diesen Zeitpunkt verschieben bzw. löschen, wenn zwischenzeitlich ein weiterer Befehl anstünde (und dann stattdessen diesen in den Timer setzen).

Was ist mit AutoShuttersControl_Up oder AutoShuttersControl_Down, also wenn ich von astro auf time gehe? Ist nicht einfach.

Das mit dem Set finde ich ganz praktisch. Muss mal drüber nach denken.
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: Beta-User am 04 September 2018, 14:21:21
Zitat von: CoolTux am 04 September 2018, 14:07:00
Was ist mit AutoShuttersControl_Up oder AutoShuttersControl_Down, also wenn ich von astro auf time gehe? Ist nicht einfach.
Nee, ist es nicht. Diese Attribute hatte ich gar nicht auf dem Schirm, und für ..._Mode_Up/Down gilt dasselbe...

Meine Meinung dazu ist aber, dass solche Änderungen aus Usersicht mit der Erwartung verbunden werden, dass sie sofort wirksam werden. Ergo muß man sie, jedenfalls sofern nicht nur Ziel-Positionen drin stehen, die zum Ausführungszeitpunkt genutzt werden (?) auch alle Attribute überwachen.

Spontaner Gedanke: Das ganze bei den Devices nur als Readings hinterlegen, und Setzen der Werte dann über das zentrale Device? Das hätte allerdings den erheblichen Nachteil, dass ohne statefile alles weg wäre => eher auch nicht optimal :( .
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: CoolTux am 04 September 2018, 14:30:31
Zitat von: Beta-User am 04 September 2018, 14:21:21
Nee, ist es nicht. Diese Attribute hatte ich gar nicht auf dem Schirm, und für ..._Mode_Up/Down gilt dasselbe...

Meine Meinung dazu ist aber, dass solche Änderungen aus Usersicht mit der Erwartung verbunden werden, dass sie sofort wirksam werden. Ergo muß man sie, jedenfalls sofern nicht nur Ziel-Positionen drin stehen, die zum Ausführungszeitpunkt genutzt werden (?) auch alle Attribute überwachen.

Spontaner Gedanke: Das ganze bei den Devices nur als Readings hinterlegen, und Setzen der Werte dann über das zentrale Device? Das hätte allerdings den erheblichen Nachteil, dass ohne statefile alles weg wäre => eher auch nicht optimal :( .

Und ich will nicht in fremde Devices mehr wie nötig reinschreiben. Das über wachen der Rollädendevices habe ich auf den Schirm, es gibt sogar schon eine Funktion um das ein zu richten, aktuell deaktiviert.
Aber wenn überhaupt dann werde ich nur einige wenige Attribute triggern. Muss selber erstmal schauen.
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: elle am 04 September 2018, 15:54:00
Zitat von: CoolTux am 04 September 2018, 13:49:26
Das mit dem AutoShutterControl Attribut ist mit Absicht in Zahlen gemacht, da ich diese Zahlen eins zu eins für ein Array nehme. Das erspart viel umschreiben innerhalb des Codes.
Nun könnte man zur Not noch über das umschreiben nachdenken, aber Du kannst nicht komplett fest machen das 1 Homematic ist und 2 der Inverse oder Rollo. Es gibt so viele verschiedene Möglichkeiten. Dann lieber an Hand von Eigenschaften fest machen und es einfach 1 und 2 nennen, denke ich.
Der Gedanke war, damit die Positionierungslogik zu beschreiben, vllt. eher "Homematic Style" fuer 100% => offen und 0% geschlossen bzw. Inverse Style fuer die Variante wie es Rollo macht mit 0% offen und 100% geschlossen.

Eventuell koennte aber ein Hash mit numerischen Keys benutzt werden, aber um dies zu beurteilen, kenne ich weder die Interna des Moduls noch jene von FHEM zur Genuege ...

my %hash = ( 0 => 'Aus', 1 => 'Homematic Style', 2 => 'Reverse Style' );
my %rev_hash = reverse %hash;

ergibt, ueber Data::Dumper ausgegeben:

$VAR1 = {
          '2' => 'Foo',
          '0' => 'Nein',
          '1' => 'Homematic style'
        };

$VAR1 = {
          'Homematic style' => '1',
          'Foo' => '2',
          'Nein' => '0'
        };

sodass man in beiden Richtungen auf alles zugreifen kann, aber nur einmal definieren muss, wie als wenn man ein einfaches Array definiert. Das Array kann man zur Not immer noch aus den Keys des Hashes abgreifen ...

Zitat von: CoolTux am 04 September 2018, 13:49:26Das setzen der Timer wäre im Prinzip automatisch möglich. Müsste ich mir anschauen. Frage ist nur ab wann Du das machen willst? Welches Attribut soll den Event liefern?
Alle wäre ungünstig dann haben wir ein Feuerwerk und was ist mit der Änderung der Attribute im Moduldevice für Sunset Sunrise? Es gibt einfach zu viele Möglichkeiten.
Aber ich werde gerne einmal darüber nachdenken wie man es machen könnte, der Aufwand es später zu implementieren ist minimal. Siehe meinen nächsten Post.
Die Frage ist tatsaechlich komplex - da stimme ich Dir zu ...

Und Beta-User hat bereits beschrieben, wieso ich diesen Gedanken hatte, da es mir - auch wenn ich mich schon laenger mit FHEM beschaeftige (nur so gut wie gar nicht hier aktiv war) - auch schon ein paar Mal passiert ist, dass ich mich gewundert hatte, warum die Aenderung nicht aktiv war und dann fiel mir ein, dass ich den at->exec_now nicht angestossen hatte  ...

Gruss
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: Beta-User am 04 September 2018, 17:28:16
Zitat von: elle am 04 September 2018, 15:54:00
Der Gedanke war, damit die Positionierungslogik zu beschreiben, vllt. eher "Homematic Style" fuer 100% => offen und 0% geschlossen bzw. Inverse Style fuer die Variante wie es Rollo macht mit 0% offen und 100% geschlossen.
Da sind wir m.E. im Prinzip ja wieder alle beieinander, oder?

Denn im Prinzip dürfte es nur zwei Grundtypen geben, nämlich entweder "Geschlossen" entspricht "0%" oder eben "100%".
Mehr Varianten sind denkbar bei den Fahrbefehlen (level, pct, percent, direkte Zahleneingabe [0-100] oder [0-1],...). Aber CoolTux hat dahingehend recht, dass man irgendwann aufhören sollte, jeden Fall unmittelbar abfangen zu wollen. Weit verbreitete Typen sollten einfach abgedeckt werden können, aber wer exotische Hardware hat, kann die volle Flexibilität nutzen und seinen eigenen Kram da händisch einpflegen.




Wie bereits geschrieben, dürfte aber die Info, wo oben und unten ist, für die Steuerung des Rolladens insgesamt sehr wichtig sein. In dem Zusammenhang zwei Fragen:

- Im Schlafzimmer sind zwei Rolläden, die werden bisher aber fast nie ganz aufgemacht, sondern z.B. meistens nur zu 20-30%. Wenn ich diese beiden Werte jetzt als "Open"-Werte angebe, gehe ich davon aus, dass das nur die auf-Befehle aus der Automatik betrifft und das System nicht insgesamt aus dem Tritt kommt, nur weil einer der Rolläden versehentlich mal manuell auf einen Wert außerhalb "Closed" und "Open" steht. Das könnte nämlich insbesondere im Rahmen der Beschattung vorkommen - da wäre z.B. 40 für den einen Rolladen ein guter Wert.

- Beschattung: Jemand stellt den Rolladen manuell auf einen Wert, der unterhalb der eigentlichen Beschattung liegt (also nachts geschlossen=0, dann Automatik-auf auf 100, manuell auf 20, Beschattung würde 40 ergeben). Wird der Rolladen gefahren?
Wunsch wäre: nein, weil ein user zwischenzeitlich anders wollte als die Automatik.
Anders wäre das, wenn der user auf 40 gestellt hätte, aber die Beschattung auf 20 erfolgen sollte. Nach einer Karenzfrist (z.B. von einer Stunde seit der letzten Betätigung) wäre es im zweiten Fall ok, wenn die Automatik greift.



Überhaupt: manuelle Betätigung.
Da ich noch keine Automatik für die Roommates hatte, gingen die Rolladen heute morgen ziemlich früh hoch. Das wollte ich mit einem Tastendruck abbrechen, was allerdings nur kurzfristig Wirkung zeigte. Nach einigen Sekunden fuhr der Rolladen wieder an...
Absicht oder nicht?
Wunsch wäre, dass Usereingriffe während einer automatischen Fahrt Prio haben.

Gruß, Beta-User
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: CoolTux am 04 September 2018, 17:35:39
Der Rolläden ist bestimmt bei Sonnenaufgang gefahren nehme ich an. Da aktuell der Sonnenaufgang immer später wird, wird es wohl so gewesen sein das nach dem ablaufen des timers der rolkaden fuhr, dann würde der nächste Sonnenaufgang berechnet, dieser war paar Minuten später wie der gerade eben und deswegen noch am selben Tag. Genau nach dem du Stop gemacht hast.

Hätte noch keine Idee zum abfangen.
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: Beta-User am 04 September 2018, 18:54:35
Jup, astro/CIVIL, ob jetzt innerhalb der gesetzten Grenzen.

Unschöne Schleife eigentlich. Auf die Schnelle mögliche Ansätze, ohne den Modulcode analysiert zu habeb: entweder beim Erstellen des Timers eine andere sunrise-Variante nehmen, oder das Ergebnis darauf prüfen, ob es zu nah an jetzt liegt (dann +24h) oder die Ausführung nur des Fahrbefehls unterlassen, wenn der Rolladen erst vor ein paar Sekunden gefahren wurde (ReadingsAge auf "level" oder "pct")?
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: CoolTux am 04 September 2018, 19:00:36
Zitat von: Beta-User am 04 September 2018, 18:54:35
Jup, astro/CIVIL, ob jetzt innerhalb der gesetzten Grenzen.

Unschöne Schleife eigentlich. Auf die Schnelle mögliche Ansätze, ohne den Modulcode analysiert zu habeb: entweder beim Erstellen des Timers eine andere sunrise-Variante nehmen, oder das Ergebnis darauf prüfen, ob es zu nah an jetzt liegt (dann +24h) oder die Ausführung nur des Fahrbefehls unterlassen, wenn der Rolladen erst vor ein paar Sekunden gefahren wurde (ReadingsAge auf "level" oder "pct")?

Ich schaue es mir die Tage mal genauer an. Heute Abend muss ich noch was am Lüften Modus umbauen. Habe da glaube einen Fehler gefunden.
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: CoolTux am 04 September 2018, 23:04:45
Guten Abend,

Ich habe soeben Version 0.1.9 integriert. Mit dabei ist nun Ausperrschutz und Frostschutz.
Bitte achtet wie immer auf den ersten Post.


Eine Warnung habe ich noch. Ich musste das Value eines Attributes ändern. Dies hat zur Folge das es zur Inkonsistenz kommt und damit zu Problemen. Je nach Anzahl und Konfiguration der Rolläden gibt es zwei Wege.
Vorbereitung vor dem Update
- Entweder das Moduldevice löschen und damit eine saubere Deinstallation
- oder jeden Rolladen anfassen und im Attribut userattr den Eintrag für AutoShuttersControl_Antifreeze sowie das Attribut AutoShuttersControl_Antifreeze an sich entfernen.
Danach speichern und dann die neue Modulversion installieren. Dann ist ein neustart Pflicht




Grüße
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: CoolTux am 05 September 2018, 06:59:54
Guten Morgen,

Wie ich finde sind wir schon sehr weit gekommen. Heute schaue ich mir die Probleme mit dem zweimal ausführen von Sunset und Sunrise am selben Tag wenn der neuerrechnete Zeitpunkt nach dem aktuellen am selben Tag liegt.
Außerdem fange ich im Modul mit der Dokumentation an. Hier nehme ich gerne auch Patches entgegen. Ich hasse Dokumentation  ;D

Ansonsten freuen wir uns über jeden mutigen Tester und Eure Berichte und Anregungen.
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: Beta-User am 05 September 2018, 10:33:46
Moin zusammen,

bin auch schwer beeindruckt, wie schnell die Entwicklung vorangeht und v.a., wie positiv Anregungen aufgenommen werden!
Einfach super :) .

Der Wechsel zur neuen Version war - anders als erwartet - keine größere Sache, geht recht einfach mit dem FILTER, nachdem man FHEM samt Modul aktualisiert hat (kam von 0.0.5, die Rolläden wurden also noch nicht über das neue Attribut erkannt, sonst muss man evtl. auch anders vorgehen):deleteattr TYPE=CUL_HM:FILTER=subType=blindActuator AutoShuttersControl_Antifreeze
attr TYPE=CUL_HM:FILTER=subType=blindActuator AutoShuttersControl 2

und dann das Attribut bei der Leinwand wieder gelöscht.

Für die Default-Werte bei den Timern: Sollte man die Grenzen nicht etwas "nachbarfreundlicher" setzen? Kann ja jeder später passend ändern.



Zu dem Zusammenfassen mehrerer Presence-Devices als Hilfsmittel noch eine RAW-Definition für eine Structure:
define rr_Parents structure eltern rr_Mann rr_Frau
attr rr_Parents clientstate_behavior relative
attr rr_Parents clientstate_priority asleep gotosleep awoken home absent
attr rr_Parents group Persons
attr rr_Parents icon user_unknown
attr rr_Parents room Steuerung
attr rr_Parents userReadings lastState:(home|awoken|asleep|gotosleep|absent) { OldValue($name) }
und als Muster ein Weekdaytimer für meinen "Mann"-Dummy, damit der sich erst mal "bewegt". Gibt's in ähnlicher Form auch für weitere Personen
define rr_Mann_Presence_Timer WeekdayTimer rr_Mann !$we|06:30|awoken !$we|06:40|home $we|08:00|awoken $we|08:30|home !$we|07:30|absent !$we|19:00|home 01234|21:45|gotosleep 01234|22:00|asleep 56|22:40|gotosleep 56|23:00|asleep
attr rr_Mann_Presence_Timer commandTemplate set $NAME  $EVENT
attr rr_Mann_Presence_Timer disable 0
attr rr_Mann_Presence_Timer group Persons
attr rr_Mann_Presence_Timer icon status_automatic
attr rr_Mann_Presence_Timer room Steuerung




Probleme habe ich noch mit dem Versuch einer handy-basierten Anwesenheitserkennung, das ist aber ein gesondertes Thema und hier eigentlich OT. Für den Fall, dass aber jemand zum Testen die "makeFamily" nutzt und das ähnlich (u.a. mit einer Fritzbox) abbilden will, hier schon mal ein Zwischenstand:

Die setlist wird bei den Personen-Dummys erweitert:attr rr_Mann readingList state smartphone smartphone_MAC
attr rr_Mann setList state:home,gotosleep,awoken,absent,asleep smartphone:absent,present smartphone_MAC

mit "set rr_Mann smartphone_MAC <mac_....:>" (kompletter Event-Teil der Fritzbox einschließlich Doppelpunkt) wird das Reading gefüllt.
Dann wird das Reading "smartphone" per notify mit "absent" bzw. "present" gefüllt:
define n_MAC_Check notify Fritzbox:mac_.*:.* {if ($EVTPART1 eq "inactive") {\
    fhem("set TYPE=dummy:FILTER=smartphone_MAC=$EVTPART0 smartphone absent");;\
  }\
  else {\
    fhem("set TYPE=dummy:FILTER=smartphone_MAC=$EVTPART0 smartphone present");;\
  }\
}
attr n_MAC_Check group Persons


Fehlt noch eine einschränkende event-on-change-reading-Definition und ein notify samt sinnvoller Logik, um aus der Anwesenheit des Smartphones passende Schlüsse zu ziehen (eigentlich sagt das - da ein DD-WRT-Router das "bessere WLAN" bereitstellt - im Moment nicht mehr wie: ziemlich sicher zuhause... Das will ich dann erst mal mit currValue aus dem jeweiligen Weekdaytimer verheiraten).



Was Doku angeht, schau' ich bei Gelegenheit mal, ob ich dazu komme, was sinnvolles beizutragen.

Gerne kann ich den "Begleitkram" mit den ReadingsGroups, der Musterfamilie etc. (wenn's mal funktioniert) dann auch ins Wiki packen, wenn das für andere von Interesse sein sollte?




Der Vollständigkeit halber zu guter Letzt noch eine Liste der offene Punkte/Wünsche:
- abgearbeitete Timer nicht mehr am selben Tag ausführen
- Timer-Attribute im HH:MM-Format möglich (? kann sein, dass es schon jetzt funktioniert, statt HH:MM:SS)
- Erster Thread:
-- chmod 644 (Erster Thread) ist ausreichend
-- Thread-Titel ;)
-- (Meine versehentlich) inkonsistente Namensgebung: "defmod rr_Mann dummy" statt "defmod rr_Maria dummy"
Großes Danke, Grüße und: Macht euch keinen Stress!

Beta-User

EDIT: Zeiten am WeekdayTimer verbessert
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: FunkOdyssey am 05 September 2018, 10:39:26
@Beta-User:
Wieso machst du dir so viel Arbeit mit denn Structure? Mit dem Residents-Modul wäre es ein Einzeiler. Ist bei mir in jeder FHEM-Installation sowieso Standard.
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: kjmEjfu am 05 September 2018, 10:59:31
Wird es die Möglichkeit geben Attribute pro Rollo zu überschreiben?
Beispiel wären dafür z.B.  AutoShuttersControl_autoAstroModeEvening und AutoShuttersControl_autoAstroModeMorning. Hintergrund: Rollos im Badezimmer könnte man dann auf REAL setzen, während Rollos im Wohnzimmer erst zu CIVIL oder in der Weihnachtszeit noch später runter fahren.

Gilt übrigens auch für so Sachen wie Urlaubs-oder Ferientage, da hier doch oft ein Unterschied zwischen Kindern und Eltern liegt und man das schwer über ein Attribut nur am Device regeln kann.
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: CoolTux am 05 September 2018, 11:11:40
Zitat von: kjmEjfu am 05 September 2018, 10:59:31
Wird es die Möglichkeit geben Attribute pro Rollo zu überschreiben?
Beispiel wären dafür z.B.  AutoShuttersControl_autoAstroModeEvening und AutoShuttersControl_autoAstroModeMorning. Hintergrund: Rollos im Badezimmer könnte man dann auf REAL setzen, während Rollos im Wohnzimmer erst zu CIVIL oder in der Weihnachtszeit noch später runter fahren.

Gilt übrigens auch für so Sachen wie Urlaubs-oder Ferientage, da hier doch oft ein Unterschied zwischen Kindern und Eltern liegt und man das schwer über ein Attribut nur am Device regeln kann.

Ja natürlich ist das möglich. Deswegen arbeiten wir ja mit Attributen, damit der User diese ändern kann. Steht aber auch im ersten Post dieses Threads.
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: CoolTux am 05 September 2018, 11:12:10
@Beta-User:
Vielen Dank für die Rückmeldung.
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: Beta-User am 05 September 2018, 11:20:08
[Sorry für OT]
@FunkOdyssey:
Danke für den Hinweis, muss ich mir bei Gelegenheit mal anschauen.

structure kenne ich halt schon, und im Ergebnis ist es auch damit nur ein 4-Zeiler; braucht keine 10 Min. bis es passt und ist sehr übersichtlich ;) .

Bisher habe ich um das Thema Anwesenheitserkennung etc. einen Bogen gemacht, und "Residents" ist wieder so ein Paket, das sehr viele Optionen anbietet (und auf den ersten Blick weitere Vorarbeiten in Richtung Roommates und Guests vorauszusetzen scheint) ; da stellt sich dann immer die Frage, was man wirklich braucht.

Bei den Dingen, die ich dazu hier gepostet habe, ging es nur darum, schnell so eine Art (halbwegs sinnvolle) "Minimalst-Lösung" zu haben, die ggf. für andere hilfreich ist (sei es nur, um eine Testinstallation einzurichten).

Daher die Frage in dem Zusammenhang: Gibt es irgendwo eine Darstellung, wie man sich mit o.g. Modulen ein "Minimal"-Set an Personen konfiguriert?

Wenn es dazu keine einfache Antwort gibt: Bitte kurzen Hinweis, das sollte in einen neuen Thread, muß CoolTux nicht auch noch alles lesen...
[/Sorry für OT]
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: kjmEjfu am 05 September 2018, 11:27:43
Zitat von: CoolTux am 05 September 2018, 11:11:40
Ja natürlich ist das möglich. Deswegen arbeiten wir ja mit Attributen, damit der User diese ändern kann. Steht aber auch im ersten Post dieses Threads.

Hmm, das habe ich irgendwie überlesen.

Im Quelltext finde ich auch nur sowas wie:

my $autoAstroMode           = AttrVal($name,'AutoShuttersControl_autoAstroModeEvening','REAL');

und dann wird im jeweiligen Device geprüft, ob astro oder time.
Mein Wunsch wäre aber (bei Clunis Code habe ich mir das reingepatcht), dass ich den autoAstroMode pro Rollos festlegen kann.

Quasi sowas wie:

my $autoAstroMode           = AttrVal($shuttersDev,'AutoShuttersControl_autoAstroModeEvening',AttrVal($name,'AutoShuttersControl_autoAstroModeEvening','REAL'));

Oder habe ich gerade einen Denkfehler?
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: CoolTux am 05 September 2018, 11:34:27
Zitat von: kjmEjfu am 05 September 2018, 11:27:43
Hmm, das habe ich irgendwie überlesen.

Im Quelltext finde ich auch nur sowas wie:

my $autoAstroMode           = AttrVal($name,'AutoShuttersControl_autoAstroModeEvening','REAL');

und dann wird im jeweiligen Device geprüft, ob astro oder time.
Mein Wunsch wäre aber (bei Clunis Code habe ich mir das reingepatcht), dass ich den autoAstroMode pro Rollos festlegen kann.

Quasi sowas wie:

my $autoAstroMode           = AttrVal($shuttersDev,'AutoShuttersControl_autoAstroModeEvening',AttrVal($name,'AutoShuttersControl_autoAstroModeEvening','REAL'));

Oder habe ich gerade einen Denkfehler?

Sorry. Ich Dussel.
Jetzt weiß ich was Du meinst. Du willst es ja pro Rolladen steuern. Ich habe mich da erstmal an Bernd sein Script gehalten. Man kann aber gerne über die Nützlichkeit einer solchen Möglichkeit Diskutieren.

Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 05 September 2018, 11:47:51
Vorschlag dazu:
Attribut für individuelle Einstellung am Rolladen vorsehen, aber nach der Installation noch nicht mit Werten füllen. Kann dann der User machen. Bei der Erstellung der Timer prüfen, ob am Gerät vorhanden, sonst Wert aus dem Zentraldevice.

Könnte man übrigens mit den meisten anderen Attributen auch so machen, das würde ggf. die Übersichtlichkeit erhöhen (die meisten Rolläden sollen z.B. bei mir auch gleich behandelt werden, es würde reichen, die abweichenden anders zu behandeln...). Wäre wieder ein deutlicher Schritt in Richtung Einrichtungsfreundlichkeit.

Wieder mal nur meine 2ct ;) .
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: FunkOdyssey am 05 September 2018, 12:08:12
Ich kann das Modul irgendwie immer noch nicht richtig nutzen:


Ich lege ASC an:
define Rolladensteuerung AutoShuttersControl

Dann setze ich das AutoShuttersControl auf 1 in einer Test-Jalousie und führe anschließend einen "scanForShutters" aus.
Die Test-Jalousie habe ich diesmal nur in einem Raum "Jalousien". Daran liegt es also wirklich nicht.
Es erscheint ein Stracktrace. Und die Liste der userattr ist nicht vollständig. Es kommen nur zwei/drei ASC-Attribute an. Das passiert auch, wenn das userattr vorher leer war.

Scheinbar kommt der Stracktrace, da Readings aktualisiert werden sollen, für die userattr standardgemäß gesetzt sein sollten. Diese sind bei mir aber nie angekommen.


2018.09.05 12:01:43.169 3: AutoShuttersControl (Rolladensteuerung) - defined
2018.09.05 12:01:46.808 5: AutoShuttersControl (Rolladensteuerung) - Devname: global Name: Rolladensteuerung Notify: [
  'ATTR Rolladensteuerung verbose 5'
]

2018.09.05 12:01:53.139 1: PERL WARNING: Use of uninitialized value $value in string eq at /opt/fhem/fhem.pl line 4578.
2018.09.05 12:02:09.617 5: AutoShuttersControl (Rolladensteuerung) - Devname: global Name: Rolladensteuerung Notify: [
  'ATTR jal_buegeln AutoShuttersControl 1'
]

2018.09.05 12:02:19.409 4: AutoShuttersControl (Rolladensteuerung) - ShuttersList: jal_buegeln
2018.09.05 12:02:19.421 5: AutoShuttersControl (Rolladensteuerung) - Devname: Rolladensteuerung Name: Rolladensteuerung Notify: [
  'userAttrList: rolled out'
]

2018.09.05 12:02:19.434 5: AutoShuttersControl (Rolladensteuerung) - Devname: global Name: Rolladensteuerung Notify: [
  'ATTR jal_buegeln AutoShuttersControl_Offset_Minutes_Evening 1'
]

2018.09.05 12:02:19.441 3: Please define Jalousien first
2018.09.05 12:02:19.442 3: Please define Jalousien first
2018.09.05 12:02:19.444 3: Please define Jalousien first
2018.09.05 12:02:19.446 3: Please define Jalousien first
2018.09.05 12:02:19.447 3: Please define Jalousien first
2018.09.05 12:02:19.449 3: Please define Jalousien first
2018.09.05 12:02:19.451 3: Please define Jalousien first
2018.09.05 12:02:19.452 3: Please define Jalousien first
2018.09.05 12:02:19.454 3: Please define Jalousien first
2018.09.05 12:02:19.455 3: Please define Jalousien first
2018.09.05 12:02:19.457 3: Please define Jalousien first
2018.09.05 12:02:19.459 3: Please define Jalousien first
2018.09.05 12:02:19.460 3: Please define Jalousien first
2018.09.05 12:02:19.462 3: Please define Jalousien first
2018.09.05 12:02:19.463 3: Please define Jalousien first
2018.09.05 12:02:19.465 3: Please define Jalousien first
2018.09.05 12:02:19.467 3: Please define Jalousien first
2018.09.05 12:02:19.468 3: Please define Jalousien first
2018.09.05 12:02:19.470 3: Please define Jalousien first
2018.09.05 12:02:19.472 3: Please define Jalousien first
2018.09.05 12:02:19.473 3: Please define Jalousien first
2018.09.05 12:02:19.475 3: Please define Jalousien first
2018.09.05 12:02:19.477 3: Please define Jalousien first
2018.09.05 12:02:19.478 3: Please define Jalousien first
2018.09.05 12:02:19.480 3: Please define Jalousien first
2018.09.05 12:02:19.482 3: Please define Jalousien first
2018.09.05 12:02:19.484 3: Please define Jalousien first
2018.09.05 12:02:19.485 3: Please define Jalousien first
2018.09.05 12:02:19.487 3: Please define Jalousien first
2018.09.05 12:02:19.489 3: Please define Jalousien first
2018.09.05 12:02:19.490 3: Please define Jalousien first
2018.09.05 12:02:19.492 3: Please define Jalousien first
2018.09.05 12:02:19.494 3: Please define Jalousien first
2018.09.05 12:02:19.496 3: Please define Jalousien first
2018.09.05 12:02:24.497 1: ERROR: empty name in readingsBeginUpdate
2018.09.05 12:02:24.497 1: stacktrace:
2018.09.05 12:02:24.497 1:     main::readingsBeginUpdate           called by ./FHEM/73_AutoShuttersControl.pm (681)
2018.09.05 12:02:24.497 1:     AutoShuttersControl::CreateSunRiseSetShuttersTimer called by ./FHEM/73_AutoShuttersControl.pm (706)
2018.09.05 12:02:24.497 1:     AutoShuttersControl::RenewSunRiseSetShuttersTimer called by /opt/fhem/fhem.pl (3134)
2018.09.05 12:02:24.497 1:     main::HandleTimeout                 called by /opt/fhem/fhem.pl (649)
2018.09.05 12:02:24.498 1: PERL WARNING: Use of uninitialized value $name in concatenation (.) or string at /opt/fhem/fhem.pl line 4597.
2018.09.05 12:02:24.498 1: readingsUpdate(,AutoShuttersControl_Time_Sunset,20:06:10) missed to call readingsBeginUpdate first.
2018.09.05 12:02:24.498 1: stacktrace:
2018.09.05 12:02:24.498 1:     main::readingsBulkUpdate            called by ./FHEM/73_AutoShuttersControl.pm (683)
2018.09.05 12:02:24.498 1:     AutoShuttersControl::CreateSunRiseSetShuttersTimer called by ./FHEM/73_AutoShuttersControl.pm (706)
2018.09.05 12:02:24.498 1:     AutoShuttersControl::RenewSunRiseSetShuttersTimer called by /opt/fhem/fhem.pl (3134)
2018.09.05 12:02:24.498 1:     main::HandleTimeout                 called by /opt/fhem/fhem.pl (649)
2018.09.05 12:02:24.499 1: readingsUpdate(,AutoShuttersControl_Time_Sunrise,06:54:22) missed to call readingsBeginUpdate first.
2018.09.05 12:02:24.499 1: stacktrace:
2018.09.05 12:02:24.499 1:     main::readingsBulkUpdate            called by ./FHEM/73_AutoShuttersControl.pm (684)
2018.09.05 12:02:24.499 1:     AutoShuttersControl::CreateSunRiseSetShuttersTimer called by ./FHEM/73_AutoShuttersControl.pm (706)
2018.09.05 12:02:24.499 1:     AutoShuttersControl::RenewSunRiseSetShuttersTimer called by /opt/fhem/fhem.pl (3134)
2018.09.05 12:02:24.499 1:     main::HandleTimeout                 called by /opt/fhem/fhem.pl (649)
2018.09.05 12:02:24.499 1: PERL WARNING: Use of uninitialized value $d in hash element at /opt/fhem/fhem.pl line 4357.
2018.09.05 12:02:24.499 1: ERROR: empty name in readingsBeginUpdate
2018.09.05 12:02:24.499 1: stacktrace:
2018.09.05 12:02:24.499 1:     main::readingsBeginUpdate           called by /opt/fhem/fhem.pl (4742)
2018.09.05 12:02:24.499 1:     main::readingsSingleUpdate          called by ./FHEM/73_AutoShuttersControl.pm (694)
2018.09.05 12:02:24.499 1:     AutoShuttersControl::CreateSunRiseSetShuttersTimer called by ./FHEM/73_AutoShuttersControl.pm (706)
2018.09.05 12:02:24.499 1:     AutoShuttersControl::RenewSunRiseSetShuttersTimer called by /opt/fhem/fhem.pl (3134)
2018.09.05 12:02:24.499 1:     main::HandleTimeout                 called by /opt/fhem/fhem.pl (649)
2018.09.05 12:02:24.499 1: readingsUpdate(,.AutoShuttersControl_InternalTimerFuncHash,HASH(0x55aa76110b60)) missed to call readingsBeginUpdate first.
2018.09.05 12:02:24.499 1: stacktrace:
2018.09.05 12:02:24.499 1:     main::readingsBulkUpdate            called by /opt/fhem/fhem.pl (4743)
2018.09.05 12:02:24.499 1:     main::readingsSingleUpdate          called by ./FHEM/73_AutoShuttersControl.pm (694)
2018.09.05 12:02:24.499 1:     AutoShuttersControl::CreateSunRiseSetShuttersTimer called by ./FHEM/73_AutoShuttersControl.pm (706)
2018.09.05 12:02:24.499 1:     AutoShuttersControl::RenewSunRiseSetShuttersTimer called by /opt/fhem/fhem.pl (3134)
2018.09.05 12:02:24.499 1:     main::HandleTimeout                 called by /opt/fhem/fhem.pl (649)
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 05 September 2018, 12:17:57
Zitat von: FunkOdyssey am 05 September 2018, 12:08:12
Ich kann das Modul irgendwie immer noch nicht richtig nutzen:


Ich lege ASC an:
define Rolladensteuerung AutoShuttersControl

Dann setze ich das AutoShuttersControl auf 1 in einer Test-Jalousie und führe anschließend einen "scanForShutters" aus.
Die Test-Jalousie habe ich diesmal nur in einem Raum "Jalousien". Daran liegt es also wirklich nicht.
Es erscheint ein Stracktrace. Und die Liste der userattr ist nicht vollständig. Es kommen nur zwei/drei ASC-Attribute an. Das passiert auch, wenn das userattr vorher leer war.

Scheinbar kommt der Stracktrace, da Readings aktualisiert werden sollen, für die userattr standardgemäß gesetzt sein sollten. Diese sind bei mir aber nie angekommen.


2018.09.05 12:01:43.169 3: AutoShuttersControl (Rolladensteuerung) - defined
2018.09.05 12:01:46.808 5: AutoShuttersControl (Rolladensteuerung) - Devname: global Name: Rolladensteuerung Notify: [
  'ATTR Rolladensteuerung verbose 5'
]

2018.09.05 12:01:53.139 1: PERL WARNING: Use of uninitialized value $value in string eq at /opt/fhem/fhem.pl line 4578.
2018.09.05 12:02:09.617 5: AutoShuttersControl (Rolladensteuerung) - Devname: global Name: Rolladensteuerung Notify: [
  'ATTR jal_buegeln AutoShuttersControl 1'
]

2018.09.05 12:02:19.409 4: AutoShuttersControl (Rolladensteuerung) - ShuttersList: jal_buegeln
2018.09.05 12:02:19.421 5: AutoShuttersControl (Rolladensteuerung) - Devname: Rolladensteuerung Name: Rolladensteuerung Notify: [
  'userAttrList: rolled out'
]

2018.09.05 12:02:19.434 5: AutoShuttersControl (Rolladensteuerung) - Devname: global Name: Rolladensteuerung Notify: [
  'ATTR jal_buegeln AutoShuttersControl_Offset_Minutes_Evening 1'
]

2018.09.05 12:02:19.441 3: Please define Jalousien first
2018.09.05 12:02:19.442 3: Please define Jalousien first
2018.09.05 12:02:19.444 3: Please define Jalousien first
2018.09.05 12:02:19.446 3: Please define Jalousien first
2018.09.05 12:02:19.447 3: Please define Jalousien first
2018.09.05 12:02:19.449 3: Please define Jalousien first
2018.09.05 12:02:19.451 3: Please define Jalousien first
2018.09.05 12:02:19.452 3: Please define Jalousien first
2018.09.05 12:02:19.454 3: Please define Jalousien first
2018.09.05 12:02:19.455 3: Please define Jalousien first
2018.09.05 12:02:19.457 3: Please define Jalousien first
2018.09.05 12:02:19.459 3: Please define Jalousien first
2018.09.05 12:02:19.460 3: Please define Jalousien first
2018.09.05 12:02:19.462 3: Please define Jalousien first
2018.09.05 12:02:19.463 3: Please define Jalousien first
2018.09.05 12:02:19.465 3: Please define Jalousien first
2018.09.05 12:02:19.467 3: Please define Jalousien first
2018.09.05 12:02:19.468 3: Please define Jalousien first
2018.09.05 12:02:19.470 3: Please define Jalousien first
2018.09.05 12:02:19.472 3: Please define Jalousien first
2018.09.05 12:02:19.473 3: Please define Jalousien first
2018.09.05 12:02:19.475 3: Please define Jalousien first
2018.09.05 12:02:19.477 3: Please define Jalousien first
2018.09.05 12:02:19.478 3: Please define Jalousien first
2018.09.05 12:02:19.480 3: Please define Jalousien first
2018.09.05 12:02:19.482 3: Please define Jalousien first
2018.09.05 12:02:19.484 3: Please define Jalousien first
2018.09.05 12:02:19.485 3: Please define Jalousien first
2018.09.05 12:02:19.487 3: Please define Jalousien first
2018.09.05 12:02:19.489 3: Please define Jalousien first
2018.09.05 12:02:19.490 3: Please define Jalousien first
2018.09.05 12:02:19.492 3: Please define Jalousien first
2018.09.05 12:02:19.494 3: Please define Jalousien first
2018.09.05 12:02:19.496 3: Please define Jalousien first
2018.09.05 12:02:24.497 1: ERROR: empty name in readingsBeginUpdate
2018.09.05 12:02:24.497 1: stacktrace:
2018.09.05 12:02:24.497 1:     main::readingsBeginUpdate           called by ./FHEM/73_AutoShuttersControl.pm (681)
2018.09.05 12:02:24.497 1:     AutoShuttersControl::CreateSunRiseSetShuttersTimer called by ./FHEM/73_AutoShuttersControl.pm (706)
2018.09.05 12:02:24.497 1:     AutoShuttersControl::RenewSunRiseSetShuttersTimer called by /opt/fhem/fhem.pl (3134)
2018.09.05 12:02:24.497 1:     main::HandleTimeout                 called by /opt/fhem/fhem.pl (649)
2018.09.05 12:02:24.498 1: PERL WARNING: Use of uninitialized value $name in concatenation (.) or string at /opt/fhem/fhem.pl line 4597.
2018.09.05 12:02:24.498 1: readingsUpdate(,AutoShuttersControl_Time_Sunset,20:06:10) missed to call readingsBeginUpdate first.
2018.09.05 12:02:24.498 1: stacktrace:
2018.09.05 12:02:24.498 1:     main::readingsBulkUpdate            called by ./FHEM/73_AutoShuttersControl.pm (683)
2018.09.05 12:02:24.498 1:     AutoShuttersControl::CreateSunRiseSetShuttersTimer called by ./FHEM/73_AutoShuttersControl.pm (706)
2018.09.05 12:02:24.498 1:     AutoShuttersControl::RenewSunRiseSetShuttersTimer called by /opt/fhem/fhem.pl (3134)
2018.09.05 12:02:24.498 1:     main::HandleTimeout                 called by /opt/fhem/fhem.pl (649)
2018.09.05 12:02:24.499 1: readingsUpdate(,AutoShuttersControl_Time_Sunrise,06:54:22) missed to call readingsBeginUpdate first.
2018.09.05 12:02:24.499 1: stacktrace:
2018.09.05 12:02:24.499 1:     main::readingsBulkUpdate            called by ./FHEM/73_AutoShuttersControl.pm (684)
2018.09.05 12:02:24.499 1:     AutoShuttersControl::CreateSunRiseSetShuttersTimer called by ./FHEM/73_AutoShuttersControl.pm (706)
2018.09.05 12:02:24.499 1:     AutoShuttersControl::RenewSunRiseSetShuttersTimer called by /opt/fhem/fhem.pl (3134)
2018.09.05 12:02:24.499 1:     main::HandleTimeout                 called by /opt/fhem/fhem.pl (649)
2018.09.05 12:02:24.499 1: PERL WARNING: Use of uninitialized value $d in hash element at /opt/fhem/fhem.pl line 4357.
2018.09.05 12:02:24.499 1: ERROR: empty name in readingsBeginUpdate
2018.09.05 12:02:24.499 1: stacktrace:
2018.09.05 12:02:24.499 1:     main::readingsBeginUpdate           called by /opt/fhem/fhem.pl (4742)
2018.09.05 12:02:24.499 1:     main::readingsSingleUpdate          called by ./FHEM/73_AutoShuttersControl.pm (694)
2018.09.05 12:02:24.499 1:     AutoShuttersControl::CreateSunRiseSetShuttersTimer called by ./FHEM/73_AutoShuttersControl.pm (706)
2018.09.05 12:02:24.499 1:     AutoShuttersControl::RenewSunRiseSetShuttersTimer called by /opt/fhem/fhem.pl (3134)
2018.09.05 12:02:24.499 1:     main::HandleTimeout                 called by /opt/fhem/fhem.pl (649)
2018.09.05 12:02:24.499 1: readingsUpdate(,.AutoShuttersControl_InternalTimerFuncHash,HASH(0x55aa76110b60)) missed to call readingsBeginUpdate first.
2018.09.05 12:02:24.499 1: stacktrace:
2018.09.05 12:02:24.499 1:     main::readingsBulkUpdate            called by /opt/fhem/fhem.pl (4743)
2018.09.05 12:02:24.499 1:     main::readingsSingleUpdate          called by ./FHEM/73_AutoShuttersControl.pm (694)
2018.09.05 12:02:24.499 1:     AutoShuttersControl::CreateSunRiseSetShuttersTimer called by ./FHEM/73_AutoShuttersControl.pm (706)
2018.09.05 12:02:24.499 1:     AutoShuttersControl::RenewSunRiseSetShuttersTimer called by /opt/fhem/fhem.pl (3134)
2018.09.05 12:02:24.499 1:     main::HandleTimeout                 called by /opt/fhem/fhem.pl (649)



Na sage mal, das ist aber seltsam.
Hast Du ein Update von FHEM heute morgen gemacht? Wenn nicht bitte machen. Hast Du verbose auf 5 im ASC Device gemacht, wenn nicht hast Du eine falsche Modulversion. Bitte Fragen beantworten.
Und bitte stelle erstmal nur Attribute um die im ersten Post dokumentiert sind. Alles andere wird noch nicht beachtet.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 05 September 2018, 12:19:46
@all

Ich habe soeben eine Abfrage eingebaut, so das der neu berechnete Timerzeitpunkt immer am Folgetag sein muß.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: FunkOdyssey am 05 September 2018, 12:26:30
Zitat von: CoolTux am 05 September 2018, 12:17:57

Na sage mal, das ist aber seltsam.
Hast Du ein Update von FHEM heute morgen gemacht? Wenn nicht bitte machen. Hast Du verbose auf 5 im ASC Device gemacht, wenn nicht hast Du eine falsche Modulversion. Bitte Fragen beantworten.
Und bitte stelle erstmal nur Attribute um die im ersten Post dokumentiert sind. Alles andere wird noch nicht beachtet.

- FHEM ist aktuell.
- Dein Modul ist aktuell.
- verbose 5 hatte ich gesetzt. Sieht man auch im CODE-Tag oben.
- Ich habe nicht ein einziges Attribut (Ausnahme AutoShuttersControl=1) gesetzt. Es sind ja keine wirklich verwertbaren ASC-userattr im Device angekommen sind.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 05 September 2018, 12:39:56
Gib mir mal bitte ein List von 2 Deiner Rolläden.

Noch mal kurz zum festhalten. Du definierst das ASC Device, danach vergibst Du an Deine Rolläden das Attribut AutoShuttersControl mit Wert 1 und dann machst Du ein set scanForShutters. Hast Du das so gemacht?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: FunkOdyssey am 05 September 2018, 14:11:24
Genau.

List per PN.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 05 September 2018, 15:48:52
Fertig. Commandref für die aktuelle Version steht.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: FunkOdyssey am 05 September 2018, 15:52:37
ASC wäre doch richtig, oder? Nicht ACS?  :)
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Papaloewe am 05 September 2018, 16:10:29
Super, endlich ein Modul dafür.  ;)

Habe ich etwas überlesen, oder gibt es zur Zeit noch keine Wochentags- Feiertags-, Ferien-Berücksichtigung?

Gruß Thomas
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 05 September 2018, 16:13:01
Zitat von: FunkOdyssey am 05 September 2018, 15:52:37
ASC wäre doch richtig, oder? Nicht ACS?  :)

Jepp. Gut aufgepasst. Danke
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 05 September 2018, 19:53:08
Zitat von: Papaloewe am 05 September 2018, 16:10:29
Super, endlich ein Modul dafür.  ;)

Habe ich etwas überlesen, oder gibt es zur Zeit noch keine Wochentags- Feiertags-, Ferien-Berücksichtigung?

Gruß Thomas

Hallo Thomas,

Aktuell ist noch keine Kalenderunterstützung implementiert.


Grüße
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Benni am 05 September 2018, 20:23:13

Zitat von: CoolTux am 05 September 2018, 16:13:01
Zitat von: FunkOdyssey am 05 September 2018, 15:52:37
ASC wäre doch richtig, oder? Nicht ACS?  :)

Zitat von: CoolTux am 05 September 2018, 16:13:01
Jepp. Gut aufgepasst. Danke

Hier noch eine Zwischenfrage von den Mitlesern aus der letzten Reihe  ;D:

Wäre es der Übersicht nicht dienlicher, dieses Kürzel auch als Präfix für die Readings und die Attribute zu nehmen? "AutoShutterControl_" finde ich schon ziemlich lange, wenn auch zugegebenermaßen eindeutiger  ???

gb#
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 05 September 2018, 20:27:28
Zitat von: Benni am 05 September 2018, 20:23:13


Hier noch eine Zwischenfrage von den Mitlesern aus der letzten Reihe  ;D:

Wäre es der Übersicht nicht dienlicher, dieses Kürzel auch als Präfix für die Readings und die Attribute zu nehmen? "AutoShutterControl_" finde ich schon ziemlich lange, wenn auch zugegebenermaßen eindeutiger  ???

gb#

Die Idee finde ich gut, Problem. Bei 3 Buchstaben ist die Möglichkeit groß daß es das schon gibt.
Ansonsten würde ich Dir aber Recht geben.
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: CoolTux am 05 September 2018, 22:00:54
Zitat von: Beta-User am 05 September 2018, 10:33:46

Zu dem Zusammenfassen mehrerer Presence-Devices als Hilfsmittel noch eine RAW-Definition für eine Structure:
define rr_Parents structure eltern rr_Mann rr_Frau
attr rr_Parents clientstate_behavior relative
attr rr_Parents clientstate_priority asleep gotosleep awoken home absent
attr rr_Parents group Persons
attr rr_Parents icon user_unknown
attr rr_Parents room Steuerung
attr rr_Parents userReadings lastState:(home|awoken|asleep|gotosleep|absent) { OldValue($name) }
und als Muster ein Weekdaytimer für meinen "Mann"-Dummy, damit der sich erst mal "bewegt". Gibt's in ähnlicher Form auch für

Hier würde ich eher sowas empfehlen

userReadings
attr rr_Parents userReadings lastState:(home|awoken|gotosleep|asleep|absent) { ReadingsVal(ReadingsVal($name,'LastDevice','none'),'lastState','none') }
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 05 September 2018, 22:14:21
Habe mir gerade das Thema Wochenende, Ferien und Feiertag angeschaut. Das ist ja im Script doch Recht einfach gelöst. Quasi für alles. Aber nun heißst es ja nicht das wenn ich Urlaub habe, meine Tochter nicht aufstehen muß wenn sie Schule hat. Also sollte Ihr Rollo schon noch hochfahren wenn die Sonne auf ist.


Wenn man sich das ganze auf Basis vom Residentsmodul an schaut ist das eh einfacher. Die Rolladen fährt erst wenn meine Tochter auf awoken oder home steht. Das passiert automatisch wenn Ihr Wecker klingelt.
Daher frage ich mich ob das mit dem Kalender überhaupt Sinn macht.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: marvin78 am 06 September 2018, 06:58:45
Das kommt wohl auf die Struktur des Haushalts, der Familie und die Räume an. Nicht jeder Rollladen hängt in einem Schlafzimmer. Bestimmte Rollläden möchte man ggf. anders öffnen.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 06 September 2018, 08:05:05
Moin,
kann sein, dass dsa auch an irgendwas anderem lag, aber evtl. ist das sehr unschön, daher die Bitte um Prüfung, ob der aktuelle Code nicht bei der Erstellung der Timer in eine Dauerschleife läuft:

Habe heute frühmorgens die pm getauscht und einen reload durchgeführt.

Danach schien erst mal alles normal zu sein (habe noch an einen der wdt was geändert). Nachdem dann die Rolläden heute morgen nicht gefahren sind, ergab ein Blick ins log tausende Einträge mit dem Muster:

2018.09.06 07:30:52 2: AutoShuttersControl (Rolladenautomatik) - CreateSunRiseSetShuttersTimer, neuer Sunset: 1 neuer Sunrise: 1
2018.09.06 07:30:53 2: AutoShuttersControl (Rolladenautomatik) - CreateSunRiseSetShuttersTimer, neuer Sunset: 1 neuer Sunrise: 1

Kann auch an irgendwas liegen, was ich drumrum gemacht habe... Habe die pm jetzt erst mal umbenannt.

Gruß, Beta-User
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 06 September 2018, 08:28:44
Zitat von: Beta-User am 06 September 2018, 08:05:05
Moin,
kann sein, dass dsa auch an irgendwas anderem lag, aber evtl. ist das sehr unschön, daher die Bitte um Prüfung, ob der aktuelle Code nicht bei der Erstellung der Timer in eine Dauerschleife läuft:

Habe heute frühmorgens die pm getauscht und einen reload durchgeführt.

Danach schien erst mal alles normal zu sein (habe noch an einen der wdt was geändert). Nachdem dann die Rolläden heute morgen nicht gefahren sind, ergab ein Blick ins log tausende Einträge mit dem Muster:

2018.09.06 07:30:52 2: AutoShuttersControl (Rolladenautomatik) - CreateSunRiseSetShuttersTimer, neuer Sunset: 1 neuer Sunrise: 1
2018.09.06 07:30:53 2: AutoShuttersControl (Rolladenautomatik) - CreateSunRiseSetShuttersTimer, neuer Sunset: 1 neuer Sunrise: 1

Kann auch an irgendwas liegen, was ich drumrum gemacht habe... Habe die pm jetzt erst mal umbenannt.

Gruß, Beta-User

Ja läuft er, die Beobachtung hatte ich auch. Schuld ist die structure welche alle seine Attribute an die Roomate Dummys weiter reicht.  War zu mindest bei mir so. Kontrolliere bitte einmal Deine structure und Deine roomate Dummys.
Am besten ein List hier rein werfen. Ich hab es auch erst heute morgen mitbekommen. Und erst nachdem ich die strukture gestern Abend angelegt hatte.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 06 September 2018, 08:48:14
Ok Vergiss meine Aussage, das war es wohl nicht.

Es ist der Timer. Wenn die Zeit für den Timer in der Vergangenheit liegt dann passiert genau das. Jetzt muss ich nur noch finden wieso er Daten aus der Vergangenheit bekommt.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 06 September 2018, 09:04:55
Ich habe auf Github eine HotFix Version eingespielt welche die Dauerschleife verhindert. Bitte unbedingt einspielen bis ich das Problem an sich identifiziert habe.


Sorry
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: kjmEjfu am 06 September 2018, 09:29:42
Zitat von: CoolTux am 05 September 2018, 22:14:21
Habe mir gerade das Thema Wochenende, Ferien und Feiertag angeschaut. Das ist ja im Script doch Recht einfach gelöst. Quasi für alles. Aber nun heißst es ja nicht das wenn ich Urlaub habe, meine Tochter nicht aufstehen muß wenn sie Schule hat. Also sollte Ihr Rollo schon noch hochfahren wenn die Sonne auf ist.


Wenn man sich das ganze auf Basis vom Residentsmodul an schaut ist das eh einfacher. Die Rolladen fährt erst wenn meine Tochter auf awoken oder home steht. Das passiert automatisch wenn Ihr Wecker klingelt.
Daher frage ich mich ob das mit dem Kalender überhaupt Sinn macht.

Ich bin da, wenig überraschend, für weitgehende Flexibilität. Sprich grundsätzlich die Attribute am ASC-Device allgemeingültig haben, aber mit der Möglichkeit die in allen Rolladen-Devices zu überschreiben. Dadurch lassen sich dann alle Möglichkeiten, die man sich nur irgendwie ausdenken mag, entsprechend umsetzen.

Derzeit (Nutzung vom Cluni Quellcode) habe ich auch awoken und asleep eingebunden, lasse aber bei Wechseln in einen dieser Status einfach nur Zeit vom jeweiligen at (Rollo_hoch bzw. Rollo_runter) auf jetzt plus zwei Sekunden setzen. (Wobei ich auch noch die Uhrzeit abfrage, damit die Kinder nicht mitten in der Nacht die Rollos in ihren Zimmern hochfahren können, weil sie meinen jetzt wach zu sein ;-)
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 06 September 2018, 09:48:03
Danke für die schnelle Analyse.

Im Moment ist die Moduldatei umbenannt und läuft daher nicht, reaktivieren folgt dann heute abend.



Was den Nebenschauplatz structure angeht:
a) Es dürfte in der Tat so sein, dass das userreading dazu führt, dass der eigentlich nur für die structure gedachte Wert für lastState wieder an die beteiligten Devices zurückvererbt wird. Das ist wenig zielführend  :( - unabhängig von der Frage, welcher Inhalt denn eigentlich der richtige ist.

Evtl. könnte man auf "setreading" ausweichen, wenn nicht wäre der Vorschlag dazu: (Mind. hier) die OldReadings-Mechanismen (über das attribut "attr <structure> oldreadings state") nutzen. Im Ergebnis würde man also bei den roommate-Devices immer erst nach lastState sehen. Ist das undef: OldReadingsVal(<structure>,'state',"unknown").

b) Es leuchtet mir noch nicht so richtig ein, wieso der lastState aus dem letzten triggernden Device aktualisiert werden soll, wenn sich der Wert der structure dadurch nicht ändert. Also: Mann ist zuhause, Frau absent => structure: home. Mann geht ins Bett => structure asleep mit lastState home (egal, ob von Mann oder structure). Frau kommt nach Hause. structure => weiterhin asleep, aber da ein Reading sich geändert hat, wird userreading getriggert. ABER eigentlich stimmt _kein_ Ergebnis: structure war schon asleep => falsch, Frau war absent => auch m.E. nicht richtig.

Irgendwie beschleicht mich der Verdacht, dass userreadings hier nicht das Gelbe vom Ei ist und man vermutlich stattdessen ein notify auf den state der structure(s) legen und damit ein setreading ausführen sollte (in dem Rahmen sollte es auch nicht triggern, oder?).

Gruß, Beta-User
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 06 September 2018, 10:11:01
Ich habe einfach alle Attribute aus den Dummys gelöscht die von der structure kamen und dann ging es. Es kommt zwar wieder nach einem neustart etwas dazu, aber nicht das ändern des userreadings.

Leider bin ich gedanklich nicht bei der Sache was Deine Fragen an geht Ich möchte schnellst möglich erstmal den Fehler finden für die Dauerschleife  :-[
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 06 September 2018, 10:36:54
Danke für die Rückmeldung, sonst hätte ich vermutlich nicht bemerkt, dass die structure natürlich bei Setzen ihre userreadings-Funktion an die Devices vererbt, und da macht sie keinen Sinn... Mist :( .
Werde mal den Test mit dem notify machen (sieht mir eh' zielführender aus) und dann berichten, wird aber dauern.

Laß dich nicht stressen durch diese Nebenthemen :) .
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 06 September 2018, 11:53:28
So Ihr Lieben,

Ich habe den Fehler gefunden. War etwas arbeit. Es gibt im Github eine neue Version. Ich habe hoch und runter getestet, es kommt zu mindest nicht mehr zum loop, und eigentlich sollten auch die Zeiten korrekt berechnet werden. Aber das sehen wir dann erst morgen früh.

Ich empfehle allen Testern das Update zu machen.


Grüße
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 06 September 2018, 14:04:48
Ich habe eben noch eine neue Version ins Git geschupst, eingebaut ist nun eine Comfort Steuerung, bedeutet sofern Ihr einen Threestate Sensor habt (Fensterdrehgriff) und Ihr das Fenster oder die Tür öffnet fährt der Rolladen in die hohe Comfort Position. Also fast auf.
Attribute muß ich noch dokumentieren

Im Moduldevice
AutoShuttersControl_autoShuttersControlComfort:on,off auf on

und im Rolladendevice
AutoShuttersControl_Pos_after_ComfortOpen auf eine hohe Öffnung einstellen. Default ist schon gesetzt
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: tatu123 am 06 September 2018, 15:59:59
Jetzt ist ein Syntaxfehler in Zeile 879 die öffnende Klammer fehlt zwischen elseif und ReadingsVal

Viele Grüße
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 06 September 2018, 16:17:31
Zitat von: tatu123 am 06 September 2018, 15:59:59
Jetzt ist ein Syntaxfehler in Zeile 879 die öffnende Klammer fehlt zwischen elseif und ReadingsVal

Viele Grüße

Danke schaue ich mir heute Abend an. Seltsam hatte eigentlich vorher getestet. Aber kriegen wir hin.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 06 September 2018, 16:21:06
Zitat von: tatu123 am 06 September 2018, 15:59:59
Jetzt ist ein Syntaxfehler in Zeile 879 die öffnende Klammer fehlt zwischen elseif und ReadingsVal

Viele Grüße

Ich habe eben Mal schnell geschaut. Kann nicht sein. Daran habe ich seit Versionen nichts mehr gemacht. Entweder ist der Fehler vorher und er meldet es erst ab da, oder beim Datei holen ist was schief gelaufen. Ich schaue heute Abend.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: tatu123 am 06 September 2018, 16:44:11
mmmhhh Stimmt. Hab gerade noch mal im GitHub geschaut. Da ist die Klamme.

Das ein Klammer beim kopieren irgend wo verschwindet ist mir auch noch nicht passiert. MAGIE -> Technik die Begeistert

Wer mal weiter einrichten.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: FunkOdyssey am 06 September 2018, 16:46:17
Hast du die Datei "73_*.pm" über die Weboberfläche aktualisiert? Oder über ne Linux-Bash?
Ich hatte schon einmal eher das Problem, dass das POST des Form-Tags bei der Bearbeitung nicht vollständig übergekommen ist.
Aber die Dateigröße des Moduls sollte es noch zulassen. Nur bei DOIF würde ich das nicht machen.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 06 September 2018, 21:21:36
So, aktuelle Version des Moduls ist wieder geladen, Danke für die Riesenarbeit, die du da reinsteckst!

Die structure sieht jetzt übrigens so aus:
defmod rr_Parents structure eltern rr_Mann rr_Frau
attr rr_Parents clientstate_behavior relative
attr rr_Parents clientstate_priority asleep gotosleep awoken home absent
attr rr_Parents event-on-change-reading .*


oldState setzt ein notify:
defmod rr_Parents_notify_oldState notify rr_Parents:.* rr_Parents:state:.* {my $oldState = OldValue($NAME);; fhem "setreading $NAME oldState $oldState"}
attr rr_Parents_notify_oldState addStateEvent 1

EDIT: Def geändert...

Schönen Abend zusammen,

Beta-User
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 06 September 2018, 23:05:42
Ich habe soeben eine aktuelle Version ins Git geladen. Version 0.1.26.
Ein fettes Danke geht an FunkOdyssey für seine unendliche Geduld beim finden eines unglaublichen Bugs.
Natürlich Danke ich auch allen mutigen Testern. Ohne Euch würde sowas nie so schnell am laufen sein.


Grüße
Leon
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Papaloewe am 07 September 2018, 08:31:40
Auch ein ganz, ganz fettes Dankeschön von meiner Seite an alle Mitwirkende!!!

Nur ein kleiner Vorschlag.

Ich finde ganz viele Userattribute, bin dann aber nicht sicher, ob die Funktion dahinter schon implementiert ist.
Das macht es den nicht ganz so versierten Tester, die nicht im Code nachshen können (wie ich), etwas schwer.
Könntest du nicht eine kleine Tabelle pflegen mit den Attributen, die schon funktionieren sollten und denen, die nur schonmal für die spätere Funktion vorgesehen werden.

Noch ganz konkret:
Es gibt ein Attribut zum Thema Brigfhtness. Ich finde aber nicht das passende Gegenstück dafür um das Brightness-Device zu definieren?

Gruß
Thomas
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 07 September 2018, 08:41:25
Zitat von: Papaloewe am 07 September 2018, 08:31:40
Auch ein ganz, ganz fettes Dankeschön von meiner Seite an alle Mitwirkende!!!

Nur ein kleiner Vorschlag.

Ich finde ganz viele Userattribute, bin dann aber nicht sicher, ob die Funktion dahinter schon implementiert ist.
Das macht es den nicht ganz so versierten Tester, die nicht im Code nachshen können (wie ich), etwas schwer.
Könntest du nicht eine kleine Tabelle pflegen mit den Attributen, die schon funktionieren sollten und denen, die nur schonmal für die spätere Funktion vorgesehen werden.

Noch ganz konkret:
Es gibt ein Attribut zum Thema Brigfhtness. Ich finde aber nicht das passende Gegenstück dafür um das Brightness-Device zu definieren?

Gruß
Thomas

Hallo Thomas,

Die Commandref im Modul spiegelt den aktuellen Entwicklungensstand wieder.
Das Device für Brightness wird im Moduldevice vergeben.


Grüße
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: pc1246 am 07 September 2018, 13:04:55
Moin
Mitles, und evtl. mittest!
Gruss Christoph
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 07 September 2018, 14:52:38
Ich habe einige Readings im Modul-Device hinzugefügt. Neue Version gibt es auf Github.
Version 0.1.31



Grüße
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 07 September 2018, 18:56:03
Mei, geht das voran, eben dachte ich noch, dass es doch schön wäre, die Timer nicht nur im list zu sehen, und schon isses so ;D ...

Super Sache! :)

Was mir noch aufgefallen ist, nachdem ich jetzt dann das eine oder andere an Spielereien mal angehen wollte:
Eben fand ich es unnötig kompliziert, für die Temperatur Sensor und Reading getrennt setzen zu müssen; "MYSENSOR_97:temperature2" in einem einzigen Attribut finde ich persönlich übersichtlicher.

ZitatDas Device für Brightness wird im Moduldevice vergeben.
Das habe ich eben auch nicht gefunden; auch hier würe mir die Schreibweise "Device:reading" (oder "device reading") entgegenkommen.

Generell wollte ich nochmal nachfragen, ob es angedacht ist, default-Werte für die Attribute aus dem Moduldevice zu nehmen; insbesondere dann wäre es für die Übersichtlichtḱeit besser, die Menge der Attribute auch dort einzugrenzen.

Schönen Abend jedenfalls,

Beta-User
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Papaloewe am 07 September 2018, 19:49:40
Hallo Leon,

in der aktuellen Version des Rollo-Moduls heißt das Kommando zum Fahren des Rolladen, bzw. der Jalousie jetzt auch "pct" und nicht mehr "position".
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 07 September 2018, 20:28:47
Zitat von: Papaloewe am 07 September 2018, 19:49:40
Hallo Leon,

in der aktuellen Version des Rollo-Moduls heißt das Kommando zum Fahren des Rolladen, bzw. der Jalousie jetzt auch "pct" und nicht mehr "position".

Alles klar. Das macht nichts. Ich schaue nur wegen der Anleitung ob ich da einen Verweis habe. Ansonsten einfach bei AutoShuttersControl die 2 mit angeben.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 07 September 2018, 20:37:19
Zitat von: Beta-User am 07 September 2018, 18:56:03
Mei, geht das voran, eben dachte ich noch, dass es doch schön wäre, die Timer nicht nur im list zu sehen, und schon isses so ;D ...

Super Sache! :)

Was mir noch aufgefallen ist, nachdem ich jetzt dann das eine oder andere an Spielereien mal angehen wollte:
Eben fand ich es unnötig kompliziert, für die Temperatur Sensor und Reading getrennt setzen zu müssen; "MYSENSOR_97:temperature2" in einem einzigen Attribut finde ich persönlich übersichtlicher.
Für mich ist das einfacher so wie es ist. So habe ich weniger Aufwand beim Code




Zitat von: Beta-User am 07 September 2018, 18:56:03
Das habe ich eben auch nicht gefunden; auch hier würe mir die Schreibweise "Device:reading" (oder "device reading") entgegenkommen.

Stimmt, das ist auch im Rolladenmodul. Ist aber auch noch nicht aktiv. Alles was aktiv ist findet man in der commandref zum Modul.

Zitat von: Beta-User am 07 September 2018, 18:56:03
Generell wollte ich nochmal nachfragen, ob es angedacht ist, default-Werte für die Attribute aus dem Moduldevice zu nehmen; insbesondere dann wäre es für die Übersichtlichtḱeit besser, die Menge der Attribute auch dort einzugrenzen.

Wie meinst das mit den default Werten? Die Werte müssen ja dahin wo das Attribut ist und das ist im Rolladen.

Ich wünsche auch einen schönen Abend.
Und schreibt mal was zur generellen Betrieb. Wie ist es beim Fenster auf oder gekippt. Wie wenn Sonnenauf oder Untergang ist. Klappt bei Euch alles?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 07 September 2018, 21:02:48
Ich würde in einer nächsten Version gern

RolloKuecheLinks_nextAstroEvent

austauschen gegen

RolloKuecheLinks_nextAstroTimeEvent

da es ja auch feste Zeiten sein können, also kein Astro. Wäre das ok? Dann müsstet Ihr das alte Reading bitte von Hand löschen.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Prof. Dr. Peter Henning am 07 September 2018, 21:06:24
Das Löschen von veralteten Readings von Hand ist fehleranfällig. Bau doch temporären Code ins Modul, der das automatisch macht.

LG

pah
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 08 September 2018, 01:04:50
Zitat von: Prof. Dr. Peter Henning am 07 September 2018, 21:06:24
Das Löschen von veralteten Readings von Hand ist fehleranfällig. Bau doch temporären Code ins Modul, der das automatisch macht.

LG

pah

Ich wollte es mir sparen  :)
Aber hast ja Recht, so kann ich wenigstens sicher sein.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 08 September 2018, 10:23:04
Zitat von: CoolTux am 07 September 2018, 20:37:19
Für mich ist das einfacher so wie es ist. So habe ich weniger Aufwand beim Code
Hätte vermutet, dass zwei AttrVal() Funktionen drin sind, um zwei Variablen zu füllen. Wenn es so wäre, wäre doch  ein split auf ein AttrVal fast dasselbe (mal abgesehen von dem einmaligen Aufwand, den bestehenden Code zu ändern; aber dafür waren ja die Rückmeldungen da, um rauszufinden, was user denken, oder?).

Zitat von: CoolTux am 07 September 2018, 20:37:19
Wie meinst das mit den default Werten? Die Werte müssen ja dahin wo das Attribut ist und das ist im Rolladen.
Hatte ich neulich schon geschrieben, versuche das mal etwas zu konkretisieren:Heute holst du vermutlich den Wert für den einzelnen Rolladen schlicht aus dem Attribut (AttrVal()).
Dafür ist es zwingend, dass jeder Rolläden die ganzen Attribute nicht nur optional erhält, sondern diese mit Werten gesetzt sind.

Mein Vorschlag wäre, eine Funktion einzubauen, die nach einer gewissen Priorität mehrere Speichermöglichkeiten absucht. Nennen wir sie "readShutterSetting($$)", die man mit dem Namen des Rolladen sowie dem (heutigen) Attributnamen füttert. Die Speichermöglichkeiten sollten dann nacheinander gelesen werden, und beim ersten Treffer, der nicht undef ist, den Inhalt zurückliefern. Also in folgender Priorität:
- AttrVal() am Rolladen
- Attrval() am AutosShutterControl-Device (das war der default, den ich meinte)
- zuletzt könnte man noch ein paar Defaults in ein Array mit "Attributname1 => "Defaultwert1, usw." packen, dann könnte man auf das Ausrollen der vielen Attribute verzichten (natürlich müssen die userattr an die Rolläden, aber man müßte erst mal keine Werte setzen).

Unausgedacht: Eventuell könnte man auch ReadingsVal() (mind. am Device?) _zusätzlich_ nutzen, aber da bin ich mir nicht so klar, ob das nicht des guten zu viel ist. Jedenfalls ergäbe das sehr flexible Möglichkeiten für versierte Nutzer, auch zur Laufzeit manches zu beeinflussen (den Einwand, dass du nicht in fremde Devices schreiben magst, habe ich wahrgenommen; hier wäre dann die Frage, ob man das Reading-Set pro Rolladen am zentralen Steuerungs-Device pflegen kann).

Hoffentlich habe ich das jetzt einigermaßen nachvollziehbar erklärt...

Zitat von: CoolTux am 07 September 2018, 20:37:19
Und schreibt mal was zur generellen Betrieb. Wie ist es beim Fenster auf oder gekippt. Wie wenn Sonnenauf oder Untergang ist. Klappt bei Euch alles?
Auf und zu scheint zu klappen, auch abhängig vom Roommate-Status, ansonsten habe ich noch nicht alles ausprobiert. Aber du darfst sicher sein, dass du was hörst, wenn was nicht funktioniert ::) ...
Gruß, Beta-User
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 08 September 2018, 12:33:55
Zitat von: Beta-User am 08 September 2018, 10:23:04
Hätte vermutet, dass zwei AttrVal() Funktionen drin sind, um zwei Variablen zu füllen. Wenn es so wäre, wäre doch  ein split auf ein AttrVal fast dasselbe (mal abgesehen von dem einmaligen Aufwand, den bestehenden Code zu ändern; aber dafür waren ja die Rückmeldungen da, um rauszufinden, was user denken, oder?).

Ich kann es mir gerne noch mal anschauen.

Zitat von: Beta-User am 08 September 2018, 10:23:04
Hatte ich neulich schon geschrieben, versuche das mal etwas zu konkretisieren:Heute holst du vermutlich den Wert für den einzelnen Rolladen schlicht aus dem Attribut (AttrVal()).
Dafür ist es zwingend, dass jeder Rolläden die ganzen Attribute nicht nur optional erhält, sondern diese mit Werten gesetzt sind.

Nein nicht zwingend. Wenn die Funktion AttrVal kein Attribut auslesen kann kommt als Rückgabe der beim Funktionsaufruf übergebene 3 Parameter als default zurück.


Zitat von: Beta-User am 08 September 2018, 10:23:04
Mein Vorschlag wäre, eine Funktion einzubauen, die nach einer gewissen Priorität mehrere Speichermöglichkeiten absucht. Nennen wir sie "readShutterSetting($$)", die man mit dem Namen des Rolladen sowie dem (heutigen) Attributnamen füttert. Die Speichermöglichkeiten sollten dann nacheinander gelesen werden, und beim ersten Treffer, der nicht undef ist, den Inhalt zurückliefern. Also in folgender Priorität:
- AttrVal() am Rolladen
- Attrval() am AutosShutterControl-Device (das war der default, den ich meinte)
- zuletzt könnte man noch ein paar Defaults in ein Array mit "Attributname1 => "Defaultwert1, usw." packen, dann könnte man auf das Ausrollen der vielen Attribute verzichten (natürlich müssen die userattr an die Rolläden, aber man müßte erst mal keine Werte setzen).

Wir können das gerne für einen späteren Zeitpunkt festhalten. Das Abfragen wäre nicht die Sache, aber dann würden auch doppelte Attributnamen im Rollo und Moduldevice sein. Weil man entweder im Rollo sucht oder im Moduldevice.




Grüße
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 08 September 2018, 14:06:32
Zitat von: CoolTux am 08 September 2018, 12:33:55
Nein nicht zwingend. Wenn die Funktion AttrVal kein Attribut auslesen kann kommt als Rückgabe der beim Funktionsaufruf übergebene 3 Parameter als default zurück.
:o Ah, daran hatte ich gar nicht mehr gedacht... jetzt wird mir aber klar, warum du den Hinweis auf "default" bisher für unsinnig gehalten haben mußt - auf diese Art die defaults über den ganzen Code zu verteilen, wäre natürlich Murks...


Zitat von: CoolTux am 08 September 2018, 12:33:55Ich kann es mir gerne noch mal anschauen.
Danke, ist aber wirklich nur eine Nebensache.

Zitat von: CoolTux am 08 September 2018, 12:33:55Wir können das gerne für einen späteren Zeitpunkt festhalten. Das Abfragen wäre nicht die Sache, aber dann würden auch doppelte Attributnamen im Rollo und Moduldevice sein. Weil man entweder im Rollo sucht oder im Moduldevice.
Ja, wobei man natürlich auch im Modul selbst ein anderes Präfix verwenden könnte, z.B. "default_Time_Up_Early" - wäre evtl. für die User einfacher zu durchschauen, und die Funktion könne man trotzdem generalisieren, weil man ja eigentlich nur den hinteren Teil ("Time_Up_Early") an die Funktion übergeben könnte und den Rest im Funktionscode ergänzen.

Und ja, muß nicht gleich sein, reicht auch später noch; bei diesem Punkt geht ja nicht um Funktionalität an sich, sondern Useability bzw. Einfachheit beim Einrichten (was mit der ReadingsGroup natürlich auch zu machen ist, aber je weniger man "drumrum" noch machen muß (nicht: kann), desto besser. .

Apropos ReadingsGroup: Muss es bei den Time-Angaben bei HH:MM:SS bleiben oder ginge auch HH:MM (ich hab's bisher nicht ausprobiert und auch den Code nicht untersucht). Schön wäre es, wenn das Modul (mittelfristig) beides nehmen würde (analog at).

Gruß, Beta-User
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 08 September 2018, 14:23:52
Zitat von: Beta-User am 08 September 2018, 14:06:32
Apropos ReadingsGroup: Muss es bei den Time-Angaben bei HH:MM:SS bleiben oder ginge auch HH:MM (ich hab's bisher nicht ausprobiert und auch den Code nicht untersucht). Schön wäre es, wenn das Modul (mittelfristig) beides nehmen würde (analog at).

Gruß, Beta-User

Zeiten setzen sollte jetzt schon ohne Sekunde gehen. Muss ich mal testen.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 08 September 2018, 15:10:41
Thx für die Info zu Zeiten, hab's eben getest: scheint zu funktionieren, DANKE!

ABER: Habe dazu das "set ... renew..." genutzt. Damit werden dann auch nachmittags die Timer für morgens gesetzt. Ist unschön, denn heute abend werden die Rolläden dann nicht fahren.
Wäre das auch bei einem Restart von FHEM so?

Einleuchtender fände ich es, wenn dann die aktuelle Soll-Position (aus dem letzten abgelaufenen Timer bzw. der Shading-Funktion) angefahren würde und zusätzlich (bzw. mind.) der nächste effektiv anstehende Timer gesetzt. Also Nachmittags dann die Schließ-Timer.




Habe eben noch etwas mit den Fensterkontakten gespielt; da ist mir manches nicht klar:

- Bei den in NOTIFYDEV genannten Fensterkontakten fehlen meine beiden den Jalousien zugeordneten Kontakte?
- Fährt man manuell zu, solange der FK open oder tilted meldet, passiert erstmal nichts.
OK, also verhindert das Modul nicht das manuelle Schließen. Verstanden, kommt dem WAF vermutlich sehr entgegen, Useraktionen haben Vorrang. Also: Wie ist das mit dem Aussperren an den Terrassentüren? Da ich die Terrassentür im Moment nicht prüfen kann (da ist eine Jalousie und der FK wird daher nicht überwacht), habe ich also das lock-out-Attribut bei einem der Fenster/Rolläden geändert auf "on". Scheint aber keine Auswirkung zu haben? Also Zustand open oder tilted iVm. Rolladen unten ist zulässig? Da stimmt m.E. was nicht (Kommt das von der "2-er" Logik, also 100=open?).

- Die Lüftungsposition wird bei threestates nur angefahren, wenn "tilted", oder? (Weiß noch nicht, ob ich das gut finde, oder die Option als Wunsch nennen, auch eine "offen"-Position anzugeben).

(- Überhaupt ist die Einrichterei der Fensterkontakte umständlich, aber das macht man ja auch nur ein Mal).

Wieder mal nur Eindrücke und spontane Gedanken ;) .
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 08 September 2018, 18:11:02
Zitat von: Beta-User am 08 September 2018, 15:10:41
Thx für die Info zu Zeiten, hab's eben getest: scheint zu funktionieren, DANKE!

ABER: Habe dazu das "set ... renew..." genutzt. Damit werden dann auch nachmittags die Timer für morgens gesetzt. Ist unschön, denn heute abend werden die Rolläden dann nicht fahren.
Wäre das auch bei einem Restart von FHEM so?

Einleuchtender fände ich es, wenn dann die aktuelle Soll-Position (aus dem letzten abgelaufenen Timer bzw. der Shading-Funktion) angefahren würde und zusätzlich (bzw. mind.) der nächste effektiv anstehende Timer gesetzt. Also Nachmittags dann die Schließ-Timer.




Habe eben noch etwas mit den Fensterkontakten gespielt; da ist mir manches nicht klar:

- Bei den in NOTIFYDEV genannten Fensterkontakten fehlen meine beiden den Jalousien zugeordneten Kontakte?
- Fährt man manuell zu, solange der FK open oder tilted meldet, passiert erstmal nichts.
OK, also verhindert das Modul nicht das manuelle Schließen. Verstanden, kommt dem WAF vermutlich sehr entgegen, Useraktionen haben Vorrang. Also: Wie ist das mit dem Aussperren an den Terrassentüren? Da ich die Terrassentür im Moment nicht prüfen kann (da ist eine Jalousie und der FK wird daher nicht überwacht), habe ich also das lock-out-Attribut bei einem der Fenster/Rolläden geändert auf "on". Scheint aber keine Auswirkung zu haben? Also Zustand open oder tilted iVm. Rolladen unten ist zulässig? Da stimmt m.E. was nicht (Kommt das von der "2-er" Logik, also 100=open?).

- Die Lüftungsposition wird bei threestates nur angefahren, wenn "tilted", oder? (Weiß noch nicht, ob ich das gut finde, oder die Option als Wunsch nennen, auch eine "offen"-Position anzugeben).

(- Überhaupt ist die Einrichterei der Fensterkontakte umständlich, aber das macht man ja auch nur ein Mal).

Wieder mal nur Eindrücke und spontane Gedanken ;) .
Gerade unterwegs daher kurz.
Sind die Jalousien mit im Moduldevice und und die Fenster nicht im NOTIFYDEV dann bitte einmal die Fensterdevice Attribute löschen und neu anlegen.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 08 September 2018, 19:58:21
Zitat von: Beta-User am 08 September 2018, 15:10:41
- Fährt man manuell zu, solange der FK open oder tilted meldet, passiert erstmal nichts.
OK, also verhindert das Modul nicht das manuelle Schließen. Verstanden, kommt dem WAF vermutlich sehr entgegen, Useraktionen haben Vorrang. Also: Wie ist das mit dem Aussperren an den Terrassentüren? Da ich die Terrassentür im Moment nicht prüfen kann (da ist eine Jalousie und der FK wird daher nicht überwacht), habe ich also das lock-out-Attribut bei einem der Fenster/Rolläden geändert auf "on". Scheint aber keine Auswirkung zu haben? Also Zustand open oder tilted iVm. Rolladen unten ist zulässig? Da stimmt m.E. was nicht (Kommt das von der "2-er" Logik, also 100=open?).

Ein manuelles fahren wird derzeit nicht verhindert. Lediglich Fahrbefehle welche über das Modul kommen richten sich nach dem Fensterkontakt.
Und natürlich wenn das Rollo unterhalb von Lüften Wert steht fährt das Modul beim kippen oder öffnen (twostate) das Rollo auf Lüften und schließt es beim schlieen wieder sofern immer noch die Lüftenposition vorhanden ist.


Zitat von: Beta-User am 08 September 2018, 15:10:41
- Die Lüftungsposition wird bei threestates nur angefahren, wenn "tilted", oder? (Weiß noch nicht, ob ich das gut finde, oder die Option als Wunsch nennen, auch eine "offen"-Position anzugeben).

ja genau. Macht sonst kein Sinn denke ich.



Grüße
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 08 September 2018, 21:36:26
Man kann wohl einige Rolladenaktoren Hardwaremäßig sperren.
set DEVICE inhibit on

oder

set DEVICE blocked

Kann mir jemand verraten ob es dazu auch Readings gibt. Finde dazu nichts.
Dann baue ich das so das wenn AutoShuttersControl_lock-out auf yes gesetzt ist ich das blockiere
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 09 September 2018, 05:04:54
Zitat von: CoolTux am 08 September 2018, 18:11:02
Sind die Jalousien mit im Moduldevice und und die Fenster nicht im NOTIFYDEV dann bitte einmal die Fensterdevice Attribute löschen und neu anlegen.
Beim ersten gemacht: Funktioniert.Beim zweiten habe ich dann nicht gelöscht, sondern einfach einen Buchstaben vom angegebenen FK gelöscht und dann wieder ergänzt. Funktioniert auch, allerdings habe ich jetzt auch den abgekürzten Fake-FK in der Liste des NOTIFYDEV. Der bleibt auch nach einem "set ... scan..." drin.

Probeweise weiter geändert, dann stehen alle drei Angaben im NOTIFYDEV.

Ist nicht wild, aber vermutlich auch nicht unbedingt erwünscht. 
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 09 September 2018, 05:30:11
Zitat von: CoolTux am 08 September 2018, 21:36:26
Man kann wohl einige Rolladenaktoren Hardwaremäßig sperren.
set DEVICE inhibit on

oder

set DEVICE blocked

Kann mir jemand verraten ob es dazu auch Readings gibt. Finde dazu nichts.
Dann baue ich das so das wenn AutoShuttersControl_lock-out auf yes gesetzt ist ich das blockiere
Bei den CUL_HM-Devices gibt es dann auch ein Reading namens inhibit, das auf "set_on" bzw. "set_off" geht.

ABER: m.E. wäre das keine gute Lösung.
Zum einen wäre damit ausgeschlossen, dass der Rolladen bei aktiviertem Aussperrschutz weiter geöffnet wird => Prognose: WAF = 0...

Und mal angenommen, der Rolladen ist oben. Dann kann entweder das inhibit mit Öffnen des FK gesetzt werden => Rolladen läßt sich nicht mal mehr auf zulässigen Level schließen. Oder die Fahrt müßte abgefangen werden,  beim vorgegebenen Level enden und das inhibit dann gesetzt werden.

Ausgeschlossen werden sollte nach meinem Gefühl nur, dass der Rolladen weiter geschlossen wird, und zwar ganz egal, von wo aus. Allerdings bin ich mir nicht so recht sicher, was denn nun wirklich das gewünschte Verhalten ist. Denn andererseits beißt sich das mit dem Grundsatz, dass Usereingriffe immer Vorrang haben sollten...


"Interessant" wird das ganze vor allem, weil es hier in meinem Fall auch um Jalousien geht, allerdings an einem Rolladenaktor (die Jalousievariante gab es damals noch nicht). Kommt die für Beschatten von unten, müßte man eigentlich zusätzlich noch die Lamellen drehen, was konkret bedeutet, dass sie zuerst 3 Punkte zu weit nach oben fahren müßte und dann diesen Wert wieder nach unten...
Wäre natürlich toll, wenn das Modul das könnte.

Wenn nicht, würde man durch "inhibit" das Drehen der Lamellen durch den User verhindern => noch weniger WAF...
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 09 September 2018, 08:05:36
Zitat von: Beta-User am 09 September 2018, 05:30:11
Bei den CUL_HM-Devices gibt es dann auch ein Reading namens inhibit, das auf "set_on" bzw. "set_off" geht.

ABER: m.E. wäre das keine gute Lösung.
Zum einen wäre damit ausgeschlossen, dass der Rolladen bei aktiviertem Aussperrschutz weiter geöffnet wird => Prognose: WAF = 0...

Und mal angenommen, der Rolladen ist oben. Dann kann entweder das inhibit mit Öffnen des FK gesetzt werden => Rolladen läßt sich nicht mal mehr auf zulässigen Level schließen. Oder die Fahrt müßte abgefangen werden,  beim vorgegebenen Level enden und das inhibit dann gesetzt werden.

Ausgeschlossen werden sollte nach meinem Gefühl nur, dass der Rolladen weiter geschlossen wird, und zwar ganz egal, von wo aus. Allerdings bin ich mir nicht so recht sicher, was denn nun wirklich das gewünschte Verhalten ist. Denn andererseits beißt sich das mit dem Grundsatz, dass Usereingriffe immer Vorrang haben sollten...

Wir versuchen ja Bernd sein Skript in ein Modul zu geben und im Skript wird hart gesperrt. Man kann es aber so machen das der Rolladen, sollte er unter sagen wir pct 80 ist auf pct 80 oder gar 100 fährt und dann erst hart sperrt.


Ich habe gestern meine restlichen Rolladenmotoren bekommen und das Modul erweitert. Jetzt wird fleißig getestet.
Da ich selbst Innenrollläden habe ist der Wunsch das bei keinem Fensterkontakt (eh logisch) oder dem Reading Lüften auf off der Rolladen immer fährt.


Thema Attribute. Event bedingt ist es so das wenn man ein Attribut anders belegen will es vorher löschen muss. Warum das sein muss hast Du ja schon erkannt. Aber ich schaue es mir noch mal an.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Deckoffizier am 09 September 2018, 10:52:34
Hallo,

habe mich mal als FHEM Laie dazu verstiegen und einige Stunden versucht ein UNIRoll Rolladen hiermit zu bedienen.
Ist wahrscheinlich gar nicht möglich da kein Reading position obwohl sich Positionen ansteuern lassen ??


Als Fragen bleiben bei mir hängen ich finde kein attr.  AutoShuttersControl_temperature                                           Device für die Aussentemperatur.
Dann was bedeutet das attr. AutoShuttersControl_Direction 178
und zu guter Letzt funktioniert das Modul momentan einzig  mit der Astro Funktion oder auch schon mit gesetzten Timern.

Finde Eure Arbeit echt interessant und würde mir Umwege über zusätzliche notify DOIF etc. ersparen.
Nun gut, habe noch ein Innenrollo von Siro mit Reading position und könnte mich da mal ran wagen.

Nachtrag: habe mittels userReadings oldPos als oldState angelegt und AutoShuttersControl_Pos_Cmd als argument in pos geändert,
warte noch mal den Abend ab, eventuell den Eventmonitor abpassen ?


Gruß und schönen Sonntag

wünscht Hans-Jürgen

   


Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 09 September 2018, 12:16:35
Zitat von: Deckoffizier am 09 September 2018, 10:52:34
Hallo,

habe mich mal als FHEM Laie dazu verstiegen und einige Stunden versucht ein UNIRoll Rolladen hiermit zu bedienen.
Ist wahrscheinlich gar nicht möglich da kein Reading position obwohl sich Positionen ansteuern lassen ??


Als Fragen bleiben bei mir hängen ich finde kein attr.  AutoShuttersControl_temperature                                           Device für die Aussentemperatur.
Dann was bedeutet das attr. AutoShuttersControl_Direction 178
und zu guter Letzt funktioniert das Modul momentan einzig  mit der Astro Funktion oder auch schon mit gesetzten Timern.

Finde Eure Arbeit echt interessant und würde mir Umwege über zusätzliche notify DOIF etc. ersparen.
Nun gut, habe noch ein Innenrollo von Siro mit Reading position und könnte mich da mal ran wagen.

Nachtrag: habe mittels userReadings oldPos als oldState angelegt und AutoShuttersControl_Pos_Cmd als argument in pos geändert,
warte noch mal den Abend ab, eventuell den Eventmonitor abpassen ?


Gruß und schönen Sonntag

wünscht Hans-Jürgen

Hallo Jürgen,

Es funktionieren nur Readings und Attribute welche in der Commandref des Modules dokumentiert sind.
Dein temperature Attribut kenne ich so nicht. Wo steht das so?
Wenn Du kein Reading hast was passent zum Fahrbefehl ist kannst du so ein Reading ja als userReadings anlegen. Pflicht sind aber Prozentangaben als Position.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Deckoffizier am 09 September 2018, 14:14:10
Hallo CoolTux,

ZitatDein temperature Attribut kenne ich so nicht. Wo steht das so?

gleich auf Seite 1 im ersten Post im Zitat unter Attribute im AutoShuttersControl Device selbst.
Denke mal irgendwo müssen ja die Werte für den Frostschutz und Hitzeschutz herkommen?

AutoShuttersControl_Time_Sunrise     05:55:16         
AutoShuttersControl_Time_Sunset          20:16:17
lastState                                                  up 0
oldPos                                                     0
oldstate                                                   up 0
state                                                       oldPos: 0

Hier wird es für mich leider nebulös....
Wenn Du kein Reading hast was passent zum Fahrbefehl ist kannst du so ein Reading ja als userReadings anlegen.....

Deshalb habe ich ja attr. AutoShuttersControl_Pos_Cmd von position auf pos geändert, der UniRoll Rolladen lässt sich ja mit pos  Werten mit set steuern.
Falscher Weg ??

Dann eventuell kurze Erleuchtung zu AutoShuttersControl_Direction 178 möglich ?

Falls ein list gewünscht wird......?
   
Genieße Du ruhig heute den Sonntag morgen ist auch noch ein Tag.

Gruß
Hans-Jürgen
   

Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 09 September 2018, 14:20:47
Das mit der Temperatur war ein Fehler. Sollte temperatureSensor heißen. Ist korrigiert.

Du musst ein userReading anlegen welches Deinem Set Befehl zum prozentualen fahren des Rollos entspricht.
Gib mal bitte ein list. Wie genau lautet dein Set Befehl und wie lautet das Reading welches den tatsächlichen Status Deines Rolladen hergibt?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Deckoffizier am 09 September 2018, 17:53:30
Hallo CoolTux,

Der Rolladen braucht ca 17 Sekunden von oben nach ganz unten.
Mit set pos 8 fährt er von oben auf etwa die Hälfte nach unten.
Eventuell gibt die Info aus der commandref zu UNIRoll für Dich mehr her als mein schriebs ?

hier das umfangreiche List vom  UniRoll Rolladen

Internals:
   BTN        1
   DEF        4455 1
   IODev      MyCUL868
   NAME       eg_sz_rollo
   NR         311
   STATE      oldPos: 0
   TYPE       UNIRoll
   XMIT       4455
   CODE:
     1          4455 1
   Helper:
     DBLOG:
       lastState:
         myDbLog:
           TIME       1536485831.69343
           VALUE      up 0
       oldPos:
         myDbLog:
           TIME       1536485832.21252
           VALUE      0
       oldstate:
         myDbLog:
           TIME       1536485831.69343
           VALUE      up 0
       state:
         myDbLog:
           TIME       1536485832.21252
           VALUE      up
   READINGS:
     2018-09-09 12:05:03   AutoShuttersControl_Time_Sunrise 05:55:16
     2018-09-09 12:05:03   AutoShuttersControl_Time_Sunset 20:16:17
     2018-09-09 11:37:11   lastState       up 0
     2018-09-09 11:37:12   oldPos          0
     2018-09-09 11:37:11   oldstate        up 0
     2018-09-09 11:37:12   state           oldPos: 0
Attributes:
   AutoShuttersControl 1
   AutoShuttersControl_Antifreeze off
   AutoShuttersControl_Closed_Pos 100
   AutoShuttersControl_Direction 178
   AutoShuttersControl_Down astro
   AutoShuttersControl_GuestRoom
   AutoShuttersControl_Mode_Down always
   AutoShuttersControl_Mode_Up always
   AutoShuttersControl_Offset_Minutes_Evening 1
   AutoShuttersControl_Offset_Minutes_Morning 1
   AutoShuttersControl_Open_Pos 0
   AutoShuttersControl_Partymode off
   AutoShuttersControl_Pos_Cmd pos
   AutoShuttersControl_Pos_after_ComfortOpen 20
   AutoShuttersControl_Rand_Minutes 20
   AutoShuttersControl_Roommate_Device
   AutoShuttersControl_Roommate_Reading state
   AutoShuttersControl_Shading off
   AutoShuttersControl_Shading_Angle_Left 85
   AutoShuttersControl_Shading_Angle_Right 85
   AutoShuttersControl_Shading_BlockingTime_After_Manual 20
   AutoShuttersControl_Shading_BlockingTime_Twilight 45
   AutoShuttersControl_Shading_Brightness_Reading brightness
   AutoShuttersControl_Shading_Brightness_Sensor 1
   AutoShuttersControl_Shading_Fast_Close off
   AutoShuttersControl_Shading_Fast_Open 1
   AutoShuttersControl_Shading_Min_Elevation 1
   AutoShuttersControl_Shading_Min_OutsideTemperature 18
   AutoShuttersControl_Shading_Pos 30
   AutoShuttersControl_Shading_Pos_after_Shading -1
   AutoShuttersControl_Shading_StateChange_Cloudy 4000
   AutoShuttersControl_Shading_StateChange_Sunny 6000
   AutoShuttersControl_Shading_WaitingPeriod 20
   AutoShuttersControl_Time_Down_Early 16:00:00
   AutoShuttersControl_Time_Down_Late 22:30:00
   AutoShuttersControl_Time_Up_Early 04:00:00
   AutoShuttersControl_Time_Up_Late 23:45:00
   AutoShuttersControl_Time_Up_WE_Holiday 09:30:00
   AutoShuttersControl_Up astro
   AutoShuttersControl_Ventilate_Pos 70
   AutoShuttersControl_Ventilate_Window_Open on
   AutoShuttersControl_WindowRec TK_EG_SZ
   AutoShuttersControl_WindowRec_subType twostate
   AutoShuttersControl_lock-out off
   IODev      MyCUL868
   devStateIcon stop:fts_shutter_updown up:fts_shutter_10 down:fts_shutter_100
   icon       fts_shutter_automatic
   rMax       17
   rMin       0
   rPos       0
   room       Schlaf_Zi_unten
   useRolloPos 1
   userReadings lastState:oldstate.* { ReadingsVal("eg_sz_rollo","oldstate",0)}
   userattr   AutoShuttersControl_Antifreeze:off,on AutoShuttersControl_Closed_Pos:0,10,20,30,40,50,60,70,80,90,100 AutoShuttersControl_Direction AutoShuttersControl_Down:time,astro AutoShuttersControl_GuestRoom:on,off AutoShuttersControl_Mode_Down:absent,always,off AutoShuttersControl_Mode_Up:absent,always,off AutoShuttersControl_Offset_Minutes_Evening AutoShuttersControl_Offset_Minutes_Morning AutoShuttersControl_Open_Pos:0,10,20,30,40,50,60,70,80,90,100 AutoShuttersControl_Partymode:on,off AutoShuttersControl_Pos_Cmd AutoShuttersControl_Pos_after_ComfortOpen:0,10,20,30,40,50,60,70,80,90,100 AutoShuttersControl_Rand_Minutes AutoShuttersControl_Roommate_Device AutoShuttersControl_Roommate_Reading AutoShuttersControl_Shading:on,off,delayed,present,absent AutoShuttersControl_Shading_Angle_Left:0,5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90 AutoShuttersControl_Shading_Angle_Right:0,5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90 AutoShuttersControl_Shading_BlockingTime_After_Manual AutoShuttersControl_Shading_BlockingTime_Twilight AutoShuttersControl_Shading_Brightness_Reading AutoShuttersControl_Shading_Brightness_Sensor AutoShuttersControl_Shading_Fast_Close:on,off AutoShuttersControl_Shading_Fast_Open:on,off AutoShuttersControl_Shading_Min_Elevation AutoShuttersControl_Shading_Min_OutsideTemperature AutoShuttersControl_Shading_Pos:10,20,30,40,50,60,70,80,90,100 AutoShuttersControl_Shading_Pos_after_Shading:-1,0,10,20,30,40,50,60,70,80,90,100 AutoShuttersControl_Shading_StateChange_Cloudy AutoShuttersControl_Shading_StateChange_Sunny AutoShuttersControl_Shading_WaitingPeriod AutoShuttersControl_Time_Down_Early AutoShuttersControl_Time_Down_Late AutoShuttersControl_Time_Up_Early AutoShuttersControl_Time_Up_Late AutoShuttersControl_Time_Up_WE_Holiday AutoShuttersControl_Up:time,astro AutoShuttersControl_Ventilate_Pos:10,20,30,40,50,60,70,80,90,100 AutoShuttersControl_Ventilate_Window_Open:on,off AutoShuttersControl_WindowRec AutoShuttersControl_WindowRec_subType:twostate,threestate AutoShuttersControl_lock-out:on,off
   webCmd     up:stop:down


Gruß
Hans-Jürgen
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 09 September 2018, 19:31:40
Das passt bei Dir so gar nicht mit dem userReadings. Wieso machst Du lastState?


pos:oldPos.* { ReadingsVal($name,"oldstate",0)}


So sollte es gehen.
Wenn Du aber schon bei 8 die Hälfte hast, dann sollte ja bei 16 Schluß sein. Also voll zu oder voll auf.

AutoShuttersControl_Closed_Pos 16
AutoShuttersControl_Open_Pos 0
AutoShuttersControl_Pos_after_ComfortOpen 2
AutoShuttersControl_Ventilate_Pos 14
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Deckoffizier am 09 September 2018, 21:15:48
Hallo CoolTux,

bin jetzt wieder mal verwirrt....

Das passt bei Dir so gar nicht mit dem userReadings. Wieso machst Du lastState?

1. Seite erster Text
ZitatWas solltet Ihr dazu haben? Rolläden, Fensterkontakte und Bewohnerstatus auf Basis von Residents/Roomates in englisch. Es können auch Dummys sein welche home,asleep,gotosleep und awoken setzen. Wichtig wäre noch ein Reading lastState. Aber sowas kann man schnell zaubern, ich helfe da gerne

Nun gut, mache mich mal ran Deine Vorschläge umzusetzen.
Danke für Dein an die Hand nehmen und ist vielleicht auch nicht ganz ohne worüber
die Laien schon stolpern. ;)

Gruß
Hans-Jürgen


Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 09 September 2018, 21:24:40
Zitat von: Deckoffizier am 09 September 2018, 21:15:48
Hallo CoolTux,

bin jetzt wieder mal verwirrt....

Das passt bei Dir so gar nicht mit dem userReadings. Wieso machst Du lastState?

1. Seite erster Text
Nun gut, mache mich mal ran Deine Vorschläge umzusetzen.
Danke für Dein an die Hand nehmen und ist vielleicht auch nicht ganz ohne worüber
die Laien schon stolpern. ;)

Gruß
Hans-Jürgen

Hallo Jürgen,

Da hast Du wohl was missverstanden. Das galt für den Bewohnerstatus. Da braucht man einen lastState.
Im Rolläden brauchst du ein Reading welches so heißt wie der Set Befehl.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Deckoffizier am 09 September 2018, 22:04:21
Hallo CoolTux,

da kommt Freude auf....
Rollo ist unten.
Habe einmal mit time für runterfahren umgestellt eingetragen.

Sowie im attr AutoShuttersControl_Roommate_Reading auf lastState geändert.
Zusätzlich rr_Mann vom Dummy Roommate in AutoShuttersControl_Roommate_Device eingetragen.
Ist doch schön  wenn es auch auf UniRoll funktioniert.

An die Feinheiten kann ich mich ja später langsam ran tasten.

Danke Euch vielmals Hans-Jürgen


Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 09 September 2018, 22:08:01
Zitat von: Deckoffizier am 09 September 2018, 22:04:21
Hallo CoolTux,

da kommt Freude auf....
Rollo ist unten.
Habe einmal mit time für runterfahren umgestellt eingetragen.

Sowie im attr AutoShuttersControl_Roommate_Reading auf lastState geändert.
Zusätzlich rr_Mann vom Dummy Roommate in AutoShuttersControl_Roommate_Device eingetragen.
Ist doch schön  wenn es auch auf UniRoll funktioniert.

An die Feinheiten kann ich mich ja später langsam ran tasten.

Danke Euch vielmals Hans-Jürgen

Hallo Jürgen,

Leider wieder falsch verstanden.
Hast du einen Dummy angelegt wie im Thread beschrieben gibst du als roommate Device den Dummy an, state lässt Du als Reading. Das userReadings lastState ist nur für den Dummy wird aber sonst nirgends mit an gegeben.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Deckoffizier am 09 September 2018, 22:38:32
Hallo CoolTux,

also Kommando zurück   ;)

Ja Dummy hatte ich schon am Anfang angelegt als  rr_Mann.
Ändere es wieder um kein Problem.
Lasse mich morgen früh überraschen.
Danke für Dein aushalten habe zwar hier soweit alles gelesen aber für die Interna fehlt mir leider der tiefere Einblick bzw. Verständnis.

Gruß vom alten Mann Hans-Jürgen
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Cluni am 10 September 2018, 08:47:50
@BetaUser und @CoolTux: Das mit dem Aussperrschutz ist so gewachsen, weil irgendjemand das mal so haben wollte. Der Schalter sollte nicht mehr bedienbar sein, wenn z.B. die Terrassentür offen ist. Hintergedanke war das Kleinkind, was einen sonst aussperren könnte, wenn man draußen ist. In meinem eigenen Code wollte ich jetzt dafür eine Differenzierung einbauen: Entweder nur Aussperrschutz, welcher die automatischen Fahrten (also von der Abschattung oder automatisches Schließen) sperrt, wenn der Rollladen dadurch weiter herunter fahren würde und die andere Möglichkeit sperrt dann zusätzlich noch (wie bisher) den physikalischen Schalter.

Grüße Cluni
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 10 September 2018, 08:51:45
Zitat von: Cluni am 10 September 2018, 08:47:50
@BetaUser und @CoolTux: Das mit dem Aussperrschutz ist so gewachsen, weil irgendjemand das mal so haben wollte. Der Schalter sollte nicht mehr bedienbar sein, wenn z.B. die Terrassentür offen ist. Hintergedanke war das Kleinkind, was einen sonst aussperren könnte, wenn man draußen ist. In meinem eigenen Code wollte ich jetzt dafür eine Differenzierung einbauen: Entweder nur Aussperrschutz, welcher die automatischen Fahrten (also von der Abschattung oder automatisches Schließen) sperrt, wenn der Rollladen dadurch weiter herunter fahren würde und die andere Möglichkeit sperrt dann zusätzlich noch (wie bisher) den physikalischen Schalter.

Grüße Cluni

Die Idee finde ich auch super. Ersteres ist bereits im Code implementiert. Der Rest wäre auch simpel ein zu binden.
Danke Bernd
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Deckoffizier am 10 September 2018, 09:54:33
Hallo CoolTux,

irgendwo ist bei mir noch der Wurm drin.
In einem zweiten UniRoll Rollo stehen unter Readings Readings drin vom Rollo an dem ich nur zum probieren arbeite, von dem Du auch mein List bekommen hast.
An dem anderen Device hatte ich rein gar nichts geändert.

Leider ist das sage mal Probier Rollo leider heute morgen nach Astro nicht hochgefahren.
Geht eigentlich auch gemischt z.B.  morgens nach Astro abends nach time.
Im Log war zwar die Auslösung morgens zu lesen, aber ich vermute der Sendebefehl(bedingt vom angepassten) userReadings war nicht richtig gegenüber gestern abend. Werde mich noch mal dran versuchen.

Gruß
Hans-Jürgen
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 10 September 2018, 10:00:50
Zitat von: Deckoffizier am 10 September 2018, 09:54:33
Hallo CoolTux,

irgendwo ist bei mir noch der Wurm drin.
In einem zweiten UniRoll Rollo stehen unter Readings Readings drin vom Rollo an dem ich nur zum probieren arbeite, von dem Du auch mein List bekommen hast.
An dem anderen Device hatte ich rein gar nichts geändert.

Leider ist das sage mal Probier Rollo leider heute morgen nach Astro nicht hochgefahren.
Geht eigentlich auch gemischt z.B.  morgens nach Astro abends nach time.
Im Log war zwar die Auslösung morgens zu lesen, aber ich vermute der Sendebefehl(bedingt vom angepassten) userReadings war nicht richtig gegenüber gestern abend. Werde mich noch mal dran versuchen.

Gruß
Hans-Jürgen

Danke für die Rückmeldung. Du fährst Dein Rollo doch über FHEM mit

set Rollo pos 4

Dann muss ja beim Rollo als Attribut für Cmd auch pos drin stehen. Das hast du ja bestimmt.
Dann solltest du schauen ob 0 wirklich auf bei Dir ist und 16 zu, oder anders rum. Ist 16 denn auch der höchste Wert für voll auf oder voll zu?
Und das stellst du dann in PosUp und PosDown entsprechend ein.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 10 September 2018, 10:19:09
Moin zusammen!

@Cluni: Willkommen in diesem Thread!

Was den Aussperrschutz angeht: Das Thema wird schnell beliebig kompliziert, wenn man alle Eventualitäten mit abfangen will. Die beiden Varianten, nur die automatischen Fahrten aus dem Modul zu unterbinden und optional den Rolladen gegen lokale Bedienung zu sperren finde ich erst mal einen akzeptablen Anfang.

Auch hier wäre der Vorschlag, nicht alle erforderlichen Angaben auf beliebig viele Attribute zu verteilen, sondern das "auf einen Rutsch" zu machen (oder zwei "Rutsche", damit ggf. für eigene Notify der Rückweg zum Shutter einfacher ist):

AutoShuttersControl_WindowRec FensterKinZimLi [twostate|treestate] [inhibit|blocked|<weitere Sperrvarianten>]

oder mit einem ergänzenden
AutoShuttersControl_WindowRecOptions [twostate|treestate] [inhibit|blocked|<weitere Sperrvarianten>]Das Options-Attribut würde ich dann wieder nicht auf alle Rolläden ausrollen, sondern stattdessen im Falle von nicht gesetzt "twostate" als default unterstellen (und nicht blockiert).

Gruß, Beta-User
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 10 September 2018, 10:47:32
Ich dachte da mehr an

In den Rollos

attr AutoShuttersControl_lock-out hard/soft


Und im Moduldevice ein set Befehl mit Reading

set Rollosteuerung on/off


überall wo soft steht wird über das Modul nicht mehr gefahren und wo hard steht wird über das Modul nicht mehr gefahren und entsprechend des Rollotypes hart gesperrt mit inhibit|blocked.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 10 September 2018, 11:03:37
Hmm,
an sich wäre ich davon ausgegangen, dass der, der einen FK angibt, auch "immer" mind. die soft-Variante haben will und auch eine automatische Reaktion auf das Öffnen des Fensters haben will, im Sinne von: Fahre den Rolladen mind. bis zur Lüften-Position hoch (es sei denn, der Bewohner schläft?) und durch eine automatische Fahrt vom Modul aus auch nicht weiter runter. Aber doppelt genäht hält besser.

Das Aktivierbar zu machen, finde ich gut, wobei m.E. "set Rollosteuerung lock-out on" als default aktiv sein sollte nach einem Start ohne bekannten Status.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 10 September 2018, 11:19:59
Zitat von: Beta-User am 10 September 2018, 11:03:37
Hmm,
an sich wäre ich davon ausgegangen, dass der, der einen FK angibt, auch "immer" mind. die soft-Variante haben will und auch eine automatische Reaktion auf das Öffnen des Fensters haben will, im Sinne von: Fahre den Rolladen mind. bis zur Lüften-Position hoch (es sei denn, der Bewohner schläft?) und durch eine automatische Fahrt vom Modul aus auch nicht weiter runter. Aber doppelt genäht hält besser.

Das Aktivierbar zu machen, finde ich gut, wobei m.E. "set Rollosteuerung lock-out on" als default aktiv sein sollte nach einem Start ohne bekannten Status.

;D Du denkst zu Eng. Ich habe zum Beispiel Innenraumrollos, ich brauche sowas wie Lüften und Co gar nicht  ;)
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 10 September 2018, 14:01:43
Zitat von: CoolTux am 10 September 2018, 11:19:59
;D Du denkst zu Eng. Ich habe zum Beispiel Innenraumrollos, ich brauche sowas wie Lüften und Co gar nicht  ;)
Man lernt nie aus ;D .

Aber warum vergibst du überhaupt einen Wert für den FK, wenn das gar keine Auswirkungen haben soll?
Oder babsichtigst du das Attribut für eigene Funktionen außerhalb des Moduls zu nutzen und verhinderst so, dass du die Angaben bei anderen Rolläden doppelt vergeben mußt ;) ?

Gruß, Beta-User
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 10 September 2018, 14:38:44
Zitat von: Beta-User am 10 September 2018, 14:01:43
Man lernt nie aus ;D .

Aber warum vergibst du überhaupt einen Wert für den FK, wenn das gar keine Auswirkungen haben soll?
Oder babsichtigst du das Attribut für eigene Funktionen außerhalb des Moduls zu nutzen und verhinderst so, dass du die Angaben bei anderen Rolläden doppelt vergeben mußt ;) ?

Gruß, Beta-User

Sagen wir ich experimentiere da noch etwas. Und muß ja auch bisschen das Modul testen  ;D
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Cluni am 10 September 2018, 14:39:39
[Klugscheißermodus]
Nur mal so zur Info: https://www.korrekturen.de/wortliste/rollladen.shtml
[/Klugscheißermodus]

...und schnell wech....  8)
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 10 September 2018, 14:43:28
Zitat von: Cluni am 10 September 2018, 14:39:39
[Klugscheißermodus]
Nur mal so zur Info: https://www.korrekturen.de/wortliste/rollladen.shtml
[/Klugscheißermodus]

...und schnell wech....  8)

Mit 3 L
Vergiss es, dafür bin ich zu alt  ;D
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Cluni am 10 September 2018, 14:44:35
Ist doch schon 14 Jahre so - warst du damals auch schon zu alt?  :o  :P
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 10 September 2018, 14:53:26
Auf jeden Fall. Da war ich schon 6 Jahre aus der Schule und 3 aus der Berufsschule. Somit schon 2 Jahre Selbstständig. Da macht man sowas nicht mehr mit. Lach
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 10 September 2018, 15:10:40
Zitat von: Cluni am 10 September 2018, 14:39:39
...und schnell wech....  8)
:o ;D ;D ;D ymmd

Damit auch noch was mit "Fortschritt für's Projekt" in diesem Beitrag steht, hier noch was zum Nebenthema "Wie füttere ich meine vorher nicht vorhandenen Bewohner mit sinnvollem content?":
define rr_Mann dummy
attr rr_Mann event-on-change-reading .*
attr rr_Mann group Persons
attr rr_Mann icon user_unknown
attr rr_Mann readingList state smartphone_MAC smartphone
attr rr_Mann room Steuerung attr rr_Mann setList state:home,gotosleep,awoken,absent,asleep smartphone:absent,present smartphone_MAC
attr rr_Mann userReadings lastState:(home|awoken|asleep|gotosleep|absent) {OldValue($name) }

define rr_Mann_Presence_Timer WeekdayTimer rr_Mann !$we|06:30|awoken !$we| 06:40|home $we|08:00|awoken $we|08:30|home !$we|07:30|absent !$we|19:00|home 01234|21:45|gotosleep 01234|22:00|asleep 56|22:40|gotosleep 01234|56|23:00|asleep {fhem "set $DEVICE $EVENT unless (ReadingsVal($DEVICE,'smartphone','absent') eq 'present' and $EVENT eq 'absent')"  }
attr rr_Mann_Presence_Timer commandTemplate set $NAME  $EVENT
attr rr_Mann_Presence_Timer disable 0
attr rr_Mann_Presence_Timer group Persons
attr rr_Mann_Presence_Timer icon status_automatic
attr rr_Mann_Presence_Timer room Steuerung

define rr_xn_MAC_Check notify Fritzbox:mac_.*:.* {if ($EVTPART1 eq "inactive") {
    fhem("set TYPE=dummy:FILTER=smartphone_MAC=$EVTPART0 smartphone absent");
  } else {
    fhem("set TYPE=dummy:FILTER=smartphone_MAC=$EVTPART0 smartphone present");
  }
}

define rr_xn_smartphone notify rr_.*:smartphone:.* {my $newState = "absent";
$newState = "home" if ($EVTPART1 eq "present");
my $timerName = $NAME."_Presence_Timer";
fhem "set $NAME $newState" if (ReadingsVal($timerName,"currValue","home") eq "absent"); }
attr rr_xn_smartphone group Persons
attr rr_xn_smartphone icon edit_settings
attr rr_xn_smartphone room Steuerung


(Achtung: das ist die modifizierte Ausgabe von einem "list -r" und sollte so für den RAW-Input passen; aber bitte ggf. erst nochmal prüfen, v.a. wg. der Zeilenumbrüche).
Irgendwann werde ich wohl um diese ROOMMATE-Dingens nicht rumkommen >:( , aber vermutlich macht das demnächst eh' Sinn wg. der Heizungssteuerung.
Jedenfalls scheint nach einem "set rr_Mann smartphone_MAC xx_usw:" erkannt zu werden, wenn ich wider Erwarten zuhause bin und dann auch wieder gehe... (das notify für die Auswertung der Fritzbox-Readings ist eine generalisierte Variante des Wiki-Abschnittes). Wer's nachbauen will/muss: Das ist nicht vollständig erprobt, kritische Prüfung wäre also angesagt...
Vielleicht ergänze ich das noch um eine Kalender-Auswertung, dann können meine Kinder das zum eigenen Komfort zusätzlich darüber erledigen bzw. teilweise übersteuern. Oder Telegram?!? Mist, warum gibt es hier nur so viele Optionen 8) .

[ad Klugscheißermodus]
Wer Schreibfehler findet, darf sie behalten; Verbesserungen am Code nehme ich dagegen gerne entgegen...
Bin zwar auch schon etwas länger aus der Schule, aber alles dreimal mit Duden Korrektur zu lesen, ist auch nicht meins ;) . In der Regel kann man schon erkennen, was mit dem Geschreibsel gemeint gewesen sein könnte...
[/ad Klugscheißermodus]

Gruß, Beta-User

EDIT: Code verbessert
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 10 September 2018, 21:17:49
Was für die Wunschliste:
Das mit der structure (und ggf. weiteren) wäre einfacher, wenn bei Nichtvorhandensein des oldState-Readings stattdessen lastState verwendet würde - das macht structure nämlich automatisch und dürfte leicht in den Code zu integrieren sein :) .

Ansonsten läuft seit eben V. 0.1.35 :) .

Gruß, Beta-User
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 10 September 2018, 22:02:12
Zitat von: Beta-User am 10 September 2018, 21:17:49
Was für die Wunschliste:
Das mit der structure (und ggf. weiteren) wäre einfacher, wenn bei Nichtvorhandensein des oldState-Readings stattdessen lastState verwendet würde - das macht structure nämlich automatisch und dürfte leicht in den Code zu integrieren sein :) .

Ansonsten läuft seit eben V. 0.1.35 :) .

Gruß, Beta-User

Ähm meinst Du umgekehrt? lastState macht das Modul nämlich  ;D
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 10 September 2018, 22:14:08
So herum war's gemeint, also das Reading verwenden, was sowieso schon da ist...

Sorry, wenn das mißverständlich formuliert war ;) .
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 10 September 2018, 22:19:23
Ich weiß es wäre nur ein Einzeiler aber einer der Unnötig wäre. Ziel ist es ja Roommate/Residents zu unterstützen. Das mit structure ist nur ne Notlösung.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Bastel-Frank am 11 September 2018, 08:05:31
Warum benötigt man ein fhem mit Update ab dem 04.09.18 - was hat sich geändert?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 11 September 2018, 08:55:20
Zitat von: Bastel-Frank am 11 September 2018, 08:05:31
Warum benötigt man ein fhem mit Update ab dem 04.09.18 - was hat sich geändert?

Ich habe 2 Funktionen für die fhem.pl geschrieben. Diese wurden von Rudi ein Tag davor eingespielt.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: MarkusHiba am 11 September 2018, 09:03:19
Hallo Leute,

gibt es schon ein Wiki dazu?

Gruß

MarkusHiba

Gesendet von meinem G8141 mit Tapatalk

Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 11 September 2018, 09:13:09
Zitat von: MarkusHiba am 11 September 2018, 09:03:19
Hallo Leute,

gibt es schon ein Wiki dazu?

Gruß

MarkusHiba

Gesendet von meinem G8141 mit Tapatalk

Nein noch nicht. Gut das Du fragst. Würde mich sehr freuen wenn Du da vielleicht was machen könntest. Im Prinzip kannst Du die Commandref zum Modul übernehmen.
Vielen lieben Dank


Grüße
Leon
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: MarkusHiba am 11 September 2018, 09:26:10
Klar würde ich gern machen aber da brauch man doch ein extra Zugang oder?

Gesendet von meinem G8141 mit Tapatalk

Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 11 September 2018, 09:29:32
Ja da braucht man einen Zugang.

https://wiki.fhem.de/wiki/Hauptseite
Ganzen unten in Dunkelgelb findest Du Administratives zum Wiki. Da steht alles dazu.
Find ich cool das Du mitmachen willst. So haben gerade Änfanger einen leichten Einstieg in unser Modul.
Bekommst auch einen Eintrag in der Moduldatei  ;)


Grüße
Leon
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 11 September 2018, 12:21:48
Zitat von: CoolTux am 10 September 2018, 22:19:23
Ich weiß es wäre nur ein Einzeiler aber einer der Unnötig wäre. Ziel ist es ja Roommate/Residents zu unterstützen. Das mit structure ist nur ne Notlösung.

War nur eine Bitte. Wäre hilfreich gewesen, aber dann nutze ich eben erst mal das notify weiter und mache ich mich ggf. bei Gelegenheit dran, das mit RESIDENTS zu lösen.

Anbei mal ein erster Wurf für die englische Commandref. K.A., ob ich auch die bislang von mir noch nicht genutzten Teile soweit verstanden habe, dass das inhaltlich paßt. Fehler dürfen natürlich verbessert werden, es würde mich insbesondere freuen, sofern einer der "üblichen Verdächtigen" hier mitlesen sollte und sich der Sache annimmt ;) !

Gruß, Beta-User
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 11 September 2018, 12:28:57
Zitat von: Beta-User am 11 September 2018, 12:21:48
Anbei mal ein erster Wurf für die englische Commandref. K.A., ob ich auch die bislang von mir noch nicht genutzten Teile soweit verstanden habe, dass das inhaltlich paßt. Fehler dürfen natürlich verbessert werden, es würde mich insbesondere freuen, sofern einer der "üblichen Verdächtigen" hier mitlesen sollte und sich der Sache annimmt ;) !

Gruß, Beta-User

Super. Vielen lieben Dank.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 11 September 2018, 16:32:28
Mal als Basis, auch wenn m.E. die CR eigentlich schon ganz gelungen ist und zum Einrichten reichen sollte:

https://wiki.fhem.de/wiki/AutoShuttersControl

Gruß, Beta-User
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: FunkOdyssey am 11 September 2018, 16:38:39
Gut gemacht. Vielen Dank.

Hattest du nicht auch ne ReadingsGroup zur Konfiguration zur Hand?
Wäre das nicht auch etwas fürs Wiki?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 11 September 2018, 16:51:53
Yup, die kommt noch; an der habe ich aber seit dem ersten Posting dazu noch etwas rumgeschraubt ::) , das wollt ich mir erst nochmal ansehen, deswegen steht im Wiki grade der Platzhalter "tbd" ;) .

Danke für's Interesse und die Nachfrage 8) .
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: MarkusHiba am 11 September 2018, 17:42:53
Hallo

Zur Ergänzung das Rollomodul besitzt jetzt  auch pct https://github.com/RettungsTim/fhem-rollo

Gruß

MarkusHiba

Gesendet von meinem G8141 mit Tapatalk

Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: C0mmanda am 11 September 2018, 20:21:12
Hallo,
habe mir das ASC-Modul mal installiert zum testen.

Habe direkt eine Frage:
Ist es geplant bzw. möglich Zwischenzeiten einzustellen?
Ich lasse meine Rolladen i.d.R. in der Dämmerung erst zu 70% herunterfahren (Sichtschutz) und eine gewisse Zeit später schliessen sie dann ganz.

Gruß
CmdA
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 11 September 2018, 20:24:39
Zitat von: C0mmanda am 11 September 2018, 20:21:12
Hallo,
habe mir das ASC-Modul mal installiert zum testen.

Habe direkt eine Frage:
Ist es geplant bzw. möglich Zwischenzeiten einzustellen?
Ich lasse meine Rolladen i.d.R. in der Dämmerung erst zu 70% herunterfahren (Sichtschutz) und eine gewisse Zeit später schliessen sie dann ganz.

Gruß
CmdA

Aktuell ist nichts geplant. Aber ich kann es ja mal für Anfang nächsten Jahres vormerken.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: FunkOdyssey am 11 September 2018, 20:47:34
Danke. Ich habe mich nicht getraut zu fragen, denn ich fahre meine Jalousien auch zuerst auf 50% (je nach Jalousie unterschiedlich) und dann erst runter. Küche und WC schließe ich aber direkt. So wie Jalousien, in denen Deko-Leuchten stehen.
Sicherlich ist das nicht wirklich gut für die Motoren, aber ganz runter bei leichter Dämmerung fänd ich zu heftig.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: C0mmanda am 11 September 2018, 21:08:43
Zitat von: CoolTux am 11 September 2018, 20:24:39
Aktuell ist nichts geplant. Aber ich kann es ja mal für Anfang nächsten Jahres vormerken.

Wäre toll wenn du das tun würdest ;)
2-stufiges fahren sollte am Ende schon möglich sein.
Das aktuell andere Baustellen wichtiger sind ist klar...

Danke & Gruss
C0mmanda
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 12 September 2018, 00:20:28
Das mit der otionalen Zwischenstufe finde ich auch nicht übel, dürfte aber etwas Aufwand sein...

Zitat von: FunkOdyssey am 11 September 2018, 16:38:39
Hattest du nicht auch ne ReadingsGroup zur Konfiguration zur Hand?
Aktualisierte Fassung ist im Wiki.

Sonst noch Wünsche und Anregungen?

Zitat von: MarkusHiba am 11 September 2018, 17:42:53
Zur Ergänzung das Rollomodul besitzt jetzt  auch pct https://github.com/RettungsTim/fhem-rollo (https://github.com/RettungsTim/fhem-rollo)

Das (und evtl. zwischenzeitlich geäußerte Wiki-Ergänzungswünsche) darfst du gerne ins Wiki korrekt eintragen  ;) . Danke jedenfalls im Voraus für's Kümmern betr. die Attribute usw..

Bin echt beeindruckt, wie das hier vorwärts geht und wie viele sich aktiv einbringen!

Gruß, Beta-User
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 12 September 2018, 06:14:16
Guten Morgen,

Ich melde mich auch mal kurz. Die Entwicklung des Modules geht natürlich weiter, aktuell bin ich auf Käferjagd.
Jemand hier hatte den Wunsch die Astrozeiten REAL,CIVIL und so an den Rolladen ein zu stellen. Da meine Tochter nun auch diesen Wunsch hatte das ihre Rolladen später fahren werde ich das einbauen.


Grüße
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 12 September 2018, 10:02:41
Moin zusammen,
weiß nicht, ob das ein Käfer ist, aber hier mal einige Eckinfos:

- Die Version 0.1.35 hatte ich nach sunset vor zwei Tagen installiert und FHEM neu gestartet, sonst m.E. nichts mehr geändert an Zeiten uws..
- Gestern nachmittag waren einige Rollläden noch geschlossen; die sind auch heute morgen nicht aufgegangen.
- Gestern abend sind mind. einige Rolläden auch nicht geschlossen worden, bei den zweien im Schlafzimmer könnte es sein, dass dies manuell erfolgt ist.
- heute morgen gingen dann die im Schlafzimmer automatisch auf, die noch geschlossenen anderen nicht.
- jetzt stehen die im Modul angezeigten Timer auf morgen früh, vermutet hätte ich, dass dies heute abend sein müßte.

Was unterscheidet die Devices?
- die gar nicht mehr Fahrenden kennen keine Residents
- die Geschlossenen haben Residents, deren Anwesenheitsstatus sich zwischenzeitlich nicht geändert hat, die sind schlicht "absent"
- Im Schlafzimmer gibt es einen Resident mit sich änderndem Anwesenheitsstatus.

Ein "renew.." der Timer führt zu keinen anderen Timer-Readings.

Neustart lasse ich mal, für den Fall, dass weitere Infos erforderlich wären.

Gruß, Beta-User
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 12 September 2018, 10:16:13
Zitat von: Beta-User am 12 September 2018, 10:02:41
Moin zusammen,
weiß nicht, ob das ein Käfer ist, aber hier mal einige Eckinfos:

- Die Version 0.1.35 hatte ich nach sunset vor zwei Tagen installiert und FHEM neu gestartet, sonst m.E. nichts mehr geändert an Zeiten uws..
- Gestern nachmittag waren einige Rollläden noch geschlossen; die sind auch heute morgen nicht aufgegangen.
- Gestern abend sind mind. einige Rolläden auch nicht geschlossen worden, bei den zweien im Schlafzimmer könnte es sein, dass dies manuell erfolgt ist.
- heute morgen gingen dann die im Schlafzimmer automatisch auf, die noch geschlossenen anderen nicht.
- jetzt stehen die im Modul angezeigten Timer auf morgen früh, vermutet hätte ich, dass dies heute abend sein müßte.

Was unterscheidet die Devices?
- die gar nicht mehr Fahrenden kennen keine Residents
- die Geschlossenen haben Residents, deren Anwesenheitsstatus sich zwischenzeitlich nicht geändert hat, die sind schlicht "absent"
- Im Schlafzimmer gibt es einen Resident mit sich änderndem Anwesenheitsstatus.

Ein "renew.." der Timer führt zu keinen anderen Timer-Readings.

Neustart lasse ich mal, für den Fall, dass weitere Infos erforderlich wären.

Gruß, Beta-User

Genau das ist es wo ich seit Tagen dran bin. Die Berechnung der neunen Timmer und deren Abhängigkeit zu nicht noch mal fahren am selben Tag wenn der nächste Startzeitpunkt nur ein paar Minuten später ist und noch hundert andere Sachen die beachtet werden müssen  ;D
Bin aber dran und habe gute Hoffnung.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 12 September 2018, 20:46:44
Na dann guten Erfolg.
Zur Info: Habe eben erst mal einen Reload gemacht => nix passiert, Timer standen auf morgen früh.

Dann den Party-Mode an und wieder aus => Rollläden gingen zu, obwohl die Astro-Zeit eigentlich um gewesen sein müßte vor dem Einschalten des Party-Mode.

Vielleicht hilft das weiter...

Danke für's Suchen "der die das" Käfer!
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Papaloewe am 12 September 2018, 20:54:12
Ja, das Verhalten kann ich auch bestätigen.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 12 September 2018, 21:03:19
Hier ein Tip damit das setzen der Timer für das nächste Astroevent geht.


deletereading RolladenDevice .AutoShuttersControl_InternalTimerFuncHash


Danach Timer neu setzen lassen über das ASC Device.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Prof. Dr. Peter Henning am 13 September 2018, 04:58:02
ZitatDie Berechnung der neunen Timmer und deren Abhängigkeit zu nicht noch mal fahren am selben Tag wenn der nächste Startzeitpunkt nur ein paar Minuten später ist und noch hundert andere Sachen die beachtet werden müssen

Das ist in der Tat ein unschönes Problem, wie ich beim YAAHM-Modul gemerkt habe. Es kommt nämlich immer der nächste Tag ebenfalls ins Spiel. Hat eine Weile gedauert, da alle Fälle richtig zu erledigen. Beispiel: Ich stelle eine manuelle Weckzeit um 7:45, obwohl der Standardwecker auf 8:00 steht. Dann darf nach Ausführung des manuellen Weckers eben nicht die manuelle Weckzeit einfach gelöscht werden, sonst geht der Wecker um 8:00 erneut los.

LG

pah
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 13 September 2018, 06:05:49
Ich denke ich bin auf einem guten Weg was das alles an geht. In 40 Minuten werde ich es genau wissen  :)


Grüße
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 13 September 2018, 07:41:30
Klingt gut!

Hätte auch eine Idee gehabt, aber das ist vermutlich unausgereifter wie das was CoolTux grade testet.

Was den Rest angeht, hätte ich mal wieder ein paar Feststellungen, _Wünsche und Anregungen_:

- hotfix für das Timerproblem: Einfach diese beiden Dinge vorläufig kurz nach Mitternacht automatisiert durchführen. (das ist keine Lösung, sondern ein unschöner würgaround, das ist schon klar)

- Partymode sollte m.E. ein echtes "set" sein, kein Attribut (das betrifft ggf. noch mehr Einstellmöglichkeiten am zentralen Device, z.B. Comfort, Astro etc.). Das mit dem ? sollte man für solche "Kleinigkeiten" vermeiden, wenn es geht, lieber die Defaults sinnvoll wählen, für den Fall, dass noch nichts in der statefile steht.
- Die Attribute am zentralen Device brauchen m.E. nicht diesen langen Präfix, insbesondere dann nicht, wenn sich darüber nicht zentrale Defaults (für timer usw.) setzen  lassen.

- Das Zeitformat, das heute standarmäßig mit Sek. ausgerollt wird, könnte auf HH:MM geändert werden

- Welchen Sinn hat eigentlich die Einschränkung auf 10-er Schritte in den ganzen Positionsvorgaben? Macht als einfache Einstellmöglichkeit schon Sinn, aber praktisch sollten sich auch andere Werte setzen lassen? (Hier geht es eigentlich nur um das Wording in der Doku, ich gehe davon aus, dass es halt ein Zahlenwert sein muß).

Das war's erst mal wieder, aber bestimmt fällt mir noch das eine oder andere auf...

Gruß, Beta-User
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 13 September 2018, 08:19:46
Zitat von: Beta-User am 13 September 2018, 07:41:30
Klingt gut!

Hätte auch eine Idee gehabt, aber das ist vermutlich unausgereifter wie das was CoolTux grade testet.

Was den Rest angeht, hätte ich mal wieder ein paar Feststellungen, _Wünsche und Anregungen_:

- hotfix für das Timerproblem: Einfach diese beiden Dinge vorläufig kurz nach Mitternacht automatisiert durchführen. (das ist keine Lösung, sondern ein unschöner würgaround, das ist schon klar)

- Partymode sollte m.E. ein echtes "set" sein, kein Attribut (das betrifft ggf. noch mehr Einstellmöglichkeiten am zentralen Device, z.B. Comfort, Astro etc.). Das mit dem ? sollte man für solche "Kleinigkeiten" vermeiden, wenn es geht, lieber die Defaults sinnvoll wählen, für den Fall, dass noch nichts in der statefile steht.
- Die Attribute am zentralen Device brauchen m.E. nicht diesen langen Präfix, insbesondere dann nicht, wenn sich darüber nicht zentrale Defaults (für timer usw.) setzen  lassen.

- Das Zeitformat, das heute standarmäßig mit Sek. ausgerollt wird, könnte auf HH:MM geändert werden

- Welchen Sinn hat eigentlich die Einschränkung auf 10-er Schritte in den ganzen Positionsvorgaben? Macht als einfache Einstellmöglichkeit schon Sinn, aber praktisch sollten sich auch andere Werte setzen lassen? (Hier geht es eigentlich nur um das Wording in der Doku, ich gehe davon aus, dass es halt ein Zahlenwert sein muß).

Das war's erst mal wieder, aber bestimmt fällt mir noch das eine oder andere auf...

Gruß, Beta-User

Ich habe eine neue Version ins Git geladen. Sie sollte nun die neuen Timer nach Ablauf der alten Timer korrekt setzen, würde aber noch nicht meine Hand dafür ins Feuer legen. Auf jeden Fall kann man aber ohne Probleme mit dem set Befehl zum setzen der neuen Timer das ganze korrigieren sollte es falsch berechnet werden. Dafür habe ich jetzt in den Rolladendevices selber vernünftige Datumsangaben.

Es gibt schon eine Weile einen set Befehl für den Partymode.

Ich habe die Astroangaben nun auch in den Rolladendevices selbst. Werden aber noch nicht beachtet. Ich muß da erstmal weiter testen was das Timer setzen an geht.

Bei den nicht so langen Präfix stimme ich Dir zu, aber einen Präfix brauchen sie. Wurde unter den Developern mal so Diskutiert und ich finde es sinnvoll.

Das mit den 10er Schritten habe ich so übernommen von Bernd. 5 oder gar 1er Schritte machen ja noch weniger Sinn finde ich.




Auf alle Fälle empfehle ich sehr die neue Version ein zu spielen. Danach ist ein neustart erforderlich. Sollten Probleme auftauchen meldet sie mir bitte.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 13 September 2018, 10:41:06
Version 0.1.40 habe ich eben noch mal gepusht. Ich hatte da noch einen Bug gefunden auf die schnelle.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Prof. Dr. Peter Henning am 13 September 2018, 12:41:56
Zum Thema Partymode: Könnte man das so ausbauen, dass diese Settings von einem Device (z.B. YAAHM-Device) übernommen werden ? Da wird das nämlich ganz komfortabel gesetzt.

Zum Thema Schrittweite: bei den meisten Aktoren wird die Position des Rollladens über die Laufzeit geschätzt. Das ist in der Regel nicht einmal zu 10% genau, insbesondere bei mehreren kleinen Schritten. Insofern wäre eine Angabe von 1%-Schritten eher in die Tasche gelogen.

LG

pah
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 13 September 2018, 12:43:36
Zitat von: Prof. Dr. Peter Henning am 13 September 2018, 12:41:56
Zum Thema Partymode: Könnte man das so ausbauen, dass diese Settings von einem Device (z.B. YAAHM-Device) übernommen werden ? Da wird das nämlich ganz komfortabel gesetzt.

Zum Thema Schrittweite: bei den meisten Aktoren wird die Position des Rollladens über die Laufzeit geschätzt. Das ist in der Regel nicht einmal zu 10% genau, insbesondere bei mehreren kleinen Schritten. Insofern wäre eine Angabe von 1%-Schritten eher in die Tasche gelogen.

LG

pah

Sofern ein passendes Event kommt kann man das sicher weiter verarbeiten. Sollte nicht das Problem.sein.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 13 September 2018, 13:13:53
Zitat von: CoolTux am 13 September 2018, 08:19:46
Bei den nicht so langen Präfix stimme ich Dir zu, aber einen Präfix brauchen sie. Wurde unter den Developern mal so Diskutiert und ich finde es sinnvoll.
Ok, mir war nicht klar, dass das mit den Präfixen sich auch auf "eigene" Readings und Attribute beziehen soll (mir ging es _nur_ um die Attributnamen im ASC-Device selbst, nicht an den Rollläden).

ZitatDas mit den 10er Schritten habe ich so übernommen von Bernd. 5 oder gar 1er Schritte machen ja noch weniger Sinn finde ich.
Geht da nur um die Frage, ob man was anderes setzen kann, nicht darum, was man im DropDown sieht (da finde ich die kleineren Schritte auch lästig. Aber neulich war doch jemand, der zwischen 1 (offen?) und 16 (komplett geschlossen?) benötigte? Das Setzen anderer Werte wäre dann ggf. über die Kommandozeile bzw. die ReadingsGroup möglich; meine aktuelle sieht in Teilbereichen 5-er Schritte vor...

Zitat
Auf alle Fälle empfehle ich sehr die neue Version ein zu spielen. Danach ist ein neustart erforderlich. Sollten Probleme auftauchen meldet sie mir bitte.
:) Wie gewohnt...

Danke!
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 13 September 2018, 13:35:37
Zitat von: Beta-User am 13 September 2018, 13:13:53
Geht da nur um die Frage, ob man was anderes setzen kann, nicht darum, was man im DropDown sieht (da finde ich die kleineren Schritte auch lästig. Aber neulich war doch jemand, der zwischen 1 (offen?) und 16 (komplett geschlossen?) benötigte? Das Setzen anderer Werte wäre dann ggf. über die Kommandozeile bzw. die ReadingsGroup möglich; meine aktuelle sieht in Teilbereichen 5-er Schritte vor...

Stimmt. Da wären 10er Schritte echt ungünstig. Man kann zwar immer noch per Hand andere Zahlen wählen, also über

attr DEVICENAME AutoShuttersControl_Closed_Pos 16

Aber das ist bisschen umständlich. Muss ich mal überlegen.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 13 September 2018, 13:41:36
Zitat von: CoolTux am 13 September 2018, 13:35:37
Aber das ist bisschen umständlich. Muss ich mal überlegen.

Solange es jetzt funktioniert (was ich unterstelle), bezog sich meine Frage eigentlich _nur auf die Doku_! Es gibt m.E. auch keinen Grund, die Diskussion auszuweiten, wenn es heute mit anderen Werten funktioniert. Dann sollte man _nur die Doku_ anpassen und nicht weiter drüber nachdenken!

Wer mag/muss, _kann_ das Attribut ja ändern (ggf. über die ReadingsGroup), und diese Option sollte der CR und ggf. dem Wiki zu entnehmen sein; da steht aber heute: nur 10-er Schritte zulässig...

Gruß, Beta-User
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Cluni am 13 September 2018, 13:45:50
Eventuell könnte man die Schrittweite anhand der offen/geschlossen Werte sinnvoll berechnen? Ich weiß - 16 in sagen wir mal 10 gleichmäßig verteilte Integer zu unterteilen wird schwierig. In dem Fall müsste man da dann vielleicht alle Werte als Dropdown anbieten. Wie man den Algorithmus zur Bestimmung der sinnvollen Unterteilung bauen könnte, müsste man halt mal überlegen. Kann man denn überhaupt das Dropdown zur Laufzeit verändern in einem Modul?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Deckoffizier am 13 September 2018, 13:48:31
Hallo CoolTux ,

Großes Danke für den Code deletereading RolladenDevice .AutoShuttersControl_InternalTimerFuncHash.

Hatte mir schon einen Wolf gesucht und probiert ohne Ende.
Heute Morgen ging der Rollladen dadurch hoch.

Mein Senf zur Positionsangabe, habe da auch erst mal  für mein UNIRoll Rollo rumexperimentiert.
Da die Einstellung über die Laufzeit geht wäre doch ein Slider  für mich pers. schöner als die 10 er Schrittweite und der Laie weiß nicht immer diesen Wert per Hand zu setzen. Hattest Du mir ja angeraten.
In Punkto Abweichungen, wenn ich es richtig verstanden habe wird doch an der obersten Stellung alles wieder synchronisiert ?

Werde ASC wohl auch mal an meinem Siro Rollo ausprobieren.
Auf ein graues Haar mehr oder weniger kommt es auch nicht mehr an  ;)

Gruß
Hans-Jürgen

Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Cluni am 13 September 2018, 13:48:36
Oder man sieht das Dropdown wirklich als Prozent und skaliert den Wert auf min/max (inkl. Rundung), bevor gesetzt wird!? Dann sollte man aber auf 5% Schritte gehen...
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 13 September 2018, 13:51:02
Zitat von: Cluni am 13 September 2018, 13:45:50
Eventuell könnte man die Schrittweite anhand der offen/geschlossen Werte sinnvoll berechnen? Ich weiß - 16 in sagen wir mal 10 gleichmäßig verteilte Integer zu unterteilen wird schwierig. In dem Fall müsste man da dann vielleicht alle Werte als Dropdown anbieten. Wie man den Algorithmus zur Bestimmung der sinnvollen Unterteilung bauen könnte, müsste man halt mal überlegen. Kann man denn überhaupt das Dropdown zur Laufzeit verändern in einem Modul?

Im Grunde geht es nicht um das fahren sondern um das Einstellen der Attribute. Ich habe für Full_Down und Full_Up 10er Schritte.
So kammt man natürlich nicht auf 16 und einer unserer User hatte Full down/up als 16



Zitat von: Beta-User am 13 September 2018, 13:41:36
Solange es jetzt funktioniert (was ich unterstelle), bezog sich meine Frage eigentlich _nur auf die Doku_! Es gibt m.E. auch keinen Grund, die Diskussion auszuweiten, wenn es heute mit anderen Werten funktioniert. Dann sollte man _nur die Doku_ anpassen und nicht weiter drüber nachdenken!

Wer mag/muss, _kann_ das Attribut ja ändern (ggf. über die ReadingsGroup), und diese Option sollte der CR und ggf. dem Wiki zu entnehmen sein; da steht aber heute: nur 10-er Schritte zulässig...

Gruß, Beta-User

Mann kann die alternative Oprion zum Einstellen, also zu Fuß über die FHEMWEB Kommandozeile per attr ja im Wiki festhalten.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Cluni am 13 September 2018, 13:56:25
Zitat von: CoolTux am 13 September 2018, 13:51:02
Im Grunde geht es nicht um das fahren sondern um das Einstellen der Attribute. Ich habe für Full_Down und Full_Up 10er Schritte.
So kammt man natürlich nicht auf 16 und einer unserer User hatte Full down/up als 16eile per attr ja im Wiki festhalten.

Das ist mir klar. Die Idee ist, dass du dem Rollladen ein min und einen max mitgibst, den man einstellen kann.  Der Wertebereich für zum Beispiel ganz zu (0) bis ganz offen (100) (oder anders herum) bleibt erhalten und wird zum Beispiel in 5% oder auch 10% Schritten angegeben. Der endgültige setvalue wird dann aber über die min und max Angabe berechnet und ggf. gerundet. Daher würde ich 5% Schritte empfehlen, da man dann auch bei 1..16 jeden Wert treffen kann mit einer Angabe von 0..100 in 5% Schritten. Das ginge bei 1ß% Schritten nicht.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 13 September 2018, 14:00:34
OK das verstehe ich. Aber wie oder wo stellst du die 16 ein. Irgendwoher muss er das mit 16 ja wissen.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 13 September 2018, 14:01:52
Zitat von: Deckoffizier am 13 September 2018, 13:48:31
Hallo CoolTux ,

Großes Danke für den Code deletereading RolladenDevice .AutoShuttersControl_InternalTimerFuncHash.

Hatte mir schon einen Wolf gesucht und probiert ohne Ende.
Heute Morgen ging der Rollladen dadurch hoch.

Mein Senf zur Positionsangabe, habe da auch erst mal  für mein UNIRoll Rollo rumexperimentiert.
Da die Einstellung über die Laufzeit geht wäre doch ein Slider  für mich pers. schöner als die 10 er Schrittweite und der Laie weiß nicht immer diesen Wert per Hand zu setzen. Hattest Du mir ja angeraten.
In Punkto Abweichungen, wenn ich es richtig verstanden habe wird doch an der obersten Stellung alles wieder synchronisiert ?

Werde ASC wohl auch mal an meinem Siro Rollo ausprobieren.
Auf ein graues Haar mehr oder weniger kommt es auch nicht mehr an  ;)

Gruß
Hans-Jürgen

Mit dem aktuell verfügbaren Modul sind solche Klimmzüge nicht mehr nötig. Mit dem set Befehl zum Aktualisieren der Timer wird der alte Hash automatisch gelöscht.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Cluni am 13 September 2018, 14:02:16
Na das musst du am Aktor einstellbar machen.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 13 September 2018, 14:04:04
Zitat von: Cluni am 13 September 2018, 14:02:16
Na das musst du am Aktor einstellbar machen.

Das wäre dann wieder ein Attribut mehr für eine kleine einmalige Sache. Ich würde sagen das rechnet sich nicht wirklich. Oder?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Deckoffizier am 13 September 2018, 14:04:59
Hallo,

das mit den 16 Sekunden war ich.
Ist aber noch nicht die ganze Wahrheit da die Laufzeit für hoch und runter unterschiedlich ist.
Musste die Zeit auf 21 ändern ist die Zeit für hoch, beim runter fahren greift ja die Endabschaltung bei 16 sek.
Sonst wurde der Rollladen nicht komplett zurück nach oben gefahren in pos 0.

Komisch nur musste die AutoShuttersControl_Open_Pos auf 1 setzen 0 wurde nicht angenommen.
Nun gut scheint schon echt knifflig zu sein hängt ja wohl auch vom Typ wie viel Intelligenz schon drin steckt.
Momentan macht es ja für mich wie es soll.

Gruß
Hans-Jürgen
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 13 September 2018, 14:06:16
Meine Güte, geht das wieder schnell hier...

Zitat von: CoolTux am 13 September 2018, 13:51:02
Mann kann die alternative Oprion zum Einstellen, also zu Fuß über die FHEMWEB Kommandozeile per attr ja im Wiki festhalten.
Danke für die Rückmeldung. Sehe ich genauso, dass man mind. erst mal sonst nichts tun sollte:

Wer was exotisches hat, soll halt eine andere Variante nutzen für's Einstellen als die angebotenen Dropdowns im Device selbst, wichtig ist nur, dass es funktioniert (tut es scheinbar).

Jede Art der Umrechnung dürfte erst mal zu Inkonsistenzen führen, das sollte man im (Modul-) Device selbst erledigen, sofern möglich, oder eben damit leben, dass die Wicklung dicker wird.

Just my2ct.

Wie gesagt, die Frage war _nur_ die nach der sachlichen Richtigkeit der (derzeitigen) Doku!

Zitat von: Cluni am 13 September 2018, 13:56:25
Das ist mir klar. Die Idee ist, dass du dem Rollladen ein min und einen max mitgibst, den man einstellen kann.  Der Wertebereich für zum Beispiel ganz zu (0) bis ganz offen (100) (oder anders herum) bleibt erhalten und wird zum Beispiel in 5% oder auch 10% Schritten angegeben. Der endgültige setvalue wird dann aber über die min und max Angabe berechnet und ggf. gerundet. Daher würde ich 5% Schritte empfehlen, da man dann auch bei 1..16 jeden Wert treffen kann mit einer Angabe von 0..100 in 5% Schritten. Das ginge bei 1ß% Schritten nicht.
Spontane Reaktion: eher dagegen. Kann nämlich z.B. sein, dass ich im Schlafzimmer gerne automatisiert nur zwischen 0 und 20% (=OpenPos) fahren will, aber beim Lüften/ganz offen auf 30%. Wenn da im Hintergrund noch weiter rumgerechnet wird, habe ich Bedenken, dass das insgesamt zu Merkwürdigkeiten führt. Dann lieber immer einen Absolutwert in der Hoffnung, dass im Aktorcode genug Toleranz drin ist, dass das auch auf Dauer halbwegs paßt...

Das dürfte für 99% der User einfacher zu durchschauen sein als eine Lösung, die (auf den ersten Blick) scheinbar mit Absolutwerten arbeitet, aber vom code her vorrangig auf Sonderlocken zielt und irgendwas im Hintergrund umwandelt. Insbesondere dann, wenn es Lösungsmöglichkeiten für die Sonderlocken gibt.

Gruß, Beta-User
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Cluni am 13 September 2018, 14:11:43
Zitat von: Beta-User am 13 September 2018, 14:06:16
Spontane Reaktion: eher dagegen. Kann nämlich z.B. sein, dass ich im Schlafzimmer gerne automatisiert nur zwischen 0 und 20% (=OpenPos) fahren will, aber beim Lüften/ganz offen auf 30%. Wenn da im Hintergrund noch weiter rumgerechnet wird, habe ich Bedenken, dass das insgesamt zu Merkwürdigkeiten führt. Dann lieber immer einen Absolutwert in der Hoffnung, dass im Aktorcode genug Toleranz drin ist, dass das auch auf Dauer halbwegs paßt...

Das dürfte für 99% der User einfacher zu durchschauen sein als eine Lösung, die (auf den ersten Blick) scheinbar mit Absolutwerten arbeitet, aber vom code her vorrangig auf Sonderlocken zielt und irgendwas im Hintergrund umwandelt. Insbesondere dann, wenn es Lösungsmöglichkeiten für die Sonderlocken gibt.

Es geht darum, dass man verschiedene Aktoren damit abdecken könnte. Wenn du dir einen Aktor kaufst, der halt nur mit 1 bis 16 gesteuert wird, dann hättest du sonst die Arschkarte und könntest ihn nicht oder nur über Umwegen mit dem Modul steuern.

Ich würde vorschlagen:
- min und max als Attribut anbieten, werden aber nicht vorbesetzt.
- wenn nicht besetzt wird wie gehabt (ohne Umrechnung) angesteuert
- wenn gesetzt, dann wird linear umgerechnet und entweder die Nachkommastellen abgeschnitten oder auf-/abgerundet
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Deckoffizier am 13 September 2018, 14:21:58
Hallo Cluni,

der Knackpunkt ist nicht unbedingt alleine der Aktor
ZitatEs geht darum, dass man verschiedene Aktoren damit abdecken könnte. Wenn du dir einen Aktor kaufst, der halt nur mit 1 bis 16 gesteuert wird, dann hättest du sonst die Arschkarte und könntest ihn nicht oder nur über Umwegen mit dem Modul steuern

sondern auch die Fenstergröße(Länge) also Rollladen die über Zeit gesteuert werden.
Deshalb fand ich Euer Modul auch so interessant da es wahrscheinlich nicht nur auf Homematic fixiert ist.

So wie ich etwas Luft habe probiere ich es auch  mit meinem Siro Rollo aus hat schon mal das Reading position statt pos.

Gruß
Hans-Jürgen
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 13 September 2018, 14:25:55
Wir sind uns einig, dass es super wäre, wenn alles so universell ist, dass wirklich alles, was so verfügbar ist an Aktoren auch angesteuert werden kann.
(@Deckoffizier: Schau mal das Rollo-Modul an, vielleicht ist das eine sinnvolle logische Zwischenschicht für dich).

Jedenfalls bei allen bisher diskutierten Modellen geht das, und der einzige Umweg ist der, dass man manuell per Kommandozeile bzw. graphisch/klickibunti per ReadingsGroup (die man ja entsprechend editieren und bei Bedarf vervielfältigen kann) die richtigen Vorbelegungswerte an die Rolläden bekommt.

Und das mit den Attributen ist ja eine nette Sache, aber dass "zu viele" m.E. nicht das Anwenderfreundlichste sind, hatte ich ja bereits (mit der Bitte, das ggf. bei Gelegenheit zu reduzieren) angemerkt; wenn man durch ein Attribut dann plötzlich ein gänzlich anderes Verhalten erzeugt, ist das auch erklärungsbedürftig und im Zweifel nicht besser wie die Anleitung für das "händische" Gradebiegen.

just my2ct. ;) Die Arbeit habt im Zweifel eh' ihr :) .
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 13 September 2018, 14:31:32
Die Umrechnung sollte nicht unser Modul machen, sondern das Modul welches Hardwareseitig das Rollo unterstützt. Es gibt offizielle und inoffizielle Einigungen wie man zum Beispiel Volume oder Mute oder was auch immer belegt. Das selbe gilt für Rolläden. Deswegen macht man ja Prozentangaben. 0 bis 100. Auf/Zu Zu/Auf.
Also sollte das Modul vom Ralladen dafür sorgen das die 100 Prozent für zu entsprechend umgerechnet werden auf die Laufzeit.

Meine Meinung.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Cluni am 13 September 2018, 14:32:16
Ja ok - dann kann man ja auch direkt den Fahrbefehl auch raus schmeißen und nur "pct" unterstützen. Und wahrscheinlich so einiges andere auch noch. Hätte ich so bei der Programmierung meiner Rollladensteuerung gedacht, dann würden heute wahrscheinlich einige Leute noch keine so komfortable Rollladensteuerung in Fhem haben.... just my2ct.... ;)
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Cluni am 13 September 2018, 14:33:06
Ach und die Fahrrichtung kann auch weg... :P
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 13 September 2018, 14:38:26
 :o

???

;D
Wo habe ich die Kurbel hin?!?
;D ;D ;D
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 13 September 2018, 14:41:53
FHEM set Befehle sind eine Sache. Du siehst ja das es auch set Befehle ohne passendes Reading gibt was auch doof ist.

Machen wir es so. Ich habe keine Zeit für sowas. Wenn ein Patch kommt oder ein Pull request können wir gerne drüber reden.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Deckoffizier am 13 September 2018, 14:47:45
Hallo Beta-User,

um Himmels Willen nur kein Streit....

Bin ja soweit zufrieden man kann sich ja auch zu Tode programmieren wenn man alles exotische mit abdecken will.
Für mich war eben die Laufzeitsteuerung nicht gerade ungewöhnlich kenne mich in den ganzen Modellen ja auch nicht aus.

Bis jetzt habe ich in FHEM für mich gesehen schon viel hinbekommen.

Danke für den Tip zum Modul Rollo hatte ich in der cmdRef nicht weiter gesehen gekannt.
Vom überfliegen her vermute ich, daß ich solch neckischen Sachen wie Astro eben auch dazu herum einbauen muss.
Man kann eben nicht alles haben oder muss sich das am besten passende Aussuchen deshalb bin ich hier erstmal mit ASC GERN dabei.

Gruß
Hans-Jürgen
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Cluni am 13 September 2018, 14:50:50
Zitat von: Beta-User am 13 September 2018, 14:38:26
Wo habe ich die Kurbel hin?!?
;D ;D ;D

;D ;D ;D ;D


Zitat von: CoolTux am 13 September 2018, 14:41:53
FHEM set Befehle sind eine Sache. Du siehst ja das es auch set Befehle ohne passendes Reading gibt was auch doof ist.

Machen wir es so. Ich habe keine Zeit für sowas. Wenn ein Patch kommt oder ein Pull request können wir gerne drüber reden.

Na klar kannst du das so machen - das ist und bleibt dein Modul! Ich wäre der letzte, der dir da einen Vorwurf macht, wenn du etwas machst, wie du es möchtest. Ich habe mir da ja auch nicht reinreden lassen. ;)
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Cluni am 13 September 2018, 14:52:23
Nein nein, Deckoffizier - hier gibt es keinen Streit. ;)
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 13 September 2018, 14:53:48
Zitat von: Cluni am 13 September 2018, 14:50:50
;D ;D ;D ;D

Na klar kannst du das so machen - das ist und bleibt dein Modul! Ich wäre der letzte, der dir da einen Vorwurf macht, wenn du etwas machst, wie du es möchtest. Ich habe mir da ja auch nicht reinreden lassen. ;)

Naja denk dran ohne Dein Skript gäbe es das Modul so in der Form sicherlich nicht. Ich tue mich immer schwer mit den Anfängen.
Aber wie gesagt wenn was geliefert wird baue ich es gerne ein.  :)
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Deckoffizier am 13 September 2018, 14:56:26
Hallo Cluni,

eine Bitte..
wie bekomme ich die ohne mein Zutun im zweiten UNIRoll Rollo quasi geerbten Readings wie oldPos wieder weg?
deletereading hat gestern leider nicht geholfen.

Gruß
Hans-Jürgen
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Cluni am 13 September 2018, 15:00:51
Na schwer ist die Formel ja nicht: y = x * (max - min) / 100 + min
Und das Ergebnis muss dann halt gerundet werden.

wobei:
x = Wert in % auf den gefahren werden soll

Im Anhang ist eine Excel-Tabelle, wo man mit min und max mal spielen kann. Und extra zwei Tabellen - einmal 5er Schritte und einmal 10er Schritte damit man es direkt sieht.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Cluni am 13 September 2018, 15:02:51
Zitat von: Deckoffizier am 13 September 2018, 14:56:26
Hallo Cluni,

eine Bitte..
wie bekomme ich die ohne mein Zutun im zweiten UNIRoll Rollo quasi geerbten Readings wie oldPos wieder weg?
deletereading hat gestern leider nicht geholfen.


Mit dem ROLLO-Modul kenne ich mich nicht aus. Keine Ahnung, warum das mit deleteReading nicht geklappt hat. Wer hat die Readings denn erzeugt?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Deckoffizier am 13 September 2018, 15:09:24
Hallo Cluni,

ZitatMit dem ROLLO-Modul kenne ich mich nicht aus. Keine Ahnung, warum das mit deleteReading nicht geklappt hat. Wer hat die Readings denn erzeugt?

Das würde ich auch gern wissen.  ;)

Nur Vermutung  ScanforShutters in ASC ??
In Deckung....

Gruß
Hans-Jürgen

Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Deckoffizier am 13 September 2018, 15:12:11
Hallo,

nur zu Info
mein Siro Rollo ließ sich auf Anhieb einbinden.
Scheint wohl mehr Logik im Modul/Hardware zu stecken in Puncto Nutzung von Position.

Gruß
Hans-Jürgen
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 13 September 2018, 15:15:50
Meine Güte, wieder ziemlich spät  und einige Beiträge weiter...

Zitat von: Cluni am 13 September 2018, 14:52:23
Nein nein, Deckoffizier - hier gibt es keinen Streit. ;)

;D ;D ;D

@Deckoffizier:
Wir verstehen uns schon, keine Sorge (denke ich zumindest ;D ).Der Hinweis auf das Rollo-Modul war nicht so gedacht, dass du ASC nicht einsetzen sollst!

So wie ich das verstanden habe, bildet das ROLLO-Modul nur eine Zwischenschicht ab, macht also die Umrechnung auf "100%" usw.. Nicht mehr, aber auch nicht weniger...

Also willkommen an Bord :) .
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 13 September 2018, 15:18:01
Ohne Dein zutun stimmt ja nicht ganz. Die sind bestimmt über Deine userReadings Versuche da hin gekommen. Hast Du denn noch userReadings in den Rolladen. Wenn ja lösche das Attribut oder Teile davon und lösche dann mit deletereading das Reading.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 13 September 2018, 15:23:02
Version 0.1.41 habe ich eben hochgeladen. Für heute ist damit Feierabend.
- die Dämmerungsphasen lassen sich nun zur Berechnung auch in den Rolladendevices einstellen. Rolladendevice hat Vorrang vor dem globalen Einstellungen im Moduldevice
- einige kleine Bugfixes, darunter der das im Moduldevice als Reading bei Räumen mit Umlauten nur immer ein Rolladendevice gelistet wurde.



Grüße
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: FunkOdyssey am 13 September 2018, 15:36:02
Ich muss mal kurz eine ganz andere Frage stellen:

Entfernt das Modul an irgendeinem Punkt die gesetzten Attribute AutoShuttersControl_.* ?
Ich habe versehentlich Jalousien vom Typ 1 angelegt, zu schnell "save" gedrückt und wollte nicht unbedingt manuell alle Attribute löschen, um sauber durchzustarten.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 13 September 2018, 15:40:43
Das Modul löscht nur alles wenn man das Moduldevice löscht.
Das werden alle Attribute und Readings welches vom Modul gesetzt werden entfernt.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: FunkOdyssey am 13 September 2018, 15:43:21
Okay, stimmt. Hat nach ner Neuanlage geklappt.

Ich hatte wohl das Attribut "AutoShuttersControl = x" vor dem Löschen des Moduls gelöscht. Danke.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: FunkOdyssey am 13 September 2018, 17:32:28
Zitat von: CoolTux am 13 September 2018, 15:23:02
- die Dämmerungsphasen lassen sich nun zur Berechnung auch in den Rolladendevices einstellen. Rolladendevice hat Vorrang vor dem globalen Einstellungen im Moduldevice

Das scheint bei mir weder im ASC-Device noch in den Rollläden zu funktionieren.
Gerade eingerichtet, aber nach den Änderung der Horizont-Attribute (von -9 bis +9) habe ich (auch nach eine "Renew-Timer") keine neuen Zeiten.
Nur die Änderung zwischen CIVIL, REAL & Co. wirkt sich aus.




Andere Frage:
Wenn ich den Astro-Modus ausgewählt habe, werden doch weiterhin "Early" und "Late" berücksichtigt, oder?
Liegt also die Astro-Zeit vor "Early" oder nach "Late" wird nicht die Astro-Zeit berücksichtigt, oder?
Das finde ich gut. Ich bin kurz davon ausgegangen, dass ich mich bei der Konfiguration vorab festlegen muss.





Gibt es so etwas wie ein "TimeOffset"?
Im Time-Modus ist das ja irrelevant, da wird später vermutlich "Rand_Minutes" aushelfen.
Beim Astro-Modus werde ich das wahrscheinlich über den Horizont feineinstellen müssen, oder?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 13 September 2018, 19:33:30
Zitat von: FunkOdyssey am 13 September 2018, 17:32:28
Das scheint bei mir weder im ASC-Device noch in den Rollläden zu funktionieren.
Gerade eingerichtet, aber nach den Änderung der Horizont-Attribute (von -9 bis +9) habe ich (auch nach eine "Renew-Timer") keine neuen Zeiten.
Nur die Änderung zwischen CIVIL, REAL & Co. wirkt sich aus.




Andere Frage:
Wenn ich den Astro-Modus ausgewählt habe, werden doch weiterhin "Early" und "Late" berücksichtigt, oder?
Liegt also die Astro-Zeit vor "Early" oder nach "Late" wird nicht die Astro-Zeit berücksichtigt, oder?
Das finde ich gut. Ich bin kurz davon ausgegangen, dass ich mich bei der Konfiguration vorab festlegen muss.





Gibt es so etwas wie ein "TimeOffset"?
Im Time-Modus ist das ja irrelevant, da wird später vermutlich "Rand_Minutes" aushelfen.
Beim Astro-Modus werde ich das wahrscheinlich über den Horizont feineinstellen müssen, oder?

Interessant. Gerade HORIZONT verwende ich selbst mit -3 Aber ich da gerne noch mal.
Early" und "Late" werden bei Astro berücksichtigt.
Ein TimeOffset wird es noch geben. Wenn alles sauber läuft.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: FunkOdyssey am 13 September 2018, 21:44:31
Zitat von: CoolTux am 13 September 2018, 19:33:30
Interessant. Gerade HORIZONT verwende ich selbst mit -3 Aber ich da gerne noch mal.


Kommando zurück.
Ich wusste nicht, dass ich auf Horizon wechseln muss, damit sich die Werte auswirken. Ich nahm an, dass sich das auch auf REAL & Co. auswirkt.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: FunkOdyssey am 13 September 2018, 21:49:38
Oje. Was mir gerade auffällt. Man kann über die GUI nicht mehr zurück auf "none" wechseln.
Ich rette mich wohl. Sollte aber gefixt werden.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 13 September 2018, 22:02:03
Zitat von: FunkOdyssey am 13 September 2018, 21:49:38
Oje. Was mir gerade auffällt. Man kann über die GUI nicht mehr zurück auf "none" wechseln.
Ich rette mich wohl. Sollte aber gefixt werden.

Wenn es um die Astro Einstellungen im Rollodevice geht, dann einfach löschen.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 14 September 2018, 11:13:11
Ich werde übers Wochenende versuchen die Attribute
Zitat
AutoShuttersControl_Offset_Minutes_Evening
AutoShuttersControl_Offset_Minutes_Morning
In die Steuerung mit ein zu bauen.



Grüße
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: FunkOdyssey am 14 September 2018, 12:16:33
Ich teste das Modul gerade mit zwei Jalousien.

AutoShuttersControl_Mode_Down: always
AutoShuttersControl_Mode_Up: absent
AutoShuttersControl_Down: astro
AutoShuttersControl_Up: time

Gestern Abend (13.09.) wurden die Jalousien erfolgreich runtergefahren.
Heute morgen - wie gewollt - nichts passiert.

Aber es sieht für mich danach aus, als würde heute Abend (14.09.) auch nichts mehr passieren:

Log Rolladensteuerung:

2018-09-13_17:28:06 Rolladensteuerung jal_test1_nextAstroTimeEvent: Thu Sep 13 18:55:28 2018
2018-09-13_17:28:20 Rolladensteuerung jal_test1_nextAstroTimeEvent: Thu Sep 13 19:47:39 2018
2018-09-13_18:55:28 Rolladensteuerung jal_test1_lastPosValue: 0
2018-09-13_19:47:39 Rolladensteuerung jal_test2_lastPosValue: 0
2018-09-13_19:47:39 Rolladensteuerung jal_test2_nextAstroTimeEvent: Fri Sep 14 08:00:00 2018
2018-09-13_19:47:39 Rolladensteuerung jal_test1_nextAstroTimeEvent: Fri Sep 14 08:00:00 2018
2018-09-14_08:00:01 Rolladensteuerung jal_test1_nextAstroTimeEvent: Sat Sep 15 08:00:00 2018
2018-09-14_08:00:01 Rolladensteuerung jal_test2_nextAstroTimeEvent: Sat Sep 15 08:00:00 2018


Im Device:
   READINGS:
     2018-09-14 08:00:01   AutoShuttersControl_Time_Sunrise Sat Sep 15 08:00:00 2018
     2018-09-14 08:00:01   AutoShuttersControl_Time_Sunset Sat Sep 15 19:25:44 2018


Man achte auf das Datum. Dort steht der 15. September. Das wäre erst morgen.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 14 September 2018, 12:58:36
Es sieht in der Tat danach aus. Welche Version hast Du aktuell im Einsatz. Ändert sich das Datum wenn du die Timer über set neu setzen lässt?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: FunkOdyssey am 14 September 2018, 13:45:33
Ja, dann ich die gewünschten Runterfahrzeiten heute Abend dort stehen.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 14 September 2018, 13:55:08
Zitat von: FunkOdyssey am 14 September 2018, 13:45:33
Ja, dann ich die gewünschten Runterfahrzeiten heute Abend dort stehen.

Welche Version hast Du verwendet?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: FunkOdyssey am 14 September 2018, 15:04:15
v0.1.41
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 14 September 2018, 15:04:30
Englische Commandref ist eingebaut. Vielen Dank an Beta-User.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 14 September 2018, 15:05:27
Zitat von: FunkOdyssey am 14 September 2018, 15:04:15
v0.1.41

Ok ist die neuste. Ich schaue noch mal und Du beobachtest bitte weiter. DANKE
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: FunkOdyssey am 14 September 2018, 15:09:33
Ich werde es beobachten. Sind bei mir aktuell auch noch Jalousien, bei denen ich eine falsche Fahrt verkraften kann. :-)
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 14 September 2018, 15:32:53
Aktuell arbeite ich am Hardware lock-out. Bin so gut wie durch.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 14 September 2018, 20:57:56
Ich habe eben Version 0.1.43 ins Git hoch geladen.
Es kam Support für hard lock-out sowie für AutoShuttersControl_Offset_Minutes_Evening, AutoShuttersControl_Offset_Minutes_Morning hinzu.
Bitte beachtet für Hard lock-out die Attribute
AutoShuttersControl_lock-out
AutoShuttersControl_lock-outCmd:inhibit,blocked


ACHTUNG!!!!
Wenn Ihr nicht alles löschen wollt, musst Ihr händisch an jedes Rolladenmodul folgendes ändern.
Im Attribut userattr muss AutoShuttersControl_lock-out:on,off zu AutoShuttersControl_lock-out:soft,hard geändert werden.
Ausserdem muss dann das eigentliche Attribut AutoShuttersControl_lock-out entsprechend neu gesetzt werden.


Es muss auf alle Fälle nach ändern der Attribute und dem einspielen der neuen Modulversion ein neustart durchgeführt werden.
Es gab noch einen Bug. In der letzen Version wurden die alten Timer beim neu setzen der Timer über renewSetSunriseSunsetTimer nicht gelöscht. Das habe ich in der aktuellen Version behoben.



Grüße
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 15 September 2018, 06:33:01
Leider gibt es immer noch falsche Zeiten wenn Morgens die Zeit für Abends am selben Tag noch mal berechnet wird. Ich habe da bereits einen Fix eingebaut bei mir und werde diesen dann morgen früh testen.


Grüße
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 15 September 2018, 12:33:55
Moin zusammen,
eben mal für die neue Version umgestellt. Zental sollte das so gehen (wenn man keine weiteren userattr nutzt):
attr AutoShuttersControl_lock-out=(on|off) AutoShuttersControl_lock-out soft

attr (Rolladen|Jalous).* userattr AutoShuttersControl_Antifreeze:off,morning AutoShuttersControl_Antifreeze:off,on AutoShuttersControl_AutoAstroModeEvening:REAL,CIVIL,NAUTIC,ASTRONOMIC,HORIZON AutoShuttersControl_AutoAstroModeEveningHorizon:-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9 AutoShuttersControl_AutoAstroModeMorning:REAL,CIVIL,NAUTIC,ASTRONOMIC,HORIZON AutoShuttersControl_AutoAstroModeMorningHorizon:-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9 AutoShuttersControl_Closed_Pos:0,10,20,30,40,50,60,70,80,90,100 AutoShuttersControl_Direction AutoShuttersControl_Down:time,astro AutoShuttersControl_GuestRoom:on,off AutoShuttersControl_Mode_Down:absent,always,off AutoShuttersControl_Mode_Up:absent,always,off AutoShuttersControl_Offset_Minutes_Evening AutoShuttersControl_Offset_Minutes_Morning AutoShuttersControl_Open_Pos:0,10,20,30,40,50,60,70,80,90,100 AutoShuttersControl_Partymode:on,off AutoShuttersControl_Pos_Cmd AutoShuttersControl_Pos_after_ComfortOpen:-2,-1,0,10,20,30,40,50,60,70,80,90,100 AutoShuttersControl_Pos_after_ComfortOpen:0,10,20,30,40,50,60,70,80,90,100 AutoShuttersControl_Rand_Minutes AutoShuttersControl_Roommate_Device AutoShuttersControl_Roommate_Reading AutoShuttersControl_Shading:on,off,delayed,present,absent AutoShuttersControl_Shading_Angle_Left:0,5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90 AutoShuttersControl_Shading_Angle_Right:0,5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90 AutoShuttersControl_Shading_BlockingTime_After_Manual AutoShuttersControl_Shading_BlockingTime_Twilight AutoShuttersControl_Shading_Brightness_Reading AutoShuttersControl_Shading_Brightness_Sensor AutoShuttersControl_Shading_Fast_Close:on,off AutoShuttersControl_Shading_Fast_Open:on,off AutoShuttersControl_Shading_Min_Elevation AutoShuttersControl_Shading_Min_OutsideTemperature AutoShuttersControl_Shading_Pos:10,20,30,40,50,60,70,80,90,100 AutoShuttersControl_Shading_Pos_after_Shading:-1,0,10,20,30,40,50,60,70,80,90,100 AutoShuttersControl_Shading_StateChange_Cloudy AutoShuttersControl_Shading_StateChange_Sunny AutoShuttersControl_Shading_WaitingPeriod AutoShuttersControl_Time_Down_Early AutoShuttersControl_Time_Down_Late AutoShuttersControl_Time_Up_Early AutoShuttersControl_Time_Up_Late AutoShuttersControl_Time_Up_WE_Holiday AutoShuttersControl_Up:time,astro AutoShuttersControl_Ventilate_Pos:10,20,30,40,50,60,70,80,90,100 AutoShuttersControl_Ventilate_Window_Open:on,off AutoShuttersControl_WindowRec AutoShuttersControl_WindowRec_subType:twostate,threestate AutoShuttersControl_lock-out:on,off room_map structexclude


Wegen der falschen Zeiten, ohne den Code im Detail zu kennen: Macht es Sinn, jeweils beim Aufruf zu unterscheiden, ob es sich um einen FHEM-Neustart, eine manuell angestoßene Berechnung (set ...) oder eine Neuberechnung innerhalb der Ausführung eines Timers handelt? (Kann sein, dass Fall 1 und 2 gleich zu behandeln sind). Dann könnte es eine Lösung sein, die "Ursache" als zusätzlichen optionalen Aufrufparameter in die Funktion zur Neuberechnung zu geben. (Nur eine Idee)

Gruß, Beta-User
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 15 September 2018, 12:36:09
Zitat von: Beta-User am 15 September 2018, 12:33:55
Moin zusammen,
eben mal für die neue Version umgestellt. Zental sollte das so gehen (wenn man keine weiteren userattr nutzt):
attr AutoShuttersControl_lock-out=(on|off) AutoShuttersControl_lock-out soft

attr (Rolladen|Jalous).* userattr AutoShuttersControl_Antifreeze:off,morning AutoShuttersControl_Antifreeze:off,on AutoShuttersControl_AutoAstroModeEvening:REAL,CIVIL,NAUTIC,ASTRONOMIC,HORIZON AutoShuttersControl_AutoAstroModeEveningHorizon:-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9 AutoShuttersControl_AutoAstroModeMorning:REAL,CIVIL,NAUTIC,ASTRONOMIC,HORIZON AutoShuttersControl_AutoAstroModeMorningHorizon:-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9 AutoShuttersControl_Closed_Pos:0,10,20,30,40,50,60,70,80,90,100 AutoShuttersControl_Direction AutoShuttersControl_Down:time,astro AutoShuttersControl_GuestRoom:on,off AutoShuttersControl_Mode_Down:absent,always,off AutoShuttersControl_Mode_Up:absent,always,off AutoShuttersControl_Offset_Minutes_Evening AutoShuttersControl_Offset_Minutes_Morning AutoShuttersControl_Open_Pos:0,10,20,30,40,50,60,70,80,90,100 AutoShuttersControl_Partymode:on,off AutoShuttersControl_Pos_Cmd AutoShuttersControl_Pos_after_ComfortOpen:-2,-1,0,10,20,30,40,50,60,70,80,90,100 AutoShuttersControl_Pos_after_ComfortOpen:0,10,20,30,40,50,60,70,80,90,100 AutoShuttersControl_Rand_Minutes AutoShuttersControl_Roommate_Device AutoShuttersControl_Roommate_Reading AutoShuttersControl_Shading:on,off,delayed,present,absent AutoShuttersControl_Shading_Angle_Left:0,5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90 AutoShuttersControl_Shading_Angle_Right:0,5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90 AutoShuttersControl_Shading_BlockingTime_After_Manual AutoShuttersControl_Shading_BlockingTime_Twilight AutoShuttersControl_Shading_Brightness_Reading AutoShuttersControl_Shading_Brightness_Sensor AutoShuttersControl_Shading_Fast_Close:on,off AutoShuttersControl_Shading_Fast_Open:on,off AutoShuttersControl_Shading_Min_Elevation AutoShuttersControl_Shading_Min_OutsideTemperature AutoShuttersControl_Shading_Pos:10,20,30,40,50,60,70,80,90,100 AutoShuttersControl_Shading_Pos_after_Shading:-1,0,10,20,30,40,50,60,70,80,90,100 AutoShuttersControl_Shading_StateChange_Cloudy AutoShuttersControl_Shading_StateChange_Sunny AutoShuttersControl_Shading_WaitingPeriod AutoShuttersControl_Time_Down_Early AutoShuttersControl_Time_Down_Late AutoShuttersControl_Time_Up_Early AutoShuttersControl_Time_Up_Late AutoShuttersControl_Time_Up_WE_Holiday AutoShuttersControl_Up:time,astro AutoShuttersControl_Ventilate_Pos:10,20,30,40,50,60,70,80,90,100 AutoShuttersControl_Ventilate_Window_Open:on,off AutoShuttersControl_WindowRec AutoShuttersControl_WindowRec_subType:twostate,threestate AutoShuttersControl_lock-out:on,off room_map structexclude


Wegen der falschen Zeiten, ohne den Code im Detail zu kennen: Macht es Sinn, jeweils beim Aufruf zu unterscheiden, ob es sich um einen FHEM-Neustart, eine manuell angestoßene Berechnung (set ...) oder eine Neuberechnung innerhalb der Ausführung eines Timers handelt? (Kann sein, dass Fall 1 und 2 gleich zu behandeln sind). Dann könnte es eine Lösung sein, die "Ursache" als zusätzlichen optionalen Aufrufparameter in die Funktion zur Neuberechnung zu geben. (Nur eine Idee)

Gruß, Beta-User

Nach unendlichen hin und her denke ich die Lösung gefunden zu haben. Ich beobachte und gebe wenn dann morgen Abend eine neue Version frei.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 16 September 2018, 07:22:25
Ich habe Version 0.1.45 soeben ins Git geladen. Bei mir wurden gestern abend und heute morgen die Zeiten korrekt berechnet, daher denke ich das wir dieses Thema abschließen können.

Ein Update ist auf jeden Fall zu empfehlen.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 16 September 2018, 09:02:24
Moin,
habe die 0.1.45 vorhin eingespielt. Vorhin war genauer gesagt zwischen der Zeit für's Hochgehen unter der Woche und am $we.

Ergebnis: Die Timer stehen auf heute abend.

Ich gehe mal davon aus, dass ich die Rollläden daher heute manuell öffnen werde. Ist zwar kein Beinbruch, aber "eigentlich" sollte m.E. das Wochenende ebenfalls bei der Berechnung der neuen Timer berücksichtigt werden. (Betrifft zwar nur Neustarts, dürfte aber trotzdem immer mal wieder den einen oder anderen irritieren, der den ruhigen So.-Morgen für updates etc. nutzt).

Schönes WE,

Beta-User
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 16 September 2018, 09:39:51
Kannst du mir da bitte Zeiten geben. Reicht so in etwa, muss nicht genau sein. Also auf welche Uhrzeit standen die Hochfahrzeiten und um welche Uhrzeit hast du neugestartet. Sicher daß es noch vor Sonnenaufgang war? Bei mir war schon lange Sonnenaufgang heute morgen wie ich das Modul hoch geladen habe.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 16 September 2018, 11:09:16
Alle Zeitangaben beziehen sich auf die Zeitzone Berlin usw..

Normale Morgens-Zeit: 6:45, WE-Time-up: 9:30
Einspielen des Moduls war kurz vor 8 (logischerweise nach deiner Info bzw. dem Hochladen zu github, also nach Sonnenaufgang und wie geschrieben vor der WE-Time).

Bis dato sind nur die Rolläden offen, die wir manuell geöffnet haben. Die Frühtimer scheinen daher verloren gegangen zu sein (bzw. die Info, dass auf awake etc. zu reagieren ist oder noch eine Aktion aussteht).

Reicht das so?

Was mir noch aufgefallen ist: die angezeigten Timer weichen jetzt leicht voneinander ab (heute nur in den Sekundenangaben). Absicht oder dauert das so lange, bis die Timer erstellt sind?

Gruß, Beta-User
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 16 September 2018, 11:14:33
Zitat von: Beta-User am 16 September 2018, 11:09:16
Alle Zeitangaben beziehen sich auf die Zeitzone Berlin usw..

Normale Morgens-Zeit: 6:45, WE-Time-up: 9:30
Einspielen des Moduls war kurz vor 8 (logischerweise nach deiner Info bzw. dem Hochladen zu github, also nach Sonnenaufgang und wie geschrieben vor der WE-Time).

Bis dato sind nur die Rolläden offen, die wir manuell geöffnet haben. Die Frühtimer scheinen daher verloren gegangen zu sein (bzw. die Info, dass auf awake etc. zu reagieren ist oder noch eine Aktion aussteht).

Reicht das so?

Was mir noch aufgefallen ist: die angezeigten Timer weichen jetzt leicht voneinander ab (heute nur in den Sekundenangaben). Absicht oder dauert das so lange, bis die Timer erstellt sind?

Gruß, Beta-User
Also WE-Time wird doch noch gar nicht unterstützt? Werden doch nur die Attribute unterstützt welche in der Commandref stehen. Oder verstehe ich Dich gerade falsch?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 16 September 2018, 11:28:57
 :o , ok.

Nochmal in die CR zu sehen hatte ich nicht mehr auf dem Schirm, da das Attribut ja schon vorhanden ist.

Aber dann ist folgendes anzumerken: Wären meine anderen Rollläden da schon offen gefahren gewesen (was eigentlich bei Nichtberücksichtigung des $we hätte so sein sollten), hätte ich vermutlich dran gedacht. Aber das war eben auch nicht der Fall. (Da war aber noch die Vorversion aus dem github aktiv, kann sein, dass dieses Verhalten zwischenzeitlich geändert wurde). Daher kam meine Unterstellung, dass das am WE liegt.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 16 September 2018, 12:14:34
Ich werde das Thema WE und Feiertag als nächstes mal angehen.

Wie viele Rollos hast Du eingebunden? Ich habe 10
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 16 September 2018, 12:27:46
16 Aktoren
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 16 September 2018, 12:30:46
Wie verhält sich FHEM bei Dir wenn Du die Timer von Hand neu setzt?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 16 September 2018, 12:40:06
Folgender Test: "set ... renew..." ausgelöst, neues Fenster mit einem Raum geöffnet.

Keine spürbare Verzögerung (Hardware siehe Signatur).

List sieht so aus:

     2018-09-16 12:34:58   Jalousie_Links_nextAstroTimeEvent Sun Sep 16 20:08:40 2018
     2018-09-16 12:34:58   Jalousie_Mitte_nextAstroTimeEvent Sun Sep 16 20:15:10 2018
     2018-09-16 12:34:58   Jalousie_Rechts_nextAstroTimeEvent Sun Sep 16 20:15:26 2018
     2018-09-16 12:34:58   Jalousie_WZ_nextAstroTimeEvent Sun Sep 16 20:15:32 2018
     2018-09-16 12:34:59   Rolladen_Bad_OG_nextAstroTimeEvent Sun Sep 16 20:15:13 2018
     2018-09-16 12:34:59   Rolladen_Buero_Ost_nextAstroTimeEvent Sun Sep 16 20:15:16 2018
     2018-09-16 12:34:59   Rolladen_Buero_Sued_nextAstroTimeEvent Sun Sep 16 20:15:17 2018
     2018-09-16 12:34:59   Rolladen_Chillraum_nextAstroTimeEvent Sun Sep 16 20:15:57 2018
     2018-09-16 12:34:59   Rolladen_Kind1_Sued_nextAstroTimeEvent Sun Sep 16 20:15:30 2018
     2018-09-16 12:34:59   Rolladen_Kind2_West_nextAstroTimeEvent Sun Sep 16 20:15:47 2018
     2018-09-16 12:34:59   Rolladen_Kind3_Nord_nextAstroTimeEvent Sun Sep 16 20:15:58 2018
     2018-09-16 12:34:59   Rolladen_Kind3_West_nextAstroTimeEvent Sun Sep 16 20:15:32 2018
     2018-09-16 12:34:59   Rolladen_SZ_Nord_nextAstroTimeEvent Sun Sep 16 20:15:41 2018
     2018-09-16 12:34:59   Rolladen_SZ_West_nextAstroTimeEvent Sun Sep 16 20:15:04 2018
     2018-09-16 12:34:59   Rolladen_Treppenhaus_nextAstroTimeEvent Sun Sep 16 20:15:51 2018
     2018-09-16 12:34:59   Rolladen_WZ_SSO_nextAstroTimeEvent Sun Sep 16 20:15:02 2018
     2018-09-16 12:34:59   Rolladen_WZ_SSW_nextAstroTimeEvent Sun Sep 16 20:15:23 2018

Weist also auch nicht auf größere Verzögerungen oder Schleifen hin. Man sieht auch die unterschiedlichen Sekundenangaben (nur eines der Attr. steht auf HH:MM).
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 16 September 2018, 12:52:17
Super. Vielen Dank
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 17 September 2018, 06:42:52
Guten Morgen,

Das Wochenende verlief ohne Probleme, bei mir werden die Zeiten nun korrekt angelegt. Werde mich nun an die Umsetzung der Wochenend und Urlaubszeiten machen.


Grüße
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 17 September 2018, 07:09:14
Ebenfalls einen guten Morgen.

Timer scheinen auch hier soweit zu passen. Allerdings sind heute morgen in zwei Räumen die Rollläden nicht gefahren, nämlich in denen, in denen sich der Status der Bewohner jeweils nicht geändert hatte (beide "absent").
Da, wo es keine Bewohner gibt, paßt es, und soweit ich das beurteilen kann auch dort, wo den Rollläden "bewegliche Bewohner" zugeordnet sind.

Gruß, Beta-User
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 17 September 2018, 07:48:48
Zitat von: Beta-User am 17 September 2018, 07:09:14
Ebenfalls einen guten Morgen.

Timer scheinen auch hier soweit zu passen. Allerdings sind heute morgen in zwei Räumen die Rollläden nicht gefahren, nämlich in denen, in denen sich der Status der Bewohner jeweils nicht geändert hatte (beide "absent").
Da, wo es keine Bewohner gibt, paßt es, und soweit ich das beurteilen kann auch dort, wo den Rollläden "bewegliche Bewohner" zugeordnet sind.

Gruß, Beta-User

Vielen vielen Dank für Deine super Tests. Schaue ich mir heute im laufe des Tages mal an.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 17 September 2018, 07:58:33
Kannst Du mir kurz sagen was bei diesen Rolladen im Attribut AutoShuttersControl_Mode_Down drin stand.
Und Du hast für den Rolladen einen Bewohner angegeben?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 17 September 2018, 08:21:19
Attribut steht (bei allen, auch den Fahrenden) auf "always" (auch für ..._Up).

Es ist - dort wo es Bewohner gibt - je nur einer angegeben. Der Unterschied liegt ggf. nur darin, dass die beiden für's Nichtfahren "verantwortlichen" Bewohner Dummy-Devices sind, im dritten Raum ist es eine structure (bei den aktuellen Sonnenstandszeiten mit Statuswechsel zwischen Schließen und Öffnen bzw. (abends) umgekehrt). 
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 17 September 2018, 08:25:55
ok.
Steht im Moduldevice für die beiden Rolläden ein $NAME_lastDelayPosValue drin? Mit der Uhrzeit wo sie heute morgen hätten fahren sollen?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 17 September 2018, 08:43:47
Nein, es stehen dort (in den Rolladen-Devices) jeweils nur 2 ASC-Readings für die Morgens- und Abends-Zeiten. Auch im ASC-Modul-Device ist nichts spezielles zu erkennen, auch jeweils nur 2 Readings (lastPosValue und nextAstroTimeEvent).
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 17 September 2018, 08:48:47
Ok dann muß ich das mal simulieren. Bin gerade etwas ratlos.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 17 September 2018, 13:17:27
Ich hänge etwas beim Urlaubskalender. Wenn ich beim letzten erstellen der Timer vor dem nächsten Sonnenaufgang (also Abends) abfrage ob Urlaub ist oder nicht, passt es für den ersten Urlaubstag nicht denn Abends ist noch nicht Urlaub, erst Mitternacht.
Alternative, ich setzte Abends den normalen Timer und morgens bei der Ausführung prüfe ich ob Urlaubstag ist und stelle den Timer dann zur Not neu. Aber bis dahin wird einem eine andere Zeit angezeigt.

Weitere Überlegungen?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 17 September 2018, 13:35:34
An sich würde mich eine Prüfung zum Ausführungszeitpunkt nicht stören, aber gleich direkt die richtige Zeit anzuzeigen, ist natürlich schicker ;) .

holiday-Devices kennen den morgigen Status (Reading "tomorrow"). Könnte man bequem verwenden, hat aber den Nachteil dass man das für mehrere Devices zulassen sollte (ich nutze neuerdings 2, die in global über holiday2we eingebunden sind; könnte man auch darüber (Umweg über Abfrage des Attributs an global) abfackeln).
Vielleicht sollte/kann man es an Urlaubs-Devices auch berücksichtigen, wenn es ein "tomorrow"-Reading gibt?

Sehe das aber eher als Ergänzung an, denn $we+Urlaubs-Gerät sollte m.E. in jedem Fall auch zum Ausführungszeitpunkt geprüft werden, sonst sind m.E. Irritationen von Leuten vorprogrammiert, die die Zusammenhänge nicht kennen. Und an einen Dummy ein tomorrow-Reading zu bekommen, ist zwar nicht schwer, aber auch nicht "Standard".
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Cluni am 17 September 2018, 13:40:54
Das und die Zeitumstellung war bei mir der Grund, warum ich die Berechnung um 3:05Uhr gemacht habe. Ist doch nicht schlimm, wenn die Zeiten für morgens erst in der Nacht gemacht werden!?

Andererseits: Ich habe nicht mehr im Kopf, wie die Prüfung auf Urlaubstag aussieht - könnte man da nicht ggf. die Anfrage für den nächsten Tag stellen?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: kjmEjfu am 17 September 2018, 13:43:51
Es könnte aber sein, dass jemand an Urlaubstagen früher aufsteht als an normalen Tagen. Denkbar z.B. bei Leuten im Schicht- oder Spätdienst. Wenn der Timer dann erst zum Ausführungszeitpunkt geprüft würde, so wäre dies vermutlich zu spät.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Cluni am 17 September 2018, 13:45:05
Oh, das macht dann aber die Prüfung etwas schwieriger. Darf dann natürlich nur auf morgen abgefragt werden, wenn die Aktualisierung zu einem bestimmten Zeitpunkt gemacht wird. Sonst muss ja auch heute abgefragt werden...

EDIT: Das war auf meine Idee bezogen...
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 17 September 2018, 13:54:57
Eine Tomorrow Prüfung war auch jetzt mein letzter Gedankenansatz und ich denke ich werde ihn beibehalten. Es muß also zwingend ein tomorrow Reading im Urlaubs oder Feiertags Device vorhanden sein.

Zwei Devices können wieder über eine structure abgebildet werden. Dafür ist sie da.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 17 September 2018, 14:06:00
An sich fand ich die 3:05-Uhr Variante auch mal ok.

Jetzt würde ich sagen, dass auf jeden Fall nach Ablauf des Spät-Timers die Zeit für den nächsten Tag gleich richtig berechnet (und angezeigt) werden sollte, um kmjEjufu's Einwand zu berücksichtigen. Das erfordert aber dann m.E. eine recht umfangreiche Prüfung vorneweg, es sei denn, man würde schlicht immer den frühesten Termin aus allen Angaben nehmen, dann bei dessen Ablauf die Bedingung ($we) prüfen und ggf. den nächsten setzen.

Für ganz flexibel Lösungen wie sie z.B. für schichtende Menschen erforderlich sind, wäre dann aber vermutlich eine sinnvolle Handhabung der Residents anzuraten - bei asleep findet ja keine Fahrt statt; das kann man über einen ical-Kalender recht gut steuern, ohne immer eine Vielzahl von Attributen zu ändern.

Zitat von: CoolTux am 17 September 2018, 13:54:57
Zwei Devices können wieder über eine structure abgebildet werden. Dafür ist sie da.
Dafür ist m.E. das Attribut in global da, oder etwa nicht? Es macht m.E. keinen Sinn, jeden User für dieselbe Funktionalität eine Sonderlocke bauen zu lassen. Das Modul kann m.E. bequem einmal zu Tagesbeginn (oder bei der ersten erforderlichen Prüfung des Tages) prüfen, ob morgen $we wahr sein wird und ein zusätzlicher optionaler Urlaubs-Dummy ein tomorrow-Reading hat. Eines wahr, alles wahr. Keine Magie, kein zusätzliches Device, super Service ;) .

Just my2ct.

EDIT: ggf. auch mehrere Urlaubs-Dummys mit beliebigen Readingnamen: "Device:Reading,Device2:Readingb,..." Ist eine einfache "foreach" mit einem split.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: kjmEjfu am 17 September 2018, 14:15:32
Zitat von: CoolTux am 17 September 2018, 13:54:57
Eine Tomorrow Prüfung war auch jetzt mein letzter Gedankenansatz und ich denke ich werde ihn beibehalten. Es muß also zwingend ein tomorrow Reading im Urlaubs oder Feiertags Device vorhanden sein.

Hmm, das würde aber bedeuten, man benötigt auf jeden Fall pro betroffener Person auch ein Urlaubsdevice. Ich glaube, es gibt viele Dinge, für die man das Residents-Modul mal erweitern könnte  ;)

Im Moment steuere ich, Clunis Code, einfach nur das jeweilige Reading über einen Kalender. Dadurch kann ich auch, wenn z.B. ein Kind krank ist und daher daheim bleibt, einfach im Kalender was eintragen und das entsprechende Notify sorgt für eine spätere Rollofahrt.
Das kann ich auch von unterwegs per Handy machen.
Am Holiday-Device was zu ändern, ist etwas umständlicher und hat einen geringeren WAF.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 17 September 2018, 14:34:31
Persönlich verstehe ich das mit dem anders fahren am WE oder im Urlaub eh nicht. Zu mindest nicht da wo Schlafräume sind und das wichtig wäre.
Nun habe ich persönlich auch nur Innenrollos. Keine Ahnung ob es wichtig ist das im Wohnzimmer oder der Küche die Rollos am WE bis zur frühsten Fahrzeit für WE unten bleiben und nicht mit dem Sonnenaufgang wie sonst auch immer auf fahren.

Es sollte wenn dann aber sich eh nichts ändern denke ich. Es sollte reichen wenn Du im Kalender den Eintrag machst.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Cluni am 17 September 2018, 14:38:23
Ich glaube so ein Außenpanzer ist etwas geräuschintensiver, als ein Innenrollo. Davon darf bei uns zu Hause keiner zu früh hoch gehen... [emoji23] [emoji85] [emoji86]


Gesendet von iPhone mit Tapatalk
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 17 September 2018, 14:40:14
Zitat von: Cluni am 17 September 2018, 14:38:23
Ich glaube so ein Außenpanzer ist etwas geräuschintensiver, als ein Innenrollo. Davon darf bei uns zu Hause keiner zu früh hoch gehen... [emoji23] [emoji85] [emoji86]


Gesendet von iPhone mit Tapatalk

Das Argument leuchtet mir ein.
Dann muß nur dafür gesorgt werden das die Kalenderdummys entsprechend mit 0 oder 1 versorgt werden.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 17 September 2018, 14:42:43
(wieder mal zu langsam beim tippen, aber da fertig...)
Zitat von: CoolTux am 17 September 2018, 14:34:31
Persönlich verstehe ich das mit dem anders fahren am WE oder im Urlaub eh nicht.
Am WE (bzw. an Feiertagen) hat es etwas damit zu tun, dass Außenrollläden etwas lauter sind als Innenrollos: Man stört die Nachbarn und die noch schlafenden Bewohner einfach per default später. Das ist daher m.E. sinnvoll, insbesondere, wenn man nicht noch eine Ladung Residents generieren will, nur um diese Funktionalität darüber hinzubiegen.

Urlaub: Ist ähnlich, nur dass hier sinnvoller Weise auch noch die Frage des Aufenthaltsorts eine Rolle spielt. Da würde ich also sagen, dass diese Frage auf der Ebene der Residents abgefrühstückt werden sollte. Dass ich das gerne so haben will, dass (lokale Schul-)Ferien wie ein Feiertag zu behandeln sein sollen, ist eine Sonderlocke, die aber von holiday2we ausdrücklich so vorgesehen ist. Jedenfalls sind mehrere holiday-Dateien für holiday2we kein Sonderfall.

Zitat von: kjmEjfu am 17 September 2018, 14:15:32Hmm, das würde aber bedeuten, man benötigt auf jeden Fall pro betroffener Person auch ein Urlaubsdevice.
Hmm, ob man das pro Resident braucht? Aber der Gedanke ist jedenfalls nicht ganz von der Hand zu weisen, dass individuelle morgige Besonderheiten berücksichtig werden sollten.
An sich war ich aber mal der Ansicht, dass dafür die states der Residents da sind (insbes. asleep), was jeweils zum Ausführungszeitpunkt berücksichtigt werden sollte.

Zitat von: kjmEjfu am 17 September 2018, 14:15:32
Ich glaube, es gibt viele Dinge, für die man das Residents-Modul mal erweitern könnte  ;)
Jup, z.B. Angaben zur IP des Smartphone und den Telegram-User; darüber versuche ich grade neben den anderen Dingen im Rahmen dieses Tests die Anwesenheit zu steuern bzw. zu manipulieren. Ist aber nicht so ganz trivial, das sehr flexibel zu gestalten...

Zitat
Am Holiday-Device was zu ändern, ist etwas umständlicher und hat einen geringeren WAF.
Mit holiday-Device war ein holiday nach commandref gemeint, nicht irgendein Dummy. Der ist in der Regel einheitlich pro Bundesland (für Weihnachten,, Ostern usw.) und ändert sich praktisch nie.
Neulich habe ich dann noch ein notify gebastelt, das aus dem ical-Ferienkalender jeden Freitag eine jeweils aktuelle holiday-Datei generiert. Das gilt dann aber für's ganze Haus.

Manuell in diesen Dateien rumzumalen war nie die Intention.

Urlaube sollte man anders abfangen, zumal da der Ort ein anderer sein kann und daher eine automatisierte Erkennung durch irgendeinen Code erklärungsbedürftig für den Ersteller der Kalendereinträge wäre.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: kjmEjfu am 17 September 2018, 14:56:57
Zitat von: Beta-User am 17 September 2018, 14:42:43
Urlaube sollte man anders abfangen, zumal da der Ort ein anderer sein kann und daher eine automatisierte Erkennung durch irgendeinen Code erklärungsbedürftig für den Ersteller der Kalendereinträge wäre.

deshalb ist halt die Frage, wie man das generell abfängt.

Letztlich gibt es ja verschiedene Gründe, weshalb jemand zuhause bleibt:
- Ferien (betrifft schulpflichtige Kinder und tlw. Lehrer)
- Urlaubstage
- bewegliche Ferientage
- Krankheitstage
- Schichtdienst
- Feiertag
- ...

Vermutlich hat jeder da seine ganz eigene Logik, was an solchen Tagen passieren soll.
Von daher macht es aus meiner Sicht Sinn, wenn jeder - mit welchem Mittel auch immer - selber dafür verantwortlich ist, dass im jeweiligen Rollo ein entsprechendes Reading auf 0 oder 1 steht.

Idee: Wenn die normale Neuberechnung läuft, dann wird Reading am Device (oder wenn nicht gesetzt am ASC-Device) ausgewertet (0 oder 1) und entsprechend früh oder spät gefahren. Zusätzlich prüft das Modul über sich das Reading ändert (Event) und führt in dem Fall eine nachträgliche Anpassung durch.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: kjmEjfu am 17 September 2018, 15:00:22
Zitat von: Beta-User am 17 September 2018, 14:42:43
An sich war ich aber mal der Ansicht, dass dafür die states der Residents da sind (insbes. asleep), was jeweils zum Ausführungszeitpunkt berücksichtigt werden sollte.

stimmt, aber letztlich könntest der Resident auch nur deshalb "asleep" sein, weil er verpennt hat. Da würde das hochfahrende Rollo eventuell als Notwecker helfen  ;)
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 17 September 2018, 15:18:15
Zitat von: kjmEjfu am 17 September 2018, 14:56:57
Vermutlich hat jeder da seine ganz eigene Logik, was an solchen Tagen passieren soll.
Grundsätzlich sehe ich das auch so. Aber wer $we nutzt und darüber bzw. über holiday2we zentrale Vorgaben macht, sollte erwarten dürfen, dass das schlicht und einfach so, wie es überall Auswirkungen hat auch hier beachtet wird; das ist eine zentrale FHEM-Funktionalität. Aus diesem Grund bin ich etwas vergrätzt, wenn das irgendwie in Frage gestellt wird, sondern adressiere die klare Erwartung, dass es hier nicht erforderlich wird, dafür nochmal einen Würgaround zu kreieren.
Die betreffende Info sollte dementsprechend auch zentral für alle Rolläden beachtet werden.

Alles andere kann man diskutieren, was die Bewertung sonstiger Sachverhalte angeht, völlig korrekt. Nur, wenn jemand aus einem Ferien- oder Urlaubstag oder einer Spätschicht ein $we macht, ist das eben eine Wahl, die vor allem anderen beachtlich ist. 

Was also Urlaube (stellvertretend für alle anderen ggf. auftretenden voraussehbaren Abweichungen) angeht:
Wer einen Urlaubstag wie einen $we-Tag behandelt wissen will, ohne dafür eine (auch für alle anderen Mitbewohner gültige!) holiday-file zu editieren, sollte nach meiner Ansicht die Option haben, den morgigen Status zur Berücksichtigung _global oder individuell am einzelnen Rolladen_ irgendwo hin zu schreiben. Das Befüllen mag dann jeder so machen, wie er das für richtig hält.

Und ob und inwieweit "asleep" zwangsweise unterbrochen werden sollte, ist m.E. auch woanders festzulegen. Von ASC wünsche ich mir jedenfalls keine Zwangsbeglückung in diese Richtung, und sei sie noch so angebracht ::) .

Just my2ct.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 17 September 2018, 15:59:49
Ich habe es nun so gebaut das we berechnet und we2holiday beachtet wird. Ausserdem ist es möglich ein Device an zu geben welches 0 oder 1 für Urlaub oder Ferien bereit hält.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 17 September 2018, 16:07:00
Zitat von: CoolTux am 17 September 2018, 15:59:49
Ich habe es nun so gebaut das we berechnet und we2holiday beachtet wird. Ausserdem ist es möglich ein Device an zu geben welches 0 oder 1 für Urlaub oder Ferien bereit hält.
Danke!

Device-STATE oder Reading am Device? (Device:Reading wäre m.E. optimal).

Das ist dann eine zentrale Vorgabe für die Installation, oder?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 17 September 2018, 16:10:12
Zitat von: Beta-User am 17 September 2018, 16:07:00
Danke!

Device-STATE oder Reading am Device? (Device:Reading wäre m.E. optimal).

Das ist dann eine zentrale Vorgabe für die Installation, oder?

Reading state

Wie meinst das mit zentrale Stelle?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 17 September 2018, 16:49:00
Zitat von: CoolTux am 17 September 2018, 16:10:12
Reading state
Was spricht gegen Device:Reading? Das zusätzliche split?
Ich fände das auf Reading-Basis besser, ich mag einfach die vielen Dummys (und Event-Handler) nicht, die man sonst benötigt, nur um irgendwas von irgendwo nach nirgendwo umzupacken. Sollte man den Leuten beibringen, dass das mit etwas Intelligenz vermieden werden kann ;) .
(Darf ich nochmal an das Temperatur-Dinges erinnern; auch da wäre es kein Hexenwerk, die zwei Attribute zu einem zusammenzuführen... Sollte halt einheitlich sein).

Zitat von: CoolTux am 17 September 2018, 16:10:12
Wie meinst das mit zentrale Stelle?
Wenn das hier gemeint ist:
ZitatDas ist dann eine zentrale Vorgabe für die Installation, oder?
Will nur heißen: Diese Geräteangabe ist am ASC-Device zu setzen und betrifft (wie $we) alle Rollläden, die Angabe ist nicht in jedem einzelnen Rollladen zu machen bzw. möglich (wer stattdessen das will, soll seinen Resident schlafen legen ;) ).
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 17 September 2018, 17:12:06
Ich Dummerschen. Kann mir das ganze ja sparen mit tomorrow. Ich setze das Device für Urlaub oder so (so wie Du gesagt hast) am Moduldevice und reagiere dann einfach auf den Event der Mitternacht kommt oder nicht.
Das Split Thema überlege ich mir noch. Hat ja noch Zeit.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 17 September 2018, 17:22:24
Na ja, was holiday (2we) angeht, kann tomorrow schon heute berücksichtigt werden bei der Berechnung der neuen Timer. Ist also früher aktuell. Aber notifyDev auch auf das zusätzliche Device zu legen, kann jedenfalls bereits um Mitternacht zur Neuberechnung führen (aber Achtung, da sollte dann $we direkt berücksichtigt werden, nicht mehr holiday:tomorrow).

Die Änderung von $we wirft keine Events, jedenfalls, soweit mir bekannt. Das muß man also anders abfrühstücken.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 17 September 2018, 17:25:39
Zitat von: Beta-User am 17 September 2018, 17:22:24
Na ja, was holiday (2we) angeht, kann tomorrow schon heute berücksichtigt werden bei der Berechnung der neuen Timer. Ist also früher aktuell. Aber notifyDev auch auf das zusätzliche Device zu legen, kann jedenfalls bereits um Mitternacht zur Neuberechnung führen (aber Achtung, da sollte dann $we direkt berücksichtigt werden, nicht mehr holiday:tomorrow).

Die Änderung von $we wirft keine Events, jedenfalls, soweit mir bekannt. Das muß man also anders abfrühstücken.

Meine Aussage bezog sich nur auf das selbst angelegte Dummydevice welches über ein notify gefüttert wird welches wiederum einen ical Kalender auswertet.
Kannst du mir kurz einen Link geben für holiday und holiday: tomorrow? Aktuell lese ich lediglich das global Attribut aus. Mit den Events muss ich erst noch schauen.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 17 September 2018, 17:53:10
Nur das globale Attribut auszulesen, dürfte nicht ganz genügen, aber ein Stück code sagt mehr als 1000 Worte, oder?

Aus fhem.pl:1091      my $we = (($wday==0 || $wday==6) ? 1 : 0);
1092      if(!$we) {
1093        foreach my $h2we (split(",", AttrVal("global", "holiday2we", ""))) {
1094          my ($a, $b) = ReplaceEventMap($h2we, [$h2we, Value($h2we)], 0);
1095          $we = 1 if($b && $b ne "none");
1096        }
1097      }

Ansonsten steht eigentlich das meiste zu holidy und holiday2we in der CR:
https://fhem.de/commandref.html#holiday2we
https://fhem.de/commandref.html#holiday

Zusammenfassung: Man kann als globales Attribut ein oder mehrere holiday-Devices angeben (Komma-getrennt); jedes der Devices hat einige Readings mit Namen state, tomorrow und yesterday. Wenn nix ist, ist der Wert "none", also sollte sich das auf Nicht-"None" abfragen lassen, wobei man eben eine loop braucht, die über alle holiday-Devices geht (bis eines einen Treffer bringt, ähnlich dem oben, nur deutlich kürzer).

Ansonsten habe ich am WE etwas gebastelt, um den ical in holiday umzuwandeln ;) : https://forum.fhem.de/index.php/topic,85759.msg836582.html#msg836582.
Dann gab es am WE auch einen Thread, in dem es um eine Nachtschicht ging, bei der auch "auf die Zukunft" abgefragt wurde. Sowas könntest du auch in ein at packen, um dann den "tomorrow"-Stand des Dummy gleich richtig zu setzen (würde die setList und readingList dann für den (zusätzlichen) Dummy so gestalten wie das bei den holidays auch der Fall ist). Code war hier (https://forum.fhem.de/index.php/topic,91060.0/topicseen.html). Sowas fände ich als generelle Funktionalität (optional) nicht schlecht, könnte man in die Begleit-Doku packen.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 17 September 2018, 20:20:06
Nur ganz kurz. Den Code hatte ich mir schon heute Nachmittag geborgt, bin nur nicht zum weiter auswerten gekommen  ;D
Ich schaue es mir morgen in Ruhe an.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 17 September 2018, 21:16:03
my $wetomorrow = (($wday==5 || $wday==6) ? 1 : 0);
if(!$wetomorrow) {
   foreach my $h2we (split(",", AttrVal("global", "holiday2we", ""))) {
     my ($a, $b) = ReplaceEventMap($h2we, [$h2we, ReadingsVal($h2we,"tomorrow","none")], 0);
     $wetomorrow = 1 if($b && $b ne "none");
   }
}

Auf die Schnelle so?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 18 September 2018, 09:40:31
Version 0.1.48 habe ich soeben ins Git geladen.
Unterstützt wird nun Wochenendsteuerung über das Rolladen Attribut AutoShuttersControl_Time_Up_WE_Holiday und im Moduldevice der set Befehl sunriseTimeWeHoliday.
Wenn sunriseTimeWeHoliday auf on steht und man das Attribut AutoShuttersControl_Time_Up_WE_Holiday am Rolladen ändert, wird automatisch der neue Timer gesetzt.
In der Wochenendsteuerung ist auch we2holiday mit enthalten. Extra Kalender folgen noch.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: MarkusHiba am 18 September 2018, 10:59:18
Hey,

Wiki aktualisiert.
Könnt ihr mir sagen was ich bei den Tabellen Datentyp/Wertebereich (z.B. HH:MM:SS) und Default-Wert (Werte die vom Modul vorgegeben sind) noch eintragen soll ?
Oder fehlt noch etwas.

Grüße

Markus
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 18 September 2018, 11:09:38
Ich habe da ein bisschen was zu geschrieben. Denke das passt soweit.
Danke für Deine Arbeit mit am Wikieintrag.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: FunkOdyssey am 18 September 2018, 11:22:16
Zitat von: CoolTux am 18 September 2018, 09:40:31
Version 0.1.48 habe ich soeben ins Git geladen.
Unterstützt wird nun Wochenendsteuerung über das Rolladen Attribut AutoShuttersControl_Time_Up_WE_Holiday und im Moduldevice der set Befehl sunriseTimeWeHoliday.
Wenn sunriseTimeWeHoliday auf on steht und man das Attribut AutoShuttersControl_Time_Up_WE_Holiday am Rolladen ändert, wird automatisch der neue Timer gesetzt.
In der Wochenendsteuerung ist auch we2holiday mit enthalten. Extra Kalender folgen noch.

Ehrlich gesagt verstehe ich das derzeit noch nicht.
Ich sehe im Code, dass du unter "Global" das holiday2we-Attribut prüfst. In meinem "holiday"-Device habe ich ja bereits stehen, dass morgen ein Wochenende sein könnte.
Ich brauche dann aber nicht noch zusätzlich unter ASC ein Device hinterlegen, oder?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 18 September 2018, 11:30:45
Zitat von: FunkOdyssey am 18 September 2018, 11:22:16
Ehrlich gesagt verstehe ich das derzeit noch nicht.
Ich sehe im Code, dass du unter "Global" das holiday2we-Attribut prüfst. In meinem "holiday"-Device habe ich ja bereits stehen, dass morgen ein Wochenende sein könnte.
Ich brauche dann aber nicht noch zusätzlich unter ASC ein Device hinterlegen, oder?

Nein. Das zusätzliche Device dient der Erkennung weiterer freier Tage. Ausserhalb von Holiday und WE. Ich habe zum Beispiel einen Urlaubskalender als ical. Sobald ein Eintrag im Calendarmodul auf taucht schreibt ein Notify mir in mein DummyKalenderDevice eine 1 rein. Um das aus zu werten, dafür ist das Attribut gedacht. Wird aber noch nicht beachtet.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 18 September 2018, 11:43:12
Zitat von: FunkOdyssey am 18 September 2018, 11:22:16
Ich sehe im Code, dass du unter "Global" das holiday2we-Attribut prüfst. In meinem "holiday"-Device habe ich ja bereits stehen, dass morgen ein Wochenende sein könnte.
Habe eben den Code mal kurz angesehen, weil ich heftig darauf hinweisen wollte, dass das holiday-Device _keine_ Info über Wochenende enthält, sondern nur die dort genannten Termine berücksichtigt.

Da sind mir aber zwei Dinge aufgefallen:
- Die neue Funktion IsWe() macht genau dasselbe wie $we, die als globale Variable systemweit verfügbar ist. Der Mehrwert ist mir nicht klar oder habe ich was nicht richtig verstanden?
- In der IsWeTomorrow wird als Variablenname $we verwendet. Könnte zu Konflikten mit der genannten global verfügbaren Variable kommen (ich weiß nicht, ob Perl das ähnlich kapselt wie C); sollte man m.E. sicherheitshalber umbenennen. Und ob die Eingangsabfrage (Zeile 1059) mit "+1" funktioniert? Würde annehmen, dass 6+1 7 ergibt ;) .
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 18 September 2018, 11:48:12
Zitat von: Beta-User am 18 September 2018, 11:43:12
Habe eben den Code mal kurz angesehen, weil ich heftig darauf hinweisen wollte, dass das holiday-Device _keine_ Info über Wochenende enthält, sondern nur die dort genannten Termine berücksichtigt.

Da sind mir aber zwei Dinge aufgefallen:
- Die neue Funktion IsWe() macht genau dasselbe wie $we, die als globale Variable systemweit verfügbar ist. Der Mehrwert ist mir nicht klar oder habe ich was nicht richtig verstanden?
- In der IsWeTomorrow wird als Variablenname $we verwendet. Könnte zu Konflikten mit der genannten global verfügbaren Variable kommen (ich weiß nicht, ob Perl das ähnlich kapselt wie C); sollte man m.E. sicherheitshalber umbenennen. Und ob die Eingangsabfrage (Zeile 1059) mit "+1" funktioniert? Würde annehmen, dass 6+1 7 ergibt ;) .

$we ist in Modulen und in 99_myUtils Funktionen als Variable nicht verfügbar.
Da ich mit packages arbeite kann ich auch Funktionen benennen die gleich lauten wie in anderen Modulen oder gar in FHEM solange ich die Funktion nicht importiere.
Bleibt am Ende 6+1 = 7 und das lasse ich gelten  ;D
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 18 September 2018, 12:14:46
...man lernt nie aus, da war ja was... :) ::) ;D

Danke für die Rückmeldung.

(Irgendwie irritierend, dass $wday geht, aber das in der commandref bei den Perl Specials in einem Atemzug mit $we auftaucht)
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 18 September 2018, 12:40:16
Zitat von: Beta-User am 18 September 2018, 12:14:46
...man lernt nie aus, da war ja was... :) ::) ;D

Danke für die Rückmeldung.

(Irgendwie irritierend, dass $wday geht, aber das in der commandref bei den Perl Specials in einem Atemzug mit $we auftaucht)

$wday wird ja auch als Variable im Modul deklariert und über die Funktion localtime(gettimeofday()); befüllt.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 18 September 2018, 12:45:48
gefixte Version 0.1.49 ist nun Online. Vielen vielen Dank für die gute Aufmerksamkeit.



Grüße
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 18 September 2018, 12:47:13
Thx für die Info.

Insgesamt auch irgendwie unbefriedigend, dass da jeder Modulautor doch wieder die Funktion selber einbauen muß; aber eine einfachere Lösung scheint es ja nicht zu geben... Lassen wir das auf sich beruhen, oder?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 18 September 2018, 12:52:03
Jepp.

Es gibt ja auch keine wirkliche Funktion für $we, das $we wurde lediglich bei AnalyzePerlCommand() abgearbeitet. Also sehr sehr FHEM intern.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: kjmEjfu am 18 September 2018, 15:01:25
Bin gerade im Wiki über

ZitatAutoShuttersControl_Time_Up_WE_Holiday         Sunrise frühste Zeit zum hochfahren am Wochenende und/oder Urlaub (we2holiday wird beachtet), Achtung sollte nicht größer sein wie AutoShuttersControl_Time_Up_Late sonst wird AutoShuttersControl_Time_Up_Late verwendet

gestolpert.

Finde ich nicht ganz so ideal.

Das Attribut AutoShuttersControl_Time_Up_Late benutze ich doch, um z.B. bei Nutzung von CIVIL zu erzwingen, dass das Rollo nicht erst um ~10 Uhr hochfährt, sondern spätestens zum festgelegten Zeitpunkt.

Bei AutoShuttersControl_Time_Up_WE_Holiday will ich doch aber vielleicht das Rollo erst um 11 Uhr hochfahren lassen, weil ich am Wochenende richtig lange schlafe.

Wenn ich dafür nun aber AutoShuttersControl_Time_Up_Late verlängern muss, dann fahren die Rollos im tiefsten Winter auch an normalen Tagen erst sehr spät hoch. Frauen haben dann schnell so einen "ich fühle mich eingesperrt"-Moment  ;)
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 18 September 2018, 15:08:00
Also ich kann es entweder so machen wie bis jetzt, oder ich nehme AutoShuttersControl_Time_Up_Late komplett aus der Berechnung am Wochenende und Feiertagen raus. Dann fährt er definitiv um AutoShuttersControl_Time_Up_WE_Holiday hoch.
Was wäre den Usern lieber?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 18 September 2018, 15:17:13
Zur Anmerkung von kjmEjufu: Ging mir im ersten Moment auch so, dann habe ich das vorläufig auf die Seite gestellt.

(Vermeiden kann man das, indem man den Resident asleep legt, oder?)
(In meiner eigenen Gedankenwelt gab es am WE auch mal 2 Werte = hier zwei Attribute; braucht es m.E. nicht)

Spricht was dagegen, den Up_Late-Timer $we abfragen zu lassen und dann erforderlichenfalls zu prüfen, ob Up_WE_Holiday bereits um ist? (Wenn nein: neuer Timer auf diese Zeit).
Oder noch besser: gleich bei der Erstellung des Timers zu prüfen, ob "tomorrow" nicht "none" ist und dann _zu prüfen, ob die WE-Time später ist als die "Late". Wenn ja: fixer Timer, ansonsten eben "normal" (ggf. mit Astro-Berechnung)? (Der Vergleich sollte sich hier ja zur Abwechslung mit einem "gt" machen lassen, oder?)
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 18 September 2018, 17:38:03
Das prüfen ob late kleiner ist wie we passiert automatisch.
Ich werde late rausnehmen für das WE und somit fährt er auf jeden Fall zum WE Zeitpunkt wenn die Bewohner auf sind, wenn nicht dann eh nicht.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: C0mmanda am 18 September 2018, 19:57:48
Auch wenn es schon hinreichend diskutiert wurde:

Ich finde es sehr unschön extra ein dummy-Device + notify anlegen zu müssen um die holiday-Funktion nutzen zu können.
(1|0 muss beim Device im state stehen).
Ich habe ja schließlich schon ein holiday-Device.

Gruß
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 18 September 2018, 20:03:24
Zitat von: C0mmanda am 18 September 2018, 19:57:48
Auch wenn es schon hinreichend diskutiert wurde:

Ich finde es sehr unschön extra ein dummy-Device + notify anlegen zu müssen um die holiday-Funktion nutzen zu können.
(1|0 muss beim Device im state stehen).
Ich habe ja schließlich schon ein holiday-Device.

Gruß

Wenn Du ein richtiges Holiday Device hast dann trage es doch in global mit Attribut we2holiday ein und gut ist. Dann brauchst du das zusätzliche Device nicht.

Noch mal zur Klärung. Dieses zusätzlich Device ist für ical Kalender gedacht.
Siehe
https://wiki.fhem.de/wiki/Wochenende,_Feiertage_und_Schulferien#Feiertage_mittels_Internet-Kalender
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: C0mmanda am 18 September 2018, 20:18:47
Zitat von: CoolTux am 18 September 2018, 20:03:24
Wenn Du ein richtiges Holiday Device hast dann trage es doch in global mit Attribut we2holiday ein und gut ist. Dann brauchst du das zusätzliche Device nicht.

Noch mal zur Klärung. Dieses zusätzlich Device ist für ical Kalender gedacht.
Siehe
https://wiki.fhem.de/wiki/Wochenende,_Feiertage_und_Schulferien#Feiertage_mittels_Internet-Kalender

Aha.
Sorry, das war mir nicht klar. Danke für die Aufklärung.
holiday2we habe ich natürlich in global hinterlegt.
Das heißt ich kann das Attribut "AutoShuttersControl_timeUpHolidayDevice" in der Rolladensteuerung komplett löschen?

gruß
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 18 September 2018, 20:19:06
Bitte trage dein Holiday Device einfach als Attribut holiday2we ins Device global ein und damit wäre es dann dem Modul bekannt.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 18 September 2018, 20:19:52
Zitat von: C0mmanda am 18 September 2018, 20:18:47
Aha.
Sorry, das war mir nicht klar. Danke für die Aufklärung.
holiday2we habe ich natürlich in global hinterlegt.
Das heißt ich kann das Attribut "AutoShuttersControl_timeUpHolidayDevice" in der Rolladensteuerung komplett löschen?

gruß

Ja das kannst Du.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: kjmEjfu am 19 September 2018, 10:41:30
Zitat von: Beta-User am 18 September 2018, 15:17:13
Zur Anmerkung von kjmEjufu: Ging mir im ersten Moment auch so, dann habe ich das vorläufig auf die Seite gestellt.

(Vermeiden kann man das, indem man den Resident asleep legt, oder?)

Naja, da stellt sich die Frage, ob man das mit einem Resident abfangen kann.
Denn Resident verlässt den Status "asleep" sobald einer der darin gruppierten Roommates aufsteht.
Hast du nun also das Rollo im Schlafzimmer mit dem gemeinsamen Resident verknüpft, könnte der spät aufstehende das eher uncool finden. Als Workaround könnte man das Rollo u.U. mit dem Roommate verknüpfen, aber dann müsste man genau einen auswählen und das ist im Zweifel der falsche ;-)
Also ganz so trivial ist es an der Stelle auch nicht mit dem asleep.

Für die ganzen Wohnräume könnte es natürlich Sinn machen, für gemeinsame Schlafräume vermutlich eher nicht.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 19 September 2018, 12:00:50
Für gemeinsame Schlafräume habe ich die entsprechenden Roommates in eine Struktur gepackt und diese im Rollo als Roommates interlegt. Klappt super.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 19 September 2018, 12:55:53
Zitat von: CoolTux am 19 September 2018, 12:00:50
Für gemeinsame Schlafräume habe ich die entsprechenden Roommates in eine Struktur gepackt und diese im Rollo als Roommates interlegt. Klappt super.
Hmmm, irgendwie wieder ziemlich unbefriedigend!

Ich war davon ausgegangen, dass die "structure-Lösung" nur eine Übergangslösung bis zur Nutzung der RESIDENTS-Funktionalität sein würde. Wenn das so nicht geht, benötigt man doppelte Strukturen, das ist unschön... Auswege? Man könnte entweder die Funktionalität innerhalb ASC nachbilden und mehrere Residents zulassen (was geplant ist, oder?), oder den Residents einen neuen Unterstatus verpassen ("Einer schläft noch"), der dann für ASC herangezogen würde. Fände ich eigentlich auch ganz chick.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: kjmEjfu am 19 September 2018, 13:24:24
Zitat von: Beta-User am 19 September 2018, 12:55:53
Man könnte entweder die Funktionalität innerhalb ASC nachbilden und mehrere Residents zulassen (was geplant ist, oder?), oder den Residents einen neuen Unterstatus verpassen ("Einer schläft noch"), der dann für ASC herangezogen würde. Fände ich eigentlich auch ganz chick.

wobei man da genau genommen keinen neuen Unterstatus für braucht.
Residents kennt ja schon die Readings residentsAsleep und residentsGotosleep  (s. https://fhem.de/commandref_DE.html#RESIDENTS)

@CoolTux: wenn ich lieber meine Klappe halten soll, dann musst du es sagen :-)
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 19 September 2018, 13:45:40
Zitat von: kjmEjfu am 19 September 2018, 13:24:24
wobei man da genau genommen keinen neuen Unterstatus für braucht.
Residents kennt ja schon die Readings residentsAsleep und residentsGotosleep  (s. https://fhem.de/commandref_DE.html#RESIDENTS)

@CoolTux: wenn ich lieber meine Klappe halten soll, dann musst du es sagen :-)

Also hier soll keiner Irgendwas halten. Es ist und bleibt mir wichtig über sowas zu Diskutieren.

Bitte verwechselt mir dabei aber nicht Residents mit Roommate. Für einzelne Schlafräume würde ich mich eher an Roommate wenden. Man kann zwar ein Residentsdevice zusätzlich anlegen für einen Raum, aber das wäre dann wie als wenn ich eine Struktur machen würde.

Mein Vorschlag wäre die Logik für Roommate ins ASC Modul zu bringen. Es können also mehrere Roommates angelegt werden und wenn beide home oder awoken sind fahren die Rollos hoch und wenn einer asleep oder gotosleep geht fahren sie runter.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 19 September 2018, 13:51:11
Zitat von: CoolTux am 19 September 2018, 13:45:40
Also hier soll keiner Irgendwas halten. Es ist und bleibt mir wichtig über sowas zu Diskutieren.
Danke für das klare statement ;) .

ZitatBitte verwechselt mir dabei aber nicht Residents mit Roommate. Für einzelne Schlafräume würde ich mich eher an Roommate wenden. Man kann zwar ein Residentsdevice zusätzlich anlegen für einen Raum, aber das wäre dann wie als wenn ich eine Struktur machen würde.

Mein Vorschlag wäre die Logik für Roommate ins ASC Modul zu bringen. Es können also mehrere Roommates angelegt werden und wenn beide home oder awoken sind fahren die Rollos hoch und wenn einer asleep oder gotosleep geht fahren sie runter.
Finde den Vorschlag einleuchtend (sorry, wenn ich die Begrifflichkeiten da irgendwie immer durcheinanderbringe; vielleicht lerne ich das noch, wenn ich das selbst irgendwann mal einsetze...)
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: kjmEjfu am 19 September 2018, 15:13:48
Sorry, ich war tatsächlich aus irgendeinem Grunde bei nem Resident-Device statt beim Roommate.
Aber wenn eh schon Roommate ausgewertet wird, dann wäre es natürlich praktisch, wenn man mehrere reinpacken kann.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 19 September 2018, 15:21:58
Zitat von: kjmEjfu am 19 September 2018, 15:13:48
Sorry, ich war tatsächlich aus irgendeinem Grunde bei nem Resident-Device statt beim Roommate.
Aber wenn eh schon Roommate ausgewertet wird, dann wäre es natürlich praktisch, wenn man mehrere reinpacken kann.

Ich baue das ein, wird aber etwas dauern. Ist genau so tricky wie die Sache mit den korrekten Zeiten für Astro  ;D
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: FunkOdyssey am 19 September 2018, 18:04:38
Zitat von: CoolTux am 18 September 2018, 15:08:00
Also ich kann es entweder so machen wie bis jetzt, oder ich nehme AutoShuttersControl_Time_Up_Late komplett aus der Berechnung am Wochenende und Feiertagen raus. Dann fährt er definitiv um AutoShuttersControl_Time_Up_WE_Holiday hoch.
Was wäre den Usern lieber?

Ich nutze zwar das Residents-Modul und habe eigentlich auch eine recht sichere Erkennung. Aber dennoch finde ich, wir hier gerade uns zu stark auf Residents und Roommates konzentrieren.

Wieso können wir nicht einfach Attribute (Mindestens, Astro, Spätestens) mit Zeiten getrennt für Werktage und Wochenenden/Feiertage/Urlaub anlegen?

Die Komplexität und die Fehlerquellen erhöhen sich doch enorm, wenn jeder Nutzer plötzlich mit CIVIL und Roommates rumspielen muss.

Oder habe ich gerade ein Brett vor dem Kopf?  :D
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 19 September 2018, 18:19:24
Astro ist das eine. Also das fahren der Rolladen auf Basis von Zeiten. In dem Fall Astrozeiten oder besser gesagt Dämmerungszeiten (Sonnenaufgang, Sonnenuntergang). Das andere ist der Status der Bewohner für die Schlafräume. Ich möchte nicht das mein Rolladen Fahrt wenn die Sonne auf geht ich aber noch schlafe. Dann fährt der Rolladen Abend nicht sondern eben von der Status des Bewohners auf home nach asleep steht. Das ist im übrigen nicht auf Roommate oder Residents begrenzt sondern solange das Reading state ein asleep awoken gotosleep und home wieder gibt gehen da auch andere.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 20 September 2018, 19:42:52
Hallo zusammen,
ich komme nochmal auf die nichtfahrenden Rollläden in den zwei Kinderzimmern zurück, da die heute nicht offen waren, als ich (vor sunset) nach Hause gekommen bin.
Habe mir mal die Werte da (Am Rolladendevice) angesehen, und siehe da, die Zeit für's Öffnen stand auf Samstag, also übermorgen...

list dazu:
Internals:
   CFGFN     
   CUL_0_MSGCNT 1
   CUL_0_RAWMSG A0EDEA41052A2E9425EE20601000037::-60.5:CUL_0
   CUL_0_RSSI -60.5
   CUL_0_TIME 2018-09-19 05:45:59
   DEF        52A2E9
   IODev      myHmUART
   LASTInputDev myHmUART
   MSGCNT     3
   NAME       Rolladen_Kind1_Sued
   NOTIFYDEV  global
   NR         204
   NTFY_ORDER 50-Rolladen_Kind1_Sued
   STATE      off
   TYPE       CUL_HM
   lastMsg    No:DE - t:10 s:52A2E9 d:425EE2 0601000037
   mapleCUN1_MSGCNT 1
   mapleCUN1_RAWMSG A0EDEA41052A2E9425EE20601000037::-91:mapleCUN1
   mapleCUN1_RSSI -91
   mapleCUN1_TIME 2018-09-19 05:45:59
   myHmUART_MSGCNT 1
   myHmUART_RAWMSG 05010034DEA41052A2E9425EE20601000037
   myHmUART_RSSI -52
   myHmUART_TIME 2018-09-19 05:45:59
   protLastRcv 2018-09-19 05:45:59
   protRcv    1 last_at:2018-09-19 05:45:59
   protSnd    2 last_at:2018-09-19 05:45:59
   protState  CMDs_done
   rssi_at_CUL_0 cnt:1 min:-60.5 max:-60.5 avg:-60.5 lst:-60.5
   rssi_at_mapleCUN1 cnt:1 min:-91 max:-91 avg:-91 lst:-91
   rssi_at_myHmUART cnt:1 min:-52 max:-52 avg:-52 lst:-52
   rssi_myHmUART cnt:1 min:-55 max:-55 avg:-55 lst:-55
   OLDREADINGS:
   READINGS:
     2018-09-20 06:45:32   AutoShuttersControl_Time_Sunrise Sat Sep 22 06:45:54 2018
     2018-09-20 06:45:32   AutoShuttersControl_Time_Sunset Thu Sep 20 20:15:20 2018
     2018-09-18 20:15:30   CommandAccepted yes
     2017-12-09 00:30:54   D-firmware      2.3
     2017-12-09 00:30:54   D-serialNr      LEQ0069948
     2017-12-21 07:35:33   PairedTo        0x425EE2
     2017-12-21 07:35:34   R-driveDown     15 s
     2017-12-21 07:35:34   R-driveTurn     0.5 s
     2017-12-21 07:35:34   R-driveUp       16 s
     2017-12-21 07:35:33   R-pairCentral   0x425EE2
     2017-12-21 07:35:34   R-powerUpAction off
     2017-12-21 07:35:34   R-sign          off
     2017-12-21 07:35:33   RegL_00.        02:01 0A:42 0B:5E 0C:E2 15:FF 18:00 00:00
     2017-12-21 07:35:34   RegL_01.        08:00 09:00 0A:00 0B:00 0C:96 0D:00 0E:A0 0F:05 10:00  30:06 57:06 56:00 00:00
     2018-05-19 19:12:30   automode        0
     2018-09-19 05:45:59   deviceMsg       off (to VCCU)
     2018-09-19 05:45:59   level           0
     2018-09-19 05:45:59   motor           stop:off
     2018-09-19 05:45:59   pct             0
     2018-07-20 22:02:29   powerOn         2018-07-20 22:02:29
     2018-09-19 05:45:59   recentStateType info
     2018-09-19 05:45:59   state           off
     2018-09-19 05:45:59   timedOn         off
   helper:
     HM_CMDNR   222
     cSnd       ,01425EE252A2E9010E
     mId        006A
     regLst     ,0,1,3p
     rxType     1
     supp_Pair_Rep 0
     ack:
     dir:
       cur        stop
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +52A2E9,00,00,00
       nextSend   1537328759.65459
       prefIO     
       rxt        0
       vccu       VCCU
       p:
         52A2E9
         00
         00
         00
     mRssi:
       mNo        DE
       io:
         CUL_0:
           -60.5
           -60.5
         mapleCUN1:
           -91
           -91
         myHmUART:
           -46
           -46
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       prs        1
     rpt:
       IO         CUL_0
       flg        A
       ts         1537328759.33617
       ack:
         HASH(0x26088b0)
         DE8002425EE252A2E900
     rssi:
       at_CUL_0:
         avg        -60.5
         cnt        1
         lst        -60.5
         max        -60.5
         min        -60.5
       at_mapleCUN1:
         avg        -91
         cnt        1
         lst        -91
         max        -91
         min        -91
       at_myHmUART:
         avg        -52
         cnt        1
         lst        -52
         max        -52
         min        -52
       myHmUART:
         avg        -55
         cnt        1
         lst        -55
         max        -55
         min        -55
     tmpl:
Attributes:
   AutoShuttersControl 2
   AutoShuttersControl_Antifreeze off
   AutoShuttersControl_AutoAstroModeEvening none
   AutoShuttersControl_AutoAstroModeEveningHorizon none
   AutoShuttersControl_AutoAstroModeMorning none
   AutoShuttersControl_AutoAstroModeMorningHorizon none
   AutoShuttersControl_Closed_Pos 0
   AutoShuttersControl_Direction 178
   AutoShuttersControl_Down astro
   AutoShuttersControl_GuestRoom 1
   AutoShuttersControl_Mode_Down always
   AutoShuttersControl_Mode_Up always
   AutoShuttersControl_Offset_Minutes_Evening 1
   AutoShuttersControl_Offset_Minutes_Morning 1
   AutoShuttersControl_Open_Pos 100
   AutoShuttersControl_Partymode off
   AutoShuttersControl_Pos_Cmd pct
   AutoShuttersControl_Pos_after_ComfortOpen 80
   AutoShuttersControl_Rand_Minutes 20
   AutoShuttersControl_Roommate_Device rr_Kind1
   AutoShuttersControl_Roommate_Reading state
   AutoShuttersControl_Shading off
   AutoShuttersControl_Shading_Angle_Left 85
   AutoShuttersControl_Shading_Angle_Right 85
   AutoShuttersControl_Shading_BlockingTime_After_Manual 20
   AutoShuttersControl_Shading_BlockingTime_Twilight 45
   AutoShuttersControl_Shading_Brightness_Reading brightness
   AutoShuttersControl_Shading_Brightness_Sensor 1
   AutoShuttersControl_Shading_Fast_Close 1
   AutoShuttersControl_Shading_Fast_Open 1
   AutoShuttersControl_Shading_Min_Elevation 1
   AutoShuttersControl_Shading_Min_OutsideTemperature 18
   AutoShuttersControl_Shading_Pos 55
   AutoShuttersControl_Shading_Pos_after_Shading -1
   AutoShuttersControl_Shading_StateChange_Cloudy 4000
   AutoShuttersControl_Shading_StateChange_Sunny 6000
   AutoShuttersControl_Shading_WaitingPeriod 20
   AutoShuttersControl_Time_Down_Early 20:15:00
   AutoShuttersControl_Time_Down_Late 22:30:00
   AutoShuttersControl_Time_Up_Early 06:45:00
   AutoShuttersControl_Time_Up_Late 09:00:00
   AutoShuttersControl_Time_Up_WE_Holiday 09:30:00
   AutoShuttersControl_Up astro
   AutoShuttersControl_Ventilate_Pos 30
   AutoShuttersControl_Ventilate_Window_Open on
   AutoShuttersControl_WindowRec Fenster_Kind1_Sued
   AutoShuttersControl_WindowRec_subType threestate
   AutoShuttersControl_lock-out soft
   AutoShuttersControl_lock-outCmd none
   IODev      CUL_0
   IOgrp      VCCU
   autoReadReg 4_reqStatus
   devStateIcon on:fts_shutter_10 off:fts_schutter_100
   expert     2_full
   firmware   2.3
   fp_Obergeschoss 655,340,0,
   group      Türen und Fenster
   icon       fts_shutter
   model      HM-LC-Bl1PBU-FM
   peerIDs    00000000,
   room       Kind1
   serialNr   LEQ0069948
   subType    blindActuator
   userattr   AutoShuttersControl_Antifreeze:off,morning AutoShuttersControl_Antifreeze:off,on AutoShuttersControl_AutoAstroModeEvening:REAL,CIVIL,NAUTIC,ASTRONOMIC,HORIZON AutoShuttersControl_AutoAstroModeEveningHorizon:-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9 AutoShuttersControl_AutoAstroModeMorning:REAL,CIVIL,NAUTIC,ASTRONOMIC,HORIZON AutoShuttersControl_AutoAstroModeMorningHorizon:-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9 AutoShuttersControl_Closed_Pos:0,10,20,30,40,50,60,70,80,90,100 AutoShuttersControl_Direction AutoShuttersControl_Down:time,astro AutoShuttersControl_GuestRoom:on,off AutoShuttersControl_Mode_Down:absent,always,off AutoShuttersControl_Mode_Down:present,absent,always,off AutoShuttersControl_Mode_Up:absent,always,off AutoShuttersControl_Mode_Up:present,absent,always,off AutoShuttersControl_Offset_Minutes_Evening AutoShuttersControl_Offset_Minutes_Morning AutoShuttersControl_Open_Pos:0,10,20,30,40,50,60,70,80,90,100 AutoShuttersControl_Partymode:on,off AutoShuttersControl_Pos_Cmd AutoShuttersControl_Pos_after_ComfortOpen:-2,-1,0,10,20,30,40,50,60,70,80,90,100 AutoShuttersControl_Pos_after_ComfortOpen:0,10,20,30,40,50,60,70,80,90,100 AutoShuttersControl_Rand_Minutes AutoShuttersControl_Roommate_Device AutoShuttersControl_Roommate_Reading AutoShuttersControl_Shading:on,off,delayed,present,absent AutoShuttersControl_Shading_Angle_Left:0,5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90 AutoShuttersControl_Shading_Angle_Right:0,5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90 AutoShuttersControl_Shading_BlockingTime_After_Manual AutoShuttersControl_Shading_BlockingTime_Twilight AutoShuttersControl_Shading_Brightness_Reading AutoShuttersControl_Shading_Brightness_Sensor AutoShuttersControl_Shading_Fast_Close:on,off AutoShuttersControl_Shading_Fast_Open:on,off AutoShuttersControl_Shading_Min_Elevation AutoShuttersControl_Shading_Min_OutsideTemperature AutoShuttersControl_Shading_Pos:10,20,30,40,50,60,70,80,90,100 AutoShuttersControl_Shading_Pos_after_Shading:-1,0,10,20,30,40,50,60,70,80,90,100 AutoShuttersControl_Shading_StateChange_Cloudy AutoShuttersControl_Shading_StateChange_Sunny AutoShuttersControl_Shading_WaitingPeriod AutoShuttersControl_Time_Down_Early AutoShuttersControl_Time_Down_Late AutoShuttersControl_Time_Up_Early AutoShuttersControl_Time_Up_Late AutoShuttersControl_Time_Up_WE_Holiday AutoShuttersControl_Up:time,astro AutoShuttersControl_Ventilate_Pos:10,20,30,40,50,60,70,80,90,100 AutoShuttersControl_Ventilate_Window_Open:on,off AutoShuttersControl_WindowRec AutoShuttersControl_WindowRec_subType:twostate,threestate AutoShuttersControl_lock-out:on,off AutoShuttersControl_lock-out:soft,hard AutoShuttersControl_lock-outCmd:inhibit,blocked
   webCmd     toggle:on:off:up:down:stop:statusRequest

Version ist 0.1.49, beide Roommates sind absent, habe das mind. bei einem der beiden heute morgen auch manuell aktualisiert.

Idee dazu?

Gruß, Beta-User
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 20 September 2018, 19:56:20
Zitat von: Beta-User am 20 September 2018, 19:42:52
Hallo zusammen,
ich komme nochmal auf die nichtfahrenden Rollläden in den zwei Kinderzimmern zurück, da die heute nicht offen waren, als ich (vor sunset) nach Hause gekommen bin.
Habe mir mal die Werte da (Am Rolladendevice) angesehen, und siehe da, die Zeit für's Öffnen stand auf Samstag, also übermorgen...

list dazu:
Internals:
   CFGFN     
   CUL_0_MSGCNT 1
   CUL_0_RAWMSG A0EDEA41052A2E9425EE20601000037::-60.5:CUL_0
   CUL_0_RSSI -60.5
   CUL_0_TIME 2018-09-19 05:45:59
   DEF        52A2E9
   IODev      myHmUART
   LASTInputDev myHmUART
   MSGCNT     3
   NAME       Rolladen_Kind1_Sued
   NOTIFYDEV  global
   NR         204
   NTFY_ORDER 50-Rolladen_Kind1_Sued
   STATE      off
   TYPE       CUL_HM
   lastMsg    No:DE - t:10 s:52A2E9 d:425EE2 0601000037
   mapleCUN1_MSGCNT 1
   mapleCUN1_RAWMSG A0EDEA41052A2E9425EE20601000037::-91:mapleCUN1
   mapleCUN1_RSSI -91
   mapleCUN1_TIME 2018-09-19 05:45:59
   myHmUART_MSGCNT 1
   myHmUART_RAWMSG 05010034DEA41052A2E9425EE20601000037
   myHmUART_RSSI -52
   myHmUART_TIME 2018-09-19 05:45:59
   protLastRcv 2018-09-19 05:45:59
   protRcv    1 last_at:2018-09-19 05:45:59
   protSnd    2 last_at:2018-09-19 05:45:59
   protState  CMDs_done
   rssi_at_CUL_0 cnt:1 min:-60.5 max:-60.5 avg:-60.5 lst:-60.5
   rssi_at_mapleCUN1 cnt:1 min:-91 max:-91 avg:-91 lst:-91
   rssi_at_myHmUART cnt:1 min:-52 max:-52 avg:-52 lst:-52
   rssi_myHmUART cnt:1 min:-55 max:-55 avg:-55 lst:-55
   OLDREADINGS:
   READINGS:
     2018-09-20 06:45:32   AutoShuttersControl_Time_Sunrise Sat Sep 22 06:45:54 2018
     2018-09-20 06:45:32   AutoShuttersControl_Time_Sunset Thu Sep 20 20:15:20 2018
     2018-09-18 20:15:30   CommandAccepted yes
     2017-12-09 00:30:54   D-firmware      2.3
     2017-12-09 00:30:54   D-serialNr      LEQ0069948
     2017-12-21 07:35:33   PairedTo        0x425EE2
     2017-12-21 07:35:34   R-driveDown     15 s
     2017-12-21 07:35:34   R-driveTurn     0.5 s
     2017-12-21 07:35:34   R-driveUp       16 s
     2017-12-21 07:35:33   R-pairCentral   0x425EE2
     2017-12-21 07:35:34   R-powerUpAction off
     2017-12-21 07:35:34   R-sign          off
     2017-12-21 07:35:33   RegL_00.        02:01 0A:42 0B:5E 0C:E2 15:FF 18:00 00:00
     2017-12-21 07:35:34   RegL_01.        08:00 09:00 0A:00 0B:00 0C:96 0D:00 0E:A0 0F:05 10:00  30:06 57:06 56:00 00:00
     2018-05-19 19:12:30   automode        0
     2018-09-19 05:45:59   deviceMsg       off (to VCCU)
     2018-09-19 05:45:59   level           0
     2018-09-19 05:45:59   motor           stop:off
     2018-09-19 05:45:59   pct             0
     2018-07-20 22:02:29   powerOn         2018-07-20 22:02:29
     2018-09-19 05:45:59   recentStateType info
     2018-09-19 05:45:59   state           off
     2018-09-19 05:45:59   timedOn         off
   helper:
     HM_CMDNR   222
     cSnd       ,01425EE252A2E9010E
     mId        006A
     regLst     ,0,1,3p
     rxType     1
     supp_Pair_Rep 0
     ack:
     dir:
       cur        stop
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +52A2E9,00,00,00
       nextSend   1537328759.65459
       prefIO     
       rxt        0
       vccu       VCCU
       p:
         52A2E9
         00
         00
         00
     mRssi:
       mNo        DE
       io:
         CUL_0:
           -60.5
           -60.5
         mapleCUN1:
           -91
           -91
         myHmUART:
           -46
           -46
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       prs        1
     rpt:
       IO         CUL_0
       flg        A
       ts         1537328759.33617
       ack:
         HASH(0x26088b0)
         DE8002425EE252A2E900
     rssi:
       at_CUL_0:
         avg        -60.5
         cnt        1
         lst        -60.5
         max        -60.5
         min        -60.5
       at_mapleCUN1:
         avg        -91
         cnt        1
         lst        -91
         max        -91
         min        -91
       at_myHmUART:
         avg        -52
         cnt        1
         lst        -52
         max        -52
         min        -52
       myHmUART:
         avg        -55
         cnt        1
         lst        -55
         max        -55
         min        -55
     tmpl:
Attributes:
   AutoShuttersControl 2
   AutoShuttersControl_Antifreeze off
   AutoShuttersControl_AutoAstroModeEvening none
   AutoShuttersControl_AutoAstroModeEveningHorizon none
   AutoShuttersControl_AutoAstroModeMorning none
   AutoShuttersControl_AutoAstroModeMorningHorizon none
   AutoShuttersControl_Closed_Pos 0
   AutoShuttersControl_Direction 178
   AutoShuttersControl_Down astro
   AutoShuttersControl_GuestRoom 1
   AutoShuttersControl_Mode_Down always
   AutoShuttersControl_Mode_Up always
   AutoShuttersControl_Offset_Minutes_Evening 1
   AutoShuttersControl_Offset_Minutes_Morning 1
   AutoShuttersControl_Open_Pos 100
   AutoShuttersControl_Partymode off
   AutoShuttersControl_Pos_Cmd pct
   AutoShuttersControl_Pos_after_ComfortOpen 80
   AutoShuttersControl_Rand_Minutes 20
   AutoShuttersControl_Roommate_Device rr_Kind1
   AutoShuttersControl_Roommate_Reading state
   AutoShuttersControl_Shading off
   AutoShuttersControl_Shading_Angle_Left 85
   AutoShuttersControl_Shading_Angle_Right 85
   AutoShuttersControl_Shading_BlockingTime_After_Manual 20
   AutoShuttersControl_Shading_BlockingTime_Twilight 45
   AutoShuttersControl_Shading_Brightness_Reading brightness
   AutoShuttersControl_Shading_Brightness_Sensor 1
   AutoShuttersControl_Shading_Fast_Close 1
   AutoShuttersControl_Shading_Fast_Open 1
   AutoShuttersControl_Shading_Min_Elevation 1
   AutoShuttersControl_Shading_Min_OutsideTemperature 18
   AutoShuttersControl_Shading_Pos 55
   AutoShuttersControl_Shading_Pos_after_Shading -1
   AutoShuttersControl_Shading_StateChange_Cloudy 4000
   AutoShuttersControl_Shading_StateChange_Sunny 6000
   AutoShuttersControl_Shading_WaitingPeriod 20
   AutoShuttersControl_Time_Down_Early 20:15:00
   AutoShuttersControl_Time_Down_Late 22:30:00
   AutoShuttersControl_Time_Up_Early 06:45:00
   AutoShuttersControl_Time_Up_Late 09:00:00
   AutoShuttersControl_Time_Up_WE_Holiday 09:30:00
   AutoShuttersControl_Up astro
   AutoShuttersControl_Ventilate_Pos 30
   AutoShuttersControl_Ventilate_Window_Open on
   AutoShuttersControl_WindowRec Fenster_Kind1_Sued
   AutoShuttersControl_WindowRec_subType threestate
   AutoShuttersControl_lock-out soft
   AutoShuttersControl_lock-outCmd none
   IODev      CUL_0
   IOgrp      VCCU
   autoReadReg 4_reqStatus
   devStateIcon on:fts_shutter_10 off:fts_schutter_100
   expert     2_full
   firmware   2.3
   fp_Obergeschoss 655,340,0,
   group      Türen und Fenster
   icon       fts_shutter
   model      HM-LC-Bl1PBU-FM
   peerIDs    00000000,
   room       Kind1
   serialNr   LEQ0069948
   subType    blindActuator
   userattr   AutoShuttersControl_Antifreeze:off,morning AutoShuttersControl_Antifreeze:off,on AutoShuttersControl_AutoAstroModeEvening:REAL,CIVIL,NAUTIC,ASTRONOMIC,HORIZON AutoShuttersControl_AutoAstroModeEveningHorizon:-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9 AutoShuttersControl_AutoAstroModeMorning:REAL,CIVIL,NAUTIC,ASTRONOMIC,HORIZON AutoShuttersControl_AutoAstroModeMorningHorizon:-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9 AutoShuttersControl_Closed_Pos:0,10,20,30,40,50,60,70,80,90,100 AutoShuttersControl_Direction AutoShuttersControl_Down:time,astro AutoShuttersControl_GuestRoom:on,off AutoShuttersControl_Mode_Down:absent,always,off AutoShuttersControl_Mode_Down:present,absent,always,off AutoShuttersControl_Mode_Up:absent,always,off AutoShuttersControl_Mode_Up:present,absent,always,off AutoShuttersControl_Offset_Minutes_Evening AutoShuttersControl_Offset_Minutes_Morning AutoShuttersControl_Open_Pos:0,10,20,30,40,50,60,70,80,90,100 AutoShuttersControl_Partymode:on,off AutoShuttersControl_Pos_Cmd AutoShuttersControl_Pos_after_ComfortOpen:-2,-1,0,10,20,30,40,50,60,70,80,90,100 AutoShuttersControl_Pos_after_ComfortOpen:0,10,20,30,40,50,60,70,80,90,100 AutoShuttersControl_Rand_Minutes AutoShuttersControl_Roommate_Device AutoShuttersControl_Roommate_Reading AutoShuttersControl_Shading:on,off,delayed,present,absent AutoShuttersControl_Shading_Angle_Left:0,5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90 AutoShuttersControl_Shading_Angle_Right:0,5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90 AutoShuttersControl_Shading_BlockingTime_After_Manual AutoShuttersControl_Shading_BlockingTime_Twilight AutoShuttersControl_Shading_Brightness_Reading AutoShuttersControl_Shading_Brightness_Sensor AutoShuttersControl_Shading_Fast_Close:on,off AutoShuttersControl_Shading_Fast_Open:on,off AutoShuttersControl_Shading_Min_Elevation AutoShuttersControl_Shading_Min_OutsideTemperature AutoShuttersControl_Shading_Pos:10,20,30,40,50,60,70,80,90,100 AutoShuttersControl_Shading_Pos_after_Shading:-1,0,10,20,30,40,50,60,70,80,90,100 AutoShuttersControl_Shading_StateChange_Cloudy AutoShuttersControl_Shading_StateChange_Sunny AutoShuttersControl_Shading_WaitingPeriod AutoShuttersControl_Time_Down_Early AutoShuttersControl_Time_Down_Late AutoShuttersControl_Time_Up_Early AutoShuttersControl_Time_Up_Late AutoShuttersControl_Time_Up_WE_Holiday AutoShuttersControl_Up:time,astro AutoShuttersControl_Ventilate_Pos:10,20,30,40,50,60,70,80,90,100 AutoShuttersControl_Ventilate_Window_Open:on,off AutoShuttersControl_WindowRec AutoShuttersControl_WindowRec_subType:twostate,threestate AutoShuttersControl_lock-out:on,off AutoShuttersControl_lock-out:soft,hard AutoShuttersControl_lock-outCmd:inhibit,blocked
   webCmd     toggle:on:off:up:down:stop:statusRequest

Version ist 0.1.49, beide Roommates sind absent, habe das mind. bei einem der beiden heute morgen auch manuell aktualisiert.

Idee dazu?

Gruß, Beta-User

Fällt mir aktuell nichts zu ein. Magst noch mal ein list vom ASC Device geben?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 20 September 2018, 23:28:17
Sorry, war weg, dafür jetzt der Stand, nachdem jetzt alle Timer für heute mal durch sind:

Für morgen früh sieht es ok aus, dafür ist der Wert für abends irritierend:
Internals:
     2018-09-20 20:15:20   AutoShuttersControl_Time_Sunrise Fri Sep 21 06:45:35 2018
     2018-09-20 20:15:20   AutoShuttersControl_Time_Sunset Sat Sep 22 20:15:07 2018
ASC-Device:
Internals:
   CFGFN     
   MID        da39a3ee5e6b4b0d3255bfef95601890afd80709
   NAME       Rolladenautomatik
   NOTIFYDEV  global,Rolladenautomatik,Terrassentuer_WZ,Fenster_Chillraum_West,Fenster_Wohnzimmer_SSO,Fenster_Bad_OG,Terrassentuer_EZ,Fenster_Wohnzimmer_SSW,AutoShuttersControl_WindowRec_subType,Fenster_Treppenhaus
   NR         380
   NTFY_ORDER 50-Rolladenautomatik
   NotifyOrderPrefix 51-
   STATE      active
   TYPE       AutoShuttersControl
   VERSION    0.1.49
   OLDREADINGS:
   READINGS:
     2018-09-20 20:15:38   Jalousie_Links_lastPosValue 0
     2018-09-20 20:15:38   Jalousie_Links_nextAstroTimeEvent Fri Sep 21 06:45:48 2018
     2018-09-20 20:15:33   Jalousie_Mitte_lastPosValue 0
     2018-09-20 20:15:33   Jalousie_Mitte_nextAstroTimeEvent Fri Sep 21 06:45:49 2018
     2018-09-20 20:15:14   Jalousie_Rechts_lastPosValue 0
     2018-09-20 20:15:14   Jalousie_Rechts_nextAstroTimeEvent Fri Sep 21 06:45:14 2018
     2018-09-20 20:15:17   Jalousie_WZ_lastPosValue 0
     2018-09-20 20:15:17   Jalousie_WZ_nextAstroTimeEvent Fri Sep 21 06:45:16 2018
     2018-09-20 20:15:27   Rolladen_Bad_OG_lastPosValue 0
     2018-09-20 20:15:27   Rolladen_Bad_OG_nextAstroTimeEvent Fri Sep 21 06:45:05 2018
     2018-09-20 20:15:33   Rolladen_Buero_Ost_lastPosValue 0
     2018-09-20 20:15:33   Rolladen_Buero_Ost_nextAstroTimeEvent Fri Sep 21 06:45:23 2018
     2018-09-20 20:15:19   Rolladen_Buero_Sued_lastPosValue 0
     2018-09-20 20:15:19   Rolladen_Buero_Sued_nextAstroTimeEvent Fri Sep 21 06:45:33 2018
     2018-09-20 20:15:39   Rolladen_Chillraum_lastPosValue 30
     2018-09-20 20:15:39   Rolladen_Chillraum_nextAstroTimeEvent Fri Sep 21 06:45:27 2018
     2018-09-19 20:15:58   Rolladen_Kind1_Sued_lastPosValue 0
     2018-09-20 20:15:20   Rolladen_Kind1_Sued_nextAstroTimeEvent Fri Sep 21 06:45:35 2018
     2018-09-19 20:16:00   Rolladen_Kind1_West_lastPosValue 0
     2018-09-20 20:15:58   Rolladen_Kind1_West_nextAstroTimeEvent Fri Sep 21 06:45:36 2018
     2018-09-20 20:15:57   Rolladen_SZ_Nord_lastPosValue 0
     2018-09-20 20:15:57   Rolladen_SZ_Nord_nextAstroTimeEvent Fri Sep 21 06:45:13 2018
     2018-09-20 20:15:43   Rolladen_SZ_West_lastPosValue 0
     2018-09-20 20:15:43   Rolladen_SZ_West_nextAstroTimeEvent Fri Sep 21 06:45:52 2018
     2018-09-20 20:15:37   Rolladen_Treppenhaus_lastPosValue 0
     2018-09-20 20:15:37   Rolladen_Treppenhaus_nextAstroTimeEvent Fri Sep 21 06:45:01 2018
     2018-09-20 20:15:29   Rolladen_WZ_SSO_lastPosValue 0
     2018-09-20 20:15:29   Rolladen_WZ_SSO_nextAstroTimeEvent Fri Sep 21 06:45:22 2018
     2018-09-20 20:15:09   Rolladen_WZ_SSW_lastPosValue 0
     2018-09-20 20:15:09   Rolladen_WZ_SSW_nextAstroTimeEvent Fri Sep 21 06:45:02 2018
     2018-09-16 09:05:43   lockOut         on
     2018-09-12 20:31:38   partyMode       off
     2018-09-18 23:02:05   room_Bad_OG     Rolladen_Bad_OG
     2018-09-18 23:02:05   room_Buero      Rolladen_Buero_Ost, Rolladen_Buero_Sued
     2018-09-18 23:02:05   room_Chillraum  Rolladen_Chillraum
     2018-09-18 23:02:05   room_Esszimmer  Jalousie_Links, Jalousie_Mitte, Jalousie_Rechts
     2018-09-18 23:02:05   room_Kind1       Rolladen_Kind1_Sued, Rolladen_Kind1_West
     2018-09-18 23:02:05   room_Schlafzimmer Rolladen_SZ_Nord, Rolladen_SZ_West
     2018-09-18 23:02:05   room_Treppenhaus Rolladen_Treppenhaus
     2018-09-18 23:02:05   room_Wohnzimmer Jalousie_WZ, Rolladen_WZ_SSO, Rolladen_WZ_SSW
     2018-09-18 23:02:05   state           active
     2018-09-18 23:02:05   sunriseTimeWeHoliday off
     2018-09-18 23:02:05   userAttrList    rolled out
   helper:
     shuttersList:
       Jalousie_Links
       Jalousie_Mitte
       Jalousie_Rechts
       Jalousie_WZ
       Rolladen_Bad_OG
       Rolladen_Buero_Ost
       Rolladen_Buero_Sued
       Rolladen_Chillraum
       Rolladen_Kind1_Sued
       ...
Attributes:
   AutoShuttersControl_antifreezeTemp 3
   AutoShuttersControl_autoAstroModeEvening CIVIL
   AutoShuttersControl_autoAstroModeMorning CIVIL
   AutoShuttersControl_autoShuttersControlComfort on
   AutoShuttersControl_autoShuttersControlEvening on
   AutoShuttersControl_autoShuttersControlMorning on
   AutoShuttersControl_temperatureReading temperature2
   AutoShuttersControl_temperatureSensor MYSENSOR_97
   icon       fts_shutter_automatic
   room       Steuerung

Mal schauen, aber ich bin ziemlich sicher, dass die Rolläden in den Kinderzimmern nicht fahren werden morgen früh.

(Muß mal sehen, dachte eigentlich, dass die Fensterkontakte vergeben wären, scheint aber teilweise nicht (mehr) der Fall zu sein...).
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 21 September 2018, 06:10:03
Da scheint sich bei Dir ein falscher Eintrag eingeschult zu haben. Der WindowRec_SubType sollte da nicht stehen. Ich befürchte da kommst du um ein löschen des versteckten Readings und neu starten nicht rum. Danach müssen alle Roommate und Fenstereinträge noch mal kurz angefasst werden. Nicht löschen die Attribute nur noch mal neu setzen.

Ich lasse mir da später mal was zu einfallen.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 21 September 2018, 06:46:26
Ein Problem konnte ich schon erkennen. Es hat was mit der Wochenendeteuerung zu tun wenn man die Sonderbehandlung aktiv hat.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 21 September 2018, 06:54:04
Hmmm, sieht irgendwie seltsam aus.

Vielleicht noch eine generelle Anmerkung zu dem Attribut-Änderungs-Thema, das hatten wir neulich indirekt schon:

Eigentlich sollte bei Änderung eines Attributwerts m.E. nicht der "alte" irgendwo im Hintergrund weiter drin bleiben. Wäre es nicht eine Lösung, in einem solchen Fall einfach das Notifydev komplett neu einzulesen, also alle aktuellen Rollläden durchzuscannen?

Damit verhindert man nicht nur solche Leichen wie neulich, sondern könnte ggf. auch dieses Problem (woher auch immer es kommt) beseitigen.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 21 September 2018, 07:05:26
Übrigens: Einen der Rolläden hatte ich angefaßt und twostate/threestate hin- und hergewechselt.

Der hat jetzt:
2018-09-21 06:47:05   AutoShuttersControl_Time_Sunrise Sat Sep 22 06:45:11 2018
2018-09-21 06:47:05   AutoShuttersControl_Time_Sunset Fri Sep 21 20:16:00 2018


Der 2. im selben Raum sieht diesbezüglich genauso aus, beide sind aber noch zu; die Zeitstempel im 2. Raum sind mind. an einem der Rollläden dieselben.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 21 September 2018, 08:03:17
Er wird IsDay falsch berechnen. Sofern du Roommates da hast. Deswegen fahren sie sie auch nicht wenn du auf Home stellst.
Das neu einlesen werde auf jeden Fall machen.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 21 September 2018, 08:47:17
Ich habe mal eine Hotfixversion hochgeladen. Damit sollten zu mindestens die Rolläden am WE korrekt fahren und für die Roommates auch korrekt ermittelt werden ob schon Tag ist oder nicht.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Papaloewe am 21 September 2018, 10:03:37
Hallo Leon,

mir ist noch eine Kleinigkeit aufgefallen:
Wenn man einen neuen Rolladen mit ROLLO-Modul, also "AutoShuttersControl = 1" einbindet, wird der Eintrag für "AutoShuttersControl_Pos_Cmd" auf den Wert "position" gesetzt. Das ist aber für die aktuelle ROLLO Version nicht mehr gültig und muss jetzt auch "pct" heißen.

Ansonsten bitte weiter so und vielen Dank für deinen Einsatz hier!

Gruß
Thomas
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 21 September 2018, 10:16:52
Zitat von: Papaloewe am 21 September 2018, 10:03:37
Hallo Leon,

mir ist noch eine Kleinigkeit aufgefallen:
Wenn man einen neuen Rolladen mit ROLLO-Modul, also "AutoShuttersControl = 1" einbindet, wird der Eintrag für "AutoShuttersControl_Pos_Cmd" auf den Wert "position" gesetzt. Das ist aber für die aktuelle ROLLO Version nicht mehr gültig und muss jetzt auch "pct" heißen.

Ansonsten bitte weiter so und vielen Dank für deinen Einsatz hier!

Gruß
Thomas

Hallo Thomas, dann musst Du bitte entscheiden ob Du die 2 nimmst und dafür die PosDown und PosUp Werte änderst oder die 1 nimmst als aus position halt pct machst.



Grüße
Leon
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Papaloewe am 21 September 2018, 10:38:46
Alles klar, aber das müssen dann alle machen, die das Rollo-Modul verwenden.  ::)

Zum Thema Ferien finde ich die Lösung aus dem Alarmclock-Modul nicht schlecht:
VacationDevice
Name of the vacation device.
There are 3 possibilities:
1.vacation device from typ holiday or Calendar.
<devicename>
Example: attr <name> VacationDevice Ferien
2.On state of a device.For example a dummy
<devicename>:<value>
Example: attr <name> VacationDevice MyDummy:Vacation
Here the AlarmTime 9_Vacation takes effect when the state of the dummy has the value Vacation
3.On a reading of a device.
<devicename>:<readingname>:<value>
Example: attr <name> VacationDevice MyDummy:Today:Vacation
VacationCheck
0 disables monitoring the vacation device
1 activates monitoring
VacationDays
List of days on which the alarmtime 9_Vacation may take effect
Example: attr <name> VacationDays 1|2|3|4|5
Default: 1|2|3|4|5|6|7


Ist bestimmt aufwendig das so umzusetzen, aber dafür auch sehr flexibel.

Gruß
Thomas
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 21 September 2018, 10:50:06
Zitat von: CoolTux am 21 September 2018, 10:16:52
oder die 1 nimmst als aus position halt pct machst.
Frage: Wenn das ROLLO-Modul per default auch pct verwendet: warum nicht das Array in Zeile 157 ändern oder eben die Arrays um eine 3 ergänzen, die für das "alte"-ROLLO-Verhalten steht? (Du scheinst das ja selbst in dieser Form zu benötigen, das ist allerdings dann die große Ausnahme ;) ).

Könnte man nicht bei der Gelegenheit dann auch die 5 Angaben in Zeile 159ff auf HH:MM ändern?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 21 September 2018, 10:57:29
Zitat von: Papaloewe am 21 September 2018, 10:38:46
Alles klar, aber das müssen dann alle machen, die das Rollo-Modul verwenden.  ::)

Zum Thema Ferien finde ich die Lösung aus dem Alarmclock-Modul nicht schlecht:
VacationDevice
Name of the vacation device.
There are 3 possibilities:
1.vacation device from typ holiday or Calendar.
<devicename>
Example: attr <name> VacationDevice Ferien
2.On state of a device.For example a dummy
<devicename>:<value>
Example: attr <name> VacationDevice MyDummy:Vacation
Here the AlarmTime 9_Vacation takes effect when the state of the dummy has the value Vacation
3.On a reading of a device.
<devicename>:<readingname>:<value>
Example: attr <name> VacationDevice MyDummy:Today:Vacation
VacationCheck
0 disables monitoring the vacation device
1 activates monitoring
VacationDays
List of days on which the alarmtime 9_Vacation may take effect
Example: attr <name> VacationDays 1|2|3|4|5
Default: 1|2|3|4|5|6|7


Ist bestimmt aufwendig das so umzusetzen, aber dafür auch sehr flexibel.

Gruß
Thomas

Das Thema Ferienkalander oder auch andere Art von Kalender haben wir ja nun durch denke ich. Man kann es in eine Holiday Datei einpflegen dann wird es automatisch beachtet, oder eben als Extra Kalenderdevice mit 0 und 1 und einem entsprechenden Attribut. Ich muss mir das aber eh noch mal anschauen mit dem extra Device.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Fixel2012 am 21 September 2018, 11:42:34
*Marker zum mitlesen*
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Cluni am 21 September 2018, 13:00:09
Zitat von: Fixel2012 am 21 September 2018, 11:42:34
*Marker zum mitlesen*

Man kann auch einfach auf den Button "Benachrichtigung" klicken - dann bekommen nicht alle 5.342.854 Mitlesenden eine Benachrichtigung, dass du nun mitliest....   ::)
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 21 September 2018, 13:20:46
Zitat von: Cluni am 21 September 2018, 13:00:09
Man kann auch einfach auf den Button "Benachrichtigung" klicken - dann bekommen nicht alle 5.342.854 Mitlesenden eine Benachrichtigung, dass du nun mitliest....   ::)
Schon zutreffend. Es gibt aber einen wesentlichen Unterschied: Es ist aber auch eine öffentliche Bekundung, dass man an was interessiert ist...

Fasse das mal als Rückmeldung auf, dass der Interessentenkreis mind. um eine Person gewachsen ist. Womit z.B. auch die Frage der Schwierigkeit der Ersteinrichtung usw. ein leicht anderes Gewicht erlangt.

(Es braucht sich keiner bei Cooltux für manche (vielleicht lästigen) Details zur Ersteinrichtung auseinanderzusetzen, wenn's eh' keinen juckt; die hier Mittestenden bekommen das hoffentlich auch hin, ohne unnötig Kapazitäten auf Entwicklerseite zu binden ;) ).
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 21 September 2018, 14:22:01
 ;D
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: FunkOdyssey am 21 September 2018, 14:55:30
Sehr sehr gut. Gut gemacht. Gefällt mir.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 21 September 2018, 15:19:01
Ideen für mehr Informationen? Welche wären noch wichtig auf einem Punkt?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: FunkOdyssey am 21 September 2018, 15:22:15
Ich finde persönlich in allen Readings die Formatierung des Datumstempels ein wenig ungünstig.
Kurz und knackig: 21.09.2018 - 20:00:00 Uhr finde ich einfacher zu lesen und damit übersichtlicher.

Und ehrlich gesagt frage ich mir, ob ich in dieser Tabelle überhaupt die Astro-Zeiten sehen will.
Wie wäre es, wenn man die prognostizieren, echten Fahrzeiten anzeigt? Was will ich Sunset sehen, wenn die Jalousie um exakt 19:00 Uhr fahren soll.

Wieso gibt es zwischen den Sunrise/Sunset-Zeiten eigentlich einen Versatz? Ich weiß, dass das vielleicht jeder anders sieht, aber wenn im Wohnzimmer vier Jalousien alle paar Sekunden anfangen herunterzufahren, so habe ich über einen längeren Zeitraum den Lärm im Ohr. Ich fahre pro Raum bzw. pro Himmelsrichtung die Jalousien nahezu zeitgleich runter.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 21 September 2018, 15:28:52
Zitat
AutoShuttersControl_Offset_Minutes_Evening - maximale zufällige Verzögerung in Minuten (minimal 1) bei der Berechnung der Fahrzeiten für Abends
AutoShuttersControl_Offset_Minutes_Morning - maximale zufällige Verzögerung in Minuten (minimal 1) bei der Berechnung der Fahrzeiten für Morgens

Ich sollte das in der Darstellung anders benennen. Es isnd in der Tat die korrekten Fahrzeiten die in den Readings stehen, basierend auf den Astro Daten oder einer festen Zeit unter einbeziehen von Offset Werten. Wenn Du 0 machst müssten alle gleich sein, muss ich mal testen.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 21 September 2018, 15:33:30
Was haltet Ihr von

AutoShuttersControl_Time_Sunrise = AutoShuttersControl_Time_DriveUp
AutoShuttersControl_Time_Sunset = AutoShuttersControl_Time_DriveDown
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 21 September 2018, 15:46:58
Zitat von: CoolTux am 21 September 2018, 15:33:30
Was haltet Ihr von

AutoShuttersControl_Time_Sunrise = AutoShuttersControl_Time_DriveUp
AutoShuttersControl_Time_Sunset = AutoShuttersControl_Time_DriveDown
Was genau ist damit gemeint?

An sich finde ich eine eher "nutzerdenke-orientierte" Namensgebung gut, allerdings impliziert Sunrise&Co. etwas dynamisches, sich änderndes. Wer fixe Zeiten hat, könnte irritiert sein.
=> Morning /Evening?
Bin aber kein Marketing-Mensch, Hauptsache, es funktioniert wie in der CR beschrieben und der Name ist nicht komplett daneben...
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 21 September 2018, 16:25:49
Zitat von: Beta-User am 21 September 2018, 15:46:58
Was genau ist damit gemeint?

An sich finde ich eine eher "nutzerdenke-orientierte" Namensgebung gut, allerdings impliziert Sunrise&Co. etwas dynamisches, sich änderndes. Wer fixe Zeiten hat, könnte irritiert sein.
=> Morning /Evening?
Bin aber kein Marketing-Mensch, Hauptsache, es funktioniert wie in der CR beschrieben und der Name ist nicht komplett daneben...


Heißt ich ändere die Readings von nach. Die Zeiten sind ja entsprechend von Sunset oder Sunrise oder eben wenn feste Zeiten vergeben sind plus etwas Zeit drauf vom Offset.

Im übrigen habe ich schon mal überlegt wie man die Rollos pro Raum fahren kann, ist aber leider nicht ganz so einfach im derzeitigen Konzept.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 21 September 2018, 16:50:44
Zitat von: FunkOdyssey am 21 September 2018, 15:22:15
Ich finde persönlich in allen Readings die Formatierung des Datumstempels ein wenig ungünstig.
Kurz und knackig: 21.09.2018 - 20:00:00 Uhr finde ich einfacher zu lesen und damit übersichtlicher.

Ich nehme mich des Themas in den kommenden Tagen noch einmal an.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 21 September 2018, 17:48:47
Zitat von: CoolTux am 21 September 2018, 16:25:49
Heißt ich ändere die Readings von nach. Die Zeiten sind ja entsprechend von Sunset oder Sunrise oder eben wenn feste Zeiten vergeben sind plus etwas Zeit drauf vom Offset.
Ah, ok, Danke für die Erläuterung.

Zitat von: CoolTux am 21 September 2018, 16:25:49
Im übrigen habe ich schon mal überlegt wie man die Rollos pro Raum fahren kann, ist aber leider nicht ganz so einfach im derzeitigen Konzept.
Das ganze raumbezogen aufzuziehen finde ich "an sich" eine sehr gute Idee; betrifft ja auch den Roommate-Status und vermutlich einiges andere mehr. Aber leider nicht alles, die Fahrbefehle, Winkel usw. für Beschattung können innerhalb eines Raums abweichen usw..

Allerdings würde es dann noch unübersichtlicher zu überblicken, was wo zu finden ist. Ich war auch am überlegen, ob es nicht eine Überlegung wert wäre, alle Konfigurationsdaten nur im ASC-Device selbst zu verwalten (lightscene scheint das ähnlich zu machen)? Die Idee, das als Attribute an den Rollläden zu machen, stammt noch vom "Urvater", innerhalb eines echten Moduls hätte man da an sich mehr Möglichkeiten.
Allerdings wäre dann die Frage, wie man die ganzen Daten für den User zugänglich und konfigurierbar macht? Programmieren einer eigenen UI dafür? (Dürfte eher unrealistisch sein)

Was aber ginge: Nach dem ersten Rolladen in einem Raum könnte man prüfen, ob die anderen im selben Raum dieselben Vorgaben haben. Wenn ja: dieselbe Fahrzeit (ohne weitere Random-Funktion), wenn nein natürlich nicht. Müßte durch eine Schleife in Schleife gehen, bei der man ggf. jeden weiteren raus-grep-t, nachdem man dieselben timer angelegt hat. (Hab nicht in den Code gesehen und kann daher nicht sagen, ob das an sich ginge)
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 21 September 2018, 19:56:54
Ok so?  :)
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 21 September 2018, 20:04:39
Version 0.1.52 habe ich soeben hochgeladen. Changetime format, add get command.

Viel Spaß
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 21 September 2018, 20:31:16
Sieht gut aus.

In meiner Liste taucht noch einer auf, der "RolloKinZim..." heißt. Ist vermutlich keine Absicht, paßt jedenfalls nicht zur Installation hier ;D .
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: FunkOdyssey am 21 September 2018, 21:15:43
Wer oder was ist RolloKinZimSteven_F1 in meinem FHEM? 😄
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 21 September 2018, 21:44:20
In welcher Liste und wo?  :-[
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 21 September 2018, 21:45:48
Sehe geade, wenn überhaupt dann im Logfile als Logausgabe.

Habe eine gefixte Version hochgeladen.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 21 September 2018, 21:48:03
Über das "get"....
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 21 September 2018, 21:53:49
komisch. Kannst Du bitte einmal die neue Vesion von eben testen ob das da auch so ist?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: FunkOdyssey am 21 September 2018, 21:59:47
War im neuen Get. Ist jetzt weg.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 21 September 2018, 22:08:21
Wie komisch ist das denn. Danke fürs testen und bescheid geben. lach
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 21 September 2018, 22:14:07
Habe noch eine 0.1.53 hochgeladen. Es gab da noch Debug Logausgaben. Man muss nicht unbedingt gleich updaten.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 23 September 2018, 10:27:40
Wer die Wochenendsteuerung aktiv hat, wird sicherlich bemerkt haben das da noch Nachbesserungsbedarf besteht.
Ich werde mich die Tage versuchen daran zu machen. Auch habe ich gemerkt das die Rolläden zwar runter aber nicht mehr hoch fahren wenn der Roommate absent ist. Das muss ich mir genauer anschauen.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 23 September 2018, 11:25:12
Das mit dem Nichtöffnen beschränkt sich m.E. nicht darauf, dass der Roommate absent ist. Am WE war einer meiner Residents home/asleep...
WE-Steuerung ist aktiv, der nächste Timer für hoch steht auf Dienstag (Angabe aus dem Rollladen-Device):
ZitatAutoShuttersControl_Time_DriveDown 23.09.2018 - 20:15:51 2018-09-23 09:30:22
AutoShuttersControl_Time_DriveUp 25.09.2018 - 09:30:47 2018-09-23 09:30:22
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 23 September 2018, 12:02:34
Zitat von: Beta-User am 23 September 2018, 11:25:12
Das mit dem Nichtöffnen beschränkt sich m.E. nicht darauf, dass der Roommate absent ist. Am WE war einer meiner Residents home/asleep...
WE-Steuerung ist aktiv, der nächste Timer für hoch steht auf Dienstag (Angabe aus dem Rollladen-Device):
Ja das kommt noch hinzu. Ich habe da zu viel Spielraum gelassen was das beachten des fahrens am selben Tag an geht. Wird wohl noch etwas dauern bis alles ausgemerzt ist. Das Problem kommt durch die WE Berechnung. Schaue ich mir noch mal an.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 24 September 2018, 09:37:01
Moin, Problem ist vermutlich bekannt, aber dennoch zur Info: heute morgen hat sich (fast, s.u.) keiner der Rollläden bewegt.

Letzter FHEM-Start war gestern abend nach sunset, Version ist 0.1.53, WE-control ist aktiviert.

Timer standen alle auf dem WE-Wert, sind dann aber nach Ablauf auch nicht gefahren, jetzt ist time_up wieder auf übermorgen (bei allen, abgefragt über das "get").

Was sich scheinbar bewegt hat, waren die im Schlafzimmer, da gab es einen Wechsel im Roommate-Status.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 24 September 2018, 09:46:54
Zitat von: Beta-User am 24 September 2018, 09:37:01
Moin, Problem ist vermutlich bekannt, aber dennoch zur Info: heute morgen hat sich (fast, s.u.) keiner der Rollläden bewegt.

Letzter FHEM-Start war gestern abend nach sunset, Version ist 0.1.53, WE-control ist aktiviert.

Timer standen alle auf dem WE-Wert, sind dann aber nach Ablauf auch nicht gefahren, jetzt ist time_up wieder auf übermorgen (bei allen, abgefragt über das "get").

Was sich scheinbar bewegt hat, waren die im Schlafzimmer, da gab es einen Wechsel im Roommate-Status.

Danke Dir für die Info. Ich hoffe das ich die Tage dazu komme mir das ganze etwas genauer an zu schauen.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 24 September 2018, 10:35:12
Keine Hektik.

Aber noch ein anderer Punkt, den ich aber noch nicht vertieft getestet habe, der mir aber "gefühlt" nicht passend vorkommt:

Ausgangszustand: Jalousie ist nach abendlicher Schließzeit zu (HM, also geschlossen=0 pct). Will ich dann nochmal auf die Terrasse, lasse also die Jalousie hochfahren und mach' bei ca. 60% offen die Tür auf (Jalousie fährt noch). Ergebnis: Jalousie fährt wieder nach unten (after_Comfort steht auf 80). Erwartung wäre gewesen, dass entweder nichts passiert, die Jalousie also weiter nach oben fährt (ggf. nur bis 80%).
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 24 September 2018, 10:48:20
Zitat von: Beta-User am 24 September 2018, 10:35:12
Keine Hektik.

Aber noch ein anderer Punkt, den ich aber noch nicht vertieft getestet habe, der mir aber "gefühlt" nicht passend vorkommt:

Ausgangszustand: Jalousie ist nach abendlicher Schließzeit zu (HM, also geschlossen=0 pct). Will ich dann nochmal auf die Terrasse, lasse also die Jalousie hochfahren und mach' bei ca. 60% offen die Tür auf (Jalousie fährt noch). Ergebnis: Jalousie fährt wieder nach unten (after_Comfort steht auf 80). Erwartung wäre gewesen, dass entweder nichts passiert, die Jalousie also weiter nach oben fährt (ggf. nur bis 80%).

Das dürfte so in der Tat nicht sein. Davon aber mal ab, warum machst Du nicht einfach die Tür auf, das Rollo sollte dann von alleine auf AutoShuttersControl_Pos_after_ComfortOpen fahren.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 24 September 2018, 10:53:27
Ich habe gerade mal geschaut. Laut Code funktioniert das mit dem automatisch hochfahren nur bei AutoShuttersControl_WindowRec_subType = threestate. Das muss ich mir noch mal anschauen.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 24 September 2018, 11:02:34
Kommando zurück. Er würde bei einem twostate Kontakt nur auf lüftenposition fahren wenn du die Tür auf machst.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 24 September 2018, 11:09:50
Es ist ein twostate (bzw. als solcher festgelegt).

Da das eine Jalousie ist, die länger fährt und ich eh' auf dem Weg woandershin war, wo der Taster am Weg lag, hat sich der Ablauf halt so ergeben. (Ich will mir auch nicht überlegen müssen, wie ich meiner Steuerung und meinen Mitmenschen am besten erkläre, was wann wie zu tun ist, um ein bestimmtes Ergebnis zu erreichen; die Technik soll unauffällig sein und das Fahrverhalten daher nicht von solchen Zufälligkeiten und pers. Vorlieben abhängen ;) ).
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Cluni am 24 September 2018, 11:19:10
Zitat von: CoolTux am 24 September 2018, 11:02:34
Kommando zurück. Er würde bei einem twostate Kontakt nur auf lüftenposition fahren wenn du die Tür auf machst.

Du müsstest vor der Fahrt mehrere Prüfungen einbauen:
- Motor bereits in Betrieb ==> nix tun
- Position oberhalb oder gleich der anzufahrenden Position ==> nix tun
- Position niedriger ==> fahren auf Position

Habe ich auch etwas mit gekämpft, um das gescheit zum Laufen zu bringen in meinem Script...
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Cluni am 24 September 2018, 11:21:19
Ach so, noch was - genauso müssen natürlich Merker fürs Lüften oder sonstiges zurückgesetzt werden, sobald da jemand manuell etwas verändert.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 24 September 2018, 13:28:01
Zitat von: Cluni am 24 September 2018, 11:19:10
- Position oberhalb oder gleich der anzufahrenden Position ==> nix tun
- Position niedriger ==> fahren auf Position

Das ist bereits beides umgesetzt und genau das hat auch bei Beta-User zugeschlagen.

Zitat von: Cluni am 24 September 2018, 11:19:10
- Motor bereits in Betrieb ==> nix tun

Die Idee ist gut, aber wie stelle ich das fest. Und zwar Unabhängig von jeglichen Hardware und Modul Eigenschaften.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Cluni am 24 September 2018, 13:37:50
Zitat von: CoolTux am 24 September 2018, 13:28:01
Das ist bereits beides umgesetzt und genau das hat auch bei Beta-User zugeschlagen.
Na ja. Er hat ja geschrieben, dass sie bei ~60% war und dann wieder runter gefahren ist, statt auf 80% zu fahen?!

Zitat von: CoolTux am 24 September 2018, 13:28:01
Die Idee ist gut, aber wie stelle ich das fest. Und zwar Unabhängig von jeglichen Hardware und Modul Eigenschaften.
Tja, gute Frage. Ich habe das bei mir das an das Komfort-Notify geknüpft, welches auf das Motor-Event (bei HM) reagiert...
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 24 September 2018, 13:46:56
Zitat von: Cluni am 24 September 2018, 13:37:50
Tja, gute Frage. Ich habe das bei mir das an das Komfort-Notify geknüpft, welches auf das Motor-Event (bei HM) reagiert...
Wäre dann natürlich nur HM spezifisch. Auch irgendwie doof. Muß ich mir mal anschauen bei Dir.


Zitat von: Cluni am 24 September 2018, 13:37:50
Na ja. Er hat ja geschrieben, dass sie bei ~60% war und dann wieder runter gefahren ist, statt auf 80% zu fahen?!
Hier muß ich noch mal schauen. beta-user was steht bei Dir für ein Wert für AutoShuttersControl_Ventilate_Pos?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: MarkusHiba am 24 September 2018, 13:50:12
Hallo,

wie wäre es mit ein Attribut wo man das Rieding vom Motor einträgt und abfragt.

Gruß MarkusHiba

Gesendet von meinem G8141 mit Tapatalk

Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 24 September 2018, 13:58:15
Zitat von: CoolTux am 24 September 2018, 13:28:01
Das ist bereits beides umgesetzt und genau das hat auch bei Beta-User zugeschlagen.
CoolTux hat dahingehend recht, dass die Ventilate-Pos auf 30% gestanden hat, und ich die after_Comfort als gedanklichen Bezugspunkt hatte, warum auch immer ??? . Dann dürfte das passen (bzw. jedenfalls kein Fehler gewesen sein).

Ansonsten ist es vermutlich beliebig schwierig, festzustellen, ob ein Rolladen fährt oder nicht. Bei HM kann man das am STATE ("set_...") oder am Motor-Reading (nicht "stop", wenn ich das richtig im Kopf habe) ablesen. Vielleicht könnte man das über ein Array abbilden, das für diverse (Sub-)Typen die "jeweils richtige Frage" enthält? (Ins Unreine: %subtype => {Reading => Value})

Das jeweils durch den User einstellen zu lassen halte ich für nicht so gut, sollte allenfalls eine Notlösung in Fällen sein, die man damit nicht abbilden kann.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Cluni am 24 September 2018, 14:02:01
Die Idee ist zwar gut, aber dafür musst du die Aktoren ja kennen und ggf immer wieder neue einpflegen. Die Idee, das bei inkompatiblen, anderen Aktoren einstellbar zu machen, finde ich aber gut.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 24 September 2018, 14:03:31
Auf jeden Fall haben wir noch so einiges auf der ToDo Liste  ;D
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Cluni am 24 September 2018, 14:05:19
Alleine die Abschattung ist nicht ohne. Ich glaube das ist bei mir die längste Routine... :P
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 24 September 2018, 14:10:19
Zitat von: CoolTux am 24 September 2018, 14:03:31
Auf jeden Fall haben wir noch so einiges auf der ToDo Liste  ;D
Yup. Aber wie meistens gilt auch hier: Wenn man's am Anfang nicht richtig konzipiert, muß man hinterher den mehrfachen Aufwand reinstecken.

Zitat von: Cluni am 24 September 2018, 14:02:01
aber dafür musst du die Aktoren ja kennen und ggf immer wieder neue einpflegen.
Ist zwar richtig, aber so oft kommen keine neuen Rolladenaktoren auf den Markt. Demnächst bekommen wir sowieso alles so standardisiert, so dass es spätestens ab 2045 egal ist, ob es CUL_HM, HMCCU-Device, HM-IP V7, ROLLO oder irgend ein anderes Modul ist, das dahinter steckt ;) .
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Cluni am 24 September 2018, 14:12:16
2045 komme ich so langsam in das Alter, wo es mich nicht mehr interessieren wird, ob die Rollladen gerade oben oder unten sind... :P

...den Partymodus brauche ich ja jetzt schon fast nicht mehr.  ::)
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 24 September 2018, 14:16:04
Zitat von: Cluni am 24 September 2018, 14:12:16
2045 komme ich so langsam in das Alter, wo es mich nicht mehr interessieren wird, ob die Rollladen gerade oben oder unten sind... :P

...den Partymodus brauche ich ja jetzt schon fast nicht mehr.  ::)
:P   ;D
Habe nicht vor daraus einen BER zu machen. Lach
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Cluni am 24 September 2018, 14:17:51
Auch nicht, wenn du von Vater Staat genauso viel Geld dafür bekommen würdest???  :o
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 24 September 2018, 14:33:47
Nee Du nicht mal dann. Wiederspricht komplett meinen Anforderungen an mich selbst.
Ich bin im übrigen jemand dem man nicht mit Geld locken kann. Ich hatte das schon mal und habe entsprechend gelebt. Hat mir auch nicht mehr Zufriedenheit im Leben gebracht.
Nun lebe ich ruhiger und vor allem für meine Familie  :)
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Cluni am 24 September 2018, 14:34:52
Das ist eine gute Einstellung! Bleib so!
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 24 September 2018, 15:35:05
Ich habe eben eine neue Version hochgeladen. Ich hoffe da die WE Problematik in den Griff bekommen zu haben.
Ich würde aber empfehlen das diese Version erstmal nur Leute testen die WE verwenden und denen es nicht stört oder sie drauf achten ob die Zeiten stimmen oder nicht.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Stonemuc am 24 September 2018, 19:20:45
Kann ich hier mit meinen FSB14 Enocean Aktoren anknüpfen?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 24 September 2018, 19:29:40
Ich würde da einfach mal frech ja sagen.
Hast du einen set Befehl der in Prozent von 0 bis 100 die Rolläden fahren kann?
Heißt Dein dazugehöriges Reading genau so wie der set Befehl?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Stonemuc am 25 September 2018, 06:28:12
Ja klar. Ich kann entweder mit open oder close komplett fahren oder mit einem set Eno_xxx 50 den entsprechenden Rollladenaktor z.B. in Position 50% bringen.
Folgende Readings hab ich - mal mit entsprechenden Werten für den jetzigen Zustand (zu) befüllt:

anglePos         90             2018-09-24 22:17:42
block                unlock      2018-09-24 19:39:46
endPosition    closed      2018-09-24 22:17:42
position           100           2018-09-24 22:17:42
state                closed      2018-09-24 22:17:42
teach              4BS teach-in sent 2018-09-18 08:40:08
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Cluni am 25 September 2018, 06:34:02
Zitat von: Stonemuc am 25 September 2018, 06:28:12
position           100           2018-09-24 22:17:42

Moin, das sieht doch gut aus.
Versuche mal bitte, ob der Rollladen mit dem Befehl
set NAME position x
(Wobei NAME der Name deines Rollladen und x ein Wert zwischen 0 und 100 ist) fährt.


Gesendet von iPhone mit Tapatalk
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 25 September 2018, 08:54:03
Moin,

Rückmeldung zur letzten Version (0.1.54, eingespielt heute morgen vor der ersten Öffnen-Zeit):

Mehrere Rollläden sind heute morgen nicht gefahren, nämlich

- zwei, bei denen ich Ursache darin vermute, dass die gar keine Fenstersensoren haben (das ist neu; keine Fenstersensoren anzugeben sollte m.E. auch dauerhaft so bleiben können => Festverglasung)

- 4, bei denen sich der Roommate-Status seit vorgestern abend bzw. noch länger nicht von "absent" weg bewegt hat; bei zwei anderen, die einen "beweglicheren" Roommate haben, passt der Zeitstempel des letzten level-Readings zur Vorgabe im Attribut.

EDIT: Formatierung geändert (was ein Sch...)
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Stonemuc am 25 September 2018, 11:23:20
Ja klar funktioniert das - ich hab ja standartmäßig schon ein kleines "Steuerinterface"
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 25 September 2018, 11:32:21
Zitat von: Beta-User am 25 September 2018, 08:54:03
Moin,

Rückmeldung zur letzten Version (0.1.54, eingespielt heute morgen vor der ersten Öffnen-Zeit):

Mehrere Rollläden sind heute morgen nicht gefahren, nämlich

- zwei, bei denen ich Ursache darin vermute, dass die gar keine Fenstersensoren haben (das ist neu; keine Fenstersensoren anzugeben sollte m.E. auch dauerhaft so bleiben können => Festverglasung)

- 4, bei denen sich der Roommate-Status seit vorgestern abend bzw. noch länger nicht von "absent" weg bewegt hat; bei zwei anderen, die einen "beweglicheren" Roommate haben, passt der Zeitstempel des letzten level-Readings zur Vorgabe im Attribut.

EDIT: Formatierung geändert (was ein Sch...)

Ich habe auch 5 ohne Fensterkontakt. Die laufen.
Kannst Du mir eine Uhrzeit sagen? So gegen halb sieben in etwa?


Grüße
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 25 September 2018, 11:39:07
Update war kurz vor 6, Soll-Fahrzeit 6:45 Uhr.

Die beiden haben auch keinen Roommate (wie der Rolladen dazwischen, der aber einen FK hat, den ich vor 6:45 auch ausgelöst hatte).
Könnte höchstens noch ein Funkproblem sein, da einer der beiden über ein anderes preferred IO (VCCU) läuft (neuerdings läut ja alles wieder gleichzeitig an, oder?).
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 25 September 2018, 11:41:23
Zitat von: Beta-User am 25 September 2018, 11:39:07
Update war kurz vor 6, Soll-Fahrzeit 6:45 Uhr.

Die beiden haben auch keinen Roommate (wie der Rolladen dazwischen, der aber einen FK hat, den ich vor 6:45 auch ausgelöst hatte).
Könnte höchstens noch ein Funkproblem sein, da einer der beiden über ein anderes preferred IO (VCCU) läuft (neuerdings läut ja alles wieder gleichzeitig an, oder?).

Hattest Du mal geschaut wie die Zeiten nach dem hochfahren von FHEM waren? Stand denn dort als Fahrzeit up 25.09.2018 6:45 Uhr?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 25 September 2018, 11:46:08
Du kannst auch mal schauen was bei Dir im Moduldevice unter MEINROLLADEN_lastPosValue steht und wie da der Zeitstempel aus schaut. Wenn das mit heute morgen passt und die Position auch dann sollte er gefahren sein.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 25 September 2018, 11:57:06
Hmm, also:

Die Zeitstempel im Moduldevice sehen für alle betreffenden Rollläden gut aus, alle timer scheinen ein paar Sekunden versetzt in der Zeit von 6:45 bis 6:46 durchgelaufen zu sein - das deutet darauf hin, dass es kein Funkproblem war.

Die alten Zeitstempel am Rolladendevice selbst sind wegen manueller Fahrt weg, nur die beiden ASC-Angaben sind mit dem zum ASC-Moduldevic passenden Zeitstempel (6:45.xx) da; da steht allerdings die up-Zeit übrigens wieder auf übermorgen früh.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 25 September 2018, 12:12:48
Zitat von: Beta-User am 25 September 2018, 11:57:06
Hmm, also:

Die Zeitstempel im Moduldevice sehen für alle betreffenden Rollläden gut aus, alle timer scheinen ein paar Sekunden versetzt in der Zeit von 6:45 bis 6:46 durchgelaufen zu sein - das deutet darauf hin, dass es kein Funkproblem war.

Die alten Zeitstempel am Rolladendevice selbst sind wegen manueller Fahrt weg, nur die beiden ASC-Angaben sind mit dem zum ASC-Moduldevic passenden Zeitstempel (6:45.xx) da; da steht allerdings die up-Zeit übrigens wieder auf übermorgen früh.

Auf Übermorgen Früh? Ich habe gerade mal geschaut. Interessanter Weise habe ich genau einen bei dem es auch auf übermorgen steht. Mal schauen was da heute Abend steht. Und ich werde mal ein paar Logausgaben einbauen um mal zu schauen wie er darauf gekommen ist.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 25 September 2018, 12:19:14
Yup, übermorgen (27.09.). Wenn es mir nicht ungewöhnlich vorgekommen wäre, hätte ich es nicht erwähnt ;) .
Hab allerdings nicht alle durchgesehen, sondern mir erst mal dur die "komischen" vorgenommen.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Deckoffizier am 25 September 2018, 14:01:10
Hallo,

hat zwar heute morgen bei meinen beiden unterschiedlichen Testrollladen(Uniroll,Siro) gut geklappt,
aber die Zeit für übermorgen verwirrt mich auch etwas.

AutoShuttersControl_Time_DriveDown
   
25.09.2018 - 19:36:37
   
2018-09-25 07:00:41
AutoShuttersControl_Time_DriveUp
   
27.09.2018 - 07:00:10
   
2018-09-25 07:00:41

Mal sehen was heute Abend passiert.

Gruß
Hans-Jürgen
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 25 September 2018, 14:07:51
Das mit übermorgen hatte ich heute auch. Meistens korrigiert es sich beim nächsten Lauf.
Ich habe heute noch eine Codeanpassung gemacht diesbezüglich. Werde erstmal testen.

Bitte seit so nett und schaut euch nach einem Sunrise Sunset Lauf mit geht alle neuen Zeiten an.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Deckoffizier am 25 September 2018, 22:05:25
Hallo,

Ich habe heute noch eine Codeanpassung gemacht diesbezüglich. Werde erstmal testen.

Bitte seit so nett und schaut euch nach einem Sunrise Sunset Lauf mit geht alle neuen Zeiten an.


habe das Modul noch mal neu eingespielt und die Zeiten aktualisiert.
Sieht soweit alles plausibel aus.
Drücke Dir die Daumen, dass die Anstrengung geholfen hat!

Gruß
Hans-Jürgen
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 25 September 2018, 23:39:16
Aktuell, erste Runde sieht gut aus. Heute Abend Rollos gefahren, alles neu berechnet und für Morgens und Abends korrekt morgiges Datum. Werde morgen früh die zweite Runde sehen.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Stonemuc am 26 September 2018, 08:45:53
Ich bin gespannt und werde wohl mal einen Versuch wagen die ganze Sache zu installieren. Hardwaremäßig geht ja alles mit dem set xy position xy. Ich hab allerdings keinen einzigen Fensterkontakt. Brauch ich die zwingend? Residets versuche ich noch vorher einzurichten. Entweder über Bluetooth oder WlanErkennung der Mobiltelefone über Fritzbox.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 26 September 2018, 08:54:40
Zitat von: Stonemuc am 26 September 2018, 08:45:53
Ich bin gespannt und werde wohl mal einen Versuch wagen die ganze Sache zu installieren. Hardwaremäßig geht ja alles mit dem set xy position xy. Ich hab allerdings keinen einzigen Fensterkontakt. Brauch ich die zwingend? Residets versuche ich noch vorher einzurichten. Entweder über Bluetooth oder WlanErkennung der Mobiltelefone über Fritzbox.

Nein Fensterkontakt ist nicht nötig. Geht auch ohne
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 26 September 2018, 08:55:27
Sowohl gestern Abend als auch heute Morgen wurden bei mir die korrekten Zeiten berechnet und natürlich auch angezeigt.
Hoffe nur es fehlt dann nicht wieder irgendwo anders  ;D
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 26 September 2018, 09:42:03
Kurze Zwischeninfo: meine beiden "Ausreißer" von gestern (die ohne FK's) sind heute morgen auch gefahren.

Die mit den abwesenden Roommates immer noch nicht; da werde ich mir die Einstellungen usw. nochmal zu Gemüte führen.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 26 September 2018, 10:00:08
Zitat von: Beta-User am 26 September 2018, 09:42:03
Kurze Zwischeninfo: meine beiden "Ausreißer" von gestern (die ohne FK's) sind heute morgen auch gefahren.

Die mit den abwesenden Roommates immer noch nicht; da werde ich mir die Einstellungen usw. nochmal zu Gemüte führen.

Auh gut das Du das sagst, ich wollte mir das ja auch noch mal anschauen.


Kurze Info "lustiger Weise" am Rande.
Ich habe gestern meine erste Testmigration in meinen neuen Virtualisierungscluster hinter mir. Habe einen postgresql DB Server und einen FHEM Server aufgesetzt und meine Produktivumgebung migriert. Das System startet und alles schick. Dann habe ich eine Änderung gemacht und beim abspeichern ist mir FHEM mit einem Neustart um die Ohren geflogen. Nach kurzen schauen im Log kam raus das die Tabelle mit einem max Character von 50 bei den Attributen angelegt wurden. Das habe ich bei 3 Attributen mit 3-4 Character überschritten und darauf hin ist FHEM neugestartet ohne zu speichern.
Also wäre es glaube besser unsere Attributsnamen doch irgendwie kürzer zu wählen. Dann müsste aber alles gelöscht und neu angelegt werden.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 26 September 2018, 10:05:23
Zitat von: CoolTux am 26 September 2018, 10:00:08
Also wäre es glaube besser unsere Attributsnamen doch irgendwie kürzer zu wählen. Dann müsste aber alles gelöscht und neu angelegt werden.
...das ist das Risiko, das man als Beta-Tester eingeht... :)
Sehe darin kein sooo großes Problem, schließlich gibt es "list -r <devspec>". Das Ergebnis nach kate oder notepad++, Rauswerfen, was man nicht ändern will, der Rest: Suchen+Ersetzen (oder in Teilen über die abzuändernden ReadingsGroups die Defaults wieder überschreiben...)

Könntest du bitte bei der Gelegenheit die Zeiten noch auf HH:MM umstellen (und evtl. etwas nachbarfreundlichere Defaults setzen) oder spricht da was massiv dagegen?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 26 September 2018, 11:03:40
Das mit der Zeit sollte nicht das Problem sein. Mache ich die Tage.
Das ändern der Attributsnamen von AutoShuttersControl_... nach ASC_... werde ich beim stable Release machen. also von 0.1.x nach 0.2.x. Wird aber noch ein paar Wochen brauchen.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 26 September 2018, 11:11:23
Das Problem das die Rolläden frühs nicht gefahren sind wenn der Roommate absent war habe ich nun gelöst. Funktioniert nun auch.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 26 September 2018, 11:21:43
Zitat von: CoolTux am 26 September 2018, 11:03:40
Das mit der Zeit sollte nicht das Problem sein. Mache ich die Tage.
Das ändern der Attributsnamen von AutoShuttersControl_... nach ASC_... werde ich beim stable Release machen. also von 0.1.x nach 0.2.x. Wird aber noch ein paar Wochen brauchen.
Sowas sollte m.E. asap erfolgen: Jeder, der hier als Tester einsteigen will (Stonemuc, z.B.) wird froh sein, wenn er das nicht mehr muß. Und an sich sollte das in einem einzigen "Suchen/Ersetzen-Durchlauf" gehen.

Übergangsweiser Vorschlag: ggf. eine Zwischenversion veröffentlichen (anderer Branch), die den User jetzt nicht gleich zwingt, die Attribute in der Installation jetzt nachzuziehen, sondern etwas Zeit läßt (eine Woche oder so).

(Im Prinzip sollte es auch möglich sein, einen Umstellungscode einzupflegen, der das gleich an allen Devices automatisiert gradezieht; dann muß "User" gar nix machen.)

Zitat von: CoolTux am 26 September 2018, 11:11:23
Das Problem das die Rolläden frühs nicht gefahren sind wenn der Roommate absent war habe ich nun gelöst. Funktioniert nun auch.
Sehr cool, hatte schon gezweifelt, ob es nicht doch irgendwas in meiner Konfiguration ist, das da schief hängt ;D .
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Prof. Dr. Peter Henning am 26 September 2018, 16:26:41
ZitatIm Prinzip sollte es auch möglich sein, einen Umstellungscode einzupflegen, der das gleich an allen Devices automatisiert gradezieht; dann muß "User" gar nix machen.
Seeehr gefährlich, an allen Devices etwas herumzufummeln.

Davon rate ich nachdrücklich ab.

LG

pah
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 26 September 2018, 16:51:32
Dass sowas nicht unkritisch ist, ist klar.

Hier geht es aber doch darum, dies im Rahmen eines Tests zu tun. Mit Usern, die entsprechende Risiken ggf. bewußt eingehen, hier mitlesen und (hoffentlich) wissen, wie sie Ihre Config sichern? Ggf. kann man das bewußte Auslösen noch Vorschalten?

Und die Auswirkungen sollten sich begrenzen lassen, indem man "das Attribut" (das überhaupt zur Unterstellung der Rolladendevices unter die Steuerung bewirkt) als oberstes Abgrenzungskriterium ranzieht.

Und zu guter Letzt: Die Attributnamen, nach denen zu suchen wäre, sind doch eher nicht verwechslungsanfällig...

Aber es ist Aufwand. U.a. deswegen stand der Zusatz auch in Klammern.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 27 September 2018, 10:54:32
Die letzten 2 Tage lief alles beim berechnen bei mir Super. Interessant wird noch das WE.
Ich habe nun auch die Attribute vom Modul entsprechend auf ASC vom Präfix her gekürzt.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: FunkOdyssey am 27 September 2018, 10:56:14
Kurz gefragt: Hast du schon eine Idee, in welcher Ausbaustufe du die Steuerung über Brightness/Lux integrieren willst?
(Nicht schlagen)
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 27 September 2018, 11:07:29
Zitat von: CoolTux am 27 September 2018, 10:54:32
Die letzten 2 Tage lief alles beim berechnen bei mir Super. Interessant wird noch das WE.
Ich habe nun auch die Attribute vom Modul entsprechend auf ASC vom Präfix her gekürzt.
Läßt du uns teilhaben? Auf github war jedenfalls eben noch kein update verfügbar ;) .
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 27 September 2018, 12:16:07
Zitat von: FunkOdyssey am 27 September 2018, 10:56:14
(Nicht schlagen)
;D


Das denke ich wird erst mit der Beschattung kommen und da haben wir ja in unseren Breitengraden gerade etwas Luft.


Grüße
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 27 September 2018, 12:20:14
Zitat von: Beta-User am 27 September 2018, 11:07:29
Läßt du uns teilhaben? Auf github war jedenfalls eben noch kein update verfügbar ;) .

Ich habe es eben hochgeladen. Version 0.1.60

ACHTUNG - Meine persönliche Empfehlung, altes AutoShuttersControl Device löschen vor dem Update.
Dann Update und neu anlegen. Es haben sich alle Attribute vom Namen her geändert. Änderung im Präfix


Was wurde noch geändert.
die Defaultwerte von Zeiten wurden auf HH:MM gekürzt.



Grüße
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 28 September 2018, 07:16:55
So, 0.1.6 läuft, Rolläden in den beiden "abwesenden" Räumen sind auch ordnungsgemäß gefahren :) .

Aufgefallen ist mir auf die Schnelle:
- Die (timer-) Readings an den Rolläden haben noch die Langfassung des Präfix, sollte m.E. durchgängig "ASC_.*" sein.
- Die default-Werte für ASC_Time_Up_Early (04:30 Uhr) und ASC_Time_Down_Early (15:30) finde ich nach wie vor wenig praxisnah (wer es so früh mag, kann es immer noch ändern, es geht hier um die überwiegende Mehrzahl potentieller User, die vermutlich Außenpanzer und Nachbarn haben). Vorschlag wäre 06:30/19:30.

Noch die aktualisierte Fassung der RG's:
defmod rg_ASC_Rollaeden_Times readingsGroup <Gerät>,<Stand>,<Time_Up_Early>,<Time_Up_WE>,<Time_Up_Late>,<Time_Down_Early>,<Time_Down_Late>,<Mode_Down>,<Mode_Up> (Rolladen_.*|Jalousie_.*)..:level,?ASC_Time_Up_Early,?ASC_Time_Up_WE_Holiday,?ASC_Time_Up_Late,?ASC_Time_Down_Early,?ASC_Time_Down_Late,?ASC_Mode_Down,?ASC_Mode_Up
attr rg_ASC_Rollaeden_Times commands {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'}
defmod rg_ASC_Rollaeden_Level readingsGroup <Gerät>,<Closed_Pos>,<Open_Pos>,<Shading_Pos>,<Ventilate_Pos> (Rolladen_.*|Jalousie_.*)..:?ASC_Closed_Pos,?ASC_Open_Pos,?ASC_Shading_Pos,?ASC_Ventilate_Pos
attr rg_ASC_Rollaeden_Level commands { ASC_Closed_Pos => 'ASC_Closed_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100',\
ASC_Open_Pos => 'ASC_Open_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100',\
ASC_Shading_Pos => 'ASC_Shading_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100',\
ASC_Ventilate_Pos => 'ASC_Ventilate_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100'}


Sonst erst mal Daumen hoch und

DANKE!
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 28 September 2018, 08:29:30
Habe die Readings nun auch geändert, wollte ich eigentlich so lassen (reine Faulheit  ;D )
Mit den default Werten habe ich kein Problem kann ich gerne ändern.

Heute Morgen ist mir dann aufgefallen das meine Wochenendsteuerung noch nicht rund läuft. Sonst fahren meine Rolläden immer um 6:34 rum und um diese Zeit erfolgte auch die neuberechnung, dummerweise selber Tag 7:00, also 7 Uhr wäre richtig aber nicht selber Tag.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Cluni am 28 September 2018, 08:32:28
Zitat von: CoolTux am 28 September 2018, 08:29:30
...also 7 Uhr wäre richtig...

Uiuiui - du schläfst ja am Wochenende richtig bis in die Puppen.... Kommt dein Körper mit soviel mehr Schlaf denn zurecht?? ;D
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: pc1246 am 28 September 2018, 08:36:30
Zitat von: Cluni am 28 September 2018, 08:32:28
Uiuiui - du schläfst ja am Wochenende richtig bis in die Puppen.... Kommt dein Körper mit soviel mehr Schlaf denn zurecht?? ;D
Moin
Rollladen hoch neq aufstehen
Und ich meine zu wissen, dass CoolTux zumindest ein Kind hat, und die kennen kein Wochenende! Erst spaeter, dann nervt es auch, aber anders herum!
Gruss Christoph
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 28 September 2018, 08:44:05
Zitat von: Cluni am 28 September 2018, 08:32:28
Uiuiui - du schläfst ja am Wochenende richtig bis in die Puppen.... Kommt dein Körper mit soviel mehr Schlaf denn zurecht?? ;D

Jepp, das gönne ich mir volle Kanne. Lach. Aber pct1246 hat Recht. Rolladen hoch heißt bei mir nicht unbedingt aufstehen. Wobei ich da aber in der Tat schon auf bin. Aber meine Rolläden sind so leise die hört man nicht selbst wenn man die Tür im Schlafzimmer auf hat. Und im Schlafzimmer bleibt natürlich geschlossen.

Und ich habe sogar 3 Kinder. Ok die 16 jährige steht am WE gar nicht auf  ;D, meine 10 jährige schläft bis 10 Uhr wenn ihr Bruder sie nicht weckt. Bleibt noch der Kurze, mit seinen 4 Jahren schläft er am WE meist so bis kurz nach 7 Uhr und dann heißt es Feuerwehreinsatz mit 7 Feuerwehren und Sirene. Man kann ihn nur lieb haben  ;D
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Cluni am 28 September 2018, 08:46:25
Ach ja - das kenne ich auch noch. Habe zwar nur eine die jetzt 10 ist, aber dafür haben wir ja jetzt einen Welpen - der kommt einem morgens ganz lieb die Füße lecken. Dann ist auch nicht mehr an schlafen zu denken... :D
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 28 September 2018, 08:50:27
Ich denke ich habe den Fehler gefunden bezüglich der WE Berechnung. Werde gleich mal Version 0.1.61 hoch laden.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Deckoffizier am 28 September 2018, 08:51:40
Hallo,

bin noch am Suchen mein Uniroll Testrollladen hat heute morgen leider nicht mitgespielt.
Mein Siro Rollladen aber ja.

Kurze Frage ist das attr. für ASC_Pos_Cmd noch frei wählbar wie bisher ? Also hatte für Uniroll pos eingesetzt.

Gruß
Hans-Jürgen
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 28 September 2018, 09:02:45
Zitat von: Deckoffizier am 28 September 2018, 08:51:40
Hallo,

bin noch am Suchen mein Uniroll Testrollladen hat heute morgen leider nicht mitgespielt.
Mein Siro Rollladen aber ja.

Kurze Frage ist das attr. für ASC_Pos_Cmd noch frei wählbar wie bisher ? Also hatte für Uniroll pos eingesetzt.

Gruß
Hans-Jürgen

Hallo Jürgen,

Ja klar, ist alles so geblieben wie bisher. Einzig der Präfix im Namen hat sich geändert. Also nur Kosmetik.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 29 September 2018, 08:07:11
Guten Morgen,

Kurze Info. Ich bin aktuell dabei den kompletten Code für das erkennen von Devices von denen wir Events verarbeiten wollen neu zu schreiben. Warum?
Nun jemand kam auf die Idee man könnte ja 2 Roommates in das Roommate Attribut eintragen  ;D
Für das verarbeiten und erkennen der Priorität des Status beider Roommates habe ich eine super tolle Lösung gefunden. Leider war das nicht mehr kompatibel zu meiner Lösung zum erkennen von Devices von denen wir Events verarbeiten.
Also noch mal zurück auf Anfang. Ich habe für 2 von 3 Anforderungen eine Lösung. Um das dritte mache ich mir später Gedanken  :)


Grüße
Leon
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 29 September 2018, 14:40:34
Fertig. Und ich muss sagen es ist geiler geworden wie ich gedacht hätte  ;D  ;D
Der Code ist nun viel flexibler. Ich teste diese Version übers Wochenende und wenn alles ok ist gebe ich sie Montag frei.


Grüße
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 29 September 2018, 15:21:19
Klingt ja vielversprechend...

Hast du zufällig auf Device:Reading umgebaut?

Noch was zur aktuellen Version und den Defaults: nach meinem persönlichen Geschmack sollte man die WE-Automatik auch in der Regel anschalten (also im define schauen, ob das Reading existiert, wenn nein auf "on" setzen).

Ansonsten war alles vom Verhalten her wie erwartet.
Ausnahme (aber nicht tragisch): An mind. einem Device habe ich trotz Löschen (mit "Delete" in FHEMWEB) noch ein paar von den alten userattr drin stehen, kann aber nicht sagen, woher das kommt.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Papaloewe am 29 September 2018, 16:37:15
Zitat von: Beta-User am 29 September 2018, 15:21:19
An mind. einem Device habe ich trotz Löschen (mit "Delete" in FHEMWEB) noch ein paar von den alten userattr drin stehen, kann aber nicht sagen, woher das kommt.

Bei mir auch.
Wie bekomme ich das wieder sauber?

Danke & Gruß
Thomas
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 29 September 2018, 16:44:38
Zitat von: Papaloewe am 29 September 2018, 16:37:15
Bei mir auch.
Wie bekomme ich das wieder sauber?

Danke & Gruß
Thomas

Einfach rauslöschen aus userattr und dann wenn noch vorhanden auch die gelöschten als Attribut entfernen.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 29 September 2018, 16:55:15
Zitat von: Beta-User am 29 September 2018, 15:21:19
Klingt ja vielversprechend...

Hast du zufällig auf Device:Reading umgebaut?

Noch was zur aktuellen Version und den Defaults: nach meinem persönlichen Geschmack sollte man die WE-Automatik auch in der Regel anschalten (also im define schauen, ob das Reading existiert, wenn nein auf "on" setzen).

Ansonsten war alles vom Verhalten her wie erwartet.
Ausnahme (aber nicht tragisch): An mind. einem Device habe ich trotz Löschen (mit "Delete" in FHEMWEB) noch ein paar von den alten userattr drin stehen, kann aber nicht sagen, woher das kommt.

Der User sieht von den Änderungen nichts. Passiert alles unter der Haube. Aber der Code ist weniger geworden und wie ich finde übersichtlicher. So wollte ich es eigentlich von Anfang an machen. Mir fehlte nur ein gedanklicher Anfang. Manchmal braucht etwas halt länger.
Ich weiß das Dir das Thema Device:Reading am Herzen liegt, aber ich werde dies nicht machen. Es ist so schon sehr schwierig gewesen Zuordnungen hin zu bekommen zum NOTIFYDEV und in welchen Zusammenhang dieses Device eigentlich zum Modul steht. Wenn ich da jetzt noch ne Trennung für Reading einbauen werde ich Probleme bekommen.
Um es mal anschaulich zu machen.
Im Internal NOTIFYDEV des Moduldevice stehen alle Devices drin auf dessen Event unser Modul triggern soll. Wir bekommen also einen Devicenamen und den Event. Doch im welchen Zusammenhang steht der Devicenamen zu unseren Rolläden. Das wissen wir nicht. Ist es ein Fensterkontakt oder ein Bewohner? Keine Ahnung. Also muss ich eine Interne Struktur für die Zuordnung schaffen, welche nach einem Reboot nicht nur erhalten bleibt sondern auch wieder sauber unser NOTIFYDEV befüllt ohne beim Start alle Rolläden und alle Attribute dessen Wert für unser NOTIFYDEV nötig ist durch zu gehen. Gerade beim oder nach einem Systemstart wäre das zu viel unnötige Last.


Grüße
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 30 September 2018, 07:08:58
Guten Morgen,

Bei mir hat nun die Berechnung zu Sonnenaufgang und Untergang mit einbeziehen von Wochenende und nicht Wochenende super geklappt.


Grüße
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 30 September 2018, 08:58:11
Zitat von: CoolTux am 30 September 2018, 07:08:58
Bei mir hat nun die Berechnung zu Sonnenaufgang und Untergang mit einbeziehen von Wochenende und nicht Wochenende super geklappt.
Auch hier keine Probleme, bin mal auf Mittwoch gespannt :) .
Zitat von: CoolTux am 29 September 2018, 16:55:15... muss ich eine Interne Struktur für die Zuordnung schaffen, welche nach einem Reboot nicht nur erhalten bleibt sondern auch wieder sauber unser NOTIFYDEV befüllt ohne beim Start alle Rolläden und alle Attribute dessen Wert für unser NOTIFYDEV nötig ist durch zu gehen. Gerade beim oder nach einem Systemstart wäre das zu viel unnötige Last.
Ist ja gut, du bist der Modulautor und darfst entscheiden, wie es gemacht wird.

Nur finde ich diese Argumentation nicht wirklich überzeugend. Denn ob du die erforderlichen Infos (z.B. zum Temperatur-Reading) jetzt aus zwei Attributen holst oder nur aus einem und ein split drüber jagst, dürfte von der Systemlast her gedacht kaum einen Unterschied machen, eher im Gegenteil.
Und spätestens bei mehreren Roommates stelle ich mir das unübersichtlich vor, wenn du die Device- und Reading-Angabe auf zwei Attribute verteilst. Ist aber nur meine Meinung :) ...
Schönes WE allseits jedenfalls noch.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 30 September 2018, 09:35:49
Zitat von: Beta-User am 30 September 2018, 08:58:11
Auch hier keine Probleme, bin mal auf Mittwoch gespannt :) .
Ist ja gut, du bist der Modulautor und darfst entscheiden, wie es gemacht wird.

Nur finde ich diese Argumentation nicht wirklich überzeugend. Denn ob du die erforderlichen Infos (z.B. zum Temperatur-Reading) jetzt aus zwei Attributen holst oder nur aus einem und ein split drüber jagst, dürfte von der Systemlast her gedacht kaum einen Unterschied machen, eher im Gegenteil.
Und spätestens bei mehreren Roommates stelle ich mir das unübersichtlich vor, wenn du die Device- und Reading-Angabe auf zwei Attribute verteilst. Ist aber nur meine Meinung :) ...
Schönes WE allseits jedenfalls noch.

Das freut mich das es auch bei Dir gut geklappt hat. Bin zuversichtlich was Mittwoch an geht  :D

Beim Thema Device:Reading darf man mir gerne einen Patch anbieten. Ich hoffe sehr das die Struktur nun so bleibt und ich nichts mehr im groben ändern muss. Somit steht es jedem frei mit der morgen hochgeladenen Version eine Möglichkeit an zu bieten.



Grüße
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: C0mmanda am 30 September 2018, 11:28:22
Moin,

gibt es eine Möglichkeit Rolläden zu "synchronisieren" bzw was muss ich einstellen damit dem so ist?
Hintergrund: Im Wohn-Esszimmer habe ich insgesamt 3 Rolläden welche zeitgleich hoch- und herunterfahren sollten. (Beschattung später ausgenommen).

Gibt es da eine Möglichkeit?
Danke für die Info und für die großartige Arbeit :)

Gruß
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 30 September 2018, 11:42:24
Die Verzögerungsattribute auf 0 stellen, Default ist 1
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 30 September 2018, 22:43:55
Ich habe soeben eine Fehlerbereinigte Version ins Git geschoben. Nun sollte auch der Status der Roommates korrekt erkannt werden wenn es mehr wie einer ist.

Gaaanz wichtig bei dieser neuen Version. Leider muss noch mal Hand an die Attribute der Rolläden angelegt werden.

Als erstes vor dem einspielen der neuen Version bitte folgendes Reading löschen

deletereading  ASControl .monitoredDevs


Bitte nicht den Punkt vor monitoredDevs vergessen.
Danach neue Version einspielen und neustarten von FHEM.
Als letztes müssen noch mal alle Rolläden angefasst werden. Einfach bei den Rolläden auf das Attribut ASC_WindowRec klicken und dann auf attr klicken damit attr Rolladen ASC_WindowRec ausgeführt wird.
Das selbe macht Ihr bei den Roommates, ändert aber bei den Rolläden wo mehr wie 1 Roommate beteiligt ist das Attribut vom structur Device zu roommate1,roommate2 und so weiter.




Grüße
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 01 Oktober 2018, 08:51:43
Und bitte nicht vergessen zu berichten. Commandref ziehe ich heute noch nach.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: FunkOdyssey am 01 Oktober 2018, 09:10:38
Ich habe bei mir nirgends das versteckte Reading .monitoredDevs.
Das LIST zeigt mir nichts an. Und aufs deletereading kommt nicht die erwartete Antwort. Demnach gehe ich davon aus, dass bei mir das Reading nicht existiert.


Ich habe bisher weder Roommate nocht Fenstergriffkontakt mit ASC genutzt. Das dürfte der Grund sein, oder?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 01 Oktober 2018, 09:35:38
Zitat von: FunkOdyssey am 01 Oktober 2018, 09:10:38
Ich habe bei mir nirgends das versteckte Reading .monitoredDevs.
Das LIST zeigt mir nichts an. Und aufs deletereading kommt nicht die erwartete Antwort. Demnach gehe ich davon aus, dass bei mir das Reading nicht existiert.


Ich habe bisher weder Roommate nocht Fenstergriffkontakt mit ASC genutzt. Das dürfte der Grund sein, oder?

Jepp das ist der Grund. Das Reading ist einzig und allein für die Rückgewinnung des Internals NOTIFYDEV.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 01 Oktober 2018, 10:25:31
Moin,

neue Version ist eingespielt, mal schauen, wie sich das verhält.

Ob der Punkt als Trenner eine gute Wahl ist? Es soll Leute geben, die den Punkt im Devicenamen verwenden. Leerzeichen, Komma oder ein | wäre diesbezüglich evtl. besser.

Das mit dem Neuaufbauen des Notifydev ist lästig. Sollte man da nicht eine Option einbauen, um das automatisiert zu machen? (Dann könnte man auch Leichen leichter beseitigen, ich hatte mich bei zweien vertippt, die sind jetzt noch in der Liste drin, bringen aber natürlich nichts...

Zitat von: CoolTux am 30 September 2018, 09:35:49
Beim Thema Device:Reading darf man mir gerne einen Patch anbieten.
Wenn ich dazu komme, mach' ich das ggf. gerne (auch zum Neubauen des Notifydev), aber nur, wenn das allg. als erwünscht angesehen wird.



Und noch eine Feature-Request:
Ein Wind-Device für das Zentrale ASC-Device und die Option, an den einzelnen Rollläden einen Grenzwert zu definieren, ab dem die Rolläden zwangsweise hoch sollen (und dann da auch bleiben). Wäre für Leute ggf. wichtig, die wie ich (u.a.) Außenjalousien haben.

Gruß, Beta-User
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 01 Oktober 2018, 10:30:36
Zitat von: Beta-User am 01 Oktober 2018, 10:25:31
Moin,

neue Version ist eingespielt, mal schauen, wie sich das verhält.

Ob der Punkt als Trenner eine gute Wahl ist? Es soll Leute geben, die den Punkt im Devicenamen verwenden. Leerzeichen, Komma oder ein | wäre diesbezüglich evtl. besser.

Das mit dem Neuaufbauen des Notifydev ist lästig. Sollte man da nicht eine Option einbauen, um das automatisiert zu machen? (Dann könnte man auch Leichen leichter beseitigen, ich hatte mich bei zweien vertippt, die sind jetzt noch in der Liste drin, bringen aber natürlich nichts...
Wenn ich dazu komme, mach' ich das ggf. gerne (auch zum Neubauen des Notifydev), aber nur, wenn das allg. als erwünscht angesehen wird.



Und noch eine Feature-Request:
Ein Wind-Device für das Zentrale ASC-Device und die Option, an den einzelnen Rollläden einen Grenzwert zu definieren, ab dem die Rolläden zwangsweise hoch sollen (und dann da auch bleiben). Wäre für Leute ggf. wichtig, die wie ich (u.a.) Außenjalousien haben.

Gruß, Beta-User

Welchen Punkt als Trenner meinst Du, also wo?
Ich werde auf jeden Fall noch eine set Funktion bauen für das Thema NOTIFYDEV und monitoredDevs.

Das mit dem Winddevice finde ich sehr gut. Werde ich auf alle Fälle mit einbauen. Wenn unser jetziger IST Stand soweit rund läuft fange ich an wieder neue Features zu implementieren.


Grüße
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 01 Oktober 2018, 10:39:43
Zitat von: CoolTux am 30 September 2018, 22:43:55
Das selbe macht Ihr bei den Roommates, ändert aber bei den Rolläden wo mehr wie 1 Roommate beteiligt ist das Attribut vom structur Device zu roommate1.roommate2
Da stand in der Version von heute Morgen erst noch ein Komma zwischen roommate1 und roommate2 ;) . Ist evtl. auch nur ein Typo.

Zitat von: CoolTux am 01 Oktober 2018, 10:30:36
Das mit dem Winddevice finde ich sehr gut. Werde ich auf alle Fälle mit einbauen. Wenn unser jetziger IST Stand soweit rund läuft fange ich an wieder neue Features zu implementieren.
Klingt gut! Danke vorab und wie immer: keine Eile!
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 01 Oktober 2018, 10:51:42
Zitat von: Beta-User am 01 Oktober 2018, 10:39:43
Da stand in der Version von heute Morgen erst noch ein Komma zwischen roommate1 und roommate2 ;) . Ist evtl. auch nur ein Typo.
Klingt gut! Danke vorab und wie immer: keine Eile!

Das war/ist in der Tat ein Typo.
Ich korrigiere es gleich mal.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Deckoffizier am 01 Oktober 2018, 13:41:45
Hallo,

habe mich gestern Abend und heute Morgen doppelt gemoppelt  am update versucht .

ZitatIch habe bei mir nirgends das versteckte Reading .monitoredDevs.
Das LIST zeigt mir nichts an. Und aufs deletereading kommt nicht die erwartete Antwort. Demnach gehe ich davon aus, dass bei mir das Reading nicht existiert.

Bei mir ebenso....

Ein Roommate ist,war  bei mir angelegt.
Warte erst mal ab.

Gruß
Hans-Jürgen

Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Deckoffizier am 01 Oktober 2018, 13:58:36
Hallo Beta-User,

ZitatDas mit dem Neuaufbauen des Notifydev ist lästig. Sollte man da nicht eine Option einbauen, um das automatisiert zu machen? (Dann könnte man auch Leichen leichter beseitigen, ich hatte mich bei zweien vertippt, die sind jetzt noch in der Liste drin, bringen aber natürlich nichts...

Ist mir leider ebenso passiert.
Gibt es da einen Kniff es wieder gerade zu biegen oder erst mal abwarten ob CoolTux so gut ist mit einer Idee ?

Gruß
Hans-Jürgen
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 01 Oktober 2018, 14:33:55
Zitat von: Deckoffizier am 01 Oktober 2018, 13:58:36
Hallo Beta-User,

Ist mir leider ebenso passiert.
Gibt es da einen Kniff es wieder gerade zu biegen oder erst mal abwarten ob CoolTux so gut ist mit einer Idee ?

Gruß
Hans-Jürgen

Der Kniff wäre das Reading .monitoredDevs zu löschen und dann einen neustart zu machen. Danach einfach in jeden Rolladendevice reingehen und die Attribute einfach noch mal setzen durch klick auf das Attribut und dann klick auf attr


Aber ich bin gerade dabei etwas zu programmieren damit man das NOTIFYDEV neu aufbauen lassen kann.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Deckoffizier am 01 Oktober 2018, 20:53:02
Hallo CoolTux,

ZitatDer Kniff wäre das Reading .monitoredDevs zu löschen und dann einen neustart zu machen. Danach einfach in jeden Rolladendevice reingehen und die Attribute einfach noch mal setzen durch klick auf das Attribut und dann klick auf attr

Hat diesmal funktioniert.

DANKE !

Gruß
Hans-Jürgen
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Karflyer am 02 Oktober 2018, 13:26:20
Hallo CoolTux,

bei den Rollläden von SOMFY ist der Positionswert für geschlossen 200. Bei Position 100 hat der Rolladen unten (Fensterbank) aufgesetzt, aber die Lamellen sind noch nicht 'lichtdicht' zugefahren. Nach der beschriebenen Position 100 kommt die Postion 200 (ohne weitere Zwischenpositionen). Erst dann ist der Rolladen komplett zu. Wäre es möglich den Wert 200 als Auswahl für die Endposition zu implementieren?

Grüße
Stefan
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 02 Oktober 2018, 13:39:27
Hallo Karflyer,
willkommen bei den Testern hier.
Der Wert sollte sich bereits heute schon "händisch" einstellen lassen, nur nicht über die Auswahlliste im Device selbst (bei Bedarf kannst du auch die ReadingsGroup anpassen, dann geht es auch web-basiert).
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 02 Oktober 2018, 13:49:10
Zitat von: Karflyer am 02 Oktober 2018, 13:26:20
Hallo CoolTux,

bei den Rollläden von SOMFY ist der Positionswert für geschlossen 200. Bei Position 100 hat der Rolladen unten (Fensterbank) aufgesetzt, aber die Lamellen sind noch nicht 'lichtdicht' zugefahren. Nach der beschriebenen Position 100 kommt die Postion 200 (ohne weitere Zwischenpositionen). Erst dann ist der Rolladen komplett zu. Wäre es möglich den Wert 200 als Auswahl für die Endposition zu implementieren?

Grüße
Stefan

Beta-User hat Recht. Du kannst einfach in der FHEMWEB Kommandozeile folgendes eingeben.

attr ROLLADENNAME ASC_Closed_Pos 200


Dann steht in dem Attribut die 200 drin und er wird entsprechend fahren.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Cluni am 02 Oktober 2018, 13:58:04
Passen denn dann die Prozentwerte noch? Ich denke er hat von 0 bis 100% und nur die 200 dreht dann die Jalousien nochmal?!
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 02 Oktober 2018, 14:03:12
Wird denn irgendwo gerechnet?

So wie ich das verstanden habe, wird eigentlich überall "nur" ein fester Wert eingestellt (für offen, zu, Beschattung, Lüften) und der dann jeweils angefahren. Sollte also kein Problem sein. Oder übersehe ich was?

Gruß, Beta-User
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Cluni am 02 Oktober 2018, 14:04:57
@CoolTux: Ich wusste nicht, ob du eine Umrechnung mit dem Endwert machst und dann immer auf 0..100 skalierst...
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 02 Oktober 2018, 14:10:31
Zitat von: Cluni am 02 Oktober 2018, 14:04:57
@CoolTux: Ich wusste nicht, ob du eine Umrechnung mit dem Endwert machst und dann immer auf 0..100 skalierst...

Nee mache ich nicht. Die User geben einfach Ihre Werte von Hand ein. Müssen dann halt bei solchen Exoten etwas überlegen. So wird dann zum Beispiel 70% nicht die geeignete Lüftung sein, sondern 50 oder so. Wobei 200 bei den Kollegen ja die Lammellen sind. Wenn er also 150 für Lüften nimmt sind die Rollos komplett unten aber die Lamellen zur Hälfte noch geöffnet.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 04 Oktober 2018, 09:31:46
Bei mir lief alles so wie erwartet. Was haben die anderen zu berichten?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 04 Oktober 2018, 10:11:37
Würde mal darauf tippen, dass Rückmeldungen bislang deswegen ausgeblieben sind, weil nichts weiter zu berichten war ;) ...

Hier war jedenfalls alles erwartungsgemäß. Sowohl der Feiertag hat funktioniert wie auch der Wechsel zum normalen Werktag.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 04 Oktober 2018, 10:12:15
Sehr schön. Dann kann man ja weiter machen.  ;D
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: HoTi am 04 Oktober 2018, 11:36:54
@CoolTux,

wann meinst du denn kann ich den Schritt von Clunis Code zu eurem Modul wagen? Dann kann ich auch mal noch Funktionen für euch testen.

Ich habe derzeit 8x das Rollomodul im Einsatz.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Cluni am 04 Oktober 2018, 11:38:44
Heeeeeyyyyyy - gar nicht! Du willst doch nicht abtrönig werden, oder???? 🤪🤪🤪🤪


Gesendet von iPhone mit Tapatalk
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: HoTi am 04 Oktober 2018, 11:42:42
Cluni, du weißt dein Code funktioniert bei mir fabelhaft!! Aber irgendwann wird euer Modul den Code ablösen ;-)
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 04 Oktober 2018, 12:40:35
Das kann und möchte ich so pauschal nicht sagen. Die API an sich dürfte nun stabil sein. Bitte lese Dir genau durch was derzeit abgedeckt wird an Funktionen und entscheide ob es für Deine Belange ausreichend ist.



Grüße
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Karflyer am 05 Oktober 2018, 18:10:05
Ich habe folgendes (Fehl)Verhalten beobachtet. Ich habe mehrere Fenster, die über Drehgriffe mit drei (vier) Stati geöffnet werden. Griffe sind von Hoppe die über enocean angeschaltet sind. Es gibt vier Stati closed, open, tilted und open-from-tilted. Der vierte Stati open-from-tilted ist über eventMap auf open gemappt.
Ist die Comfort-Funktion eingeschaltet (ASC_AutoShuttersControlComfort) und am entsprechenden Rolladen threestate (ASC_WindowRec_subType) eingetragen ist folgendes Verhalten zu beobachten:
Drehgriff ist 'closed', Rolladen ist komplett geöffnet
Drehgriff geht in 'open' oder über 'open' in 'tilted' -> Rolladen fährt in Comfort-Position (ASC_Pos_after_ComfortOpen)-> Ist das so gewollt?
Drehgriff geht von open oder von 'tilted' über 'open' in 'closed' -> Rolladen wird komplett geschlossen -> Das, würde ich sagen, ist devinitiv falsch. Hier müsste doch die letzte Postion vor dem Öffnen angefahren werden. Oder sehe ich das falsch?

Grüße
Stefan
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 05 Oktober 2018, 18:27:08
Hallo Stefan,

Wenn der Rolladen geöffnet ist sollte beim öffnen des Fensters gar nichts passieren, nur wenn es geschlossen ist.
Kannst Du bitte ein List des Rolladens hier poste.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Karflyer am 05 Oktober 2018, 18:51:04
Hier das Listing eines ensprechenden Rolladen.

Internals:
   ADDRESS    000001
   CFGFN      /opt/fhem/FHEM/somfydevices.cfg
   DEF        000001 A0 01C0
   IODev      CUL_SOMFY
   NAME       sht_ezr
   NR         153
   STATE      open
   TYPE       SOMFY
   move       stop
   CODE:
     1          000001
   OLDREADINGS:
   READINGS:
     2018-10-05 08:43:27   ASC_Time_DriveDown  5.10.2018 - 19:30
     2018-10-05 08:43:27   ASC_Time_DriveUp  6.10.2018 - 08:00
     2018-10-05 18:11:58   enc_key         A0
     2018-10-05 18:12:18   exact           0
     2018-10-05 18:12:18   position        0
     2018-10-05 18:11:58   rolling_code    01C0
     2018-10-05 18:12:18   state           open
Attributes:
   ASC        1
   ASC_Antifreeze off
   ASC_AutoAstroModeEvening none
   ASC_AutoAstroModeEveningHorizon none
   ASC_AutoAstroModeMorning none
   ASC_AutoAstroModeMorningHorizon none
   ASC_Closed_Pos 200
   ASC_Direction 178
   ASC_Down   astro
   ASC_GuestRoom none
   ASC_Mode_Down always
   ASC_Mode_Up always
   ASC_Offset_Minutes_Evening 1
   ASC_Offset_Minutes_Morning 1
   ASC_Open_Pos 0
   ASC_Partymode off
   ASC_Pos_Cmd position
   ASC_Pos_after_ComfortOpen 20
   ASC_Rand_Minutes 20
   ASC_Roommate_Device none
   ASC_Roommate_Reading state
   ASC_Shading off
   ASC_Shading_Angle_Left 85
   ASC_Shading_Angle_Right 85
   ASC_Shading_BlockingTime_After_Manual 20
   ASC_Shading_BlockingTime_Twilight 45
   ASC_Shading_Brightness_Reading brightness
   ASC_Shading_Brightness_Sensor none
   ASC_Shading_Fast_Close none
   ASC_Shading_Fast_Open none
   ASC_Shading_Min_Elevation none
   ASC_Shading_Min_OutsideTemperature 18
   ASC_Shading_Pos 50
   ASC_Shading_Pos_after_Shading -1
   ASC_Shading_StateChange_Cloudy 4000
   ASC_Shading_StateChange_Sunny 6000
   ASC_Shading_WaitingPeriod 20
   ASC_Time_Down_Early 16:00
   ASC_Time_Down_Late 22:30
   ASC_Time_Up_Early 06:00
   ASC_Time_Up_Late 09:00
   ASC_Time_Up_WE_Holiday 08:00
   ASC_Up     astro
   ASC_Ventilate_Pos 70
   ASC_Ventilate_Window_Open on
   ASC_WindowRec sc_ezr
   ASC_WindowRec_subType threestate
   ASC_lock-out soft
   ASC_lock-outCmd none
   IODev      CUL_SOMFY
   alias      Esszimmer (r)
   devStateIcon open|10:fts_shutter_10 20:fts_shutter_20 30:fts_shutter_30 40:fts_shutter_40 50:fts_shutter_50 60:fts_shutter_60 70:fts_shutter_70 80:fts_shutter_80 90:fts_shutter_90 100|down|closed:fts_shutter_100
   drive-down-time-to-100 16
   drive-down-time-to-close 19
   drive-up-time-to-100 3
   drive-up-time-to-open 20
   eventMap   /on:down/off:up/pos 60:go-my/
   group      SOMFY
   model      somfyshutter
   room       SOMFY
   sortby     01
   userattr   ASC_Antifreeze:off,on ASC_AutoAstroModeEvening:REAL,CIVIL,NAUTIC,ASTRONOMIC,HORIZON ASC_AutoAstroModeEveningHorizon:-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9 ASC_AutoAstroModeMorning:REAL,CIVIL,NAUTIC,ASTRONOMIC,HORIZON ASC_AutoAstroModeMorningHorizon:-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9 ASC_Closed_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_Direction ASC_Down:time,astro ASC_GuestRoom:on,off ASC_Mode_Down:absent,always,off ASC_Mode_Up:absent,always,off ASC_Offset_Minutes_Evening ASC_Offset_Minutes_Morning ASC_Open_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_Partymode:on,off ASC_Pos_Cmd ASC_Pos_after_ComfortOpen:0,10,20,30,40,50,60,70,80,90,100 ASC_Rand_Minutes ASC_Roommate_Device ASC_Roommate_Reading ASC_Shading:on,off,delayed,present,absent ASC_Shading_Angle_Left:0,5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90 ASC_Shading_Angle_Right:0,5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90 ASC_Shading_BlockingTime_After_Manual ASC_Shading_BlockingTime_Twilight ASC_Shading_Brightness_Reading ASC_Shading_Brightness_Sensor ASC_Shading_Fast_Close:on,off ASC_Shading_Fast_Open:on,off ASC_Shading_Min_Elevation ASC_Shading_Min_OutsideTemperature ASC_Shading_Pos:10,20,30,40,50,60,70,80,90,100 ASC_Shading_Pos_after_Shading:-1,0,10,20,30,40,50,60,70,80,90,100 ASC_Shading_StateChange_Cloudy ASC_Shading_StateChange_Sunny ASC_Shading_WaitingPeriod ASC_Time_Down_Early ASC_Time_Down_Late ASC_Time_Up_Early ASC_Time_Up_Late ASC_Time_Up_WE_Holiday ASC_Up:time,astro ASC_Ventilate_Pos:10,20,30,40,50,60,70,80,90,100 ASC_Ventilate_Window_Open:on,off ASC_WindowRec ASC_WindowRec_subType:twostate,threestate ASC_lock-out:soft,hard ASC_lock-outCmd:inhibit,blocked
   webCmd     down:stop:up:go-my
   widgetOverride position:slider,0,10,100


Stefan
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 05 Oktober 2018, 18:57:44
Danke Dir Stefan, schaue ich mir an.


Grüße
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 06 Oktober 2018, 21:07:02
Zitat von: Karflyer am 05 Oktober 2018, 18:10:05
Ich habe folgendes (Fehl)Verhalten beobachtet. Ich habe mehrere Fenster, die über Drehgriffe mit drei (vier) Stati geöffnet werden. Griffe sind von Hoppe die über enocean angeschaltet sind. Es gibt vier Stati closed, open, tilted und open-from-tilted. Der vierte Stati open-from-tilted ist über eventMap auf open gemappt.
Ist die Comfort-Funktion eingeschaltet (ASC_AutoShuttersControlComfort) und am entsprechenden Rolladen threestate (ASC_WindowRec_subType) eingetragen ist folgendes Verhalten zu beobachten:
Drehgriff ist 'closed', Rolladen ist komplett geöffnet
Drehgriff geht in 'open' oder über 'open' in 'tilted' -> Rolladen fährt in Comfort-Position (ASC_Pos_after_ComfortOpen)-> Ist das so gewollt?
Drehgriff geht von open oder von 'tilted' über 'open' in 'closed' -> Rolladen wird komplett geschlossen -> Das, würde ich sagen, ist devinitiv falsch. Hier müsste doch die letzte Postion vor dem Öffnen angefahren werden. Oder sehe ich das falsch?

Grüße
Stefan

Ich denke das ich es gefixt habe. Wird in einer neuen Version am Sonntag Abend oder Montag früh kommen.
Desweiteren habe ich eine set Funktion für das neu erstellen der NOTIFYDEV gemacht und eine get Funktion um zu testen ob alle Devices auf dessen Events wir reagieren wollen korrekt erkannt wurden.



Grüße
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 08 Oktober 2018, 04:03:30
Neue Version ist nun im Git. Ich denke damit gewinnt unser Modul mehr und mehr an Stabilität. Als nächstes können wir dann neue Funktionen hinzufügen.

Da ich mich selbst auch weiter entwickeln möchte was das programmieren an geht, habe ich beschlossen nebenbei Code für Objektorientierte Programmierung in diesem Modul zu verwenden. Nur zur Info falls sich jemand den Code neben mit an schaut.


Grüße
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 08 Oktober 2018, 12:16:29
0.1.73 ist am Start :) .

Das neu Aufbauen des Notifydev hat gut funktioniert, die Leichen sind jetzt weg.

Das neue get für die überwachten Devices ist auch nett.
Dazu hätte ich einen Wunsch (mal wieder eher useability-getrieben bzw. dem Gedanken, das möglichst übersichtlich zu haben, also nicht wirklich eilig oder wichtig): Die Sortierung sollte m.E. nach Shutter-Device sein, im Moment geht das bunt durcheinander (k.A., nach welcher Logik). Also alle zu einem bestimmten Rollladen gehörende Angaben zu Roommate und WindowContact nacheinander, dann erst der nächste Rollladen; das ganze am besten als nächste Sortierebene nach Räumen.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 08 Oktober 2018, 12:55:18
Zitat von: Beta-User am 08 Oktober 2018, 12:16:29
0.1.73 ist am Start :) .

Das neu Aufbauen des Notifydev hat gut funktioniert, die Leichen sind jetzt weg.

Das neue get für die überwachten Devices ist auch nett.
Dazu hätte ich einen Wunsch (mal wieder eher useability-getrieben bzw. dem Gedanken, das möglichst übersichtlich zu haben, also nicht wirklich eilig oder wichtig): Die Sortierung sollte m.E. nach Shutter-Device sein, im Moment geht das bunt durcheinander (k.A., nach welcher Logik). Also alle zu einem bestimmten Rollladen gehörende Angaben zu Roommate und WindowContact nacheinander, dann erst der nächste Rollladen; das ganze am besten als nächste Sortierebene nach Räumen.

Kann ich mir gerne anschauen. Ist ja nur eine Sortierreinfolge. Weiß nur nicht in wie fern FHEMWEB da auch was macht. Müssen wir mal aus testen.
Aktuell schreibe ich das Modul komplett für OOP (Objektorientierte Programmierung in Perl) um. Ist natürlich bisschen Perl  ;D für die Säue mit nur einer Modul/Klassen Datei, aber mir geht es um das lernen.


Grüße
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 08 Oktober 2018, 13:06:55
Der Ansatz gefällt mir gut, eine Art "Muster"-Modul daraus zu machen, auch wenn es vermutlich "overdone" ist. Aber wen "copy/paste"-Hobbyisten wie ich schon Code irgendwo her klauen, ist es besser, es wird aus einer mustergültigen Quelle gemacht ;) .

Wenn du magst (du warst ja auf der Suche nach einem guten 2-stufigen): Schau doch mal bei MySensors vorbei. Das war mal kurz und knackig (und ist es im wesentlichen noch). Vielleicht kannst du uns ja Tips dazu geben... (Was man besser dokumentierne könnte ist das etwas unübersichtliche Durcheinander, was sich aus Abfrage von irgendwas und verzögerter Reaktion ergibt).

Wäre gut für den Fall, dass ich irgendwann mal zigbee@serial anfangen sollte ;) .
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: C0mmanda am 08 Oktober 2018, 17:22:59
Zitat von: CoolTux am 08 Oktober 2018, 04:03:30
Neue Version ist nun im Git. Ich denke damit gewinnt unser Modul mehr und mehr an Stabilität. Als nächstes können wir dann neue Funktionen hinzufügen.


Da hätte ich ja direkt eine Idee ;)
Abgesehen von den bereits angesprochenen Zwischenfahrten habe ich einen weiteren "Wunsch":

Ich hatte bisher immer ein DOIF/notify o.ä. welches kritische Fenster im EG "überwacht" und die Rolläden schliesst wenn
ein Fenster geöffnet ist, aber niemand mehr zuhause ist. (Also vergessen hat das Fenster zu schliessen).
Der Rolladen wird dann aus Sicherheitsgründen herunter gefahren.
Kommt nun ein Roommate nach Hause wird der Rolladen wieder in die vorherige Position zurück gefahren, es sei denn
das Nachtschliessen wäre bereits gewesen, dann bleibt der Rolladen natürlich auch geschlossen.

Wäre natürlich optimal wenn solch eine Funktion implementiert werden könnte. Roommates + Fensterkontakte werden ohnehin bereits abgefragt.

Komme darauf weil ich dies jetzt wieder implementieren wollte aber kein passendes Reading habe (Clunis myUtils-Code hatte z.B. "Nachtschliessen (0|1)" welches ich abfragen konnte).
Müsste wohl die Zeitstempel abfragen und vergleichen um heraus zu finden ob das Nachtschliessen schon gewesen wäre, wäre der Rolladen offen gewesen..

Nur eine Idee.  8)
Für die jetzt schon großartige Arbeit vielen vielen Dank!

gruß
CmdA
Titel: Antw:Betatester für ein neues Modul gesucht!
Beitrag von: CoolTux am 08 Oktober 2018, 17:33:58
Zitat von: C0mmanda am 08 Oktober 2018, 17:22:59
Da hätte ich ja direkt eine Idee ;)
Abgesehen von den bereits angesprochenen Zwischenfahrten habe ich einen weiteren "Wunsch":

Ich hatte bisher immer ein DOIF/notify o.ä. welches kritische Fenster im EG "überwacht" und die Rolläden schliesst wenn
ein Fenster geöffnet ist, aber niemand mehr zuhause ist. (Also vergessen hat das Fenster zu schliessen).
Der Rolladen wird dann aus Sicherheitsgründen herunter gefahren.
Kommt nun ein Roommate nach Hause wird der Rolladen wieder in die vorherige Position zurück gefahren, es sei denn
das Nachtschliessen wäre bereits gewesen, dann bleibt der Rolladen natürlich auch geschlossen.

Wäre natürlich optimal wenn solch eine Funktion implementiert werden könnte. Roommates + Fensterkontakte werden ohnehin bereits abgefragt.

Komme darauf weil ich dies jetzt wieder implementieren wollte aber kein passendes Reading habe (Clunis myUtils-Code hatte z.B. "Nachtschliessen (0|1)" welches ich abfragen konnte).
Müsste wohl die Zeitstempel abfragen und vergleichen um heraus zu finden ob das Nachtschliessen schon gewesen wäre, wäre der Rolladen offen gewesen..

Nur eine Idee.  8)
Für die jetzt schon großartige Arbeit vielen vielen Dank!

gruß
CmdA

Zitat von: CoolTux am 03 September 2018, 10:40:55
Von einem Smart Home Kollegen habe ich auch geade eine super tolle Logikidee bekommenIch finde das ist eine super tolle Idee.

Self Defence, wenn beim Verlassen des letzten Bewohners noch ein Fenster gekippt ist, wird der Rolladen an diesem Fenster automatisch geschlossen.


Kommt also
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: FunkOdyssey am 08 Oktober 2018, 17:35:12
Aber erst die Helligkeitssteuerung :-)
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 08 Oktober 2018, 18:21:51
Zitat von: Beta-User am 08 Oktober 2018, 13:06:55
Der Ansatz gefällt mir gut, eine Art "Muster"-Modul daraus zu machen, auch wenn es vermutlich "overdone" ist. Aber wen "copy/paste"-Hobbyisten wie ich schon Code irgendwo her klauen, ist es besser, es wird aus einer mustergültigen Quelle gemacht ;) .

Wenn du magst (du warst ja auf der Suche nach einem guten 2-stufigen): Schau doch mal bei MySensors vorbei. Das war mal kurz und knackig (und ist es im wesentlichen noch). Vielleicht kannst du uns ja Tips dazu geben... (Was man besser dokumentierne könnte ist das etwas unübersichtliche Durcheinander, was sich aus Abfrage von irgendwas und verzögerter Reaktion ergibt).

Wäre gut für den Fall, dass ich irgendwann mal zigbee@serial anfangen sollte ;) .

Kann mich gerade nicht erinnern auf der Suche nach einem 2-stufigen Modul gewesen zu sein :-)
Habe ja selber schon 2-3 gemacht. Da kann ich dann im Winter wenn ich bisschen das Developer Wiki erweitere ein paar Auszüge als Beispiel nehmen  ;D
Wenn Du auch gerne ein Modul erstellen willst kannst Du Dir auch einen Mentor suchen. Denke das kennst Du ja bestimmt, wurde schon paar mal im Forum erwähnt.  :)

Ein gutes Beispiel kann das Modul sein, zu mindest was die Verwendung von package an geht. OOP muss aber nicht sein.


Grüße
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 08 Oktober 2018, 18:34:32
Zitat von: CoolTux am 08 Oktober 2018, 18:21:51
Wenn Du auch gerne ein Modul erstellen willst kannst Du Dir auch einen Mentor suchen. Denke das kennst Du ja bestimmt, wurde schon paar mal im Forum erwähnt.  :)
Ist schon klar, ich will aber erst mal niemanden mit meinen rudimentären Perl-Kenntnissen behelligen, zumal ich auch erst mal noch HW (und viel ruhige Zeit) dafür benötige (ist im Zulauf). Welches "2-stufige" würdest du denn als mustergültig einschätzen? (Dass du da schon mehrere gemacht hast, ist mir bekannt, aber manchmal ist es so, dass man im Lauf der Zeit Dinge dazulernt und manches dann ganz anders machen würde, würde man nochmal "grüne Wiese" haben... Hätte mich im wesentlichen an MySensors orientiert, da ich das schon etwas in der Funktionsweise einschätzen kann und ansonsten vorrangig bei CUL+CUL_HM bedient, da es vermutlich viele Parallelen zwischen HM-BidCos und zigbee gibt).

Ich komme aber ggf. auf den Hinweis zurück, oder war das ein konkretes Angebot?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Karflyer am 08 Oktober 2018, 21:59:35
Habe die neue Version eingespielt. Das Verhalten bzgl. Comfort-Stellung und threestate-Fenstergriffen ist jetzt wie erwartet.
Das Modul ist wirklich klasse! Weiter so.

Stefan
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 09 Oktober 2018, 12:36:22
Zitat von: FunkOdyssey am 08 Oktober 2018, 17:35:12
Aber erst die Helligkeitssteuerung :-)

Was genau stellst Du Dir darunter vor?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 09 Oktober 2018, 12:37:11
Ich habe eine neue Version nun fertig. Komplett umgestellt auf OOP und mit selfDevense Mode
Ich teste die Tage noch und dann stelle ich sie online.


Grüße
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: FunkOdyssey am 09 Oktober 2018, 12:44:37
Zitat von: CoolTux am 09 Oktober 2018, 12:36:22
Was genau stellst Du Dir darunter vor?

Sind dafür nicht die Brightness-Attribute gedacht?

Ich will keinen Astro-Modus, weil die Helligkeitssensoren rund um mein Haus viel genauer sind.
Von diesem Werte lege ich einen Durchschnitt an und bei Unterschreitung des Wertes x fahren die Jalousien halt runter.

(Ehrlich gesagt fahren die Jalousien bei mir einmal auf 50% und dann auf 0% runter. Das hier bereits erwähnt Zweistufenverfahren, welches viel später kommen soll. :-) )
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Cluni am 09 Oktober 2018, 13:13:05
Zitat von: Beta-User am 08 Oktober 2018, 18:34:32
...(und viel ruhige Zeit) dafür benötige (ist im Zulauf). ...

Geilomat - wo bekommst du die ruhige Zeit denn her? Suche schon lange, aber habe bis jetzt noch keinen Händler gefunden. Würde da auch jede Menge von bestellen und abnehmen!  ;D
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 09 Oktober 2018, 13:25:07
Zitat von: FunkOdyssey am 09 Oktober 2018, 12:44:37
Sind dafür nicht die Brightness-Attribute gedacht?

Ich will keinen Astro-Modus, weil die Helligkeitssensoren rund um mein Haus viel genauer sind.
Von diesem Werte lege ich einen Durchschnitt an und bei Unterschreitung des Wertes x fahren die Jalousien halt runter.

(Ehrlich gesagt fahren die Jalousien bei mir einmal auf 50% und dann auf 0% runter. Das hier bereits erwähnt Zweistufenverfahren, welches viel später kommen soll. :-) )

Interessant. Die Helligkeitssensoren sind eigentlich für die Abschattung gedacht. Aber ich denke mal man kann Prinzip auch assoziieren.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: FunkOdyssey am 09 Oktober 2018, 13:53:26
Ich habe auch nie verstanden, wieso ich zweigleisig fahren sollte.
- Astro,
- fixe Uhrzeiten,
- und die Umgebungshelligkeit.

Fixe Uhrzeiten in Kombination mit der Umgebungshelligkeit oder mit den Astro-Zeiten macht ja noch Sinn. Aber Astro mit Helligkeit zu kombinieren halt nicht.

Die Astro-Zeiten (egal ob Modul ASTRO oder Twilight) sind mir halt nicht genau genug. Und wenn ich die Sensoren sowieso schon für die Abschattung benötige, so kann ich dieses auch zum Runterfahren nutzen.

Twilight habe ich nur zusätzlich in meinen DOIFs, um den Zeitrahmen grob vorzubelegen. Ich will halt nicht, dass die Jalousien herunterfahren wenn es mal tagsüber zu dunkel wird. Aber diese Extreme gab es nur ein bis zweimal im Jahr.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 09 Oktober 2018, 14:08:32
Auch wenn ich sehr positiv angetan bin von den Astro-Ergebnissen: Könnte man die Logik für eine helligkeitsbasierte Variante nicht ähnlich machen wie mit Astro?
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).

Vermutlich sollte man zwei Schwellenwerte definieren: einen Mindestwert für das Öffnen und einen für das Schließen (muß ja nicht zwangsläufig gleich sein).
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Cluni am 09 Oktober 2018, 14:13:35
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*
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 09 Oktober 2018, 14:18:27
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 ::) .
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Cluni am 09 Oktober 2018, 14:20:10
Nein, das kann man auch reihum bei jedem neuen Helligkeiwert machen. So läuft bei mir die Abschattung...


Gesendet von iPhone mit Tapatalk
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 09 Oktober 2018, 14:23:03
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.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Cluni am 09 Oktober 2018, 14:41:53
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...
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 09 Oktober 2018, 14:52:15
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.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 09 Oktober 2018, 15:02:28
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.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 09 Oktober 2018, 15:39:30
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.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 09 Oktober 2018, 15:56:25
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.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 10 Oktober 2018, 10:47:22
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
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: C0mmanda am 10 Oktober 2018, 19:46:44
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
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag 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.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: C0mmanda am 10 Oktober 2018, 22:38:02
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
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 11 Oktober 2018, 08:07:00
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.  :(
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 11 Oktober 2018, 08:23:16
Ich habe eben ein Fix hochgeladen. Version 0.1.78.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: C0mmanda am 11 Oktober 2018, 17:54:25
Was muss konfiguriert sein damit selfDefense funktioniert?

Im ASC-Device ist ASC_residentsDevice definiert.
In den Rolläden-Devices habe ich KEINE Roommates definiert.

Geht mein Residents-Device in absent passiert mit den Rolläden...nichts.

V0.1.7.8 ist installiert.
selfDefense auch aktiviert. (set selfDefense on)

Danke & Gruß
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 11 Oktober 2018, 18:18:50
Ich teste das noch mal. Fensterkontakt ist eingerichtet? Fenster war offen? Es schließt ja nur da wo Fenster offen sind.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: C0mmanda am 11 Oktober 2018, 19:00:20
Japp!
Fensterkontakt ist hinterlegt (ASC_WindowRec) und subType ist auch korrekt hinterlegt (twoState/threeState).
Kann auch ein list einstellen wenns hilft.

Gruß
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 11 Oktober 2018, 19:11:44
Zitat von: C0mmanda am 11 Oktober 2018, 19:00:20
Japp!
Fensterkontakt ist hinterlegt (ASC_WindowRec) und subType ist auch korrekt hinterlegt (twoState/threeState).
Kann auch ein list einstellen wenns hilft.

Gruß

Ja bitte.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: C0mmanda am 11 Oktober 2018, 19:18:09
Kann es sein das ich
,,set <ASC-device> createnewnotifydev"
Hätte machen müssen?
lists kann ich nach dem Abendbrot einstellen  8)

Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 11 Oktober 2018, 19:42:02
Zitat von: C0mmanda am 11 Oktober 2018, 19:18:09
Kann es sein das ich
,,set <ASC-device> createnewnotifydev"
Hätte machen müssen?
lists kann ich nach dem Abendbrot einstellen  8)

Nein. Der Residents sollte im Notifydev beim Attribut hinzufügen drin stehen.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: C0mmanda am 11 Oktober 2018, 20:00:36
OK :)
War nur eine Idee  ::)

List ASC-Device:
Internals:
   MID        da39a3ee5e6b4b0d3255bfef95601890afd80709
   NAME       Rolladensteuerung
   NOTIFYDEV  EG.ku.TK.FensterKU,OG.sz.TK.FensterSZ,Rolladensteuerung,global,rgr_Home,rr_Sascha
   NR         219
   NTFY_ORDER 50-Rolladensteuerung
   NotifyOrderPrefix 51-
   STATE      active
   TYPE       AutoShuttersControl
   VERSION    0.1.78
   OLDREADINGS:
   READINGS:
     2018-10-11 19:28:37   EG.ku.RO.KURolladen_lastPosValue 30
     2018-10-11 19:28:37   EG.ku.RO.KURolladen_nextAstroTimeEvent 12.10.2018 - 07:21
     2018-10-11 19:28:33   EG.sp.RO.SPRolladen_lastPosValue 100
     2018-10-11 19:28:33   EG.sp.RO.SPRolladen_nextAstroTimeEvent 12.10.2018 - 07:21
     2018-10-11 19:28:25   EG.wz.RO.WZRolladen.1_lastPosValue 100
     2018-10-11 19:28:25   EG.wz.RO.WZRolladen.1_nextAstroTimeEvent 12.10.2018 - 07:21
     2018-10-11 19:28:25   EG.wz.RO.WZRolladen.2_lastPosValue 100
     2018-10-11 19:28:25   EG.wz.RO.WZRolladen.2_nextAstroTimeEvent 12.10.2018 - 07:21
     2018-10-11 19:29:11   OG.az.RO.AZRolladen_lastPosValue 100
     2018-10-11 19:29:11   OG.az.RO.AZRolladen_nextAstroTimeEvent 12.10.2018 - 07:22
     2018-10-11 19:28:30   OG.gz.RO.GZRolladen_lastPosValue 90
     2018-10-11 19:28:30   OG.gz.RO.GZRolladen_nextAstroTimeEvent 12.10.2018 - 09:30
     2018-10-11 19:28:34   OG.sz.RO.SZRolladen_lastPosValue 30
     2018-10-11 19:28:34   OG.sz.RO.SZRolladen_nextAstroTimeEvent 12.10.2018 - 07:21
     2018-09-30 11:23:06   lockOut         off
     2018-09-30 11:15:58   partyMode       off
     2018-10-11 17:49:18   room_Homekit_Rolladen EG.ku.RO.KURolladen, EG.sp.RO.SPRolladen, EG.wz.RO.WZRolladen.1, EG.wz.RO.WZRolladen.2, OG.az.RO.AZRolladen, OG.gz.RO.GZRolladen, OG.sz.RO.SZRolladen
     2018-10-10 19:40:55   selfDefence     on
     2018-10-11 17:49:18   state           active
     2018-10-06 10:12:13   sunriseTimeWeHoliday on
     2018-10-11 17:49:18   userAttrList    rolled out
   helper:
     shuttersList:
       EG.ku.RO.KURolladen
       EG.sp.RO.SPRolladen
       EG.wz.RO.WZRolladen.1
       EG.wz.RO.WZRolladen.2
       OG.az.RO.AZRolladen
       OG.gz.RO.GZRolladen
       OG.sz.RO.SZRolladen
   monitoredDevs:
     EG.ku.TK.FensterKU:
       EG.ku.RO.KURolladen ASC_WindowRec
     OG.sz.TK.FensterSZ:
       OG.sz.RO.SZRolladen ASC_WindowRec
     rgr_Home:
       Rolladensteuerung ASC_residentsDevice
     rr_Sascha:
       OG.sz.RO.SZRolladen ASC_Roommate_Device
Attributes:
   ASC_antifreezeTemp 3
   ASC_autoAstroModeEvening HORIZON
   ASC_autoAstroModeEveningHorizon -7
   ASC_autoAstroModeMorning HORIZON
   ASC_autoAstroModeMorningHorizon -5
   ASC_autoShuttersControlEvening on
   ASC_autoShuttersControlMorning on
   ASC_residentsDevice rgr_Home
   ASC_sunPosDevice Astro
   ASC_sunPosReading SunAz
   ASC_temperatureReading temperature
   ASC_temperatureSensor GV.xx.TF.Aussen
   DbLogExclude .*
   icon       fts_shutter_automatic
   room       Rolladen


List Rolladen-Device:
Internals:
   CUL_Stick_MSGCNT 7
   CUL_Stick_RAWMSG A0DC3A4103B85C12CD68A06015000::-65:CUL_Stick
   CUL_Stick_RSSI -65
   CUL_Stick_TIME 2018-10-11 19:58:41
   DEF        3B85C1
   HMLAN_MSGCNT 8
   HMLAN_RAWMSG E3B85C1,0000,01C89FD6,FF,FFB8,C3A4103B85C12CD68A06015000
   HMLAN_RSSI -72
   HMLAN_TIME 2018-10-11 19:58:41
   IODev      CUL_Stick
   LASTInputDev HMLAN
   MSGCNT     15
   NAME       EG.ku.RO.KURolladen
   NOTIFYDEV  global
   NR         169
   NTFY_ORDER 50-EG.ku.RO.KURolladen
   STATE      60
   TYPE       CUL_HM
   lastMsg    No:C3 - t:10 s:3B85C1 d:2CD68A 06015000
   protLastRcv 2018-10-11 19:58:41
   protRcv    7 last_at:2018-10-11 19:58:41
   protSnd    8 last_at:2018-10-11 19:58:41
   protState  CMDs_done
   rssi_CUL_Stick cnt:3 min:-71 max:-69 avg:-70.33 lst:-71
   rssi_HMLAN cnt:1 min:-68 max:-68 avg:-68 lst:-68
   rssi_at_CUL_Stick cnt:7 min:-71.5 max:-65 avg:-67.5 lst:-65
   rssi_at_HMLAN cnt:8 min:-72 max:-69 avg:-70.62 lst:-72
   OLDREADINGS:
   READINGS:
     2018-10-11 19:28:37   ASC_Time_DriveDown 12.10.2018 - 19:29
     2018-10-11 19:28:37   ASC_Time_DriveUp 12.10.2018 - 07:21
     2018-10-11 19:58:37   CommandAccepted yes
     2018-09-30 11:11:46   D-firmware      2.5
     2018-09-30 11:11:46   D-serialNr      MEQ0392305
     2018-10-04 19:04:36   PairedTo        0x2CD68A
     2018-10-04 19:04:36   R-confBtnTime   5 min
     2018-10-04 19:04:36   R-driveDown     23 s
     2018-10-04 19:04:36   R-driveTurn     0.5 s
     2018-10-04 19:04:36   R-driveUp       23 s
     2018-10-04 19:04:36   R-intKeyVisib   invisib
     2018-10-04 19:04:36   R-localResDis   off
     2018-10-04 19:04:36   R-pairCentral   0x2CD68A
     2018-10-04 19:04:36   R-refRunCounter 0
     2018-10-04 19:04:36   R-sign          off
     2018-10-04 19:04:36   R-statusInfoMinDly 2 s
     2018-10-04 19:04:36   R-statusInfoRandom 1 s
     2018-10-04 19:04:36   R-transmitTryMax 6
     2018-10-04 19:04:36   RegL_00.        02:01 0A:2C 0B:D6 0C:8A 15:05 18:00 00:00
     2018-10-04 19:04:36   RegL_01.        08:00 09:00 0A:00 0B:00 0C:E6 0D:00 0E:E6 0F:05 10:00  30:06 57:24 56:00 00:00
     2018-10-11 19:58:41   deviceMsg       60 (to VCCU)
     2018-10-11 19:58:41   level           60
     2018-10-11 19:58:41   motor           stop:60
     2018-10-11 19:58:41   pct             60
     2018-10-11 19:58:41   recentStateType info
     2018-10-11 19:58:41   state           60
     2018-10-11 19:58:41   timedOn         off
   helper:
     HM_CMDNR   195
     cSnd       112CD68A3B85C102013C,112CD68A3B85C1020150
     dlvlCmd    ++A0112CD68A3B85C1020150
     mId        0005
     regLst     ,0,1,3p
     rxType     1
     supp_Pair_Rep 0
     ack:
     dir:
       cur        stop
       rct        up
     expert:
       def        1
       det        1
       raw        1
       tpl        1
     io:
       newChn     +3B85C1,00,00,00
       nextSend   1539280721.50428
       prefIO     
       rxt        0
       vccu       VCCU
       p:
         3B85C1
         00
         00
         00
     mRssi:
       mNo        C3
       io:
         CUL_Stick:
           -61
           -61
         HMLAN:
           -72
           -72
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       prs        1
     rpt:
       IO         CUL_Stick
       flg        A
       ts         1539280721.4058
       ack:
         HASH(0x77d2a38)
         C380022CD68A3B85C100
     rssi:
       CUL_Stick:
         avg        -70.3333333333333
         cnt        3
         lst        -71
         max        -69
         min        -71
       HMLAN:
         avg        -68
         cnt        1
         lst        -68
         max        -68
         min        -68
       at_CUL_Stick:
         avg        -67.5
         cnt        7
         lst        -65
         max        -65
         min        -71.5
       at_HMLAN:
         avg        -70.625
         cnt        8
         lst        -72
         max        -69
         min        -72
     tmpl:
Attributes:
   ASC        2
   ASC_Antifreeze off
   ASC_AutoAstroModeEvening none
   ASC_AutoAstroModeEveningHorizon none
   ASC_AutoAstroModeMorning none
   ASC_AutoAstroModeMorningHorizon none
   ASC_Closed_Pos 100
   ASC_Direction 178
   ASC_Down   astro
   ASC_GuestRoom none
   ASC_Mode_Down always
   ASC_Mode_Up always
   ASC_Offset_Minutes_Evening 1
   ASC_Offset_Minutes_Morning 1
   ASC_Open_Pos 0
   ASC_Partymode off
   ASC_Pos_Cmd pct
   ASC_Pos_after_ComfortOpen 80
   ASC_Rand_Minutes 20
   ASC_Roommate_Device none
   ASC_Roommate_Reading state
   ASC_Shading off
   ASC_Shading_Angle_Left 55
   ASC_Shading_Angle_Right 70
   ASC_Shading_BlockingTime_After_Manual 20
   ASC_Shading_BlockingTime_Twilight 45
   ASC_Shading_Brightness_Reading brightness
   ASC_Shading_Brightness_Sensor none
   ASC_Shading_Fast_Close none
   ASC_Shading_Fast_Open none
   ASC_Shading_Min_Elevation none
   ASC_Shading_Min_OutsideTemperature 18
   ASC_Shading_Pos 30
   ASC_Shading_Pos_after_Shading -1
   ASC_Shading_StateChange_Cloudy 4000
   ASC_Shading_StateChange_Sunny 6000
   ASC_Shading_WaitingPeriod 20
   ASC_Time_Down_Early 15:30
   ASC_Time_Down_Late 22:30
   ASC_Time_Up_Early 04:30
   ASC_Time_Up_Late 09:00
   ASC_Time_Up_WE_Holiday 08:30
   ASC_Up     astro
   ASC_Ventilate_Pos 60
   ASC_Ventilate_Window_Open on
   ASC_WindowRec EG.ku.TK.FensterKU
   ASC_WindowRec_subType threestate
   ASC_lock-out soft
   ASC_lock-outCmd none
   DbLogExclude .*
   IODev      HMLAN
   IOgrp      VCCU
   autoReadReg 4_reqStatus
   devStateIcon Auf:fts_shutter_10@green Zu:fts_shutter_100@black 9\d.*:fts_shutter_90 8\d.*:fts_shutter_80 7\d.*:fts_shutter_70 6\d.*:fts_shutter_60 5\d.*:fts_shutter_50 4\d.*:fts_shutter_40 3\d.*:fts_shutter_30 2\d.*:fts_shutter_20 1\d.*:fts_shutter_10 0\d.*:fts_shutter_10
   eventMap   off:Auf on:Zu up:Hoch down:Runter stop:Stop
   expert     251_anything
   firmware   2.5
   genericDeviceType blind
   group      Rolladen
   model      HM-LC-BL1-FM
   param      levelInverse
   peerIDs    00000000,
   room       Homekit,Rolladen
   serialNr   MEQ0392305
   subType    blindActuator
   userattr   ASC_Antifreeze:off,on ASC_AutoAstroModeEvening:REAL,CIVIL,NAUTIC,ASTRONOMIC,HORIZON ASC_AutoAstroModeEveningHorizon:-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9 ASC_AutoAstroModeMorning:REAL,CIVIL,NAUTIC,ASTRONOMIC,HORIZON ASC_AutoAstroModeMorningHorizon:-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9 ASC_Closed_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_Direction ASC_Down:time,astro ASC_GuestRoom:on,off ASC_Mode_Down:absent,always,off ASC_Mode_Up:absent,always,off ASC_Offset_Minutes_Evening ASC_Offset_Minutes_Morning ASC_Open_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_Partymode:on,off ASC_Pos_Cmd ASC_Pos_after_ComfortOpen:0,10,20,30,40,50,60,70,80,90,100 ASC_Rand_Minutes ASC_Roommate_Device ASC_Roommate_Reading ASC_Shading:on,off,delayed,present,absent ASC_Shading_Angle_Left:0,5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90 ASC_Shading_Angle_Right:0,5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90 ASC_Shading_BlockingTime_After_Manual ASC_Shading_BlockingTime_Twilight ASC_Shading_Brightness_Reading ASC_Shading_Brightness_Sensor ASC_Shading_Fast_Close:on,off ASC_Shading_Fast_Open:on,off ASC_Shading_Min_Elevation ASC_Shading_Min_OutsideTemperature ASC_Shading_Pos:10,20,30,40,50,60,70,80,90,100 ASC_Shading_Pos_after_Shading:-1,0,10,20,30,40,50,60,70,80,90,100 ASC_Shading_StateChange_Cloudy ASC_Shading_StateChange_Sunny ASC_Shading_WaitingPeriod ASC_Time_Down_Early ASC_Time_Down_Late ASC_Time_Up_Early ASC_Time_Up_Late ASC_Time_Up_WE_Holiday ASC_Up:time,astro ASC_Ventilate_Pos:10,20,30,40,50,60,70,80,90,100 ASC_Ventilate_Window_Open:on,off ASC_WindowRec ASC_WindowRec_subType:twostate,threestate ASC_lock-out:soft,hard ASC_lock-outCmd:inhibit,blocked AutoShuttersControl_lock-out:on,off
   webCmd     pct:Auf:Zu:Hoch:Runter:Stop
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Deckoffizier am 11 Oktober 2018, 20:17:18
Hallo,

bescheidene Anfrage: hat sich bei der neusten Version am ASC_Pos_Cmd etwas geändert?

Mein Siro Rollo ist Heute runter gefahren mit ASC_Pos_Cmd position.
Meine beiden UniRoll Rollos sind oben geblieben mit ASC_Pos_Cmd pos.

Bei der letzten Version lief eigentlich soweit alles bestens auch nach FHEM Neustart.

Gruß

Hans-Jürgen
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 11 Oktober 2018, 21:03:59
Sollte sich nichts geändert haben. Aber ich schaue da gerne noch mal nach.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Deckoffizier am 11 Oktober 2018, 22:19:28
Hallo CoolTux,

habe erstmal das up und down Kommando benutzt, danach lief auch der pos Befehl wieder,
mal sehen wie es morgen früh aussieht.

Gruß
Hans-Jürgen
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 11 Oktober 2018, 22:43:58
Zitat von: C0mmanda am 11 Oktober 2018, 20:00:36
OK :)
War nur eine Idee  ::)

List ASC-Device:
Internals:
   MID        da39a3ee5e6b4b0d3255bfef95601890afd80709
   NAME       Rolladensteuerung
   NOTIFYDEV  EG.ku.TK.FensterKU,OG.sz.TK.FensterSZ,Rolladensteuerung,global,rgr_Home,rr_Sascha
   NR         219
   NTFY_ORDER 50-Rolladensteuerung
   NotifyOrderPrefix 51-
   STATE      active
   TYPE       AutoShuttersControl
   VERSION    0.1.78
   OLDREADINGS:
   READINGS:
     2018-10-11 19:28:37   EG.ku.RO.KURolladen_lastPosValue 30
     2018-10-11 19:28:37   EG.ku.RO.KURolladen_nextAstroTimeEvent 12.10.2018 - 07:21
     2018-10-11 19:28:33   EG.sp.RO.SPRolladen_lastPosValue 100
     2018-10-11 19:28:33   EG.sp.RO.SPRolladen_nextAstroTimeEvent 12.10.2018 - 07:21
     2018-10-11 19:28:25   EG.wz.RO.WZRolladen.1_lastPosValue 100
     2018-10-11 19:28:25   EG.wz.RO.WZRolladen.1_nextAstroTimeEvent 12.10.2018 - 07:21
     2018-10-11 19:28:25   EG.wz.RO.WZRolladen.2_lastPosValue 100
     2018-10-11 19:28:25   EG.wz.RO.WZRolladen.2_nextAstroTimeEvent 12.10.2018 - 07:21
     2018-10-11 19:29:11   OG.az.RO.AZRolladen_lastPosValue 100
     2018-10-11 19:29:11   OG.az.RO.AZRolladen_nextAstroTimeEvent 12.10.2018 - 07:22
     2018-10-11 19:28:30   OG.gz.RO.GZRolladen_lastPosValue 90
     2018-10-11 19:28:30   OG.gz.RO.GZRolladen_nextAstroTimeEvent 12.10.2018 - 09:30
     2018-10-11 19:28:34   OG.sz.RO.SZRolladen_lastPosValue 30
     2018-10-11 19:28:34   OG.sz.RO.SZRolladen_nextAstroTimeEvent 12.10.2018 - 07:21
     2018-09-30 11:23:06   lockOut         off
     2018-09-30 11:15:58   partyMode       off
     2018-10-11 17:49:18   room_Homekit_Rolladen EG.ku.RO.KURolladen, EG.sp.RO.SPRolladen, EG.wz.RO.WZRolladen.1, EG.wz.RO.WZRolladen.2, OG.az.RO.AZRolladen, OG.gz.RO.GZRolladen, OG.sz.RO.SZRolladen
     2018-10-10 19:40:55   selfDefence     on
     2018-10-11 17:49:18   state           active
     2018-10-06 10:12:13   sunriseTimeWeHoliday on
     2018-10-11 17:49:18   userAttrList    rolled out
   helper:
     shuttersList:
       EG.ku.RO.KURolladen
       EG.sp.RO.SPRolladen
       EG.wz.RO.WZRolladen.1
       EG.wz.RO.WZRolladen.2
       OG.az.RO.AZRolladen
       OG.gz.RO.GZRolladen
       OG.sz.RO.SZRolladen
   monitoredDevs:
     EG.ku.TK.FensterKU:
       EG.ku.RO.KURolladen ASC_WindowRec
     OG.sz.TK.FensterSZ:
       OG.sz.RO.SZRolladen ASC_WindowRec
     rgr_Home:
       Rolladensteuerung ASC_residentsDevice
     rr_Sascha:
       OG.sz.RO.SZRolladen ASC_Roommate_Device
Attributes:
   ASC_antifreezeTemp 3
   ASC_autoAstroModeEvening HORIZON
   ASC_autoAstroModeEveningHorizon -7
   ASC_autoAstroModeMorning HORIZON
   ASC_autoAstroModeMorningHorizon -5
   ASC_autoShuttersControlEvening on
   ASC_autoShuttersControlMorning on
   ASC_residentsDevice rgr_Home
   ASC_sunPosDevice Astro
   ASC_sunPosReading SunAz
   ASC_temperatureReading temperature
   ASC_temperatureSensor GV.xx.TF.Aussen
   DbLogExclude .*
   icon       fts_shutter_automatic
   room       Rolladen


List Rolladen-Device:
Internals:
   CUL_Stick_MSGCNT 7
   CUL_Stick_RAWMSG A0DC3A4103B85C12CD68A06015000::-65:CUL_Stick
   CUL_Stick_RSSI -65
   CUL_Stick_TIME 2018-10-11 19:58:41
   DEF        3B85C1
   HMLAN_MSGCNT 8
   HMLAN_RAWMSG E3B85C1,0000,01C89FD6,FF,FFB8,C3A4103B85C12CD68A06015000
   HMLAN_RSSI -72
   HMLAN_TIME 2018-10-11 19:58:41
   IODev      CUL_Stick
   LASTInputDev HMLAN
   MSGCNT     15
   NAME       EG.ku.RO.KURolladen
   NOTIFYDEV  global
   NR         169
   NTFY_ORDER 50-EG.ku.RO.KURolladen
   STATE      60
   TYPE       CUL_HM
   lastMsg    No:C3 - t:10 s:3B85C1 d:2CD68A 06015000
   protLastRcv 2018-10-11 19:58:41
   protRcv    7 last_at:2018-10-11 19:58:41
   protSnd    8 last_at:2018-10-11 19:58:41
   protState  CMDs_done
   rssi_CUL_Stick cnt:3 min:-71 max:-69 avg:-70.33 lst:-71
   rssi_HMLAN cnt:1 min:-68 max:-68 avg:-68 lst:-68
   rssi_at_CUL_Stick cnt:7 min:-71.5 max:-65 avg:-67.5 lst:-65
   rssi_at_HMLAN cnt:8 min:-72 max:-69 avg:-70.62 lst:-72
   OLDREADINGS:
   READINGS:
     2018-10-11 19:28:37   ASC_Time_DriveDown 12.10.2018 - 19:29
     2018-10-11 19:28:37   ASC_Time_DriveUp 12.10.2018 - 07:21
     2018-10-11 19:58:37   CommandAccepted yes
     2018-09-30 11:11:46   D-firmware      2.5
     2018-09-30 11:11:46   D-serialNr      MEQ0392305
     2018-10-04 19:04:36   PairedTo        0x2CD68A
     2018-10-04 19:04:36   R-confBtnTime   5 min
     2018-10-04 19:04:36   R-driveDown     23 s
     2018-10-04 19:04:36   R-driveTurn     0.5 s
     2018-10-04 19:04:36   R-driveUp       23 s
     2018-10-04 19:04:36   R-intKeyVisib   invisib
     2018-10-04 19:04:36   R-localResDis   off
     2018-10-04 19:04:36   R-pairCentral   0x2CD68A
     2018-10-04 19:04:36   R-refRunCounter 0
     2018-10-04 19:04:36   R-sign          off
     2018-10-04 19:04:36   R-statusInfoMinDly 2 s
     2018-10-04 19:04:36   R-statusInfoRandom 1 s
     2018-10-04 19:04:36   R-transmitTryMax 6
     2018-10-04 19:04:36   RegL_00.        02:01 0A:2C 0B:D6 0C:8A 15:05 18:00 00:00
     2018-10-04 19:04:36   RegL_01.        08:00 09:00 0A:00 0B:00 0C:E6 0D:00 0E:E6 0F:05 10:00  30:06 57:24 56:00 00:00
     2018-10-11 19:58:41   deviceMsg       60 (to VCCU)
     2018-10-11 19:58:41   level           60
     2018-10-11 19:58:41   motor           stop:60
     2018-10-11 19:58:41   pct             60
     2018-10-11 19:58:41   recentStateType info
     2018-10-11 19:58:41   state           60
     2018-10-11 19:58:41   timedOn         off
   helper:
     HM_CMDNR   195
     cSnd       112CD68A3B85C102013C,112CD68A3B85C1020150
     dlvlCmd    ++A0112CD68A3B85C1020150
     mId        0005
     regLst     ,0,1,3p
     rxType     1
     supp_Pair_Rep 0
     ack:
     dir:
       cur        stop
       rct        up
     expert:
       def        1
       det        1
       raw        1
       tpl        1
     io:
       newChn     +3B85C1,00,00,00
       nextSend   1539280721.50428
       prefIO     
       rxt        0
       vccu       VCCU
       p:
         3B85C1
         00
         00
         00
     mRssi:
       mNo        C3
       io:
         CUL_Stick:
           -61
           -61
         HMLAN:
           -72
           -72
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       prs        1
     rpt:
       IO         CUL_Stick
       flg        A
       ts         1539280721.4058
       ack:
         HASH(0x77d2a38)
         C380022CD68A3B85C100
     rssi:
       CUL_Stick:
         avg        -70.3333333333333
         cnt        3
         lst        -71
         max        -69
         min        -71
       HMLAN:
         avg        -68
         cnt        1
         lst        -68
         max        -68
         min        -68
       at_CUL_Stick:
         avg        -67.5
         cnt        7
         lst        -65
         max        -65
         min        -71.5
       at_HMLAN:
         avg        -70.625
         cnt        8
         lst        -72
         max        -69
         min        -72
     tmpl:
Attributes:
   ASC        2
   ASC_Antifreeze off
   ASC_AutoAstroModeEvening none
   ASC_AutoAstroModeEveningHorizon none
   ASC_AutoAstroModeMorning none
   ASC_AutoAstroModeMorningHorizon none
   ASC_Closed_Pos 100
   ASC_Direction 178
   ASC_Down   astro
   ASC_GuestRoom none
   ASC_Mode_Down always
   ASC_Mode_Up always
   ASC_Offset_Minutes_Evening 1
   ASC_Offset_Minutes_Morning 1
   ASC_Open_Pos 0
   ASC_Partymode off
   ASC_Pos_Cmd pct
   ASC_Pos_after_ComfortOpen 80
   ASC_Rand_Minutes 20
   ASC_Roommate_Device none
   ASC_Roommate_Reading state
   ASC_Shading off
   ASC_Shading_Angle_Left 55
   ASC_Shading_Angle_Right 70
   ASC_Shading_BlockingTime_After_Manual 20
   ASC_Shading_BlockingTime_Twilight 45
   ASC_Shading_Brightness_Reading brightness
   ASC_Shading_Brightness_Sensor none
   ASC_Shading_Fast_Close none
   ASC_Shading_Fast_Open none
   ASC_Shading_Min_Elevation none
   ASC_Shading_Min_OutsideTemperature 18
   ASC_Shading_Pos 30
   ASC_Shading_Pos_after_Shading -1
   ASC_Shading_StateChange_Cloudy 4000
   ASC_Shading_StateChange_Sunny 6000
   ASC_Shading_WaitingPeriod 20
   ASC_Time_Down_Early 15:30
   ASC_Time_Down_Late 22:30
   ASC_Time_Up_Early 04:30
   ASC_Time_Up_Late 09:00
   ASC_Time_Up_WE_Holiday 08:30
   ASC_Up     astro
   ASC_Ventilate_Pos 60
   ASC_Ventilate_Window_Open on
   ASC_WindowRec EG.ku.TK.FensterKU
   ASC_WindowRec_subType threestate
   ASC_lock-out soft
   ASC_lock-outCmd none
   DbLogExclude .*
   IODev      HMLAN
   IOgrp      VCCU
   autoReadReg 4_reqStatus
   devStateIcon Auf:fts_shutter_10@green Zu:fts_shutter_100@black 9\d.*:fts_shutter_90 8\d.*:fts_shutter_80 7\d.*:fts_shutter_70 6\d.*:fts_shutter_60 5\d.*:fts_shutter_50 4\d.*:fts_shutter_40 3\d.*:fts_shutter_30 2\d.*:fts_shutter_20 1\d.*:fts_shutter_10 0\d.*:fts_shutter_10
   eventMap   off:Auf on:Zu up:Hoch down:Runter stop:Stop
   expert     251_anything
   firmware   2.5
   genericDeviceType blind
   group      Rolladen
   model      HM-LC-BL1-FM
   param      levelInverse
   peerIDs    00000000,
   room       Homekit,Rolladen
   serialNr   MEQ0392305
   subType    blindActuator
   userattr   ASC_Antifreeze:off,on ASC_AutoAstroModeEvening:REAL,CIVIL,NAUTIC,ASTRONOMIC,HORIZON ASC_AutoAstroModeEveningHorizon:-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9 ASC_AutoAstroModeMorning:REAL,CIVIL,NAUTIC,ASTRONOMIC,HORIZON ASC_AutoAstroModeMorningHorizon:-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9 ASC_Closed_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_Direction ASC_Down:time,astro ASC_GuestRoom:on,off ASC_Mode_Down:absent,always,off ASC_Mode_Up:absent,always,off ASC_Offset_Minutes_Evening ASC_Offset_Minutes_Morning ASC_Open_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_Partymode:on,off ASC_Pos_Cmd ASC_Pos_after_ComfortOpen:0,10,20,30,40,50,60,70,80,90,100 ASC_Rand_Minutes ASC_Roommate_Device ASC_Roommate_Reading ASC_Shading:on,off,delayed,present,absent ASC_Shading_Angle_Left:0,5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90 ASC_Shading_Angle_Right:0,5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90 ASC_Shading_BlockingTime_After_Manual ASC_Shading_BlockingTime_Twilight ASC_Shading_Brightness_Reading ASC_Shading_Brightness_Sensor ASC_Shading_Fast_Close:on,off ASC_Shading_Fast_Open:on,off ASC_Shading_Min_Elevation ASC_Shading_Min_OutsideTemperature ASC_Shading_Pos:10,20,30,40,50,60,70,80,90,100 ASC_Shading_Pos_after_Shading:-1,0,10,20,30,40,50,60,70,80,90,100 ASC_Shading_StateChange_Cloudy ASC_Shading_StateChange_Sunny ASC_Shading_WaitingPeriod ASC_Time_Down_Early ASC_Time_Down_Late ASC_Time_Up_Early ASC_Time_Up_Late ASC_Time_Up_WE_Holiday ASC_Up:time,astro ASC_Ventilate_Pos:10,20,30,40,50,60,70,80,90,100 ASC_Ventilate_Window_Open:on,off ASC_WindowRec ASC_WindowRec_subType:twostate,threestate ASC_lock-out:soft,hard ASC_lock-outCmd:inhibit,blocked AutoShuttersControl_lock-out:on,off
   webCmd     pct:Auf:Zu:Hoch:Runter:Stop



Ich habe das mal mit Deinen Daten simuliert, bei mir geht es. Entscheidend ist das Residents eingerichtet ist und SelfDefense auf on steht. Wenn dann ein Fenster offen steht und Residents absent ist sollte da der Rolladen runter fahren.
Zeig mal bitte ein List Deines Residents Devices.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 12 Oktober 2018, 06:41:02
Guten Morgen,

Leider gab es heute bei der Berechnung vom WE Timer einen Absturz vom kompletten FHEM  :'(
Bitte kontrolliert Eure FHEM Instanzen auf Funktion. Ich habe das bereits gefixt und ins Github hoch geladen. Bitte vor heute Abend unbedingt Updaten.


Grüße
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: C0mmanda am 12 Oktober 2018, 07:02:56
Moin,

da läuft jetzt scheinbar was anderes nicht rund...

Durch das Update sind alle Einstellungen bezgl ASC_AutoAstroMode(Evening|Morning) auf default zurück, ebenso die Zeiten! (TimeUpEarly, TimeUpLate).
Außerdem nimmt er für heute (Freitag) die WE-Zeit anstatt die Zeit für Wochentage.

Siehe list. Rolladen sollte heute spätestens um 7:00 hochfahren (TimeUpLate), fährt aber erst um 09:30 (TimeUpWE).
renewsetSunriseSunSetTimer hilft nicht, neustart auch nicht.

Internals:
   CUL_Stick_MSGCNT 1
   CUL_Stick_RAWMSG A0EAFA4103B85C12CD68A0601000046::-66.5:CUL_Stick
   CUL_Stick_RSSI -66.5
   CUL_Stick_TIME 2018-10-12 06:54:58
   DEF        3B85C1
   HMLAN_MSGCNT 2
   HMLAN_RAWMSG R66A0AF99,0001,01AFE412,FF,FFB8,AFA4103B85C12CD68A0601000046
   HMLAN_RSSI -72
   HMLAN_TIME 2018-10-12 06:54:58
   IODev      HMLAN
   LASTInputDev CUL_Stick
   MSGCNT     3
   NAME       EG.ku.RO.KURolladen
   NOTIFYDEV  global
   NR         168
   NTFY_ORDER 50-EG.ku.RO.KURolladen
   STATE      Zu
   TYPE       CUL_HM
   lastMsg    No:AF - t:10 s:3B85C1 d:2CD68A 0601000046
   protLastRcv 2018-10-12 06:54:58
   protRcv    1 last_at:2018-10-12 06:54:58
   protSnd    2 last_at:2018-10-12 06:54:58
   protState  CMDs_done
   rssi_HMLAN cnt:1 min:-70 max:-70 avg:-70 lst:-70
   rssi_at_CUL_Stick cnt:1 min:-66.5 max:-66.5 avg:-66.5 lst:-66.5
   rssi_at_HMLAN cnt:2 min:-72 max:-72 avg:-72 lst:-72
   OLDREADINGS:
   READINGS:
     2018-10-12 07:00:14   ASC_Time_DriveDown 12.10.2018 - 19:27
     2018-10-12 07:00:14   ASC_Time_DriveUp 12.10.2018 - 09:30
     2018-10-11 20:10:49   CommandAccepted yes
     2018-09-30 11:11:46   D-firmware      2.5
     2018-09-30 11:11:46   D-serialNr      MEQ0392305
     2018-10-04 19:04:36   PairedTo        0x2CD68A
     2018-10-04 19:04:36   R-confBtnTime   5 min
     2018-10-04 19:04:36   R-driveDown     23 s
     2018-10-04 19:04:36   R-driveTurn     0.5 s
     2018-10-04 19:04:36   R-driveUp       23 s
     2018-10-04 19:04:36   R-intKeyVisib   invisib
     2018-10-04 19:04:36   R-localResDis   off
     2018-10-04 19:04:36   R-pairCentral   0x2CD68A
     2018-10-04 19:04:36   R-refRunCounter 0
     2018-10-04 19:04:36   R-sign          off
     2018-10-04 19:04:36   R-statusInfoMinDly 2 s
     2018-10-04 19:04:36   R-statusInfoRandom 1 s
     2018-10-04 19:04:36   R-transmitTryMax 6
     2018-10-04 19:04:36   RegL_00.        02:01 0A:2C 0B:D6 0C:8A 15:05 18:00 00:00
     2018-10-04 19:04:36   RegL_01.        08:00 09:00 0A:00 0B:00 0C:E6 0D:00 0E:E6 0F:05 10:00  30:06 57:24 56:00 00:00
     2018-10-12 06:54:58   deviceMsg       on (to VCCU)
     2018-10-12 06:54:58   level           100
     2018-10-12 06:54:58   motor           stop:on
     2018-10-12 06:54:58   pct             100
     2018-10-12 06:54:58   recentStateType info
     2018-10-12 06:54:58   state           on
     2018-10-12 06:54:58   timedOn         off
   helper:
     HM_CMDNR   175
     cSnd       ,012CD68A3B85C1010E
     mId        0005
     regLst     ,0,1,3p
     rxType     1
     supp_Pair_Rep 0
     ack:
     dir:
       cur        stop
     expert:
       def        1
       det        1
       raw        1
       tpl        1
     io:
       newChn     +3B85C1,00,00,00
       nextSend   1539320098.89234
       prefIO     
       rxt        0
       vccu       VCCU
       p:
         3B85C1
         00
         00
         00
     mRssi:
       mNo        AF
       io:
         CUL_Stick:
           -66.5
           -66.5
         HMLAN:
           -70
           -70
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       prs        1
     rpt:
       IO         HMLAN
       flg        A
       ts         1539320098.75356
       ack:
         HASH(0x70ec658)
         AF80022CD68A3B85C100
     rssi:
       HMLAN:
         avg        -70
         cnt        1
         lst        -70
         max        -70
         min        -70
       at_CUL_Stick:
         avg        -66.5
         cnt        1
         lst        -66.5
         max        -66.5
         min        -66.5
       at_HMLAN:
         avg        -72
         cnt        2
         lst        -72
         max        -72
         min        -72
     tmpl:
Attributes:
   ASC        2
   ASC_Antifreeze off
   ASC_AutoAstroModeEvening HORIZON
   ASC_AutoAstroModeEveningHorizon -7
   ASC_AutoAstroModeMorning HORIZON
   ASC_AutoAstroModeMorningHorizon -5
   ASC_Closed_Pos 100
   ASC_Direction 178
   ASC_Down   astro
   ASC_GuestRoom none
   ASC_Mode_Down always
   ASC_Mode_Up always
   ASC_Offset_Minutes_Evening 1
   ASC_Offset_Minutes_Morning 1
   ASC_Open_Pos 0
   ASC_Partymode off
   ASC_Pos_Cmd pct
   ASC_Pos_after_ComfortOpen 80
   ASC_Rand_Minutes 20
   ASC_Roommate_Device none
   ASC_Roommate_Reading state
   ASC_Shading off
   ASC_Shading_Angle_Left 55
   ASC_Shading_Angle_Right 70
   ASC_Shading_BlockingTime_After_Manual 20
   ASC_Shading_BlockingTime_Twilight 45
   ASC_Shading_Brightness_Reading brightness
   ASC_Shading_Brightness_Sensor none
   ASC_Shading_Fast_Close none
   ASC_Shading_Fast_Open none
   ASC_Shading_Min_Elevation none
   ASC_Shading_Min_OutsideTemperature 18
   ASC_Shading_Pos 30
   ASC_Shading_Pos_after_Shading -1
   ASC_Shading_StateChange_Cloudy 4000
   ASC_Shading_StateChange_Sunny 6000
   ASC_Shading_WaitingPeriod 20
   ASC_Time_Down_Early 18:30
   ASC_Time_Down_Late 23:00
   ASC_Time_Up_Early 06:30
   ASC_Time_Up_Late 07:00
   ASC_Time_Up_WE_Holiday 09:30
   ASC_Up     astro
   ASC_Ventilate_Pos 60
   ASC_Ventilate_Window_Open on
   ASC_WindowRec EG.ku.TK.FensterKU
   ASC_WindowRec_subType threestate
   ASC_lock-out soft
   ASC_lock-outCmd none
   DbLogExclude .*
   IODev      HMLAN
   IOgrp      VCCU
   autoReadReg 4_reqStatus
   devStateIcon Auf:fts_shutter_10@green Zu:fts_shutter_100@black 9\d.*:fts_shutter_90 8\d.*:fts_shutter_80 7\d.*:fts_shutter_70 6\d.*:fts_shutter_60 5\d.*:fts_shutter_50 4\d.*:fts_shutter_40 3\d.*:fts_shutter_30 2\d.*:fts_shutter_20 1\d.*:fts_shutter_10 0\d.*:fts_shutter_10
   eventMap   off:Auf on:Zu up:Hoch down:Runter stop:Stop
   expert     251_anything
   firmware   2.5
   genericDeviceType blind
   group      Rolladen
   model      HM-LC-BL1-FM
   param      levelInverse
   peerIDs    00000000,
   room       Homekit,Rolladen
   serialNr   MEQ0392305
   subType    blindActuator
   userattr   ASC_Antifreeze:off,on ASC_AutoAstroModeEvening:REAL,CIVIL,NAUTIC,ASTRONOMIC,HORIZON ASC_AutoAstroModeEveningHorizon:-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9 ASC_AutoAstroModeMorning:REAL,CIVIL,NAUTIC,ASTRONOMIC,HORIZON ASC_AutoAstroModeMorningHorizon:-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9 ASC_Closed_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_Direction ASC_Down:time,astro ASC_GuestRoom:on,off ASC_Mode_Down:absent,always,off ASC_Mode_Up:absent,always,off ASC_Offset_Minutes_Evening ASC_Offset_Minutes_Morning ASC_Open_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_Partymode:on,off ASC_Pos_Cmd ASC_Pos_after_ComfortOpen:0,10,20,30,40,50,60,70,80,90,100 ASC_Rand_Minutes ASC_Roommate_Device ASC_Roommate_Reading ASC_Shading:on,off,delayed,present,absent ASC_Shading_Angle_Left:0,5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90 ASC_Shading_Angle_Right:0,5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90 ASC_Shading_BlockingTime_After_Manual ASC_Shading_BlockingTime_Twilight ASC_Shading_Brightness_Reading ASC_Shading_Brightness_Sensor ASC_Shading_Fast_Close:on,off ASC_Shading_Fast_Open:on,off ASC_Shading_Min_Elevation ASC_Shading_Min_OutsideTemperature ASC_Shading_Pos:10,20,30,40,50,60,70,80,90,100 ASC_Shading_Pos_after_Shading:-1,0,10,20,30,40,50,60,70,80,90,100 ASC_Shading_StateChange_Cloudy ASC_Shading_StateChange_Sunny ASC_Shading_WaitingPeriod ASC_Time_Down_Early ASC_Time_Down_Late ASC_Time_Up_Early ASC_Time_Up_Late ASC_Time_Up_WE_Holiday ASC_Up:time,astro ASC_Ventilate_Pos:10,20,30,40,50,60,70,80,90,100 ASC_Ventilate_Window_Open:on,off ASC_WindowRec ASC_WindowRec_subType:twostate,threestate ASC_lock-out:soft,hard ASC_lock-outCmd:inhibit,blocked AutoShuttersControl_lock-out:on,off
   webCmd     pct:Auf:Zu:Hoch:Runter:Stop
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 12 Oktober 2018, 08:06:30
Das mit den Wochendezeiten zum hochfahren heute schaue ich mir an.
Das mit den default Werten kann ich leider an dem Rolladen von Dir nicht sehen.

ASC_AutoAstroModeEvening HORIZON

past ja. Default wäre none
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: hexenmeister am 12 Oktober 2018, 08:56:12
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.
Ich sehe einen Grund.
Ein Beispiel: ich habe mehrere 'normale' Fenster, bei denen so etwas sicherlich sehr sinnvoll ist, aber auch Velux-Dachfenster. Wenn diese offen sind, können die Rolladen nicht heruntergefahren werden, sie klemmen sich ein. Zwar erkennen sie das und bleiben stehen, dennoch unschön und sicher nicht materialschonend. Wäre daher schon wichtig, bestimmte Fenster ausschliessen zu können.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 12 Oktober 2018, 09:04:41
Zitat von: hexenmeister am 12 Oktober 2018, 08:56:12
Ich sehe einen Grund.
Ein Beispiel: ich habe mehrere 'normale' Fenster, bei denen so etwas sicherlich sehr sinnvoll ist, aber auch Velux-Dachfenster. Wenn diese offen sind, können die Rolladen nicht heruntergefahren werden, sie klemmen sich ein. Zwar erkennen sie das und bleiben stehen, dennoch unschön und sicher nicht materialschonend. Wäre daher schon wichtig, bestimmte Fenster ausschliessen zu können.

Dann werde ich schauen das ich da noch eine Abfrage mit einbaue.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: pc1246 am 12 Oktober 2018, 10:55:39
Zitat von: hexenmeister am 12 Oktober 2018, 08:56:12
Ich sehe einen Grund.
Ein Beispiel: ich habe mehrere 'normale' Fenster, bei denen so etwas sicherlich sehr sinnvoll ist, aber auch Velux-Dachfenster. Wenn diese offen sind, können die Rolladen nicht heruntergefahren werden, sie klemmen sich ein. Zwar erkennen sie das und bleiben stehen, dennoch unschön und sicher nicht materialschonend. Wäre daher schon wichtig, bestimmte Fenster ausschliessen zu können.
Moin
Mal eine Frage zwischendrin. Wie machst Du das mit den Sensoren am Velux Dachfenster?
Gruss Christoph
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: hexenmeister am 12 Oktober 2018, 11:27:02
Zitat von: pc1246 am 12 Oktober 2018, 10:55:39
Wie machst Du das mit den Sensoren am Velux Dachfenster?
Hardwareseitig?
Beim Ausbau von Dachboden habe ich Leitungen aus dem Verteiler zu jedem Fenster (draußen) verlegt. Diese sind an Reed-Kontakte (fertig eingegossene stabile Ausführung) angeschlossen. Die Kontakte sind mit Silikon vor jedem Fenster auf dem Blech festgeklebt. Am Fenster ist entsprechend ein kleines Neodim-Magnet befestigt. Ich habe EnOcean-Bus laufen, die Kontakte sind an ein FTS14-EM (umkonfiguriert in Fensterkontaktmodus) angeschlossen. Dann per FGW14-USB kommen die Daten zur FHEM...
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 12 Oktober 2018, 13:13:56
Ich habe nun eine neue Version fertig gestellt. Werde diese aber noch intensiv über das Wochenende testen.

SelfDevence kann pro Rolladen gesteuert werden Attr ASC_Self_Devence_Exclude on/off bei on wird SelfDevence nicht angewand.

Das öffnen und schließen Morgens und Abends kann per Brightness konfiguriert werden.
Dazu muss im Moduldevice Attr ASC_brightnessMinVal gesetzt werden. Desweiteren muss korrekt
ASC_Time_Down_Early
ASC_Time_Down_Late
ASC_Time_Up_Early
ASC_Time_Up_Late

korrekt gesetzt werden. Und nur zwischen Down_Early und Down_Late wird die Brightness aus gewertet und wenn drunter dann runter gefahren Abends und wenn drüber dann hoch gefahren Morgens.


Grüße
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: FunkOdyssey am 12 Oktober 2018, 13:53:32
Juchu :-) Und natürlich: Danke.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Benni am 12 Oktober 2018, 14:05:54
Zitat von: CoolTux am 12 Oktober 2018, 13:13:56
SelfDevence kann pro Rolladen gesteuert werden Attr ASC_Self_Devence_Exclude on/off bei on wird SelfDevence nicht angewand.

Ist hoffentlich nur in deinem Post falsch geschrieben? SelfDevence
Richtig müsste es SelfDefenfence oder auch SelfDefense heißen

Gruß Benni.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 12 Oktober 2018, 14:25:46
Zitat von: Benni am 12 Oktober 2018, 14:05:54
Ist hoffentlich nur in deinem Post falsch geschrieben? SelfDevence
Richtig müsste es SelfDefenfence oder auch SelfDefense heißen

Gruß Benni.

:-[ peinlich. Habe es mal korrigiert (im Code)
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: C0mmanda am 12 Oktober 2018, 18:02:50
Mahlzeit,

selfDefense funktioniert jetzt, zumindest fahren die Rolladen herunter wenn ein Fenster geöffnet ist und Residents auf absent geht.
Das die Rolläden wieder in die zuletzt bekannte Position hochfahren (WENN normalerweise kein Nachtschliessen erfolgt hat) funktioniert
aktuell noch nicht.

Gruß
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 12 Oktober 2018, 18:25:36
Zitat von: C0mmanda am 12 Oktober 2018, 18:02:50
Mahlzeit,

selfDefense funktioniert jetzt, zumindest fahren die Rolladen herunter wenn ein Fenster geöffnet ist und Residents auf absent geht.
Das die Rolläden wieder in die zuletzt bekannte Position hochfahren (WENN normalerweise kein Nachtschliessen erfolgt hat) funktioniert
aktuell noch nicht.

Gruß

Das ist/war bis jetzt auch noch nicht implementiert. Kann ich aber gerne einbauen.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: C0mmanda am 12 Oktober 2018, 18:30:32
Zitat von: CoolTux am 12 Oktober 2018, 18:25:36
Das ist/war bis jetzt auch noch nicht implementiert. Kann ich aber gerne einbauen.

Das wäre großartig!

Danke für die Arbeit!
Gruß
CmdA
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: C0mmanda am 12 Oktober 2018, 23:51:00
Zitat von: CoolTux am 12 Oktober 2018, 08:06:30
Das mit den Wochendezeiten zum hochfahren heute schaue ich mir an.
Das mit den default Werten kann ich leider an dem Rolladen von Dir nicht sehen.

ASC_AutoAstroModeEvening HORIZON

past ja. Default wäre none

Richtig, weil ich es bereits geändert hatte.
In dem list ist aber zu sehen das im Reading als nächstes Up-Event 09:30 angegeben ist, laut Attributen es auf einem Freitag um spätestens 7:00 erfolgen müsste.
Dafür war das list gedacht ;)

Gruss
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 13 Oktober 2018, 00:41:32
Ah jetzt verstehe ich. Alles klar.

Habe im übrigen Deinen Wunsch fertig eingebaut. Wenn Residents home geht und lastState absent oder gone war und SelfDefense on dann setzt er den Rolladen auf den Wert den er vor dem verlassen des Hauses hatte.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: C0mmanda am 13 Oktober 2018, 07:09:58
Wow, das ging mal wieder schnell :)
Werde testen sobald ich die Gelegenheit habe.

Gruß
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 13 Oktober 2018, 07:31:16
Aber erst ab Montag. Will erst noch mehr testen, sowas wie letztens mit Absturz von FHEM darf nicht noch mal passieren.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: C0mmanda am 13 Oktober 2018, 07:32:31
Zitat von: CoolTux am 13 Oktober 2018, 07:31:16
Aber erst ab Montag. Will erst noch mehr testen, sowas wie letztens mit Absturz von FHEM darf nicht noch mal passieren.

Ah okay.
Lass dir Zeit :)

Gruß
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 13 Oktober 2018, 08:39:08
Ich habe eben noch einen kleinen Bug gefixt. Bei mir sind morgens die Rolläden nicht hochgefahren wo ein Fenster auf war aber alle Einstellungen so das dies nicht beachtet werden sollte und Self Defense off.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Karflyer am 13 Oktober 2018, 11:08:38
Mir ist nicht klar welche Auswirkung aktuell das setzen des Resident-Devices im Modul bzw. das setzten eines Roommate am Rolladen-Device hat. Kann mir das bitte jemand erklären? Oder gibt es eine zusammenfassenden Beitrag zu dem Thema (habe selbst keinen gefunden). Ich hatte das bis dato per DOIF so gesteuert, dass die Rolläden bei 'absent' des Resident per Astro-Zeiten hoch und runter fahren. Bei Anwesenheit der Roommates wird auf den Zustand 'awoken' geprüft und die Rolläden fahren bei dem Zustandswechsel asleep->awoken hoch. Das konnte ich bis dato mit dem ASC nicht nachbilden. Deshalb die Bitte kurz zusammenzufassen, was bereits mit Residents/Rommate geht.

Gruss
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 13 Oktober 2018, 11:12:51
Solange der resident "asleep" ist, wird nicht geöffnet. Könnte evtl. schon in der commandref (help ...) stehen.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 13 Oktober 2018, 11:13:18
Aktuell ist es so das die Roommates für hoch und runter fahren bei schlafen gehen und aufstehen da sind. Morgens wird also der Rolladen nicht hochgefahren wenn ein Roommate im Raum des Rolladens noch schläft.

Residents ist aktuell nur für SelfDefense. Wenn der Residents sich auf absent stellt wird geschaut wo ein Fenster noch auf ist und der dazugehörige Rolladen nicht zu. Wenn dem so ist wird der Rolladen runter gefahren.


Grüße
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Karflyer am 13 Oktober 2018, 11:15:38
OK. habe ich verstanden. Danke für die Erläuterungen.
Gruß
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Papaloewe am 13 Oktober 2018, 20:38:19
Hallo Leon,

mir ist gerade Folgendes aufgefallen:
Ausgangslage: Fenster ist bereits geöffnet und der Rolladen fährt mit der normalen Astro-Funktion herunter.
Dabei wird nicht die Ventilate-Position, sondern die Endlage (ganz herunter) angefahren.
Wenn das Fenster danach geschlossen und wieder geöffnet wird, wird die Ventilate Position angefahren.

Bug, oder Feature?

Gruß
Thomas
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 13 Oktober 2018, 20:41:18
Zitat von: Papaloewe am 13 Oktober 2018, 20:38:19
Hallo Leon,

mir ist gerade Folgendes aufgefallen:
Ausgangslage: Fenster ist bereits geöffnet und der Rolladen fährt mit der normalen Astro-Funktion herunter.
Dabei wird nicht die Ventilate-Position, sondern die Endlage (ganz herunter) angefahren.
Wenn das Fenster danach geschlossen und wieder geöffnet wird, wird die Ventilate Position angefahren.

Bug, oder Feature?

Gruß
Thomas

Hallo Thomas,

Kannst Du mir bitte ein list vom Rolladendevice geben.


Grüße
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Papaloewe am 13 Oktober 2018, 21:13:35
Bitte sehr:

Internals:
   CFGFN     
   DEF        3079F7
   HMLAN1_MSGCNT 21
   HMLAN1_RAWMSG E3079F7,0000,F1D43A7B,FF,FFAB,1EA4103079F7123ABC06010000
   HMLAN1_RSSI -85
   HMLAN1_TIME 2018-10-13 19:26:12
   HMUART_MSGCNT 12
   HMUART_RAWMSG 0500005A1EA4103079F7123ABC06010000
   HMUART_RSSI -90
   HMUART_TIME 2018-10-13 19:26:12
   IODev      hmusb
   LASTInputDev hmusb
   MSGCNT     58
   NAME       KG.KZ.Roll
   NOTIFYDEV  global
   NR         187
   NTFY_ORDER 50-KG.KZ.Roll
   STATE      down
   TYPE       CUL_HM
   hmusb_MSGCNT 25
   hmusb_RAWMSG E3079F7,0000,0BF797C3,FF,FFCF,1EA4103079F7123ABC06010000
   hmusb_RSSI -49
   hmusb_TIME 2018-10-13 19:26:12
   lastMsg    No:1E - t:10 s:3079F7 d:123ABC 06010000
   protLastRcv 2018-10-13 19:26:12
   protRcv    24 last_at:2018-10-13 19:26:12
   protSnd    27 last_at:2018-10-13 19:26:12
   protState  CMDs_done
   rssi_at_HMLAN1 cnt:21 min:-95 max:-84 avg:-89.61 lst:-85
   rssi_at_HMUART cnt:12 min:-96 max:-81 avg:-89.75 lst:-90
   rssi_at_hmusb cnt:25 min:-55 max:-48 avg:-51 lst:-49
   rssi_hmusb cnt:5 min:-54 max:-51 avg:-52.4 lst:-51
   Helper:
     DBLOG:
       state:
         myDbLog:
           TIME       1539451572.93465
           VALUE      down
   OLDREADINGS:
   READINGS:
     2018-10-13 19:05:59   ASC_Time_DriveDown 14.10.2018 - 19:06
     2018-10-13 19:05:59   ASC_Time_DriveUp 14.10.2018 - 09:30
     2018-10-13 19:26:07   CommandAccepted yes
     2017-07-26 18:29:02   D-firmware      2.11
     2017-07-26 18:29:02   D-serialNr      LEQ1179527
     2018-10-13 16:48:05   PairedTo        0x123ABC
     2017-07-26 18:30:28   R-confBtnTime   permanent
     2018-10-13 16:48:06   R-driveDown     13 s
     2017-07-26 18:30:29   R-driveTurn     0.5 s
     2018-10-13 16:48:06   R-driveUp       13 s
     2017-07-26 18:30:28   R-intKeyVisib   invisib
     2017-07-26 18:30:28   R-localResDis   off
     2017-07-26 18:30:28   R-pairCentral   0x123ABC
     2017-07-26 18:30:29   R-powerUpAction off
     2017-07-26 18:30:29   R-refRunCounter 0
     2017-07-26 18:30:29   R-sign          off
     2017-07-26 18:30:29   R-statusInfoMinDly 3 s
     2017-07-26 18:30:29   R-statusInfoRandom 0 s
     2017-07-26 18:30:29   R-transmitTryMax 6
     2018-10-13 19:26:12   deviceMsg       off (to vccu)
     2018-10-13 19:26:12   level           0
     2018-10-13 19:26:12   motor           stop:off
     2018-10-13 19:26:12   pct             0
     2018-10-13 19:26:12   recentStateType info
     2017-12-20 09:28:15   sabotageAttack_ErrIoAttack cnt 2
     2018-10-13 19:26:12   state           off
     2018-10-13 19:26:12   timedOn         off
   helper:
     HM_CMDNR   30
     cSnd       11123ABC3079F7020100,11123ABC3079F7020100
     dlvlCmd    ++A011123ABC3079F7020100
     mId        006A
     peerIDsRaw ,00000000
     regLst     ,0,1,3p
     rxType     1
     supp_Pair_Rep 0
     ack:
     dir:
       cur        stop
       rct        down
     expert:
       def        1
       det        1
       raw        0
       tpl        0
     io:
       newChn     +3079F7,00,01,00
       nextSend   1539451573.04285
       prefIO     
       rxt        0
       vccu       vccu
       p:
         3079F7
         00
         01
         00
     mRssi:
       mNo        1E
       io:
         HMLAN1:
           -85
           -85
         HMUART:
           -90
           -90
         hmusb:
           -41
           -41
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       prs        1
     rpt:
       IO         HMUART
       flg        A
       ts         1539451572.91659
       ack:
         HASH(0x5e60708)
         1E8002123ABC3079F700
     rssi:
       at_HMLAN1:
         avg        -89.6190476190476
         cnt        21
         lst        -85
         max        -84
         min        -95
       at_HMUART:
         avg        -89.75
         cnt        12
         lst        -90
         max        -81
         min        -96
       at_hmusb:
         avg        -51
         cnt        25
         lst        -49
         max        -48
         min        -55
       hmusb:
         avg        -52.4
         cnt        5
         lst        -51
         max        -51
         min        -54
     shadowReg:
     tmpl:
Attributes:
   ASC        2
   ASC_Antifreeze off
   ASC_AutoAstroModeEvening none
   ASC_AutoAstroModeEveningHorizon none
   ASC_AutoAstroModeMorning none
   ASC_AutoAstroModeMorningHorizon none
   ASC_Closed_Pos 0
   ASC_Direction 178
   ASC_Down   astro
   ASC_GuestRoom none
   ASC_Mode_Down always
   ASC_Mode_Up always
   ASC_Offset_Minutes_Evening 1
   ASC_Offset_Minutes_Morning 1
   ASC_Open_Pos 100
   ASC_Partymode off
   ASC_Pos_Cmd pct
   ASC_Pos_after_ComfortOpen 80
   ASC_Rand_Minutes 20
   ASC_Roommate_Device none
   ASC_Roommate_Reading state
   ASC_Shading off
   ASC_Shading_Angle_Left 85
   ASC_Shading_Angle_Right 85
   ASC_Shading_BlockingTime_After_Manual 20
   ASC_Shading_BlockingTime_Twilight 45
   ASC_Shading_Brightness_Reading brightness
   ASC_Shading_Brightness_Sensor none
   ASC_Shading_Fast_Close none
   ASC_Shading_Fast_Open none
   ASC_Shading_Min_Elevation none
   ASC_Shading_Min_OutsideTemperature 18
   ASC_Shading_Pos 70
   ASC_Shading_Pos_after_Shading -1
   ASC_Shading_StateChange_Cloudy 4000
   ASC_Shading_StateChange_Sunny 6000
   ASC_Shading_WaitingPeriod 20
   ASC_Time_Down_Early 16:30
   ASC_Time_Down_Late 23:00
   ASC_Time_Up_Early 05:00
   ASC_Time_Up_Late 08:00
   ASC_Time_Up_WE_Holiday 09:30
   ASC_Up     astro
   ASC_Ventilate_Pos 20
   ASC_Ventilate_Window_Open on
   ASC_WindowRec KG.KZ.TFK.li,KG.KZ.TFK.re
   ASC_WindowRec_subType twostate
   ASC_lock-out soft
   ASC_lock-outCmd none
   IODev      hmusb
   IOgrp      vccu
   Rolladen   Roll
   autoReadReg 0_off
   cmdIcon    on:fts_shutter_up off:fts_shutter_down
   devStateIcon set_.*:fts_shutter_updown@red up:fts_shutter_10 down:fts_shutter_100 9\d.*:fts_shutter_10 8\d.*:fts_shutter_20 7\d.*:fts_shutter_30 6\d.*:fts_shutter_40 5\d.*:fts_shutter_50 4\d.*:fts_shutter_50 3\d.*:fts_shutter_40 2\d.*:fts_shutter_30 1\d.*:fts_shutter_20 0\d.*fts_:shutter_10
   event-on-change-reading state
   eventMap   on:up off:down
   expert     1_allReg
   firmware   2.11
   group      Rolladen
   model      HM-LC-Bl1PBU-FM
   peerIDs    00000000,
   room       ASC,Patrick
   serialNr   LEQ1179527
   subType    blindActuator
   userattr   ASC_Antifreeze:off,on ASC_AutoAstroModeEvening:REAL,CIVIL,NAUTIC,ASTRONOMIC,HORIZON ASC_AutoAstroModeEveningHorizon:-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9 ASC_AutoAstroModeMorning:REAL,CIVIL,NAUTIC,ASTRONOMIC,HORIZON ASC_AutoAstroModeMorningHorizon:-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9 ASC_Closed_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_Direction ASC_Down:time,astro ASC_GuestRoom:on,off ASC_Mode_Down:absent,always,off ASC_Mode_Up:absent,always,off ASC_Offset_Minutes_Evening ASC_Offset_Minutes_Morning ASC_Open_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_Partymode:on,off ASC_Pos_Cmd ASC_Pos_after_ComfortOpen:0,10,20,30,40,50,60,70,80,90,100 ASC_Rand_Minutes ASC_Roommate_Device ASC_Roommate_Reading ASC_Shading:on,off,delayed,present,absent ASC_Shading_Angle_Left:0,5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90 ASC_Shading_Angle_Right:0,5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90 ASC_Shading_BlockingTime_After_Manual ASC_Shading_BlockingTime_Twilight ASC_Shading_Brightness_Reading ASC_Shading_Brightness_Sensor ASC_Shading_Fast_Close:on,off ASC_Shading_Fast_Open:on,off ASC_Shading_Min_Elevation ASC_Shading_Min_OutsideTemperature ASC_Shading_Pos:10,20,30,40,50,60,70,80,90,100 ASC_Shading_Pos_after_Shading:-1,0,10,20,30,40,50,60,70,80,90,100 ASC_Shading_StateChange_Cloudy ASC_Shading_StateChange_Sunny ASC_Shading_WaitingPeriod ASC_Time_Down_Early ASC_Time_Down_Late ASC_Time_Up_Early ASC_Time_Up_Late ASC_Time_Up_WE_Holiday ASC_Up:time,astro ASC_Ventilate_Pos:10,20,30,40,50,60,70,80,90,100 ASC_Ventilate_Window_Open:on,off ASC_WindowRec ASC_WindowRec_subType:twostate,threestate ASC_lock-out:soft,hard ASC_lock-outCmd:inhibit,blocked Rolladen Rolladen_map structexclude
   webCmd     up:down:stop:pct


Noch etwas:
Die Ventilate-Position bleibt auch nicht dauerhaft erhalten. Sprich, nach einer Zeit x wird wieder in die Endlage gefahren, obwohl das Fenster weiter gekippt ist.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 13 Oktober 2018, 21:19:27
ich versuche das mal nach zu bauen. kannst du mir noch ein list vom Moduldevice bitte geben.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Papaloewe am 13 Oktober 2018, 21:25:12
Internals:
   CFGFN     
   MID        da39a3ee5e6b4b0d3255bfef95601890afd80709
   NAME       Rolladensteuerung
   NOTIFYDEV  global,Rolladensteuerung,OG.KZ.TFK.re,EG.WZ.TFK.li,KG.KZ.TFK.re,OG.KZ.TFK.li,OG.SZ.TFK.re,OG.WC.TFK.re,OG.SZ.TFK.li,KG.KZ.TFK.li,EG.WZ.TFK.re,EG.KU.TFK.re
   NR         627
   NTFY_ORDER 50-Rolladensteuerung
   NotifyOrderPrefix 51-
   STATE      active
   TYPE       AutoShuttersControl
   VERSION    0.1.79
   Helper:
     DBLOG:
       EG.KU.Roll_lastPosValue:
         myDbLog:
           TIME       1539450364.08572
           VALUE      100
       EG.KU.Roll_nextAstroTimeEvent:
         myDbLog:
           TIME       1539450364.09493
           VALUE      14.10.2018 - 08:00
       EG.WZ.Roll_lastPosValue:
         myDbLog:
           TIME       1539457841.57773
           VALUE      0
       EG.WZ.Roll_nextAstroTimeEvent:
         myDbLog:
           TIME       1539450380.06398
           VALUE      14.10.2018 - 08:00
       KG.KZ.Roll_lastPosValue:
         myDbLog:
           TIME       1539451567.24309
           VALUE      0
       KG.KZ.Roll_nextAstroTimeEvent:
         myDbLog:
           TIME       1539450359.06873
           VALUE      14.10.2018 - 09:30
       OG.KZ.Roll_lastPosValue:
         myDbLog:
           TIME       1539450345.08866
           VALUE      100
       OG.KZ.Roll_nextAstroTimeEvent:
         myDbLog:
           TIME       1539450345.09828
           VALUE      14.10.2018 - 09:30
       OG.SZ.Roll_lastPosValue:
         myDbLog:
           TIME       1539450330.07713
           VALUE      100
       OG.SZ.Roll_nextAstroTimeEvent:
         myDbLog:
           TIME       1539450330.08687
           VALUE      14.10.2018 - 08:30
       OG.WC.Roll_lastDelayPosValue:
         myDbLog:
           TIME       1539450372.01704
           VALUE      90
       OG.WC.Roll_nextAstroTimeEvent:
         myDbLog:
           TIME       1539450372.03054
           VALUE      14.10.2018 - 08:00
   OLDREADINGS:
   READINGS:
     2018-10-13 19:06:04   EG.KU.Roll_lastPosValue 100
     2018-10-13 19:06:04   EG.KU.Roll_nextAstroTimeEvent 14.10.2018 - 08:00
     2018-10-13 21:10:41   EG.WZ.Roll_lastPosValue 0
     2018-10-13 19:06:20   EG.WZ.Roll_nextAstroTimeEvent 14.10.2018 - 08:00
     2018-10-13 19:26:07   KG.KZ.Roll_lastPosValue 0
     2018-10-13 19:05:59   KG.KZ.Roll_nextAstroTimeEvent 14.10.2018 - 09:30
     2018-10-13 19:05:45   OG.KZ.Roll_lastPosValue 100
     2018-10-13 19:05:45   OG.KZ.Roll_nextAstroTimeEvent 14.10.2018 - 09:30
     2018-10-13 19:05:30   OG.SZ.Roll_lastPosValue 100
     2018-10-13 19:05:30   OG.SZ.Roll_nextAstroTimeEvent 14.10.2018 - 08:30
     2018-10-13 19:06:12   OG.WC.Roll_lastDelayPosValue 90
     2018-10-13 19:06:12   OG.WC.Roll_nextAstroTimeEvent 14.10.2018 - 08:00
     2018-10-01 20:37:12   lockOut         on
     2018-10-01 20:37:50   partyMode       on
     2018-10-13 09:39:27   room_ASC_Bad    OG.WC.Roll
     2018-10-13 09:39:27   room_ASC_Kueche EG.KU.Roll
     2018-10-13 09:39:27   room_ASC_Marvin OG.KZ.Roll
     2018-10-13 09:39:27   room_ASC_Patrick KG.KZ.Roll
     2018-10-13 09:39:27   room_ASC_Schlafen OG.SZ.Roll
     2018-10-13 09:39:27   room_ASC_Wohnen EG.WZ.Roll
     2018-10-11 20:44:20   selfDefence     off
     2018-10-13 09:39:27   state           active
     2018-10-08 18:25:48   sunriseTimeWeHoliday on
     2018-10-13 09:39:27   userAttrList    rolled out
   helper:
     shuttersList:
       EG.KU.Roll
       EG.WZ.Roll
       KG.KZ.Roll
       OG.KZ.Roll
       OG.SZ.Roll
       OG.WC.Roll
   monitoredDevs:
     EG.KU.TFK.re:
       EG.KU.Roll ASC_WindowRec
     EG.WZ.TFK.li:
       EG.WZ.Roll ASC_WindowRec
     EG.WZ.TFK.re:
       EG.WZ.Roll ASC_WindowRec
     KG.KZ.TFK.li:
       KG.KZ.Roll ASC_WindowRec
     KG.KZ.TFK.re:
       KG.KZ.Roll ASC_WindowRec
     OG.KZ.TFK.li:
       OG.KZ.Roll ASC_WindowRec
     OG.KZ.TFK.re:
       OG.KZ.Roll ASC_WindowRec
     OG.SZ.TFK.li:
       OG.SZ.Roll ASC_WindowRec
     OG.SZ.TFK.re:
       OG.SZ.Roll ASC_WindowRec
     OG.WC.TFK.re:
       OG.WC.Roll ASC_WindowRec
Attributes:
   ASC_antifreezeTemp 1
   ASC_autoAstroModeEvening HORIZON
   ASC_autoAstroModeEveningHorizon -4
   ASC_autoAstroModeMorning HORIZON
   ASC_autoAstroModeMorningHorizon -4
   ASC_autoShuttersControlEvening on
   ASC_autoShuttersControlMorning on
   ASC_brightnessMinVal 100
   ASC_sunElevationDevice Astro
   ASC_sunElevationReading SunAlt
   ASC_sunPosDevice Astro
   ASC_sunPosReading SunAz
   ASC_temperatureReading temperature
   ASC_temperatureSensor GA.TH
   icon       fts_shutter_automatic
   room       ASC
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 13 Oktober 2018, 21:33:48
du hast aber schon ein twostate Fensterkontakt? Weil Du was von gekippt erzählt hast
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Papaloewe am 13 Oktober 2018, 21:43:09
Ja, ist ein normaler HM-SEC-SC, welcher oben am Fensterflügel montiert ist.
Reagiert also mit "auf" auch beim Kippen.

Gerade fährt der Rolladen wieder von selber in Ventilate.
Er toggelt also zwischen ganz geschlossen und entilate automatisch hin und her.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 13 Oktober 2018, 21:48:11
Das ist mehr wie seltsam. Kommen denn irgendwelche Events zu dem Zeitpunkt vom Fensterkontakt?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 13 Oktober 2018, 21:52:38
Eigentlich dürfte er so gar nicht fahren, denn Du hast lockOut aktiv. Warum auch immer?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Papaloewe am 13 Oktober 2018, 22:15:31
sorry, das war das falsche list vom Rolladen:
Internals:
   CFGFN     
   DEF        20A2D5
   HMLAN1_MSGCNT 31
   HMLAN1_RAWMSG E20A2D5,0000,F26B83D8,FF,FFB6,0BA41020A2D5123ABC06010000
   HMLAN1_RSSI -74
   HMLAN1_TIME 2018-10-13 22:11:26
   HMUART_MSGCNT 30
   HMUART_RAWMSG 0501002E0BA41020A2D5123ABC06010000
   HMUART_RSSI -46
   HMUART_TIME 2018-10-13 22:11:26
   IODev      HMUART
   LASTInputDev HMLAN1
   MSGCNT     90
   NAME       EG.WZ.Roll
   NOTIFYDEV  global
   NR         110
   NTFY_ORDER 50-EG.WZ.Roll
   STATE      down
   TYPE       CUL_HM
   hmusb_MSGCNT 29
   hmusb_RAWMSG E20A2D5,0000,0C8EDC51,FF,FFC4,0BA41020A2D5123ABC06010000
   hmusb_RSSI -60
   hmusb_TIME 2018-10-13 22:11:26
   lastMsg    No:0B - t:10 s:20A2D5 d:123ABC 06010000
   protLastRcv 2018-10-13 22:11:26
   protRcv    32 last_at:2018-10-13 22:11:26
   protSnd    32 last_at:2018-10-13 22:11:26
   protState  CMDs_done
   rssi_HMLAN1 cnt:1 min:-78 max:-78 avg:-78 lst:-78
   rssi_HMUART cnt:20 min:-49 max:-44 avg:-46.15 lst:-46
   rssi_at_HMLAN1 cnt:31 min:-76 max:-70 avg:-73.16 lst:-74
   rssi_at_HMUART cnt:30 min:-49 max:-42 avg:-45.8 lst:-46
   rssi_at_hmusb cnt:29 min:-75 max:-60 avg:-62.55 lst:-60
   rssi_hmusb cnt:1 min:-62 max:-62 avg:-62 lst:-62
   Helper:
     DBLOG:
       state:
         myDbLog:
           TIME       1539461486.41909
           VALUE      down
   OLDREADINGS:
   READINGS:
     2018-10-13 19:06:20   ASC_Time_DriveDown 14.10.2018 - 19:05
     2018-10-13 19:06:20   ASC_Time_DriveUp 14.10.2018 - 08:00
     2018-10-13 22:11:11   CommandAccepted yes
     2018-09-18 09:47:08   D-firmware      2.11
     2018-09-18 09:47:08   D-serialNr      KEQ0154684
     2018-09-16 17:32:11   PairedTo        0x123ABC
     2018-09-16 17:29:57   R-confBtnTime   permanent
     2018-09-16 17:29:58   R-driveDown     29 s
     2018-09-16 17:29:58   R-driveTurn     0.5 s
     2018-09-16 17:29:58   R-driveUp       31 s
     2018-09-16 17:29:57   R-intKeyVisib   invisib
     2018-09-16 17:29:57   R-localResDis   off
     2018-09-16 17:29:57   R-pairCentral   0x123ABC
     2018-09-16 17:29:58   R-powerUpAction off
     2018-09-16 17:29:58   R-refRunCounter 0
     2018-09-16 17:29:58   R-sign          off
     2018-09-16 17:29:58   R-statusInfoMinDly 3 s
     2018-09-16 17:29:58   R-statusInfoRandom 0 s
     2018-09-16 17:29:58   R-transmitTryMax 6
     2018-10-13 22:11:26   deviceMsg       off (to vccu)
     2018-10-13 22:11:26   level           0
     2018-10-13 22:11:26   motor           stop:off
     2018-10-13 22:11:26   pct             0
     2018-10-13 22:11:26   recentStateType info
     2018-10-13 22:11:26   state           off
     2018-10-13 22:11:26   timedOn         off
   helper:
     HM_CMDNR   11
     cSnd       11123ABC20A2D502013C,11123ABC20A2D5020100
     dlvlCmd    ++A011123ABC20A2D5020100
     mId        006A
     regLst     ,0,1,3p
     rxType     1
     supp_Pair_Rep 0
     ack:
     dir:
       cur        stop
       rct        down
     expert:
       def        1
       det        1
       raw        0
       tpl        0
     io:
       newChn     +20A2D5,00,01,00
       nextSend   1539461486.47483
       prefIO     
       rxt        0
       vccu       vccu
       p:
         20A2D5
         00
         01
         00
     mRssi:
       mNo        0B
       io:
         HMLAN1:
           -74
           -74
         HMUART:
           -38
           -38
         hmusb:
           -60
           -60
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       prs        1
     rpt:
       IO         HMUART
       flg        A
       ts         1539461486.38677
       ack:
         HASH(0x58cf138)
         0B8002123ABC20A2D500
     rssi:
       HMLAN1:
         avg        -78
         cnt        1
         lst        -78
         max        -78
         min        -78
       HMUART:
         avg        -46.15
         cnt        20
         lst        -46
         max        -44
         min        -49
       at_HMLAN1:
         avg        -73.1612903225806
         cnt        31
         lst        -74
         max        -70
         min        -76
       at_HMUART:
         avg        -45.8
         cnt        30
         lst        -46
         max        -42
         min        -49
       at_hmusb:
         avg        -62.5517241379311
         cnt        29
         lst        -60
         max        -60
         min        -75
       hmusb:
         avg        -62
         cnt        1
         lst        -62
         max        -62
         min        -62
     shadowReg:
     tmpl:
Attributes:
   ASC        2
   ASC_Antifreeze off
   ASC_AutoAstroModeEvening none
   ASC_AutoAstroModeEveningHorizon none
   ASC_AutoAstroModeMorning none
   ASC_AutoAstroModeMorningHorizon none
   ASC_Closed_Pos 0
   ASC_Direction 178
   ASC_Down   astro
   ASC_GuestRoom none
   ASC_Mode_Down always
   ASC_Mode_Up always
   ASC_Offset_Minutes_Evening 1
   ASC_Offset_Minutes_Morning 1
   ASC_Open_Pos 100
   ASC_Partymode off
   ASC_Pos_Cmd pct
   ASC_Pos_after_ComfortOpen 80
   ASC_Rand_Minutes 20
   ASC_Roommate_Device none
   ASC_Roommate_Reading state
   ASC_Shading off
   ASC_Shading_Angle_Left 85
   ASC_Shading_Angle_Right 85
   ASC_Shading_BlockingTime_After_Manual 20
   ASC_Shading_BlockingTime_Twilight 45
   ASC_Shading_Brightness_Reading brightness
   ASC_Shading_Brightness_Sensor none
   ASC_Shading_Fast_Close none
   ASC_Shading_Fast_Open none
   ASC_Shading_Min_Elevation none
   ASC_Shading_Min_OutsideTemperature 18
   ASC_Shading_Pos 0
   ASC_Shading_Pos_after_Shading -1
   ASC_Shading_StateChange_Cloudy 4000
   ASC_Shading_StateChange_Sunny 6000
   ASC_Shading_WaitingPeriod 20
   ASC_Time_Down_Early 16:30
   ASC_Time_Down_Late 23:00
   ASC_Time_Up_Early 06:00
   ASC_Time_Up_Late 08:00
   ASC_Time_Up_WE_Holiday 08:00
   ASC_Up     astro
   ASC_Ventilate_Pos 30
   ASC_Ventilate_Window_Open on
   ASC_WindowRec EG.WZ.TFK.li,EG.WZ.TFK.re
   ASC_WindowRec_subType twostate
   ASC_lock-out soft
   ASC_lock-outCmd none
   IODev      HMUART
   IOgrp      vccu
   Rolladen   Roll
   autoReadReg 5_readMissing
   cmdIcon    up:fts_shutter_up down:fts_shutter_down half:fts_shutter_50 stop:stop2
   devStateIcon set_.*:fts_shutter_updown@red up:fts_shutter_10 down:fts_shutter_100 half:fts_shutter_50 100:fts_shutter_100 9\d.*:fts_shutter_10 8\d.*:fts_shutter_20 7\d.*:fts_shutter_30 6\d.*:fts_shutter_40 5\d.*:fts_shutter_50 4\d.*:fts_shutter_60 3\d.*:fts_shutter_70 2\d.*:fts_shutter_80 1\d.*:fts_shutter_90 0:fts_shutter_10
   event-on-change-reading state
   eventMap   on:up off:down pct 50:half
   expert     1_allReg
   firmware   2.11
   group      Rolladen
   model      HM-LC-Bl1PBU-FM
   peerIDs    00000000,
   room       ASC,Wohnen
   serialNr   KEQ0154684
   subType    blindActuator
   userattr   ASC_Antifreeze:off,on ASC_AutoAstroModeEvening:REAL,CIVIL,NAUTIC,ASTRONOMIC,HORIZON ASC_AutoAstroModeEveningHorizon:-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9 ASC_AutoAstroModeMorning:REAL,CIVIL,NAUTIC,ASTRONOMIC,HORIZON ASC_AutoAstroModeMorningHorizon:-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9 ASC_Closed_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_Direction ASC_Down:time,astro ASC_GuestRoom:on,off ASC_Mode_Down:absent,always,off ASC_Mode_Up:absent,always,off ASC_Offset_Minutes_Evening ASC_Offset_Minutes_Morning ASC_Open_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_Partymode:on,off ASC_Pos_Cmd ASC_Pos_after_ComfortOpen:0,10,20,30,40,50,60,70,80,90,100 ASC_Rand_Minutes ASC_Roommate_Device ASC_Roommate_Reading ASC_Shading:on,off,delayed,present,absent ASC_Shading_Angle_Left:0,5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90 ASC_Shading_Angle_Right:0,5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90 ASC_Shading_BlockingTime_After_Manual ASC_Shading_BlockingTime_Twilight ASC_Shading_Brightness_Reading ASC_Shading_Brightness_Sensor ASC_Shading_Fast_Close:on,off ASC_Shading_Fast_Open:on,off ASC_Shading_Min_Elevation ASC_Shading_Min_OutsideTemperature ASC_Shading_Pos:10,20,30,40,50,60,70,80,90,100 ASC_Shading_Pos_after_Shading:-1,0,10,20,30,40,50,60,70,80,90,100 ASC_Shading_StateChange_Cloudy ASC_Shading_StateChange_Sunny ASC_Shading_WaitingPeriod ASC_Time_Down_Early ASC_Time_Down_Late ASC_Time_Up_Early ASC_Time_Up_Late ASC_Time_Up_WE_Holiday ASC_Up:time,astro ASC_Ventilate_Pos:10,20,30,40,50,60,70,80,90,100 ASC_Ventilate_Window_Open:on,off ASC_WindowRec ASC_WindowRec_subType:twostate,threestate ASC_lock-out:soft,hard ASC_lock-outCmd:inhibit,blocked AutoShutters7Control_Shading_WaitingPeriod AutoShuttersControl_Antifreeze:off,morning AutoShuttersControl_Pos_after_ComfortOpen:-2,-1,0,10,20,30,40,50,60,70,80,90,100 AutoShuttersControl_lock-out:on,off Rolladen Rolladen_map room_map structexclude
   webCmd     up:down:half:stop:pct
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Papaloewe am 13 Oktober 2018, 22:17:37
und hier noch der List des Fenstekontaktes:
Internals:
   CFGFN     
   DEF        56B2CB
   HMLAN1_MSGCNT 35
   HMLAN1_RAWMSG E56B2CB,0000,F24FB12E,FF,FFAA,D1A61056B2CB123ABC0601C800
   HMLAN1_RSSI -86
   HMLAN1_TIME 2018-10-13 21:41:03
   HMUART_MSGCNT 39
   HMUART_RAWMSG 05010040D1A61056B2CB123ABC0601C800
   HMUART_RSSI -64
   HMUART_TIME 2018-10-13 21:41:03
   IODev      HMUART
   LASTInputDev HMLAN1
   MSGCNT     112
   NAME       EG.WZ.TFK.li
   NOTIFYDEV  global
   NR         518
   NTFY_ORDER 50-EG.WZ.TFK.li
   STATE      auf
   TYPE       CUL_HM
   hmusb_MSGCNT 38
   hmusb_RAWMSG E56B2CB,0000,0C730A92,FF,FFB0,D1A61056B2CB123ABC0601C800
   hmusb_RSSI -80
   hmusb_TIME 2018-10-13 21:41:03
   lastMsg    No:D1 - t:10 s:56B2CB d:123ABC 0601C800
   peerList   EG.WZ.HZ_WindowRec,
   protLastRcv 2018-10-13 21:41:03
   protRcv    47 last_at:2018-10-13 21:41:03
   protRcvB   16 last_at:2018-10-13 20:28:27
   protSnd    31 last_at:2018-10-13 21:41:03
   protState  CMDs_done
   rssi_at_HMLAN1 cnt:35 min:-106 max:-82 avg:-88.14 lst:-86
   rssi_at_HMUART cnt:39 min:-77 max:-58 avg:-65.3 lst:-64
   rssi_at_hmusb cnt:38 min:-83 max:-65 avg:-73.81 lst:-80
   Helper:
     DBLOG:
       battery:
         myDbLog:
           TIME       1539459663.27707
           VALUE      ok
       state:
         myDbLog:
           TIME       1539459663.27707
           VALUE      auf
   READINGS:
     2018-10-13 09:39:22   Activity        alive
     2018-02-24 17:17:06   CommandAccepted yes
     2018-02-24 17:17:44   D-firmware      1.0
     2018-02-24 17:17:44   D-serialNr      OEQ0223451
     2018-02-24 17:17:45   PairedTo        0x123ABC
     2018-02-24 17:10:53   R-EG.WZ.HZ_WindowRec-expectAES off
     2018-02-24 17:10:53   R-EG.WZ.HZ_WindowRec-peerNeedsBurst on
     2018-02-17 13:15:35   R-cyclicInfoMsg on
     2018-02-24 17:17:46   R-eventDlyTime  20 s
     2018-02-24 17:17:46   R-msgScPosA     open
     2018-02-24 17:17:46   R-msgScPosB     closed
     2018-02-17 13:29:44   R-pairCentral   0x123ABC
     2018-02-17 13:15:35   R-sabotageMsg   on
     2018-02-24 17:17:46   R-sign          on
     2018-02-17 13:15:35   R-transmDevTryMax 6
     2018-02-24 17:17:46   R-transmitTryMax 6
     2018-02-24 17:17:06   aesCommToDev    ok
     2018-02-24 17:17:06   aesKeyNbr       00
     2018-10-13 21:41:03   alive           yes
     2018-10-13 21:41:03   battery         ok
     2018-10-13 21:41:03   contact         open (to vccu)
     2018-10-13 09:39:22   peerList        EG.WZ.HZ_WindowRec,
     2018-08-22 19:41:15   powerOn         2018-08-22 19:41:15
     2018-10-13 21:41:03   recentStateType info
     2018-02-17 13:29:46   sabotageAttack_ErrIoAttack cnt 1
     2018-10-13 21:41:03   sabotageError   off
     2018-10-13 21:41:03   state           open
     2018-02-24 16:27:48   trigDst_EG.WZ.HZ_Unit noConfig
     2018-10-13 20:28:28   trigger_cnt     176
   helper:
     HM_CMDNR   209
     mId        00C7
     regLst     ,0,1,4p
     rxType     28
     supp_Pair_Rep 0
     ack:
     expert:
       def        1
       det        1
       raw        0
       tpl        0
     io:
       newChn     +56B2CB,00,01,00
       nextSend   1539459663.30701
       prefIO     
       rxt        2
       vccu       vccu
       p:
         56B2CB
         00
         01
         00
     mRssi:
       mNo        D1
       io:
         HMLAN1:
           -86
           -86
         HMUART:
           -60
           -60
         hmusb:
           -80
           -80
     prt:
       bErr       0
       sProc      0
       sleeping   0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
     rpt:
       IO         HMUART
       flg        A
       ts         1539459663.21271
       ack:
         HASH(0xd5ab5f0)
         D18002123ABC56B2CB00
     rssi:
       at_HMLAN1:
         avg        -88.1428571428571
         cnt        35
         lst        -86
         max        -82
         min        -106
       at_HMUART:
         avg        -65.3076923076923
         cnt        39
         lst        -64
         max        -58
         min        -77
       at_hmusb:
         avg        -73.8157894736842
         cnt        38
         lst        -80
         max        -65
         min        -83
     shadowReg:
     tmpl:
Attributes:
   Fenster    TFK_FG
   IODev      HMUART
   IOgrp      vccu
   actCycle   002:50
   actStatus  alive
   autoReadReg 0_off
   devStateIcon auf:fts_window_2w_open_l@red zu:fts_window_2w@green
   event-on-change-reading state
   event-on-update-reading state,battery
   eventMap   closed:zu open:auf
   expert     1_allReg
   firmware   1.0
   group      Türen
   model      HM-SEC-SCo
   peerIDs    00000000,21CCA103,
   room       Wohnen
   serialNr   OEQ0223451
   subType    threeStateSensor
   userattr   Fenster Fenster_map structexclude
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 13 Oktober 2018, 22:22:34
Dennoch ist im Moduldevice lockOut und PartyMode auf on

Und gibt es nun Events in FHEM wenn der Rolladen fährt? Wenn müssten Events vom Fensterkontakt kommen

Beim Fensterkontakt ist das hier Unsinn
event-on-change-reading state
event-on-update-reading state,battery


Wenn dann
event-on-change-reading state
event-on-update-reading battery
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Papaloewe am 13 Oktober 2018, 23:16:25
Ok, da hast du recht.

Ich sehe gerade beim List des UM Fensterkontakt steht unter subtype threestatesensor?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 13 Oktober 2018, 23:17:59
Zitat von: Papaloewe am 13 Oktober 2018, 23:16:25
Ok, da hast du recht.

Ich sehe gerade beim List des UM Fensterkontakt steht unter subtype threestatesensor?

Das wird vom Modul nicht beachtet. Entscheidend ist was du als Attribut beim Rolladen hinterlegst.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Papaloewe am 14 Oktober 2018, 21:26:38
Zitat von: CoolTux am 13 Oktober 2018, 22:22:34

Beim Fensterkontakt ist das hier Unsinn
event-on-change-reading state
event-on-update-reading state,battery


Wenn dann
event-on-change-reading state
event-on-update-reading battery

Ja das war's, sorry und danke für den Hinweis!
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 15 Oktober 2018, 06:21:45
Ich habe am Wochenende die neue Version getestet. Sieht gut aus.
Hier könnt sie Euch über GitHub runterladen.

Neu ist das die Rolläden bei SelfDefense nach dem nach Hause kommen wieder in ihre alte Stellung fahren.

SelfDevence kann pro Rolladen gesteuert werden Attr ASC_Self_Devence_Exclude on/off bei on wird SelfDevence nicht angewand.

Das öffnen und schließen Morgens und Abends kann per Brightness konfiguriert werden.
Dazu muss im Moduldevice Attr ASC_brightnessMinVal gesetzt werden. Desweiteren muss korrekt
ASC_Time_Down_Early
ASC_Time_Down_Late
ASC_Time_Up_Early
ASC_Time_Up_Late
korrekt gesetzt werden. Und nur zwischen Down_Early und Down_Late wird die Brightness aus gewertet und wenn drunter dann runter gefahren Abends und wenn drüber dann hoch gefahren Morgens.

Und ich habe den einen oder anderen kleinen Bug gefixt.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Papaloewe am 15 Oktober 2018, 17:03:26
Bin wahrscheinlich gerade mal wieder blind, aber wo gebe ich das Device und das Reading für Brightness an?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 15 Oktober 2018, 17:09:36
Commandref bitte lesen.
Device im Rolläden und Brightness Wert im ASC Device.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: FunkOdyssey am 15 Oktober 2018, 17:32:19
Zitat von: CoolTux am 15 Oktober 2018, 06:21:45

Das öffnen und schließen Morgens und Abends kann per Brightness konfiguriert werden.
Dazu muss im Moduldevice Attr ASC_brightnessMinVal gesetzt werden. Desweiteren muss korrekt
ASC_Time_Down_Early
ASC_Time_Down_Late
ASC_Time_Up_Early
ASC_Time_Up_Late
korrekt gesetzt werden. Und nur zwischen Down_Early und Down_Late wird die Brightness aus gewertet und wenn drunter dann runter gefahren Abends und wenn drüber dann hoch gefahren Morgens.

Vielen Dank. Aber soll der Helligkeitswert (via ASC_brightnessMinVal) wirklich nur im Modul hinterlegt werden? Kann ich das gar nicht je Jalousie steuern?
So gibt es doch nun keine Möglichkeit mehr, das Hoch- und Runterfahren zu entzerren, oder? Ich fahre bspw. die Jalousien in einigen sensiblen Bereichen (Gäste-WC, einsehbare Räume) bereits bei einer geringeren Dämmerung runter.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 15 Oktober 2018, 17:38:46
Keine Ahnung. Kann mich da an keine genaue Anforderung erinnern  ;D
Sollte aber nicht so das Problem sein da noch was ein zu bauen. Ist ja vielleicht auch für die Beschattung ganz gut.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: hexenmeister am 16 Oktober 2018, 07:26:41
Ich denke auch, dass getrennte Angaben für die Grenzhelligkeit sinnvoll ist. Es sind nicht nur Räume, wie WC/Bad, es sind auch unterschiedliche Lichtsituationen in Räumen. So wird in einem Raum oft schneller dunkler, weil z.B. vor dem Fenster ein Baum steht.

Noch eine Idee wäre, Rollläden früher zu schliessen, wenn im betroffenen Raum Licht angeht. Das könnte gleich auf Arten überwacht werden: rauminterne Lichtsensoren und Readings der Lampenaktoren. Halte Unterstützung für beides gleichzeitig für sinnvoll.
Ist natürlich nur ein Vorschlag, bei der Vielzahl der unterschiedlichen Einsatzszenarien kann man sich sicher vieles einfallen lassen ;)
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 16 Oktober 2018, 08:24:40
Zitat von: hexenmeister am 16 Oktober 2018, 07:26:41
Noch eine Idee wäre, Rollläden früher zu schliessen, wenn im betroffenen Raum Licht angeht. Das könnte gleich auf Arten überwacht werden: rauminterne Lichtsensoren und Readings der Lampenaktoren. Halte Unterstützung für beides gleichzeitig für sinnvoll.
Ist natürlich nur ein Vorschlag, bei der Vielzahl der unterschiedlichen Einsatzszenarien kann man sich sicher vieles einfallen lassen ;)

Darüber können wir uns dann gerne zu einem späteren Zeitpunkt unterhalten. Die Idee finde ich gut.
Jetzt baue ich erstmal noch die Brightness Werte pro Rolladen ein und dann testen wir erstmal ausgiebig. Danach wird die Abschattung in Angriff genommen.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: FunkOdyssey am 16 Oktober 2018, 09:33:21
Ick freu mir wie Bolle
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: hexenmeister am 16 Oktober 2018, 09:38:35
Zitat von: CoolTux am 16 Oktober 2018, 08:24:40
Darüber können wir uns dann gerne zu einem späteren Zeitpunkt unterhalten. Die Idee finde ich gut.

Sehe ich auch so. Schritt nach Schritt und nicht überstürzen :D
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 16 Oktober 2018, 10:33:08
neue Version 0.1.80 habe ich soeben ins Git geladen. Nun kann man auch am Rolladen selbst die Brightness einstellen.


Grüße
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: sledge am 16 Oktober 2018, 17:55:08
Zitat von: CoolTux am 16 Oktober 2018, 08:24:40
Darüber können wir uns dann gerne zu einem späteren Zeitpunkt unterhalten. Die Idee finde ich gut.
Jetzt baue ich erstmal noch die Brightness Werte pro Rolladen ein und dann testen wir erstmal ausgiebig. Danach wird die Abschattung in Angriff genommen.

Als eifriger Nutzer von Clunis Lösung fällt mir zur Abschattung folgendes ein: Ich selber verwende keine Helligkeitssensoren, ein Abschattung rein basierend auf Azimut und Elevation wäre ein Feature, das ich mir gut vorstellen kann. Als "Basisvariante" sozusagen.

Andere Frage:
Ab wann - so die Frage - lohnt sich denn für einen produktiven Nutzer von Clunis Lösung der Umstieg, um sinnvoll zu den Tests beitragen zu können? Zugegeben verfolge ich den Thread nur mit einem Auge, aber wüsste noch nicht, ob der Umstieg jetzt schon sinnvoll ist.

Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 16 Oktober 2018, 18:07:02
Das kannst eigentlich nur Du selbst wissen.
Wenn alle Features die Du über den Winter brauchst bereits enthalten sind kannst Du gerne mit testen. Abschattung dürfte ja so langsam nicht mehr aktuell sein bis zum Frühling.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: C0mmanda am 16 Oktober 2018, 19:06:48
Zitat von: CoolTux am 16 Oktober 2018, 18:07:02
Das kannst eigentlich nur Du selbst wissen.
Wenn alle Features die Du über den Winter brauchst bereits enthalten sind kannst Du gerne mit testen. Abschattung dürfte ja so langsam nicht mehr aktuell sein bis zum Frühling.

Würde ich nur bedingt so unterschreiben.
Mein "Arbeitsplatz" liegt am Fenster und die tiefstehende Herbst-/Wintersonne blendet dermaßen das eine Abschattung auch im Winter sinnvoll sein kann.

Zitat von: sledge am 16 Oktober 2018, 17:55:08
Andere Frage:
Ab wann - so die Frage - lohnt sich denn für einen produktiven Nutzer von Clunis Lösung der Umstieg, um sinnvoll zu den Tests beitragen zu können? Zugegeben verfolge ich den Thread nur mit einem Auge, aber wüsste noch nicht, ob der Umstieg jetzt schon sinnvoll ist.

Diese Frage kann man sich am Ende immer nur selbst beantworten, ich finde den Stand aktuell aber so fortgeschritten das man es wagen kann.
Ich habe und teste das Modul im Produktiv-Einsatz.
Was kann schlimmstenfalls passieren? Ein Rolladen fährt / fährt nicht wie gewünscht. ;)
Ist aber nur meine Meinung....

Gruß
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: sledge am 17 Oktober 2018, 09:33:21
Zitat von: CoolTux am 16 Oktober 2018, 18:07:02
Das kannst eigentlich nur Du selbst wissen.
Wenn alle Features die Du über den Winter brauchst bereits enthalten sind kannst Du gerne mit testen. Abschattung dürfte ja so langsam nicht mehr aktuell sein bis zum Frühling.

;-)

In der Tat ist mit automatisch rauf / runter + Bewohnerstatus schonmal 80% dessen enthalten, was sich in den Tagesablauf so eingeschlichen hat. Ich setze mal ne Testinstanz auf und ziehe einzwei Rolladen rüber.

Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 17 Oktober 2018, 10:04:56
Einfach mal ein paar Entwicklernews am Rande.
Dank der OOP kann ich nun alle versteckten Readings aus den Rolladen Devices entfernen. Ich halte alle Informationen in Objekten fest. Das macht vieles einfacher.
Unter anderem lastPos samt timestamp was sich auf die letzte Position bezieht bevor ASC eine Änderung gemacht hat. Deweiteren habe ich vor so langsam die Rolladen Devices in die NOTIFYDEV mit auf zu nehmen und sobald eine Stellungsänderung der Rolladen stattgefunden hat und diese nicht vom ASC selbst kam die aktuelle Stellung in lastManuPos zu schreiben. Somit haben wir schon mal wichtige Informationen zum Rolladen und seiner Position vor und nachher.



Grüße
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: hexenmeister am 17 Oktober 2018, 11:28:18
Zitat von: CoolTux am 17 Oktober 2018, 10:04:56
Ich halte alle Informationen in Objekten fest. Das macht vieles einfacher.

Stellst Du irgendwie sicher, dass bei einem FHEM-Neustart die Infos nicht verloren gehen?
In Readings sind sie ja automatisch in statefile...
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 17 Oktober 2018, 11:53:15
Da diese Infos bisher auch nur temporär genutzt wurden da sie immer zurük gesetzt wurden bei einem Neustart ist das erstmal nicht so wichtig.
Bei bedarf kann man gerne darüber nachdenken diese Infos bei einem Neustart weg zu schreiben. So lange FHEM läuft und ein Verweiß auf das Objekt vorhanden ist bleiben die Daten jedenfalls erhalten.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: FunkOdyssey am 17 Oktober 2018, 12:11:17
Ich habe gestern Abend die ersten Jalousien über die Brightness-Werte gesteuert.
Funktioniert wie es soll. Gefällt mir gut.
Ich würde mir wünschen, wenn man im ASC-Log ein wenig mehr Infos über das hätte, was gerade wirklich passiert.
Man kann nicht wirklich erkennen, dass die Jalousien gerade runtergefahren sind, weil:
- Astro-Zeitpunkt erreicht,
- Feste Uhrzeit erreicht
- oder ein Helligkeitswert erreicht wurde.




Ich habe die (neue) CommandRef gelesen und mich versucht über die ASC_brightnessMinVal und ASC_brightnessMaxVal zu informieren.
Im Quellcode erkenne ich nur Abhängigkeiten zu MinVal. Aber die Jalousien sind beim Unterschreiten von MaxVal heruntergefahren.
Das Hochfahren habe ich aktuell nicht implementiert.

Unabhängig davon sind mir die Unterschiede zwischen den beiden Attributen noch nicht klar.




Ein Brightness-Sensor könnte ja auch kurzzeitig eine Schwelle unter- bzw. überschreiten, falls bspw. eine größere Wolkenfront kommt.
Besteht irgendwie die Möglichkeit, dass erst nach zweifacher Unterschreitung oder nach einem Wartezeitraum von x Sekunden die Jalousien gefahren werden?
Ich glaube zwar, dass es in der Praxis nicht oft passieren wird, aber die Steuerung könnte sonst theoretisch ein wenig sensibel reagieren und auslösen.

Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 17 Oktober 2018, 12:31:09
Zitat von: FunkOdyssey am 17 Oktober 2018, 12:11:17
Ich habe gestern Abend die ersten Jalousien über die Brightness-Werte gesteuert.
Funktioniert wie es soll. Gefällt mir gut.
Ich würde mir wünschen, wenn man im ASC-Log ein wenig mehr Infos über das hätte, was gerade wirklich passiert.
Man kann nicht wirklich erkennen, dass die Jalousien gerade runtergefahren sind, weil:
- Astro-Zeitpunkt erreicht,
- Feste Uhrzeit erreicht
- oder ein Helligkeitswert erreicht wurde.


Es sollte sich eigentlich aus der Logik heraus ergeben, da man nur eines der 3 Trigger wählen kann. Du sagst ja im Attribut
ASC_Down - astro/time/brightness
Kannst also nur eines der 3 Methoden expliziet auswählen.

Zitat von: FunkOdyssey am 17 Oktober 2018, 12:11:17
Ich habe die (neue) CommandRef gelesen und mich versucht über die ASC_brightnessMinVal und ASC_brightnessMaxVal zu informieren.
Im Quellcode erkenne ich nur Abhängigkeiten zu MinVal. Aber die Jalousien sind beim Unterschreiten von MaxVal heruntergefahren.
Das Hochfahren habe ich aktuell nicht implementiert.

Unabhängig davon sind mir die Unterschiede zwischen den beiden Attributen noch nicht klar.

In der derzeitigen Umsetzung wird lediglich MinVal verwendet. Daher würde es mich auch schwer wundern wenn Deine Rollos bei unterschreitung von MaxVal gefahren sind es sei denn die beiden Werte sind gleich oder MaxVal war kleiner wie MinVal

Zitat von: FunkOdyssey am 17 Oktober 2018, 12:11:17
Ein Brightness-Sensor könnte ja auch kurzzeitig eine Schwelle unter- bzw. überschreiten, falls bspw. eine größere Wolkenfront kommt.
Besteht irgendwie die Möglichkeit, dass erst nach zweifacher Unterschreitung oder nach einem Wartezeitraum von x Sekunden die Jalousien gefahren werden?
Ich glaube zwar, dass es in der Praxis nicht oft passieren wird, aber die Steuerung könnte sonst theoretisch ein wenig sensibel reagieren und auslösen.

Über eine Art Schwelle habe ich mir auch schon Gedanken gemacht. Verwendest Du Aussen oder Innensensoren für Brightness?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: hexenmeister am 17 Oktober 2018, 12:47:05
Zitat von: CoolTux am 17 Oktober 2018, 11:53:15
Da diese Infos bisher auch nur temporär genutzt wurden da sie immer zurük gesetzt wurden bei einem Neustart ist das erstmal nicht so wichtig.
Bei bedarf kann man gerne darüber nachdenken diese Infos bei einem Neustart weg zu schreiben. So lange FHEM läuft und ein Verweiß auf das Objekt vorhanden ist bleiben die Daten jedenfalls erhalten.
In den Fällen, wo man die Daten rekostruieren kann, ist das ja völlig ok.
Es wäre nur wichtig, dass bei einem Restart die Rolladen-Logik genauso weiter bleibt, wie ohne Restart :)
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: hexenmeister am 17 Oktober 2018, 12:50:33
Bei den Helligkeitswerten müsste man das Problem mit kurzzeitigen Beleuchtung (Autoscheinwerfen etc.) ggf. durch Ermitteln vom Mittelwerden (kurzzeitigen 'Spitzen' ignorieren) und mit einer Hysterese (Wert zum Hochfahren etwas über dem Wert zum Herunterfahren und eine gewisse 'tote Zone' dazwischen) in Griff bekommen können.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: FunkOdyssey am 17 Oktober 2018, 12:58:36
So ähnlich mache ich das aktuell auch schon.
Ich habe einen Mittelwert verschiedener HM-Bewegungsmelder.
Threshold oder Histerese brauche ich bei den nicht berücksichtigen, da dies bereits in der Hardware abgefangen wird.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: hexenmeister am 17 Oktober 2018, 13:49:10
Zitat von: FunkOdyssey am 17 Oktober 2018, 12:58:36
Threshold oder Histerese brauche ich bei den nicht berücksichtigen, da dies bereits in der Hardware abgefangen wird.
Im allgemeinverwendbaren Modul wäre dies hingegen schon notwendig ;)
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: FunkOdyssey am 17 Oktober 2018, 14:25:34
Zitat von: CoolTux am 17 Oktober 2018, 12:31:09
In der derzeitigen Umsetzung wird lediglich MinVal verwendet. Daher würde es mich auch schwer wundern wenn Deine Rollos bei unterschreitung von MaxVal gefahren sind es sei denn die beiden Werte sind gleich oder MaxVal war kleiner wie MinVal

Genau so sagt es auch die Programmierung.
Aber dennoch sind die Jalousien gestern bei MaxVal heruntergefahren. Aber: Das scheint ein Zufall zu sein, denn die Astro-Zeit lag auch exakt zu diesem Zeitpunkt. Sehr unwahrscheinlich, aber wahr. Das ist auch der Grund wieso ich nach mehr Infos im Log gefragt habe. :-)

Ich habe nun tatsächlich feststellt, dass meine ASC_Up | ASC_Down Konfiguration wieder überschrieben war. Ich hatte es bewusst von "astro" auf "brightness" gesetzt. Und gerade stand es wieder auf "astro". Vermutlich habe ich irgendetwas nicht gespeichert oder vielleicht durch ne ReadingsGroup wieder überschrieben. Komisch komisch.

Sorry für die Unruhe :-)
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 17 Oktober 2018, 16:00:03
Lieber einmal mehr Unruhe wie keine Eindeutige Funktion. Von daher alles schick.


Grüße
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: FunkOdyssey am 18 Oktober 2018, 10:24:27
Es mag vielleicht auch unglücklich sein, dass meine Brightness-Schwelle und die Astro-Zeit so nah beinanderliegen.
Aber: Trotz gewollter Brightness-Steuerung wurde nicht darüber runtergefahren.


2018-10-17_08:03:18 Rolladensteuerung jal_kind1_nextAstroTimeEvent: 17.10.2018 - 18:31
2018-10-17_08:03:29 Rolladensteuerung jal_kind2_nextAstroTimeEvent: 17.10.2018 - 18:29
2018-10-17_08:03:40 Rolladensteuerung jal_buegeln_nextAstroTimeEvent: 17.10.2018 - 18:30
2018-10-17_08:03:41 Rolladensteuerung jal_bad_nextAstroTimeEvent: 17.10.2018 - 18:29
2018-10-17_11:04:48 Rolladensteuerung userAttrList: rolled out
2018-10-17_11:04:53 Rolladensteuerung jal_kind1_nextAstroTimeEvent: 17.10.2018 - 18:29
2018-10-17_11:04:53 Rolladensteuerung jal_bad_nextAstroTimeEvent: 17.10.2018 - 18:30
2018-10-17_11:04:53 Rolladensteuerung jal_buegeln_nextAstroTimeEvent: 17.10.2018 - 18:29
2018-10-17_11:04:53 Rolladensteuerung jal_kind2_nextAstroTimeEvent: 17.10.2018 - 18:29
2018-10-17_11:48:21 Rolladensteuerung userAttrList: rolled out
2018-10-17_11:48:25 Rolladensteuerung jal_kind1_nextAstroTimeEvent: 17.10.2018 - 18:30
2018-10-17_11:48:25 Rolladensteuerung jal_bad_nextAstroTimeEvent: 17.10.2018 - 18:30
2018-10-17_11:48:25 Rolladensteuerung jal_buegeln_nextAstroTimeEvent: 17.10.2018 - 18:29
2018-10-17_11:48:25 Rolladensteuerung jal_kind2_nextAstroTimeEvent: 17.10.2018 - 18:29
2018-10-17_18:29:14 Rolladensteuerung jal_kind2_lastPosValue: 0
2018-10-17_18:29:14 Rolladensteuerung jal_kind2_nextAstroTimeEvent: 17.10.2018 - 19:01
2018-10-17_18:29:33 Rolladensteuerung jal_buegeln_lastPosValue: 0
2018-10-17_18:29:33 Rolladensteuerung jal_buegeln_nextAstroTimeEvent: 17.10.2018 - 19:00
2018-10-17_18:30:34 Rolladensteuerung jal_kind1_lastPosValue: 0
2018-10-17_18:30:34 Rolladensteuerung jal_kind1_nextAstroTimeEvent: 17.10.2018 - 19:01
2018-10-17_18:30:58 Rolladensteuerung jal_bad_lastPosValue: 0
2018-10-17_18:30:58 Rolladensteuerung jal_bad_nextAstroTimeEvent: 17.10.2018 - 19:00
2018-10-17_19:00:01 Rolladensteuerung jal_bad_nextAstroTimeEvent: 18.10.2018 - 08:00
2018-10-17_19:00:56 Rolladensteuerung jal_buegeln_nextAstroTimeEvent: 18.10.2018 - 08:00
2018-10-17_19:01:06 Rolladensteuerung jal_kind1_nextAstroTimeEvent: 18.10.2018 - 08:00
2018-10-17_19:01:22 Rolladensteuerung jal_kind2_nextAstroTimeEvent: 18.10.2018 - 08:00
2018-10-18_08:00:04 Rolladensteuerung jal_kind1_nextAstroTimeEvent: 18.10.2018 - 19:00
2018-10-18_08:00:06 Rolladensteuerung jal_buegeln_nextAstroTimeEvent: 18.10.2018 - 19:01
2018-10-18_08:00:30 Rolladensteuerung jal_kind2_nextAstroTimeEvent: 18.10.2018 - 19:01
2018-10-18_08:00:43 Rolladensteuerung jal_bad_nextAstroTimeEvent: 18.10.2018 - 19:00
2018-10-18_08:49:51 Rolladensteuerung jal_buegeln_lastPosValue: 100
2018-10-18_08:49:51 Rolladensteuerung jal_kind1_lastPosValue: 100
2018-10-18_08:49:51 Rolladensteuerung jal_bad_lastPosValue: 100
2018-10-18_08:49:51 Rolladensteuerung jal_kind2_lastPosValue: 100
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 18 Oktober 2018, 10:33:20
Kannst Du mir bitte ein list vom ASC Device und von einem exenplarischen Rolladendevice geben.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: FunkOdyssey am 18 Oktober 2018, 11:31:14
Danke. Habe ich dir per E-Mail geschickt.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 18 Oktober 2018, 11:36:47
Alles klar. Ich teste das heute Abend einmal.

Grüße
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: cbl am 19 Oktober 2018, 11:53:58
Hallo,

dieses Modul wird die Übersichtlichkeit deutlich erhöhen und erfüllt mittlerweile einen großen Teil der über die Zeit zusammengekommenen Funktionen, die ich so gebastelt habe.

Eine Funktion in Verbindung mit "Holiday" habe ich noch nicht gefunden (oder im langen Thread übersehen):
Der Rolladen an meiner Terrassentür bleibt soll im Holiday-Modus unten bleiben (war ein deutlicher Tipp der Kripo). Dazu bräuchte der jeweilige Rolladen noch ein Reading, um auszudrücken, in welcher Position er im Holiday-Modus bleiben soll.

Gruß
Christian
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 19 Oktober 2018, 12:06:39
Das klingt wirklich gut. Problem bei der Sache ist nur, Holiday kann in unserem Fall auch Ferien sein oder Wochenende oder Urlaub. Alles was man in einer Holidaydatei so ein trägt.
Es gibt für Residents allerdings den state gone, das bedeutet so viel wie man ist bereits länger wie 36 Stunden weg. Eventuell kann man darauf aufbauen und ein Attribut schaffen welches man dann halt nur bei Terrassentüren setzt.
Was hälst Du davon?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: cbl am 19 Oktober 2018, 12:48:02
Hallo,

das passt. Mein Holiday-Status ist genau das, was du beschreibst.

Gruß
Christian
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Papaloewe am 19 Oktober 2018, 15:02:21
Ich würde gerne bei Abwesenheit eines Roomates den Rolladen gar nicht automatisch (herunter)fahren.
Leider ist bisher nur das Gegenteil implementiert, also nur bei Abwesenheit die Automatik zu steuern.
Wäre es möglich noch für die beiden Attribute "ASC_ModeUp" und "ASC_ModeDown" noch den Wert "present" zus. einzuführen?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Karflyer am 19 Oktober 2018, 15:05:12
Mir ist heute folgendes Verhalten aufgefallen. Ich habe bei einigen Rolladen-Devices das Attribut 'ASC_Up' auf dem Wert 'time' stehen. Damit sollen die Rolläden morgens über die Zeiteinstellungen und den roommate-Status gefahren werden. Das funktioniert auch bestens. Nach dem ich ein weiteres Rolladen-Device über 'scanForShutters' im ASC-Modul hinzugefügt hatte, stand das Attribut 'ASC_Up' bei allen Rolläden-Devices wieder auf 'astro'. Ich meine dieses Verhalten war auch nach dem einspielen einer neuen Modul-Version zu beobachten. Während die 'anderen' Attribute am Rolladen-Device auf dem eingestellten Wert bleiben, wird der Wert bei ASC_Up (vermutlich auch ASC_Down) auf den Standardwert zurückgestellt. Ich denke, das ist so nicht geplant.

Gruß
Stefan
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: FunkOdyssey am 19 Oktober 2018, 15:07:50
Jawohl, das ist auch der Grund meines ersten Fehlers. Bei mir wurde die Zeit- und Brightness-Auswahl damit auch wieder auf "astro|astro" gesetzt.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 19 Oktober 2018, 15:51:32
Zitat von: Karflyer am 19 Oktober 2018, 15:05:12
Mir ist heute folgendes Verhalten aufgefallen. Ich habe bei einigen Rolladen-Devices das Attribut 'ASC_Up' auf dem Wert 'time' stehen. Damit sollen die Rolläden morgens über die Zeiteinstellungen und den roommate-Status gefahren werden. Das funktioniert auch bestens. Nach dem ich ein weiteres Rolladen-Device über 'scanForShutters' im ASC-Modul hinzugefügt hatte, stand das Attribut 'ASC_Up' bei allen Rolläden-Devices wieder auf 'astro'. Ich meine dieses Verhalten war auch nach dem einspielen einer neuen Modul-Version zu beobachten. Während die 'anderen' Attribute am Rolladen-Device auf dem eingestellten Wert bleiben, wird der Wert bei ASC_Up (vermutlich auch ASC_Down) auf den Standardwert zurückgestellt. Ich denke, das ist so nicht geplant.

Gruß
Stefan

Das schaue ich mir gerne an.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 19 Oktober 2018, 15:52:08
Zitat von: Karflyer am 19 Oktober 2018, 15:05:12
Mir ist heute folgendes Verhalten aufgefallen. Ich habe bei einigen Rolladen-Devices das Attribut 'ASC_Up' auf dem Wert 'time' stehen. Damit sollen die Rolläden morgens über die Zeiteinstellungen und den roommate-Status gefahren werden. Das funktioniert auch bestens. Nach dem ich ein weiteres Rolladen-Device über 'scanForShutters' im ASC-Modul hinzugefügt hatte, stand das Attribut 'ASC_Up' bei allen Rolläden-Devices wieder auf 'astro'. Ich meine dieses Verhalten war auch nach dem einspielen einer neuen Modul-Version zu beobachten. Während die 'anderen' Attribute am Rolladen-Device auf dem eingestellten Wert bleiben, wird der Wert bei ASC_Up (vermutlich auch ASC_Down) auf den Standardwert zurückgestellt. Ich denke, das ist so nicht geplant.

Gruß
Stefan

Kann ich gerne einbauen.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Papaloewe am 19 Oktober 2018, 16:01:48
Zitat von: CoolTux am 19 Oktober 2018, 15:52:08
Kann ich gerne einbauen.

Bezog sich das auf meine Frage?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 19 Oktober 2018, 16:51:54
Zitat von: Papaloewe am 19 Oktober 2018, 16:01:48
Bezog sich das auf meine Frage?
Jepp
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 19 Oktober 2018, 20:09:50
Zitat von: FunkOdyssey am 18 Oktober 2018, 10:24:27
Es mag vielleicht auch unglücklich sein, dass meine Brightness-Schwelle und die Astro-Zeit so nah beinanderliegen.
Aber: Trotz gewollter Brightness-Steuerung wurde nicht darüber runtergefahren.


2018-10-17_08:03:18 Rolladensteuerung jal_kind1_nextAstroTimeEvent: 17.10.2018 - 18:31
2018-10-17_08:03:29 Rolladensteuerung jal_kind2_nextAstroTimeEvent: 17.10.2018 - 18:29
2018-10-17_08:03:40 Rolladensteuerung jal_buegeln_nextAstroTimeEvent: 17.10.2018 - 18:30
2018-10-17_08:03:41 Rolladensteuerung jal_bad_nextAstroTimeEvent: 17.10.2018 - 18:29
2018-10-17_11:04:48 Rolladensteuerung userAttrList: rolled out
2018-10-17_11:04:53 Rolladensteuerung jal_kind1_nextAstroTimeEvent: 17.10.2018 - 18:29
2018-10-17_11:04:53 Rolladensteuerung jal_bad_nextAstroTimeEvent: 17.10.2018 - 18:30
2018-10-17_11:04:53 Rolladensteuerung jal_buegeln_nextAstroTimeEvent: 17.10.2018 - 18:29
2018-10-17_11:04:53 Rolladensteuerung jal_kind2_nextAstroTimeEvent: 17.10.2018 - 18:29
2018-10-17_11:48:21 Rolladensteuerung userAttrList: rolled out
2018-10-17_11:48:25 Rolladensteuerung jal_kind1_nextAstroTimeEvent: 17.10.2018 - 18:30
2018-10-17_11:48:25 Rolladensteuerung jal_bad_nextAstroTimeEvent: 17.10.2018 - 18:30
2018-10-17_11:48:25 Rolladensteuerung jal_buegeln_nextAstroTimeEvent: 17.10.2018 - 18:29
2018-10-17_11:48:25 Rolladensteuerung jal_kind2_nextAstroTimeEvent: 17.10.2018 - 18:29
2018-10-17_18:29:14 Rolladensteuerung jal_kind2_lastPosValue: 0
2018-10-17_18:29:14 Rolladensteuerung jal_kind2_nextAstroTimeEvent: 17.10.2018 - 19:01
2018-10-17_18:29:33 Rolladensteuerung jal_buegeln_lastPosValue: 0
2018-10-17_18:29:33 Rolladensteuerung jal_buegeln_nextAstroTimeEvent: 17.10.2018 - 19:00
2018-10-17_18:30:34 Rolladensteuerung jal_kind1_lastPosValue: 0
2018-10-17_18:30:34 Rolladensteuerung jal_kind1_nextAstroTimeEvent: 17.10.2018 - 19:01
2018-10-17_18:30:58 Rolladensteuerung jal_bad_lastPosValue: 0
2018-10-17_18:30:58 Rolladensteuerung jal_bad_nextAstroTimeEvent: 17.10.2018 - 19:00
2018-10-17_19:00:01 Rolladensteuerung jal_bad_nextAstroTimeEvent: 18.10.2018 - 08:00
2018-10-17_19:00:56 Rolladensteuerung jal_buegeln_nextAstroTimeEvent: 18.10.2018 - 08:00
2018-10-17_19:01:06 Rolladensteuerung jal_kind1_nextAstroTimeEvent: 18.10.2018 - 08:00
2018-10-17_19:01:22 Rolladensteuerung jal_kind2_nextAstroTimeEvent: 18.10.2018 - 08:00
2018-10-18_08:00:04 Rolladensteuerung jal_kind1_nextAstroTimeEvent: 18.10.2018 - 19:00
2018-10-18_08:00:06 Rolladensteuerung jal_buegeln_nextAstroTimeEvent: 18.10.2018 - 19:01
2018-10-18_08:00:30 Rolladensteuerung jal_kind2_nextAstroTimeEvent: 18.10.2018 - 19:01
2018-10-18_08:00:43 Rolladensteuerung jal_bad_nextAstroTimeEvent: 18.10.2018 - 19:00
2018-10-18_08:49:51 Rolladensteuerung jal_buegeln_lastPosValue: 100
2018-10-18_08:49:51 Rolladensteuerung jal_kind1_lastPosValue: 100
2018-10-18_08:49:51 Rolladensteuerung jal_bad_lastPosValue: 100
2018-10-18_08:49:51 Rolladensteuerung jal_kind2_lastPosValue: 100


Ich habe versucht es nach zu vollziehen. Leider konnte ich Deine Beobachtung nicht teilen. Irgendwas fehlt uns da noch. Du hast mir auch ein list von ankleide zukommen lassen, hier im log sehe ich davon gar nichts.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: FunkOdyssey am 19 Oktober 2018, 21:27:29
Mein Code im Forum war verfremdet. Search&Replace.
Ich schicke dir noch ein richtiges Log per Mail.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 20 Oktober 2018, 10:00:31
Zitat von: FunkOdyssey am 19 Oktober 2018, 21:27:29
Mein Code im Forum war verfremdet. Search&Replace.
Ich schicke dir noch ein richtiges Log per Mail.

Ich habe das jetzt mal bei mir auch so eingestellt, mal schauen was heute Abend passiert. Einzig das max habe ich weg gelassen, das ist noch nicht nötig ein zu stellen.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 20 Oktober 2018, 16:31:28
@FunkOdyssey
Meine Rolläden sind bei 2000 wie eingestellt im Rolladen runter gefahren. Im ASC Device war 1000 eingestellt.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: FunkOdyssey am 20 Oktober 2018, 19:55:53
Ich schaffe es einfach nicht, den down-Wert auf Brightness zu belassen.
Ständig habe ich wieder "astro" im Attribut. Rekonstruierbar nach dem FHEM-Neustart.
Aber das passiert auch nach nem Scan-Durchlauf.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 20 Oktober 2018, 19:58:58
Zitat von: FunkOdyssey am 20 Oktober 2018, 19:55:53
Ich schaffe es einfach nicht, den down-Wert auf Brightness zu belassen.
Ständig habe ich wieder "astro" im Attribut. Rekonstruierbar nach dem FHEM-Neustart.
Aber das passiert auch nach nem Scan-Durchlauf.

Ich weiß, ist ein aktueller Bug. In der nächsten Version ist das raus. Ich würde sie morgen Abend oder Montag früh raus geben. Will noch etwas testen.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: sentinel1 am 20 Oktober 2018, 22:41:18
Hallo,

ich wollte auch das Modul testen,bei mir werden aber die user Attribute in Rollladen nicht erstellt.
Ich habe zuerst das Device erstellt
define Rolladensteuerung AutoShuttersControl

dann beim Rollo Device
attr Rollo ASC 2

danach wieder in der Rolladensteuerung
set Rolladensteuerung scanForShutters

Fhem Neustart,dann wollte ich in Rollo Device die Attribute einstellen,aber da gibt es keine.Fhem und Modul sind auf aktuellem stand.
Habe ich was vergessen oder warum ist da so?

List Rolladensteuerung
Internals:
   CHANGED   
   MID        da39a3ee5e6b4b0d3255bfef95601890afd80709
   NAME       Rolladensteuerung
   NOTIFYDEV  global,Rolladensteuerung
   NR         565
   NTFY_ORDER 50-Rolladensteuerung
   NotifyOrderPrefix 51-
   STATE      please set attribut 'ACS' with value 1 or 2 to all your auto controlled shutters and then do 'set DEVICENAME scanForShutters
   TYPE       AutoShuttersControl
   VERSION    0.1.80
   READINGS:
     2018-10-20 22:18:48   lockOut         off
     2018-10-20 22:18:48   partyMode       off
     2018-10-20 22:18:48   selfDefense     off
     2018-10-20 22:22:46   state           please set attribut 'ACS' with value 1 or 2 to all your auto controlled shutters and then do 'set DEVICENAME scanForShutters
     2018-10-20 22:18:48   sunriseTimeWeHoliday off
     2018-10-20 22:22:53   userAttrList    rolled out
   helper:
     shuttersList:
       rollo1_bad
Attributes:
   ASC_antifreezeTemp 3
   ASC_autoAstroModeEvening REAL
   ASC_autoAstroModeMorning REAL
   ASC_autoShuttersControlEvening on
   ASC_autoShuttersControlMorning on
   ASC_temperatureReading temperature
   DbLogExclude .*
   event-on-change-reading state
   icon       fts_shutter_automatic
   room       ASC


List Rollo


Internals:
   CHANGED   
   DEF        565739
   IODev      hmUART_Lan2
   LASTInputDev hmUART_Lan2
   MSGCNT     8
   NAME       rollo1_bad
   NOTIFYDEV  global
   NR         382
   NTFY_ORDER 50-rollo1_bad
   STATE      runter
   TYPE       CUL_HM
   hmUART_Lan1_MSGCNT 4
   hmUART_Lan1_RAWMSG 0500003D6DA4105657392424240601000054
   hmUART_Lan1_RSSI -61
   hmUART_Lan1_TIME 2018-10-20 22:24:15
   hmUART_Lan2_MSGCNT 4
   hmUART_Lan2_RAWMSG 050100396DA4105657392424240601000054
   hmUART_Lan2_RSSI -57
   hmUART_Lan2_TIME 2018-10-20 22:24:15
   lastMsg    No:6D - t:10 s:565739 d:242424 0601000054
   peerList   VCCU_Btn1,
   protCmdDel 1
   protLastRcv 2018-10-20 22:24:15
   protRcv    2 last_at:2018-10-20 22:24:15
   protResnd  3 last_at:2018-10-20 22:23:52
   protResndFail 1 last_at:2018-10-20 22:23:58
   protSnd    5 last_at:2018-10-20 22:24:15
   protState  CMDs_done
   rssi_at_hmUART_Lan1 cnt:4 min:-62 max:-60 avg:-61 lst:-61
   rssi_at_hmUART_Lan2 cnt:4 min:-58 max:-56 avg:-57 lst:-57
   rssi_hmUART_Lan2 cnt:2 min:-85 max:-84 avg:-84.5 lst:-84
   READINGS:
     2018-10-20 19:36:10   CommandAccepted yes
     2017-12-07 09:03:36   D-firmware      2.11
     2017-12-07 09:03:36   D-serialNr      OEQ0291657
     2018-06-05 20:42:02   PairedTo        0x242424
     2017-12-21 22:58:36   R-VCCU_Btn1-lgActionType jmpToTarget
     2017-12-21 22:58:36   R-VCCU_Btn1-lgOnLevel 100 %
     2017-12-21 22:58:36   R-VCCU_Btn1-shActionType jmpToTarget
     2017-12-21 22:58:36   R-VCCU_Btn1-shOnLevel 100 %
     2017-12-07 09:14:05   R-driveDown     27 s
     2017-12-07 09:03:42   R-driveTurn     0.5 s
     2017-12-07 09:13:36   R-driveUp       26 s
     2017-12-07 09:03:41   R-pairCentral   0x242424
     2017-12-07 09:03:42   R-powerUpAction off
     2017-12-07 09:03:42   R-sign          off
     2018-06-05 20:42:02   RegL_00.        02:01 0A:24 0B:24 0C:24 15:FF 18:00 00:00
     2018-06-05 20:42:03   RegL_01.        08:00 09:00 0A:00 0B:01 0C:0E 0D:01 0E:04 0F:05 10:00  30:06 57:24 56:00 00:00
     2018-06-05 20:42:05   RegL_03.VCCU_Btn1 01:00 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:14 0C:52 0D:63 0E:00 0F:00 11:C8 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 1A:00 1B:00 1C:00 1D:FF 1E:63 1F:00 81:00 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:14 8C:52 8D:63 8E:00 8F:00 91:C8 92:00 93:00 94:00 95:00 96:00 97:00 98:00 99:00 9A:00 9B:00 9C:00 9D:05 9E:63 9F:00 00:00
     2018-10-20 22:24:15   deviceMsg       off (to VCCU)
     2018-10-20 22:24:15   level           0
     2018-10-20 22:24:15   motor           stop:off
     2018-10-20 22:24:15   pct             0
     2018-10-20 22:22:48   peerList        VCCU_Btn1,
     2018-06-05 20:42:01   powerOn         2018-06-05 20:42:01
     2018-10-20 22:24:15   recentStateType info
     2018-10-20 22:24:15   state           off
     2018-10-20 22:24:15   timedOn         off
     2018-07-28 06:00:37   trigLast        VCCU_Btn1:short
     2018-07-28 06:00:37   trig_VCCU_Btn1  Short_1
   helper:
     HM_CMDNR   109
     cSnd       ,01242424565739010E
     mId        006A
     regLst     ,0,1,3p
     rxType     1
     supp_Pair_Rep 0
     ack:
     dir:
       cur        stop
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +565739,00,01,00
       nextSend   1540067055.51957
       rxt        0
       vccu       VCCU
       p:
         565739
         00
         01
         00
       prefIO:
         hmUART_Lan2
     mRssi:
       mNo        6D
       io:
         hmUART_Lan1:
           -61
           -61
         hmUART_Lan2:
           -51
           -51
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       prs        1
     rpt:
       IO         hmUART_Lan1
       flg        A
       ts         1540067055.21098
       ack:
         HASH(0x41e6e90)
         6D800224242456573900
     rssi:
       at_hmUART_Lan1:
         avg        -61
         cnt        4
         lst        -61
         max        -60
         min        -62
       at_hmUART_Lan2:
         avg        -57
         cnt        4
         lst        -57
         max        -56
         min        -58
       hmUART_Lan2:
         avg        -84.5
         cnt        2
         lst        -84
         max        -84
         min        -85
     tmpl:
Attributes:
   ASC        2
   IODev      hmUART_Lan2
   IOgrp      VCCU:hmUART_Lan2
   alias      Rollo Bad
   autoReadReg 5_readMissing
   devStateIcon runter:shutter_closed 0:shutter_closed hoch:shutter_open 100:shutter_open .*:shutter_halfopen
   event-on-change-reading pct,state
   eventMap   /off:runter/ /on:hoch/ /pct 40:halb/ /pct 80:regen/ /stop:stop/
   expert     2_raw
   firmware   2.11
   group      Bedienung
   icon       fts_shutter_manual
   model      HM-LC-Bl1PBU-FM
   peerIDs    00000000,24242401,
   rollo_wg   rollo_wohnung
   rollo_wg_map pct:0:unten pct:100:oben pct:\b[1-9]\b:halb pct:\b[1-9][0-9]\b:halb
   room       CUL_HM,Wohnung
   serialNr   OEQ0291657
   subType    blindActuator
   userattr   rollo_wg rollo_wg_map structexclude
   webCmd     hoch:runter:halb:stop

Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 20 Oktober 2018, 22:51:01
event-on-change-reading state

Bitte raus nehmen, jegliche event-on-change-reading* dürfen auf keinen Fall gesetzt werden.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: sentinel1 am 20 Oktober 2018, 23:49:51
Zitat von: CoolTux am 20 Oktober 2018, 22:51:01
event-on-change-reading state

Bitte raus nehmen, jegliche event-on-change-reading* dürfen auf keinen Fall gesetzt werden.

...und schon funktioniert es.Danke
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: C0mmanda am 21 Oktober 2018, 17:20:43
Wäre es möglich in den Rolläden Readings für:

- aktiviertes Nachtschliessen
- aktivierte Beschattung
- aktiviertes selfDefense + das zurücksetzen / deaktivieren von selfDefense

zu hinterlegen?

z.B.
ASC_Nachtschliessen (0|1)
ASC_Shading (0|1)
ASC_selfDefense (0|1)

Damit könnte man dann Benachrichtigungen (z.b. Pushover/Telegram) auslösen und man könnte die Readings fürs TabletUI nutzen wenn gewollt.

gruß
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 21 Oktober 2018, 17:59:47
Die stehen im ASC Device selbst da sie "global" sind. Also das ein und aus schalten. Bei den Rolläden kann man nur Einzel Steuerungen per Attribut ein stellen.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: C0mmanda am 21 Oktober 2018, 21:26:31
Zitat von: CoolTux am 21 Oktober 2018, 17:59:47
Die stehen im ASC Device selbst da sie "global" sind. Also das ein und aus schalten. Bei den Rolläden kann man nur Einzel Steuerungen per Attribut ein stellen.

Ich habe im ASC-Device nur die Readings xx_nextAstroTimeEvent und xx_lastPosValue.
Fehlen mir Readings? Übersehe ich etwas?

Internals:
   CHANGED   
   MID        da39a3ee5e6b4b0d3255bfef95601890afd80709
   NAME       Rolladensteuerung
   NOTIFYDEV  EG.ku.TK.FensterKU,GH.xx.LS.HelligkeitAussen,OG.sz.TK.FensterSZ,Rolladensteuerung,global,rgr_Home,rr_Sascha
   NR         217
   NTFY_ORDER 50-Rolladensteuerung
   NotifyOrderPrefix 51-
   STATE      active
   TYPE       AutoShuttersControl
   VERSION    0.1.80
   OLDREADINGS:
   READINGS:
     2018-10-21 19:07:25   EG.ku.RO.KURolladen_lastPosValue 100
     2018-10-21 19:07:25   EG.ku.RO.KURolladen_nextAstroTimeEvent 22.10.2018 - 07:00
     2018-10-21 19:08:17   EG.sp.RO.SPRolladen_lastPosValue 100
     2018-10-21 19:08:17   EG.sp.RO.SPRolladen_nextAstroTimeEvent 22.10.2018 - 07:38
     2018-10-21 19:07:20   EG.wz.RO.WZRolladen.1_lastPosValue 100
     2018-10-21 19:07:20   EG.wz.RO.WZRolladen.1_nextAstroTimeEvent 22.10.2018 - 07:38
     2018-10-21 19:07:20   EG.wz.RO.WZRolladen.2_lastPosValue 100
     2018-10-21 19:07:20   EG.wz.RO.WZRolladen.2_nextAstroTimeEvent 22.10.2018 - 07:38
     2018-10-21 19:07:49   OG.az.RO.AZRolladen_lastPosValue 100
     2018-10-21 19:07:49   OG.az.RO.AZRolladen_nextAstroTimeEvent 22.10.2018 - 07:39
     2018-10-21 19:07:31   OG.gz.RO.GZRolladen_lastPosValue 90
     2018-10-21 19:07:31   OG.gz.RO.GZRolladen_nextAstroTimeEvent 22.10.2018 - 09:30
     2018-10-21 20:24:59   OG.sz.RO.SZRolladen_lastPosValue 80
     2018-10-21 19:07:45   OG.sz.RO.SZRolladen_nextAstroTimeEvent 21.10.2018 - 22:30
     2018-09-30 11:23:06   lockOut         off
     2018-09-30 11:15:58   partyMode       off
     2018-10-20 14:02:59   room_Homekit_Rolladen EG.ku.RO.KURolladen,EG.sp.RO.SPRolladen,EG.wz.RO.WZRolladen.1,EG.wz.RO.WZRolladen.2,OG.az.RO.AZRolladen,OG.gz.RO.GZRolladen,OG.sz.RO.SZRolladen
     2018-10-20 14:14:41   selfDefense     on
     2018-10-20 14:02:59   state           active
     2018-10-06 10:12:13   sunriseTimeWeHoliday on
     2018-10-20 14:02:59   userAttrList    rolled out
   helper:
     shuttersList:
       EG.ku.RO.KURolladen
       EG.sp.RO.SPRolladen
       EG.wz.RO.WZRolladen.1
       EG.wz.RO.WZRolladen.2
       OG.az.RO.AZRolladen
       OG.gz.RO.GZRolladen
       OG.sz.RO.SZRolladen
   monitoredDevs:
     EG.ku.TK.FensterKU:
       EG.ku.RO.KURolladen ASC_WindowRec
     GH.xx.LS.HelligkeitAussen:
       EG.ku.RO.KURolladen ASC_Shading_Brightness_Sensor
       OG.sz.RO.SZRolladen ASC_Shading_Brightness_Sensor
     OG.sz.TK.FensterSZ:
       OG.sz.RO.SZRolladen ASC_WindowRec
     rgr_Home:
       Rolladensteuerung ASC_residentsDevice
     rr_Sascha:
       OG.sz.RO.SZRolladen ASC_Roommate_Device
Attributes:
   ASC_antifreezeTemp 3
   ASC_autoAstroModeEvening HORIZON
   ASC_autoAstroModeEveningHorizon -7
   ASC_autoAstroModeMorning HORIZON
   ASC_autoAstroModeMorningHorizon -5
   ASC_autoShuttersControlEvening on
   ASC_autoShuttersControlMorning on
   ASC_residentsDevice rgr_Home
   ASC_sunPosDevice Astro
   ASC_sunPosReading SunAz
   ASC_temperatureReading temperature
   ASC_temperatureSensor GV.xx.TF.Aussen
   DbLogExclude .*
   icon       fts_shutter_automatic
   room       Rolladen
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 22 Oktober 2018, 06:12:38

     2018-09-30 11:23:06   lockOut         off
     2018-09-30 11:15:58   partyMode       off
     2018-10-20 14:14:41   selfDefense     on
     2018-10-06 10:12:13   sunriseTimeWeHoliday on

Das ist der Rest der wichtig ist. Shading gibt es noch nicht. Was ist Nachtschließen?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: C0mmanda am 22 Oktober 2018, 07:35:49
Zitat von: CoolTux am 22 Oktober 2018, 06:12:38

Das ist der Rest der wichtig ist. Shading gibt es noch nicht. Was ist Nachtschließen?

Ah, das meinst du. Dann meinen wir nicht dasselbe ;)
Ich meine nicht die global aktivierten Modi sondern die einzelnen Stati der Rolläden.

Ich habe das in etwa so im Sinn (Reading jeweils im einzelnen Rolladen):

Rolladen1 schliesst beim verlassen des Hauses, Fenster geöffnet: ASC_selfDefense = on|1
Rolladen2 fährt in Beschattungsposition: ASC_shading = on|1
Rolladen3 schliesst um 19:30 planmäßig herunter: ASC_Nachtschliessen = on|1

"Nachtschliessen" ist für mich das planmäßige herunterfahren am Abend ausgelöst durch Zeit, astro oder Brightness.
Cluni hat dies so in seiner shutterUtils.pm genannt.

Ich fand dies sehr praktisch da man hierauf eben triggern kann und z.B. eine Pushnachricht versenden oder im TabletUI anzeigen lassen kann dass der Rolladen im OG gerade in der Beschattung ist.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 22 Oktober 2018, 08:15:29
Ich habe Version 0.1.81 ins Git geladen. Einige Bugfix, außer dem gib es das Attribut "ASC_ShuttersPlace" window/terrace welches vom SelfDefence Mode ausgewertet wird.
Und man kann nun bei den Attributen   ASC_Mode_Down und ASC_Mode_Up home einstellen.


Grüße
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 22 Oktober 2018, 10:30:00
Zitat von: C0mmanda am 22 Oktober 2018, 07:35:49
Ah, das meinst du. Dann meinen wir nicht dasselbe ;)
Ich meine nicht die global aktivierten Modi sondern die einzelnen Stati der Rolläden.

Ich habe das in etwa so im Sinn (Reading jeweils im einzelnen Rolladen):

Rolladen1 schliesst beim verlassen des Hauses, Fenster geöffnet: ASC_selfDefense = on|1
Rolladen2 fährt in Beschattungsposition: ASC_shading = on|1
Rolladen3 schliesst um 19:30 planmäßig herunter: ASC_Nachtschliessen = on|1

"Nachtschliessen" ist für mich das planmäßige herunterfahren am Abend ausgelöst durch Zeit, astro oder Brightness.
Cluni hat dies so in seiner shutterUtils.pm genannt.

Ich fand dies sehr praktisch da man hierauf eben triggern kann und z.B. eine Pushnachricht versenden oder im TabletUI anzeigen lassen kann dass der Rolladen im OG gerade in der Beschattung ist.

Schaue ich mir an. Wollte eigentlich so wenig wie möglich in die fremden Devices schreiben. Aber ein bisschen mehr Infos sind wahrscheinlich nicht verkehrt.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 22 Oktober 2018, 15:07:26
Zitat von: C0mmanda am 22 Oktober 2018, 07:35:49
Ah, das meinst du. Dann meinen wir nicht dasselbe ;)
Ich meine nicht die global aktivierten Modi sondern die einzelnen Stati der Rolläden.

Ich habe das in etwa so im Sinn (Reading jeweils im einzelnen Rolladen):

Rolladen1 schliesst beim verlassen des Hauses, Fenster geöffnet: ASC_selfDefense = on|1
Rolladen2 fährt in Beschattungsposition: ASC_shading = on|1
Rolladen3 schliesst um 19:30 planmäßig herunter: ASC_Nachtschliessen = on|1

"Nachtschliessen" ist für mich das planmäßige herunterfahren am Abend ausgelöst durch Zeit, astro oder Brightness.
Cluni hat dies so in seiner shutterUtils.pm genannt.

Ich fand dies sehr praktisch da man hierauf eben triggern kann und z.B. eine Pushnachricht versenden oder im TabletUI anzeigen lassen kann dass der Rolladen im OG gerade in der Beschattung ist.

Ich habe ein Reading für dieRolläden gebaut
Zitat
ASC_ShuttersLastDrive - Grund des letzten fahrens vom Rolladen
passt das so?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Cluni am 22 Oktober 2018, 15:16:45
Nachtschliesen wird bei mir gesetz, wenn ein Fenster oder eine Tür noch offen ist und der Zeitpunkt zum schließen gekommen ist. Der Rollladen wird dann geschlossen, sobald das Fenster / die Tür geschlossen wird. Ist ein Merker, damit das nachgeholt wird. Sonst würde der Rollladen ja nicht geschlossen bei entsprechend gesetzten Attributen.


Gesendet von iPhone mit Tapatalk
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: C0mmanda am 22 Oktober 2018, 15:40:05
Zitat von: CoolTux am 22 Oktober 2018, 15:07:26
Ich habe ein Reading für dieRolläden gebautpasst das so?

Ich werde testen und berichten!
Vielen Dank.

Gruß
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 22 Oktober 2018, 16:08:34
Ist noch nicht im Git, mir ging es erstmal um das Reading an sich  ;D
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: C0mmanda am 22 Oktober 2018, 22:45:30
Zitat von: CoolTux am 22 Oktober 2018, 16:08:34
Ist noch nicht im Git, mir ging es erstmal um das Reading an sich  ;D

::)
Und ich habe mich schon gefragt warum es nicht auftaucht  :-[
Ich denke es sollte ausreichend sein.
Vielleicht sogar besser als drei einzelne Readings. Wenns im git ist werde
ich testen!

Grus
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: sentinel1 am 23 Oktober 2018, 02:04:59
Zitat von: sentinel1 am 20 Oktober 2018, 23:49:51
...und schon funktioniert es.Danke

Das Modul ist super.Viellen Dank für deine Arbeit.

Ich konnte alle meine DOIF für Rollladensteuerung und Beschattung ersetzen bis auf einen,daher eine Frage/Wunsch ob folgendes machbar währe.

Wenn keiner zuhause ist  die Fenster gekippt/offen sind und ein Regensensor regen meldet "regen" dann fahren die Betroffenen Rollläden in eine bestimmte Position. Etwa so wie jetzt selfDefense nur Regensensor abhängig.

Gruß,
Claudiu
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 23 Oktober 2018, 06:15:08
Hallo Claudius,

Das klingt sehr gut. Werde ich in nächster Zeit einbauen. Dauert aber ein bisschen.


Grüße

PS: Danke für Deine Spende  ;)
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 23 Oktober 2018, 11:44:37
Zitat von: Papaloewe am 19 Oktober 2018, 15:02:21
Ich würde gerne bei Abwesenheit eines Roomates den Rolladen gar nicht automatisch (herunter)fahren.
Leider ist bisher nur das Gegenteil implementiert, also nur bei Abwesenheit die Automatik zu steuern.
Wäre es möglich noch für die beiden Attribute "ASC_ModeUp" und "ASC_ModeDown" noch den Wert "present" zus. einzuführen?

Hierzu habe ich eine Anmerkung. Wie sollten sich die Rollos verhalten wenn der Roommate wieder present ist? Sollen sie dann ihre Fahrt auf nehmen?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 23 Oktober 2018, 12:09:19
Zitat von: sentinel1 am 23 Oktober 2018, 02:04:59
Das Modul ist super.Viellen Dank für deine Arbeit.

Ich konnte alle meine DOIF für Rollladensteuerung und Beschattung ersetzen bis auf einen,daher eine Frage/Wunsch ob folgendes machbar währe.

Wenn keiner zuhause ist  die Fenster gekippt/offen sind und ein Regensensor regen meldet "regen" dann fahren die Betroffenen Rollläden in eine bestimmte Position. Etwa so wie jetzt selfDefense nur Regensensor abhängig.

Gruß,
Claudiu

Reicht es wenn ich den Regensensor und Reading global im ASC Device unter bringe oder brauch man das auch für jedes Fenster einzeln?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: FunkOdyssey am 23 Oktober 2018, 17:33:27
Zitat von: FunkOdyssey am 20 Oktober 2018, 19:55:53
Ich schaffe es einfach nicht, den down-Wert auf Brightness zu belassen.
Ständig habe ich wieder "astro" im Attribut. Rekonstruierbar nach dem FHEM-Neustart.
Aber das passiert auch nach nem Scan-Durchlauf.

Ich wurde heute morgen im hellen Bad und bei Dunkelheit im Außenbereich plötzlich durch hochfahrende Jalousien überrascht. :-)
Ich hatte nach dem Fix von dir vergessen, die Werte neu zu schreiben. Und scheinbar wurde auch "Mode_Up" zurückgesetzt.

Aber: Ich konnte gerade erstmals die Jalousien anhand der Helligkeitswerte herunterfahren. Vielen Dank. Dies finde ich sehr praktisch. Die Einstellungen werden auch nicht mehr gelöscht.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: sentinel1 am 23 Oktober 2018, 17:42:24
Zitat von: CoolTux am 23 Oktober 2018, 12:09:19
Reicht es wenn ich den Regensensor und Reading global im ASC Device unter bringe oder brauch man das auch für jedes Fenster einzeln?

Mir würde global reichen,so mache ich es jetzt auch in DOIF.Für jedes Fenster wäre auch nicht schlecht aber ich glaube das ist viel mehr Arbeit für dich.Ich bin froh das Du es überhaupt einbaust.

Gruß,
Claudiu
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: FunkOdyssey am 23 Oktober 2018, 17:46:08
Ein paar Fragen und Hinweise:




Ich hatte gerade im NOTIFYDEV sämtliche Geräte doppelt gelistet:

Rolladensteuerung,dummy_brightness,global,rgr_Residents,jal_ankleide,jal_bad,jal_buegeln,jal_waschen,jal_ankleide,jal_bad,jal_buegeln,jal_waschen,dummy_brightness,rgr_Residents

Nach nem "set xyz createNewNotifyDev" war das weg.




Besteht die Möglichkeit, die benutzten Jalousie-Devices unter "Probably associated with" aufzuführen? Ist absolut nicht wichtig, aber manchmal ganz nett, wenn man direkt zu den Geräten springen kann.




Im Fenster "showShutterInformation" scheint an ein paar Stellen die Zeit nicht gewandelt zu werden:

Shutters Next DriveUp Next DriveDown Partymode Lock-Out Sunrise Sunset Last manual Position Last manual Position Timestamp
jal_ankleide 24.10.2018 - 08:15 23.10.2018 - 19:00 off soft 1540361749 1540314007 0 1540308499





Persönliche Meinung:
Ich finde es immer wieder ziemlich schwierig, zwischen Mode_Down, Mode_Up, Up und Down zu differenzieren.
Du wirst die Frage vermutlich nicht mögen, aber könnte man bei Up/Down vielleicht auch ein Präfix nutzen?
Und ist die Wortwahl "Mode" wirklich richtig? Ist nicht auch Up/Down (brightness, astro, etc.) auch ein Modus?
Das eine sagt doch "wann" und das andere "wie", oder?




Bei mir wurden im "get xyz showNotifyDevsInformations" auch die Brightness-Notify-Geräte angezeigt, als ich gar keine Brightness-Auswahl in Up/Down gesetzt hatte. Ist das korrekt? Ich verstehe den Sinn hinter diesem Getter nicht.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 23 Oktober 2018, 17:47:40
Zitat von: sentinel1 am 23 Oktober 2018, 17:42:24
Mir würde global reichen,so mache ich es jetzt auch in DOIF.Für jedes Fenster wäre auch nicht schlecht aber ich glaube das ist viel mehr Arbeit für dich.Ich bin froh das Du es überhaupt einbaust.

Gruß,
Claudiu

Mehr Arbeit wäre es nicht, aber es soll ja auch Sinn machen. Ich denke allerdings nicht wirklich das man mehr wie einen Regensensor hat und es dazu noch unterschiedlich doll regnet pro Fenster. Daher sehe ich global im ASC als sinnvoller an.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: sentinel1 am 23 Oktober 2018, 20:21:45
Zitat von: CoolTux am 23 Oktober 2018, 17:47:40
Daher sehe ich global im ASC als sinnvoller an.

ja,Du hast recht,global ist sinnvoller.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 23 Oktober 2018, 21:12:13
Zitat von: FunkOdyssey am 23 Oktober 2018, 17:46:08
Besteht die Möglichkeit, die benutzten Jalousie-Devices unter "Probably associated with" aufzuführen? Ist absolut nicht wichtig, aber manchmal ganz nett, wenn man direkt zu den Geräten springen kann.

Soweit ich weiß kommt diese Zuordnung automatisch. Ich denke nicht das ich da etwas steuern kann. Wenn Du schnellen Zugriff haben willst kannst Du über die Liste des Internals NOTIFYDEV direkt auf die Devicenamen klicken.

Zitat von: FunkOdyssey am 23 Oktober 2018, 17:46:08
Im Fenster "showShutterInformation" scheint an ein paar Stellen die Zeit nicht gewandelt zu werden:

Shutters Next DriveUp Next DriveDown Partymode Lock-Out Sunrise Sunset Last manual Position Last manual Position Timestamp
jal_ankleide 24.10.2018 - 08:15 23.10.2018 - 19:00 off soft 1540361749 1540314007 0 1540308499


Das ist korrekt, ich habe dies Ausgabe zu Debigzwecke verwendet. Die letzten beiden Ausgaben werde ich ändern oder ganz raus nehmen. Muss ich mal schauen.
Zitat von: FunkOdyssey am 23 Oktober 2018, 17:46:08
Persönliche Meinung:
Ich finde es immer wieder ziemlich schwierig, zwischen Mode_Down, Mode_Up, Up und Down zu differenzieren.
Du wirst die Frage vermutlich nicht mögen, aber könnte man bei Up/Down vielleicht auch ein Präfix nutzen?
Und ist die Wortwahl "Mode" wirklich richtig? Ist nicht auch Up/Down (brightness, astro, etc.) auch ein Modus?
Das eine sagt doch "wann" und das andere "wie", oder?

Das habe ich so halbwegs von Bernd versucht zu übernehmen. Sicherlich ist die Benennung nicht ganz eindeutig, aber dafür gibt es ja die ausführliche Commandref.

Zitat von: FunkOdyssey am 23 Oktober 2018, 17:46:08
Bei mir wurden im "get xyz showNotifyDevsInformations" auch die Brightness-Notify-Geräte angezeigt, als ich gar keine Brightness-Auswahl in Up/Down gesetzt hatte. Ist das korrekt? Ich verstehe den Sinn hinter diesem Getter nicht.
Es spielt keine Rolle ob Du in Up und Down Brightness gewählt hast oder nicht, sobald Du ein Device im Attribut Brightness Device angegeben hast wird/muss dieses Device im Internet NOTIFYDEV gelistet sein um dessen Events zu triggern und dann wird es auch in dem get gelistet. get xyz showNotifyDevsInformations soll helfen schnell zu sehen ob ein eventueller Fehler im Internal NOTIFYDEV wie bei Dir ein Fehler vom Modul oder eine fehlerhafte Zusammensetzung woher auch immer ist.
Ich werde das mal auslagern, sichtbar erst ab verbose 4.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 24 Oktober 2018, 08:04:08
Zitat von: FunkOdyssey am 17 Oktober 2018, 12:11:17
Ich habe gestern Abend die ersten Jalousien über die Brightness-Werte gesteuert.
Funktioniert wie es soll. Gefällt mir gut.
Ich würde mir wünschen, wenn man im ASC-Log ein wenig mehr Infos über das hätte, was gerade wirklich passiert.
Man kann nicht wirklich erkennen, dass die Jalousien gerade runtergefahren sind, weil:
- Astro-Zeitpunkt erreicht,
- Feste Uhrzeit erreicht
- oder ein Helligkeitswert erreicht wurde.




Ich habe die (neue) CommandRef gelesen und mich versucht über die ASC_brightnessMinVal und ASC_brightnessMaxVal zu informieren.
Im Quellcode erkenne ich nur Abhängigkeiten zu MinVal. Aber die Jalousien sind beim Unterschreiten von MaxVal heruntergefahren.
Das Hochfahren habe ich aktuell nicht implementiert.

Unabhängig davon sind mir die Unterschiede zwischen den beiden Attributen noch nicht klar.




Ein Brightness-Sensor könnte ja auch kurzzeitig eine Schwelle unter- bzw. überschreiten, falls bspw. eine größere Wolkenfront kommt.
Besteht irgendwie die Möglichkeit, dass erst nach zweifacher Unterschreitung oder nach einem Wartezeitraum von x Sekunden die Jalousien gefahren werden?
Ich glaube zwar, dass es in der Praxis nicht oft passieren wird, aber die Steuerung könnte sonst theoretisch ein wenig sensibel reagieren und auslösen.

Wie schaut es aktuell aus bei Dir? Bei mir sind sie mit der Brightnesseinstellung immer korrekt gefahren.


Grüße
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 24 Oktober 2018, 08:19:44
Zitat von: FunkOdyssey am 17 Oktober 2018, 12:11:17
Ich habe gestern Abend die ersten Jalousien über die Brightness-Werte gesteuert.
Funktioniert wie es soll. Gefällt mir gut.
Ich würde mir wünschen, wenn man im ASC-Log ein wenig mehr Infos über das hätte, was gerade wirklich passiert.
Man kann nicht wirklich erkennen, dass die Jalousien gerade runtergefahren sind, weil:
- Astro-Zeitpunkt erreicht,
- Feste Uhrzeit erreicht
- oder ein Helligkeitswert erreicht wurde.




Ich habe die (neue) CommandRef gelesen und mich versucht über die ASC_brightnessMinVal und ASC_brightnessMaxVal zu informieren.
Im Quellcode erkenne ich nur Abhängigkeiten zu MinVal. Aber die Jalousien sind beim Unterschreiten von MaxVal heruntergefahren.
Das Hochfahren habe ich aktuell nicht implementiert.

Unabhängig davon sind mir die Unterschiede zwischen den beiden Attributen noch nicht klar.




Ein Brightness-Sensor könnte ja auch kurzzeitig eine Schwelle unter- bzw. überschreiten, falls bspw. eine größere Wolkenfront kommt.
Besteht irgendwie die Möglichkeit, dass erst nach zweifacher Unterschreitung oder nach einem Wartezeitraum von x Sekunden die Jalousien gefahren werden?
Ich glaube zwar, dass es in der Praxis nicht oft passieren wird, aber die Steuerung könnte sonst theoretisch ein wenig sensibel reagieren und auslösen.

Was mir gerade noch einfällt, falls noch nicht gesagt. Wenn der minimale Wert einmal Abends unterschritten bzw. Morgens überschritten wurde, fahren die Rollos runter bzw. hoch. Eine weitere Fahrt sollte es dann innerhalb der Tageszeit nicht mehr geben.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Cluni am 24 Oktober 2018, 08:22:08
Zitat von: CoolTux am 23 Oktober 2018, 17:47:40
Mehr Arbeit wäre es nicht, aber es soll ja auch Sinn machen. Ich denke allerdings nicht wirklich das man mehr wie einen Regensensor hat und es dazu noch unterschiedlich doll regnet pro Fenster. Daher sehe ich global im ASC als sinnvoller an.

Es kann schon unterschiedlich doll pro Fenster regnen. Aber mit persönlich ist es auch egal.


Gesendet von iPhone mit Tapatalk
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: FunkOdyssey am 24 Oktober 2018, 09:16:19
Zitat von: CoolTux am 24 Oktober 2018, 08:04:08
Wie schaut es aktuell aus bei Dir? Bei mir sind sie mit der Brightnesseinstellung immer korrekt gefahren.

So ist es bei mir auch. Dies hatte ich hier (https://forum.fhem.de/index.php/topic,90751.msg848951.html#msg848951) versucht zu beschreiben. Alles läuft wie erwartet. Danke.

Zitat von: CoolTux am 24 Oktober 2018, 08:19:44
Was mir gerade noch einfällt, falls noch nicht gesagt. Wenn der minimale Wert einmal Abends unterschritten bzw. Morgens überschritten wurde, fahren die Rollos runter bzw. hoch. Eine weitere Fahrt sollte es dann innerhalb der Tageszeit nicht mehr geben.

Sehr praktisch. Danke.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 24 Oktober 2018, 10:09:33
Zitat von: sentinel1 am 23 Oktober 2018, 02:04:59
Das Modul ist super.Viellen Dank für deine Arbeit.

Ich konnte alle meine DOIF für Rollladensteuerung und Beschattung ersetzen bis auf einen,daher eine Frage/Wunsch ob folgendes machbar währe.

Wenn keiner zuhause ist  die Fenster gekippt/offen sind und ein Regensensor regen meldet "regen" dann fahren die Betroffenen Rollläden in eine bestimmte Position. Etwa so wie jetzt selfDefense nur Regensensor abhängig.

Gruß,
Claudiu

Welche Werte dienen eigentlich zum erfassen des Regens. Also stehen in das zu benutzende Reading Zahlen drin oder eher Strings, sowas wie rain noRain oder so?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Karflyer am 24 Oktober 2018, 15:41:05
Bei dem Netatmo-Regenmesser gibt es das reading "rain". Das hat den Wert 0 wenn es nicht regnet oder Werte (Zahlen) > 0 wenn es regnet.

Stefan
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 24 Oktober 2018, 15:42:13
Zitat von: Karflyer am 24 Oktober 2018, 15:41:05
Bei dem Netatmo-Regenmesser gibt es das reading "rain". Das hat den Wert 0 wenn es nicht regnet oder Werte (Zahlen) > 0 wenn es regnet.

Stefan

Danke Dir. Dann hoffen wir mal das die anderen das auch so haben. Mal schauen was sentinel1 sagt.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 24 Oktober 2018, 16:06:45
Finde true/false auch OK. (Für Perl dürfte das dasselbe sein, 0=false, positive Werte=true.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 24 Oktober 2018, 16:48:36
Ich auch. Aber ab die Sensoren das so liefern
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: sentinel1 am 24 Oktober 2018, 18:12:18
Zitat von: CoolTux am 24 Oktober 2018, 15:42:13
Danke Dir. Dann hoffen wir mal das die anderen das auch so haben. Mal schauen was sentinel1 sagt.

ich habe ein HM Regensensor,da habe ich in Reading state "rain" bei regen und "dry" wenn es nicht regnet.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 24 Oktober 2018, 18:15:49
Zitat von: sentinel1 am 24 Oktober 2018, 18:12:18
ich habe ein HM Regensensor,da habe ich in Reading state "rain" bei regen und "dry" wenn es nicht regnet.
OK, hast Du da noch andere Readings?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: sentinel1 am 24 Oktober 2018, 18:46:02
Zitat von: CoolTux am 24 Oktober 2018, 18:15:49
OK, hast Du da noch andere Readings?

da ist ein List von Regensensor:
Internals:
   DEF        24593601
   NAME       regensensor_Rain
   NOTIFYDEV  global
   NR         103
   NTFY_ORDER 50-regensensor_Rain
   STATE      25
   TYPE       CUL_HM
   chanNo     01
   device     regensensor
   Helper:
     DBLOG:
       regen:
         myDbLog:
           TIME       1540396079.60187
           VALUE      25
   READINGS:
     2017-11-23 17:37:51   R-cndTxThrhHi   2900 mV
     2017-11-23 17:37:51   R-cndTxThrhLo   2850 mV
     2017-11-23 17:37:51   R-eventFilterTimeB 0 s
     2017-11-23 17:37:51   R-evntRelFltTime 120 s
     2017-12-05 15:23:57   R-highHoldTime  60 s
     2017-11-23 17:37:51   R-sign          off
     2017-11-23 17:37:51   R-transmitTryMax 6
     2018-10-24 17:45:55   lastRain        2018-10-24 16:52:31
     2018-10-24 17:47:59   recentStateType info
     2018-10-24 17:47:59   regen           rain
     2018-10-24 17:47:59   state           rain
     2018-10-24 17:47:59   timedOn         off
   helper:
     lastRain   2018-10-24 17:47:59
     regLst     ,1,4p
     expert:
       def        1
       det        1
       raw        0
       tpl        0
     role:
       chn        1
     tmpl:
Attributes:
   alias      Wetter Zuhause
   devStateIcon 0:weather_sun dry:weather_sun rain:weather_rain_light 25:weather_rain_light
   event-on-change-reading .*
   eventMap   rain:25 dry:0
   expert     1_allReg
   group      Wetter
   model      HM-Sen-RD-O
   peerIDs    00000000,
   room       Wetter
   userReadings regen {ReadingsVal("regensensor_Rain","state",0);}


true/false wäre für mich auch ok,sollte mit userReadings machbar sein.

Ich wolte die Rollos über Brightness_Werte mal testen finde aber in Rollo Device nicht wo ich das Brightness Device angeben kann.
Es gibt nur ASC_Shading_Brightness_Sensor,das ist aber nicht das richtige attr,oder?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 25 Oktober 2018, 04:44:55
Zitat von: sentinel1 am 24 Oktober 2018, 18:46:02

Ich wolte die Rollos über Brightness_Werte mal testen finde aber in Rollo Device nicht wo ich das Brightness Device angeben kann.
Es gibt nur ASC_Shading_Brightness_Sensor,das ist aber nicht das richtige attr,oder?

Doch das ist es.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 25 Oktober 2018, 13:02:20
Zitat von: sentinel1 am 24 Oktober 2018, 18:46:02
da ist ein List von Regensensor:
Internals:
   DEF        24593601
   NAME       regensensor_Rain
   NOTIFYDEV  global
   NR         103
   NTFY_ORDER 50-regensensor_Rain
   STATE      25
   TYPE       CUL_HM
   chanNo     01
   device     regensensor
   Helper:
     DBLOG:
       regen:
         myDbLog:
           TIME       1540396079.60187
           VALUE      25
   READINGS:
     2017-11-23 17:37:51   R-cndTxThrhHi   2900 mV
     2017-11-23 17:37:51   R-cndTxThrhLo   2850 mV
     2017-11-23 17:37:51   R-eventFilterTimeB 0 s
     2017-11-23 17:37:51   R-evntRelFltTime 120 s
     2017-12-05 15:23:57   R-highHoldTime  60 s
     2017-11-23 17:37:51   R-sign          off
     2017-11-23 17:37:51   R-transmitTryMax 6
     2018-10-24 17:45:55   lastRain        2018-10-24 16:52:31
     2018-10-24 17:47:59   recentStateType info
     2018-10-24 17:47:59   regen           rain
     2018-10-24 17:47:59   state           rain
     2018-10-24 17:47:59   timedOn         off
   helper:
     lastRain   2018-10-24 17:47:59
     regLst     ,1,4p
     expert:
       def        1
       det        1
       raw        0
       tpl        0
     role:
       chn        1
     tmpl:
Attributes:
   alias      Wetter Zuhause
   devStateIcon 0:weather_sun dry:weather_sun rain:weather_rain_light 25:weather_rain_light
   event-on-change-reading .*
   eventMap   rain:25 dry:0
   expert     1_allReg
   group      Wetter
   model      HM-Sen-RD-O
   peerIDs    00000000,
   room       Wetter
   userReadings regen {ReadingsVal("regensensor_Rain","state",0);}


true/false wäre für mich auch ok,sollte mit userReadings machbar sein.

Ich wolte die Rollos über Brightness_Werte mal testen finde aber in Rollo Device nicht wo ich das Brightness Device angeben kann.
Es gibt nur ASC_Shading_Brightness_Sensor,das ist aber nicht das richtige attr,oder?

Kannst Du mir verraten ab welchen Wert Du Deine Rollos so schließt.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: sentinel1 am 25 Oktober 2018, 18:23:59
Zitat von: CoolTux am 25 Oktober 2018, 13:02:20
Kannst Du mir verraten ab welchen Wert Du Deine Rollos so schließt.

Meinst du wenn es regnet?
das Rollo schließt wenn der Regensensor "rain" meldet und ein Fenster offen/gekippt ist.

Die Rollos Abend schließen über Brightness werde ich heute oder morgen probieren.Gehen da kleinere Werte als 1 auch zb. 0.1 ?

Bei mir sind gerade die Wohnzimmer Rollos zu gegangen.Ich wahr mir sicher das ich heute bei den Rollo device auf REAL eingestellt habe.CIVIL steht in ASC_Device,also sind sie nach den ASC_Device Zeit runtergefahren.
Als ich die Rollo device überprüft habe ist mir gleich aufgefallen das die ganzen ASC_attr weg sind.Ich habe ein List von einen Rollo gemacht,da sind aber die ASC_attr zu sehen.

TYPE       CUL_HM
   hmUART_Lan1_MSGCNT 38
   hmUART_Lan1_RAWMSG 0500004355A4105F16C024242406010000
   hmUART_Lan1_RSSI -67
   hmUART_Lan1_TIME 2018-10-25 18:01:45
   hmUART_Lan2_MSGCNT 39
   hmUART_Lan2_RAWMSG 0501003F55A4105F16C024242406010000
   hmUART_Lan2_RSSI -63
   hmUART_Lan2_TIME 2018-10-25 18:01:45
   lastMsg    No:55 - t:10 s:5F16C0 d:242424 06010000
   peerList   VCCU_Btn1,
   protLastRcv 2018-10-25 18:01:45
   protRcv    39 last_at:2018-10-25 18:01:45
   protResnd  2 last_at:2018-10-21 00:25:19
   protSnd    40 last_at:2018-10-25 18:01:45
   protState  CMDs_done
   rssi_at_hmUART_Lan1 cnt:38 min:-70 max:-63 avg:-65.78 lst:-67
   rssi_at_hmUART_Lan2 cnt:39 min:-74 max:-56 avg:-61.2 lst:-63
   rssi_hmUART_Lan2 cnt:19 min:-74 max:-65 avg:-69.05 lst:-74
   OLDREADINGS:
   READINGS:
     2018-10-25 09:00:16   ASC_Time_DriveDown 25.10.2018 - 18:36
     2018-10-25 09:00:16   ASC_Time_DriveUp 26.10.2018 - 09:00
     2018-10-25 18:01:18   CommandAccepted yes
     2017-12-19 18:46:01   D-firmware      2.11
     2017-12-19 18:46:01   D-serialNr      OEQ1298922
     2018-05-26 23:28:29   PairedTo        0x242424
     2017-12-21 22:55:54   R-VCCU_Btn1-lgActionType jmpToTarget
     2017-12-21 22:55:54   R-VCCU_Btn1-lgOnLevel 100 %
     2017-12-21 22:55:54   R-VCCU_Btn1-shActionType jmpToTarget
     2017-12-21 22:55:54   R-VCCU_Btn1-shOnLevel 100 %
     2017-12-19 19:31:02   R-driveDown     22 s
     2017-12-19 18:46:07   R-driveTurn     0.5 s
     2017-12-19 19:36:01   R-driveUp       22 s
     2017-12-19 18:46:06   R-pairCentral   0x242424
     2017-12-19 18:46:07   R-powerUpAction off
     2017-12-19 18:46:07   R-sign          off
     2018-05-26 23:28:29   RegL_00.        02:01 0A:24 0B:24 0C:24 15:FF 18:00 00:00
     2018-05-26 23:28:30   RegL_01.        08:00 09:00 0A:00 0B:00 0C:DC 0D:00 0E:DC 0F:05 10:00  30:06 57:24 56:00 00:00
     2018-05-26 23:28:32   RegL_03.VCCU_Btn1 01:00 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:14 0C:52 0D:63 0E:00 0F:00 11:C8 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 1A:00 1B:00 1C:00 1D:FF 1E:63 1F:00 81:00 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:14 8C:52 8D:63 8E:00 8F:00 91:C8 92:00 93:00 94:00 95:00 96:00 97:00 98:00 99:00 9A:00 9B:00 9C:00 9D:05 9E:63 9F:00 00:00
     2018-10-25 18:01:45   deviceMsg       off (to VCCU)
     2018-10-25 18:01:45   level           0
     2018-10-25 18:01:45   motor           stop:off
     2018-10-25 18:01:45   pct             0
     2018-10-21 00:24:08   peerList        VCCU_Btn1,
     2018-05-26 21:50:34   powerOn         2018-05-26 21:50:34
     2018-10-25 18:01:45   recentStateType info
     2018-10-25 18:01:45   state           off
     2018-10-25 18:01:45   timedOn         off
     2018-07-28 06:00:38   trigLast        VCCU_Btn1:short
     2018-07-28 06:00:38   trig_VCCU_Btn1  Short_1
   helper:
     HM_CMDNR   85
     cSnd       112424245F16C00201C8,112424245F16C0020100
     dlvlCmd    ++A0112424245F16C0020100
     mId        006A
     regLst     ,0,1,3p
     rxType     1
     supp_Pair_Rep 0
     ack:
     dir:
       cur        stop
       rct        down
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +5F16C0,00,01,00
       nextSend   1540483306.15374
       rxt        0
       vccu       VCCU
       p:
         5F16C0
         00
         01
         00
       prefIO:
         hmUART_Lan2
     mRssi:
       mNo        55
       io:
         hmUART_Lan1:
           -67
           -67
         hmUART_Lan2:
           -59
           -59
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       prs        1
     rpt:
       IO         hmUART_Lan2
       flg        A
       ts         1540483305.67816
       ack:
         HASH(0x4379330)
         5580022424245F16C000
     rssi:
       at_hmUART_Lan1:
         avg        -65.7894736842105
         cnt        38
         lst        -67
         max        -63
         min        -70
       at_hmUART_Lan2:
         avg        -61.2051282051282
         cnt        39
         lst        -63
         max        -56
         min        -74
       hmUART_Lan2:
         avg        -69.0526315789474
         cnt        19
         lst        -74
         max        -65
         min        -74
     tmpl:
Attributes:
   ASC        2
   ASC_Antifreeze off
   ASC_AutoAstroModeEvening CIVIL
   ASC_AutoAstroModeEveningHorizon none
   ASC_AutoAstroModeMorning REAL
   ASC_AutoAstroModeMorningHorizon none
   ASC_BrightnessMaxVal -1
   ASC_BrightnessMinVal 0.1
   ASC_Closed_Pos 0
   ASC_Direction 178
   ASC_Down   astro
   ASC_GuestRoom none
   ASC_Mode_Down always
   ASC_Mode_Up always
   ASC_Offset_Minutes_Evening 1
   ASC_Offset_Minutes_Morning 1
   ASC_Open_Pos 100
   ASC_Partymode off
   ASC_Pos_Cmd pct
   ASC_Pos_after_ComfortOpen 30
   ASC_Rand_Minutes 20
   ASC_Roommate_Device none
   ASC_Roommate_Reading state
   ASC_Self_Defense_Exclude off
   ASC_Shading off
   ASC_Shading_Angle_Left 85
   ASC_Shading_Angle_Right 85
   ASC_Shading_BlockingTime_After_Manual 20
   ASC_Shading_BlockingTime_Twilight 45
   ASC_Shading_Brightness_Reading luminosity
   ASC_Shading_Brightness_Sensor HM_D2018C
   ASC_Shading_Fast_Close none
   ASC_Shading_Fast_Open none
   ASC_Shading_Min_Elevation none
   ASC_Shading_Min_OutsideTemperature 18
   ASC_Shading_Pos 30
   ASC_Shading_Pos_after_Shading -1
   ASC_Shading_StateChange_Cloudy 4000
   ASC_Shading_StateChange_Sunny 6000
   ASC_Shading_WaitingPeriod 20
   ASC_Time_Down_Early 17:30
   ASC_Time_Down_Late 22:30
   ASC_Time_Up_Early 05:30
   ASC_Time_Up_Late 09:00
   ASC_Time_Up_WE_Holiday 08:30
   ASC_Up     brightness
   ASC_Ventilate_Pos 30
   ASC_Ventilate_Window_Open on
   ASC_WindowRec fenster_wohnzimmer1
   ASC_WindowRec_subType threestate
   ASC_lock-out soft
   ASC_lock-outCmd none
   IODev      hmUART_Lan2
   IOgrp      VCCU:hmUART_Lan2
   alias      Rollo Wohnzimmer Links
   autoReadReg 5_readMissing
   devStateIcon runter:shutter_closed 0:shutter_closed hoch:shutter_open 100:shutter_open .*:shutter_halfopen
   event-on-change-reading pct,state
   eventMap   /off:runter/ /on:hoch/ /pct 40:halb/ /pct 80:regen/ /stop:stop/
   expert     2_defReg+raw
   firmware   2.11
   group      Bedienung
   icon       fts_shutter_manual
   model      HM-LC-Bl1PBU-FM
   peerIDs    00000000,24242401,
   rollo_wg   rollo_wohnung
   rollo_wg_map pct:0:unten pct:100:oben pct:\b[1-9]\b:halb pct:\b[1-9][0-9]\b:halb
   room       CUL_HM,Wohnung
   serialNr   OEQ1298922
   subType    blindActuator
   userattr   ASC_Antifreeze:off,on ASC_AutoAstroModeEvening:REAL,CIVIL,NAUTIC,ASTRONOMIC,HORIZON ASC_AutoAstroModeEveningHorizon:-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9 ASC_AutoAstroModeMorning:REAL,CIVIL,NAUTIC,ASTRONOMIC,HORIZON ASC_AutoAstroModeMorningHorizon:-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9 ASC_BrightnessMaxVal ASC_BrightnessMinVal ASC_Closed_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_Direction ASC_Down:time,astro,brightness ASC_GuestRoom:on,off ASC_Mode_Down:absent,always,off ASC_Mode_Up:absent,always,off ASC_Offset_Minutes_Evening ASC_Offset_Minutes_Morning ASC_Open_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_Partymode:on,off ASC_Pos_Cmd ASC_Pos_after_ComfortOpen:0,10,20,30,40,50,60,70,80,90,100 ASC_Rand_Minutes ASC_Roommate_Device ASC_Roommate_Reading ASC_Self_Defense_Exclude:on,off ASC_Shading:on,off,delayed,present,absent ASC_Shading_Angle_Left:0,5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90 ASC_Shading_Angle_Right:0,5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90 ASC_Shading_BlockingTime_After_Manual ASC_Shading_BlockingTime_Twilight ASC_Shading_Brightness_Reading ASC_Shading_Brightness_Sensor ASC_Shading_Fast_Close:on,off ASC_Shading_Fast_Open:on,off ASC_Shading_Min_Elevation ASC_Shading_Min_OutsideTemperature ASC_Shading_Pos:10,20,30,40,50,60,70,80,90,100 ASC_Shading_Pos_after_Shading:-1,0,10,20,30,40,50,60,70,80,90,100 ASC_Shading_StateChange_Cloudy ASC_Shading_StateChange_Sunny ASC_Shading_WaitingPeriod ASC_Time_Down_Early ASC_Time_Down_Late ASC_Time_Up_Early ASC_Time_Up_Late ASC_Time_Up_WE_Holiday ASC_Up:time,astro,brightness ASC_Ventilate_Pos:10,20,30,40,50,60,70,80,90,100 ASC_Ventilate_Window_Open:on,off ASC_WindowRec ASC_WindowRec_subType:twostate,threestate ASC_lock-out:soft,hard ASC_lock-outCmd:inhibit,blocked rollo_wg rollo_wg_map structexclude
   webCmd     hoch:runter:halb:stop


Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 25 Oktober 2018, 19:24:29
Entscheidend ist was das Reading sagt
ASC_Time_DriveDown 25.10.2018 - 18:36
Dieses Rollo dürfte also noch nicht geschlossen sein gewesen.
Wenn Du ASC_AutoAstroModeXXX änderst musst Du die Zeiten neu berechnen lassen.
Also
set ASCDEVICE renewSetSunriseSunsetTimer


Grüße
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 25 Oktober 2018, 19:28:03
Zitat von: Karflyer am 24 Oktober 2018, 15:41:05
Bei dem Netatmo-Regenmesser gibt es das reading "rain". Das hat den Wert 0 wenn es nicht regnet oder Werte (Zahlen) > 0 wenn es regnet.

Stefan

Was wäre denn Deine Erfahrung, ab welchen Wert sollte man Rollos so schließen? Bei drei Tropfen Regen kommt dann gleich ein Wert größer Null? Also wenn was vom Baum tropft oder so?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Karflyer am 26 Oktober 2018, 10:17:05
Ich habe für das Fahren der Rolläden am Morgen 'ASC_UP' auf den Wert 'time' eingestellt. Zusätzlich ist ein 'roommate' am Rolladendevice eingetragen. Erhält der Status des 'roommate' am Morgen den Wert 'awoken' fahren die Rolläden wie gewünscht nach oben. Allerdings wird hierbei das Attribut 'ASC_Offset_Minutes_Morning' (Wert z.B. 5) wohl nicht berücksichtigt.
Alle betroffenen Rolläden fahren gleichzeitig hoch. Würde mich nicht stören, jedoch hat SOMFY in Verbindung mit einem CUL (SignalDuino) Schwierigkeiten wenn innerhalb kurzer Zeit zu viele Commandos gesendet werden. Das hat dann zur Folge, dass einzelne Rolläden ihr Kommando nicht empfangen. Könntest du bitte diesen Sachverhalt im Modul überprüfen. Die Attribute ASC_Offset_Minutes_Morning und ASC_Offset_Minutes_Evenening sollten auch im Modus 'time' für ASC_UP bzw. ASC_DOWN greifen.

Stefan
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 26 Oktober 2018, 10:42:23
Zitat von: Karflyer am 26 Oktober 2018, 10:17:05
Ich habe für das Fahren der Rolläden am Morgen 'ASC_UP' auf den Wert 'time' eingestellt. Zusätzlich ist ein 'roommate' am Rolladendevice eingetragen. Erhält der Status des 'roommate' am Morgen den Wert 'awoken' fahren die Rolläden wie gewünscht nach oben. Allerdings wird hierbei das Attribut 'ASC_Offset_Minutes_Morning' (Wert z.B. 5) wohl nicht berücksichtigt.
Alle betroffenen Rolläden fahren gleichzeitig hoch. Würde mich nicht stören, jedoch hat SOMFY in Verbindung mit einem CUL (SignalDuino) Schwierigkeiten wenn innerhalb kurzer Zeit zu viele Commandos gesendet werden. Das hat dann zur Folge, dass einzelne Rolläden ihr Kommando nicht empfangen. Könntest du bitte diesen Sachverhalt im Modul überprüfen. Die Attribute ASC_Offset_Minutes_Morning und ASC_Offset_Minutes_Evenening sollten auch im Modus 'time' für ASC_UP bzw. ASC_DOWN greifen.

Stefan

Ich habe das gerade mal geprüft. Bei mir klappt das alles wunderbar. Hattest Du nach dem ändern ein renewSet SunriseSunsetTimer gemacht?
Gib mal bitte ein list vom ASC Device und eines von 2 Rolläden wo Du time gesetzt hast.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Karflyer am 26 Oktober 2018, 11:22:53
ZitatHattest Du nach dem ändern ein renewSet SunriseSunsetTimer gemacht?

Da bin ich mir nicht sicher. Ich dachte, diese Aktion wäre nur notwendig, wenn man ASC_UP oder ASC_DOWN auf 'astro' stellt...
Werde das machen und Morgen früh beobachten, wie es läuft.
Hier aber trotzdem die gewünschten List:
ASC
Internals:
   MID        da39a3ee5e6b4b0d3255bfef95601890afd80709
   NAME       Rolladensteuerung
   NOTIFYDEV  global,Rolladensteuerung,sht_bz,sht_ezl,sht_ezr,sht_fo,sht_ft,sht_fz,sht_kc,sht_szl,sht_szr,sht_wz,sc_ezl,sc_ft,sc_wz,sc_bz,sc_fz,sc_szl,sc_ezr,rr_Simone,sc_kc,rgr_Residents,rr_Stefan,sc_fo
   NR         630
   NTFY_ORDER 50-Rolladensteuerung
   NotifyOrderPrefix 51-
   STATE      active
   TYPE       AutoShuttersControl
   VERSION    0.1.81
   OLDREADINGS:
   READINGS:
     2018-10-12 07:18:04   lockOut         off
     2018-10-12 07:18:04   partyMode       off
     2018-10-26 10:56:22   room_SOMFY      sht_bz,sht_ezl,sht_ezr,sht_fo,sht_ft,sht_fz,sht_kc,sht_szl,sht_szr,sht_wz
     2018-10-15 21:00:09   selfDefense     off
     2018-10-26 11:11:38   sht_bz_nextAstroTimeEvent 26.10.2018 - 18:51
     2018-10-26 11:11:38   sht_ezl_nextAstroTimeEvent 26.10.2018 - 18:51
     2018-10-26 11:11:38   sht_ezr_nextAstroTimeEvent 26.10.2018 - 18:54
     2018-10-26 11:11:38   sht_fo_nextAstroTimeEvent 26.10.2018 - 18:53
     2018-10-26 11:11:38   sht_ft_nextAstroTimeEvent 26.10.2018 - 18:54
     2018-10-26 11:11:38   sht_fz_nextAstroTimeEvent 26.10.2018 - 18:54
     2018-10-26 11:11:38   sht_kc_nextAstroTimeEvent 26.10.2018 - 18:54
     2018-10-26 11:11:39   sht_szl_nextAstroTimeEvent 26.10.2018 - 18:51
     2018-10-26 11:11:39   sht_szr_nextAstroTimeEvent 26.10.2018 - 18:53
     2018-10-26 11:11:39   sht_wz_nextAstroTimeEvent 26.10.2018 - 18:53
     2018-10-26 10:56:22   state           active
     2018-10-16 14:29:27   sunriseTimeWeHoliday on
     2018-10-26 10:56:22   userAttrList    rolled out
   helper:
     shuttersList:
       sht_bz
       sht_ezl
       sht_ezr
       sht_fo
       sht_ft
       sht_fz
       sht_kc
       sht_szl
       sht_szr
       sht_wz
   monitoredDevs:
     rgr_Residents:
       Rolladensteuerung ASC_residentsDevice
     rr_Simone:
       sht_bz     ASC_Roommate_Device
       sht_ezl    ASC_Roommate_Device
       sht_ezr    ASC_Roommate_Device
       sht_fo     ASC_Roommate_Device
       sht_ft     ASC_Roommate_Device
       sht_fz     ASC_Roommate_Device
       sht_kc     ASC_Roommate_Device
       sht_szl    ASC_Roommate_Device
       sht_szr    ASC_Roommate_Device
       sht_wz     ASC_Roommate_Device
     rr_Stefan:
       sht_bz     ASC_Roommate_Device
       sht_szl    ASC_Roommate_Device
       sht_szr    ASC_Roommate_Device
     sc_bz:
       sht_bz     ASC_WindowRec
     sc_ezl:
       sht_ezl    ASC_WindowRec
     sc_ezr:
       sht_ezr    ASC_WindowRec
     sc_fo:
       sht_fo     ASC_WindowRec
     sc_ft:
       sht_ft     ASC_WindowRec
     sc_fz:
       sht_fz     ASC_WindowRec
     sc_kc:
       sht_kc     ASC_WindowRec
     sc_szl:
       sht_szl    ASC_WindowRec
     sc_wz:
       sht_wz     ASC_WindowRec
Attributes:
   ASC_antifreezeTemp 3
   ASC_autoAstroModeEvening CIVIL
   ASC_autoAstroModeMorning CIVIL
   ASC_autoShuttersControlComfort on
   ASC_autoShuttersControlEvening on
   ASC_autoShuttersControlMorning on
   ASC_residentsDevice rgr_Residents
   ASC_residentsDeviceReading state
   ASC_sunElevationDevice myAstro
   ASC_sunElevationReading SunAlt
   ASC_sunPosDevice myAstro
   ASC_sunPosReading SunAz
   ASC_temperatureReading temperature
   ASC_temperatureSensor Terasse
   ASC_timeUpHolidayDevice dy_Urlaub
   icon       fts_shutter_automatic
   room       ASC
   verbose    3


Shutter
Internals:
   ADDRESS    000001
   CFGFN      /opt/fhem/FHEM/somfydevices.cfg
   DEF        000001 A8 01E8
   IODev      CUL_SOMFY
   NAME       sht_ezr
   NR         152
   STATE      open
   TYPE       SOMFY
   move       stop
   CODE:
     1          000001
   READINGS:
     2018-10-26 11:11:38   ASC_Time_DriveDown 26.10.2018 - 18:54
     2018-10-26 11:11:38   ASC_Time_DriveUp 27.10.2018 - 05:31
     2018-10-26 07:40:27   enc_key         A8
     2018-10-26 07:40:47   exact           0
     2018-10-26 07:40:47   position        0
     2018-10-26 07:40:27   rolling_code    01E8
     2018-10-26 07:40:47   state           open
Attributes:
   ASC        1
   ASC_Antifreeze off
   ASC_AutoAstroModeEvening none
   ASC_AutoAstroModeEveningHorizon none
   ASC_AutoAstroModeMorning none
   ASC_AutoAstroModeMorningHorizon none
   ASC_BrightnessMaxVal -1
   ASC_BrightnessMinVal -1
   ASC_Closed_Pos 200
   ASC_Direction 178
   ASC_Down   astro
   ASC_GuestRoom none
   ASC_Mode_Down always
   ASC_Mode_Up always
   ASC_Offset_Minutes_Evening 5
   ASC_Offset_Minutes_Morning 5
   ASC_Open_Pos 0
   ASC_Partymode off
   ASC_Pos_Cmd position
   ASC_Pos_after_ComfortOpen 20
   ASC_Rand_Minutes 20
   ASC_Roommate_Device rr_Simone
   ASC_Roommate_Reading state
   ASC_Self_Defense_Exclude off
   ASC_Shading off
   ASC_Shading_Angle_Left 85
   ASC_Shading_Angle_Right 85
   ASC_Shading_BlockingTime_After_Manual 20
   ASC_Shading_BlockingTime_Twilight 45
   ASC_Shading_Brightness_Reading brightness
   ASC_Shading_Brightness_Sensor none
   ASC_Shading_Fast_Close none
   ASC_Shading_Fast_Open none
   ASC_Shading_Min_Elevation none
   ASC_Shading_Min_OutsideTemperature 18
   ASC_Shading_Pos 50
   ASC_Shading_Pos_after_Shading -1
   ASC_Shading_StateChange_Cloudy 4000
   ASC_Shading_StateChange_Sunny 6000
   ASC_Shading_WaitingPeriod 20
   ASC_ShuttersPlace window
   ASC_Time_Down_Early 16:00
   ASC_Time_Down_Late 22:30
   ASC_Time_Up_Early 05:30
   ASC_Time_Up_Late 08:30
   ASC_Time_Up_WE_Holiday 08:00
   ASC_Up     time
   ASC_Ventilate_Pos 70
   ASC_Ventilate_Window_Open on
   ASC_WindowRec sc_ezr
   ASC_WindowRec_subType threestate
   ASC_lock-out soft
   ASC_lock-outCmd none
   IODev      CUL_SOMFY
   alias      Esszimmer (r)
   devStateIcon open|10:fts_shutter_10 20:fts_shutter_20 30:fts_shutter_30 40:fts_shutter_40 50:fts_shutter_50 60:fts_shutter_60 70:fts_shutter_70 80:fts_shutter_80 90:fts_shutter_90 100|down|closed:fts_shutter_100
   drive-down-time-to-100 16
   drive-down-time-to-close 19
   drive-up-time-to-100 3
   drive-up-time-to-open 20
   eventMap   /on:down/off:up/pos 60:go-my/
   group      SOMFY
   model      somfyshutter
   room       SOMFY
   sortby     01
   userattr   ASC_Antifreeze:off,on ASC_AutoAstroModeEvening:REAL,CIVIL,NAUTIC,ASTRONOMIC,HORIZON ASC_AutoAstroModeEveningHorizon:-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9 ASC_AutoAstroModeMorning:REAL,CIVIL,NAUTIC,ASTRONOMIC,HORIZON ASC_AutoAstroModeMorningHorizon:-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9 ASC_BrightnessMaxVal ASC_BrightnessMinVal ASC_Closed_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_Direction ASC_Down:time,astro,brightness ASC_GuestRoom:on,off ASC_Mode_Down:absent,always,off,home ASC_Mode_Up:absent,always,off,home ASC_Offset_Minutes_Evening ASC_Offset_Minutes_Morning ASC_Open_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_Partymode:on,off ASC_Pos_Cmd ASC_Pos_after_ComfortOpen:0,10,20,30,40,50,60,70,80,90,100 ASC_Rand_Minutes ASC_Roommate_Device ASC_Roommate_Reading ASC_Self_Defense_Exclude:on,off ASC_Shading:on,off,delayed,present,absent ASC_Shading_Angle_Left:0,5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90 ASC_Shading_Angle_Right:0,5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90 ASC_Shading_BlockingTime_After_Manual ASC_Shading_BlockingTime_Twilight ASC_Shading_Brightness_Reading ASC_Shading_Brightness_Sensor ASC_Shading_Fast_Close:on,off ASC_Shading_Fast_Open:on,off ASC_Shading_Min_Elevation ASC_Shading_Min_OutsideTemperature ASC_Shading_Pos:10,20,30,40,50,60,70,80,90,100 ASC_Shading_Pos_after_Shading:-1,0,10,20,30,40,50,60,70,80,90,100 ASC_Shading_StateChange_Cloudy ASC_Shading_StateChange_Sunny ASC_Shading_WaitingPeriod ASC_ShuttersPlace:window,terrace ASC_Time_Down_Early ASC_Time_Down_Late ASC_Time_Up_Early ASC_Time_Up_Late ASC_Time_Up_WE_Holiday ASC_Up:time,astro,brightness ASC_Ventilate_Pos:10,20,30,40,50,60,70,80,90,100 ASC_Ventilate_Window_Open:on,off ASC_WindowRec ASC_WindowRec_subType:twostate,threestate ASC_lock-out:soft,hard ASC_lock-outCmd:inhibit,blocked
   webCmd     down:stop:up:go-my
   widgetOverride position:slider,0,10,100


Noch ein Shutter
Internals:
   ADDRESS    000002
   CFGFN      /opt/fhem/FHEM/somfydevices.cfg
   DEF        000002 A1 0171
   IODev      CUL_SOMFY
   NAME       sht_ezl
   NR         154
   STATE      open
   TYPE       SOMFY
   move       stop
   CODE:
     1          000002
   READINGS:
     2018-10-26 11:11:38   ASC_Time_DriveDown 26.10.2018 - 18:51
     2018-10-26 11:11:38   ASC_Time_DriveUp 27.10.2018 - 05:32
     2018-10-26 07:40:27   enc_key         A1
     2018-10-26 07:40:47   exact           0
     2018-10-26 07:40:47   position        0
     2018-10-26 07:40:27   rolling_code    0171
     2018-10-26 07:40:47   state           open
Attributes:
   ASC        1
   ASC_Antifreeze off
   ASC_AutoAstroModeEvening none
   ASC_AutoAstroModeEveningHorizon none
   ASC_AutoAstroModeMorning none
   ASC_AutoAstroModeMorningHorizon none
   ASC_BrightnessMaxVal -1
   ASC_BrightnessMinVal -1
   ASC_Closed_Pos 200
   ASC_Direction 178
   ASC_Down   astro
   ASC_GuestRoom none
   ASC_Mode_Down always
   ASC_Mode_Up always
   ASC_Offset_Minutes_Evening 5
   ASC_Offset_Minutes_Morning 5
   ASC_Open_Pos 0
   ASC_Partymode off
   ASC_Pos_Cmd position
   ASC_Pos_after_ComfortOpen 20
   ASC_Rand_Minutes 20
   ASC_Roommate_Device rr_Simone
   ASC_Roommate_Reading state
   ASC_Self_Defense_Exclude off
   ASC_Shading off
   ASC_Shading_Angle_Left 85
   ASC_Shading_Angle_Right 85
   ASC_Shading_BlockingTime_After_Manual 20
   ASC_Shading_BlockingTime_Twilight 45
   ASC_Shading_Brightness_Reading brightness
   ASC_Shading_Brightness_Sensor none
   ASC_Shading_Fast_Close none
   ASC_Shading_Fast_Open none
   ASC_Shading_Min_Elevation none
   ASC_Shading_Min_OutsideTemperature 18
   ASC_Shading_Pos 50
   ASC_Shading_Pos_after_Shading -1
   ASC_Shading_StateChange_Cloudy 4000
   ASC_Shading_StateChange_Sunny 6000
   ASC_Shading_WaitingPeriod 20
   ASC_ShuttersPlace window
   ASC_Time_Down_Early 16:00
   ASC_Time_Down_Late 22:30
   ASC_Time_Up_Early 05:30
   ASC_Time_Up_Late 08:30
   ASC_Time_Up_WE_Holiday 08:00
   ASC_Up     time
   ASC_Ventilate_Pos 70
   ASC_Ventilate_Window_Open on
   ASC_WindowRec sc_ezl
   ASC_WindowRec_subType threestate
   ASC_lock-out soft
   ASC_lock-outCmd none
   IODev      CUL_SOMFY
   alias      Esszimmer (l)
   devStateIcon open|10:fts_shutter_10 20:fts_shutter_20 30:fts_shutter_30 40:fts_shutter_40 50:fts_shutter_50 60:fts_shutter_60 70:fts_shutter_70 80:fts_shutter_80 90:fts_shutter_90 100|down|closed:fts_shutter_100
   drive-down-time-to-100 16
   drive-down-time-to-close 19
   drive-up-time-to-100 3
   drive-up-time-to-open 20
   eventMap   /on:down/off:up/pos 60:go-my/
   model      somfyshutter
   room       SOMFY
   sortby     02
   userattr   ASC_Antifreeze:off,on ASC_AutoAstroModeEvening:REAL,CIVIL,NAUTIC,ASTRONOMIC,HORIZON ASC_AutoAstroModeEveningHorizon:-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9 ASC_AutoAstroModeMorning:REAL,CIVIL,NAUTIC,ASTRONOMIC,HORIZON ASC_AutoAstroModeMorningHorizon:-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9 ASC_BrightnessMaxVal ASC_BrightnessMinVal ASC_Closed_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_Direction ASC_Down:time,astro,brightness ASC_GuestRoom:on,off ASC_Mode_Down:absent,always,off,home ASC_Mode_Up:absent,always,off,home ASC_Offset_Minutes_Evening ASC_Offset_Minutes_Morning ASC_Open_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_Partymode:on,off ASC_Pos_Cmd ASC_Pos_after_ComfortOpen:0,10,20,30,40,50,60,70,80,90,100 ASC_Rand_Minutes ASC_Roommate_Device ASC_Roommate_Reading ASC_Self_Defense_Exclude:on,off ASC_Shading:on,off,delayed,present,absent ASC_Shading_Angle_Left:0,5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90 ASC_Shading_Angle_Right:0,5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90 ASC_Shading_BlockingTime_After_Manual ASC_Shading_BlockingTime_Twilight ASC_Shading_Brightness_Reading ASC_Shading_Brightness_Sensor ASC_Shading_Fast_Close:on,off ASC_Shading_Fast_Open:on,off ASC_Shading_Min_Elevation ASC_Shading_Min_OutsideTemperature ASC_Shading_Pos:10,20,30,40,50,60,70,80,90,100 ASC_Shading_Pos_after_Shading:-1,0,10,20,30,40,50,60,70,80,90,100 ASC_Shading_StateChange_Cloudy ASC_Shading_StateChange_Sunny ASC_Shading_WaitingPeriod ASC_ShuttersPlace:window,terrace ASC_Time_Down_Early ASC_Time_Down_Late ASC_Time_Up_Early ASC_Time_Up_Late ASC_Time_Up_WE_Holiday ASC_Up:time,astro,brightness ASC_Ventilate_Pos:10,20,30,40,50,60,70,80,90,100 ASC_Ventilate_Window_Open:on,off ASC_WindowRec ASC_WindowRec_subType:twostate,threestate ASC_lock-out:soft,hard ASC_lock-outCmd:inhibit,blocked
   webCmd     down:stop:up:go-my
   widgetOverride position:slider,0,10,100


Stefan
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 26 Oktober 2018, 11:48:54
Das sieht doch gut aus
Shutter 1

ASC_Time_DriveDown 26.10.2018 - 18:54
ASC_Time_DriveUp 27.10.2018 - 05:31


Shutter 2

ASC_Time_DriveDown 26.10.2018 - 18:51
ASC_Time_DriveUp 27.10.2018 - 05:32


Starten also Zeitversetzt. Aber das liegt daran das mittlerweile ein Neuberechnen stattgefunden hat denke ich. Wenn Du irgendwas an Zeiten oder sonstwie änderst was sich auf die Berechnung der Fahrzeiten auswirkt musst du immer den set Befehl im Anschluss machen.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Karflyer am 26 Oktober 2018, 12:21:23
ZitatAber das liegt daran das mittlerweile ein Neuberechnen stattgefunden hat denke ich. Wenn Du irgendwas an Zeiten oder sonstwie änderst was sich auf die Berechnung der Fahrzeiten auswirkt musst du immer den set Befehl im Anschluss machen.

OK. Werde ich beherzigen  ;). Danke dir.

Stefan
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 26 Oktober 2018, 12:24:02
Zitat von: Karflyer am 26 Oktober 2018, 12:21:23
OK. Werde ich beherzigen  ;). Danke dir.

Stefan

Ich werde mal schauen das ich in den nächsten Versionen es so mache das beim Verändern der Attribute das neu berechnen automatisch passiert.
Mal schauen wie das wird.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: C0mmanda am 27 Oktober 2018, 19:02:40
Gibt es eigentlich die Möglichkeit 2 Fensterkontakte zu hinterlegen oder muss ich dazu eine structure bauen?
Hintergrund: Ich habe bei meinen Doppelflügel-Fenstern nun die Fensterkontakte angeschlossen und der Rolladen
soll natürlich auf Lüften fahren, egal welcher Flügel geöffnet wird ;)

Danke!
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 27 Oktober 2018, 19:39:31
Zitat von: C0mmanda am 27 Oktober 2018, 19:02:40
Gibt es eigentlich die Möglichkeit 2 Fensterkontakte zu hinterlegen oder muss ich dazu eine structure bauen?
Hintergrund: Ich habe bei meinen Doppelflügel-Fenstern nun die Fensterkontakte angeschlossen und der Rolladen
soll natürlich auf Lüften fahren, egal welcher Flügel geöffnet wird ;)

Danke!

Da dann bitte mit einer Struktur arbeiten.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 27 Oktober 2018, 21:22:16
Ein neuer Eindruck
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: FunkOdyssey am 27 Oktober 2018, 23:11:20
Heute morgen wurde alle Jalousien um 08:57 hochgefahren.
Ich hatte bei den Jalousien UP="absent" eingestellt, aber keinen Roommate. Ich ging davon aus, dass dann das Residents-Device (der Gesamtanwesenheitsstatus) dann genutzt wird. Dies war wohl falsch. In der Doku steht, dass eigentlich gar nichts passieren sollte.

Es war zu dieser niemand mehr absent.
Der Zeitpunkt war nirgendwo eingestellt. Passt auch nicht zu "astro".

Kannst du mir mehr dazu sagen, wie sich absent oder vielleicht auch Home verhalten?
Die Doku scheint nicht korrekt zu sein, oder?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 27 Oktober 2018, 23:39:39
Ja das ist leider noch eine offene Baustelle. Ich weiß noch nicht genau wie ich das machen soll wenn kein Roommate vergeben ist. Es gab ja mal ein default wie es nur absent gab, aber nun gibt es ja auch noch home für Up und Down.
Da überlege ich noch.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 28 Oktober 2018, 07:35:22
Ich habe über Deine Idee mit Residents und den Gesamtstatus nach gedacht. Die Idee ist super, leider macht das mehr Abhängigkeit zu einem Residentsdevice oder einem Äquivalent. Ich würde das dennoch gerne so umsetzen. Was denkt Ihr?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 28 Oktober 2018, 07:59:32
Habe mal drüber nachgedacht und ich würde es so machen das wenn weder ein Roommate noch ein Residents Device angegeben ist es das selbe ist als wenn Up und Down always gesetzt sind.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: FunkOdyssey am 28 Oktober 2018, 09:55:10
Also irgendetwas stimmt noch nicht.
Ich kann meine Jalousien nur bis zum nächsten Brightness-Trigger runterfahren. Die werden von ASC immer wieder hochgefahren. Bereits mehrfach heute. Es ist Wochenende. Werktags ist mir das noch nicht aufgefallen, aber das war auch einige ASC-Versionen vorher und meistens waren die Jalousien dann auch schon manuell gefahren worden.

ModeUp ist überall "off"

Ich hab ein Verbose=5 Log; kann es aber über das Smartphone nicht verschicken.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 28 Oktober 2018, 10:34:39
Zitat von: FunkOdyssey am 28 Oktober 2018, 09:55:10
Also irgendetwas stimmt noch nicht.
Ich kann meine Jalousien nur bis zum nächsten Brightness-Trigger runterfahren. Die werden von ASC immer wieder hochgefahren. Bereits mehrfach heute. Es ist Wochenende. Werktags ist mir das noch nicht aufgefallen, aber das war auch einige ASC-Versionen vorher und meistens waren die Jalousien dann auch schon manuell gefahren worden.

ModeUp ist überall "off"

Ich hab ein Verbose=5 Log; kann es aber über das Smartphone nicht verschicken.

Bist Du innerhalb der Zeitgrenze wo die Devices fahren? Also early und late?
Ich schaue nachher mal. Aber wieso fährst Du die Rolläden wieder runter?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: FunkOdyssey am 28 Oktober 2018, 11:42:39
Time_Up_Early 08:00
Time_Up_WE 09:30
Time_Up 10:00
Mode_Up off
Up astro

Um 08:02 fuhren alle runter.
Dann habe ich es nur bis 09:22 Uhr ausprobiert und es meine manuelle Steuerung wurde mehrfach übersteuert. Zeitlich passt es zum Brightness-Trigger.

Ich habe manuell runtergefahren, weil
- die Jalousien eigentlich gar nicht hoch hätten sein dürfen
- und ich im Bad nicht gesehen werden möchte. 😀 (oder umgekehrt)
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 28 Oktober 2018, 11:49:24
Zitat von: FunkOdyssey am 28 Oktober 2018, 11:42:39
Time_Up_Early 08:00
Time_Up_WE 09:30
Time_Up 10:00
Mode_Up off
Up astro

Um 08:02 fuhren alle runter.
Dann habe ich es nur bis 09:22 Uhr ausprobiert und es meine manuelle Steuerung wurde mehrfach übersteuert. Zeitlich passt es zum Brightness-Trigger.

Ich habe manuell runtergefahren, weil
- die Jalousien eigentlich gar nicht hoch hätten sein dürfen
- und ich im Bad nicht gesehen werden möchte. 😀 (oder umgekehrt)

Ich habe einige Anpassungen vorgenommen Up und Down wurden bei Brightness nicht beachtet, habe ich nun geändert. Up WE wird nicht beachtet wenn Brightness triggert, da ist late und early nur wichtig und das muss auch so bleiben.
Ich könnte einen Marker setzen wenn der Rolladen einmal wegen Brightness und passender Zeit zwischen early und late gefahren ist. Dann fährt er aber auch nicht noch einmal.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: FunkOdyssey am 28 Oktober 2018, 11:54:22
Danke. Die Frage ich aber auch, warum die Jalousien überhaupt geöffnet wurden. 
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 28 Oktober 2018, 11:58:16
Ah jetzt sehe ich. Up steht bei Dir ja auf Astro, da hatte er gar nichts mit Brightness machen dürfen, laut deinen logs hat er das aber. Da muss ich noch eine Abfrage einbauen.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 28 Oktober 2018, 12:03:19
Gerade mal im Code geschaut, es gibt eine Abfrage. Aber! Du hast zwar für Up Astro drin aber für Down Brightness. Stimmts?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 28 Oktober 2018, 12:06:37
Habe das mal korrigiert und eine Zusätzliche Abfrage in der Brightness Routine ein gebaut. Sollte nun nicht mehr vorkommen
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Karflyer am 28 Oktober 2018, 12:09:25
ZitatDas sieht doch gut aus
Shutter 1
Code: [Auswählen]

ASC_Time_DriveDown 26.10.2018 - 18:54
ASC_Time_DriveUp 27.10.2018 - 05:31

Shutter 2
Code: [Auswählen]

ASC_Time_DriveDown 26.10.2018 - 18:51
ASC_Time_DriveUp 27.10.2018 - 05:32

Starten also Zeitversetz...

Ich habe das heute Morgen noch einmal beobachtet. Die Rolläden würden im time-Modus ASC_Offset_Minutes_Morning berücksichtigen und wie berechnet zeitversetzt hochfahren. Aber die warten schön brav auf den Roommate. Wenn der erwacht fahren alle betroffenen Rolläden auf einen schlag hoch, was nicht gewünscht ist.
Eigentlich müssten doch, um die ASC_Offset-Zeiten zu berücksichtigen, jedesmal bei Statuswechsel des Roommate die ASC_Time_DriveUP bzw. Down-Zeiten neu berechnet werden. Oder sehe ich das falsch?

Stefan
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 28 Oktober 2018, 12:49:56
Zitat von: Karflyer am 28 Oktober 2018, 12:09:25
Ich habe das heute Morgen noch einmal beobachtet. Die Rolläden würden im time-Modus ASC_Offset_Minutes_Morning berücksichtigen und wie berechnet zeitversetzt hochfahren. Aber die warten schön brav auf den Roommate. Wenn der erwacht fahren alle betroffenen Rolläden auf einen schlag hoch, was nicht gewünscht ist.
Eigentlich müssten doch, um die ASC_Offset-Zeiten zu berücksichtigen, jedesmal bei Statuswechsel des Roommate die ASC_Time_DriveUP bzw. Down-Zeiten neu berechnet werden. Oder sehe ich das falsch?

Stefan

Hallo Stefan,

Doch das ist so gewünscht. Beim Roommate wird ein versetztes fahren nicht berücksichtigt. Nur bei Zeitfahren wird das berücksichtigt. Von wie viel Rolläden reden wir denn hier die auf einmal fahren würden wenn Roommate aktiv wird?


Grüße
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: FunkOdyssey am 28 Oktober 2018, 13:30:06
Zitat von: CoolTux am 28 Oktober 2018, 12:03:19
Gerade mal im Code geschaut, es gibt eine Abfrage. Aber! Du hast zwar für Up Astro drin aber für Down Brightness. Stimmts?

Ja. Korrekt.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Karflyer am 28 Oktober 2018, 14:20:44
Bei mir fahren morgens alle Rolläden per 'time' wenn der/die Roommates wach sind, das sind dann im Summe 11 Stück.
Ich stehe morgens nicht immer genau zur gleichen Zeit auf. Deshalb ist die Steuerung per Roommate-Status genau das richtige.
Wie gesagt, wäre es mir persönlich egal, ob die Rolläden alle zur gleichen Zeit fahren, aber SOMFY mag das nicht so gerne  :(

Stefan
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 28 Oktober 2018, 14:33:32
Zitat von: Karflyer am 28 Oktober 2018, 14:20:44
Bei mir fahren morgens alle Rolläden per 'time' wenn der/die Roommates wach sind, das sind dann im Summe 11 Stück.
Ich stehe morgens nicht immer genau zur gleichen Zeit auf. Deshalb ist die Steuerung per Roommate-Status genau das richtige.
Wie gesagt, wäre es mir persönlich egal, ob die Rolläden alle zur gleichen Zeit fahren, aber SOMFY mag das nicht so gerne  :(

Stefan

Wenn Deine Rolläden per time fahren dann fahren sie auch asynchron. Ausser in den Räumen wo ein Roommate definiert ist und dieser Roommate schläft. Mal ne Frage, hast Du in allen Räumen Roommates definiert?
Wenn ja ist das so nicht gewollt. Die Roommates sind für Schlafräume, also da wo die Rolläden nicht fahren sollen obwohl die Zeit dafür da wäre aber die Leute in den Räumen noch schlafen. Und das sollten dann ja keine 11 sein, sondern höchsten 4 oder so. Bei mir sind es genau immer 2. Im Schlafzimmer und in 2 Kinderzimmern. Die Eltern stehen meist gleich auf wie ein Kind, also fahren 4 Rolläden, aber auch nicht ganz genau synchrone. Es bleiben also genau 2 Rolläden die immer zusammen fahren.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag 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.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Papaloewe am 28 Oktober 2018, 17:29:43
ZitatDaher war für mich immer genau das Roommate-awoken, der ideale Trigger um alle Rolläden hoch zu fahren.

Was 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.ä.?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 28 Oktober 2018, 17:40:43
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.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Karflyer am 28 Oktober 2018, 17:43:07
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 .
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Karflyer am 28 Oktober 2018, 17:51:44
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
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 28 Oktober 2018, 18:03:21
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?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Karflyer am 28 Oktober 2018, 20:38:57
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.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 29 Oktober 2018, 04:44:02
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
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 29 Oktober 2018, 05:08:09
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?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 29 Oktober 2018, 09:03:41
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...
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 29 Oktober 2018, 09:10:47
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?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Cluni am 29 Oktober 2018, 09:14:10
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.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Cluni am 29 Oktober 2018, 09:16:13
Also ich meine die Einstellung am Rollladen selber.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 29 Oktober 2018, 09:59:10
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.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Cluni am 29 Oktober 2018, 10:01:06
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...
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Karflyer am 29 Oktober 2018, 10:01:24
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.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Karflyer am 29 Oktober 2018, 10:03:26
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.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 29 Oktober 2018, 10:11:20
Zitat von: Karflyer am 29 Oktober 2018, 10:01:24
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.

So habe ich mir Beschattung nicht vorgestellt. Die Rolläden fahren erst runter in die Beschattung wenn die Sonne auf das entsprechende Fenster scheint und eine gewisse Temperatur überschritten würde.
Bei mir zum Beispiel Nachmittag ab 13:30 im Sommer. Doch da ist keiner zu Hause in der Woche und ich habe für alle Rolläden home eingestellt. Dennoch möchte ich das beschattet wird damit die Räume nicht aufheizen.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 29 Oktober 2018, 10:11:43
@all
Was sind so Eure maximalen Fahrzeiten der Rolläden?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Cluni am 29 Oktober 2018, 10:13:25
Ich glaube die längste Fahrzeit ist bei mir 32s oder so.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: FunkOdyssey am 29 Oktober 2018, 10:15:03
Hier: Max. 28sec
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 29 Oktober 2018, 10:18:02
Dann gehe ich jetzt mal davon aus das kein Rolladen mehr wie 40s zum kompletten fahren benötigt.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Cluni am 29 Oktober 2018, 10:19:12
Warum willst du das begrenzen?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 29 Oktober 2018, 10:26:40
Nein nicht begrenzen. Ich möchte gerne ein Reading setzen, ok eigentlich mache ich es schon, welches im Rolladen angibt wieso er gefahren wurde. ASC schreibt als Value da diverse Dinge in das Reading wenn es selbst gesteuert hat. z.B. roommate awoken, rain protected und so weiter.
Wenn aber der Rolladen von Hand gefahren wurde, so steht da manual drin. Aber genau da muss ich unterschieden. Wenn ASC einen Fahrbefehl sendet kommt nach erreichen der Position ja ein Event vom Rolladen, dieses Event wertet ASC aus, ist dieser Event größer 40s älter wie der Timestamp vom ASC Fahrbefehl wird davon ausgegangen das der Fahrbefehl von Hand kam oder besser nicht von ASC.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Cluni am 29 Oktober 2018, 10:32:55
Das ist der Grund, warum bei mir im Skript ein Merker gesetzt wird, wenn ein Befehl vom Skript gesendet wird. Beim Event werte ich das einfach aus. Wenn da eine 0 drin steht, dann war es eine manuelle Aktion über Taster oder über die Oberfläche. Kannst du dir doch auch intern merken, oder? Die Timestamps auszuwerten wäre mir dazu zu unsicher. Überlege mal, wie einfach man den Raspi eine Zeit lang weghängen kann, wenn man das will. Wenn jemand da unsauber in einem Modul/DoIF/... programmiert hat, dann kann das schon mal vorkommen...
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: marvin78 am 29 Oktober 2018, 10:33:43
Ich hasse solche "Annahmen". Es gibt sicher Rollläden die deutlich länger fahren. Frei konfigurierbar kann man sowas machen, aber 40s als feste Grenze ist natürlich Quatsch.

"größer als" ... ;)
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Cluni am 29 Oktober 2018, 10:38:50
Wenn du es unbedingt so machen willst, dann könnte man den Wert (zumindest bei HM) von allen Aktoren auslesen und den größten plus Puffer nehmen...
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 29 Oktober 2018, 11:00:42
Ich würde da einfach mal abwarten wie der Erfahrungswert sein wird.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 29 Oktober 2018, 11:37:58
Zitat von: CoolTux am 29 Oktober 2018, 10:18:02
Dann gehe ich jetzt mal davon aus das kein Rolladen mehr wie 40s zum kompletten fahren benötigt.
M.E. zu wenig: habe Jalousien, die ca. 1 Min. laufen.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 29 Oktober 2018, 11:42:52
Zitat von: Beta-User am 29 Oktober 2018, 11:37:58
M.E. zu wenig: habe Jalousien, die ca. 1 Min. laufen.

Würde denn > 60s bei Dir reichen?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 29 Oktober 2018, 11:49:15
Vermutlich.
Aber grundsätzlich fände ich es besser, bei Aktortypen, die die max. Fahrzeiten als Reading preisgeben, diesen auch zu verwenden (+kleine Zugabe, da up u. down unterschiedlich sein können/sind). Den Wert könnte man ja einmalig für jeden Aktor intern ermitteln und speichern/verwalten.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 29 Oktober 2018, 12:47:56
Zitat von: Beta-User am 29 Oktober 2018, 11:49:15
Vermutlich.
Aber grundsätzlich fände ich es besser, bei Aktortypen, die die max. Fahrzeiten als Reading preisgeben, diesen auch zu verwenden (+kleine Zugabe, da up u. down unterschiedlich sein können/sind). Den Wert könnte man ja einmalig für jeden Aktor intern ermitteln und speichern/verwalten.

Ist denn das Reading bei allen Aktoren gleich? Denke eher nicht.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 29 Oktober 2018, 12:51:43
Bei allen hn-typen dürften die beiden Readings gleich sein; ähnliches ist bei gängigen zwave und enocean- Aktoren zu vermuten. (Ist schon klar, dass das Aufwand ist...; nur eben von vornherein korrekt bzw. as good as it gets...)
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Cluni am 29 Oktober 2018, 12:52:15
Hinterlege doch einfach einen Merker im ASC-Device für den Rollladen, den du gerade automatisch bewegst und schau dort beim Event nach und lösche es wieder. Was spricht dagegen?
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Beta-User am 29 Oktober 2018, 12:57:28
Zitat von: Cluni am 29 Oktober 2018, 12:52:15
Hinterlege doch einfach einen Merker im ASC-Device für den Rollladen, den du gerade automatisch bewegst und schau dort beim Event nach und lösche es wieder. Was spricht dagegen?
Noch einfacher: merke die letzte asc-Zielposition. Aktuelle Position gleich? Annahme: Ursache=ASC...

Zur Klarstellung: die Redings heißen gleich, der Wert ist es nicht zwangsläufig (idR. gruppenweise gleich, z.B. 3 von 4 Jalousien)
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 29 Oktober 2018, 13:10:48
Gute Vorschläge. Ich schaue es mir an.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: sentinel1 am 29 Oktober 2018, 17:29:06
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.

Zitat von: Karflyer am 29 Oktober 2018, 10:03:26
Das passt doch super und bietet das Maximum an Flexibilität.

bin der gleichen Meinung wie @Karflyer

ZitatSo habe ich mir Beschattung nicht vorgestellt. Die Rolläden fahren erst runter in die Beschattung wenn die Sonne auf das entsprechende Fenster scheint und eine gewisse Temperatur überschritten würde.
Bei mir zum Beispiel Nachmittag ab 13:30 im Sommer. Doch da ist keiner zu Hause in der Woche und ich habe für alle Rolläden home eingestellt. Dennoch möchte ich das beschattet wird damit die Räume nicht aufheizen.

so läuft die Beschattung auch bei mir,über Sone/Helligkeit und Temperatur.Unabhängig von An/Abwesenheit.


Edit: Ich habe gearde festgestellt das bei mir die Lüften Funktion nicht mehr geht.Die Rollos sind heruntergefahren,wenn ich
jetzt einen Fenster öffne geht der Rollo nicht mehr in Lüftung Stellung.Kann sein das ich was verstellt habe da ich die letzten tage verschiedene Einstellungen probiert habe.


Ich hänge mal ein List vom Rollo an.

Internals:
   DEF        565739
   IODev      hmUART_Lan2
   LASTInputDev hmUART_Lan2
   MSGCNT     2
   NAME       rollo1_bad
   NOTIFYDEV  global
   NR         375
   NTFY_ORDER 50-rollo1_bad
   STATE      runter
   TYPE       CUL_HM
   hmUART_Lan1_MSGCNT 1
   hmUART_Lan1_RAWMSG 0500003CDCA4105657392424240601000063
   hmUART_Lan1_RSSI -60
   hmUART_Lan1_TIME 2018-10-29 18:17:49
   hmUART_Lan2_MSGCNT 1
   hmUART_Lan2_RAWMSG 05010045DCA4105657392424240601000063
   hmUART_Lan2_RSSI -69
   hmUART_Lan2_TIME 2018-10-29 18:17:49
   lastMsg    No:DC - t:10 s:565739 d:242424 0601000063
   peerList   VCCU_Btn1,
   protCmdDel 2
   protIOerr  1 last_at:2018-10-29 17:47:50
   protLastRcv 2018-10-29 18:17:49
   protRcv    1 last_at:2018-10-29 18:17:49
   protSnd    2 last_at:2018-10-29 18:17:49
   protState  CMDs_done
   rssi_at_hmUART_Lan1 cnt:1 min:-60 max:-60 avg:-60 lst:-60
   rssi_at_hmUART_Lan2 cnt:1 min:-69 max:-69 avg:-69 lst:-69
   rssi_hmUART_Lan2 cnt:1 min:-99 max:-99 avg:-99 lst:-99
   READINGS:
     2018-10-29 17:47:20   ASC_Time_DriveDown 30.10.2018 - 17:30
     2018-10-29 17:47:20   ASC_Time_DriveUp 30.10.2018 - 06:55
     2018-10-29 17:30:46   CommandAccepted yes
     2017-12-07 09:03:36   D-firmware      2.11
     2017-12-07 09:03:36   D-serialNr      OEQ0291657
     2018-06-05 20:42:02   PairedTo        0x242424
     2017-12-21 22:58:36   R-VCCU_Btn1-lgActionType jmpToTarget
     2017-12-21 22:58:36   R-VCCU_Btn1-lgOnLevel 100 %
     2017-12-21 22:58:36   R-VCCU_Btn1-shActionType jmpToTarget
     2017-12-21 22:58:36   R-VCCU_Btn1-shOnLevel 100 %
     2017-12-07 09:14:05   R-driveDown     27 s
     2017-12-07 09:03:42   R-driveTurn     0.5 s
     2017-12-07 09:13:36   R-driveUp       26 s
     2017-12-07 09:03:41   R-pairCentral   0x242424
     2017-12-07 09:03:42   R-powerUpAction off
     2017-12-07 09:03:42   R-sign          off
     2018-06-05 20:42:02   RegL_00.        02:01 0A:24 0B:24 0C:24 15:FF 18:00 00:00
     2018-06-05 20:42:03   RegL_01.        08:00 09:00 0A:00 0B:01 0C:0E 0D:01 0E:04 0F:05 10:00  30:06 57:24 56:00 00:00
     2018-06-05 20:42:05   RegL_03.VCCU_Btn1 01:00 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:14 0C:52 0D:63 0E:00 0F:00 11:C8 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 1A:00 1B:00 1C:00 1D:FF 1E:63 1F:00 81:00 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:14 8C:52 8D:63 8E:00 8F:00 91:C8 92:00 93:00 94:00 95:00 96:00 97:00 98:00 99:00 9A:00 9B:00 9C:00 9D:05 9E:63 9F:00 00:00
     2018-10-29 18:17:49   deviceMsg       off (to VCCU)
     2018-10-29 18:17:49   level           0
     2018-10-29 18:17:49   motor           stop:off
     2018-10-29 18:17:49   pct             0
     2018-10-29 17:46:40   peerList        VCCU_Btn1,
     2018-06-05 20:42:01   powerOn         2018-06-05 20:42:01
     2018-10-29 18:17:49   recentStateType info
     2018-10-29 18:17:49   state           off
     2018-10-29 18:17:49   timedOn         off
     2018-07-28 06:00:37   trigLast        VCCU_Btn1:short
     2018-07-28 06:00:37   trig_VCCU_Btn1  Short_1
   helper:
     HM_CMDNR   220
     cSnd       ,01242424565739010E
     mId        006A
     regLst     ,0,1,3p
     rxType     1
     supp_Pair_Rep 0
     ack:
     dir:
       cur        stop
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +565739,00,01,00
       nextSend   1540833469.99662
       rxt        0
       vccu       VCCU
       p:
         565739
         00
         01
         00
       prefIO:
         hmUART_Lan2
     mRssi:
       mNo        DC
       io:
         hmUART_Lan1:
           -60
           -60
         hmUART_Lan2:
           -65
           -65
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       prs        1
     rpt:
       IO         hmUART_Lan1
       flg        A
       ts         1540833469.54775
       ack:
         HASH(0x466e418)
         DC800224242456573900
     rssi:
       at_hmUART_Lan1:
         avg        -60
         cnt        1
         lst        -60
         max        -60
         min        -60
       at_hmUART_Lan2:
         avg        -69
         cnt        1
         lst        -69
         max        -69
         min        -69
       hmUART_Lan2:
         avg        -99
         cnt        1
         lst        -99
         max        -99
         min        -99
     tmpl:
Attributes:
   ASC        2
   ASC_Antifreeze off
   ASC_AutoAstroModeEvening CIVIL
   ASC_AutoAstroModeEveningHorizon none
   ASC_AutoAstroModeMorning REAL
   ASC_AutoAstroModeMorningHorizon none
   ASC_BrightnessMaxVal -1
   ASC_BrightnessMinVal -1
   ASC_Closed_Pos 0
   ASC_Direction 178
   ASC_Down   astro
   ASC_GuestRoom none
   ASC_Mode_Down always
   ASC_Mode_Up always
   ASC_Offset_Minutes_Evening 1
   ASC_Offset_Minutes_Morning 1
   ASC_Open_Pos 100
   ASC_Partymode off
   ASC_Pos_Cmd pct
   ASC_Pos_after_ComfortOpen 30
   ASC_Rand_Minutes 20
   ASC_Roommate_Device none
   ASC_Roommate_Reading state
   ASC_Self_Defense_Exclude off
   ASC_Shading off
   ASC_Shading_Angle_Left 85
   ASC_Shading_Angle_Right 85
   ASC_Shading_BlockingTime_After_Manual 20
   ASC_Shading_BlockingTime_Twilight 45
   ASC_Shading_Brightness_Reading brightness
   ASC_Shading_Brightness_Sensor none
   ASC_Shading_Fast_Close none
   ASC_Shading_Fast_Open none
   ASC_Shading_Min_Elevation none
   ASC_Shading_Min_OutsideTemperature 18
   ASC_Shading_Pos 30
   ASC_Shading_Pos_after_Shading -1
   ASC_Shading_StateChange_Cloudy 4000
   ASC_Shading_StateChange_Sunny 6000
   ASC_Shading_WaitingPeriod 20
   ASC_ShuttersPlace window
   ASC_Time_Down_Early 17:30
   ASC_Time_Down_Late 22:30
   ASC_Time_Up_Early 05:30
   ASC_Time_Up_Late 09:00
   ASC_Time_Up_WE_Holiday 08:30
   ASC_Up     astro
   ASC_Ventilate_Pos 30
   ASC_Ventilate_Window_Open on
   ASC_WindowRec fenster_bad
   ASC_WindowRec_subType threestate
   ASC_lock-out soft
   ASC_lock-outCmd none
   IODev      hmUART_Lan2
   IOgrp      VCCU:hmUART_Lan2
   alias      Rollo Bad
   autoReadReg 5_readMissing
   devStateIcon runter:shutter_closed 0:shutter_closed hoch:shutter_open 100:shutter_open .*:shutter_halfopen
   event-on-change-reading pct,state
   eventMap   /off:runter/ /on:hoch/ /pct 40:halb/ /pct 80:regen/ /stop:stop/
   expert     2_raw
   firmware   2.11
   group      Bedienung
   icon       fts_shutter_manual
   model      HM-LC-Bl1PBU-FM
   peerIDs    00000000,24242401,
   rollo_wg   rollo_wohnung
   rollo_wg_map pct:0:unten pct:100:oben pct:\b[1-9]\b:halb pct:\b[1-9][0-9]\b:halb
   room       CUL_HM,Wohnung
   serialNr   OEQ0291657
   subType    blindActuator
   userattr   ASC_Antifreeze:off,on ASC_AutoAstroModeEvening:REAL,CIVIL,NAUTIC,ASTRONOMIC,HORIZON ASC_AutoAstroModeEveningHorizon:-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9 ASC_AutoAstroModeMorning:REAL,CIVIL,NAUTIC,ASTRONOMIC,HORIZON ASC_AutoAstroModeMorningHorizon:-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9 ASC_BrightnessMaxVal ASC_BrightnessMinVal ASC_Closed_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_Direction ASC_Down:time,astro,brightness ASC_GuestRoom:on,off ASC_Mode_Down:absent,always,off,home ASC_Mode_Up:absent,always,off,home ASC_Offset_Minutes_Evening ASC_Offset_Minutes_Morning ASC_Open_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_Partymode:on,off ASC_Pos_Cmd ASC_Pos_after_ComfortOpen:0,10,20,30,40,50,60,70,80,90,100 ASC_Rand_Minutes ASC_Roommate_Device ASC_Roommate_Reading ASC_Self_Defense_Exclude:on,off ASC_Shading:on,off,delayed,present,absent ASC_Shading_Angle_Left:0,5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90 ASC_Shading_Angle_Right:0,5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90 ASC_Shading_BlockingTime_After_Manual ASC_Shading_BlockingTime_Twilight ASC_Shading_Brightness_Reading ASC_Shading_Brightness_Sensor ASC_Shading_Fast_Close:on,off ASC_Shading_Fast_Open:on,off ASC_Shading_Min_Elevation ASC_Shading_Min_OutsideTemperature ASC_Shading_Pos:10,20,30,40,50,60,70,80,90,100 ASC_Shading_Pos_after_Shading:-1,0,10,20,30,40,50,60,70,80,90,100 ASC_Shading_StateChange_Cloudy ASC_Shading_StateChange_Sunny ASC_Shading_WaitingPeriod ASC_ShuttersPlace:window,terrace ASC_Time_Down_Early ASC_Time_Down_Late ASC_Time_Up_Early ASC_Time_Up_Late ASC_Time_Up_WE_Holiday ASC_Up:time,astro,brightness ASC_Ventilate_Pos:10,20,30,40,50,60,70,80,90,100 ASC_Ventilate_Window_Open:on,off ASC_WindowRec ASC_WindowRec_subType:twostate,threestate ASC_lock-out:soft,hard ASC_lock-outCmd:inhibit,blocked rollo_wg rollo_wg_map structexclude
   webCmd     hoch:runter:halb:stop


Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 30 Oktober 2018, 08:31:31
@all
Ich habe soeben Version 0.1.83 ins Git geladen.
- Regensensor support
- Beachtung von komme nach Hause und gehe ausser Haus wenn ASC_Down/Up home oder absent engestellt ist.
- die Informationsanzeige wurde ausgebaut/umgebaut
- Anzeige get und set für NOTIFYDEV erfolgt nur bei verbose > 3
- eine Menge Bugfixes (hoffe ich)
- großer Umbau für das zeitversetzte fahren der Rollos Offset

Ich habe sehr viel getestet die letzten Tage. Denke aber nicht das ich alles mögliche Abgedeckt habe, irgendwas ist ja immer. Von daher egal wie klein Eure Beobachtung Euch erscheint, meldet bitte erstmal.

Denkt bitte daran das Ihr Offset neu setzen müsst da neues Attribut. Entweder am Rolladen oder eben global beim ASC Device

Grüße
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 30 Oktober 2018, 08:34:04
Zitat von: sentinel1 am 29 Oktober 2018, 17:29:06
Ich habe gearde festgestellt das bei mir die Lüften Funktion nicht mehr geht.Die Rollos sind heruntergefahren,wenn ich
jetzt einen Fenster öffne geht der Rollo nicht mehr in Lüftung Stellung.Kann sein das ich was verstellt habe da ich die letzten tage verschiedene Einstellungen probiert habe.


Ich hänge mal ein List vom Rollo an.

Internals:
   DEF        565739
   IODev      hmUART_Lan2
   LASTInputDev hmUART_Lan2
   MSGCNT     2
   NAME       rollo1_bad
   NOTIFYDEV  global
   NR         375
   NTFY_ORDER 50-rollo1_bad
   STATE      runter
   TYPE       CUL_HM
   hmUART_Lan1_MSGCNT 1
   hmUART_Lan1_RAWMSG 0500003CDCA4105657392424240601000063
   hmUART_Lan1_RSSI -60
   hmUART_Lan1_TIME 2018-10-29 18:17:49
   hmUART_Lan2_MSGCNT 1
   hmUART_Lan2_RAWMSG 05010045DCA4105657392424240601000063
   hmUART_Lan2_RSSI -69
   hmUART_Lan2_TIME 2018-10-29 18:17:49
   lastMsg    No:DC - t:10 s:565739 d:242424 0601000063
   peerList   VCCU_Btn1,
   protCmdDel 2
   protIOerr  1 last_at:2018-10-29 17:47:50
   protLastRcv 2018-10-29 18:17:49
   protRcv    1 last_at:2018-10-29 18:17:49
   protSnd    2 last_at:2018-10-29 18:17:49
   protState  CMDs_done
   rssi_at_hmUART_Lan1 cnt:1 min:-60 max:-60 avg:-60 lst:-60
   rssi_at_hmUART_Lan2 cnt:1 min:-69 max:-69 avg:-69 lst:-69
   rssi_hmUART_Lan2 cnt:1 min:-99 max:-99 avg:-99 lst:-99
   READINGS:
     2018-10-29 17:47:20   ASC_Time_DriveDown 30.10.2018 - 17:30
     2018-10-29 17:47:20   ASC_Time_DriveUp 30.10.2018 - 06:55
     2018-10-29 17:30:46   CommandAccepted yes
     2017-12-07 09:03:36   D-firmware      2.11
     2017-12-07 09:03:36   D-serialNr      OEQ0291657
     2018-06-05 20:42:02   PairedTo        0x242424
     2017-12-21 22:58:36   R-VCCU_Btn1-lgActionType jmpToTarget
     2017-12-21 22:58:36   R-VCCU_Btn1-lgOnLevel 100 %
     2017-12-21 22:58:36   R-VCCU_Btn1-shActionType jmpToTarget
     2017-12-21 22:58:36   R-VCCU_Btn1-shOnLevel 100 %
     2017-12-07 09:14:05   R-driveDown     27 s
     2017-12-07 09:03:42   R-driveTurn     0.5 s
     2017-12-07 09:13:36   R-driveUp       26 s
     2017-12-07 09:03:41   R-pairCentral   0x242424
     2017-12-07 09:03:42   R-powerUpAction off
     2017-12-07 09:03:42   R-sign          off
     2018-06-05 20:42:02   RegL_00.        02:01 0A:24 0B:24 0C:24 15:FF 18:00 00:00
     2018-06-05 20:42:03   RegL_01.        08:00 09:00 0A:00 0B:01 0C:0E 0D:01 0E:04 0F:05 10:00  30:06 57:24 56:00 00:00
     2018-06-05 20:42:05   RegL_03.VCCU_Btn1 01:00 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:14 0C:52 0D:63 0E:00 0F:00 11:C8 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 1A:00 1B:00 1C:00 1D:FF 1E:63 1F:00 81:00 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:14 8C:52 8D:63 8E:00 8F:00 91:C8 92:00 93:00 94:00 95:00 96:00 97:00 98:00 99:00 9A:00 9B:00 9C:00 9D:05 9E:63 9F:00 00:00
     2018-10-29 18:17:49   deviceMsg       off (to VCCU)
     2018-10-29 18:17:49   level           0
     2018-10-29 18:17:49   motor           stop:off
     2018-10-29 18:17:49   pct             0
     2018-10-29 17:46:40   peerList        VCCU_Btn1,
     2018-06-05 20:42:01   powerOn         2018-06-05 20:42:01
     2018-10-29 18:17:49   recentStateType info
     2018-10-29 18:17:49   state           off
     2018-10-29 18:17:49   timedOn         off
     2018-07-28 06:00:37   trigLast        VCCU_Btn1:short
     2018-07-28 06:00:37   trig_VCCU_Btn1  Short_1
   helper:
     HM_CMDNR   220
     cSnd       ,01242424565739010E
     mId        006A
     regLst     ,0,1,3p
     rxType     1
     supp_Pair_Rep 0
     ack:
     dir:
       cur        stop
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +565739,00,01,00
       nextSend   1540833469.99662
       rxt        0
       vccu       VCCU
       p:
         565739
         00
         01
         00
       prefIO:
         hmUART_Lan2
     mRssi:
       mNo        DC
       io:
         hmUART_Lan1:
           -60
           -60
         hmUART_Lan2:
           -65
           -65
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       prs        1
     rpt:
       IO         hmUART_Lan1
       flg        A
       ts         1540833469.54775
       ack:
         HASH(0x466e418)
         DC800224242456573900
     rssi:
       at_hmUART_Lan1:
         avg        -60
         cnt        1
         lst        -60
         max        -60
         min        -60
       at_hmUART_Lan2:
         avg        -69
         cnt        1
         lst        -69
         max        -69
         min        -69
       hmUART_Lan2:
         avg        -99
         cnt        1
         lst        -99
         max        -99
         min        -99
     tmpl:
Attributes:
   ASC        2
   ASC_Antifreeze off
   ASC_AutoAstroModeEvening CIVIL
   ASC_AutoAstroModeEveningHorizon none
   ASC_AutoAstroModeMorning REAL
   ASC_AutoAstroModeMorningHorizon none
   ASC_BrightnessMaxVal -1
   ASC_BrightnessMinVal -1
   ASC_Closed_Pos 0
   ASC_Direction 178
   ASC_Down   astro
   ASC_GuestRoom none
   ASC_Mode_Down always
   ASC_Mode_Up always
   ASC_Offset_Minutes_Evening 1
   ASC_Offset_Minutes_Morning 1
   ASC_Open_Pos 100
   ASC_Partymode off
   ASC_Pos_Cmd pct
   ASC_Pos_after_ComfortOpen 30
   ASC_Rand_Minutes 20
   ASC_Roommate_Device none
   ASC_Roommate_Reading state
   ASC_Self_Defense_Exclude off
   ASC_Shading off
   ASC_Shading_Angle_Left 85
   ASC_Shading_Angle_Right 85
   ASC_Shading_BlockingTime_After_Manual 20
   ASC_Shading_BlockingTime_Twilight 45
   ASC_Shading_Brightness_Reading brightness
   ASC_Shading_Brightness_Sensor none
   ASC_Shading_Fast_Close none
   ASC_Shading_Fast_Open none
   ASC_Shading_Min_Elevation none
   ASC_Shading_Min_OutsideTemperature 18
   ASC_Shading_Pos 30
   ASC_Shading_Pos_after_Shading -1
   ASC_Shading_StateChange_Cloudy 4000
   ASC_Shading_StateChange_Sunny 6000
   ASC_Shading_WaitingPeriod 20
   ASC_ShuttersPlace window
   ASC_Time_Down_Early 17:30
   ASC_Time_Down_Late 22:30
   ASC_Time_Up_Early 05:30
   ASC_Time_Up_Late 09:00
   ASC_Time_Up_WE_Holiday 08:30
   ASC_Up     astro
   ASC_Ventilate_Pos 30
   ASC_Ventilate_Window_Open on
   ASC_WindowRec fenster_bad
   ASC_WindowRec_subType threestate
   ASC_lock-out soft
   ASC_lock-outCmd none
   IODev      hmUART_Lan2
   IOgrp      VCCU:hmUART_Lan2
   alias      Rollo Bad
   autoReadReg 5_readMissing
   devStateIcon runter:shutter_closed 0:shutter_closed hoch:shutter_open 100:shutter_open .*:shutter_halfopen
   event-on-change-reading pct,state
   eventMap   /off:runter/ /on:hoch/ /pct 40:halb/ /pct 80:regen/ /stop:stop/
   expert     2_raw
   firmware   2.11
   group      Bedienung
   icon       fts_shutter_manual
   model      HM-LC-Bl1PBU-FM
   peerIDs    00000000,24242401,
   rollo_wg   rollo_wohnung
   rollo_wg_map pct:0:unten pct:100:oben pct:\b[1-9]\b:halb pct:\b[1-9][0-9]\b:halb
   room       CUL_HM,Wohnung
   serialNr   OEQ0291657
   subType    blindActuator
   userattr   ASC_Antifreeze:off,on ASC_AutoAstroModeEvening:REAL,CIVIL,NAUTIC,ASTRONOMIC,HORIZON ASC_AutoAstroModeEveningHorizon:-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9 ASC_AutoAstroModeMorning:REAL,CIVIL,NAUTIC,ASTRONOMIC,HORIZON ASC_AutoAstroModeMorningHorizon:-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9 ASC_BrightnessMaxVal ASC_BrightnessMinVal ASC_Closed_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_Direction ASC_Down:time,astro,brightness ASC_GuestRoom:on,off ASC_Mode_Down:absent,always,off,home ASC_Mode_Up:absent,always,off,home ASC_Offset_Minutes_Evening ASC_Offset_Minutes_Morning ASC_Open_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_Partymode:on,off ASC_Pos_Cmd ASC_Pos_after_ComfortOpen:0,10,20,30,40,50,60,70,80,90,100 ASC_Rand_Minutes ASC_Roommate_Device ASC_Roommate_Reading ASC_Self_Defense_Exclude:on,off ASC_Shading:on,off,delayed,present,absent ASC_Shading_Angle_Left:0,5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90 ASC_Shading_Angle_Right:0,5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90 ASC_Shading_BlockingTime_After_Manual ASC_Shading_BlockingTime_Twilight ASC_Shading_Brightness_Reading ASC_Shading_Brightness_Sensor ASC_Shading_Fast_Close:on,off ASC_Shading_Fast_Open:on,off ASC_Shading_Min_Elevation ASC_Shading_Min_OutsideTemperature ASC_Shading_Pos:10,20,30,40,50,60,70,80,90,100 ASC_Shading_Pos_after_Shading:-1,0,10,20,30,40,50,60,70,80,90,100 ASC_Shading_StateChange_Cloudy ASC_Shading_StateChange_Sunny ASC_Shading_WaitingPeriod ASC_ShuttersPlace:window,terrace ASC_Time_Down_Early ASC_Time_Down_Late ASC_Time_Up_Early ASC_Time_Up_Late ASC_Time_Up_WE_Holiday ASC_Up:time,astro,brightness ASC_Ventilate_Pos:10,20,30,40,50,60,70,80,90,100 ASC_Ventilate_Window_Open:on,off ASC_WindowRec ASC_WindowRec_subType:twostate,threestate ASC_lock-out:soft,hard ASC_lock-outCmd:inhibit,blocked rollo_wg rollo_wg_map structexclude
   webCmd     hoch:runter:halb:stop


Ich habe das gerade mal getestet. Bei mir ging es. Ich mache mal einen ausführlichen Test.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Karflyer am 30 Oktober 2018, 13:05:54
Nach dem Update auf die aktuelle Version habe ich folgendes Verhalten festgestellt.
Im Modul habe ich shutterDriveOffset auf 5 gesetzt, an den Devices habe ich den Wert auf dem Vorgabewert (-1) belassen. Ein neu berechnen der Fahrzeiten (set renewSunriseSunsetTimer) führt nicht zum gewünschten Ergebnis. An allen devices bleibt der Wert für den 'next_time_Event' (Fahrzeitpunkt) gleich.

Hier ein List des ASC-devices
Internals:
   CHANGED   
   MID        da39a3ee5e6b4b0d3255bfef95601890afd80709
   NAME       Rolladensteuerung
   NOTIFYDEV  1,Regenmesser,Rolladensteuerung,global,none,rgr_Residents,rr_Simone,sc_bz,sc_ezl,sc_ezr,sc_fo,sc_ft,sc_kc,sc_szl,sc_wz,sht_bz,sht_ezl,sht_ezr,sht_fo,sht_ft,sht_fz,sht_kc,sht_szl,sht_szr,sht_wz
   NR         623
   NTFY_ORDER 51-Rolladensteuerung
   STATE      active
   TYPE       AutoShuttersControl
   VERSION    0.1.83
   OLDREADINGS:
   READINGS:
     2018-10-12 07:18:04   lockOut         off
     2018-10-12 07:18:04   partyMode       off
     2018-10-30 11:52:44   room_SOMFY      sht_bz,sht_ezl,sht_ezr,sht_fo,sht_ft,sht_fz,sht_kc,sht_szl,sht_szr,sht_wz
     2018-10-30 10:40:29   selfDefense     on
     2018-10-30 06:18:48   sht_bz_lastPosValue 0
     2018-10-30 11:52:48   sht_bz_nextAstroTimeEvent 30.10.2018 - 17:43
     2018-10-30 05:49:25   sht_ezl_lastPosValue 0
     2018-10-30 12:48:22   sht_ezl_nextAstroTimeEvent 30.10.2018 - 17:43
     2018-10-30 05:48:21   sht_ezr_lastPosValue 0
     2018-10-30 11:52:48   sht_ezr_nextAstroTimeEvent 30.10.2018 - 17:43
     2018-10-30 05:45:01   sht_fo_lastPosValue 0
     2018-10-30 11:52:48   sht_fo_nextAstroTimeEvent 30.10.2018 - 17:43
     2018-10-30 05:49:53   sht_ft_lastPosValue 0
     2018-10-30 11:52:48   sht_ft_nextAstroTimeEvent 30.10.2018 - 17:43
     2018-10-30 06:41:01   sht_fz_lastPosValue 200
     2018-10-30 11:52:48   sht_fz_nextAstroTimeEvent 30.10.2018 - 17:43
     2018-10-30 05:47:04   sht_kc_lastPosValue 0
     2018-10-30 11:52:48   sht_kc_nextAstroTimeEvent 30.10.2018 - 17:43
     2018-10-30 06:18:48   sht_szl_lastPosValue 0
     2018-10-30 11:52:48   sht_szl_nextAstroTimeEvent 30.10.2018 - 17:43
     2018-10-30 06:18:48   sht_szr_lastPosValue 0
     2018-10-30 11:52:48   sht_szr_nextAstroTimeEvent 30.10.2018 - 17:43
     2018-10-30 05:49:19   sht_wz_lastPosValue 0
     2018-10-30 11:52:48   sht_wz_nextAstroTimeEvent 30.10.2018 - 17:43
     2018-10-30 11:52:44   state           active
     2018-10-30 11:05:51   sunriseTimeWeHoliday on
     2018-10-30 11:52:44   userAttrList    rolled out
   helper:
     shuttersList:
       sht_bz
       sht_ezl
       sht_ezr
       sht_fo
       sht_ft
       sht_fz
       sht_kc
       sht_szl
       sht_szr
       sht_wz
   monitoredDevs:
     1:
       sht_ezr    ASC_WindowRec
     Regenmesser:
       Rolladensteuerung ASC_rainSensorDevice
     none:
       sht_ezl    ASC_Roommate_Device
       sht_ezr    ASC_Roommate_Device
     rgr_Residents:
       Rolladensteuerung ASC_residentsDevice
     rr_Simone:
       sht_ezl    ASC_Roommate_Device
       sht_ezr    ASC_Roommate_Device
     sc_bz:
       sht_bz     ASC_WindowRec
     sc_ezl:
       sht_ezl    ASC_WindowRec
     sc_ezr:
       sht_ezr    ASC_WindowRec
     sc_fo:
       sht_fo     ASC_WindowRec
     sc_ft:
       sht_ft     ASC_WindowRec
     sc_kc:
       sht_kc     ASC_WindowRec
     sc_szl:
       sht_szl    ASC_WindowRec
     sc_wz:
       sht_wz     ASC_WindowRec
Attributes:
   ASC_antifreezeTemp 0
   ASC_autoAstroModeEvening CIVIL
   ASC_autoAstroModeMorning CIVIL
   ASC_autoShuttersControlComfort on
   ASC_autoShuttersControlEvening on
   ASC_autoShuttersControlMorning on
   ASC_autoShuttersControl_Shading off
   ASC_guestPresence off
   ASC_rainSensorDevice Regenmesser
   ASC_rainSensorReading rain
   ASC_residentsDevice rgr_Residents
   ASC_residentsDeviceReading state
   ASC_shuttersDriveOffset 5
   ASC_sunElevationDevice myAstro
   ASC_sunElevationReading SunAlt
   ASC_sunPosDevice 1
   ASC_sunPosReading SunAz
   ASC_temperatureReading temperature
   ASC_temperatureSensor Terasse
   ASC_timeUpHolidayDevice dy_Urlaub
   icon       fts_shutter_automatic
   room       ASC
   verbose    3
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 30 Oktober 2018, 13:09:56
Das ist korrekt so. Die Verzögerung erfolgt nun nicht mehr beim berechnen sondern erst beim eigentlich Fahrbefehl. Und das gilt für alle Fahrbefehle. Darum ging es ja eigentlich von Anfang an.
5s scheint recht knapp, nimm lieber 30 also 30s
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: Karflyer am 30 Oktober 2018, 13:16:10
Ist der Wert jetzt in Sekunden anzugeben? Bislang waren es Minuten.

Ist der set-Befehl um das NOTIFYDEV 'manuell' neu aufzubauen rausgefallen? Ich habe da jezt so seltsame Werte "1","none" drinstehen.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 30 Oktober 2018, 13:21:24
Zitat von: CoolTux am 30 Oktober 2018, 08:31:31
- Anzeige get und set für NOTIFYDEV erfolgt nur bei verbose > 3

In der Commandref steht genau wie das nun an zu geben ist. Der Wert ist nun in Sekunden an zu geben. Grund ist das ich keinen Sinn darin sehe eine Fahrt auf mehr wie 3 min zu verzögern. Da kann man ohne Probleme und auch feiner in Sekunden arbeiten.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 30 Oktober 2018, 15:44:35
Ich habe soeben noch mal ein eine neue Version 0.1.84 hoch geladen. Wer die Vorgängerversion 0.1.83 hat muß nicht unbedingt noch mal updaten. Ist nur ein kleiner fix.
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: sentinel1 am 30 Oktober 2018, 16:46:45
Zitat von: CoolTux am 30 Oktober 2018, 08:34:04
Ich habe das gerade mal getestet. Bei mir ging es. Ich mache mal einen ausführlichen Test.

brauchst du nicht mehr machen,die Fenstersensoren waren nicht mehr in NOTIFYDEV,jetzt sind sie wieder drin und sollte wieder funktionieren.Werde heute abend testen.

Gruß,
Claudiu
Titel: Antw:Betatester für neues Modul AutoShuttersControl gesucht!
Beitrag von: CoolTux am 30 Oktober 2018, 17:31:27
Ich habe nun einen offiziellen Modulthread eröffnet. Dort können wir weiter diskutieren und neue Ideen umsetzen.

Hier geht es nun weiter

https://forum.fhem.de/index.php/topic,92628.0.html