Z-WavePlus Thermostat Eurotronic Spirit: Schrittweise Inbetriebnahme

[krikan]

Und wer ist nun wieder Herr Paetz? Bzw: Wo kann man dessen Werk einsehen?

https://www.thalia.de/shop/home/artikeldetails/ID40364151.html

[krikan]

Was bringt das ganz konkret, was habe ich davon, wenn ich ein externes Thermometer mit dem Thermostat ver-assoziiere? Vergisst der Thermostat dann das interne Thermometer und nutzt das externe Thermometer für seinen internen Regelkreis bei thHeating und tmEnergiySaveHeating? Oder wie?

In https://eurotronic.org/wp-content/uploads/2018/08/Spirit_Z-Wave_BAL_web_DE_view_V5.pdf steht auf Seite 17:

Spirit Z-Wave Plus kann gemessene Temperaturen von anderen Z-Wave Geräten (z.B. einem Wandthermostat) empfangen und diese Temperatur zur Raumtemperaturregelung verwenden. Diese Funktion muss per Konfigurations-Befehlsklasse aktiviert werden.

Verstehe ich als: Verbundenes externes Thermometer ersetzt internes Thermometer. Parameternummer 8 muss auf 0x80 gestellt werden (Temperatur wird extern bereitgestellt).

[Beta-User]

Jetzt habe ich versehentlich den vorherigen Beitrag editiert, statt nur ein Zitat daraus zu verwenden...

[...] Da ist auch myUtils-Code drin, den werde ich mal (in leicht veränderter Form) in die zwave-myUtils-file reinnehmen. Leicht verändert deswegen, weil ich mal unterstelle, dass das (im Prinzip) genauso mit einem Fensterkontakt ginge.

Sieht so aus, als wäre beim Spirit kein myUtils-Code mehr nötig. Völlig unscheinbar zwischen allem anderen findet sich da was von Rudi, das bisher niemand (...!) kommentiert hat:
https://forum.fhem.de/index.php/topic,77598.msg999601.html#msg999601

@Rudi, da du die Senderoutine via "get" als "hack" bezeichnet hast und wir eigentlich auch weg wollen von "device specials" im Modulcode selbst (?): Es gibt zwischenzeitlich eine ganze Armada von Clonen von dem Spirit, (lt. Versandhaus mit "A") auch eine neuere Version) und (neuerdings?) auch Thermostate von Fibaro. Würde man da nicht eher eine Art generische Sende-Option benötigen?

(Fensterkontakte gingen ja auch via tmOff, dafür wäre wohl kein Würgaround erforderlich....)

[Deckoffizier]

Hallo,

bin zwar leider im Ernst kein begnadeter Programmierer aber warum so verkomplizieren....

entweder hat man mit den ZWae Spirits im "normalen" Modus wie
tmHeating die Möglichkeit die Regelung mit seinen internen Thermometer zu
betreiben wahlweise mit Offset,

oder mit einem anderen   !  ZWave Temperaturgeber zu Koppeln und das interne zu umgehen
bei der Regelung als Input.

Oder andere Variante mit Umweg über PID20 im tmManual Modus ein externes Thermometer
aber   !    nicht unbedingt als von Zwave zu benutzen wobei auch das interne des Spirit den Temperaturwert
liefern kann.

Verstehe ich trotz meines hohen Alters das soweit richtig ?

Gruß
Hans-Jürgen

[Beta-User]

Es gibt eine 4. Variante über den setter, den Rudi aaO. eingebaut hat:

Damit wird nur beim Spirit ein externalTemp Befehl zur Verfuegung gestellt.
Achtung: ich habe kein Spirit, konnte den Patch also nicht testen.

Danach würde man z.B. über ein notify die Temperatur von einem beliebigen Sensor nehmen können:

Code Auswählen Erweitern

n_Virtual_Temp_notify notify EG_sz_Tempsensor:temperature:.* set EG_sz_THERM  externalTemp $EVTPART1Und hätte dann dasselbe Verhalten wie unter "mit einem anderen   !  ZWave Temperaturgeber zu Koppeln" beschrieben - man muß allerdings vermutlich in beiden Fällen das interne Thermometer ausschalten...
Damit verbleibt die Regelungslogik (die du mit PID20 ersetzt) auf dem Spirit, aber ähnlich wie bei den HM-Thermostaten dürfte das abgesetzte Thermometer zu einem deutlich besseren Regelungsverhalten führen.
Problematisch (aber auch mit PID20) wird es dann, wenn der Sensor keine Daten (mehr) liefert.

[rudolfkoenig]

Es gibt eine 4. Variante über den setter, den Rudi aaO. eingebaut hat:

Soweit ich sehe, habe ich diesen Patch nur vorgeschlagen, und mangels Feedback nicht eingebaut.

Würde man da nicht eher eine Art generische Sende-Option benötigen?

Gerne, aber wie?
Oder auch: woran soll ich festmachen, dass ein Geraet dieses Befehl unterstuetzt?

[Beta-User]

Ah, ok.

Was das "Festmachen" angeht, bin ich auch etwas ratlos. Meine evtl. mal wieder völlig abwegigen Gedanken: ein Setter am IO?
Syntax in diese Richtung:

Code Auswählen Erweitern

set <IO> virtValue <Device> <type> <value>
<Device> = Das Zieldevice, hier der jeweilige Spirit
<type>    = Art des Werts (also Temperatur, motion (?), Helligkeitswert, ..., Wochenprofil (?), whatever)
<value>   = Wert
Ggf. noch ergänzt um

Code Auswählen Erweitern

set <IO> sendRaw <hex-code>

Wenn ich es richtig verstanden habe, braucht man in Variante 1 zum Zusammenbauen alle diese Infos, und eigentlich sind die Formate und Umrechnungen bekannt und im Modul hinterlegt (?).
Variante 2 würde dann den "Hack"-Modus umgehen, indem man eben dem wissenden User die Option gäbe, selbst fertigen Code zu liefern. Ginge ggf. auch über ein IOWrite, aber vermutlich würde es schon sinnvoll sein, das in der/den Warteschlange/n zu verwalten.


Was mir beim Schreiben gekommen ist: eigentlich ist doch "set <zwavedevice> configDefault" auch nur eine Art wrapper für "alles mögliche". Wäre es nicht möglich, damit einen etwas weniger unschönen Hack zu basteln?
Oder (als "Expertenmodus"?) einen sendRaw-setter für solche Fälle zu ermöglichen?

Wie gesagt: erst mal ungeordnet, aber bevor ich einen Hack verbreite...?
(Es wäre sicher schöner, wenn man - um erst mal beim konkreten Anwendungsfall zu bleiben - am Device selbst den gesendeten Temperaturwert ablesen könnte samt dem Zeitstempel der letzten Aktualisierung; aber letztlich ist das nachrangig zur Funktionalität.

[Deckoffizier]

Hallo Beta-User,

Danke für die Erläuterung zu Variante 4 macht einiges klarer!

Und hätte dann dasselbe Verhalten wie unter "mit einem anderen   !  ZWave Temperaturgeber zu Koppeln" beschrieben - man muß allerdings vermutlich in beiden Fällen das interne Thermometer ausschalten...
Damit verbleibt die Regelungslogik (die du mit PID20 ersetzt) auf dem Spirit, aber ähnlich wie bei den HM-Thermostaten dürfte das abgesetzte Thermometer zu einem deutlich besseren Regelungsverhalten führen.
Problematisch (aber auch mit PID20) wird es dann, wenn der Sensor keine Daten (mehr) liefert.

Zu Problematisch wenn der Sensor keine Daten mehr liefert, naja in PID20 ist dafür die Möglichkeit vorgesehen u.a einen Ersatzwert für die Ventilöffnung
zu nehmen bei mir habe ich sicherheitshalber 7% genommen damit die Hütte nicht einfriert.
Dann wäre noch Gürtel und Hosenträger also 2 Sensoren parallel und einer könnte dann sogar wieder der interne sein(? Programmieraufwand)   

Wenn man das letzte noch raus kitzeln will ist eben die Visualisierung ganz Hilfreich mit PID20.
Hoffentlich klappt diesmal der Datei Anhang hat irgendwie beim letzten Mal nicht geklappt.

Im SVG sieht man sehr schön IST und Soll liegen fast aufeinander.
Aber auch um die Batterielaufzeit zu verlängern kann versuchen so wenig wie möglich Ventilverstellungen
hin zu bekommen.

Jetzt habt Ihr mich natürlich am Haken mit verkomplizieren ala Spielwiese.

Gruß
Hans-Jürgen

[rudolfkoenig]

@Beta-User:
es geht hier um das optionale Senden von SENSOR_MULTILEVEL ZWave-Nachrichten an beliebige Geraete (d.h. nix mit Wochenprofil )

Meiner Ansicht nach gehoert das als setList Attribut an das Geraet, mit der Liste der gewuenschten Befehle, in der Art

Code Auswählen Erweitern

attr dev setList sml_temperature sml_luminance
die dann in der Liste aller sets auftauchen. Alle Befehle nehmen zwei weitere Parameter, Wert und Einheit, Letzteres optional. Die zu schreibende Routine  muss nur die Umkehrung von ZWave_multilevelParse implementieren.

[Beta-User]

Meiner Ansicht nach gehoert das als setList Attribut an das Geraet, mit der Liste der gewuenschten Befehle, in der Art

Code Auswählen Erweitern

attr dev setList sml_temperature sml_luminance
die dann in der Liste aller sets auftauchen. Alle Befehle nehmen zwei weitere Parameter, Wert und Einheit, Letzteres optional. Die zu schreibende Routine  muss nur [...].

Das mit der setList gefällt mir gut, das ist in der Tat ein generischer Ansatz, und das Stichwort "setList" ist auch einigermaßen verbreitet. Weiter könnte man bei der FHEMWEB-Eingabe gleich prüfen, ob es tatsächlich eine entsprechende (Umkehr-) Routine gibt.

(v.a.) @krikan: Deine Meinung dazu?

Code Auswählen Erweitern


es geht hier um das optionale Senden von SENSOR_MULTILEVEL ZWave-Nachrichten an beliebige Geraete (d.h. nix mit Wochenprofil )
Korrekt, _hier_ geht es wohl um SENSOR_MULTILEVEL.

Ein Fensterkontakt wäre aber BASIC_SET, oder? Meine _Meinung_: Wenn wir das schon generisch angehen, sollte man auch (irgendwann...) die Fensterkontakt-Funktionalität mit einbauen. Dann würde es genügen, den Thermostaten (z.B. über einen WeekdayTimer) mit Solltemperaturen zu versorgen und ein simples notify den Fensterkontakt simulieren zu lassen. Sonst muss man das irgendwie synchronisieren (nicht, dass das schwierig wäre, der WDT kann ja durchaus FK's abfragen, aber es ist dann eben eine Stufe komplexer).

(Und das Thema mit den Wochenprofilen will mir einfach nicht aus dem Kopf, ist aber wirklich eine andere Baustelle, zumal ich bisher nur in der Doku gelesen habe, dass es geht, aber nirgends, wie. Es müsste doch einen Controller geben, über den man die betreffenden Messages ersniffen könnte...? (Vorausgesetzt, man weiß, wie.)).

[krikan]

(v.a.) @krikan: Deine Meinung dazu?

Bisher: Keine.   Habe keine Ahnung wie genau ich mir das vorstellen darf und wie Rudi das umsetzen will.

(Und das Thema mit den Wochenprofilen will mir einfach nicht aus dem Kopf, ist aber wirklich eine andere Baustelle, zumal ich bisher nur in der Doku gelesen habe, dass es geht, aber nirgends, wie. Es müsste doch einen Controller geben, über den man die betreffenden Messages ersniffen könnte...? (Vorausgesetzt, man weiß, wie.)).

Wenn Du das auf das Spirit beziehst und der Aussage auf https://eurotronic.org/produkte/z-wave-heizkoerperthermostat/spirit-z-wave-plus/ "Heiz- und Sparzeiten individuell einstellbar": Das Spirit hat afaik keine Command Class, die Wochenprofile oder andere Zeiteinstellmöglichkeiten unterstützt. Das muss alles von extern (Software z.B. FHEM) gesteuert werden.

Gruß, Christian

[rudolfkoenig]

.. wie Rudi das umsetzen will.

Bisher gar nicht, ich habe ja nur geschrieben, wie ich das vorstelle

Und das Thema mit den Wochenprofilen will mir einfach nicht aus dem Kopf, ist aber wirklich eine andere Baustelle, zumal ich bisher nur in der Doku gelesen habe, dass es geht, aber nirgends, wie.

Da schickt wer vmtl. Meldungen der Klasse CLIMATE_CONTROL_SCHEDULE.
Das sollte aber OOB funktionieren, da es keine "Sensor" Klasse ist.
BASIC_SET kann man senden, wenn man classes mit BASIC_SET ergaenzt.
Komisch, dass das Geraet das nicht von selber anbietet, wenn er es doch versteht.

Es müsste doch einen Controller geben, über den man die betreffenden Messages ersniffen könnte...?

Hurrah, ein neuer OpferTester fuer mein eingeschlafenes ZWCUL Projekt

[Beta-User]

Bisher: Keine.   Habe keine Ahnung wie genau ich mir das vorstellen darf und wie Rudi das umsetzen will.

Wenn ich's richtig verstanden habe:
Es gäbe ein neues Attribut setList. Das hätte dieselbe Wirkung wie z.B. bei dummy oder MQTT2_DEVICE, nämlich dass es alle dort enthaltenen Elemente als setzbare Elemente/Readings gäbe (für Readings braucht man @dummy noch einen korrespondierenden readingList-Eintrag).

Der User hätte es dann in der Hand, z.B.

Code Auswählen Erweitern

attr <spirit> setList sml_temperaturezu konfigurieren und könnte dann den setter sml_temperature benutzen:

Code Auswählen Erweitern

set <spirit> sml_temperature 22.4
Das ZWave-Modul würde dann das ganze in den passenden Sendecode umwandeln und dem betreffenden Spirit als externe Temperatur übermitteln. That's all...

Wenn Du das auf das Spirit beziehst und der Aussage auf https://eurotronic.org/produkte/z-wave-heizkoerperthermostat/spirit-z-wave-plus/ "Heiz- und Sparzeiten individuell einstellbar": Das Spirit hat afaik keine Command Class, die Wochenprofile oder andere Zeiteinstellmöglichkeiten unterstützt. Das muss alles von extern (Software z.B. FHEM) gesteuert werden.

An der gleichen Stelle findet sich auch:

Schaltzeiten pro Tag: 8
Schaltzeiten pro Woche: 7

Sowas macht für mich nur Sinn, wenn a) der Spirit auch Zeit und den Wochentag kennt (z.B. die equiva brauchen auch immer wieder eine Zeit) und b) diese "Schaltzeiten" auf dem Thermostat gespeichert sind. Sonst - z.B. über FHEM - gibt es doch keinerlei echte Limitierung, man könnte theoretisch jede Minute eine neue Solltemperatur vorgeben...

Daher meine ich, man müßte den Hersteller mal beim Wort nehmen und das mal austesten oder - wenn es nicht klappt - erfragen, wie man dem Spirit denn das mitzuteilen hat - andernfalls können die auch gerne die Werbeaussage ändern oder das so formulieren, dass man es als DAU auch versteht...

Wenn es über CLIMATE_CONTROL_SCHEDULE geht, dann fehlt m.E. noch eine Umsetzung, die das insbesondere zu weekprofile brückt - das "native ZWave-Format" ist ja grausam.... Nach meinen Erfahrungen bei WeekdayTimer würde das hier vermutlich eher klappen, wenn wir den betreffenden Code in ZWave unterbringen würden, weil da - jedenfalls auf den ersten Blick - ziemlich viel umgerechnet werden müßte und auch die aktuelle Soll-Temperatur des jeweiligen Thermostats eine Rolle spielt. Der WDT wird von weekprofile nur über einen setter informiert, dass er ein neues Wochenprofil verwenden soll, holt sich die Daten dann über ein CommandGet und wandelt die dann erst in sein eigenes Format um...

Wäre ggf. ein weiteres Listen-Element für setList...?

(Falls da Interesse besteht: Da könnte ich versuchen, Code (für ZWave.pm) zu liefern, wenn der "Rahmen" dafür vorhanden ist. An sich meine ich, dass sich der Aufwand mittelfristig lohnen könnte, weil man über weekprofile eine recht komfotable Abstraktionsebene hat, die einige schon nutzen).

BASIC_SET kann man senden, wenn man classes mit BASIC_SET ergaenzt.
Komisch, dass das Geraet das nicht von selber anbietet, wenn er es doch versteht.

Vielleicht zur Klarstellung: ich habe keinen Spirit und errate das alles nur aus der Doku...

Hurrah, ein neuer OpferTester fuer mein eingeschlafenes ZWCUL Projekt

Von daher kann ich zwar bestätigen, zwei der Transceiver auf einem MapleCUN auf ZWCUL via STACKABLE konifguriert zu haben, aber das war es dann auch schon...

[krikan]

Daher meine ich, man müßte den Hersteller mal beim Wort nehmen und das mal austesten oder - wenn es nicht klappt - erfragen, wie man dem Spirit denn das mitzuteilen hat - andernfalls können die auch gerne die Werbeaussage ändern oder das so formulieren, dass man es als DAU auch versteht...

Vielleicht ist der kleine Untertitel "Technische Änderungen jederzeit vorbehalten." zutreffend.
Wenn Du Zeit/Lust hast, kannst Du ja mal anfragen. Bei mir war man damals ziemlich "schweigsam".
Weder NIF noch Doku oder Praxis liefern Anhaltspunkte für eine eingebaute Zeitsteuerungsmöglichkeit bspw. über CLIMATE_CONTROL_SCHEDULE im Gerät. 
Evtl. habe ich etwas übersehen.

[Beta-User]

...kann schon sein, dass die dreist sind, die Beiträge hier lesen sich ja teils auch in diese Richtung, was Anfragen an den support anging (dazu habe ich dann grade das hier gefunden: https://forum.fhem.de/index.php/topic,92500.0.html).

Unabhängig davon:
Der Spirit ist ja nicht das einzige Klima-Gerät mit dieser Option, und das in der cref bei ZWave hinterlegte Format ist ... - nennen wir es "speziell". Wenn wir wollen, dass sowas wirklich genutzt wird, sollten die Werkzeuge auch dazu passen...
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. Z.B. der danfoss könnte das mit CLIMATE_CONTROL_SCHEDULE auch können (? https://community.hubitat.com/t/community-device-drivers-aka-compatible-devices-wiki/465/83)...

Ihr bringt mich noch soweit, dass ich mir beide (und/oder den "Knob" von Fibaro) besorge, nur um zu sehen, ob es geht...

Evtl. habe ich etwas übersehen.

Aber ja, vermutlich übersiehst du nichts, und der Wunsch ist der Vater des Gedankens...

Für's erste wäre es vermutlich schon mal zielführend, das zu implementieren, was wir als "sollte funktionieren" identifiziert haben: Das mit dem externen Thermometer. Den "knob" gibt es btw. auch im Set mit einem Thermometer, der kann das mit dem externen assoziierten Thermometer in jedem Fall auch.