Wer nutzt denn eigentlich alles Home Assistant?

[henfri]

Hallo,

ohne die leeren GAs funktioniert es jetzt.
Allerdings stimmt etwas mit dem State nicht. Z.B. Sollte der Wert Heizen&Komfort/Anwesend sein (Hex 21). Angezeigt im Dashboard wird aber Heizen/Abwesend.

Mein MDT Heizungsaktor nutzt diese Definition:



image.png

Ist die nicht mit Home-Assistant kompatibel?


Gruß,
Hendrik

[tsb2001]

Kurze Rückmeldung: läuft seit heute Nachmittag einwandfrei.
Danke an die Unterstützer!

[meti]

Das liegt vermutlich daran, dass es versucht seinen eigenen Wert zu lesen (else-Block) - den es zu dem Zeitpunkt nicht gibt.
Manche Entities speichern ihren Wert und stellen ihn nach Neustart wieder her (RestoreEntity), andere lesen den Wert aus ihrer jeweiligen Quelle. Das hängt ganz von der Integration ab. State-based Template Entities gehören zur 2. Gruppe - Trigger-based Templates zur Ersten soweit ich weiß (hab selber noch nicht so viel mit Templates herumgespielt).

[tsb2001]

Das evaluierte Template bestimmt nur den neuen Wert, bricht aber nicht die aufrufende Funktion ab. Das Ergebnis deines leeren else Blocks ist wahrscheinlich ein leerer String "".

Das wird’s sein!
Das funktioniert jetzt einwandfrei; was ich jedoch nicht verstehe: wenn ich nach einer Änderung in der yaml den Homeassistant neu starte, kommt ein Wert „unknown“ heraus, bis der erste neue Wert (also nicht „0“) gelesen wird.

Wie kann ich dann den Wert über einen Neustart retten (auch wenn das im Energiedashboard vermutlich einfach ignoriert wird und daher irrelevant ist)?
Ich möchte das halt einfach wissen, damit ich die Zusammenhänge besser verstehen kann. Das macht dann am Ende das suchen eigener Lösungenwege für weitere Anwendungsfälle viel einfacher…

[meti]

Dann kommt das ELSE: da steht nichts hinter; was normalerweise bedeutet, dass auch kein Code ausgeführt wird.

Der trigger das ein neuer State geschrieben wird hat schon getriggert - durch einen state-change der überwachten Entity. Das evaluierte Template bestimmt nur den neuen Wert, bricht aber nicht die aufrufende Funktion ab. Das Ergebnis deines leeren else Blocks ist wahrscheinlich ein leerer String "".

[tsb2001]

{% else %}
{{ states('PV_GEN24_KWH_BAT_laden') }}
{% endif %}​

Toll, danke! Funktioniert!
Es kann so einfach sein!

Was ich trotzdem nicht verstehe: Die IF-Abfrage gibt bei mehr als 1 ein True und führt die Berechnung in den doppelt geschweiften Klammern mit dem Wert, dem Scalefaktor und der Teilung durch 1000aus.
Dann kommt das ELSE: da steht nichts hinter; was normalerweise bedeutet, dass auch kein Code ausgeführt wird.
Warum muss man dem explizit beibringen, dass er den Wert halten soll, in dem man den Wert erneut in doppelt geschweiften Klammern zuweist?

Kann mich da noch jemand erhellen???

[tsb2001]

Die Fronius API ist leider ziemlicher Mist. Was du versuchen könntest wäre ModbusTCP - vielleicht hast du da mehr Glück und der Wert bleibt da gleich. Schau vielleicht auch mal ob es ein Firmwareupdate gibt (auf solarweb).

Sorry, hatte ich vergessen; die API liefert die Werte gar nicht.
Ich frage alles über Modbus TCP ab. Und genau da entsteht das Problem.
Ich muss das eh mit dem ScaleFactor rechnen, da kann ich auch direkt die Kilowattstunden generieren…

Ich versuche es mal mit dem Tip von Danny…

Danke euch!

[meti]

Die Fronius API ist leider ziemlicher Mist. Was du versuchen könntest wäre ModbusTCP - vielleicht hast du da mehr Glück und der Wert bleibt da gleich. Schau vielleicht auch mal ob es ein Firmwareupdate gibt (auf solarweb).
Ansonsten entweder wie danny geschrieben hat (aber mit `sensor.` vor der entity_id 😉) den letzten Wert nehmen, oder "unavailable" / "unknown" benutzen - das Engergy Dashboard sollte den State dann ignorieren. Du müsstest übrigens nicht in kWh umrechnen - das Dashboard würde das schon machen solange die Einheit stimmt.

[danny]

Hallo,

vielleicht einfach nur:

      {% else %}
        {{ states('sensor.PV_GEN24_KWH_BAT_laden') }}
      {% endif %}​

dann nimmt er normal den letzten korrekten Wert.

Gruß
Danny

[tsb2001]

Auf die Eingangsfrage: ich! Und mit steigender Begeisterung.

Nun hab ich ein kleines Problem:
Ich habe einen Fronius GEN24-Wechselrichter, der in den DC-Strings Zähler hat.

In dem DC-Anschluss vom Akku gibt es 2 Zähler. Einer liefert die Wattstunden zur Ladung, der weitere zur Entladung. Die Werte sind naturgemäß genauer, als wenn ich die Leistung mit dem Riemann-Summenintegralsensor integriere; vor allem wenn Homeassistant nicht verfügbar ist.

Das eigentliche Problem: ich würde dir gerne zur Visualisierung des Akkus in dem Energiedashboard nutzen. Leider liefern die Zähler einen Wert „0“, wenn die Funktion nicht erfüllt wird.
Beispiel: Der Zähler für Entladen liefert einen plausiblen Wert, sagen wir mal 2589 Wh, wenn Energie aus dem Akku entnommen wird. Scheint die Sonne und der Akku wird geladen, wird dieser Wert auf „0“ gesetzt. Bewölkt es sich und der Akku wird wieder entladen, macht er mit dem Zählerstand 2589 weiter.

Ich brauche aber für das Energiedashboard einen hochzählenden Wert. Die „0“ kann ich nicht verwerten und muss die ausblenden. Da ich eh in Kilowattstunden umrechnen muss, erzeuge ich eine neue Variable, die den Wert durch 1000 teilt und nur aufgerufen wird, wenn der Zählerstand größer 1 ist.

Das sieht zunächst so aus:

      - name: "PV_GEN24_KWH_BAT_laden"
        unit_of_measurement: kWh
        device_class: energy
        state: >-
          {% set kwhlad = states('sensor.PV_GEN24_DCWH_BAT_laden_RAW') | int %}
          {% if kwhlad > 1 %}
            {{(states('sensor.PV_GEN24_DCWH_BAT_laden_RAW') | int * (10 **(states('sensor.PV_GEN24_DCWH_SF')) | int ) / 1000) }}
          {% else %}
          {% endif​ %}

Die Konvertierung des Werts funktioniert und in der Variable unter „name“ hab ich den korrekten Wert.
Jedoch bei dem „else“ tritt das Problem auf.
Ich möchte gerne, dass die Variable unter „name“ auf dem Wert stehenbleibt, wenn der Rohwert (der mit dem RAW) mit 0 geliefert wird.
Ich hatte die Hoffnung, dass mit dem „else“ einfach nichts passiert, jedoch wird der Wert der Variable unter „name“ vollständig geleert.

Wie kann ich dem else ein quasi „do nothing“ aufzwingen, wenn der Rohwert „0“ ist?

Danke für die Bemühungen!

[meti]

Du hast schon wieder leere Listen als Adressen konfiguriert. Das geht nicht -> die internen xknx-Device Instanzen funktionieren dann nicht.

 - name: eg.Schuppen.heizung
temperature_address: []​

Der Check dafür ist erst ab Mittwoch (2023.4) live. Dann wird das als invalide Konfig erkannt (und xknx würde es dann ignorieren).

Das mit dem Annehmen das die address schon die state address sein wird wär machbar... aber dann kommt der nächste der das genau nicht will / dessen Gerät das nicht unterstützt etc. Dafür müsste man dann erst wieder extra konfigurieren das kein Read gemacht werden soll.
So ist es ganz klar:
- es wird nie was anderes als ein Read an eine state_address geschickt
- es wird nie ein Read an eine non-state-address geschickt
Man kann die gleiche Adresse für state und address Konfigurieren wenn man nur eine GA benutzen möchte.
Einzige (mir bewusste) Ausnahme ist Climate.temperature_address - das müsste eigentlich temperature_state_address heißen 🫤

[henfri]

Hallo,

vielen Dank. Der 1.0.16 ist ein MDT Strommessaktor. Ich denke, das ist aber nicht relevant, denn auch andere PAs machen Probleme:

2023-04-02 22:20:58.454 ERROR (MainThread) [xknx.log] Unexpected error while processing incoming telegram <Telegram direction="Incoming" source_address="1.0.76" destination_address="6/7/40" payload="<GroupValueWrite value="<DPTArray value="[0x43,0xb7,0x0,0x0]" />" />" />
Traceback (most recent call last):
  File "/usr/local/lib/python3.10/site-packages/xknx/core/telegram_queue.py", line 129, in _telegram_consumer
    await self.process_telegram_incoming(telegram)
  File "/usr/local/lib/python3.10/site-packages/xknx/core/telegram_queue.py", line 214, in process_telegram_incoming
    await self.xknx.devices.process(telegram)
  File "/usr/local/lib/python3.10/site-packages/xknx/devices/devices.py", line 90, in process
    for device in self.devices_by_group_address(telegram.destination_address):
  File "/usr/local/lib/python3.10/site-packages/xknx/devices/devices.py", line 46, in devices_by_group_address
    if device.has_group_address(group_address):
  File "/usr/local/lib/python3.10/site-packages/xknx/devices/climate.py", line 150, in has_group_address
    if self.mode is not None and self.mode.has_group_address(group_address):
AttributeError: 'Climate' object has no attribute 'mode'
2023-04-02 22:20:58.506 ERROR (MainThread) [xknx.log] Unexpected error while processing incoming telegram <Telegram direction="Incoming" source_address="1.0.16" destination_address="6/0/11" payload="<GroupValueWrite value="<DPTArray value="[0x0,0x0]" />" />" />
Traceback (most recent call last):
  File "/usr/local/lib/python3.10/site-packages/xknx/core/telegram_queue.py", line 129, in _telegram_consumer
    await self.process_telegram_incoming(telegram)
  File "/usr/local/lib/python3.10/site-packages/xknx/core/telegram_queue.py", line 214, in process_telegram_incoming
    await self.xknx.devices.process(telegram)
  File "/usr/local/lib/python3.10/site-packages/xknx/devices/devices.py", line 90, in process
    for device in self.devices_by_group_address(telegram.destination_address):
  File "/usr/local/lib/python3.10/site-packages/xknx/devices/devices.py", line 46, in devices_by_group_address
    if device.has_group_address(group_address):
  File "/usr/local/lib/python3.10/site-packages/xknx/devices/climate.py", line 150, in has_group_address
    if self.mode is not None and self.mode.has_group_address(group_address):
AttributeError: 'Climate' object has no attribute 'mode'
​

Ich denke, es liegt daran, dass ein Climate object, keinen "mode" hat. Ich finde aber in den Items nicht den Grund, warum ein mode fehlen würde:

  climate:
  - name: og.Lina.heizung
    temperature_address:
    - 6/2/0
    setpoint_shift_address:
    - 3/2/7
    setpoint_shift_state_address:
    - 3/2/7
    target_temperature_state_address:
    - 3/2/6
    operation_mode_address:
    - 3/2/9
    operation_mode_state_address:
    - 3/2/9
  - name: og.Charlie.heizung
    temperature_address:
    - 6/2/15
    setpoint_shift_address:
    - 3/2/67
    setpoint_shift_state_address:
    - 3/2/67
    target_temperature_state_address:
    - 3/2/66
    operation_mode_address:
    - 3/2/69
    operation_mode_state_address:
    - 3/2/69
  - name: og.Elternbad.heizung
    temperature_address: []
    setpoint_shift_address:
    - 3/2/27
    setpoint_shift_state_address:
    - 3/2/27
    target_temperature_state_address:
    - 3/2/26
    operation_mode_address:
    - 3/2/29
    operation_mode_state_address:
    - 3/2/29
  - name: og.Schlafzimmer.heizung
    temperature_address: []
    setpoint_shift_address:
    - 3/2/47
    setpoint_shift_state_address:
    - 3/2/47
    target_temperature_state_address:
    - 3/2/46
    operation_mode_address:
    - 3/2/49
    operation_mode_state_address:
    - 3/2/49
  - name: og.Kinderbad.heizung
    temperature_address:
    - 6/2/20
    setpoint_shift_address:
    - 3/2/87
    setpoint_shift_state_address:
    - 3/2/87
    target_temperature_state_address:
    - 3/2/86
    operation_mode_address:
    - 3/2/89
    operation_mode_state_address:
    - 3/2/89
  - name: og.Flur.heizung
    temperature_address: []
    setpoint_shift_address:
    - 3/2/107
    setpoint_shift_state_address:
    - 3/2/107
    target_temperature_state_address:
    - 3/2/106
    operation_mode_address:
    - 3/2/109
    operation_mode_state_address:
    - 3/2/109
  - name: eg.Kueche.heizung
    temperature_address: []
    setpoint_shift_address:
    - 3/1/67
    setpoint_shift_state_address:
    - 3/1/67
    target_temperature_state_address:
    - 3/1/66
    operation_mode_address:
    - 3/1/69
    operation_mode_state_address:
    - 3/1/69
  - name: eg.Schuppen.heizung
    temperature_address: []
    setpoint_shift_address:
    - 3/1/7
    setpoint_shift_state_address:
    - 3/1/7
    target_temperature_state_address:
    - 3/1/6
    operation_mode_address:
    - 3/1/9
    operation_mode_state_address:
    - 3/1/9
  - name: eg.Flur.heizung
    temperature_address:
    - 6/1/5
    setpoint_shift_address:
    - 3/1/27
    setpoint_shift_state_address:
    - 3/1/27
    target_temperature_state_address:
    - 3/1/26
    operation_mode_address:
    - 3/1/29
    operation_mode_state_address:
    - 3/1/29
  - name: eg.Gaestebad.heizung
    temperature_address: []
    setpoint_shift_address:
    - 3/1/47
    setpoint_shift_state_address:
    - 3/1/47
    target_temperature_state_address:
    - 3/1/46
    operation_mode_address:
    - 3/1/49
    operation_mode_state_address:
    - 3/1/49
  - name: eg.Esszimmer_nicht_nutzen.heizung
    temperature_address:
    - 6/1/25
    setpoint_shift_address:
    - 3/1/87
    setpoint_shift_state_address:
    - 3/1/87
    target_temperature_state_address:
    - 3/1/86
    operation_mode_address:
    - 3/1/89
    operation_mode_state_address:
    - 3/1/89
  - name: eg.Wohnzimmer.heizung
    temperature_address: []
    setpoint_shift_address:
    - 3/1/107
    setpoint_shift_state_address:
    - 3/1/107
    target_temperature_state_address:
    - 3/1/106
    operation_mode_address:
    - 3/1/109
    operation_mode_state_address:
    - 3/1/109
  - name: eg.Arbeitszimmer.heizung
    temperature_address: []
    setpoint_shift_address:
    - 3/1/127
    setpoint_shift_state_address:
    - 3/1/127
    target_temperature_state_address:
    - 3/1/126
    operation_mode_address:
    - 3/1/129
    operation_mode_state_address:
    - 3/1/129
  - name: eg.Till.heizung
    temperature_address:
    - 6/1/35
    setpoint_shift_address:
    - 3/1/147
    setpoint_shift_state_address:
    - 3/1/147
    target_temperature_state_address:
    - 3/1/146
    operation_mode_address:
    - 3/1/149
    operation_mode_state_address:
    - 3/1/149

Was allerdings manchmal fehlt ist die Temperatur (wg. 1wire).

Noch eine Frage:
Wäre es nicht sinnvoll, dass man die "state_address" weglassen kann und dann für "setzen" und "status" die gleiche GA angenommen wird?
Das reicht in vielen Fällen ja aus (nicht nur bei Climate).

Gruß,
Hendrik

[meti]

"Unexpected error" klingt eher nicht so gut. Klick mal auf "Vollständiges Protokoll laden" - da sollte dann ein Stacktrace zu finden sein. Die sind alle von 1.0.16 - was ist das?

[henfri]

Hallo,

zu 1):
Da ist tatsächlich etwas im Log:

• Unexpected error while processing incoming telegram <Telegram direction="Incoming" source_address="1.0.16" destination_address="6/0/12" payload="<GroupValueWrite value="<DPTArray value="[0x0,0x1]" />" />" />
• Unexpected error while processing incoming telegram <Telegram direction="Incoming" source_address="1.0.16" destination_address="6/5/100" payload="<GroupValueWrite value="<DPTArray value="[0x0,0x1]" />" />" />
• Unexpected error while processing incoming telegram <Telegram direction="Incoming" source_address="1.0.16" destination_address="6/5/101" payload="<GroupValueWrite value="<DPTArray value="[0x0,0x29]" />" />" />
• Unexpected error while processing incoming telegram <Telegram direction="Incoming" source_address="1.0.16" destination_address="6/0/10" payload="<GroupValueWrite value="<DPTArray value="[0x0,0xa]" />" />" />
• Unexpected error while processing incoming telegram <Telegram direction="Incoming" source_address="1.0.16" destination_address="6/5/102" payload="<GroupValueWrite value="<DPTArray value="[0x0,0x1]" />" />" />

Allerdings nutze ich diese GAs in HA gar nicht.

Den Punkt (2) habe ich verstanden. Werde ich so machen.

Noch eine Frage:
Nutzt hier jemand 1Wire?
Wenn ich als Server den Host der VM eintrage, dann bekomme ich die Meldung "Connection Failed"

Telnet auf 4304 von einem anderen Client auf den Server funktioniert aber... Und die VM (HA) findet ja auch andere Geräte im Netzwerk (nicht zuletzt das IP-Interface)

Gruß,
Hendrik

[meti]

1) Diese Konfiguration sollte doch funktionieren, oder?

wenn sie nicht funktioniert würdest du den Grund in den Logs sehen https://my.home-assistant.io/redirect/logs/

wie ich dem climate-Gerät sage, dass es keine KNX-GA als Input bekommt, sondern eine andere Entity

das geht mit einer knx-climate-entity nicht. Um verschiedene Integrationen zu mixen gibt es normal die Template-Entities - aber soweit ich weiß gibt es genau Climate nicht als Template Entity.
Du könntest aber die 1-wire Werte auf eine GA (oder eine interne GA wenn du willst) schreiben mit `expose` und dann in der knx-climate-entity benutzen.