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.
Ankündigung
Einklappen
Wer nutzt denn eigentlich alles Home Assistant?
Einklappen
Dieses Thema ist geschlossen.
X
X
-
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 hab es zwar nicht ausprobiert, aber ich dachte, ich lasse einfach die Fahrzeiten weg, dann kann man auch nichts rechnen, oder?Zitat von crazyfx Beitrag anzeigenIch würde mir wünschen, dass man die Berechnung einfach deaktivieren kann.
Gruß, Waldemar
Einen Kommentar schreiben:
-
Der neue Aktor von MDT mit Fahrtzeitmessung passt es laufend an, KO gibt es glaub ich keines. Selbst habe ich einen Aktor ohne Fahrzeitmessung.
Einen Kommentar schreiben:
-
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.Zitat von crazyfx Beitrag anzeigen2. 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)
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.
Einen Kommentar schreiben:
-
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.
Einen Kommentar schreiben:
-
Ja das wird von der Integration berechnet. Damit das ordentlich integriert werden kann muss der eigentliche Feature Request an HA gehen, nicht an die Integration. Einer zB ist hier zu finden. https://github.com/home-assistant/ar...ure/issues/429
Einen Kommentar schreiben:
-
Da gibt es schon div. Feature requests, einen Versuch ist es Wert: https://github.com/XKNX/xknx/issues
Einen Kommentar schreiben:
-
Hi,
hab mich jetzt mal ne Zeit lang an dem UI ausgetobt (lovelace) und da mal die Möglichkeiten auszuloten und bin da sehr positiv überrascht. Aber eine Frage zur KNX-Integration hab ich noch:
Kann es sein, dass die KNX-cover-Integration die Positionsinformation alleine berechnet, wenn man die Fahrzeiten angegeben hat? Die Wirkung ist natürlich sehr schön, aber leider wird auch berechnet, wenn der Rollladen gesperrt ist. Es sieht also so aus, als ob der Rollladen fährt, obwohl er es nicht tut. Gibt es einen Sperreingang an der cover-Integration, den ich nicht gefunden habe? Die einzige andere Alternative, die mir einfällt, ist das Weglassen der Fahrzeiten und es dann selbst per automation berechnen. Sonst noch Ideen?
Kann man auf github eigentlich auch Featurewünsche äußern (in diesem Beispiel für einen Sperreingang)? Oder wo werden die Wünsche für neue Features geäußert?
Gruß, Waldemar
Einen Kommentar schreiben:
-
Hm Danke für Info... irgendwie wusste ich das ich das schon mal gelesen hab.
Die custom:shutter-card hab ich auch schon probiert aber die hat mir leider nicht so wirklich gefallen, vorallem de braucht pro Rolladen/Jalousie recht viel Platz.
Da wäre/ist mir sowas hier im Moment lieber:
Screenshot 2020-12-09 171605.png
Mal OT nimmt einer von euch an der HA Conference am Sonntag teil? Ich habe mich mal angemeldet.
Einen Kommentar schreiben:
-
Das dumme is dass das von HA an andere integrations so weitergeleitet wird. Man muss halt einfach damit leben das HA das genau anders definiert.
Will man zB von Alexa über HA ein Cover auf 30% fahren wird das als HA% interpretiert, nicht als KNX%.
Andererseits will man von ner Integration / Automation close_cover aufrufen müssen die Open und close Positionen richtig sein.
Wenn man es sich so hininvertiert dass eines passt, passt immer das andere nicht.
Einen Kommentar schreiben:
-
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:
PS: Das mit den Slidern ist mir noch gar nicht weiter aufgefallen, die nutze ich extrem selten; Danke für den Tipp mumpf!Code:- 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
Zuletzt geändert von MarkusLa; 09.12.2020, 16:58.
Einen Kommentar schreiben:
-
Hi,
ja das kenne ich. Das Problem ist, dass im HA der Prozentwert nicht die Rolladenposition angibt, sondern wie viel Licht noch reinkommt. Also ist 0% in HA (kein Licht von außen) = 100% in KNX. Bei invert_position wird die Positionsanzeige zwar umgerechnet (100 - p), aber das passt dann nicht mit der cover-card zusammen.
Ich nutze derzeit den KNX-Cover ohhe invert_position und nutze für die Anzeige die custom:shutter-card. Da kann man nur für die Anzeige die Position invertieren lassen (invert_percentage: true). Die Buttons sind dann nicht umgedreht und es geht so, wie man es vom KNX her kennt. Leider ist die card nicht sooo schick, aber da ich noch keine eigenen cards schreiben kann, lebe ich erstmal damit.
Gruß, Waldemar
Einen Kommentar schreiben:
-
Ich bin mittlerweile auf der Beta, funktioniert soweit einwandfrei aber was ich nicht verstehe ist:
Das bedeutet für mich (MDT JAL) ich muss das Setting eigentlich auf false setzen bzw. gar nicht setzen (da 100% = fully closed). Dann stimmen aber die Slider um einen % Wert anzufahren nicht bzw. sind genau verkehrtrum. Ich hab das Setting mal mit true aktiviert, jetzt stimmt auch die Richtung bzw. der % Wert wenn man mit HA die Rolläden fährt.Code:invert_position boolean (Optional, default: false) Set this to true if your actuator report fully closed as 0% in KNX.
Was aber echt blöd ist, scheinbar sind jetzt auch die auf und ab Pfeile vertauscht. Kennt ihr das ?Zuletzt geändert von FRO; 09.12.2020, 16:11.
Einen Kommentar schreiben:
-
Mit der aktuellen HA 1.0.0 beta sollte knx wieder vernünftig funktionieren.
Einen Kommentar schreiben:


Einen Kommentar schreiben: