Wer nutzt denn eigentlich alles Home Assistant?

[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,

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

[Tontechniker]

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

[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]

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]

Hallo Hans,

läuft Dein KNX-TPUART mit knxd? Ich habe HA erfolgreich mit dem eibd (Vorläufer vom knxd) + USB-Schnittstelle und alternativ mit einer MDT-Schnittstelle getestet, läuft beides. Wenn Du also knxd auf Deinen Raspi bekommst, wird das wahrscheinlich klappen. Dem kann man auf jeden fall die Schnittstelle mitgeben, über die er kommunizieren soll. Und der knxd kann seinerseits von IP nach KNX tunneln.

Gruß, Waldemar

[meti]

Die knx Integration von HA spricht ausschließlich KNX-IP (tunneling und routing), kein TP. Vielleicht kann man das irgendwie mit knxd machen, sowas hab ich nie probiert.

[Tontechniker]

Kann mir hier jemand hefen?
Ich habe den KNX-daemon von Franz Koch versucht für meine KNX TPUART-Anwendung einzusetzen. Leider arbeitet er mit der Schnittstelle ttyACM0 (externer TPUART über USB). Ich habe auf meinem Raspi aber eine interne TPUART, die über ttyAMA0 angesprochen wird. Was muß ich ändern, damit ich von Home Assistent auf KNX zugreifen kann?
Gruß
Hans

[meti]

Welche from: Klausel?

Du kannst in einem Automation trigger nicht nur "to: "on", sondern auch "from: off" angeben, dann sind zB calls von periodisch sendenden GAs gefiltert.

Macht es irgendwie Sinn, auf xknx zu gehen? Kann man da mehr ausdrücken?

Nur wenn du beim Beta-testen helfen willst. Nein.

Ich habe es nicht geschafft, bei knx entities friendly_name: bzw. icon: zu spezifizieren.

Das geht von über customize, nicht über den knx key. https://www.home-assistant.io/docs/c...izing-devices/
Es gibt aber ne Diskussion düber hier: https://github.com/XKNX/xknx/issues/296

[mumpf]

Hi,

Das kann man zwar durch eine from: Klausel verhindern, aber wer macht das schon

das habe ich ehrlich gesagt nicht verstanden. Welche from: Klausel? Und wo wird die angegeben? Ich verwende übrigens nur das eingebaute (x)knx. Macht es irgendwie Sinn, auf xknx zu gehen? Kann man da mehr ausdrücken?

In dem Zusammenhang noch ne noob-Frage: Ich habe es nicht geschafft, bei knx entities friendly_name: bzw. icon: zu spezifizieren. Geht das nicht, gibt es einen Trick oder mach ich was falsch? Wenn man name: lesbar macht, wird der name der entity verunglimpft. Und für icon: muss man immer im UI was spezifizieren, das ist blöd, vor allem, weil auf Hilfsdialogen dann trotzdem die von der Integration vorgegebenen icons drauf sind.

Gruß, Waldemar

[meti]

Ja das mein ich. Dabei wird aber absichtlich nicht bei GroupValueRead requests getriggert (es sei denn der State hat sich geändert) weil sonst der StateUpdater automations auslösen könnte. (stand xknx 0.15.3). Das kann man zwar durch eine from: Klausel verhindern, aber wer macht das schon 🤣

selbes gilt für always_callback bei Sensoren.

Edit: das gilt nicht im startup Fall weil da die values None waren (in xknx, nicht HA)

[mumpf]

Hi meti,

ich mache jetzt erstmal ein paar Tests, um das Verhalten genau zu verstehen.

Vielleicht wird nix getriggert (sofern nicht anders konfiguriert) wenn der Wert sich zum gespeicherten nicht geändert hat.

So wie ich das derzeit sehe/verstehe, werden beim Startup gar keine automations getriggert, egal was mit dem Wert passiert. Ich habe folgendes mal gemacht:

automation:
  # startup tests
  - alias: 'test_trigger_source'
    description: Triggerquelle
    trigger:
      - platform: state
        entity_id: 
          - light.licht_bett_rechts
        to: 'on'
    action:
      - service: notify.mobile_app_nokia_9
        data:
          title: Test
          message: "automation gestartet"
          data:
            timeout: 60

Wenn ich im Normalbetrieb "light.licht_bett_links" schalte (das Licht ist über KNX geschaltet), bekomme ich brav eine Notification aufs Handy, wenn das Licht eingeschaltet wird, egal ob über HA oder KNX - so soll das sein.
Nach einem Startup bekomme ich keine Notification, und zwar egal, ob sich der Wert von "light.licht_bett_links" geändert hat oder nicht. Ich hab auch explizit den Test gemacht, dass ich vor dem Startup das Licht ausschalte und dann während des Startup einschalte. Im Lovelace-UI bekomme ich dann:

• unten die Meldung, dass HA startet und somit nicht alle Elemente verfügbar sind
• meine light-entity ist im UI gelb mit dem gleichen Text
• dann wird das light-entity erzeugt, man sieht es im UI mit "off"
• dann kommt wohl der "GroupValueRead" zurück, die light-entity geht auf "on"
• kein notify aufs Handy

Jetzt muss ich es noch schaffen, über den homeassistant.start-Trigger vorher noch ein notify aufs Handy zu bekommen, dann hab ich auch ausgeschlossen, dass die notify-plattform noch nicht geladen war.

Wahrscheinlich ist es gar nicht dumm, beim startup keine automations zu starten, denn es können sehr viele werden und damit viele (auch unerwünschte) Aktionen ausgelöst werden. Aber ich will auch in Sync mit den KNX-KO sein, und da fällt mir immer wieder auf, dass das sporadisch nicht so ist.

Wenn man dann mit Zustandsautomaten arbeiten möchte, wird das Problem schlimmer, weil nach einem Restart potentiell ein Zustandsautomat in einem Zustand ist, der nicht mehr zu dem Zustand auf dem KNX-Bus passt und es womöglich keinen Weg mehr gibt, der aus diesem Zustand "rausführt". Da muss ich noch weiter forschen.

Vielleicht wird nix getriggert (sofern nicht anders konfiguriert)

Du schreibst "sofern nicht anders konfiguriert"... gibt es denn da Möglichkeiten, was zu konfigurieren? Ich hab nichts gefunden... oder meinst Du   ignore_internal_state ? Das ist bei mir auf true, damit immer ein Trigger gesendet wird.

Gruß, Waldemar

P.S.: Ich hab jetzt mal meinen Zustandsautomaten für den Geschirrspüler implementiert, der läuft auch, aber bleibt eben manchmal in einem Zustand hängen, wenn ich HA neu starte (was ich wegen meiner vielen Versuche durchaus häufiger mache). Insofern ist das noch nicht gut genug, um hier vorgestellt zu werden...

[meti]

Soweit ich weiß speichert HA die Zustände der Entities. Vielleicht wird nix getriggert (sofern nicht anders konfiguriert) wenn der Wert sich zum gespeicherten nicht geändert hat.

Hast du ein Beispiel für so ne Automation?

[moe01325]

Hi,

ich suche mich mal wieder zu Tode... vielleicht weiß jemand ein Stichwort. Ich hab das Problem, dass einige "Automations", die sonst korrekt laufen, bei einem Startup nicht getriggert werden. Ich kann mir das nur so erklären, dass die "Automations" erst nach KNX geladen werden, sonst müsste das doch klappen, wenn die Antworten auf die KNX-ReadRequests eintrudeln.

Ich wollte die entsprechenden "Automations" dann über

trigger:
- platform: homeassistant
event: start

loslaufen lassen, aber entweder mach ich da was falsch oder das event kommt auch bevor die knx-Sachen geladen sind. Jetzt suche ich nach einer Möglichkeit, beim Startup eine bestimmte Reihenfolge zu erreichen, also erst "Automations" laden, dann KNX, dann alles passend abzuarbeiten.

Hintergrund: Falls ich HA als meine neue Logik- und Visu-Engine einsetze, muss ich ein definiertes Startup-Verhalten sicherstellen können. Ich will nicht, dass durch einen Restart des Servers (sei es durch manuelle Auslösung oder irgend einen automatischen Restart) plötzlich mitten in der Nacht die Rolläden laufen, nur weil die Zeitinformation (mitten in der Nacht) erst verfügbar ist, nachdem die Rolladenlogik festgestellt hat, dass alle Rolläden hoch sollen).

Weiß jemand, wo ich da nachschauen muss bzw. was nachlesen kann?

Gruß, Waldemar

interessante frage, direkt beantworten kann ichs leider auch nicht.

entweder du versuchst mittels logfile analyse herauszufinden was zuerst fertig ist, oder du machst in die HA startup trigger automations noch einen zusätzlichen delay hinein? einfach um praktisch sicher zu stellend dass knx module etc schon geladen sind?

[mumpf]

Hi,

ich suche mich mal wieder zu Tode... vielleicht weiß jemand ein Stichwort. Ich hab das Problem, dass einige "Automations", die sonst korrekt laufen, bei einem Startup nicht getriggert werden. Ich kann mir das nur so erklären, dass die "Automations" erst nach KNX geladen werden, sonst müsste das doch klappen, wenn die Antworten auf die KNX-ReadRequests eintrudeln.

Ich wollte die entsprechenden "Automations" dann über

trigger:
  - platform: homeassistant
    event: start

loslaufen lassen, aber entweder mach ich da was falsch oder das event kommt auch bevor die knx-Sachen geladen sind. Jetzt suche ich nach einer Möglichkeit, beim Startup eine bestimmte Reihenfolge zu erreichen, also erst "Automations" laden, dann KNX, dann alles passend abzuarbeiten.

Hintergrund: Falls ich HA als meine neue Logik- und Visu-Engine einsetze, muss ich ein definiertes Startup-Verhalten sicherstellen können. Ich will nicht, dass durch einen Restart des Servers (sei es durch manuelle Auslösung oder irgend einen automatischen Restart) plötzlich mitten in der Nacht die Rolläden laufen, nur weil die Zeitinformation (mitten in der Nacht) erst verfügbar ist, nachdem die Rolladenlogik festgestellt hat, dass alle Rolläden hoch sollen).

Weiß jemand, wo ich da nachschauen muss bzw. was nachlesen kann?

Gruß, Waldemar