Posts by qschneider

Quote from jotube

ich bin jetzt endlich mal dazu gekommen es auszuprobieren, doch leider bekomme ich es nicht zum laufen. Ich habe die thermostat entität ebenfalls climate.wohnung_raumklima gennant. Aber ich kann keine automation ausführen um die Temperatur zu ändern. Ich kann nur sehen wie die Temperatur ist, also einen Auslöser konfigurien. Hast du noch einen Tipp?

Falls du ansonsten alles übernommen hast, kann es vlt daran liegen, das du den code Teil nicht innerhalb eines template Blocks eingefügt hast?

Wie ich oben schrieb kommt entweder in der configuration.yaml ein

template: !include templates.yaml

und der codeblock oben in diese Datei oder du machst es so

template:
  - name:                "Wohnung Current TVR Temperature"
    unique_id:           "wohnung_current_tvr_temperature"
    unit_of_measurement: °C
    device_class:        temperature
    state_class:         measurement
    state:               "{{ state_attr('climate.wohnung_raumklima', 'current_temperature')  }}"

  - name:                "Wohnung TVR Temperature"
    unique_id:           "wohnung_tvr_temperature"
    unit_of_measurement: °C
    device_class:        temperature
    state_class:         measurement
    state:               "{{ state_attr('climate.wohnung_raumklima', 'temperature')  }}"

  - name:                "Wohnung Current TVR Humidity"
    unique_id:           "wohnung_current_tvr_humidity"
    unit_of_measurement: "%"
    device_class:        humidity
    state_class:         measurement
    state:               "{{ state_attr('climate.wohnung_raumklima', 'current_humidity')  }}"

nach einem Neustart solltest du in den Entwicklerwergzeugen die Entitäten sehen.

Das geht leider nur über Umwege, da die Integration so gebaut wurde, das diese Werte nicht als Entitäten sondern nur als State Attribute bereit gestellt werden.

Es geht jedoch über eigene Template Objekte, die in der configuration.yaml oder einer extra templates.yaml angelegt werden müssen.

  - name:                "Wohnung Current TVR Temperature"
    unique_id:           "wohnung_current_tvr_temperature"
    unit_of_measurement: °C
    device_class:        temperature
    state_class:         measurement
    state:               "{{ state_attr('climate.wohnung_raumklima', 'current_temperature')  }}"

  - name:                "Wohnung TVR Temperature"
    unique_id:           "wohnung_tvr_temperature"
    unit_of_measurement: °C
    device_class:        temperature
    state_class:         measurement
    state:               "{{ state_attr('climate.wohnung_raumklima', 'temperature')  }}"

  - name:                "Wohnung Current TVR Humidity"
    unique_id:           "wohnung_current_tvr_humidity"
    unit_of_measurement: "%"
    device_class:        humidity
    state_class:         measurement
    state:               "{{ state_attr('climate.wohnung_raumklima', 'current_humidity')  }}"

Die kommen sicherlich ja auch noch.

Du darfst nur keinen Anspruch an eine vollständige oder zeitnahe Umsetzung haben.

Mir tun die freiwilligen Programmierer leid, da sie nur das umsetzen können, was Livisi in ihrer API und der aiolivisi zur Verfügung stellt.

Dort und im HA-Know-how scheint mir auch die Limitierung zu liegen, sofern ich es richtig lese. Die PRs hat zumindest einer der Hauptentwickler von HA reviewed, was so kleinteilig bestimmt nicht seine Aufgabe ist.

Das gewünschte Änderung im Verhalten des VRCC oder genauer des HK-Thermostats bzw. einer Gruppe von HK-Thermostaten scheint im momentanen Zustand nicht umsetzbar zu sein, wenn ich mir https://github.com/home-assistant/core/issues/90630 und https://github.com/home-assistant/core/pull/90716 richtig interpretiere. Jedenfalls sind beide geschlossen worden.

Der Grund scheint daran zu liegen, das die benötigten Stati und Actions nicht vom Geräte bereitgestellt werden, ob dies jetzt aufgrund einer unvollständigen Implementierung von https://github.com/StefanIacobLivisi/aiolivisi (welches die Bibliothek für HA ist, die auf die livisi-api bzw die Zentrale via websockets zugreift) oder in einer Limitierung der API bzw. der HW liegt kann ich mangels Infos und direkter Kommunikation mit den Entwicklern nicht beurteilen.

Liegt eindeutig nicht an den Entwicklern, die das in ihrer Freizeit durchführen - meinen großen Dank an diese Personen, sondern imho in der halbherzigen Unterstützung durch Livisi. Ich verstehe dabei nicht warum man sich soviel negatives Feedback von Kunden einhandeln muss, ohne die wenigen Dinge die man anpacken kann, auch vernünftig umzusetzen, zu kommunizieren und zu begleiten.

Da das Ganze ja sowieso eher nur wenige hier zu betreffen scheint, würde ich ab jetzt nichts weiteres mehr erwarten. Bedeutet für mich persönlich, das wenn sich in den nächsten beiden Wochen nichts mehr tut, das Projekt für mich auf dem Stand eingefroren und gestorben ist.

Quote from metaiiica

Habt ihr das auch wenn:

Ein Schalter/Licht an ist und ihr macht bei HA einen Neustart und der Zustand (an) wird nicht mehr angezeigt?

Das kann ich so nicht bestätigen. Ich habe zwei Schalter (PSS und PSSO) angeschaltet und anschießend einen HA Neustart ausgeführt. Danach wurden beide Schalter immer noch als angeschaltet dargestellt.

Genauso meinte ich es auch.

BT kombiniert ja nur bestimmte Aktoren und Sensoren der bestehenden Geräte ohne aber alle Funktionen dieser zu kennen. Wenn dann noch der Zustand "off" bei Livisi (noch) nicht implementiert ist, bekommt BT ja nicht mit das ein externes Hochdrehen der Zieltemperatur an BT vorbei ein Umschalten von "OFF" auf "Heizen" bedeutet - das System läuft somit "auseinander".

Dies müsste sofern von BT gewünscht, programmatisch abgefangen werden.

Dies wird aber mMn nicht seitens BT passieren, wenn ich mir die Requests und die Kapazitäten des Projektes anschaue.

Bleibt also nur in der Livisi Welt zu bleiben, in HA Standards zu nutzen und hoffen das die nötigen Stati noch irgendwann kommen, oder die einzelnen Livisi Komponenten als "dumme" Aktoren/Sensoren in HA einzubinden und die Logik dorthin zu verlagern.

Letzteres ist mein Anspruch an die Livisi Geräte, sprich nutzen solange bis sie sich von selbst zerlegen.

In ein/zwei Jahren wird mit Matter/Thread ein neuer Standard soweit mit Geräten versorgt sein, um solche herstellereigenen Lösungen überflüssig zu machen. HA ist für mich dabei der Weg den ganzen Zoo zu vereinen oder OpenHAB, ioBroker wenn man möchte.

Ich habe keine Raumthermostate, die sind im Zusammenspiel mit BT auch nicht angedacht soweit ich weiss. BT versucht bei dir die Temperatur nach seinen Vorgaben einzustellen und kollidiert mit den Vorgaben des Raumthermostats. Wenn das aber dein Wunsch ist, so wirst du zumindest für diesen Raum auf den Standard zurückgreifen müssen.

In meinem Fall regele ich aber alles via HA, bzw versuche gar nicht einzugreifen und bin froh, wenn Fenster- und Aussensensoren das wenig nötige automatisch erledigen.

Du kannst ja aber mal bei BT ein Issue einstellen, so das sie sich mit den Livisi Thermostaten, als auch den Raumthermostaten beschäftigen. Für Tado gibt es in BT eine Lösung und die verwenden auch Raumthermostate.

Bin mal gespannt was dann für Anforderungen an Livisi daraus folgern und ob dies noch umgesetzt wird, scheinen dort ja zZ alle offline zu sein.

Quote from ThMF

War nicht die Rede davon, dass dann endlich auch das Better-Thermostat funktioniert?

Wie es sich gezeigt hat ist es nur für das Standard-Thermostat notwendig und damit dafür sinnvoll das es umgesetzt wird. BT berechnet es alles selbst, das livisi climate ist dann quasi nur Stellmotor und liefert die Referenztemperaturen damit BT weiss, wieviel nachgeregt werden muss.

Wenn du in den Entwicklerwerkzeugen die Attribute das BT und livisi climate Objekts vergleichst, so siehst du das die fehlenden Stati in BT vorhanden sind, obwohl sie im Original (noch) nicht implementiert sind.

Allerdings kann BT "OFF" so nur durch Einstellen der Minimaltemperatur erreichen, was in der Praxis aber sowieso passiert.

Bzgl. der Eberle Raumthermostates. Ich kenne das Gerät nicht aber das scheint eine Heizungssteuerung auf Basis eines festen Temperaturbezugspunktes zu sein, der bei dir dann eben im WZ installiert ist.

idR sind Heizung Aussentemperatur gesteuert, dh du hast einen Aussenfühler mit der Heizung verbunden. In der Heizungsteuerung definierst du dann deine Wunschtemperatur und Heizkurve (wobei vB 1,83 nur die Steigung angibt und somit nur ein Teil der für die Heizkurve benötigten Daten angibt). Der andere Wert ist zB die Parallelverschiebung deiner Heizkurve auf ein Niveau das es sowohl bei -10°C und +10°C passt.

Was du über eine Heizlastberechnung erreichst, ist festzustellen wieviel Heizleistung jeder Raum für die Wunschtemperatur benötigt ( zB Bad 24°C, WZ 21°C, SZ 18°C usw.) Im Anschluss daran weisst du ob deine HK ausreichend dimensioniert sind um diese Werte Raumweise zu erreichen. Wenn du dann dir durchrechnen lässt, welche Vorlauf/Rücklauftemperatur bei Auslegungstemperatur (variiert nach Wohnort) gefahren werden kann, ohne das deine HK die Werte nicht mehr schaffen, hast du deine Heizung gut eingestellt. Mit den voreinstellbaren HK-Ventilen regelst du dann deine HK alle auf ein Niveau, so das egal wie weit sie von der Heizung entfernt sind oder wie groß sie sind immer ein vergleichbarer Durchfluss gewährleistet ist.

Dann kannst du anhand der HK-Thermostate je nach Wunsch die Solltemperatur runterregeln, wobei es nicht ratsam ist einzelne Räume runterzuregeln, da innerhalb deiner Gebäudehülle ansonsten diese Räume durch angrenzende Räume versorgt werden. Ausserdem kenne ich niemanden, der konsequent immer die Zimmertüren zumacht.

Das war jetzt mal vereinfacht ausgedrückt, was dein Weg sein könnte, ein Energieberater wird dir dies besser und anschaulicher erklären. Kurz gesagt es ist ist nicht entscheidend, das du deine Vaillant fernsteuern kannst, sondern das du sie ivM deinen Heizkörpern korrekt einstellst.

Quote from ThMF

und da Livisi und HA scheinbar keine Bugs mehr beheben, müssen wir warten....

Der noch offene PR ist ivm mit BT nicht entscheidend, nice to have aber mehr auch nicht.
Wie schon in der Diskussion der letzten Monate angemerkt, ich nehme was kommt und erwarte eigentlich nichts. Das was open source ist kann eingesehen und verändert werden (bis auf die Implementierung der Zentrale).

Quote from olli711

Hm, ich habe jetzt den Livisi Raumthermostaten als Sensor für Better Thermostat und nutze jetzt mal DWD als Aussensensor.

Das funktioniert schonmal besser, als das was ich beim letzte Test hatte. Aber, ich habe 1 Grad unterschied von BT zu Livisi. Also, wenn ich in HA 18 Grad einstelle, dann habe ich 17 Grad im Thermostat stehen. Das scheint ein Bug zu sein.

Das ist normal, da die Temperatur ja an den Thermostaten gemessen wird und es wahrscheinlich deswegen eine Kompensation gibt. Deswegen ist ja sehr interessant eine Temperaturmessung im Raum zu haben, welche dann wiederum die HK steuert. Im Prinzip ist es ja auch egal was dort angezeigt wird, entscheidend ist ja das deine Wunschtemperatur erreicht und gehalten wird.

Wenn du in deinem eigenen Zuhause wohnst, kannst du dich ja einmal mit einer Heizlastberechnung, dem hydraulischen Abgleich, voreinstellbaren HK-Ventilen und der Anpassung deiner Heizkurve beschäftigen, bzw das beauftragen. Den Anfang kann man kostengünstig über die Verbraucherzentralen machen.

Die Anpassungen die du mit den HK-Thermostaten erreichst ohne an die Heizanlage ran zu gehen, lassen sich in etwa damit vergleichen, einen PKW auf Volllast zu betreiben und das Tempo über die Bremse zu regulieren.

Das HK-Thermostat-gesteuere ist im wesentlichen nur eine Komfortgeschichte.

Ich will jetzt damit keine Diskussion lostreten, es kann ja jeder so machen wie er möchte, nur sollt man sich von dem "Smarthome" allein keine Wunder erwarten.

Und Better Thermostat ist nur sinnvoll gegenüber dem Standardthermostat in HA wenn man über die zusätzlichen Sensoren verfügt, das müssen ja keine Livisi Geräte sein.

sieht doch gut aus, was meinst du mit "zu flach" ?

Hier das Video zu Better Thermostat von dem selben Youtuber wie oben.

wenn du mal deinen Teil mit meinem Bsp vergleichst, hast du sehr viel verändert was Fehler produziert.

state: >
            {{ state_attr('climate.wohnzimmer_thermostat_wohnzimmer', 'current_temperature')}}"

vs

state:               "{{ state_attr('climate.wohnzimmer_thermostat_wohnzimmer', 'current_temperature')  }}"

bei dir fehlt ein " ausserdem wird die Schreibweise mit dem > nur benötigt wenn du mehrere Zeilen code nutzt, hier also nicht nötig und macht das ganze fehleranfälliger.

- platform:
  - template:
  - sensors:

vs

  - platform: template
    sensors:

auch das ist falsch und kann nur zu Fehlern führen.

Einige ältere Beispiele verwenden zudem noch ein ältere, mittlerweile von HA nicht mehr als korrekt angesehene Schreibweise. Macht es für den Neuling nicht einfacher, seinen code testen...

Genauso ist es.

Wenn man in den Entwicklungswerkzeuge sieht man die verfügbaren Attribute pro Entität.

Ebenso die durch die templates erzeugten Entitäten.

Ausserdem fällt im Vergleich zum Better Thermostat auf, welche hvac_modes und hvac_actions bei Livisi nützlich für eine komplette Implementierung sind.

climate.wohnung_raumklima so heisst das Heizkörperthermostat bei mir, bei dir climate.xyz.

name und unique_id kannst du dir so wählen wie du möchtest, darüber kannst du die Werte dann hinterher in deinem Floorplan ansprechen.

Wichtig bei yaml ist die korrekte Einrückung, zB immer zwei spaces eingerückt wie in meinem Bsp.

Versuchs doch erst einmal mit einem Wert, wenn das klappt dann kannst du die anderen benötigten dann nach dem selbem Muster einfügen.

Ohne das du mal das schreibst, was du bei dir eingegeben hast, kann dir leider niemand wirklich weiter helfen Auch ein Screenshot von dem was du erreichen willst, oder das Anzeigen des Fehlers der geworfen wird macht es erst möglich dir ansatzweise zu helfen, jedenfalls geht das mir so.

Dazu auch nochmal mein Tipp, versuch es mal in einem HA Forum, - die Probleme die du hast, haben nichts mit den Livisi Geräten zu tun.

Quote from olli711

Moin,

hat mal jemand versucht irgendwie die Luftfeuchtigkeit abzugreifen? Die Entiäten geben das nicht her.

  - platform: template
    sensors:
      - name:                "Wohnung Current TVR Temperature"
        unique_id:           "wohnung_current_tvr_temperature"
        unit_of_measurement: °C
        device_class:        temperature
        state_class:         measurement
        state:               "{{ state_attr('climate.wohnung_raumklima', 'current_temperature')  }}"

      - name:                "Wohnung TVR Temperature"
        unique_id:           "wohnung_tvr_temperature"
        unit_of_measurement: °C
        device_class:        temperature
        state_class:         measurement
        state:               "{{ state_attr('climate.wohnung_raumklima', 'temperature')  }}"

      - name:                "Wohnung Current TVR Humidity"
        unique_id:           "wohnung_current_tvr_humidity"
        unit_of_measurement: "%"
        device_class:        humidity
        state_class:         measurement
        state:               "{{ state_attr('climate.wohnung_raumklima', 'current_humidity')  }}"

Das würde in yaml so aussehen, da die Werte nur als Attribute zur Verfügung stehen. Müsste dann in die configuration.yaml oder ausgelagerte yaml.

Ich habe ausser nach einem Neustart von HA eigentlich nie Ausfälle/Recalibrierungen der Anzeige.

Ich verwende Better Thermostat aus HACS und die zugehörige Lovelave BT Climate Card.

Nach etwas ausprobieren habe ich mit einer um 1°C niedriger eingestellten Solltemperatur als der gewünschten Raumtemperatur einen ziemlich guten Temperaturverlauf mit kaum über/unterschießenden Temperaturen am TVR.

Anbei mal meine Konfiguration und die entsprechenden Temperaturkurven. Daran kann man sehen, das die "AI" ziemlich oft eingreift, die Livisi eigene Steuerung ist da sehr viel träger und scheint imho nur auf/zu zu kennen.

Die Fenster auf/zu Erkennung wird zZ noch ignoriert, da für Geräte die keinen Zustand "OFF" kennen die funktionierende Erkennung ignoriert wird. Dafür ist aber bereits ein PR bei BT eingestellt,

Jedem seine Ansicht

Ich bin in dem HomeAutomation Bereich schon seit Jahren unterwegs und für mich stand immer im Vordergrund mich von einzelnen Herstellern unabhängig zu machen und die "dummen" Geräte mit einer grafisch ansprechenden Software zusammenzuführen und zu steuern. Das und einfach eigene Steuerungen auf Basis von ESP32/8266 zu realisieren wo es keine Herstellerlösungen gab.

Was ich damit sagen möchte ist das es je nach Gerätepark und persönlichen Präferenzen unterschiedliche Systeme gibt, die für einen geeignet sind oder nicht. Und diese Präferenzen ändern sich auch mit Technologien und über die Zeit.

Jedes System wird über die Oberfläche hinaus Skriptsprachen oder Konfigurationmöglichkeiten mitbringen, die idR für Spezialfälle gedacht sind.

In HA bewegt sich die Entwicklung aber weg von der Konfiguration über Yaml-Dateien, welche in der Vergangenheit die Norm waren.
Dies passiert jeden Monat ein Stück mehr - mit unterschiedlicher Intensität, was auch in den Relasenotes deutlich wird. Das gleiche gilt für Automatisierungen, welche grafisch konfiguriert werden, aber eben auch für Spezialfälle in YAML erstellt werden können.

HA wächst zZ wahnsinnig schnell, sei es im Bereich Matter/Thread oder Voice Assistants oder über die eher international angelegten Integrationen. Ich denke dies wird auch der Grund gewesen sein warum Livisi in letzter "Minute" noch auf diesen Zug aufgesprungen ist, obwohl es gute bestehende Implementationen gab.

Wenn man Zeit/Lust hat schaut man sich eben mehrere Systeme parallel an. Dabei sollte man imho eher konservativ heran gehen, bis man das Konzept hinter den Systemen verstanden hat.

Dieser (englischsprachige) Kanal fasst die Neuerungen und wichtige Themen in HA ganz gut zusammen, ua auch die monatlichen Releases (die eher einen Podcastcharakter haben, aber auch die Stimmung in der Community widerspiegeln). https://www.youtube.com/@EverythingSmartHome

Urteile über ein System aufgrund einer Momentbetrachtung finde ich daher schwierig und werden idR eher bestehende Vorurteile bestätigen, da das andere System es ja immer "anders" macht als man es gewöhnt ist. Aber anders muss ja nicht schlechter sein

LG