Ford Prefect Posted April 27, 2023 Share Posted April 27, 2023 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). Quote Link to comment
mgutt Posted April 27, 2023 Author Share Posted April 27, 2023 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. Quote Link to comment
Ford Prefect Posted April 27, 2023 Share Posted April 27, 2023 (edited) 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 Quote Link to comment
mgutt Posted June 8, 2023 Author Share Posted June 8, 2023 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. Quote Link to comment
mgutt Posted June 10, 2023 Author Share Posted June 10, 2023 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: Quote Link to comment
Ford Prefect Posted June 10, 2023 Share Posted June 10, 2023 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. Quote Link to comment
mgutt Posted June 10, 2023 Author Share Posted June 10, 2023 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. Quote Link to comment
mgutt Posted June 11, 2023 Author Share Posted June 11, 2023 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. Quote Link to comment
mgutt Posted June 12, 2023 Author Share Posted June 12, 2023 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 😅 Quote Link to comment
hawihoney Posted June 13, 2023 Share Posted June 13, 2023 (edited) 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 Quote Link to comment
mgutt Posted June 20, 2023 Author Share Posted June 20, 2023 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. Quote Link to comment
Mati369 Posted July 14, 2023 Share Posted July 14, 2023 (edited) 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 Quote Link to comment
MPC561 Posted July 17, 2023 Share Posted July 17, 2023 (edited) 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 Quote Link to comment
mgutt Posted July 17, 2023 Author Share Posted July 17, 2023 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. 1 Quote Link to comment
MPC561 Posted July 17, 2023 Share Posted July 17, 2023 (edited) 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 Quote Link to comment
Chriz123 Posted July 29, 2023 Share Posted July 29, 2023 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 Quote Link to comment
alturismo Posted July 29, 2023 Share Posted July 29, 2023 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 Quote Link to comment
mgutt Posted July 29, 2023 Author Share Posted July 29, 2023 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. Quote Link to comment
FeelNiceInc Posted July 29, 2023 Share Posted July 29, 2023 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? Quote Link to comment
alturismo Posted July 30, 2023 Share Posted July 30, 2023 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 Quote Link to comment
Mati369 Posted July 31, 2023 Share Posted July 31, 2023 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. Quote Link to comment
mgutt Posted September 24, 2023 Author Share Posted September 24, 2023 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?! Quote Link to comment
matty2k Posted September 30, 2023 Share Posted September 30, 2023 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 Quote Link to comment
Alku1 Posted October 10, 2023 Share Posted October 10, 2023 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? Quote Link to comment
sonic6 Posted October 10, 2023 Share Posted October 10, 2023 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. 1 Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.