feat/addmultiplebrightnesssensorsdegree by estebanri87 · Pull Request #6 · OpenKNX/OFM-ShutterControllerModule

estebanri87 · 2026-02-12T20:01:28Z

Erweiterung Beschattung (zusätzliche Sensoren, Implementierung Azimutausrichtung in Grad)

ETS/UI-Parameter für Fensterausrichtung und Azimutauswahl aktualisiert; Kompass-/Gradbezeichnungen, klarere Sichtbarkeitsregeln und Formatierung des Azimutsensors hinzugefügt.
ETS-Hilfetext hinzugefügt, der verdeutlicht, wann Aggregation bzw. Interpolation relevant ist.
Diagnoseprotokollierung für die Verwendung von ETS-Fensterausrichtung und Azimut-Zielen hinzugefügt.
Globale Statusmeldung „Beschattung Bereit KO“ pro Kanal eingeführt; Bereitschaftsmeldung pro Modus entfernt und KO-Offsets für Beschattungs-/Fenster-offen-Modi angepasst.
Die Bereitschaftslogik berücksichtigt Benutzereinflüsse: Beschattungssteuerung aktiviert, keine Kanalsperre, kein Fenster-offen-Handler, nicht im manuellen Modus und keine aktive Beschattungssperre/Brechungssperre.
Wiederherstellung der vorherigen Rollladen-/Lamellenposition nach dem Schließen des Fensters implementiert.
Dokumentation/Skripte aufeinander abgestimmt (Pfadkorrekturen, Dokumentation neu generiert).

…ing standby status -Updated ETS/UI parameters for window orientation and azimuth selection; added compass/degree labels, clearer visibility rules, and azimuth sensor formatting. -Added ETS help text clarifying when aggregation is relevant versus interpolation. -Added diagnostic logging for ETS window orientation and azimuth target usage. -Introduced global per-channel Status Beschattung Bereit KO; removed per-mode readiness KO and adjusted KO offsets for shading/window-open modes. -Readiness logic now reflects user-influence factors: shading control enabled, no channel lock, no window-open handler, not in manual mode, and no shading lock/break lock active. -Implemented window open/tilt restore to previous shutter/slat position once the window closes. -Kept docs/scripts aligned (path fixes, generated docs)

mgeramb

Ein paar erste Kommentare von mir.

mgeramb · 2026-02-20T19:00:29Z

src/MeasurementWatchdog.h

+    virtual bool isChanged() const = 0;
+};
+
+class MeasurementWatchdog : public MeasurementSource


Wozu dient die Aufsplitterung zwischen Source und Watchdog? Jedes KNX Gruppenobjekt das einen Messwert liefert, sollte den Watchdog support haben

Die Aufsplitterung erfolgte für BrightnessMeasurement, das mehrere Sensoren vereint:
• MeasurementSource: Interface für alle Messquellen (KOs, berechnete/aggregierte Werte)
• MeasurementWatchdog: KO mit Watchdog-Funktionalität
• BrightnessMeasurement: Aggregiert 4 Sensoren basierend auf Azimut-Interpolation
Das Problem: war das BrightnessMeasurement keine direkte KO-Quelle ist, sondern ein berechneter Wert aus mehreren Sensoren. Ein Watchdog würde hier nicht passen, da die einzelnen Sensor-Watchdogs bereits überwachen.
Wir haben zwei Möglichkeiten:
• Interface umbenennen zur Klarheit (IAggregatedMeasurement vs IDirectMeasurement)
• BrightnessMeasurement direkt in CallContext integrieren ohne Interface-Hierarchie

mgeramb · 2026-02-20T19:01:17Z

src/PositionController.cpp

-    // <Enumeration Text="Manuelle Bedienung über Aktor" Value="0" Id="%ENID%" />
-    // <Enumeration Text="Modul sendet Auf/Ab zum Aktor" Value="1" Id="%ENID%" />
-    // <Enumeration Text="Modul sendet 0/100% zum Aktor " Value="2" Id="%ENID%" />
+    // <Enumeration Text="Manual control via actuator" Value="0" Id="%ENID%" />


Warum wurde das auf Englisch übersetzt? Das sind die Texte aus den Enum in der ETS. Das darf nicht übersetzt sein

Stimmt, das war unbeabsichtigt. Ich kann alle Enum-Kommentartexte wieder exakt auf die ETS-Originaltexte (Deutsch) zurück setzen. Oder willst du das machen?

Bitte zurück ändern

mgeramb · 2026-02-20T19:02:01Z

src/ShutterControllerChannel.cpp

-    // <Enumeration Text="Nein" Value="0" Id="%ENID%" />
-    // <Enumeration Text="Stellwert %" Value="1" Id="%ENID%" />
-    // <Enumeration Text="Heizungsanforderung (EIN/AUS)" Value="2" Id="%ENID%" />
+    // <Enumeration Text="No" Value="0" Id="%ENID%" />


Auch hier, bitte keine Übersetzungen

Ich kann alle Kommentartexte auf Deutsch ändern.

mgeramb · 2026-02-20T19:03:34Z

src/ShutterControllerChannel.cpp

        }
+        if (startingWindowOpen)
+        {
+            _windowOpenRestoreActive = true;


Was macht dieser Block genau? Wo war da ein Problem?

Problem vorher: Wenn Fenster geöffnet/gekippt → Rollo fährt in definierte Position → Fenster schließt → Rollo blieb in definierter Position (alte Position ging verloren).
Jetzt: Rollo fährt automatisch auf die Position zurück, die er vor dem Fenster-Öffnen hatte.
Aus meiner Sicht ist das eine Komfortfunktion - > z.B. nach dem Lüften fährt das Rollo automatisch zur vorherigen Position zurück.

Verstehe ich nicht, dass ist ja die Standardfunktion die ich auch nutze, und ja, das Rollo soll nach dem schließen des Fensters wieder in die Ursprungsposition fahren. Und das macht sie bei mir auch.
Bitte beschreib mal genau in welcher Position die Rollo vor dem Fenster offen ist und was deine Einstellung in der ETS sind, ich würde das gerne nachstellen, bevor wir hier was ändern was eventuell einen anderen Grund hat.

mgeramb · 2026-02-20T19:04:54Z

src/ShutterControllerChannel.cpp

    _currentMode->control(callContext, _positionController);
    _positionController.control(callContext);

+#ifdef KoSHC_CShadingReadyUser


Was macht dieses #ifdef ? Das define kommt ja vom Producer und sollte so der KO vorhanden ist, immer gesetzt sein

Das #ifdef ist als Rückwärtskompatibilität zu älteren bzw. generierten Headern gedacht. Wenn wir garantieren, dass alle Builds immer mit aktualisiertem Producer laufen, kann es auch entfallen.

Das kann entfallen, wir können die Producer Minimum Version auch über das XML vorschreiben. Wird aber nicht nötig sein, da die Logik die beim RaumController und bei der Jalousiensteuerung dabei ist, das ohnedies schon macht. Also bitte #ifdef Raus nehmen

mgeramb · 2026-02-20T19:09:04Z

src/ShutterControllerModule.ModeShading.xml

 							<ComObject Id="%AID%_O-%TT%%CC%%PPP+5%" Number="%K%En+5%%" ObjectSize="4 Bytes" DatapointType="DPST-27-1" Name="C%C%Shading%Pn%DiagnoseNotAllowedBit" Text="" FunctionText="" ReadFlag="Enabled" WriteFlag="Disabled" CommunicationFlag="Enabled" TransmitFlag="Enabled" UpdateFlag="Disabled" ReadOnInitFlag="Disabled" />
 							<!-- Modus 1 Diagnose "Nicht erlaubt" Grund -->
 							<ComObject Id="%AID%_O-%TT%%CC%%PPP+6%" Number="%K%En+6%%" ObjectSize="1 Byte" DatapointType="DPST-5-5" Name="C%C%Shading%Pn%DiagnoseNotAllowedReason" Text="" FunctionText="" ReadFlag="Enabled" WriteFlag="Disabled" CommunicationFlag="Enabled" TransmitFlag="Enabled" UpdateFlag="Disabled" ReadOnInitFlag="Disabled" />
+							<!-- Modus 1 Bereitschaft -->


Neue KOs hier einzuführen bricht die Updatefähigkeit wenn der Benutzer die Logik verwendet hat und dort KO Nummern referenziert. Braucht es den KO wirklich unbedingt?

Verstanden. Sollen wir das KO ans Ende verschieben oder ganz entfernen? Ich würde bevorzuge es zu behalten. und zu verschieben.
Damit visualisiere ich die Bereitschaft der Beschattung die durch den Nutzer beeinflussbar sind.

Lass uns das in Slack diskutieren, das Thema ist schwieriger, aber wir werden ein Lösung finden

estebanri87 · 2026-02-21T23:21:14Z

Habe deine Anmerkungen kurz kommentiert.

estebanri87 added 2 commits February 10, 2026 22:34

Update toDo + Release Notes

7bd5322

mgeramb requested changes Feb 20, 2026

View reviewed changes

Conversation

estebanri87 commented Feb 12, 2026

Uh oh!

mgeramb left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

estebanri87 commented Feb 21, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants