Wer nutzt denn eigentlich alles Home Assistant?

[Tontechniker]

Hallo Waldemar,
ich habe dieses Interface https://selfbus.myxwiki.org/xwiki/bi...-%20Selbstbau/ . In meiner anderen Anwendung (CometVisu) funktioniert diese Schnittstelle mit EIBD über ttyAMA0 ohne Probleme. Mit dem add on KNX-daemon von Franz Koch arbeitet er mit knxd, aber über die USB-Schnittstelle (ttyACM0) des Raspi. Ich habe jetzt die Schnittstelle auf ttyAMA0 geändert. leider geht das nich so einfach (KNX-daemon im Anhang). Danach müsste knxd schon im container installiert sein.
Gruß, Hans
hass-io-addons-master.zip

[mumpf]

Hi,

wenn Du schon den eibd für die CometVisu nutzt, dann nimm den doch auch für Home Assistant, der unterstützt ja tunneling...

Bei Deinem eigentlichen Problem kann ich Dir nicht wirklich helfen, ich hab meinen eibd auch auf nem anderen Rechner (wiregate) laufen, nicht integriert in die HA-Instanz.

Gruß, Waldemar

[Tontechniker]

Danke Waldemar!
Habe Home Assistant erst einmal wieder aufgegeben - schade!
Gruß, Hans

[mumpf]

Hi,

Frage an die "Erfahrenen" unter euch: Wie ist denn die Performance vom HA, wenn es viele automations gibt? Also so 1000 bis 2000? Und viele Entities? Bricht es dann irgendwann ein?

Ich hab so 3000 GA, selbst wenn ich nicht alles in HA rüberbringe, würde ich mit ca. 1000 Entities rechnen. Und so wie ich derzeit die Zustandsautomaten umsetzen kann, muss ich wohl 2 Automations pro Zustand machen. Alleine meine Rolladensteuerung hat derzeit 32 Zustände, bei 17 Fenstern und 2 Automations pro Zustand macht das 17*32*2 = 1088 Automations.

Ich habe natürlich nicht vor, das alles manuell anzulegen, sondern werde es generieren (auch wenn mir noch nicht klar ist, wie). Aber ich will mir nicht ewig viel Arbeit machen und dann hinterher feststellen, dass es gar nicht geht...

Ich wäre somit an Erfahrungswerten interessiert, wie das mit vielen vielen Objekten in HA geht...

Gruß, Waldemar

[Jo07]

Wie ist denn die Performance vom HA, wenn es viele automations gibt? Also so 1000 bis 2000? Und viele Entities? Bricht es dann irgendwann ein?

Ich denke das hängt stark von der Verwendeten Hardware für den HA ab..
Ich nutzte einen PI4 mit 4 GB Ram, auf dem noch paar andere Dienste laufen und habe bisher keine Performance Probleme...
Einzig die Datenbanken sind bei Größeren Abfragen etwas träge (Influx und MariaDB).

Alleine meine Rolladensteuerung hat derzeit 32 Zustände, bei 17 Fenstern und 2 Automations pro Zustand macht das 17*32*2 = 1088 Automations

Was für Automations nutzt du denn für die Rollos?
Ich habe 12 Rollos, und diese jeweils als eigenes Entity angelegt. Automations zur Steuerung habe ich bisher keine benötigt, geht ja out-of the-box.
Im habe im Aktor Automatikpositionen definiert und steuere diese per HA-Switch, damit komme ich auf 4 Stück für meine "Automations"... :O
Du kannst entitäten auch Gruppieren, falls es dir hilft?

Mich würde interessieren, was die "32 Zustände" sind?
Ich komme pro Fenster auf knapp 3 Zustände Auf / Zu / Beschattung (2x)

[mumpf]

Hi Johann,

Ich komme pro Fenster auf knapp 3 Zustände Auf / Zu / Beschattung (2x)

So einfach hab ich es mir noch nie gemacht . Zuerstmal: Meine Rolladenaktoren haben noch keine Beschattungsfunktionen eingebaut. Allerdings vermisse ich die nicht wirklich, weil ich festgestellt habe, dass mir die - soweit ich mich jeweils in die Applikationsbeschreibung eingelesen habe - sowieso nicht ausreichen. Ich will meine Rolläden komplett automatisch laufen haben und trotzdem manuelle Bedienung erlauben.
Bei den automatischen Aktionen spielen folgende Aspekte eine Rolle:

• Alarme (Rauchmelder, Stromausfall)
• Abwesenheit (kurzfristige, also kleiner 1 Tag)
• Urlaub (also langfristige Abwesenheit > 1 Tag)
• Beschattung
• Sichtschutz (in Räumen, die von außen einsehbar sind, bei bestimmten Lichtverhältnissen den Rollladen passend runterfahren)
• Blendschutz (je nach Sonnenstand und Szene (z.B. Fernsehen) den Rollladen passend fahren)
• Tür-/Fensterüberwachung (das übliche: Tür auf->hochfahren, Tür/Fenster gekippt->Schlitzposition)
• Lichtoptimierung (Wenn Rollladen unten und Licht an und draußen hell (z.B. morgens im Sommer), wird statt Licht anzumachen der Rollladen hochgefahren)
• Manuellmodus (alle Automatiken - außer Alarme - können manuell übersteuert werden. Das bleibt so lange erhalten wie auch Präsenz im Raum ist)

Diese ganzen Bereiche sind natürlich nicht unabhängig voneinander und beeinflussen sich. Ferner gibt es bestimmte Bereiche, die nicht in allen Räumen sinnvoll sind. Und dann gibt es individuelle Wünsche (meine Kinder in ihren Kinderzimmern, meine Frau in ihrem Büro), die noch hinzukommen. So ergeben sich bei mir folgende Zustände (es sind inzwischen sogar 33):

"Rauchalarm": {
    "description": "höchste Prio - Rauchalarm macht die Rolllaeden auf 0% und bleibt in dem Zustand für min. 3 Minuten"
},
"Gesperrt": {
    "description": "falls die Sperre gesetzt ist, soll auch manuell keine Verstellung möglich sein"
},
"SettingsTrigger": {
    "description": "Dieser Zustand wird sofort wieder verlassen, führt aber dazu, dass Änderungen an den Settings aktuell gesetzt werden"
},
"MovingTrigger": {
    "description": "Warten, bis das Rollo aufhört zu fahren, dann PM Sperre entfernen, nur im Veschattungsfall"
},
"Schlafen": {
    "description": "Spezialstatus im Schlafzimmer wegen Baby, jegliche Verschattungs- oder Öffnungsautomatik ist deaktiviert"
},
"Manuell": {
    "description": "Manueller Modus hat Prio vor fast allen Automatiken und bleibt bestehen, solange Praesenz da ist, Nachlauf 15 Minuten"
},
"Krank": {
    "description": "Bei krank sind alle folgenden Automatiken deaktiviert, Manuellbedienung noch möglich, keine Rückfallzeit"
},
"Besuch": {
    "description": "Besuch darf ausschlafen und wird erst Mittags verlassen"
},
"SchlafenAnfang": {
    "description": "Schlafen Teil 1: Von 12:00 bis 3:00 Uhr wird Schlafmodus erhalten, sobald er manuell eingeschaltet wurde"
},
"Schultag": {
    "description": "An einem Schultag wird der Rolladen schon um 7 Uhr hochgefahren, wenn es draußen hell genug ist"
},
"Schulfrei": {
    "description": "An einem schulfreien Tag erst um 10 Uhr hochfahren"
},
"SchlafenEnde": {
    "description": "Schlafen Teil 2: Wenn nicht durch einen der Zustaende vorher, wir Schlafen spaetestens um 12 Uhr beendet"
},
"Abwesend": {
    "description": "Bei Abwesenheit werden alle Rolllaeden, die eine Abwesenheitsposition zugewiesen haben, tagsüber in diese Position gefahren"
},
"OffenTag": {
    "description": "Terrassentüren, die geöffnet sind, lassen den Rolladen oben, ab 23:30 gilt das nicht mehr (dann wurde die Tür vergessen zuzumachen). TODO: Status Party, der das wieder übersteuert"
},
"Sichtschutz": {
    "description": "in der Dämmerung sollen bei bestimmten Fenstern (Klo, Bad, Schlafzimmer zum Nachbarn) bei Licht die Rollos zugehen, damit man nicht reingucken kann "
},
"OffenNacht": {
    "description": "Offene Fenster sollten Nachts auch auf Schliztpositions fahren, aber nur die, die nicht als Tueren markiert sind (z.B. Terrassentuer)"
},
"KippNacht": {
    "description": "Nachts führen gekippte Fenster zur Schlitzposition"
},
"Nacht": {
    "description": "Nachts sind die Rollos unten"
},
"KippDaemmerung": {
    "description": "In der Daemmerung sind gekippte Fenster auf Schlitzposition"
},
"Daemmerung": {
    "description": "In der Daemmerung sind die Rollaeden unten "
},
"Fernsehen": {
    "description": "Beim Fensehmodus sind die Rollos auf Schlitzposition"
},
"Blendschutz": {
    "description": "Die Fenster, durch die die Sonne blenden kann (die sind entsprechend markiert), fahren zum Blendschutz auf eine in Settings einstellbare Position"
},
"SchattenWestHeiss": {
    "description": "Beschattung Westfassade, wenn es sehr heiss ist"
},
"SchattenWest": {
    "description": "Beschattung Westfassade, wenn es zu warm ist"
},
"SchattenSuedHeiss": {
    "description": "Beschattung Suedfassade, wenn es sehr heiss ist"
},
"SchattenSued": {
    "description": "Beschattung Suedfassade, wenn es zu warm ist"
},
"SchattenOst": {
    "description": "Beschattung Ostfassade, wenn es zu warm ist"
},
"SchattenNord": {
    "description": "Beschattung Nordfassade, wenn es zu warm ist"
},
"SchattenDachSued": {
    "description": "Beschattung Dach Suedseite, wenn es zu warm ist"
},
"SchattenDachNord": {
    "description": "Beschattung Dach Nordseite, wenn es zu warm ist"
},
"Tag": {
    "description": "Standardposition am Tag"
},
"Wach": {
    "description": "Rollo morgens hochfahren, wenn ein Raum betreten wird (Treppenhaus, Küche, Esszimmer, Wohnzimmer)"
},
"Morgen": {
    "description": "Standardposition am Morgen"
}

Das ist nur ein Extrakt der Kommentare, die ich zu jedem Zustand gemacht habe. Ferner Funktioniert die StateEngine so, dass ein Zustand weiter unten (z.B. Tag) nur betreten werden kann, wenn alle Bedingungen aller Zustände oben drüber nicht erfüllt worden sind.

Um es mit HA-Worten auszudrücken: Die State-Engine, die ich habe, triggert eine geordnete Liste von Automations nacheinander an, und sobald eine der Automations eine Action angestoßen hat (weil deren Condition zutrifft), wird die geordnete Liste wieder von vorne abgearbeitet. Getriggert wird somit nur die State-Engine, nicht jede einzelne Automation. Und so etwas gibt es in HA nicht nativ, deswegen ist es auch schwieriger, solche State-Engines abzubilden (mir ist das nur gelungen, indem ich 2 Automations pro Zustand erzeuge, bin mir aber nicht sicher, ob das universell genug ist).

Hoffe, das reicht als erste Info. Wenn Du noch Fragen hast, stell sie einfach, ich beantworte sie gerne, bin mir nur nicht sicher, ob das noch das Thema dieses Thread trifft...

Gruß, Waldemar

[mumpf]

Hi,

und noch eine Frage, zu der ich nirgendwo eine Doku gefunden habe: Gibt es für die KNX-Kommunikation in HA (also in xknx) etwas äquivalentes zu den FLAGS bei den KNX-KO? Als Beispiel:

Kann ich für ein

switch:
  - name: 'waschmaschine_steckdose'
    address: '30/3/0'
    state_address: '30/3/1'

irgendwie formulieren, dass die 30/3/0 nur zum KNX-Bus schreibt und die 30/3/1 nur auf Telegramme vom Bus hört? In der ETS wären das S- und L-Flag, aber wie geht das in xknx? Und wie sage ich, auf was die 30/3/1 hören soll? Auf GroupVaulueWrite oder auf GroupValueResponse oder auf beide? Derzeit hab ich den Eindruck, dass auf GroupValueResponse nicht gehört wird (außer xknx setzt selbst explizit ein GroupValueRead ab). Das muss ich aber noch verifizieren.

Ansonsten hab ich beim obigen Switch das Problem, dass dieser auf "off" geht (Ausgangssituation ist "on"), wenn die 30/3/0 über den Bus eine 0 bekommt. Das passiert auch, wenn der Aktor gesperrt ist, also gar nicht aus geht und somit gar keine Statusänderung auf der 30/3/1 erfolgt. In KNX würde ich beim Tasterausgang einfach das S-Flag entfernen und gut ist. Aber wie mach ich das hier?

Ich hoffe, das Problem ist gut genug beschrieben...

Gruß, Waldemar

P.S.: Sorry für die vielen Detailfragen, aber wie schon gesagt teste ich, ob HA für mich in Frage kommt und versuche, allgemeine Alltagsprobleme in Einzeltests mit HA zu lösen, bevor ich meine gesamte Visu und Logik darauf umsetze.

[meti]

so Kleinteilig ist die config nicht. Bis auf wenige Ausnahmen* läuft es so ab:
- alle "address" (also ohne "state") können Senden und Empfangen (Aktualisieren) - sowohl GroupValueWrite als auch GroupValueResponse. Es werden keine GroupValueRead auf diese Adressen gesendet.
- "state_address" werden nie Senden sondern nur Empfangen (Aktualisieren). Es werden GroupValueRead gesendet alle 60 Minuten seit letzten eingegangenem Telegram (gilt auch für die nicht-state-adresse der gleichen Funktion), oder je nach `sync_state` wenn konfigurierbar.
- expose antwortet auf GroupValueRead

Ich glaub dein Beispiel lässt sich dann nur mit einem binary_sensor umgehen. Gesperrte switches gibt es in HA nicht.

*: Bei sensor mit `always_callback = True` und binary_sensor mit `ignore_internal_state = True` werden GroupValueResponse nur als state change behandelt wenn sich die Payload tatsächlich verändert hat (beides gilt erst ab xknx 0.15.3 - also zur Zeit noch nicht).

[mumpf]

Hi Matthias,

danke für die detaillierte Antwort. Sehe ich das richtig, dass Du an xknx mitentwickelst? Danke dass Du Dir Zeit für meine Anfängerfragen nimmst.

Ich glaub dein Beispiel lässt sich dann nur mit einem binary_sensor umgehen.

Hmm, an sich will ich ja schon einen Switch haben, ich will den Aktor ja auch von HA aus bedienen können... oder meinst Du, dass ich eine "normale" HA-Switch-Entität nehme, die per expose auf die 30/3/0 senden lasse und nur ein Binalry-Sensor auf die 30/3/1 für den Status mache? Dann bräuchte ich auch eine automation, die Änderungen an der 30/3/1 (also an dem daraus abgeleiteten Binary-Sensor) noch an den "normalen" HA-Switch sentzt.

Erscheint mir aufwändig und ich hab dann immer noch das Problem, dass ich - wenn der Schalter in HA betätigt wird, der Aktor aber wegen der Sperre nicht schaltet - immer noch den falschen Status sehe.

Ich habe eben nochmal in der Doku geschaut und das hier gefunden:

You can also use the homeassistant.update_entity service call to issue GroupValueRead requests for all *state_address of a device.

Damit kann ich bei den Switches für die Aktoren, von den ich weiß, dass sie gesperrt werden können, auch nach einem State-change noch ein homeassistant.update_entitiy hinterherschicken, dann stellt sich der Switch wieder in den korrekten Zustand. Muss ich morgen gleich ausprobieren.

Danke und Gruß,
Waldemar

P.S.: Trotzden es sehr schade, dass man beim knx-switch (und potentiell auch bei anderen Geräten) nur zwischen address und state_address wählen kann, man könnte auch noch so was wie send_address und reply_address einführen und so Detailsteuerung erlauben...

[meti]

Hi! Ja, siehst du richtig.

Mit einem Template Switch kann man das machen. Da braucht's keine eigene automation.
https://www.home-assistant.io/integr...itch.template/
Die value_template setzt man dann auf den state des binary_sensor und als Service kann man knx.send benutzen, oder auch expose (was auch Respond senden würde).

Wenn du nicht willst das die "address" auch aktualisiert kannst du ja eine eigene GA anlegen und die zum Kommunikationsobjekt auf das geschrieben werden soll dazuverbinden.

[mumpf]

Hi,

danke, über den Template Switch bin ich bisher noch nicht gestolpert (obwohl ich bestimmt schon Tage mit der Doku verbracht habe). Der könnte wirklich zur Problemlösung beitragen. Ich werde mal ein paar Versuche starten.

Wenn du nicht willst das die "address" auch aktualisiert kannst du ja eine eigene GA anlegen und die zum Kommunikationsobjekt auf das geschrieben werden soll dazuverbinden.

Ist eine gute Idee, werde ich im Hinterkopf behalten. Aber derzeit bin ich nicht gewillt, auf KNX-Seite irgendwas zu korrigieren, das seinen Ursprung in potentiellen Unvollständigkeiten der Visu/Logikengine hat. Ich suche ja derzeit nicht eine Lösung für Einzelprobleme, ich versuche systematisch Sachen zu testen, die häufig bei mir im Haus vorkommen. Somit müsste ich im Finalausbau die "Sonderlocken" dann auch häufig (z.B. pro Raum einmal) realisieren, und dazu bin ich (noch) nicht bereit.

Danke erstmal, ich melde mich bestimmt wieder

Gruß, Waldemar

[mumpf]

Hi meti,

- "state_address" werden nie Senden sondern nur Empfangen (Aktualisieren). Es werden GroupValueRead gesendet alle 60 Minuten seit letzten eingegangenem Telegram (gilt auch für die nicht-state-adresse der gleichen Funktion),

habe ich Dich hier richtig verstanden? Bei einem

switch:
    - name: 'licht_treppenhaus'
      address: '31/0/0'
      state_address: '31/0/1'

wird, je nachdem was bei sync_state eingestellt ist (oder sonst alle 60 Minuten), auf beiden GA (also address und state_address) ein GroupValueRead gesendet? Und da hat sich noch keiner drüber beschwert? Das würde immerhin eine sporadische "Fehlanzeige" erklären, die ich noch weiter untersuchen wollte, aber bisher nicht wusste, wie ich das einkreisen soll. Welche Antwort auf die GroupValueRead gewinnt denn? Wahrscheinlich der letzte, der eintrifft, oder?

Folgendes Beispiel: Obiges Licht geht nach 3 Minuten aus (Treppenlichtfunktion). Damit liefert ein GroupValueRead auf address eine 1, auf state_address eine 0. Und je nachdem welche Antwort zuletzt eintrifft, nimmt die Entity den Wert 1 oder 0 an. Die 1 wahrscheinlich sehr selten...

Fakt ist, ich sehe immer wieder mal ein "on" auf dem zugehörigen Switch. Hab ich bisher nicht zuverlässig reproduzieren können, aber falls wirklich beide gelesen werden, würde es das erklären.

Habe ich Dich also richtig verstanden oder falsch? Wenn richtig, muss ich nicht weiter suchen...

Gruß, Waldemar

[meti]

Nein, so war das nicht gemeint. Das GroupValueRead wird immer nur auf die state_address gesendet. Der Timer wird zurückgesetzt wenn auf einer der beiden Adressen ein Telegram kommt.

Das würde immerhin eine sporadische "Fehlanzeige" erklären, die ich noch weiter untersuchen wollte,

Wenn du "Could not sync group address ..." und "Error: KNX bus did not respond in time (2 secs) to GroupValueRead request" meinst, da handelt es sich um einen Bug der (hoffentlich) bereits behoben, aber noch nicht in HA gemerged ist.

[mumpf]

Hi,

Das GroupValueRead wird immer nur auf die state_address gesendet.

ok, dann war es das nicht, dann muss ich mal feiner analysieren. Es hätte gepasst...

Wenn du "Could not sync group address ..." und "Error: KNX bus did not respond in time (2 secs) to GroupValueRead request" meinst, da handelt es sich um einen Bug der (hoffentlich) bereits behoben, aber noch nicht in HA gemerged ist.

Ich hab die Meldungen auch im Log gesehen... dazu hätte ich auch nachgefragt, gut zu wissen, dass es ein Bug ist. Ob meine sporadische "Fehlanzeige" darauf basiert, weiß ich noch nicht. Melde mich, wenn ich das weiter eingegrenzt habe.

Danke und Gruß, Waldemar

[mumpf]

Hi,

nochmal ne Frage an alle, die HA schon länger nutzen (in der Hoffnung, dass ich "nur" nicht die richtige Doku gefunden habe): Kann ich die configuration.yaml nicht freier aufteilen? Ich hab das hier gelesen https://www.home-assistant.io/docs/c...configuration/ und damit auch etwas rumgespielt. Aber es erlaubt im wesentlichen die "device type" basierte Grundstruktur der config auf verschiedene Files zu verteilen.

Hat man da nicht mehr Freiheitsgrade? Ich hab wirklich noch keine große config, so etwa 500 Zeilen configuration.yaml, 500 Zeilen knx.yaml und ca. 1200 Zeilen automation.yaml, aber ich komme jetzt schon massiv in die Probleme, dass ich immer suchen muss, wo was ist. Und es ist äußerst unübersichtlich, wenn man mal eine automation kopieren will, um sie für ein anderes Gerät verfügbar zu machen, da man sich die passenden Sensoren (also sensor.xxx, binary_sensor.xxx), Switches, passende knx-entities (auch hier sensor.xxx, binary_sensor.xxx, switch.xxx) an verschiedenen Stellen zusammensuchen muss.

Für knx kann ich das noch verstehen, da alles unter einem eigenen Root-Objekt steht (obwohl ich die frühere Notation mit "platform: knx" konsistenter fand), aber der Rest erscheint mir ziemlich wirr.

Mein Ordnungskriterium ist normalerweise eher der Raum, dann die Gewerke, dann weitere Ordnungskriterien und dann erst physikalische Geräte. Gibt es so was wie ein include (oder include_dir), dass aus einem File einfach alle "light" device types rausliest? Entsprechendes dann für switch, sensor, binary_sensor, automation, etc.?

So was würde doch eine freie Verzeichnisstruktur unter einem config-Verzeichnis erlauben und unabhängig von der Schachtelung der device types trotzdem das gewünschte Ergebnis liefern?

Falls es das nicht gibt, werde ich versuchen, mir einem kleinen "Preparser" zu schreiben, der das macht. Aber mich würde interessieren, ob ich der einzige bin, dem das komisch vorkommt, dass man zusammenhängende Sachen (z.B. Rolladenaktoren und -sensoren, Fensterkontakte und automations/scripts, die das steuern) nicht zusammen in ein File schreiben kann. Und natürlich, welche Lösungen ihr für das Problem habt, falls es welche gibt.

Gruß, Waldemar