[73_AutoShuttersControl.pm] Feedback und Anregungen

[pruy]

Ich habe mich in den letzten Wochen damit beschäftigt,
meine Rollläden auf eine Automatisierung mit AutoShutterControl
umzustellen. Im wesentlichen tut das nun so, wie ich das haben will.
Allerdings musste ich den einen oder anderen Irrweg erst mal erkennen
und dreht man etwas an der Konfiguration, dann kann schon mal eine
kleine Debug-Session erforderlich werden, bis man den gewünschten Effekt
erzielt.

Ich hatte auch mit ein paar Bekannten gesprochen, die mir erklärten,
sie hätten das mit ASC aufgegeben, da viel zu kompliziert und wenig erfolgreich,
und lieber ihre eigene Lösung entwickelt.

Aufgrund eigener Erfahrung kann ich diese negative Haltung verstehen.
Ich bedauere aber, dass hier kleinere Fallen die wahrgenommene Nützlichkeit
eines durchaus sinnvollen Moduls so massiv beeinträchtigen.
(Ja ich gebe zu, ich war zwischen durch auch an der Stelle, wo ich dachte, lass
es und mach dir was eigenes, aber dann wollte ich nicht gleich die Flinte ins
Korn werfen.)

Der Eindruck, dass die Nutzung von ASC nicht einfach und "selbsterklärend" ist,
verstärkt sich auch mit der Beobachtung, dass im Forum regelmäßig 6-10 von 20
Beiträgen auf der ersten Seite von "Automatisierung" auf ASC bezogen sind,
also viel Austausch zu dem Thema erfolgt. Das mag daran liegen, dass das Modul
aktiv gepflegt und weiterentwickelt wird, aber genügend Fragen in dem
Bereich machen deutlich, die Schwierigkeiten der Nutzer sind ein verbreitetes
Phänomen.

Andererseits sind in das Modul viele Jahre an Denk- und Entwicklungsarbeit
eingeflossen. Diese geballte Erfahrung nicht zu nutzen und stattdessen das "Rad
neu zu erfinden" wäre nicht wirklich sinnig.

Letztlich hat mich das dazu veranlasst, das Modul genauer zu betrachten und
daraus wiederum ist die Motivation entstanden, ein paar Anmerkungen zurück zu
spiegeln und einen Beitrag zur Verbesserung zu leisten (oder zumindest eine
entsprechende Diskussion anzustoßen, wie das Modul verbessert werden könnte.)

Zunächst:

Wieso gibt es so viele Probleme bei (Erst-)Nutzern (und nicht nur bei denen)?

A)
Für mich war es so (und das scheint der häufigste Problemauslöser zu sein),
das nicht klar wird, wie die verschiedenen Semantiken (Basissteuerung,
Beschattung, Windschutz, Regenschutz, Belüftung, LockOut, Sicherheit) zusammen
arbeiten.

Das wird
1. weder in der Dokumentation (Modul oder Wiki) erkennbar, noch
2. lässt es sich aus den Log-Messages erkennen.

Beispiel:
Dass die Beschattungskontrolle verscheidene Zustände kennt (in, out, X reserved,,???)
kann man bestenfalls dem Code entnehmen. Was sie jeweils bedeuten ist damit
(von aussen) nicht wirklich ersichtlich. Damit ist auch die Angabe in der
Statusübersicht nicht wirklich informativ und erhellend.

Beispiel:
Eine Log-Meldung "nach dem return" trägt nicht wirklich zum Verständnis des
Ablaufs bei, auch wenn für einen Entwickler (oder einem verständigen
Code-Leser) klar wird, welche Randbedingungen damit erfüllt sind und welche
Entscheidungen nun folgen müss(t)en.
Ganz abgesehen von der Frage, aufgrund welcher Werte im Einzelfall eine
Entscheidung getroffen wurde.


B)
Welche Einstellung für eine Funktionalität jeweils erforderlich sind und ob
alle Einstellungen korrekt oder wenigstens sinnvoll vorgenommen sind,
kann der Nutzer nur am "Erfolg" am Ende erkennen.

Beispiel:
Ich hatte mich bei der Angabe eine TempSensor in einem Rollladen vertippt.
Es hat eine ganze Zeit gedauert, dass ich die Ursache dafür gefunden habe,
dass intern OutTemp immer als -100 "gelesen" wurde.
(Ja, einem Entwickler ist das schnell klar. Ein (Normal-)Nutzer hat erst mal
keine Chance, obwohl das  Modul leicht erkennen und dem Nutzer zurückmelden
könnte, dass das angegebene Device nicht bekannt ist.)


In Folge der Beobachtungen unter A müsste also die Dokumentationslage deutlich
verbessert werden. Die Zustandsübergänge und deren Abhängigkeit von den
verschiedenen Attributen müssen dem Nutzer vermittelt werden.

Die Beobachtung zu B zielt eher auf die Code-Struktur.
Hier zeigt ein Blick, das die Architektur jeweils aus einem Ereignis(typ)
eine Fahroperation für einen Rollladen ermittelt.

Damit ist die Zustandsverwaltung intern auf verschiedene Routinen verteilt,
was die Pflege und Erweiterung des Moduls (insbesondere mit Zuname der Funktionalitäten)
schwierig macht, da alle Stellen sich über das gewünschte Verhalten einig sein
müssen. (Sonst führt ein Event des tempSensor Devices zu einem anderen Ergebnis
als ein Azimut-Event auch wenn jeweils die beteiligten Messwerte alle identisch
wären.)

Andererseits sind die Ereignisroutinen ziemlich umfänglich für die
Zustandsverwaltung verantwortlich. D.h., es müssen jeweils alle Aspekte
berücksichtigt werden.

Eine kleine Beobachtung hierzu:
Bei der Beschattung wird ein "ShadingState" gesetzt, ebenso ein
"ShadingLastState".
Allerdings werden jeweils beide Werte explizit gesetzt.
Strukturell einfacher wäre es in der Funktion "setShadingState", die den
"ShadingState" setzt, direkt den "ShadingLastState" zu setzen. Damit wäre dieser
Wert immer sinnvoll korrekt. Selbst wenn "ShadingLastState" einem vereinfachtem
Zustandsmodell folgen würde (z.B. nur "in" und "out") kann sich in der Funktion
zentral darum gekümmert werden, statt den Code an 'zig Stellen zu wiederholen.
Da auch der "ShadingLastState" dafür von Bedeutung ist, ob (und wie) die
Rollladenposition verändert wird, ist ein Fehler an dieser Stelle fatal (und
darüber hinaus auch nur mühsam zu finden).

Ich denke eine verbesserte "responsibility" würde zu einer besseren (aus Sicht
Weiterentwicklung, Wartung und Verständlichkeit) Code-Struktur (und
Architektur) führen.

Aus der Auseinandersetzung mit dem Themenbereichen komme ich zu nachfolgender
logischen Strukturierung der Aufgaben für den Kernbereich des ASC Moduls:


Bereich A)  Eventhandling

Hierin verortet sind die Aktivitäten, die Konfiguration, Messwerte und
Zeitpunkte verwalten und auf entsprechende externe und interne Ereignisse
"reagieren".

Hier gibt es zwei Unterbereiche:
    A1) Reaktion auf Konfigurationsänderungen
        Während bei Änderungen an Attributen eines ASC Devices direkt in den
        Set-Funktionen geprüft und reagiert werden kann, müssen
        Konfigurationsänderungen an anderen relevanten Geräten (z.B. den
        Rollläden) über entsprechende Events erkannt werden.

        Z.B. wird "ASC_enable" gesetzt, könnte man des Gerät (nachträglich) in
        die Liste der verwalteten Geräte aufnehmen (und sofort prüfen, ob
        wichtige Konfigurationsdetails fehlen oder die Angaben plausibel sind).
        Ein "scanForDevices" oder auch ein nachgelagertes "set
        createNewNotifyDev" sind damit nicht wirklich mehr notwendig.
        Änderungen an der Konfiguration würden "sofort" auf die Rollläden
        wirken.

        Wg. Konfiguration ist auch die Verwaltung (Einrichten, Löschen) von
        Timern hier anzusiedeln.
       
        Wird durch die Änderung der Konfiguration auch der (potentielle) Zustand
        eines oder mehrerer Rollläden verändert, so wird ebenfalls eine
        Aktivität nach A2 ausgelöst. (Z.B.: wird das unter "ASC_tempSensor"
        hinterlegte Gerät geändert, dann wird sich möglicherweise auch der
        Temperaturwert geändert haben, daher muss der Rollladenzustand
        aktualisiert werden.

    A2) Reaktion auf Zustands relevante Events (auch Timerablauf)

        Hier wird die Menge der betroffenen Rollladen-Geräte ermittelt und für
        jedes Gerät eine Verarbeitung nach Bereich B angestoßen.

Bereich B) Zustandsverwaltung

Hierin verortet ist die Ermittlung des Soll-Zustands eines Rollladen
aufgrund aktueller Konfiguration und Messwerte
Das ist der Teil, der einen Nutzer am Ende "interessiert".
Hier ist die "eigentliche" Steuerlogik implementiert.

Auch wenn es ggf. marginal "teurer" ist, die relevanten Werte aus den Geräten
statt aus dem Event abzulesen, denke ich, dass die eigentliche Berechnung
damit vereinfacht wird, da der Zugriff auf z.B. die aktuelle für einen
Rollladen gültige Außentemperatur immer gleich erfolgt unabhängig davon, ob
der aktuelle Auslöser der Verarbeitung ein Temperatur-Event oder ein
Azimut-Event war.

Ist der Sollzustand ermittelt, wird eine Verarbeitung nach Bereich C ausgelöst.

Bereich C) Fahrsteuerung

Hier wird der Rollanden vom Ist-Zustand in den berechneten Sollzustand
überführt. Dies allerdings nur, soweit nicht Umstände dagegen stehen.
Z.B. Verhinderung von Lockout verbietet das beabsichtigte Schließen,
oder eine manuelle Einstellung übersteuert die Automatik.
   
Hier kann auch Gerätetyp-spezifisch agiert werden.
Z.B. bei Geräten ohne Positionsrückmeldung (z.B. SOMFY-RTS)
(konfigurationsabhängig) ein präziser Fahrmodus implementiert werden (erst in
Endlage bewegen, dann Position anfahren)
(Entsprechendes ließe sich auch über eine "ASC kompatible Schnittstelle" in den
Devices realisieren, aber vermutlich ist eine ASC lokale "Geräte-Adaption"
einfacher wg. geringerer Abhängigkeiten von anderen Entwicklungen.)

Für B wäre es wohl sinnvoll, ein Zustandsmodell zu beschreiben, dass die
verschiedenen Semantiken (Grundöffnung/-schließung, Beschattung, Windschutz,
Regenschutz, Lüftung, Gebäudeschutz wie auch Lockout, PartyMode) mit den
zugehörigen Attributen erklärt und auch die Wechselwirkungen beschreibt.
(Wenn Windschutz sagt "Position 0" und Beschattung sagt "Position 90" und
Gebäudeschutz sagt "Position 100", was passiert dann tatsächlich?)

[Ich habe mal überschlagen und bin auf gut 30.000 mögliche Zustände gekommen.
Dabei sind die offensichtlich unmöglichen (weil mit Abschalten einer Semantik
die zugehörigen Unterzustände nicht mehr erreichbar sind) bereits eliminiert.
Selbst wenn sich das in der Praxis auf 3.000 oder 4.000 realistische
Kombinationen "reduziert" ist klar, wieso Nutzer immer wieder von unerwarteten
Verhaltensweisen "überrascht" werden.]

Wenn ich jetzt lese, dass nun zur Steuerung noch eine 2. Dimension (Winkel bei
Lamellen) hinzukommt, wird der Gesamtzustand nicht einfacher.

Eine Restrukturierung des Kernbereichs von ASC in die genannten logischen
Blöcke dürfte das Risiko von "handwerklichen" Fehlern deutlich reduzieren.
Dass im Bereich B mit der Logik genug Fallen (und auch ein Spektrum an
unterschiedlichen Sichtweisen das leben erschwert, lässt sich leider
Grundsätzlich nicht vermeiden. Das Thema ist komplex und die Komplexität wird
nicht so einfach verschwinden.
Zumindest aber kann man erreichen, das ein Nutzer erkennt, welche
Entscheidungen warum getroffen wurden und damit entweder geeignete Korrekturen
seiner Einstellungen vornehmen oder entsprechende Feature-Requests bei
für ggf. fehlenden Semantiken zu formulieren.

Soweit mal meine Anmerkungen und Gedanken.
Ich hoffe das war ausreichend verständlich und letztlich hilfreich.

Rainer

[CoolTux]

Hallo Rainer,

Vielen Dank für Deinen Erfahrungsbericht und Deine sehr ausführlichen Erläuterungen. Das Modul selbst befindet sich noch in der Entwicklung und wie selbst festgestellt hast wurden in den 2 Jahren eine Menge Wünsche der User umgesetzt. Daraus resultiert in der Tat eine zunehmende Komplexität welche es schwer macht alle Bedingungen zu erfassen.
Was dem Modul definitiv fehlt ist eine große Dokumentation. Keine Commandref sondern ein richtiges Buch wo auch die Abhängigkeiten und nötigen Konfigurationen erklärt sind. Leider habe ich nicht die Zeit das Modul (und 15 weitere) zu entwickeln zu pflegen und ein Buch (Dokumentation) zu schreiben. Und zugegebener Maßen und das ist sicherlich auch eher der Hauptgrund, ich bin mega schlecht in Dokumentation 

Ich hatte versucht eine bessere Debugausgabe zu erzeugen, das Beispiel mit dem return ist in der Tat ungünstig. Auch werde ich mir anschauen ob ich für einige Einstellungen (Beschattung) eine Plausibilitätsprüfung für die Abhängigkeiten einbauen kann.

Wenn sich also jemand findet der bereit ist eine umfassende Dokumentation zu schreiben so erkläre ich mich bereit für jede Frage ein Ohr zu haben und darauf zu antworten. Ich selbst bin absoluter Pragmatiker. Gibt es ein Problem schreibe ich Code um das Problem zu lösen, alles andere ist für mich schwierig. Da bin ich auf Hilfe angewiesen.
Bisher haben die Leute zwar Ihre Wünsche und Meinungen zu ASC gehäußert, aber noch niemand hat sich angeboten sich intensiv in das Thema einzuarbeiten und zu unterstützen. Leider. Ich selbst bin ja schon froh das es 1-2 Leute gibt die wenigsten die Commandref vom deutschen ins englische schreiben.

Das mit dem ShadingLastStatus nehme ich mir sehr gerne zu Herzen, da hast Du komplett Recht. Das kann man in der Tat über die setShadingStatus abarbeiten. Vielen Dank.



Grüße
Marko

[JWRu]

Hallo zusammen,

Ich habe lange überlegt, ob ich mich zu diesem Thema äußere, möchte es aber tun.
Ich kann viele der Kommentare von Rainer (pruy) nachvollziehen, auch ich habe beim Einrichten von ASC ziemlich gekämpft.
Auf der anderen Seite lebt FHEM aber von der Initiative von Leuten wie Marko (CoolTux). Was er in die Entwicklung und in den Support von ASC steckt, ist einfach unglaublich.
Ich sehe aber auch die Gefahr, das Modul mit neuen Funktionen zu überladen. Jede davon bringt mehr Komplexität und erschwert die Wartung und die Fehlersuche.
Meine erste spontane Reaktion, als ich las, dass jetzt auch Jalousien unterstützt werden sollen, war: Mach jetzt ein "exclude_from_update".
Natürlich werden von der Benutzern immer neue Wünsche geäußert - ich würde aber für mehr "Mut zur Lücke" plädieren.
Die Konfiguration einer eierlegende Wollmilchsau überfordert aus meiner Sicht viele Benutzer.

Jochen

[flummy1978]

Hallöchen,

zunächst einmal ist es mir persönlich wichtig, nochmals zu erwähnen, dass auch mit einem grundsätzlich kritischem Grundposting nichts damit zu tun hat, die (unbezahlbare - auch wenn er ein Paypal Konto hat ) Arbeit des Entwicklers runter zu machen. Diese kann man gar nicht hoch genug anrechnen. Wie "Rainer" bereits schrieb, ist es Wahnsinn was bisher in das Modul eingeflossen ist, und es ist sicherlich noch nicht das Ende der Fahnenstange erreicht. Aber die Punkte die hier angesprochen wurden, finde ich persönlich auch sehr sinnvoll.

Ich möchte nicht wieder alles aufs Neue ansprechen, aber auch meine Gespräche(Beiträge) die ich zuletzt (auch per PN) geführt habe, stoßen in ein ähnliches Horn wie hier das Eingangsposting. Ich habe auch mehrmals im Forum geschrieben, dass es schwierig ist für Frischlinge (wie mich) ein System zu erkennen, wie man sich an mögliche Fehler langsam rantasten könnte. Hinzu kommen:

• Sehr sehr viele Funktionen, die sich einzeln nicht abschalten lassen und daher kompliziert in der (Grund)Einrichtung sind
• Viele Stolpersteine und Wechselwirkung die wenig bis gar nicht erklärt sind (.....Wenn Windschutz sagt "Position 0" und Beschattung sagt "Position 90" und Gebäudeschutz sagt "Position 100", was passiert dann tatsächlich?....) war ein super Beispiel
• Schwierige gezielte Debug Möglichkeit (wenn man 10 Rollos hat und Debug einschaltet, gehts leider schnell ins unmögliche noch was zu erkennen, weil man Debug nur global und nicht bei den Rollos selbst zuschalten kann. Damit ist der Log schnell überlaufen.)
• 1000de Beiträge die immerwieder in die gleiche Richtung gehen (Beschattung) und am Ende weiß fast nie jemand woran es lag, weil in der Zwischenzeit a. 25 neue Beiträge dazu kommen und b. durch Wechselwirkung aus anderen Gründen das Rollo doch wieder fährt (oder nicht)
• Auswertung (ausschließlich) anhand der Position, fand ich von Anfang an schwierig weil ich sicher bin, dass ich nicht der Einzige bin, bei dem an einem Rollo die Beschattung == Closed ist an einem anderen wiederum Beschattung == Privacy oder Regenschutz == LockOut == Windschutz == offen. Wiederum ein anderes ist Lüften == Beschattungsposition
• Ich bin ziemlich sicher mal von Funktionen gelesen zu haben, die sich 2,3 User gewünscht haben. (Die anderen haben eben wegen der 50 Beiträge dazwischen nicht mehr geantwortet) Diese Funktionen haben dann aber zu Wechselwirkung bzw. Fehlfunktionen in anderen Bereichen geführt

Ich halte mich maximal für einen Hobbyprogrammierer (zumindest außerhalb von dem mit dem ich beruflich zu tun hab), aber das ein oder andere habe ich auch schon gesehen, was verschiedene Strukturen angeht. Ich bin mir aber auch sicher, dass Marko als er überlegt hat sowas wie das ASC zu machen, gar nicht erst auf die Idee kam an Sachen wie Lamellen, oder Lockoff Partymodus und und zu denken. Also entstehen viele Sachen Schritt für Schritt. Wie schwierig es ist im Nachhinein etwas im GROßEN zu ändern, weiß jeder der mal was größeres Programmiert / gebaut oder was auch immer hat.

Ich bin mir sicher, dass insg. sehr viele Leute sich mit dem ASC beschäftigen und auch einigermaßen gut auskennen. Aber...

Wenn sich also jemand findet der bereit ist eine umfassende Dokumentation zu schreiben so erkläre ich mich bereit für jede Frage ein Ohr zu haben und darauf zu antworten.

....hier sehe ich persönlich genau das größte Problem im Zusammenhang was ich oben geschrieben habe. Durch die Komplexität, die (für mich z.B.) schwierige Nachvollziehbarkeit im Code, Einstellmöglichkeit und Wechselwirkung macht es für alle anderen (außerhalb von Deinem Kopf ) fast unmöglich es vollständig komplett zu erklären. Ist meine persönliche Meinung ... vielleicht sehen das andere anders.
Nochmal wichtig: Es ist nicht Sinn und Zweck des Beitrages (von mir) das Modul runter zu machen oder sonst was negatives anzubringen. Eher die Kritik die zeigt, dass sich sehr viele Nutzer damit beschäftigen und sehr dankbar sind was Du hier auf die Beine stellst.

@OffTopic: Schade dass sind hier scheinbar jemand hinter einem neuen Nick versteckt. Ich denke für kritische Worte (positiv wie negativ) ist jeder (Entwickler) dankbar. In diesem Fall GLAUBE ich einfach, dass dem so ist, weil jemand der sich ~zitat~in den letzten Wochen damit beschäftigt, meine Rollläden auf eine Automatisierung mit AutoShutterControl umzustellen. ~zitatEnde~ kaum schafft ein Modul wie dieses umzusetzen ohne auch nur eine einzige Frage oder Ergänzung im Forum vorzunehmen. Sollte ich richtig liegen, finde ich es wie gesagt sehr schade ..... Falls ich mich irre, tut es mir leid, ich nehme alles zurück und behaupte das Gegenteil... aber merkwürdig sieht das schon aus

Viele Grüße,
genießt die Sonne, das WE und
bleibt gesund
Andreas

[pruy]

@OffTopic: Schade dass sind hier scheinbar jemand hinter einem neuen Nick versteckt. Ich denke für kritische Worte (positiv wie negativ) ist jeder (Entwickler) dankbar. In diesem Fall GLAUBE ich einfach, dass dem so ist, weil jemand der sich ~zitat~in den letzten Wochen damit beschäftigt, meine Rollläden auf eine Automatisierung mit AutoShutterControl umzustellen. ~zitatEnde~ kaum schafft ein Modul wie dieses umzusetzen ohne auch nur eine einzige Frage oder Ergänzung im Forum vorzunehmen. Sollte ich richtig liegen, finde ich es wie gesagt sehr schade ..... Falls ich mich irre, tut es mir leid, ich nehme alles zurück und behaupte das Gegenteil... aber merkwürdig sieht das schon aus

Nur um gleich von Anfang an irrige Annahmen und Vemutungen auszuschließen ein klares Statement:

    Außer dass ich ASC nutze, habe ich mit CoolTux (zumindest bisher) nichts zu tun.

Dass ich selten Fragen stelle, liegt daran, dass ich mit über 35 Jahren aktiver SW Entwicklung nicht mehr als reiner Hobbyentwickler durchgehe
und den grundsätzlichen "Schaden" habe, das ich, wenn etwas unklar ist, einfach in den Quellcode sehe, denn nur dort
gibt es Infos "aus erster Hand". (Erst danach sehe ich - wenn überhaupt - an "Standardplätzen" nach, ob ich das auch schneller hätte haben können.)
Das ist am Ende etwas assozial, denn die Fragen (und vor allem Antworten) könnten Anderen helfen (Asche auf mein Haupt).
Nur bin ich dann meist schon wieder in neuen Themen und das "Gelöste" fällt auf den Boden....

[CoolTux]

Guten Morgen,

Ich bin immer offen für jede Art von konstruktiver Kritik. Denn ich möchte das meine Module sich weiter entwickeln und nützlich für die Community sind.
Einige Überlegungen von Rainer habe ich mir auch zu Herzen genommen, anderen konnte ich nicht folgen. Aber das liegt eher daran das ich weniger Theoretiker und mehr Pragmatiker bin.
Da wo ich kann setze ich die Kritik sehr gerne um.

Aktuell das Thema "Positionsangaben müssen unterschiedlich sein"


Grüße
Marko

[pruy]

...Und zugegebener Maßen und das ist sicherlich auch eher der Hauptgrund, ich bin mega schlecht in Dokumentation 

Das kann ich voll verstehen. Ich bin bei Dokumentation auch eher "zurückhaltend" (da bin ich dann doch eher Entwickler).
Dennoch ist es zwingend erforderlich, wenn man das "baby" in die "freie Wildbahn" entlassen möchte, auch den
Nicht-Insidern eine Idee zu vermitteln, was für den sinnvollen Gebrauch zu tun ist.

Leider ist ab einer gewissen Komplexität die CommendRef nicht mehr geeignet.
Der Fokus dort liegt auf Erläuterung der set und get Operationen, sowie der Erklärung der Readings
und natürlich die Beschreibung der Attribute. Dort wäre zwar inhaltlich ein großer Teil der (hilfreichen) Erläuterungen möglich,
aber die CommandRef ist eher als "Nachschlagewerk" (Referenzdokumentation) denn als "HowTo" gedacht
und daher wären ausuferende Erläöuterungen für Einsteiger wiederum fehl am Platz.

Ich hatte versucht eine bessere Debugausgabe zu erzeugen, das Beispiel mit dem return ist in der Tat ungünstig.

Dazu gleich noch eine Anregung von meiner Seite:

Auf Dauer hilft es ungemein, wenn man bei Log-Ausgaben (auch für Debug-Zwecke)
grundsätzlich alle Informationen mit ausgibt, die an dieser Stelle im Code wesentlich sind.
Ein "das sehe ich ja dann im Attribut oder im Reading oder im EventLog" ist bestenfalls gefährlich, weil man dann bereits (evtl fälschlicherweise) unterstellt, dass man exakt beurteilen kann, welcher konkrete Wert an dieser Stelle benutzt wurde.
(Manchmal ist genau der Irrtum über diesen Zusammenhang der Fehler den man sucht.)

Also:
Nicht einfach loggen:
"Einer der Beschattungsbedingungen wird nicht mehr erfüllt und somit wird der Beschattungsstatus um eine Stufe reduziert", sondern statt dessen explizit sagen:
"Beschattungsstatus wird um eine Stufe reduziert (ALT->NEU) da folgende Bedingungen nicht mehr erfüllt sind:  IstAzimut in [Min:Max], IstBrightnes<Grenzwert"

Dann weiß man genau, warum das Modul auf eine bestimmte Idee kam und kann gleichzeitig verifizieren, dass man selbst die korrekte Vorstellung hatte. (Aka: "Oh, ich dachte, ich hatte den Brightness-Grenzwert geändert.")

Wenn sich also jemand findet der bereit ist eine umfassende Dokumentation zu schreiben so erkläre ich mich bereit für jede Frage ein Ohr zu haben und darauf zu antworten.

Das Risiko ist leider, dass die Leute, die wirklich gut in Dokumentation sind, eher seltener in Projekte einsteigen, die noch einen gewissen Grad an Affinität zu Entwicklungsaktivitäten erkennen lassen.

In der Hoffnung, dass sich jemand angesprochen fühlt, werfe ich folgende Idee in den Ring (ob ich selbst dazu komme, damit anzufangen, kann ich aktuell nicht garantieren):

Den meisten Nutzern würde ein "Howto start with ASC" massiv helfen. (Ich habe entsprechende Frgmente irgendwo gesehen,
die müsste man aber wohl weiterentwickeln.)

Also:

• Definiere ein ASC Device
• Nimm Dir einen Rolladen
• Überlege, wann der öffnen und schließen soll
    (Hier Erklärung der Modi und der erforderlichen Einstellungen)
  
• Überlege, ob Du dort Beschattung brauchst/haben möchtest....
• Hast Du Öffnungssensoren?...
• Ist das eine Tür/Möchtest Du verhindern, dass Du ausgesperrt wirst?...
  
• (Und so weiter)
• Setze ASC_enable
• Nimm ggf. den nächsten Rolladen....

Das könnte helfen, 80%-90% der Fragen zu klären.

Ich selbst bin absoluter Pragmatiker. Gibt es ein Problem schreibe ich Code um das Problem zu lösen, alles andere ist für mich schwierig. Da bin ich auf Hilfe angewiesen. Bisher haben die Leute zwar Ihre Wünsche und Meinungen zu ASC gehäußert, aber noch niemand hat sich angeboten sich intensiv in das Thema einzuarbeiten und zu unterstützen. Leider.

Ich biete doch gerade meine Hilfe an.

Ich hoffe ich kann etwas helfen, dass ASC nicht zur Maintenance-nighmare mutiert.

Ich weiß aus eigener Erfahrung, dass bei steigender Komplexität und vor allem inkrementeller Entwicklung,
immer irgendwann ein Punkt erreicht wird, an dem die Grundarchitektur neu überlegt werden muss.
Entdeckt man dabei, dass das bisherige an einigen Stellen zu stark "verbogen" werden muss oder einige Features schlecht "passen",
dann sollte man einen Schritt zurücktreten und sehen, wie es besser zusammen passen könnte.
(Daher meine Vorschläge aus dem Startposting.)

[Ob hier der beste Ort ist, Entwicklungskonzete zu diskutieren, ist mir nicht klar. Ich bin eher selten in Foren unterwegs.
Wenn es einen "sinnvolleren" Platz gibt. Dann bitte ich um entsprechende Info.]

[CoolTux]

Aktuell bin ich dabei einige alte Zöpfe ab zu schneiden und somit das ganze etwas einfacher zu machen. Beispiel Positionsangaben müssen unterschiedlich sein.
Im übrigen ist hier ein guter Platz darüber zu diskutieren.
Das mit dem debug Log nehme ich mir sehr gerne zu Herzen und werde es überarbeiten.


Grüße

[pruy]

Zum Thema Positionsangaben gleich ein paar Überlegungen:

Die faktische Rolladensteuerung (Fahrkontrolle) erfolgt letztlich immer auf der Grundlage einer Positionsangabe.
(Eine der vielen Varianten von "position", "pct", "dim"...).
Während die Rolladengeräte immer ein Intervall (meist 0-100) unterstützen,
verwendet ASC nur einzelne diskrete (letztlich logische) "Positionen",
(die auch noch identisch sein können!): Open, Closed, Shading, Privacy, LockOut, Ventilation,...

Das war der Grund für mich zu sagen, ASC sollte eigentlich nur auf logischen Positionen operieren.
Die Abbildung auf die Positionierung des konkreten Rolladengeräts kann und sollte dann
von einer separaten Funktion übernommen werden, die dafür sorgt, dass die beabsichtigte "logische" Position auch tatsächlich physikalisch  eingenommen wird. Dass man dort generelle "Übersteuerungen" unterbringt, die man von der
allgemeinen Steuerlogik entkoppeln kann, weil sie orthogonal sind, hilft, die Komplexität der Steuerlogik zu reduzieren (ohne die gesamtfunktionalität zu beschränken.)

[CoolTux]

Die Abbildung auf die Positionierung des konkreten Rolladengeräts kann und sollte dann
von einer separaten Funktion übernommen werden, die dafür sorgt, dass die beabsichtigte "logische" Position auch tatsächlich physikalisch  eingenommen wird. Dass man dort generelle "Übersteuerungen" unterbringt, die man von der
allgemeinen Steuerlogik entkoppeln kann, weil sie orthogonal sind, hilft, die Komplexität der Steuerlogik zu reduzieren (ohne die gesamtfunktionalität zu beschränken.)

Genau das ist es was ich eigentlich nicht wollte. Ich finde nicht das eine Automatik kontrollieren sollte ob das Rollo tatsächlich in die an zu fahrende Position gefahren ist.
Es gibt zwei Möglichkeiten wieso die Position welche angefahren werden sollte nicht erreicht wurde. Manuelle Unterbrechung, das ist dann so gewollt. Das Modul für das Rollo kann nicht korrekt steuern, erhält keine Rückmeldung oder wie auch immer. Und genau das ist Problem des Modules welches das Device Steuert und die Eigenarten des Devices genau kennen sollte. Ich sage dem Läufer nur sprint los ich will das. Ob er am Ziel an kommt oder nach 200m keuchent im Graben liegt ist mir egal, ich bekomme die Meldung das er angekommen ist. Wo? Egal. Die nächste Prüfung wird zeigen denn ich sage los laufe aber nur wenn Du am Ziel bist. (also nicht wenn er im Graben liegt)

[pruy]

Genau das ist es was ich eigentlich nicht wollte. Ich finde nicht das eine Automatik kontrollieren sollte ob das Rollo tatsächlich in die an zu fahrende Position gefahren ist.
Es gibt zwei Möglichkeiten wieso die Position welche angefahren werden sollte nicht erreicht wurde. Manuelle Unterbrechung, das ist dann so gewollt. Das Modul für das Rollo kann nicht korrekt steuern, erhält keine Rückmeldung oder wie auch immer. Und genau das ist Problem des Modules welches das Device Steuert und die Eigenarten des Devices genau kennen sollte. Ich sage dem Läufer nur sprint los ich will das. Ob er am Ziel an kommt oder nach 200m keuchent im Graben liegt ist mir egal, ich bekomme die Meldung das er angekommen ist. Wo? Egal. Die nächste Prüfung wird zeigen denn ich sage los laufe aber nur wenn Du am Ziel bist. (also nicht wenn er im Graben liegt)

Sorry, in diese Richtung wollte ich gar nicht argumentieren.
ASC muss irgendwo für sich entscheiden, in welcher Position der Rollladen "sein" soll.
Diese Entscheidung habe ich nun in 2 Teile aufgeteilt:
- eine logische Position und
- den eigentlichen Fahrbefehl (die Übersetzung der logischen in eine Position des Geräts)

Ob der Rollladen am Ende gar nicht dort ankommt (weil ein Hinderniss die Bewegung stoppt oder ein User manuell eingreift, oder..)
ist dafür kein Thema.

Übrigens ist die Argumentation ASC sollte sich gar nicht darum kümmern, ob der Rolladen in der gewünschten Position angekommen ist,
da das Verantwortlichkeit des Rolladen-Devices ist, genau ein Grund, warum ASC intern mit den Positionsangaben nicht arbeiten sollte: Die gehören dem Rolladen-Device. Basta.

Ich hatte bei der Fahrsteuerung innerhalb ASC nur im Blick, dass es innerhalb der Steuerungslogik Aspekte gibt, die "mit höchster Priorität" andere Zielpositionen "übersteuern" und damit zu anderen Fahrbefehlen führen.

Weiterhin folgt aus Deiner Begründung auch gleich die Frage, wieso sich ASC überhaupt um konkrete Positionen von gesteuerten Geräten kümmert oder kümmern muss?
Denn die konkrete Umsetzung eines Fehrbefehls (und ggf. die Koordinierung mit weiteren Fahrbefehlen) ist Aufgabe des Rolladen-Devices.
Also:
Wenn der Rolladen morgens zur Open-Position fahren soll und noch bevor er dort ankommt Beschattung feststellt, er soll in Beschattungsposition fahren, dann kommt der 2 Befehl eben noch während der 1. Befehl bearbeitet wird und es wäre Aufgabe des Rolladen-Devices den neuen Befehl passend umzusetzen. (Entweder den alten Befehl stoppen oder den neuen im Anschluss an den ersten berarbeiten.)

[CoolTux]

Du meinst also sowas wie
Shadin => 20
Open => 0


Und im Code wird dann als Position lediglich $shutterPos->{shading} angegeben?

ASC muss schon wissen wo das Rollo gerade steht. Es macht keinen Sinn bei Fenster auf das Rollo in die Lüften Position zu fahren wenn es bereits oberhalb dieser Position steht.

[pruy]

Du meinst also sowas wie
Shadin => 20
Open => 0


Und im Code wird dann als Position lediglich $shutterPos->{shading} angegeben?

ASC muss schon wissen wo das Rollo gerade steht. Es macht keinen Sinn bei Fenster auf das Rollo in die Lüften Position zu fahren wenn es bereits oberhalb dieser Position steht.

Nicht ganz.
Am Ende wird diese Zuordnung "logische Position" >= Positionswert sicherlich als ASC Attribute im Rolladendevice hinterlegt sein.
Dann wird der entsprechende Code irgendwie in dieser Art auftreten.

Aber:
Für die eigentliche Steuerung ist die Frage, ob Shading bei 90 oder doch bei 70 liegen soll nicht wichtig (wird ohnehin vom Nutzer festgelegt.) Da ist nur wichtig, dass aktuell "shading" anliegt.

Es muss also ermittelt werden, dass aktuell "shading" gelten soll. In der Fahrsteuerung wird dann ermittelt, dass aktuell Shading bei 90 sein soll.
Dann kann der Fehrbefehl abesetzt werden.
Und genau da kommt dann ggf. ins Spiel, dass die aktuelle Positions bereits für den Fahrzweck kompatibel ist.

Denn, wenn ich aktuell bei 90 stehe (sagen wir mal Shading Position) und soll nun auf 80 fahren, macht es möglicherweise einen Unterschied, ob das wg. privacy oder wg. Ventilation erfolgen soll.

Die pauschale Aussage  "eine Position oberhalb" der Zielposition ist bereits eine passende, ist so wohl nicht korrekt.

Wenn ich wg. shading bei 90 stehe und nun wg. Ventilation auf 80 positionieren soll, dann ist eine Positionsveränderung angesagt.
Wenn ich statt dessen auf 80 fahren soll wg. WinProtect, könnte die 90 evtl. ein gute Position sein, die ich lieber nicht verlasse.

Diese Entscheidung an 100 Stellen zu verteilen und jedesmal neu zu implementieren (immer jeweils den Anteil, der gerade einschlägig ist), wird schnell unübersichtlich und führt zu Inkonsistenzen, die den Nutzer verwirren, weil der dachte, verstanden zu haben, was passieren wird.

Ich bin völlig einverstanden, dass abhängig von der aktuellen Position, die Steuerung ggf. keine Veränderung vornehmen sollte.
Aber genau diese Logik sollte an einer Stelle gebündelt sein und somit für alle Fälle einheitlich und konsistent.

Das Ganze ist eigentlich nur eine saubere Strukturierung (gerade geht es mir um "separation of concerns"). Führt einfach zu leichter wartbarem Code. Das möchte ich klar als Hilfestellung verstanden wissen. Ob die Grenzziehung so sinnvoll ist, wie ich mir das aktuell denke, muss nicht sicher sein. Da fehlt mir ggf ein paar Jahre Auseinandersetzung mit der Logik.

ich habe nur aus den zahlreichen Fragen in den Beiträgen (ich hab nicht alle gelesen) herausgelesen, dass regelmäßig die
Interpretation einer aktuellen Position als Zustand, etwas ist was schief geht.
Was wiederum kein Wunder ist: Die Abbildung ist surjektiv. Damit ist die Umkehrung von Position auf Zustand nicht eindeutig.
Man muss also auf dem logischen Zustand bleiben, solange es möglich ist und erst am Ende mit "echten" Positionen arbeiten.

(Wenn das jetzt zu theoretisch wurde: Tut mir leid, das muss manchmal sein)

[CoolTux]

Wenn ich wg. shading bei 90 stehe und nun wg. Ventilation auf 80 positionieren soll, dann ist eine Positionsveränderung angesagt.
Wenn ich statt dessen auf 80 fahren soll wg. WinProtect, könnte die 90 evtl. ein gute Position sein, die ich lieber nicht verlasse.

Diese Entscheidung an 100 Stellen zu verteilen und jedesmal neu zu implementieren (immer jeweils den Anteil, der gerade einschlägig ist), wird schnell unübersichtlich und führt zu Inkonsistenzen, die den Nutzer verwirren, weil der dachte, verstanden zu haben, was passieren wird.

Es gibt leider zu viele unterschiedliche Bedingungen pro Fahrgrund. Viele habe ich aber schon zusammen gelegt an Abfragen. Zum Beispiel die BlockingTime oder ob die aktuelle Position über oder unter dem Fahrziel liegt und so weiter. Das sind schon einzelne Routinen welche die den gesamten Code beinhalten für die korrekte Auswertung. Am Ende kommt nur eine 1 wahr oder eine 0 unwahr.

Sicherlich kann man vieles besser machen. Und wenn man es mir zeigt dann lerne ich sehr gerne dazu. Ich bin halt nur Hobbyprogrammierer. Dafür aber mit Leidenschaft 

[flummy1978]

Auch wenn Ihr Euch lieber zu zweit unterhaltet, oder unterhalten solltet (so tief in die Materie kann man kaum kommen  ) und der Rest dabei nicht so wichig war, möchte ich hier gern auch nochmal meinen Senf dazu geben:

Also:
Nicht einfach loggen:
"Einer der Beschattungsbedingungen wird nicht mehr erfüllt und somit wird der Beschattungsstatus um eine Stufe reduziert", sondern statt dessen explizit sagen:
"Beschattungsstatus wird um eine Stufe reduziert (ALT->NEU) da folgende Bedingungen nicht mehr erfüllt sind:  IstAzimut in [Min:Max], IstBrightnes<Grenzwert"

Das ist exakt das was ich bereits mehrmals erwähnt habe und auch in dieser Auflistung meinte..... daher finde ich diesen Einwand auch sehr gut

• Sehr sehr viele Funktionen, die sich einzeln nicht abschalten lassen und daher kompliziert in der (Grund)Einrichtung sind
• Viele Stolpersteine und Wechselwirkung die wenig bis gar nicht erklärt sind (.....Wenn Windschutz sagt "Position 0" und Beschattung sagt "Position 90" und Gebäudeschutz sagt "Position 100", was passiert dann tatsächlich?....) war ein super Beispiel
• Schwierige gezielte Debug Möglichkeit (wenn man 10 Rollos hat und Debug einschaltet, gehts leider schnell ins unmögliche noch was zu erkennen, weil man Debug nur global und nicht bei den Rollos selbst zuschalten kann. Damit ist der Log schnell überlaufen.)
• 1000de Beiträge die immerwieder in die gleiche Richtung gehen (Beschattung) und am Ende weiß fast nie jemand woran es lag, weil in der Zwischenzeit a. 25 neue Beiträge dazu kommen und b. durch Wechselwirkung aus anderen Gründen das Rollo doch wieder fährt (oder nicht)
• Auswertung (ausschließlich) anhand der Position, fand ich von Anfang an schwierig weil ich sicher bin, dass ich nicht der Einzige bin, bei dem an einem Rollo die Beschattung == Closed ist an einem anderen wiederum Beschattung == Privacy oder Regenschutz == LockOut == Windschutz == offen. Wiederum ein anderes ist Lüften == Beschattungsposition
• Ich bin ziemlich sicher mal von Funktionen gelesen zu haben, die sich 2,3 User gewünscht haben. (Die anderen haben eben wegen der 50 Beiträge dazwischen nicht mehr geantwortet) Diese Funktionen haben dann aber zu Wechselwirkung bzw. Fehlfunktionen in anderen Bereichen geführt