Neue HA-Integration: Shadow Control

[starwarsfan]

Hallo miteinander

Release 0.5.0 ist verfügbar. Die Changes:

• Add configuration dump service
• Implement new shutter type "Rolling shutter / blind"
• Improve readme files

Config Dump Service
Da die Konfiguration sehr umfangreich ist, kann diese nun in das HA-Log gedumped werden. Details siehe Doku.

Neuer Behangtyp Jalousie
Es gibt einen neuen Behangtyp für Jalousien resp. Rollos. Wird dieser Typ verwendet, wird die Konfiguration der nicht relevanten Werte ausgeblendet. Konkret sind das sämtliche Winkeleinstellungen sowie die Lamellenabmessungen. Im Sensor der Instanz werden in dem Fall ebenfalls keinerlei Winkel ausgegeben.

[Evolution100]

Ich hab gestern mal versucht das neue Gerät in eine Automation einzubinden... z.B. für Lüften Sperren in Zwangsposition... nun frag ich mich, ob ich für z.B. Wartungszwecke, die Integration auch komplett abschalten kann (in den Geräten geht das, aber nicht aus dem Dashboard raus...) und die Zwangsposition bringt ggf. die Jalousie zum fahren, was ich in diesem Fall nicht mehr möchte.

Hat da jemand eine Idee?

[starwarsfan]

Hi

nun frag ich mich, ob ich für z.B. Wartungszwecke, die Integration auch komplett abschalten kann

Natürlich geht das, siehe hier und hier.

[Evolution100]

Wenn die Beschattung und die Dämmerung deaktiviert ist und jemand die Zwangspositionierung auslöst, fährt die Jalousie ja auf die Sperrhöhe

Die Zwangspositionierung hätte ich z. B. für die Lüftung oder Bewohner schläft verwendet

[uncelsam]

Wenn ich richtig dran bin startet die Beschattung nur wenn, die Werte des Behangs dem Status entsprechen (so wird es zumindest im entsprechenden Video von Edomi erklärt). Wenn Du also vorher manuell gefahren bis, läuft die Automatik gar nicht an...

[woda]

starwarsfan Zuerst, vielen Dank für die Integration
Hatte vorher in EDOMI mehrere Jahre was eigenes aus am laufen (Jeder Rollo ein eigenes Logikblatt und alles diskret, ohne Baustein).
Aktuell bin ich noch auf dem CCA Blueprint in HA, weil es einige Funktionen bietet, welche ich in EDOMI auch umgesetzt hatte.

Wie setzt ihr folgende Funktionen aktuell um?:

• Beschattung erst ab einer bestimmten Aussentemperatur; Innentemperatur
• Abends Rollo frühestens zu und spätestens zu Uhrzeit definieren
• Morgens Rollo frühestens auf und spätestens auf Uhrzeit definieren
• Hysterese Werte für die Helligkeit für die Beschattung und Dämmerung
  z.B. Beschattung ein bei 25000lx, Beschattung aus bei 10000lx
  Abends zu bei 90lx, morgens auf bei 130lx

Gruß,
Wolfgang

[uncelsam]

Hierfür hab ich einen extra Theard aufgemacht:

https://knx-user-forum.de/forum/proj...matik-feigeben

[starwarsfan]

Hallo miteinander

Shadow Control ist nun als Default-Integration in HACS verfügbar:

image.png

Damit braucht es für die Installation kein händisches hinzufügen der URL mehr.

[starwarsfan]

Hallo Wolfgang

[*]Beschattung erst ab einer bestimmten Aussentemperatur; Innentemperatur

Das mach' ich im Moment noch gar nicht. Hatte das vor langer Zeit mal begonnen aber nicht weiter verfolgt. Diskussion dazu siehe anderer Thread.

[*]Abends Rollo frühestens zu und spätestens zu Uhrzeit definieren[*]Morgens Rollo frühestens auf und spätestens auf Uhrzeit definieren

Uhrzeiten verwende ich überhaupt nicht aber für gewisse Räume wird die Beschattung via Tag-Nacht-Status des Hauses bzw. des Raumes gesperrt. Von daher wäre das in HA wohl ähnlich zu lösen.

[*]Hysterese Werte für die Helligkeit für die Beschattung und Dämmerung
z.B. Beschattung ein bei 25000lx, Beschattung aus bei 10000lx
Abends zu bei 90lx, morgens auf bei 130lx

Die Integration funktioniert eben nicht via Hysterese sondern über Timer. Ich habe eine Hysterese in den letzten zehn Jahren nicht vermisst aber das soll nicht heissen, dass man das nicht einbauen kann. Jetzt als HA-Integration ist das einfacher als vorher beim Edomi-Baustein...

[ChristianW]

Hallo Yves,

kannst du dir kurz #45 anschauen? Vielleicht ist es untergegangen :-).

Danke und Grüße
Christian

[uncelsam]

Hallo,

nach dem ich heute bei Sonnenschein mal zu Hause war, konnte ich das mit dem Lamellenwinkel testen.
Wenn ich in der KNX-Yaml den Lamellenwinkel invertiere passt , dass die Lamellen nach aussen kippen.
Denke das ist wieder das "Problem" wie bei der Höhe, das die KNX Werte invertiert zu den Werten in Homeassistant sind.

Evtl. könnte man für das "Problem" eine Schalter einbau der die Werte invertiert ausgibt, so fern das nicht zu viel Aufwand ist.

[starwarsfan]

Hallo Holger

Denke das ist wieder das "Problem" wie bei der Höhe, das die KNX Werte invertiert zu den Werten in Homeassistant sind.

Nein, das hat damit überhaupt nichts zu tun. Sowohl Shadow Control als auch die KNX-Integration arbeiten konform nach dem HA-Standard, wonach 0% "ganz unten" (geschlossen) und 100% "ganz oben" (offen) ist. Die KNX-Integration wandelt die Werte direkt vor dem beschreiben der GAs entsprechend um, siehe hier und bei Shadow Control ist es schlussendlich so, dass intern nach KNX-Standard gerechnet wird, die Ausgaben aber nach HA-Standard erfolgen.

Bei Dir geht's aber um 180° schwenkbare Lamellen, da sind beide Endlagen geschlossen, also egal ob 0% oder 100%. Wenn Du nun also die Werte invertierst, dann schwenken sie eben in die andere Richtung.

Evtl. könnte man für das "Problem" eine Schalter einbau der die Werte invertiert ausgibt, so fern das nicht zu viel Aufwand ist.

IMHO gibt es hier kein Problem oder zumindest sehe ich es noch nicht.

Nur damit wir uns richtig verstehen: Was genau passiert, wenn Du in der KNX-Integration alles beim Standard lässt, also nicht invertiert und dann die Lamellenwinkel 0%/50%/100% anfährst? Was ist das für ein Aktor?

[uncelsam]

Genau bei mir geht es um 180° schwenkbare Lamellen.

Aktor ist ein Becker KNX/SMI-Aktor REG-3TE 16K BT, die Lamellenwinkel werden in der ETS mittels DCA konfiguiert, also die Impulse für die vollen 180°.

Diese werden dann anhand es % Wertes Verfahren, (bei 3000 Impulsen für die vollen 180°) werden 1500 Pulse gefahren, dass die Lamelle auf 50% steht, das Funktioniert z.B. über YouVI auch perfekt.
(Der Aktor gleicht sogar das Umkehrspiel aus, in dem er die Lamellen immer von der selben richtung Anfährt)


Auf KNX-Seite:

50% ist immer Waagerecht.
bei 100% sind die Lamellen nach Aussen gekippt (wie beim herunterfahren)
bei 0% sind die Lamellen nach Innen gekippt (wie beim hochfahren)

Bei HA ist ohne invertierung genau gleich.

Wenn ich die Lamellenwinkel invertiere ist 0% voll nach aussen gekippt und 100% voll nach innen.

Wenn Shadow-Control jetzt 20% anzeigt, fährt der KNX Aktor auch auf 20%, also die Lamellen nach innen gekippt.
Wenn ich jetzt in der KNX-Integration invertiere, fährt der Aktor auf 80% kippt also die Lamellen nach aussen (wie gewollt).

Ich hoffe das ist jetzt so verständlich...

Grüße Holger

[schrotti93]

Vielen Dank für das Migrieren deines LBS auf HA - hatte den LBS lange zufriedenstellend im Einsatz

Da deine Integration ja die Behanghöhe nachführt, damit der eingestellte Lichtstreifen erreicht wird, ist die richtige Positionierung relativ wichtig.

Bei meinen Rollläden ist es im Extremfall - je nach Behanghöhe - so, dass bei einer RM vom Aktor von 70% der Behang schon auf ca. 95% ist.

Leider kann mein Aktor das nicht linearisieren.
Bei Edomi war das kein Problem mit dem Logikeditor.
Bei HA stellt die KNX Integration gleich die Cover Entitäten bereit, da kann man "dazwischen" nichts machen.
Die einzige Lösung welche mir einfällt wäre, für jedes Rollo ein eigenes Template-Cover, basierend auf den KNX Cover Entitäten, anzulegen...

Daher nun meine Frage bzw. Bitte:
Ist hier deinerseits noch was geplant, damit man die Positionsrückmeldung (bzw. dann im Umkehrschluss auch den Expose) linearisieren kann?
Bei Edomi sah das in etwa so aus:
RM von 0-70% entsprechen 0-95%
RM von 71-100% entsprechen 96-100%
Ansteuerung dann natürlich umgekehrt.

Danke im Voraus

[DerSeppel]

Also was du machen kannst ist, dass du einen KNX Sensor für die Position anlegst. Name z.B. "knx_rollladen_rohwert"
Dann erstellst du einen Template Sensor, der dir die linearisierten Werte berechnet. Anhand deiner Angaben oben etwa so:

template:
  - sensor:
      - name: "Rollladen Position Linearisiert"
        unit_of_measurement: "%"
        state: >
          {% set knx_rohwert = states('sensor.knx_rollladen_rohwert') | float(0) %}
          {% if knx_rohwert <= 70 %}
            {# Bereich 1: Rohwert 0-70% -> HA 0-96% #}
            {{ (knx_rohwert * (96 / 70)) | round(0) }}
          {% else %}
            {# Bereich  2: Rohwert 71-100% -> HA 96-100% #}
            {{ ((knx_rohwert - 70) * (4 / 29) + 96) | round(0) }}
          {% endif %}​

Dann verwendest du den Wert in einem Template-Cover:

cover:
  - platform: template
    covers:
      mein_rollladen_linearisiert:
        friendly_name: "Mein Rollladen"
        position_template: "{{ states('sensor.rollladen_position_linearisiert') | int }}"
...​

Ungetestet, aber so in etwa sollte es gehen. Hat bei mir auch ne Weile gedauert, bis ich die Template Entitäten verstanden habe. Aber damit kann man solche Sonderfälle eigentlich recht elegant lösen.

Ich probier das selbst mal die Tage aus. Bisher hat mich das nicht-lineare Verhalten unserer Rollläden nicht genug gestört.