Z-WavePlus Thermostat Eurotronic Spirit: Schrittweise Inbetriebnahme

[krikan]

Dann können wir immer noch austesten, ob es einfach beim Spirit ein undokumentiertes feature ist (dann müsste bei set und get ja was passieren, wenn man die command class ergänzt?), oder ob es eben wirklich "nur" via FHEM/Controller-Software geht.

Das Spirit akzeptiert zwar den set-Befehl von CLIMATE_CONTROL_SCHEDULE, was zunächst nicht ungewöhnlich ist, aber Reaktion kann ich nicht feststellen.
get-Befehle werden nicht beantwortet. Die Command Class wird auch bei explizierter Anfrage per "get-versionClass" als nicht vorhanden deklariert. Zusätzlich gibt es keine Möglichkeit dem Spirit die Uhrzeit/Datum beizubringen. Die Command Class CLOCK ist nicht vorhanden und eine manuelle Einstellmöglichkeit gibt es nicht. Darum bleibe ich bei meiner These: Geht nicht.
Anders ist das beim Danfoss, aber das würde ich nicht (mehr) zum Kauf empfehlen.
Das Fibaro-Modell kenne ich nur theoretisch.

[rudolfkoenig]

Ich habe das oben erwaehnte setList Attribut implementiert:

setList
Some devices interpret SENSOR_MULTILEVEL events, e.g. to react to an external temperature sensor.
To enable FHEM to send such messages, specify the list of the desired readings, comma separated, with an sml_ prefix.
Example:
  attr DEV setList sml_temperature
  set DEV sml_temperature -12.2 C
The list of available scales can be retreived by specifying ? as scale. If no scale is specified, the first one from this list is used.

[curt]

Freunde der warmen Wohnküche - ich als Threadopener auch mal wieder.

0) Der  Z-WavePlus Thermostat Eurotronic Spirit scheint mir (derzeit) mit Einschränkungen erstaunlich stabil. Aus meiner Sicht ist es klug, da sowohl in Software (ich nenne es mal Treiber) als auch in Dokumentation zu investieren.

1) Nachteilig:
1a) Keine Rückmeldung des veränderten Sollwerts (das ist ein echtes Problem, da muss auf FHEM-Ebene immer automatisiert GET ran!)
1b) Offenbar verschiedene Firmware (bei mir kommt Reading battery nicht).

2) Meine Erkenntnisse möchte ich für spätere Nutzer irgendwie festhalten. Mir widerstrebt es aber, in @kirkan s Wiki-Eintrag rumzufuschen. Möglicherweise werde ich den ersten Beitrag dieses Threads nachträglich ändern, ich weiß noch nicht.

3) Lasst doch mal bitte Zeit-Profile weg - wer mit beiden Füßen gleichzeitig losläuft, fällt hin.

4) Externer Istwertgeber "Temperatur" - da sollten wir schlauerweise nicht primär an ZWave-interne Assoziationsspiele denken - sondern an Istwertgeber (Temperatur), die als Raum-Thermometer verfügbar sind - also auf der Ebene FHEM.
@rudolfkoenig Ganz naiv gefragt: Siehst Du gedanklich einen Weg, via FHEM alle halbe Stunde (irgend eine Zeitspanne!) dem Thermostaten eine externe IST-Werttemperatur zu geben, die nicht auf der ZWave-Ebene läuft? Die also quasi den im Thermostaten intern gemessenen IST-Wert ersetzt?

Ja, ist heikel, ich weiß. Musst Du mir nicht erzählen. Ich will ja erstmal nur wissen, ob Du das für technisch machbar hältst, machen könntest. (<lacht> ... und falls es geht, natürlich mit Rückfallebene auf den internen Temperatursensor, klar.)

5) @Beta-User
Das von Dir vorgeschlagene 70-Sensor-Dingens ist noch nicht da. Da die Frage "neuer Thread" bestand: Ich neige deutlich dazu, da (wie dieser Thread) ganz naiv einen neuen Thread aufzumachen, dann sinngemäß "Z-WAVEPlus Aeotec Multi-Sensor 6 ZW100-C: Schrittweise Inbetriebnahme".

Im angedachten Thread muss ich mich nicht doof stellen - ich bin das ja wirklich. Und dann nehmen wir das Dingens schrittweise in Betrieb ... und ich nutze nach Deinen Erklärungen Dein experimentelles template - höchst öffentlich. Und wir tauschen uns da (alle) ganz ausführlich ganz öffentlich aus. Also das wäre mein Vorschlag. Klar, kann auch schief gehen, vielleicht werfe ich dann das Dingens genervt aus dem Fenster ...

Aber von "lies mal commandref" und "danke, geht" lernt doch kein späterer Leser was. Irgendwie möchte ich dazu beitragen, dass sich da die Kommunikationskultur ändert.

[krikan]

Mir widerstrebt es aber, in @kirkan s Wiki-Eintrag rumzufuschen.

Das ist nicht mein Wiki(-artikel). Jeder darf gerne daran arbeiten. Ich selbst mache das immer nur soweit ich das für mein Verständnis brauche.

[Beta-User]

...vielleicht machen wir erst die Funktionalität vollends fertig und ziehen dann die Doku nach?

@curt:
Es gibt seit eben auch einen attrTemplate-Versuch für den spirit. Vielleicht magst du den mal austesten...? Dann sollte sich der Nebel um das Thema vielleicht insgesamt etwas lichten, wobei es durchaus sein kann, dass dieser erste Versuch ziemlich missglückt ist.
Leider war ich für das heutige update zu spät dran, also entweder das normale update machen und die template-File aus dem svn holen, z.B. für Freunde des Kochbuchs mit

Code Auswählen Erweitern

{ Svn_GetFile("FHEM/lib/AttrTemplate/zwave.template", "FHEM/lib/AttrTemplate/zwave.template", sub(){ AttrTemplate_Initialize() }) }
@krikan:
OK, verstanden, Hersteller Eurotronics kommt auf die "zwilichtig"-Liste...
Wäre nett, wenn du das template mal ansehen würdest, die configByte-Anweisungen sind ziemlich aus der Hüfte geschossen. Links zum Wiki etc. ziehe ich bei Gelegenheit nach.

@Rudi:
Danke für's Implementieren!

[curt]

Das ist nicht mein Wiki(-artikel). Jeder darf gerne daran arbeiten. Ich selbst mache das immer nur soweit ich das für mein Verständnis brauche.

Bei kleinen Wiki-Projekten (ich weiß, von was ich da rede) leidet die Konsistenz, wenn zwei Autoren ihre Sichten quasi konkurrierend vorstellen. - Wikipedia ist anders: Da ist es unbedeutend, ob das Stadtfest von ADorf erwähnt wird. Du verstehst?

...vielleicht machen wir erst die Funktionalität vollends fertig und ziehen dann die Doku nach?

Wenn ich es recht sehe, werden wir bis März/April ganz viel Zeit haben, Stichwort Corona.

@curt:
Es gibt seit eben auch einen attrTemplate-Versuch für den spirit. Vielleicht magst du den mal austesten...?

Amazon meldet, dass man irgendwann Anfang November prime liefern könne: Dann habe ich einen freien Thermostaten. Und ich bin da auch zu jeder Schandtat bereit. (Mit der Einschränkung, dass ich da nicht ständig, nur ab und an umschrauben werde, ich habe ja das zusätzliche einschränkende Problem, dass zwischen Ventil und Thermostat noch ein Adapter als Metall/Edelstahl ist.

Dann sollte sich der Nebel um das Thema vielleicht insgesamt etwas lichten, wobei es durchaus sein kann, dass dieser erste Versuch ziemlich missglückt ist.

Das Leben ist kompliziert.

Erkläre Du mir, wie ich #unknown22 aus ZWave rausbastele. Oder wenigstens, wie ich meinen ZWave-Adapter mal sichere ohne Kenntnis der Speichergröße ... dann bin ich auch gnädig mit Deinen Code-Fehlern.

OK, verstanden, Hersteller Eurotronics kommt auf die "zwilichtig"-Liste...

Überfliege mal unauffällig https://forum.fhem.de/index.php?topic=114669.msg1088958#msg1088958

[rudolfkoenig]

@rudolfkoenig Ganz naiv gefragt: Siehst Du gedanklich einen Weg, via FHEM alle halbe Stunde (irgend eine Zeitspanne!) dem Thermostaten eine externe IST-Werttemperatur zu geben, die nicht auf der ZWave-Ebene läuft? Die also quasi den im Thermostaten intern gemessenen IST-Wert ersetzt?

Ich meine genau diesen Weg implementiert zu haben mit setList, siehe oben.

[Beta-User]

@Rudi:
Evtl. wäre es sinnvoll, auch die Versions-Angaben direkt bei der Inclusion mit abzufragen?

Hab's jetzt nicht recherchiert, aber dem Gefühl nach haben wir eine Ahnung, welche firmware-Version etc. auf den 8 Thermostaten von @curt werkelt, und ehrlich gesagt habe ich mich etwas gewundert, dass ich sowas selbst bei den am Stromnetz hängenden Aktoren selbst abrufen mußte.

@curt
Na ja, mein Verständnis war, dass du dringend nach einer Möglichkeit suchst, einen der Thermostate mit einem externen Temperatursensor zu steuern, ohne dich auch noch in PID20 einzulesen... Das sollte mit Rudi's update iVm. dem attrTemplate möglich sein, Restrisiken selbstredend nicht ausgeschlossen.
Die Befürchtung, dass du damit die firmware komplett abschießt, teile ich allerdings nicht, und den genannten "#unknown22" kann ich auch nicht zuordnen. Hat das was mit den configByte-Anweisungen im attrTemplate zu tun?

Deinen Frust bzgl. der Batterie-Geschichte in dem anderen Thread habe ich auch ohne ausdrücklichen Hinweis schon wahrgenommen, und mir war auch klar, dass der Versuch, das betreffende Byte zu setzen ggf. nicht erfolgreich ist und man ggf. Nacharbeiten muss (mit einem at, z.B.).

@all:
Das Thema firmware-Updates scheint ein "common problem" zu sein. Bzgl. der Fibaro-Devices (und ggf. auch dem Spirit?) hätte ich eine Idee. Scheinbar kann man einen root-ssh-Zugang auf die Home-Center bekommen, und lt. den Untiefen des Inet sollte es möglich sein, so ein HomeCenter auch in ein bestehendes ZWave-Netz zu includieren, dann updates durchzuführen und das Teil danach wieder zu excludieren. Von daher bin ich am überlegen, so eine Art "Community-Gerät" zu beschaffen, das gegen eine Aufwandsentschädigung alle User hier für z.B. 10 Tage leihen könnten, um auf den letzten Stand der Dinge zu kommen. Danach ginge es an den nächsten usw.. Evtl. gäbe es über den ssh-Zugang noch andere Optionen, z.B. festzustellen, wie das Ding intern tickt? Ggf. kann man darüber auch welche "Fremdfirmwares" updaten?
Falls das mit der "Comunity-update-Box" jemand eine gute Idee findet: Melden. Nur für mich ist es ein Spielzeug und evtl. sieht das Budget ggf. anders aus, wenn sich jemand beteiligen mag oder wenigstens Interesse bekundet...

Ergänzend: Es war da auch zu lesen, dass evtl. ab Q1 2021 updates auch ohne HomeCenter möglich sein könnten; Fibaro scheint (bis dahin begrenzt?) irgendein "Problem" mit TI zu haben.

[curt]

Ich meine genau diesen Weg implementiert zu haben mit setList, siehe oben.

Danke für Deine Antwort.

Rudolf, ich bin der mit den kleinen Kartoffeln:
Ich habe das nicht gesehen und kann das derzeit auch nicht überblicken. Eigentlich reicht aber, dass andere das können und erkennen können, sofern sie wollen.

Danke nochmals.

[curt]

Deinen Frust bzgl. der Batterie-Geschichte

Pahhhh ... Frust.

Quitsch. Es ist anders: Ich nehme Fakten zur Kenntnis. Es gibt bei meinen Thermostaten halt keine selbstlaufenden battery-Updates, dann müssen wir damit umgehen.

Ich will nicht zu viel von mir erzählen: Ich code mehr oder minder intensiv seit 35 Jahren. Eher minder, im Hauptberuf leite ich ein IT-Unternehmen ... also sagen wir mal so: Ich bin schmerzbefreit. Ich bin Kummer gewohnt.

[rudolfkoenig]

Evtl. wäre es sinnvoll, auch die Versions-Angaben direkt bei der Inclusion mit abzufragen?

Ich bin immer noch der Meinung, bei der Inklusion nur das Notwendigste abzufragen, um keine Probleme zu provozieren.

Ich wuerde "get XX version" hoechstens in "Welche Infos sollten Anfragen im ZWave-Forum enthalten?" eintragen, aber selbst da ist das nur in speziellen Faellen hilfreich, meines Wissens liefern die Hersteller keine Change-Historie, d.h. wir muessten selbst so eine DB aufbauen.

In unserem speziellen Fall waere version aber sicherlich vom Interesse.

[rudolfkoenig]

den genannten "#unknown22" kann ich auch nicht zuordnen.

Ich vermute dabei ein Geraet, was dem Controller bekannt ist (siehe get nodeList) aber FHEM nicht, deswegen kann FHEM 22 nicht einem Geraet zuordnen. Kann auch sein, dass es eine "Leiche" ist.

[curt]

Ich bin immer noch der Meinung, bei der Inklusion nur das Notwendigste abzufragen, um keine Probleme zu provozieren.

Ich habe noch nicht verstanden, welche Probleme Du ganz konkret siehst:
Ich kämpfe mich durch zig Posts und Anleitungen um dann ca. 5 GETs von Hand loszuschicken. Also der Teil könnte ja wohl mit jeweils Zeitversatz 3sec auch automatisch laufen ... wenn das schief gehen sollte, bin ich genau da, wo ich auch ohne Automatismus bin. Schaden kann da also nicht entstehen.

Kannst Du bitte Dein "um keine Probleme zu provozieren" fachlich konkretisieren? Oder ist das eher Dein Bauchgefühl?

P.S:
"#unknown22" ist eine Leiche, die der ZWave-USB-Adapter mit sich rumschleppt. Selbigen würde ich übrigens gern daten-sichern, mein RANT in der Sache wurde überlesen.

[rudolfkoenig]

Wir reden ueber Daten, die im Normalfall nicht benoetigt werden, siehe diesen Wiki Abschnitt.
Je nach Geraet sind das 10 bis 100 Datenpunkte, die jeweils zwei ZWave-Telegramme bedeuten (Frage+Antwort). Bei zwei Hops/Router zwischen Controller und Endgeraet verursacht ein Telegramm 7 Funknachrichten (wenn alles ohne Probleme laeuft). Ich will nicht ohne triftigen Grund einen lange andauernden Funkverkehr verursachen, was mit einiger Wahrscheinlichkeit zu Problemen fuehrt.
Im Bedarfsfall muessen diese Daten abgefragt werden, damit das Problem identifiziert werden kann, aber frische Daten sind besser, als Veraltete. Welche das sind, ist dokumentiert.

Zum backup: versuchs mal mit 256k. Was groesseres habe ich noch nicht gehoert, und wenn es kleiner ist, dann werden die Daten wiederholt, sollte auch kein Problem sein.

[Beta-User]

Ich bin immer noch der Meinung, bei der Inklusion nur das Notwendigste abzufragen, um keine Probleme zu provozieren.

Hatte erst geschrieben: "Zweifle an der Stelle immer noch leicht, aber ihr habt da mehr Erfahrung und ggf. auch größere Netze (=>höheres Risiko, dass da was schiefgeht, wenn zu viel gleichzeitg kommt)". Bin jetzt bei dir (s.u.).

Mit meiner CUL_HM-geprägten noob-Herangehensweise habe ich jedenfalls eine gewisse zeit gebraucht, bis mir aufgegangen ist, dass man die Versionsinfos @ZWave aktiv anfragen muss.

Ich wuerde "get XX version" hoechstens in "Welche Infos sollten Anfragen im ZWave-Forum enthalten?" eintragen, aber selbst da ist das nur in speziellen Faellen hilfreich, meines Wissens liefern die Hersteller keine Change-Historie, d.h. wir muessten selbst so eine DB aufbauen.

"Höchstens" irritiert mich dann doch etwas. Klar kann die Abfrage gerade dann störend sein, wenn man sowieso schon Probleme hat. Das wirft aber dann wieder die Frage auf, wann denn der bessere Zeitpunkt wäre...
Wir brauchen vermutlich keine DB dazu aufbauen, weil wir eh' wenig machen können (außer ggf. den Herstellern auf die Füße zu steigen oder private Würgarounds zu generieren), aber es hilft eventuell schon mal um rauszufinden, ob man es denn mit einer problematischen firmware zu tun hat (ggf. mit neueren Versionen behobene Fehlerbilder sind ja nicht auf FHEM beschränkt), oder ob man einigermaßen "auf Stand" ist. Jedenfalls weiß ich bzgl. des 6-fach-AEOTEC zwischenzeitlich, dass es einen minor change gab, und vermutlich ist der auch für den Missmatch zwischen "Beipackzettel" und meiner realen Welt verantwortlich...

Aber ich gebe dir recht, es ist vermutlich besser, die User an der Stelle zu instruieren, dann können die das machen, wenn sie es für passend empfinden. Ich werde das künftig direkt nach der Inclusion machen, aber eher, weil mich eben interessiert, mit was ich es zu tun habe. Meine "Wohnzimmer-Licht"-Aktoren hatte ich jetzt über Monate stressfrei am Laufen, und da war es mir bis dato nicht so wichtig, eben weil a) alles funktioniert hat und b) sowieso nirgends firmwareupdates für die Dinger zu erhalten gewesen wären...

Spicht für deine "Sparsamkeitsthese"  .