Smart Home mit Home Assistant

[Ford Prefect]

9 hours ago, mgutt said:

Kann man das irgendwie auf 100% Zuverlässigkeit bekommen? zB in dem der das Kommando 2x absetzt oder prüft, ob der finale Status wirklich erreicht wurde und falls nicht, dann noch mal das Kommando sendet?!

Die Frage wäre, welches Protokoll verwendet wird, um die Steckdose anzusteuern.

 

Bei MQTT kann man QoS Parameter setzen *und* als Pub/Sub-Protokoll kannst Du wirklich sicher sein, dass - selbst wenn die Steckdose selbst mal kurzzeitig nicht im (W)LAN ist - der letzte Wert/Befehl auch später noch von der Steckdose "abgeholt" werden kann (Retain-Flag bei Publish setzen).

Ausserdem kannst Du über das LWT (Last-Will-and-Testament) im MQTT-Broker sehen, ob die Steckdose gerade beim Broker online/connected ist...kannst also auch das überwachen.

 

Eine Websocket-API ist halt doof, und läuft bestenfalls in den Timeout, den man dann abfangen und mit ner "Retry-Schleife" heilen muss.

 

Next Best Thing, nach MQTT wäre Modbus (serielles Ende-zu-Ende-Protokoll, geht auch über TCP).

 

Ob HA das alles so transparent kann weiss ich allerdings nicht.

Kurz: mit MQTT bist Du auf der deutlich sichereren Seite, dass es einfach funktioniert.

Daher haben alle meine smarten Gismos Tasmota Firmware und alle Systeme, die ich steuern/integrieren will (Hausbatterie, PV, Wallbox) können MQTT (oder zumindest Modbus).

[mgutt]

2 hours ago, Ford Prefect said:

Die Frage wäre, welches Protokoll verwendet wird, um die Steckdose anzusteuern.

ZigBee. Mag ja sein, dass der Aktor wie bei UDP einfach nur "schluckt", aber HA könnte ja im Anschluss den Aktor fragen welchen Zustand er nun hat und dann eben das Kommando wiederholen. Wobei mir gerade einfällt, dass ich die Logs vom Stick vergessen habe zu prüfen. Also vielleicht hat ja der Stick selbst in dem Moment nichts vom HA angenommen. Wobei ja auch dann eine Wiederholung HA's Aufgabe wäre. 

[Ford Prefect]

4 minutes ago, mgutt said:

ZigBee

Zigbee ist L2, analog WLAN...ich meinte das Protokoll, dass zur Steuerung darüber liegt (Ende-zu-Ende auf Applikationslevel).

 

Edit: Ah, sorry...Zigbee ist wieder son Kuddelmuddel-Protokoll.

Für Tasmota gibt es da ein Gateway: https://tasmota.github.io/docs/Zigbee/

Damit könnte man denn wenigstens auf HA Seite was "vernünftiges" AKA mqtt nutzen.

Edited April 27, 2023 by Ford Prefect

[mgutt]

Mir ist im Energie-Tab aufgefallen, dass ich den Strombezug und auch die Einspeisung falsch berechne. Und zwar hatte ich vorgestern einen guten Sonnentag, so dass ich zwischen 12 und 13 Uhr eigentlich erwarten würde, dass der Bezug vom Stromzähler gleich 0 ist. Der Balken im Energie-Tab zeigt aber eher ein Verhältnis von 50/50:

 

Der Energie-Tab nutzt dazu diese benutzerdefinierte Entität, welche den Bezug aller drei Phasen addiert, welcher vom Shelly 3EM ermittelt wurde:

  - sensor:
    - name: Stromzähler Bezug
      unique_id: shelly3main_energy
      unit_of_measurement: 'kWh'
      state: '{{ states("sensor.shelly3main_channel_a_energy") |float(0) |round(2)
             + states("sensor.shelly3main_channel_b_energy") |float(0) |round(2) 
             + states("sensor.shelly3main_channel_c_energy") |float(0) |round(2) }}'
      device_class: energy
      state_class: total_increasing

 

Dabei handelt sich um diese drei Werte:

 

Und genau die sind "falsch". Denn der Shelly ermittelt zwar eigentlich korrekt, dass ich auf Phase A einspeise und parallel auf Phase B und C verbrauche:

 

Aber eigentlich stimmt das ja nicht, weil der Stromzähler in dem Fall intern den Verbrauch von Phase B und C vom Ertrag der Phase A abzieht, also unter dem Strich der Bezug aus dem Netz 0 Watt ist, während die Einspeisung zu dem Zeitpunkt 429,3 Watt entspricht (-646,5 + 43,3 + 173,9 Watt).

 

Dieses Problem wird im folgenden Thread besprochen:

https://www.shelly-support.eu/forum/thread/8977-shelly-3em-phasen-saldieren-in-home-assistant/?postID=215634#post215634

 

Da versuchte man bisher die Watt-Werte zu addieren und dann daraus kWh zu machen. Mein Ansatz (auch dort gepostet), nutzt dagegen die kWh-Werte des Shelly. Ich muss aber noch bis morgen warten, um zu sehen, ob es auch so funktioniert wie gedacht.

[mgutt]

Ich habe jetzt die Lösung, aber sie ist nicht persistent. Dh beim nächtlichen Backup / Neustart des HA wird der Wert zurückgesetzt:

https://www.shelly-support.eu/forum/thread/8977-shelly-3em-phasen-saldieren-in-home-assistant/?postID=215864#post215864

 

Kann man Werte evtl in eine Datei schreiben oder die Sensor-Werte irgendwie persistent machen? Wobei das ja eigentlich schon persistent ist, da die Werte ja auch nach einem Neustart dem Diagramm entnommen werden können, aber direkt nach einem Neustart scheint der erst mal immer mit "nicht verfügbar" zu starten 🤔

 

Aktuell habe ich es so dargestellt:

 

 

 

[Ford Prefect]

2 hours ago, mgutt said:

Kann man Werte evtl in eine Datei schreiben oder die Sensor-Werte irgendwie persistent machen? Wobei das ja eigentlich schon persistent ist, da die Werte ja auch nach einem Neustart dem Diagramm entnommen werden können, aber direkt nach einem Neustart scheint der erst mal immer mit "nicht verfügbar" zu starten 🤔

Verstehe nicht ganz, was Du damit meinst. Evtl. ist Dein "Problem", dass Du Daten-/Transaktionsbezogen denkst. Der Wert war ja schonmal da, warum nach dem Neustart nicht mehr? -> Weil das Sensordaten sind und ein Sensor ist Event-bezogen. Die Daten erscheinen also erst wieder im HA, wenn der Sensor neue Daten, bzw. die letzten wieder/nochmal einliefert (oder HA diese pollt/abholt)....bis dahin gibt es keinen Event, also per Definition keine Daten.

 

...ich persistiere alle Sensordaten in einer InfluxDB...alle meine Sensoren liefern über mqtt Events/Daten...telegraf holt die ab und pusht die in die InfluxDB...HA bedient sich auch bei mqtt.

Grafen usw habe ich dann über Grafana-Dashboards aus der InfluxDB.

Die Diagramme bei HA sind für mich nur Beiwerk....die Aktoren sind das, was mich in HA interessiert.

[mgutt]

Mittlerweile habe ich den Tipp bekommen das Utility Meter zu nehmen, was auch einen Neustart überlebt:

https://www.home-assistant.io/integrations/utility_meter/

 

Da spiele ich gerade mit rum.

 

3 hours ago, Ford Prefect said:

.ich persistiere alle Sensordaten in einer InfluxDB...alle meine Sensoren liefern über mqtt Events/Daten...telegraf holt die ab und pusht die in die InfluxDB...HA bedient sich auch bei mqtt.

Bisher komme ich gut ohne klar, da ich ja nur ZigBee und Shelly Produkte verwende. Also wenn es geht, versuche ich die Komplexität weiterhin gering zu halten.

[mgutt]

Das mit dem persistenten Wert konnte ich noch nicht lösen, aber dafür ein anderes Problem. Und zwar zählte HA ständig meinen berechneten Netzbezug hoch, obwohl die Sonne durchgehend schien. Das konnte ich erst lösen, als ich den Shelly 3EM zu ungeraden Minuten auslaß:

 

  - sensor:
    - name: Phasenbezug
      unique_id: phasenbezug
      unit_of_measurement: "kWh"
      state: >
        {% set keep_last_state = true %}
        {# update state only at odd minutes (1, 3, 5, etc) #}
        {% if now().strftime("%M") | int % 2 %}
            {# sensors must return a number (not "unknown" or "unavailable") #}
            {% if is_number(states("sensor.shelly3main_channel_a_energy")) and is_number(states("sensor.shelly3main_channel_b_energy")) and is_number(states("sensor.shelly3main_channel_c_energy")) %}
                {{ (states("sensor.shelly3main_channel_a_energy") | float
                 + states("sensor.shelly3main_channel_b_energy") | float 
                 + states("sensor.shelly3main_channel_c_energy") | float) | round(2) }}
                 {% set keep_last_state = false %}
            {% endif %}
        {% endif %}
        {% if keep_last_state %}{{ states("sensor.phasenbezug") }}{% endif %}
      device_class: energy
      state_class: total_increasing
  - sensor:
    - name: Phaseneinspeisung
      unique_id: phaseneinspeisung
      unit_of_measurement: "kWh"
      state: >
        {% set keep_last_state = true %}
        {# update state only at odd minutes (1, 3, 5, etc) #}
        {% if now().strftime("%M") | int % 2 %}
            {# sensors must return a number (not "unknown" or "unavailable") #}
            {% if is_number(states("sensor.shelly3main_channel_a_energy_returned")) and is_number(states("sensor.shelly3main_channel_b_energy_returned")) and is_number(states("sensor.shelly3main_channel_c_energy_returned")) %}
                {{ (states("sensor.shelly3main_channel_a_energy_returned") | float
                 + states("sensor.shelly3main_channel_b_energy_returned") | float 
                 + states("sensor.shelly3main_channel_c_energy_returned") | float) | round(2) }}
                {% set keep_last_state = false %}
            {% endif %}
        {% endif %}
        {% if keep_last_state %}{{ states("sensor.phaseneinspeisung") }}{% endif %}
      device_class: energy
      state_class: total_increasing

 

 

Während ich nur bei geraden Minuten den Netzbezug / die Netzeinspeisung berechnete:

 

  - sensor:
    - name: Netzbezug
      unique_id: netzbezug
      unit_of_measurement: "kWh"
      state: >
        {% set keep_last_state = true %}
        {# update state only at even minutes (2, 4, 6, etc) #}
        {% if not now().strftime("%M") | int % 2 %}
            {# sensors must return a number (not "unknown" or "unavailable") #}
            {% if is_number(states("sensor.phasenbezug")) and is_number(states("sensor.phaseneinspeisung")) %}
            {% if is_number(states("sensor.shelly3main_channel_a_energy")) and is_number(states("sensor.shelly3main_channel_b_energy")) and is_number(states("sensor.shelly3main_channel_c_energy")) %}
            {% if is_number(states("sensor.shelly3main_channel_a_energy_returned")) and is_number(states("sensor.shelly3main_channel_b_energy_returned")) and is_number(states("sensor.shelly3main_channel_c_energy_returned")) %}
                {# obtain balanced energy value of household #}
                {% set phases_current = (states("sensor.shelly3main_channel_a_energy") | float + states("sensor.shelly3main_channel_b_energy") | float + states("sensor.shelly3main_channel_c_energy") | float) | round(2) %}
                {% set phases_diff = (phases_current - states("sensor.phasenbezug") | float) | round(2) %}
                {% set phases_returned_current = (states("sensor.shelly3main_channel_a_energy_returned") | float + states("sensor.shelly3main_channel_b_energy_returned") | float + states("sensor.shelly3main_channel_c_energy_returned") | float) | round(2) %}
                {% set phases_returned_diff = (phases_returned_current - states("sensor.phaseneinspeisung") | float) | round(2) %}
                {% set phases_balance = (phases_diff - phases_returned_diff) | round(2) %}
                {# update this sensor only if balance is positive #}
                {% if phases_balance > 0 %}
                    {{ (states("sensor.netzbezug") | float(0) + phases_balance | abs) | round(2) }}
                    {% set keep_last_state = false %}
                {% endif %}
            {% endif %}
            {% endif %}
            {% endif %}
        {% endif %}
        {% if keep_last_state %}{{ states("sensor.netzbezug") | float(0) | round(2) }}{% endif %}
      device_class: energy
      state_class: total_increasing
  - sensor:
    - name: Netzeinspeisung
      unique_id: netzeinspeisung
      unit_of_measurement: 'kWh'
      state: >
        {% set keep_last_state = true %}
        {# update state only at even minutes (2, 4, 6, etc) #}
        {% if not now().strftime("%M") | int % 2 %}
            {# sensors must return a number (not "unknown" or "unavailable") #}
            {% if is_number(states("sensor.phasenbezug")) and is_number(states("sensor.phaseneinspeisung")) %}
            {% if is_number(states("sensor.shelly3main_channel_a_energy")) and is_number(states("sensor.shelly3main_channel_b_energy")) and is_number(states("sensor.shelly3main_channel_c_energy")) %}
            {% if is_number(states("sensor.shelly3main_channel_a_energy_returned")) and is_number(states("sensor.shelly3main_channel_b_energy_returned")) and is_number(states("sensor.shelly3main_channel_c_energy_returned")) %}
                {# obtain balanced energy value of household #}
                {% set phases_current = (states("sensor.shelly3main_channel_a_energy") | float + states("sensor.shelly3main_channel_b_energy") | float + states("sensor.shelly3main_channel_c_energy") | float) | round(2) %}
                {% set phases_diff = (phases_current - states("sensor.phasenbezug") | float) | round(2) %}
                {% set phases_returned_current = (states("sensor.shelly3main_channel_a_energy_returned") | float + states("sensor.shelly3main_channel_b_energy_returned") | float + states("sensor.shelly3main_channel_c_energy_returned") | float) | round(2) %}
                {% set phases_returned_diff = (phases_returned_current - states("sensor.phaseneinspeisung") | float) | round(2) %}
                {% set phases_balance = (phases_diff - phases_returned_diff) | round(2) %}
                {# update this sensor only if balance is negative #}
                {% if phases_balance < 0 %}
                    {{ (states("sensor.netzeinspeisung") | float(0) + phases_balance | abs) | round(2) }}
                    {% set keep_last_state = false %}
                {% endif %}
            {% endif %}
            {% endif %}
            {% endif %}
        {% endif %}
        {% if keep_last_state %}{{ states("sensor.netzeinspeisung") | float(0) | round(2) }}{% endif %}
      device_class: energy
      state_class: total_increasing

 

Ließ ich beides in der selben Minute laufen, aktualisierte er nur den Netzbezug und den hätte er wie gesagt gar nicht aktualisieren dürfen.

 

Ich vermute, dass HA alle Sensoren mit mehreren Python Threads parallel verarbeitet und da ich in meinen vorherigen Versuchen den Wert "Phaseneinspeisung" sowohl für die Berechnung brauchte, als auch aktualisiert habe, löste das vermutlich eine Race Condition aus.

 

Jedenfalls klappt es jetzt wie erwartet. "Strom gekauft" bleibt auf 0 und "verkauft" steigt fröhlich, da ich aktuell Überschuss produziere:

 

Das Energie-Dashboard aktualisiert sich in ca einer Stunde. Dann sollte auch da kaum oder gar kein Netzbezug mehr zu sehen sein. Ich poste dazu heute Abend einen Screenshot, dann sieht man auch wie es sich verhält, wenn die Sonne untergeht.

[mgutt]

On 6/8/2023 at 7:57 PM, mgutt said:

Vorher:

 

 

 

Nachher:

 

Wie man sieht funktioniert die neue Berechnung. Diesmal gab es zwischen 12 und 13 Uhr ausschließlich Einspeisung und keinen Bezug mehr.

 

Der hohe Bezug am Morgen (der einzelne große Balken, der nach oben zeigt) war auch wirklich so. Meine Frau hatte da Spülmaschine und Waschmaschine gleichzeitig angeworfen. Ich brauche wohl eine LED, die rot leuchtet, wenn die PV noch nicht genug Saft produziert 😅

 

 

[hawihoney]

7 hours ago, mgutt said:

Ich brauche wohl eine LED, die rot leuchtet, wenn die PV noch nicht genug Saft produziert 😅

 

^^ Das ist ganz wichtig. Und der Blick auf die Anzeigen bevor man "Großverbraucher" anschmeißt ist ebenfalls sehr wichtig. Aber das lebt man mit der Zeit. Daraus entwickelt sich auch eine Art "Ehrgeiz" das System so weit wie möglich zu nutzen. Wenn man dann noch den Effekt kommuniziert (Stromkauf in 05/2023 0,28 EUR bzw. 0,02 EUR aktuell in 06/2023) dann spielen alle mit.

 

Eine entsprechende Anzeige hatte ich mal, mittlerweile kennen wir alle in etwa den Grundverbrauch und den Verbrauch der Großgeräte auswendig.

 

Morgens, kurz vor 8, in Köln:

 

 

Edited June 13, 2023 by hawihoney

[mgutt]

Ich habe wieder etwas wichtiges über HA gelernt:

 

Erstelle niemals einen Custom-Sensor, der mehrere Entitäten enthält ohne zeitbasierten Trigger.

 

Warum? Weil ein Sensor, wenn man keinen zeitbasierten Trigger hinterlegt, sich immer dann aktualisiert, wenn die Entität sich aktualisiert:

https://www.home-assistant.io/integrations/template/#trigger-based-template-binary-sensors-buttons-numbers-selects-and-sensors

 

Addiert man wie im folgenden Beispiel drei Entitäten, um eine Summe in einem neuen Sensor zu erhalten, wird dieser also nicht nur 1x alle 60 Sekunden aktualisiert, sondern jedes mal, wenn eine der drei Entitäten aktualisiert wird:

  - sensor:
    - name: Wärmepumpe Verbrauch
      unique_id: shelly3wp_power
      unit_of_measurement: 'W'
      state: '{{ (states("sensor.shelly3wp_channel_a_power") | float(0)
             + states("sensor.shelly3wp_channel_b_power") | float(0)
             + states("sensor.shelly3wp_channel_c_power") | float(0)) | round(2) }}'
      device_class: power
      state_class: measurement

 

Was ist nun das Problem daran? Ein Auszug aus meiner HA-Datenbank zeigt es:

 

Während ich also zuvor den Verbrauch der Wärmepumpe durch Addition aller drei Phasen mehrmals pro Minute erfasst hatte, passiert das nun durch den Time Trigger nur noch 1x pro Minute. Was das an Datenbank-Platz spart, muss ich denke ich nicht erklären.

 

Dieser Custom-Sensor sieht nun jedenfalls so aus:

  - trigger:
      - platform: time_pattern
        minutes: "/1"
    sensor:
    - name: Wärmepumpe Verbrauch
      unique_id: shelly3wp_power
      unit_of_measurement: 'W'
      state: '{{ (states("sensor.shelly3wp_channel_a_power") | float(0)
             + states("sensor.shelly3wp_channel_b_power") | float(0)
             + states("sensor.shelly3wp_channel_c_power") | float(0)) | round(2) }}'
      device_class: power
      state_class: measurement

 

 

HA ist immer für eine Überraschung gut.

[Mati369]

Moin,

hat jemand von euch schon den SkyConnect in einem HA Docker zum laufen bekommen? Bei mir scheitert es schon daran das ich ihn unter unraid nicht mal finde mit (fehlende Treiber?)
 

ls -l /dev/serial/by-id
/bin/ls: cannot access '/dev/serial/by-id': No such file or directory

 

oder unter

 

lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 0781:5571 SanDisk Corp. Cruzer Fit
Bus 001 Device 005: ID 046b:ff10 American Megatrends, Inc. Virtual Keyboard and Mouse
Bus 001 Device 004: ID 046b:ffb0 American Megatrends, Inc. Virtual Ethernet
Bus 001 Device 007: ID 046b:ff31 American Megatrends, Inc. Virtual HardDisk Device
Bus 001 Device 006: ID 046b:ff20 American Megatrends, Inc. Virtual Cdrom Device
Bus 001 Device 003: ID 046b:ff01 American Megatrends, Inc. Virtual Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

 

und mit 
 

ls /dev/tty*
/dev/tty    /dev/tty13  /dev/tty19  /dev/tty24  /dev/tty3   /dev/tty35  /dev/tty40  /dev/tty46  /dev/tty51  /dev/tty57  /dev/tty62
/dev/tty0   /dev/tty14  /dev/tty2   /dev/tty25  /dev/tty30  /dev/tty36  /dev/tty41  /dev/tty47  /dev/tty52  /dev/tty58  /dev/tty63
/dev/tty1   /dev/tty15  /dev/tty20  /dev/tty26  /dev/tty31  /dev/tty37  /dev/tty42  /dev/tty48  /dev/tty53  /dev/tty59  /dev/tty7
/dev/tty10  /dev/tty16  /dev/tty21  /dev/tty27  /dev/tty32  /dev/tty38  /dev/tty43  /dev/tty49  /dev/tty54  /dev/tty6   /dev/tty8
/dev/tty11  /dev/tty17  /dev/tty22  /dev/tty28  /dev/tty33  /dev/tty39  /dev/tty44  /dev/tty5   /dev/tty55  /dev/tty60  /dev/tty9
/dev/tty12  /dev/tty18  /dev/tty23  /dev/tty29  /dev/tty34  /dev/tty4   /dev/tty45  /dev/tty50  /dev/tty56  /dev/tty61  /dev/ttyS0

 

finde ich auch kein ttyUSB0

Habt ihr noch andere Ideen?

Wegen der möglichen fehlenden Treibern habe ich hier auch schon angefragt.

Edited July 14, 2023 by Mati369

[MPC561]

Ich habe das ganze gerade jetzt erst gelesen. Speziell das @mgutt meint die Anzeige aus dem Energie Panel wäre falsch weil genügend Eigenproduktion da war und trotzdem Netzbezug angezeigt wird.

 

Ich verstehe jetzt nicht was daran falsch sein soll. Die dort angezeigten Werte sind aufintegrierte Werte über die Zeitdauer einer Stunde. Nur weil 3,3kWh produzierte Energie angezeigt werden heisst das nicht das die Sonne die ganze Zeit geschienen hat. Bricht nur 10 Minuten der Solarertrag zusammen während Du Eigenverbrauch hast der einfach kurzzeitig höher als dein Solaretrag ist, dann wird das genau so angezeigt weil du genau dann Netzbezug hattest. 

 

Hatte das selber auch schon und viel Tasmota Dosen die ich mitlaufen lasse und auch zu dem Zeitpunkt die Werte vom Wechselrichter (Ist nur ein BKW), vom Stromzähler etc.:

 

 

 

 

Gruss,

Joerg

 

 

PS: Ich hab gerade Ärger mit meinen selbstgebauten Temperatursensoren auf Basis eines ESP8266 mit DHT22 Sensor und Tasmota, die via MQTT mit HA kommunizieren. Nachts um 4 läuft mein App Backup und dann wird der MQTT Container und der HA Docker Container gestoppt. Danach werden keine Werte mehr an HA kommuniziert von den Sensoren die grade im DeepSleep waren, obwohl der Sensor nach dem Wakeup weiter Werte an MQTT sendet. Nur ein Neustart des Sensors löst das Problem. Das Problem hab ich auch wenn ich Docker Updates hab. Ich werd noch irre deswegen...

 

Edited July 17, 2023 by MPC561

[mgutt]

3 hours ago, MPC561 said:

Hatte das selber auch schon und viel Tasmota Dosen die ich mitlaufen lasse und auch zu dem Zeitpunkt die Werte vom Wechselrichter (Ist nur ein BKW), vom Stromzähler etc.:

 

Vorher hatte ich trotz hoher Produktion, angeblich immer auch einen Bezug aus dem Netz:

 

Und mit immer, meine ich auch immer. Selbst wenn keine Wolke zu sehen war.

 

Das ist jetzt nicht mehr so:

 

 

Ursache ist, dass der Shelly 3EM keine Saldierung vornimmt. Er zählt für jede Phase einzeln den Ertrag und Bezug. Hat man nun wie ich auf einer Phase die PV-Anlage, dann ermittelt der Shelly auf den anderen beiden Phasen einen Bezug, obwohl die erste Phase bei Sonnenschein den Gesamtbezug aller Phasen abdeckt. Der Stromzähler saldiert das korrekt, nur der Shelly eben nicht, wodurch es zu Darstellungsfehlern kam. Diesen Fehler habe ich aber wie man sieht gelöst.

 

 

[MPC561]

Ok, das hatte ich in der Hitze des Gefechtes überlesen. Ich nutze einen IR Lesekopf am Zähler der via einem seriell angeschlossenen ESP8266 Microcontroler/Wifimodul mit Tasmota die vom Zähler direkt gemessenen Werte HA zur Verfügung stellt. Und ich bekommen dadurch schon den Gesamtverbrauch aller Phasen (den ich auch nutze) und nicht die Werte der einzelnen Phasen.

 

 

Gruss,

Joerg 

Edited July 17, 2023 by MPC561

[Chriz123]

On 7/14/2023 at 4:32 PM, Mati369 said:

Moin,

hat jemand von euch schon den SkyConnect in einem HA Docker zum laufen bekommen? Bei mir scheitert es schon daran das ich ihn unter unraid nicht mal finde mit (fehlende Treiber?)
 

ls -l /dev/serial/by-id
/bin/ls: cannot access '/dev/serial/by-id': No such file or directory

 

oder unter

 

lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 0781:5571 SanDisk Corp. Cruzer Fit
Bus 001 Device 005: ID 046b:ff10 American Megatrends, Inc. Virtual Keyboard and Mouse
Bus 001 Device 004: ID 046b:ffb0 American Megatrends, Inc. Virtual Ethernet
Bus 001 Device 007: ID 046b:ff31 American Megatrends, Inc. Virtual HardDisk Device
Bus 001 Device 006: ID 046b:ff20 American Megatrends, Inc. Virtual Cdrom Device
Bus 001 Device 003: ID 046b:ff01 American Megatrends, Inc. Virtual Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

 

und mit 
 

ls /dev/tty*
/dev/tty    /dev/tty13  /dev/tty19  /dev/tty24  /dev/tty3   /dev/tty35  /dev/tty40  /dev/tty46  /dev/tty51  /dev/tty57  /dev/tty62
/dev/tty0   /dev/tty14  /dev/tty2   /dev/tty25  /dev/tty30  /dev/tty36  /dev/tty41  /dev/tty47  /dev/tty52  /dev/tty58  /dev/tty63
/dev/tty1   /dev/tty15  /dev/tty20  /dev/tty26  /dev/tty31  /dev/tty37  /dev/tty42  /dev/tty48  /dev/tty53  /dev/tty59  /dev/tty7
/dev/tty10  /dev/tty16  /dev/tty21  /dev/tty27  /dev/tty32  /dev/tty38  /dev/tty43  /dev/tty49  /dev/tty54  /dev/tty6   /dev/tty8
/dev/tty11  /dev/tty17  /dev/tty22  /dev/tty28  /dev/tty33  /dev/tty39  /dev/tty44  /dev/tty5   /dev/tty55  /dev/tty60  /dev/tty9
/dev/tty12  /dev/tty18  /dev/tty23  /dev/tty29  /dev/tty34  /dev/tty4   /dev/tty45  /dev/tty50  /dev/tty56  /dev/tty61  /dev/ttyS0

 

finde ich auch kein ttyUSB0

Habt ihr noch andere Ideen?

Wegen der möglichen fehlenden Treibern habe ich hier auch schon angefragt.

 

Hallo,

 

bin ein UNRAID Neuling, daher bitte nicht böse sein falls die Frage dumm erscheint.

 

Warum als Docker und nicht als VM?

 

Aktuell ist HA noch auf dem Raspbrry am laufen, da mein Unraid sich nach und nach noch aufbaut (Daten umziehen, nginx unc co einrichten etc pp fehlt noch alles) Da ich vom pI komme und dort die HAOS laufen hab, hab ich mich für die VM entschieden, und werde dort mein HA wieder neu einrichten.

 

Als ich dein Problem gelesen hab, hab ich mein SkyConnect mal kurz an Unraid gehängt. Unter den USB Einstellungen (USB Manager Plugin) wird er erkannt, also in der Unraid übersichtsseite wird er als SkyConnect_v1.0 erkannt, in den USB Einstellungen selber wird er als Silicon Labs:CP210x UART Bridge ausgewiesen.

Konnte Ihn Problemlos meiner VM zur Verfüfung stellen

[alturismo]

23 minutes ago, Chriz123 said:

Warum als Docker und nicht als VM?

 

 

23 minutes ago, Chriz123 said:

Konnte Ihn Problemlos meiner VM zur Verfüfung stellen

 

dann nimm die VM und gut ist  es spricht nichts dagegen außer ein wenig mehr overhead da eine VM etwas mehr Ressourcen nimmt als ein Docker, Benefit, hast dafür den komplett vollen Umfang sofern benötigt ...

 

Das wurde in diesem Thread auch mehrfach behandelt, einfach durchlesen falls von Interesse

[mgutt]

9 hours ago, Chriz123 said:

Warum als Docker und nicht als VM?

Bei mir würde eine VM 24/7 ungefähr 10W mehr Stromverbrauch ausmachen. Außerdem ist es viel einfacher Backups zu machen oder Config Files zu bearbeiten. Eben weil die Dateien direkt über unRAID bearbeitet werden können. Auch Updates hat man direkt im Blick bei der Docker Übersicht. Also eigentlich viele gute Argumente gegen die VM. Aber der Container kann nicht alles was die VM kann. Da muss man abwägen.

[FeelNiceInc]

11 hours ago, Chriz123 said:

Warum als Docker und nicht als VM?

Vor der Frage stehe ich auch grade. Aktuell läuft mein HA noch auf einen Raspberry. Da ich mir grade einen kleines Unraid-System zusammenstelle bzw. rumprobiere, steht hier auch der Umzug irgendwann ins Haus.

 

Mich würde die Meinung von anderen Foren-Mitgliedern intressieren. Wie macht ihr es?

Und welche Vor- und Nachteile gibt es bei Docker bzw. VM?

[alturismo]

8 hours ago, FeelNiceInc said:

Und welche Vor- und Nachteile gibt es bei Docker bzw. VM?

das steht schon ziemlich genau hier beschrieben ... 

 

hier "nochmals" die offizielle Übersicht, wobei addons ein weitläufiger Begriff ist, HACS läuft beispielsweise auch im Docker ...
es gibt jedoch das ein oder andere addon wozu es die VM benötigt.

 

https://www.home-assistant.io/installation/#compare-installation-methods

 

ansonsten, genau 1 Post über deinem, der Overhead einer VM zu Docker ... deine Entscheidung

[Mati369]

On 7/29/2023 at 10:42 AM, Chriz123 said:

 

Hallo,

 

bin ein UNRAID Neuling, daher bitte nicht böse sein falls die Frage dumm erscheint.

 

Warum als Docker und nicht als VM?

 

Aktuell ist HA noch auf dem Raspbrry am laufen, da mein Unraid sich nach und nach noch aufbaut (Daten umziehen, nginx unc co einrichten etc pp fehlt noch alles) Da ich vom pI komme und dort die HAOS laufen hab, hab ich mich für die VM entschieden, und werde dort mein HA wieder neu einrichten.

 

Als ich dein Problem gelesen hab, hab ich mein SkyConnect mal kurz an Unraid gehängt. Unter den USB Einstellungen (USB Manager Plugin) wird er erkannt, also in der Unraid übersichtsseite wird er als SkyConnect_v1.0 erkannt, in den USB Einstellungen selber wird er als Silicon Labs:CP210x UART Bridge ausgewiesen.

Konnte Ihn Problemlos meiner VM zur Verfüfung stellen

Danke für deinen Input hier. Ich habe zwischenzeitlich rausgefunden, dass meine Einstellungen in den IOMMU Groups das Problem waren. Nun taucht auch der SkyConnect wie bei dir korrekt auf.

[mgutt]

Ich habe eben in den Logs diverse Fehlermeldungen vorgefunden. Hier ein Beispiel:

 

2023-09-24 22:06:39.214 WARNING (MainThread) [homeassistant.components.zha.core.cluster_handlers] [0x709E:1:0x0002]: async_initialize: all attempts have failed: [DeliveryError('Failed to deliver message: <EmberStatus.DELIVERY_FAILED: 102>'), DeliveryError('Failed to deliver message: <EmberStatus.DELIVERY_FAILED: 102>'), DeliveryError('Failed to deliver message: <EmberStatus.DELIVERY_FAILED: 102>'), DeliveryError('Failed to deliver message: <EmberStatus.DELIVERY_FAILED: 102>')]

 

Wenn man googled, stößt man auf Themen rund um Zigbee Aktoren. Also habe ich versucht herauszufinden welcher Aktor das sein könnte. Ist natürlich super, dass da nur "0x709E" steht. 😒

 

Ich habe dann aber herausgefunden, dass man ein Zigbee Gerät anklicken und dann auf "Netzwerk anzeigen" gehen muss:

 

Und dann kann man oben links in der Suche die Zeichenfolge eingeben und der entsprechende Aktor wird hervorgehoben:

 

Aber was ist nun das ":1:0x0002" ?

 

Ist da mit die "DeviceTemperature" gemeint?

 

Und wenn ja, was soll mir das nun sagen. Kann HA den Wert nicht auslesen oder was ist das Problem? 

 

Wirklich Sinn macht das jedenfalls nicht, da genau dieser Wert nicht verfügbar ist:

 

Oder ist das schon das Problem? Ich habe den Wert aus Spaß mal aktiviert und er wird scheinbar auch ausgelesen:

 

Ich habe daher das Gefühl, dass ich an der falschen Stelle schaue?!

 

 

 

 

[matty2k]

Guten Tag zusammen,

habe seit wenigen Tagen das Problem, dass der Zwave USB STICK nicht mehr zur HA VM durchgereicht und auch nicht in HA unter Hardware ausgewählt werden kann.

In Z-Wave JS unter HA kann der USB Stick ebenfalls nicht ausgewählt werden, es wird die Fehlermeldung angezeigt:

 

„Control Panel Driver: Failed to open the serial port: Error: No such file or directory, cannot open /dev/ttyACM0 (ZW0100)“

 

Habe auch schon den Lösungsansatz aus dem folgenden Post erfolglos versucht:

Hat noch jemand eine Idee?

Grüße

[Alku1]

Hey,

 

Ich haenge mich mal mit meinem Problem dran.

Beim Aufsetzten meiner smarten Thermostate "_TZE200_6rdj8dzm" komme ich einfach nicht weiter. Das pairing hat funktioniert, allerdings sehe ich keine Sensoren/Aktoren der Thermostate. Nach online Recherche habe ich festgestellt, dass ich dafuer wahrscheinlich einen custom quirk hinzufuegen muss. Das Verzeichnis "custom_zha_quirks" habe ich in einem neuen Unterverzeichnis "config" im HA docker erstellt. Hier meine configuration.yaml

# Loads default set of integrations. Do not remove.
default_config:

# Load frontend themes from the themes folder
frontend:
  themes: !include_dir_merge_named themes

automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml
zha:
  custom_quirks_path: /config/custom_zha_quirks/

 

Allerdings erhalte ich beim starten von HA den folgenden Fehler:
 

Quote

Invalid config for [zha]: not a directory for dictionary value @ data['zha']['custom_quirks_path']. Got '/config/custom_zha_quirks/'. (See /config/configuration.yaml, line 12).

 

 

Aus irgendeinem Grund kommt HA mit dem directory nicht klar, aber ich weiss nicht wieso
Habt ihr einen Tipp?

[sonic6]

3 hours ago, Alku1 said:

Das Verzeichnis "custom_zha_quirks" habe ich in einem neuen Unterverzeichnis "config" im HA docker erstellt.

das Verzeichnis "config" besteht schon:

Sprich dein Verzeichniss /homeassistant/ in /mnt/user/appdata  entspricht im Container dem Verzeichnis /config/ .

 

Du musst nur folgendes Verzeichnis erstellen:

/mnt/user/appdata/homeassistant/custom_zha_quirks/

und schon gehts.