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“ 