Z-WavePlus Thermostat Eurotronic Spirit: Schrittweise Inbetriebnahme

Beta-User · 22 September 2020, 07:39:18

Mit DOIF tue ich mich auch schwer, aber es verhält sich nach meiner Kenntnis hinsichtlich der meisten FHEMWEB-bezogenen Attribute wie dummy (hier: die letzten drei); da gibt es eine Doku dazu, die hier zu finden ist: https://wiki.fhem.de/wiki/FHEMWEB/Widgets (MQTT2_DEVICE ist ein naher Verwandter dazu, falls du das kennst).
Das konkrete DOIF scheint einfach nur ein erweiterter dummy zu sein mit der Möglichkeit der automatischen Übernahme aus einem übergeordneten Device namens "Wunschtemp_temp_eg_kue", falls da was gesetzt wird - Freunde alternativer Varianten würden vermutlich structure für diese übergeordnete Ebene verwenden. (Falls ich da was falsch verstanden haben sollte, bitte um Rückmeldung).

Mein Verständnis des Aktors:
- auto ist "Tagtemperatur" als Zielwert, energysave... ist Nachtabsenkung (irgendwo müßte man die entsprechenden Werte setzen können).
- Cooling kehrt das Verhalten um, es wird ein kaltes Medium "verwaltet", je höher die Temperaturabweichung nach oben, desto mehr macht er das Ventil auf (also SOLL = 22°, IST = 23° bei tendenziell fallender IST-Temp => Ventil schließen; IST = 28° bei tendenziell steigender IST-Temp => Ventil aufdrehen...)

Was die Frage der Inclusion angeht:
Mein Verständnis bisher war, dass FHEM das Modell kennen muß, dann ergeben sich setter und getter aus den XML-files. Kann dauern, bis das da ist, aber wenn, dann ist auch alles auf einmal da (bis auf wirklich sehr grundlegende "basics", (um an die Modell-Infos zu kommen, z.B.).
Wenn da also was fehlt, muß man erst mal sicherstellen, dass dieser grundlegende Vorgang abgeschlossen ist, vorher bringt alles andere nichts. Diese "Grundregel" muß man bei ZWave (wie auch anderswo - es macht auch bei CUL_HM keinen Sinn weiterzumachen, wenn die "pairCentral" auf "set_.*" steht) kennen und dann ggf. manuell die Modellanfrage so lange wiederholen (aber bitte nicht zu früh...), bis es geklappt hat.

Die weitere Ebene - Attribute - sind dann eigentlich ganz überwiegend Sache des Benutzers, und es kann in der Tat sein, dass man beim "attrTemplate"-Weg ggf. auch zweistufig vorgehen muß. Wie ziemlich vorne erwähnt, ist das ganze bei weitem noch nicht ausgegoren, es geht (mir) eher darum rauszufinden, was überhaupt sinnvoll wäre und wie man das ggf. organisiert.

Welche Elemente beim Thema Heizungssteuerung zusammenwirken, haben wir m.E. alle halbwegs verinnerlicht. Was deine konkrete Situation angeht, ist die grundsätzliche Frage, was dir Thermostate überhaupt bringen, da das ganze System (bei geschlossenen Türen und Fenstern) sowieso ziemlich träge sein dürfte. (OK, Nebenräume gesondert zu behandeln und "Sitztemperaturen" im Wohnzimmer für die bessere Hälfte zu ermöglichen macht schon auch aus meiner Sicht Sinn).

rudolfkoenig · 22 September 2020, 08:54:11

ZitatMein Verständnis bisher war, dass FHEM das Modell kennen muß, dann ergeben sich setter und getter aus den XML-files

Bei der Inclusion sendet das ZWave Geraet ein sog. NIF Paket, was im wesentlichen eine Liste der unterstuetzten sog. Command-Classes ist. Diese Liste definiert die Liste der auf dem Geraet implementierten get/set Befehle. FHEM setzt daraufhin die im ZWave.pm je Klasse konfigurierte init Befehle ab, wie "set associationAdd 1 dongleId" wenn ASSOCIATION da ist, oder "get model", wenn MANUFATURER_SPECIFIC vorhanden ist.

Wenn man _danach_ ueber die Modeldaten verfuegt, die CONFIGURATION Klasse verfuegbar ist und im XML dieses Model beschrieben ist, dann stehen zusaetzlich zu configByte/configWord noch weitere config* Befehle zur Verfuegung, um das Lesen des Beipackzettels zu sparen => Auch ohne XML ist eine vollstaendige Bedienung oder Konfiguration moeglich.

Feinheiten:
- Je nach Inklusionsart ("Normal" oder Secure) melden bestimmte Geraete eine unterschiedliche Command-Class Liste im NIF, z.Bsp. um das Tueroeffnen nur bei Secure-Inklusion zu ermoeglichen.
- Jedes Geraet kann jeweils alle Klassen in unterschiedlichen Versionen implementieren, siehe get versionClass, bzw. das vclasses Attribut. Je nach Version gibt es zusaetzliche Befehle, oder weitere Parameter fuer ein Befehl. Z.Bsp. gibt es on-for-timer fuer SWITCH_BINARY erst ab Version 2, was wiederum kaum jemand implementiert, ich kenne nur Geraete mit Version 1.

krikan · 22 September 2020, 10:42:38

Vereinfacht aus meiner Anwendersicht: FHEM bietet immer alle setter/getter an, die es für die jeweilige Command Class und Version kennt. FHEM überprüft nicht, ob das Gerät diese Befehle tatsächlich komplett oder ggf. nur teilweise unterstützt oder sogar gar nicht. (Das habe ich bisher in https://wiki.fhem.de/wiki/Z-Wave nicht festgehalten.)

Man könnte von Zwave-Geräten abfragen, welche Befehle der gemeldeten Command Classes sie unterstützen ("Interview") und das in FHEM entsprechend ein- und ausblenden. Das ist aber erheblicher (Programmier-)aufwand und führt zu neuen Problemen und geräteindividuellem Anpassungsbedarf bspw. aufgrund von Fehlern in der Gerätefirmware. Wenn man sich in den Foren bspw. von z-way, das das Interview nutzt, umsieht dann findet man manchmal die Hinweise auf Nicht-Nutzbarkeit von Gerät XY wegen gescheiterten Interviews oder Anpassungbedarf wegen Firmwarefehlern. Diese Problemquelle gibt es aufgrund Rudis Designentscheidung (kein Interview) nicht. Dafür erfordert es mehr Anwendereingriff/-nachdenken. Persönlich bevorzuge ich Rudis Designentscheidung, auch wenn das manches auf den Anwender verlangert.

Welche Betriebeinstellung das/mein Spirit unterstützt habe ich damals (2018?) in https://wiki.fhem.de/wiki/Z-Wave-Eurotronic_Spirit_Thermostat#Betriebsmodi mit den Hinweis auf die nicht unterstützten Einstellung und Anzeige in FHEM kurz aufgeschrieben. Ob ich dabei ein Fehler gemacht habe, kann ich in den nächsten Tagen mangels Zugriff auf das Spirit nicht prüfen. Es passt aber zum Handbuch.
Vom Gerät selbst kann man das mit dem bisher nicht in FHEM implementierten Befehl "Thermostat Mode Supported Get Command" (0x04) der Command Class THERMOSTAT_MODE (0x40) durch Auswertung der darauf erfolgenden Antwort/Report "Thermostat Mode Supported Report Command" ermitteln. Natürlich nur, wenn das in der Gerätefirmware fehlerfrei eingebaut ist.

Gruß, Christian

rudolfkoenig · 22 September 2020, 11:14:47

ZitatMan könnte von Zwave-Geräten abfragen, welche Befehle der gemeldeten Command Classes sie unterstützen ("Interview")

Kannst du bitte andeuten, wie das erfolgt?
Ich fuerchte meine "Designentscheidung" war einfach Unwissenheit

krikan · 22 September 2020, 13:54:40

Zitat von: rudolfkoenig am 22 September 2020, 11:14:47
Kannst du bitte andeuten, wie das erfolgt?

Für jede vom Gerät unterstützte Command Class (CC) wird/werden die von CC und CC-Version abhängige(n) SupportedGet-Abfrage(n) an das Gerät abgesetzt und die zugehörige SupportedReport-Antwort(en) vom Gerät zurückgeliefert. In den CC Specs gibt es dazu jeweils bei (fast) jeder Command Class eine Info und auch "irgendwo" eine allgemeine Ausführung in den Specs. Paetz hat das Thema anwendertauglich in einem Kapitel seines Buches untergebracht.

Teilweise gibt es in FHEM auch schon die für das Interview erforderlichen SupportedGet-Abfragen; nur eben keine automatische Auswertung der Folgen.

Um das Interview möglichst ordentlich durchlaufen zu lassen, ist -grobe Erinnerung- dann bei der Ermittlung der Command Class neben dem NIF zunächst die https://www.silabs.com/documents/public/miscellaneous/SDS10242-Z-Wave-Device-Class-Specification.pdf zu berücksichtigen. ozw macht das so, wir/Du hatten damals entschieden das aus Vereinfachungsgründen nicht in FHEM zu implementieren. Details und ob das wirklich wichtig ist, müsste ich mir noch anschauen, falls von Interesse.

Bezogen auf Spirit:
Die Antwort "Thermostat Mode Supported Report Command" (0x05) auf "Thermostat Mode Supported Get Command" (0x04) sollte nur die in der Tabelle https://wiki.fhem.de/wiki/Z-Wave-Eurotronic_Spirit_Thermostat#Betriebsmodi genannten Betriebseinstellungen zurückliefern. tmCooling, tmAuto, tmFan müssten fehlen und daraufhin die zugehörigen Befehle bzw. Einstellungsmöglichkeiten nicht mehr angeboten werden.

Gruß, Christian

Beta-User · 22 September 2020, 15:30:48

Klingt alles auch interessant, aber tendenziell ist das hier der falsche Thread, oder?

Demnach hätte man Inclusion/NIF, danach (wiederholbares, erstmalig automatisch ausgeführtes?) Interview für die generelle Nachoptimierung und dann die Userkonfiguration (ggf. unterstützt durch attrTemplate)...

Bisschen OT: Was mir hier (wie auch in Homematic, da hatte ich mal eine ähnliche Diskussion mit martinp876) irritiert ist, dass Teile der Konfiguration, die der User eigentlich nicht beeinflussen können soll, meinem Bauchgefühl nach "falsch" abgelegt werden... In HM als Attribute (allen voran: Model), in ZWave als Readings (model.*). "Eigentlich" gehört sowas mMn. eher in die Konfiguration (=>Attribut), aber eben als (aus Usersicht "Readonly Attribut", als (im Wesentlichen nicht direkt dem Userzugriff direkt zugänglicher) Mechanismus ist daher Reading eigentlich besser; das hat aber was "flüchtiges". Wie dem auch sei, martinp876 hat da (mMn.) sehr spezielle Startmechanismen entwickelt, um da irgendwie eine Art workaround zu haben, damit am Ende alles (seiner Meinung nach) "betriebsbereit'" ist...
(Generell ist es gar nicht so einfach, die Erstinitialisierung eines (auch) von Attributen abhängigen Gerätes "sauber" zu gestalten, das ist mir erst gestern wieder beim Umbau von Twilight "auf die Füße gefallen" (no action required)).

Zitat von: krikan am 22 September 2020, 13:54:40
Bezogen auf Spirit:
Die Antwort "Thermostat Mode Supported Report Command" (0x05) auf "Thermostat Mode Supported Get Command" (0x04) sollte nur die in der Tabelle https://wiki.fhem.de/wiki/Z-Wave-Eurotronic_Spirit_Thermostat#Betriebsmodi genannten Betriebseinstellungen zurückliefern. tmCooling, tmAuto, tmFan müssten fehlen und daraufhin die zugehörigen Befehle bzw. Einstellungsmöglichkeiten nicht mehr angeboten werden.

Das klingt auf alle Fälle einleuchtend und auch wieder (in Teilen) on topic...

rudolfkoenig · 22 September 2020, 16:56:38

@krikan: Danke fuer die Erklaerung, ich bleibe bei dann weiterhin bei der "Designentscheidung". Je weniger Funkverkehr, desto weniger kann schiefgehen.

Deckoffizier · 22 September 2020, 18:09:13

Hallo curt,

ZitatNein, wir sprechen über den im Subject angegebenen Thermostat. (Ich vermute aber, dass Deckoffizier einen anderen Thermostaten am Start hat.)

Da vermutest Du falsch, es sind die gleichen Spirit wie von Deinem Amazon Link wo ich auch schon bestellt hatte.
Jetzt nicht sicher, habe ich nicht schon ein List vom Spirit hier eingestellt unter Modell müsste alles vergleichbar sein.

@All nehmt es mir nicht übel, lest Ihr den Beipackzettel, Bedienungsanleitung nicht? da sind die einzelnen Thermostat Modi
erklärt, denke mal Beta-User hat es soweit gut getroffen.
Kleiner Hinweis für PID20 Nutzer max Ventilöffnung ist 99 als attr.

@curt

ZitatBei der konkreten Heizung wird sowohl die Außentemperatur als auch die Innentemperatur des größten Hauses als Regelgrößen genommen. Wer es in so einer Konstellation noch nicht wusste, der lernt es dann: Da ist mit einfacher Ganglinie nichts mal einfach zu machen.

Eventuell vertan meintest Du vielleicht größten Raum?
Ist bei Dir Ganglinie=Heizkennlinie für den Vorlauf.

An der Heizkennlinie haben sich schon Generationen von Heizungsbauern versucht und habe an meinem
Kesselschaltfeld(Holzvergaser+Ölheizung+Mischer) auch eine Weile gebraucht um möglichst geringe Vorlauftemperatur in allen Lagen hinzu bekommen.
Heizungsbauer stellen gerne mal auf Sibirien ein und Tschüss

Zum Multisensor Bild im Anhang....

hier noch die 2 fehlenden DOIF um alles komplett zu machen

1)NAME wunschtemp_kueche_check1

Code Auswählen

##soll beim auslösen vom weekdaytimer  eventuelle manuelle
## vorherige temp Anzeige(Änderung) zurücksetzen
([wdtimer_kueche])
(setstate eg_kue_wunschtemp Manuell inaktiv,
setreading eg_kue_wunschtemp mantemp 0,
set eg_kue_wunschtemp mantemp 0)

2) NAME wunschtemp_kueche_check2

Code Auswählen

## zeitweises ändern der wunschtemperatur nur bei fenster zu
## mit setzen des Regler und Anzeige
([eg_kue_wunschtemp:mantemp:d] > 0 and [?TK_EG_Kueche:state] eq "Closed")
(set KUECHE_ZW_THERMOSTAT protectionOff,
set KUECHE_ZW_THERMOSTAT tmManual,
setstate eg_kue_wunschtemp  Manuell aktiv)
({my $neuer_wert = ReadingsVal("eg_kue_wunschtemp","mantemp","0");; fhem("set pidregler_kueche desired $neuer_wert")})
({my $neuer_wert = ReadingsVal("eg_kue_wunschtemp","mantemp","0");; fhem("setreading eg_kue_wunschtemp mantemp $neuer_wert")})
({my $neuer_wert = ReadingsVal("eg_kue_wunschtemp","mantemp","0");; fhem("set eg_kue_wunschtemp mantemp $neuer_wert")})

Gruß
Hans-Jürgen

curt · 23 September 2020, 01:29:57

Zitat von: krikan am 22 September 2020, 13:54:40
Bezogen auf Spirit:
Die Antwort "Thermostat Mode Supported Report Command" (0x05) auf "Thermostat Mode Supported Get Command" (0x04) sollte nur die in der Tabelle https://wiki.fhem.de/wiki/Z-Wave-Eurotronic_Spirit_Thermostat#Betriebsmodi genannten Betriebseinstellungen zurückliefern. tmCooling, tmAuto, tmFan müssten fehlen und daraufhin die zugehörigen Befehle bzw. Einstellungsmöglichkeiten nicht mehr angeboten werden.

Zunächst zu den in der Doku für den Thermostat möglichen Modi (cut+paste):

Zitat
0x00 Energy Save Heating Regeln gemäß eingestellter Absenktemperatur
0x0F OFF Heizung aus. 6°C halten
0xF0 Full Power Heating Der Boost Modus wird ausgeführt. Regeln gemäß eingestellter Komforttempe-ratur
0xFE Manufacturer Specific Wechseln in den Stellwerte-Betrieb
0xFF Heating Regeln gemäß eingestellter Komforttemperatur

Kirkan:
Wenn ich in FHEM (Standardoberfläche) auf einen konkreten Thermostaten gehe, wird mir tmCooling, tmAuto, tmFan sehr wohl als mögliches Kommando für "set" angeboten.

@krikan @rudolfkoenig
Eurer eingeschobenen kurzen Diskussion lauschte ich und konnte teilweise folgen; ich fand das nicht offtopic. Mir geht es in gleichem Sinne aber um etwas (teilweise) anderes im Sinne der Nutzerfreundlichkeit bei bzw. direkt nach Inklusion.

Ich hatte öffentlich zugesagt, dass ich
1) meine Konfiguration zeigen (und zur Diskussion stellen) werde
2) meine Wunschvorstellung für Kommandos im Zusammenhang mit erfolgreicher Inklusion vorstellen werde

Zu 2) Im Grunde hatte ich das schon getan, aber wohl zu versteckt. Kommt gelegentlich neu.

Das habe ich nicht vergessen, bin aber zeitlich ein wenig eingespannt.

curt · 23 September 2020, 01:31:55

Zitat von: Deckoffizier am 22 September 2020, 18:09:13
@curt
Eventuell vertan meintest Du vielleicht größten Raum?

Ja, natürlich. Das war gemeint.

Übrigens zu Deinem Foto: Danke für das Zeigen, das ist wirklich eine schicke Idee.

curt · 01 Oktober 2020, 02:06:34

@Deckoffizier

Ok, nochmalige Nachfrage.

Code Auswählen

defmod eg_kue_wunschtemp DOIF ([Wunschtemp_temp_eg_kue])

Soweit ich sehen kann, hast Du Wunschtemp_temp_eg_kue noch nirgendwo gezeigt. Und ohne geht es nun mal nicht.

curt · 01 Oktober 2020, 02:34:31

Freunde des warmen Badezimmers,

Zitat von: rudolfkoenig am 22 September 2020, 08:54:11
FHEM setzt daraufhin die im ZWave.pm je Klasse konfigurierte init Befehle ab, wie "set associationAdd 1 dongleId" wenn ASSOCIATION da ist, oder "get model", wenn MANUFATURER_SPECIFIC vorhanden ist.

Ok, also um "associationAdd" muss ich mich schon mal nicht kümmern.

Zitat von: rudolfkoenig am 22 September 2020, 08:54:11
Wenn man _danach_ ueber die Modeldaten verfuegt, die CONFIGURATION Klasse verfuegbar ist und im XML dieses Model beschrieben ist, dann stehen zusaetzlich zu configByte/configWord noch weitere config* Befehle zur Verfuegung, um das Lesen des Beipackzettels zu sparen [...]

Zitat von: krikan am 22 September 2020, 10:42:38
Vereinfacht aus meiner Anwendersicht: FHEM bietet immer alle setter/getter an, die es für die jeweilige Command Class und Version kennt.

Grau ist alle Theorie.

Wenn ich nichts weiter gemacht hätte, hätte ich wohl noch heute disfunktionale Thermostaten. Und der Kollege mit dem Türschloss aus dem Nachbarthread würde heute noch ohne wichtige Readings dastehen.

Ich kam eher zufällig darauf, es war ein Hinweis von @Beta-User [¹] in völlig anderem Zusammenhang: Ich muss bei jedem Thermostaten händisch folgende Befehle absetzen:

Code Auswählen


    get <device> configAll
    get <device> versionClassAll
    get <device> mcaAll [bei Thermostat nicht vorhanden]
    get <device> wakeupInterval

Erst danach sind wichtige Readings da. Und das betrifft nicht nur die genannten Thermostaten, das betrifft mindestens auch das von einem anderen Nutzer erwähnte Türschloss. (Widerspruch?)

Mir könnte das ja völlig egal sein, meine Thermostaten funktionieren jetzt. Aber ich denke an die, die künftig mal testweise einen Thermostat kaufen, nicht auf den Trick kommen und das Ding entnervt zurückschicken. Es muss ja eigentlich nicht sein, dass nach und nach jeder in die immer gleiche Falle tapst ... manche krabbeln da wieder raus, andere bleiben unten liegen.

Ich rege an, dass diese Befehlskette automatisiert abgearbeitet wird. Zudem rege ich an, dass ein erstes "set ... neighborUpdate" bei dieser Gelegenheit gleich mit abgesetzt wird.

[¹] https://wiki.fhem.de/wiki/Z-Wave#Welche_Infos_sollten_Anfragen_im_ZWave-Forum_enthalten.3F

rudolfkoenig · 01 Oktober 2020, 07:58:50

Diese Befehle sind zum Betrieb nicht notwendig, erzeugen aber eine grosse Menge an Funkverkehr. Das Problem damit ist, dass es dabei leicht zu Problemen kommt: keine Antwort, verstopft manche Controller, stoert andere Teilnehmer, etc.
Die Ausnahme ist versionClassAll: sie wird jetzt schon bei der Inklusion abgesetzt, da etliche Befehle versionsabhaengig sind.

Manche Regeln sind mir selbst nicht ganz klar: neighborUpdate dauert laenger (Minuten?), mW duerfen waehrendessen andere Befehle abgesetzt werden, aber kein weiteres neighborUpdate. Woran ich das Ende vom neighborUpdate erkenne, weiss ich nicht. Eine korrekte Behandlung von neighborUpdate in der aktuellen Warteschlange waere vmtl. nicht trivial.

Die anderen Befehle bei der Inklusion abzusetzen ist aber trivial, wenn die qualifizierte

Mehrheit dafuer ist, mache ich es.
Evtl. ist ein manuell abgesetztes "get allAdditionalInfo" (oder aehnlich) ein Kompromiss.

Beta-User · 01 Oktober 2020, 08:34:56

(Bitte nicht als qualifizierte Antwort werten, ich stehe immer noch vor einem Berg an Fragezeichen und habe auch nicht in den Code geschaut...).

Ein paar Gedanken dazu:
- Funkverkehr vermeiden ist gut, aber grade die Batterie-Geräte haben doch in der Regel gerade bei der Inclusion ein kleines Zeitfenster, in dem sie auf Messages vom Controller warten, oder? Da macht es m.E. viel Sinn, das zu nutzen. Die Frage ist nur wie...

- (ist evtl. sachlich völlig daneben, wenn es gar keine Warteschlage gibt etc.

Das mit den neighborUpdates ist doch mWn. eine spezielle Sache mit "low prio" usw.. Wäre es wirklich ein größerer Aufwand, die Warteschlage (?) dazu je Device separat zu halten oder irgendwo einen Kenner zu setzen, dass schon was läuft (und dazu eine Warteschlage zu generieren, die angeschubst wird, wenn z.B. für 10 Min. keine Meldungen vom vorhergehenden Device eingehen?) Dann könnte man anderes mit höherer Prio raushauen und wüßte ggf. auch, wann man "fertig" ist?

Was die "Lorbeeren" angeht: Das Wiki stammt afaik im Wesentlichen von krikan! (@einen admin/Mod hier: Es würde nur ggf. Sinn machen, hier einen kurzen Hinweis/Link auf den Bereich im Wiki anzupinnen, analog zum MQTT-Bereich?)

Deckoffizier · 01 Oktober 2020, 08:41:50

Hallo curt,

vielleicht fehlt Dir ne Mütze Schlaf

Zitat@Deckoffizier

Ok, nochmalige Nachfrage.

Code: [Auswählen]

defmod eg_kue_wunschtemp DOIF ([Wunschtemp_temp_eg_kue])

Soweit ich sehen kann, hast Du Wunschtemp_temp_eg_kue noch nirgendwo gezeigt. Und ohne geht es nun mal nicht.

Wie kommst Du darauf hast Du es wenigstens mal probiert........

Beta-User hat es Dir doch schon ganz gut erklärt.

Nochmal Auszug aus der DOIF Hilfe

Darstellungselement mit Eingabemöglichkeit im Frontend und Schaltfunktion

Die unter Dummy beschriebenen Attribute readingList und setList stehen auch im DOIF zur Verfügung. Damit wird erreicht, dass DOIF im Web-Frontend als Eingabeelement mit Schaltfunktion dienen kann. Zusätzliche Dummys sind nicht mehr erforderlich. Es können im Attribut setList, die in FHEMWEB angegebenen Modifier des Attributs widgetOverride verwendet werden.

Mach doch einfach den Test mit

defmod blabla DOIF ([halloballo])

Statt Wunschtemp_temp_eg_kue kann da auch x beliebiges stehen.

Gruß
Hans-Jürgen