[73_AutoShuttersControl.pm] - aktuelle Entwicklerversionen zum testen

[CoolTux]

Alles gut. Habe es gefixt.

Eine aktuelle Version ist online für Dich.

[Beta-User]

So, Version 0.4.0.11beta42 ist am Start.

Meine Rollläden hatte ich länger vor dem Einspielen der Version manuell geöffnet.

Nach dem Start steht ein Teil (u.A. der im Bad) wieder auf "wind un-protectio" und ist geschlossen.

Problem beim Erkennen des Zustands beim Start, verbliebene Info aus der Vorversion oder "feature"?

[CoolTux]

So, Version 0.4.0.11beta42 ist am Start.

Meine Rollläden hatte ich länger vor dem Einspielen der Version manuell geöffnet.

Nach dem Start steht ein Teil (u.A. der im Bad) wieder auf "wind un-protectio" und ist geschlossen.

Problem beim Erkennen des Zustands beim Start, verbliebene Info aus der Vorversion oder "feature"?

Dann muss ich mir was einfallen lassen was die erst Initialisierung an geht. Im fehlt zum Zeitpunkt kurz nach dem ersten Start und des ersten Events vom Windsensor die Info zum aktuellen Zustand.
Das fixe ich nachher noch.

[CoolTux]

Gerade geschaut. Das ist alles schick soweit von der Logik her, aber ich hatte einen Typo bei meinen gettern. Ups

[CoolTux]

So neue Version ist online

0.4.0.11beta43

[Beta-User]

Scheint im Wesentlichen zu passen.

Zwei Rollläden gibt's noch, da steht das wind un-protection noch drin (angezeigt via ASC-get). Ich kann aber grade nicht sagen, an was das liegt, würde auf den Bewohner tippen. Jedenfalls sind alle Rollläden oben geblieben, was zur jetzigen Zeit auch korrekt ist.

Danke bis dahin!

[CoolTux]

Das beste ist das ich im selben Zuge Anpassungen für das Beschatten gemacht habe. Bin gespannt wie das bei mir hier so läuft.

[Beta-User]

Das beste ist das ich im selben Zuge Anpassungen für das Beschatten gemacht habe. Bin gespannt wie das bei mir hier so läuft.

Moin,ich glaube, eben die erste Beschattungsfahrt an meiner Testjalousie beobachtet zu haben. "Leider" hatte ich 0 als Ziellevel eingetragen. Leider deswegen, weil die Laufzeit von der Jalousie zu lang ist, die stand danach auf "manual"...

Da ich das Problem praktisch bei allen Jalousien habe, dass die Laufzeit von ganz offen zu ganz geschlossen länger ist als die max. Zeit, die das Modul für die Erkennung nutzt: Wie groß sind die Chancen, die Laufzeit konfigurierbar zu machen (oder automatisch zu erkennen, die Homematic-Aktoren haben dazu zwei Readings)?

[CoolTux]

Wie lauten denn die Readings und welchen kann man da am besten nehmen?

[Beta-User]

Die Infos zur Laufzeit, die auf dem Aktor gespeichert sind, stecken hier drin:

Code Auswählen Erweitern

Internals:
     2017-12-21 07:35:17   R-driveDown     15 s
     2017-12-21 07:35:17   R-driveTurn     0.5 s
     2017-12-21 07:35:17   R-driveUp       16 s


driveTurn ist m.E. nur beim direkten Umschalten relevant, von daher meine ich, dass für CUL_HM der größere der beiden anderen relevant ist, dazu kämen dann noch kurze Zuschläge für die Zeit, die das Signal von FHEM zum Aktor und zurück benötigt, einschl. der Verarbeitungszeit innerhalb von FHEM.
Mehr wie 2 Sek. sind die beiden Werte aber bei mir auch nicht auseinander, die eine Sekunde ist für ein "normalgroßes" Fenster passend; ein sehr großer Rolladen kommt vermutlich nicht auf mehr wie 3 Sek. Differenz. Wenn der Wert einmalig beim Laden des Moduls ermittelt wird, würde ich den Vergleich machen wollen und einen Zuschlag von 2-3Sek. machen für die Signalwege usw..

(Ich gehe mal davon aus, dass das ROLLO-Modul derartige Infos per Attribut bereithält, dort aber ein kleinererZuschlag erforderlich wäre, weil die Verarbeitungslogik innerhalb FHEM ist.)
(Ergänzend: Wenn man es noch genauer haben wollte: die Gesamtlaufzeit ist ja nur relevant für die Fahrten zwischen beiden Endpunkten; fährt man nur zwischen 50% Beschattung und 70% Lüften, dauert eine automatische Fahrt nicht die gesamte Zeit...)

[CoolTux]

Ok er brauch also für eine ganze Fahrt von unten nach oben 16s, Das verstehe ich aber nicht, ich gebe ihm hier 60s.

Wenn also das ASC Modul die Fahrt aus löst, dann muß die Fahrt innerhalb von 60s beendet sein um als eine ASC Fahrt zu gelten.
Wenn der Rolladen von Hand bewegt wird erkennt ASC diese Fahrt als manuelle fahrt wenn die letzte ASC Fahrt länger wie 60s her ist.

[Beta-User]

Die Frage war nach der Readingbenennung, deswegen hatte ich genommen, was verfügbar war (der Rollladen, den ich neulich hier gepostet hatte)...

Die Jalousien liegen bei 65 sek, soweit ich mich entsinne; die hatte ich grade nur nicht zur Hand.

[CoolTux]

Die Frage war nach der Readingbenennung, deswegen hatte ich genommen, was verfügbar war (der Rollladen, den ich neulich hier gepostet hatte)...

Die Jalousien liegen bei 65 sek, soweit ich mich entsinne; die hatte ich grade nur nicht zur Hand.

Haben Deine Jalousien auch so ein Reading oder brauchen wir da ein Attribut?

[Beta-User]

Das ist genau derselbe Aktortyp (wie alle meine Rollladen- und Jalousieaktoren). Daher sind genau diese Readings selbstredend auch dort vorhanden.
(Was ich mir nochmal ansehen müßte wäre die Frage, ob die auch immer sichtbar sind. Bei mir ja, weil ich die Fahrzeiten eingestellt habe. Das dürfte aber eigentlich bei allen Anwendern genauso sein, weil sonst einfach nix vernünftiges an %-Wert angezeigt wird usw.).

[CoolTux]

Dann lass es und doch einfach in ein Attribut stecken. Ist ja dann auch egal

Was hälst eigentlich davon wenn wir

Code Auswählen Erweitern


ASC_BlockingTime_afterManual 1200
ASC_BlockingTime_beforDayOpen 3600
ASC_BlockingTime_beforNightClose 3600


Als ein einziges Attribut schreiben?

Code Auswählen Erweitern


ASC_BlockingTime 1200 3600:3600