Wer nutzt denn eigentlich alles Home Assistant?

[henfri]

Danke!

[daengl]

Ich möchte auf einem MDT Smart Taster einen über HA erzeugten String mit Temperatur und Luftfeuchte anzeigen lassen. Klappt grundsätzlich auch, allerdings habe ich mit dem '°'-Zeichen ein Problem.

In der ETS habe ich dem Eingang für "Statustext 1" den Typ "16.001 Zeichen (ISO 8859-1)" zugewiesen. Die GA hat ebenfalls diesen Typ und wenn ich im Gruppenmonitor manuell einen String eingebe wird er auch korrekt dargestellt.

Im HA sind die configs jedoch mit UTF-8 codiert und wenn ich da im template das '°'-Zeichen eingebe kommt im Gruppenmonitor nur '?' (HEX 3F anstelle von B0) an. Ein manuelles Umcodieren auf ISO 8859-1 oder Windows-1252 mag HA nicht.

Hatte das Problem schon jemand bzw. wie macht ihr das?

expose.yaml
- type: string
  entity_id: sensor.first_floor_bedroom_climate_string
  address: "3/3/8"
templates.yaml
- sensor:
    - name: "Bedroom Temperature and Humidity"
      unique_id: sensor.first_floor_bedroom_climate_string
      state: "{{'{:.1f}'.format(float(states('sensor.first_floor_bedroom_switch_temperature')))}} °C | {{'{:.0f}'.format(float(states('sensor.first_floor_bedroom_switch_humidity')))}} %"​

[meti]

daengl benutze

type: latin_1

(DPT 16.001) statt "string" (der ist DPT 16.000)

[daengl]

Hallo meti,

Danke, das klingt gut

Nun noch meine zerschossene KNX-config reparieren, dann sollte das hoffentlich klappen...

[henfri]

Hallo,

zu climate habe ich zwei Fragen:
1) Diese Konfiguration sollte doch funktionieren, oder?

  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

Im Dashboard erscheint aber kein Climate Gerät...

2) Ich nutze in einigen Räumen 1wire Sensoren für den Ist-Wert.
Wie binde ich diese in das Climate-Gerät ein?

Mir geht es hierbei nicht um die Einbindung von 1Wire Sensoren an sich, sondern wie ich dem climate-Gerät sage, dass es keine KNX-GA als Input bekommt, sondern eine andere Entity...

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.

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

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

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]

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 🫤

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

[danny]

Hallo,

vielleicht einfach nur:

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

dann nimmt er normal den letzten korrekten Wert.

Gruß
Danny

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

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

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