Posts by qschneider

    Moin, ich meinte in meinem Beitrag nicht das Überschwingen, das ist i.o.

    Es ist eher eine Darstellungssache in HA, das wenn die Temperatur oberhalb der Zieltemperatur liegt, der Bereich nicht rot eingefärbt dargestellt wird, da ja nicht mehr "geheizt" wird.


    in den beiden Grafiken sieht man den Unterschied.

    Wodurch es ausgelöst wird und wie es behoben werden kann, müssten die Entwickler mal analysieren, daher die Frage wo solche (vermeintlichen) issues gepostet werden sollen.

    Was mir bei meinem Heizkörperthermostat auffällt ist das er den Heizmodus nicht abstellt, wenn er die Solltemperatur erreicht hat, ist aber vlt nur ein Darstellungsfehler oder im Swingbereich. Was mich zu der Frage bringt, wie LIVISI Userfeedback zur Umsetzung mitgeteilt haben möchte?


    laut dem changelog https://rc.home-assistant.io/changelogs/core-2023.4 sollen mehrere Devices kommen.


    Wenn die Fußbodenheizungsregelung die FSC8 ist, dann ist sie laut Beschreibung (s.u.) dabei.


    home-assistant.io/livisi.markdown at cd2dc11833fdcdaf65165ea11511686969416bc3 · StefanIacobLivisi/home-assistant.io
    :blue_book: Home Assistant User documentation. Contribute to StefanIacobLivisi/home-assistant.io development by creating an account on GitHub.
    github.com


    Add support for Livisi PSSO, ISS and ISS2 switch devices by planbnet · Pull Request #89140 · home-assistant/core
    Breaking change Proposed change Add support for additional device types: PSSO (Outdoor Switchable Outlet) ISS and ISS2 (In-Wall Switch) The interface to…
    github.com

    Die Beta ist jetzt seit ca einer Stunde raus und einige neue Livisi Komponenten sind drin enthalten.

    Leider sind die Werte der HKTs nicht als Entitäten abgreifbar, nur als Attribute - das macht es etwas aufwändiger zB die Luftfeuchtigkeit gesondert darzustellen.



    Wie ich hier schon schrieb, unter https://www.home-assistant.io/common-tasks/os/ wird alles beantwortet was dev, beta und restore angeht. Lohnt sich mal ganz durchzulesen, aber hier in Kurzform.


    1. In your Home Assistant UI navigate to System > Updates
    2. Click the overflow menu in the top right corner
    3. Click “Join beta”
    4. Navigate to Configuration panel
    5. Install the update that is presented to you
    Quote

    Wenn aus dem zerknitterten 10-Mark-Schein den man mir geschenkt hat dann doch kein "Hunni" mehr wird ist das schade aber die Streusel auf dem Schokoüberzug der Sahne des geschenkten Eises zu bemängeln find ich dann schon überzogen.

    Das hatte ich oben in etwa damit ausdrücken wollen

    Quote

    Von Seiten der Anwender muss man aber auch sagen, das ich da sehr viel enttäuschte Erwartungen sehe, welche realistisch nicht erfüllt werden können. Der Vergleich wäre von VW zu fordern, das mein Käfer ein kostenloses Umrüstpaket auf einen E-Motor erhalten soll.

    Oder bezog sich das auf die anderen Beiträge hier?


    Ich kann persönlich damit damit gut leben am Ende zu schauen was von diesem System nutzbar bleibt, der Elektroschrottvermeidungsgedanke ist jedoch meine Triebfeder weiter nachzuhaken. Daher auch keine Schuldzuweisungen sondern Lösungsgedanken.


    LG

    Ich denke wir werden das von dir geschriebene am 2.März 2024 abschließend bewerten können!

    Quote

    Und finde es etwas unfair LIVISI gegenüber hier Druck auf zu bauen.

    Dies ist der einzige Kanal um in den Dialog mit Livisi als Firma zu treten, warum also nicht respektvoll aber offen Themen ansprechen die jetzt noch möglich sind? Daher muss ich das leider zurückweisen.


    Warum sich Livisi entschieden hat auf HA zu setzen, war wohl eine strategische Entscheidung, deren Grundlage ich nicht kenne, die aber natürlich aus meiner Sicht sehr zu begrüßen ist - das steht ausser Frage.

    Nur wenn man es machen will, sollte man vor dem Announcement geklärt haben wer dies dann umsetzen soll und einen Zeitplan haben und sich daran halten.


    Ich würde daher gerne lesen, was passiert, wenn es keine Freiwilligen gibt die das Projekt umsetzen wollen.


    Wie man nun zu diesem Zeitpunkt damit verfahren könnte, dazu habe ich meine Vorschläge gemacht und bin gerne bereit darüber zu diskutieren, alles andere bringt uns in der Sache mMn nicht weiter.

    Moin, ich denke die Geschichte und Beweggründe der Firmen und Käuferentscheidungen sind schon in der Vergangenheit ausreichend beleuchtet worden, das die Diskussion aber immer wieder geführt werden zeigt mir aber das ein Grundproblem immer noch besteht.


    Enttäuschte Erwartungen, unzureichende Kommunikation was in der Zukunft verlässlich erwartet werden kann und dies dann auch zum zugesagten Zeitpunkt zu liefern!


    Dies wird von LIVISI zwar immer als Reaktion auf solche threads gut und nachvollziehbar erläutert, nur verfehlt man immer die Erwartungen, die man selber in den Köpfen der Anwender einmal gesät hatte.

    Bsp. HKT Anfang Feb/März für HA, wo doch der Fahrplan für HA schon im Sommer/Herbst feststand und man die Prios eindeutig hierauf hätte setzen können.


    Von Seiten der Anwender muss man aber auch sagen, das ich da sehr viel enttäuschte Erwartungen sehe, welche realistisch nicht erfüllt werden können. Der Vergleich wäre von VW zu fordern, das mein Käfer ein kostenloses Umrüstpaket auf einen E-Motor erhalten soll.


    Das diese Diskussion um Prioritäten, Ressourcen und Strategien geführt wird, ist aber gerade jetzt sehr sinnvoll, weil es später im Jahr nur Frust zu bewältigen gibt.


    Es wäre daher ehrlich zu kommunizieren, was man mit den eigenen Ressourcen bis wann liefern kann.

    Immer zu sagen das das lokale SH prio hatte, bringt nur Frust. Und wer will das lokale SH denn nach März 2024 pflegen, welches ja die Basis für alle anderen SH Systeme ist, es selbst aber closed source ist?


    Genauso wird ein Interesse von Entwicklern eher mau sein unter diesen Bedingungen ihre Freizeit in ein System zu investieren, welches nur noch am Laufen gehalten wird und für das es zwei lauffähige Integrationen gibt.

    Auf der anderen Seite würde es jetzt schon einen gewissen „Entwicklungsdruck“ der Gemeinde auslösen, wenn livisi klar formulieren würde was aus den Erfahrungen des letzten halben Jahres der Entwicklung für HA überhaupt möglich ist, bzw was man selbst schaffen kann.

    Eine Roadmap wäre da hilfreich und auch eine Anlaufstelle in Form eines Github repos in welchem dann die Dokus, technische Diskussion und PRs einfließen sollten/können.


    Vlt ist es auch ein Ansatz auf Basis der bestehenden Integrationen zB eine MQTT Schnittstelle zur Verfügung zu stellen, welche dann von Drittsystemen genutzt werden könnte. Ob DAS jemand machen möchte, steht auf einem anderen Blatt.


    Bsp hierfür ist zB das Projekt https://github.com/dewenni/ESP_Buderus_KM271 welches es ermöglicht die Steinzeitschnittstelle einer Buderus-Steuerung in modernen Systemen zu nutzen. In Vorgängerprojekten zB in FEHM wurde über Jahre reverse-engeniering die Grundlage hierfür geschaffen, weil auch hier der Hersteller seine Dokus nur unvollständig verfügbar gemacht hatte.


    Ich verweise hier auch auf meinen Artikel, wo ich dies für meinen Usecase auf Basis von iobroker/nodeRed/HA gelöst habe.


    happy hacking und ein friedvolles Jahr 2023!


    „Und so kam der Käfer dann doch noch zum E-Motor“ :)

    Sobald man etwas mehr als nur das nackte HA laufen lassen will wird der Arbeitsspeicher zum Flaschenhals, >= 2GB sind sehr zu empfehlen, auch sollte es dann auch etwas besseres als eine SD Card sein, min eine externe HDD auf welcher man dann die Daten auslagert (in HA einstellbar). Und wenn man zB ein ESPhome Projekt kompiliert, wird das Ganze auf einem RP3 dann zur Kaffepause.


    Zum Reinschnuppern mag es jedoch ausreichen...

    Moin, wer es als Home Assistant (HA) Anwender nicht erwarten kann, zB seine Livisi HK Thermostate jetzt schon in HA zu nutzen, für den beschreibe ich hier einen möglichen Weg. Für alle anderen sollte die offizielle Integration ja bald verfügbar sein.


    Der Weg ist bestimmt nichts für jeden, eher etwas für Fortgeschrittene, da hier sowohl iobroker, node-RED und HA (HACS) eingerichtet sein müssen. Die können sich dann aber auch andere Livisi devices, welche in iobroker unterstützt, nur zu diesem Zeitpunkt noch nicht in HA verfügbar sind, in HA verfügbar machen.

    Die obigen Komponenten sollten vorher alle installier/konfiguriert sein, bevor mit meinem Bsp weitergemacht werden kann!


    Mein Bsp ist wie folgt aufgebaut, kann als Basis verwendet, muss aber an die eigenen Devices angepasst werden.


    4 HK Thermostate in 3 Räumen, 2 davon sind in einem Raum zusammengeschaltet worden und werden daher immer gemeinsam geschaltet, liefern aber ihre jeweiligen Temperatur/Luftfeuchtigkeitswerte.



    In Node-RED verwende ich den angefügten flow wie im Bild zu sehen.


    Die bestehende HA-Serverkonfiguration und meine bestehenden entities müssen jeweils neu erzeugt bzw angepasst werden, bevor der flow deployed wird.

    Dazu kann es daher hilfreich sein, zuerst nur den iobroker part zu konfigurieren und zu testen, das die gewünschten Werte auch angezeigt werden, bevor man die HA Nodes erzeugen lässt.


    In HA benötigt man die Konfiguration der Programmable Thermostat, welche in meinem Bsp so definiert sind und dann auf der Oberfläche so aussehen.


    Die verwendeten entities für zB heater: input_boolean.heater_dining sind Helper die keine Auswirkungen auf die Funktion haben, jedoch für die Komponente definiert sein müssen.


    Happy hacking 8o

    Danke das auf diesem Weg Bewegung in die Sache kommt, zwischen 988 und 1024 liegen aber potentiell eine Menge Auslieferungen die nicht raus gegangen sind....


    Leise, ganz leise Kritik

    Checkt das bei Livisi keiner wenn eine Abteilung 4 Wochen stark verzögert/nichts ausliefert und sich nicht beim Kunden zurückmeldet?

    Moin, ich muss leider dieses Forum nutzen um eine Antwort der oben genannten Abteilungen bei Livisi zu bekommen.

    Hintergrund ist folgender, nach langem hin und her und diversen Firmwares ist meine Zentrale 1.0 jetzt in einer Rebootschleife beim Coprozessorupdate und damit gebricked.

    Der Service hat dann ziemlich schnell und kulant eine Zentrale 2.0 als Austausch angeboten.

    Im Ergebnis soweit alles gut.


    Nun habe ich wie angeraten im Retourenportal einen Austausch beantragt, welcher am 7. Dezember wie folgt genehmigt wurde.


    wir haben deine Anfrage (Fallnummer 1024) auf Gewährleistung für das Gerät innogy Zentrale mit der Seriennummer 8) geprüft und werden den Versand eines Ersatzgerätes umgehend veranlassen.


    Danach ist nichts mehr passiert und auch drei Emails meinerseits mit der Bitte mir eine Versandnummer und Versandstatus zu nennen wurden nicht beantwortet. Auch eine Email im ehemaligen Serviceticket (SHFTS-62778) mit der Bitte dies intern anzustoßen blieb unbeantwortet.


    Daher meine Frage und Bitte auf diesem Weg hier tätig zu werden, "umgehend" verstehe ich anders und nicht zu antworten kann ich nicht akzeptieren.


    Mit freundlichen Grüßen

    Moin, mich würde auch der zeitliche Fahrplan für weitere Geräte interessieren, RST steht bei mir auch vorne an.

    Kann eher man mit monatlichen Releases wie bei HA rechnen oder wovon wird es abhängen?