Wer nutzt denn eigentlich alles Home Assistant?

[crazyfx]

Ich bin auch kein Fan von der automatischen Positionsberechnung über die Zeit aus folgenden Gründen:

1. Will ich die Zeit nicht doppelt warten, die Zeit habe ich bereits im Jalousieaktor eingetragen
2. Die Zeit ist zB bei Aktoren mit Fahrzeitmessung nicht konstant
3. Die Zeit ist auch nicht konstant durch äußere Einflüsse (Längung der Bänder durch Temperatur zB)
4. Wenn ich die Bewegung sehen will, dann aktiviere ich beim Jalousieaktor direkt, dass er die Position während der Fahrt laufend ausschicken soll

Und dann noch das Thema der Sperren natürlich.
Ich würde mir wünschen, dass man die Berechnung einfach deaktivieren kann.

[meti]

2. Die Zeit ist zB bei Aktoren mit Fahrzeitmessung nicht konstant
3. Die Zeit ist auch nicht konstant durch äußere Einflüsse (Längung der Bänder durch Temperatur zB)

Wird die Zeit bei Fahrzeitmessung kontinuierlich gemessen oder einmalig? Es würd mich ja wundern wenn sich, im Laufe des Lebens eines Motors, diese Zeiten um über 5% ändern würden. Aber Erfahrung hab ich damit keine.
Kann man die Ermittelte Fahrzeit bei Fahrzeitmessung auf ein KO ausgeben?

Selbst wenn sich das stark ändert wird man wahrscheinlich keinen Unterschied sehen weil eine empfangene Position immer die Errechnete überschreibt. Dh. gilt immer die Aktorposition.

[crazyfx]

Der neue Aktor von MDT mit Fahrtzeitmessung passt es laufend an, KO gibt es glaub ich keines. Selbst habe ich einen Aktor ohne Fahrzeitmessung.

[mumpf]

Hi,

danke für das Feedback. Das mit der Sperre war auch zu kurz von mir gedacht. Es gibt ja auch noch die ganzen Alarmfunktionen, die ja auch Sperren sind und vom Aktor ausgelöst werden.

Eigentlich muss die lokale Berechnung nur laufen, wenn vom Aktor ein "Motor fährt" Status kommt. Und in welche Richtung gerechnet wird, kommt von dem Status "Fahrtrichtung". Und wenn der Aktor sowieso die Position ausgibt, müsste eigentlich nicht lokal gerechnet werden. Wenn aber der Wert passend überschrieben wird, ist das ja auch OK.

Ich werde erstmal probieren, was ich mit einer automation erreichen kann.

Ich würde mir wünschen, dass man die Berechnung einfach deaktivieren kann.

Ich hab es zwar nicht ausprobiert, aber ich dachte, ich lasse einfach die Fahrzeiten weg, dann kann man auch nichts rechnen, oder?

Gruß, Waldemar

[meti]

Nein, da nimmt's einfach default Werte.
Das Problem an der Sache ist halt das es nicht den einen Aktor gibt. Viele haben kein "Motor fährt" KO. Viele geben nichtmal die Position aus.

[mumpf]

Das Problem an der Sache ist halt das es nicht den einen Aktor gibt.

Das ist klar, aber deswegen kann man auch nicht nur ein Verhalten implementieren. Und man wird auch ohne passende Status-Info vom Aktor nicht alles fehlerfrei simulieren können. Die Frage ist eher, ob man verschiedene Verhalten der cover-Intergration durch passende Parametrisierung erreichen kann. Aber eine Lösung hab ich auch nicht wirklich parat für das Problem . Ist sicherlich eine "Herausforderung". Aber ich verstehe jetzt zumindest, dass es Abweichungen im Verhalten zwischen UI und Wirklichkeit geben kann und ich muss für einzelne Fälle entscheiden, inwiefern ich damit leben will

Gruß, Waldemar

[Kamsi]

Ich habe auch eine Frage zur Raffstoresteuerung. Laut Doku sind hier die Beispielparameter angegeben:

# Example configuration.yaml entry
knx:
cover:
- name: "Kitchen.Shutter"
move_long_address: '3/0/0'
move_short_address: '3/0/1'
stop_address: '3/0/4'
position_address: '3/0/3'
position_state_address: '3/0/2'
travelling_time_down: 51
travelling_time_up: 61

Bei den Parametern move_long_address und move_short_address weiß ich nicht was ich hier eintragen soll. Ich habe bei meinen Aktor nur 1 Objekt mit GA 1/1/0 um den Behang auf/ab zu fahren, siehe Bild. Aktor ist der ABB JRA/S8.230.5.1 8f 230V
Die GA in beide Parameter schreiben funktioniert nicht.
JRA_GAs.png



Ist wahrscheinlich nur eine Kleinigkeit aber ich stehe hier grad komplett auf der Leitung 😕

[crazyfx]

move_long_address = "Auf / Ab" also bei dir 1/1/0
move_short_address = Lamellenverst. / Stopp also bei dir 1/2/0

[meti]

Kamsi Ich hab den gleichen Aktor (den .2.1 ohne Fahrzeitermittlung) und bei mir gibts da immer ein eigenes Stop Objekt (evtl weil ich keine Lamellenverstellung hab?).
Wenn du Zwischenpositionen willst könntest du das im Aktor unter Funktionen aktivieren. Sonst werden die von HA berechnet und ein Stop zur berechneten Zeit nachgesendet. Funktioniert aber im Grunde genau so.

PS: bitte bei Problemen detailliertere Fehlerbeschreibung als "funktioniert nicht" verfassen 😉

[momax]

Richtig, für den MDT JAL habe ich invert position auch auf false (bzw. auskommentiert). Hat so, seitdem das vor ein paar Monaten endlich "korrekt" implementiert wurde, bis zum aktuellen Bug gut funktioniert. Ich hoffe mit dem Bugfix ist das nicht wieder durcheinander.

Bsp:

- name: "EG Küche Rolladen Front"
move_long_address: '3/1/15'
move_short_address: '3/1/16'
position_state_address: '3/1/17'
travelling_time_down: 19
travelling_time_up: 19
# invert_position: true

PS: Das mit den Slidern ist mir noch gar nicht weiter aufgefallen, die nutze ich extrem selten; Danke für den Tipp mumpf!

Ich habe auch NDT JAL und bei mir funktioniert leider nicht.

- name: "Büro"
move_long_address: '2/1/28'
move_short_address: '2/2/28'
#stop_address: '2/2/28'
position_address: '2/3/0'
position_state_address: '2/4/0'
#assumed_state: True
#angle_address: '9/0/4'
#angle_state_address: '9/0/5'
#invert_position: true
#invert_angle: true
travelling_time_down: 14
travelling_time_up: 14

Das custom:shutter-card.und (invert_percentage: true) funktioniert leider auch wie von dir mumpf oben beschrieben nicht.
Was mache ich hier falsch?
Möchte gerne alles auf dem Homeassi umziehen und hänge gerade bei den Rollos.

Vielen Dank euch!

[crazyfx]

Und was funktioniert nicht?
Und woher sollen wir wissen, welche Gruppenadressen bei dir im ETS verbunden sind?

[mumpf]

Hi,

ich kann hier nur schreiben, wie es bei mir funktioniert. Mit 0.117.6. Auch mit einem MDT JAL-Aktor.

in HA:

- name: rollo_terrasse
  move_long_address: '12/1/0'
  stop_address: '12/1/2'
  position_address: '12/1/3'
  position_state_address: '12/1/6'
  travelling_time_down: 30
  travelling_time_up: 31
  invert_position: false

Lovelace:

type: 'custom:shutter-card'
entities:
  - entity: cover.rollo_terrasse
    name: Terrassentür
    buttons_position: right
    invert_percentage: true

Mit den Settings erhalte ich eine Anzeige von 100% bei geschlossenem Rolladen im UI. Natürlich ist die Position des cover.rollo_terrasse immer noch 0%, daran ändert das Setup nichts.

Gruß, Waldemar

[momax]

Was nicht funktioniert ist was die meistens hier (Bitte oben lesen!) beschreiben und darauf habe ich auch referenziert:
in Homeassitant entspricht 100% nicht den KNX Standard (Rolloden unten/zu) sondern Offen/Oben.
Meine KNX und Homeassitant Config funktioniert einwandfrei nur Status nicht,

[MarkusLa]

In HA 0.118 ist knx bzw. der Status ja eh kaputt. Also entweder mit der 0.117 arbeiten oder mit der 1.0 Beta (?)
alles andere führt zu viel mehr Frust als nötig.
mit 0.117 hat es so bei uns funktioniert, 0% / 100% und Pfeile haben getan was sie sollten. Ob die slider funktioniert haben oder irgendwas zwischen 0 / 100 korrekt angezeigt wird weiß ich nicht, dazu nutze ich das zu selten.

[meti]

Also jetzt nochmal: das 100% am Slider in HA als offen gilt ist kein Bug sondern HA definiert das einfach so (wie auch zB. HomeKit).
Auf KNX kommt wenn ihr von HA 100% einstellt ein Telegram mit 0% raus.

KNX: % geschlossen
HA, HomeKit: % geöffnet