Z-WavePlus Thermostat Eurotronic Spirit: Schrittweise Inbetriebnahme

[krikan]

Erkläre Du mir, wie ich #unknown22 aus ZWave rausbastele.

So kann man "Leichen" entfernen: https://wiki.fhem.de/wiki/Z-Wave#Wie_kann_man_ohne_Exklusion_Nodes_des_Controllers_l.C3.B6schen.3F

Gruß, Christian

[krikan]

Wäre nett, wenn du das template mal ansehen würdest, die configByte-Anweisungen sind ziemlich aus der Hüfte geschossen.

Stolpere mangels attrTemplate-Wissen schon bei den Grundlagen: Wenn ich "Use internal temperature sensor for regulation" nehme wird der Abschnitt "option { 1 }" im Template nicht ausgeführt. Ich hätte erwartet, das auch dies abgearbeitet wird!?

[Beta-User]

Eigentlich sollte das "option:{ 1 }" alles wieder einschalten, so steht es jedenfalls (bis auf die Leerzeichen) hier: https://forum.fhem.de/index.php/topic,99195.msg925952.html#msg925952.

Kann also entweder an den Leerzeichen liegen oder das mit dem Versuch der Addition vorher bringt AttrTemplate.pm aus dem Tritt? Aber normalen Perl-Code haben wir häufiger, v.a. in der speechcontrol.template. Komisch...
Muß ich mir ggf. auch mal live ansehen, habe jetzt auch einen spirit + home-center geschossen .

[curt]

Stolpere mangels attrTemplate-Wissen schon bei den Grundlagen:

Da sind wir schon mal zwei.

Also @Beta-User hatte ja so ein zig-Sensor-Dingens genannt. Das habe ich mal aus Spaß für 55 Euro bestellt - ist aber noch nicht da. Ansich brauche ich den nicht so wirklich, also da kann ich schön rumtesten.

Ich habe -wie schon gesagt- vor, höchstöffentlich in einem neuen Thread das Dingens in Betrieb zu nehmen, mit allen Stolpersteinen ... und Beta-User wirft dann irgendwann ein, was ich mit templates so machen muss. Da ich davon so garnix weiß, darf jeder mitlesen, wie ich da langsam lerne.

Im Grunde entstammt die Idee diesem Thread: Ich dachte an Thermostat, die bisherigen waren alt. Und ich stolperte - und machte genau diesen Thread auf. Und stolperte wieder ... ich denke schon, dass das für spätere Neu-Nutzer erhellend sein kann - aber auch für Profis, so in der Art "ach Jottchen, das war doch eine kleine Hürde, hatte ich das schlecht erklärt?".

[Beta-User]

Da sind wir schon mal zwei.

Na ja, eigentlich ist es - zumindest hinsichtlich der Sachen, die man als Anwender zu sehen bekommt - meistens nicht sooo schwierig, zum anderen gibt es (etwas) Doku und ziemlich viele Beispiele . (Sicher, das richtige Beispiel für den konkreten Fall zu finden ist nicht immer einfach).

ABER: hier liegt vermutlich ein Denkfehler vor, den ich auch erst mal übersehen habe:
Das Problem dürfte  nicht aus dieser Zeile mit "option" kommen, sondern entsteht davor. AttrTemplate bricht nämlich ab, wenn eine Anweisung nicht ausgeführt werden kann.
@krikan: Es wäre daher interessant, an welcher Stelle das genau war, falls sich das feststellen läßt?

An sich brauche ich den nicht so wirklich, also da kann ich schön rumtesten.

Der Ansatz gefällt mir. Hoffe, dass wir das eine oder andere "ach Jottchen" für die Zukunft sparen können, wenn wir erst mal eine "gemeinsame" Sprache sprechen und das ganze dann "aufzeichnen" können . (Aber klar, ich übersehe auch immer mal wieder was, und dann braucht's halt eine Schleife mehr. Von daher schon mal Danke vorab für eure Geduld!)

[krikan]

Es wäre daher interessant, an welcher Stelle das genau war, falls sich das feststellen läßt?

Das ist (vermutlich) der letzte Befehl der ausgeführt wird:

deleteattr DEVICE setList

Selbst im global-verbose 5-Log habe ich gestern aber keinen Fehler/Problem gesehen. Der "deleteattr DEVICE setList"-Befehl wurde in der Kommandozeile ohne Fehler geschluckt.
Wenn Du nichts auf Anhieb siehst, müsste ich noch einmal mit einer sauberen minimal FHEM-Installation testen.

[Beta-User]

Das klingt plausibel, dass es diese Zeile(n) ist/sind...

Wir hatten mal was ähnliches bei deletereading@mqtt2, seitdem gibt es da den "-q"-Aufruf, wenn ich das richtig im Kopf habe (das Problem war wohl, dass da irgendwas zurückkommt, in diesen Fall hier vermutlich die Meldung, dass es das Attribut nicht gibt oder dass es gelöscht wurde).

Hier bin ich noch nicht sicher, ob das mit dem deleteattr "die" Lösung ist. Die Rationale dahinter war, Fehlermeldungen im laufenden Betrieb zu erzeugen, wenn der User z.B. dann noch eine Routine am Laufen hat, die den "virtuellen Kanal" befüllt und deswegen glaubt, die Steuerung liefe über diesen Kanal.

Für's weitere Testen bitte die fraglichen Zeilen mal auskommentieren und dann ein AttrTemplate_Initialize() ausführen, ich werde das bei Gelegenheit auch im svn anpassen, bis klarer ist, ob obiger Gedankengang überhaupt zielführend ist oder ggf. besser einfach ein passendes farewell angesagt wäre (das geht aber nur einheitlich und erfordert daher ein gewisses "Mitdenken" seitens des Users).

[Beta-User]

Vielleicht auch noch zu dem hier aus dem list im Parallel-Thread:

Code Auswählen Erweitern

   stateFormat {
sprintf(
        "Ist: %.1f Soll: %.1f Ventil: %d %% Mode: %s %s",
        ReadingsVal($name,"temperature",0),
        ReadingsVal($name,"desiredTemp",0),
        ReadingsVal($name,"valve",0),
        ReadingsVal($name,"thermostatMode",0),
        ReadingsVal($name,"transmit",0)
    )
}
   userReadings valve { my @values = split / /, ReadingsVal("$name","reportedState",0);;;; if ($values[1]) { $values[1] } else { return "0" } }, desiredTemp { my @values = split / /, ReadingsVal("$name","setpointTemp",0);;;; $values[0] }

Da hätte ich auf der vorhandenen Basis erst mal folgende Verbesserungsvorschläge, die die Error-Einträge im Log beseitigen sollten:

Code Auswählen Erweitern


   stateFormat {
sprintf(
        "Ist: %.1f Soll: %.1f Ventil: %d %% Mode: %s %s",
        ReadingsNum($name,"temperature",0),
        ReadingsNum($name,"desiredTemp",0),
        ReadingsNum($name,"valve",0),
        ReadingsVal($name,"thermostatMode",0),
        ReadingsVal($name,"transmit",0)
    )
}
   userReadings valve:reportedState.* { ReadingsNum("$name","reportedState",0) }, desiredTemp:setpointTemp.* { ReadingsNum("$name","setpointTemp",0)}

Zwei weitergehende Fragen (auch an die Experten und fortgeschritteneren User hier):
- zum einen irritiert mich der Dualismus von desiredTemp und setpointTemp. Wäre das nicht (in Teilen) eleganter durch eventMap zu lösen, also setpointTemp:desiredTemp? (oder kommt einem da die Einheit in die Quere? Überhaupt: das mit den Einheiten macht mich unruhig...)

- Ggf. könnte man ohne weiteres nicht nur für Rollläden und Jalousien, sondern auch für Thermostate wie diese hier über die myUtils-File (ggf. mehrere) Varianten von devStateIcon- oder stateFormat-Code anbieten (via Parameter umstellbar). Was da in dem Screenshot vom 10. zu sehen war, ist eigentlich devStateIconCode und ab hier zu finden: https://github.com/rejoe2/FHEM/blob/master/99_myUtils_Homematic.pm#L53.
(Klar, das ist für Perl-Einsteiger kein wirkliches Lernfeld mehr).

EDIT: grade gesehen, dass an dem anderen screenshot der in dem anderen Beitrag eigentlich interessante Teil fehlt, warum auch immer. Hier daher noch "das volle Bild"...

[krikan]

Das klingt plausibel, dass es diese Zeile(n) ist/sind...
[..]
Für's weitere Testen bitte die fraglichen Zeilen mal a[uskommentieren und dann ein AttrTemplate_Initialize() ausführen, ich werde das bei Gelegenheit auch im svn anpassen, bis klarer ist, ob obiger Gedankengang überhaupt zielführend ist oder ggf. besser einfach ein passendes farewell angesagt wäre (das geht aber nur einheitlich und erfordert daher ein gewisses "Mitdenken" seitens des Users).

Habe mal die deleteattr-Zeile entfernt. Jetzt bildet der letzte configByte-Befehl das Ende der abgesetzten Befehle. Alles unter option { 1 } wird weiterhin nicht ausgewertet. Irgendwie ist die Suche ziemlich ermüdend, da ich keine Ahnung habe, wie ich ohne zusätzliche Log-Ausgaben in FHEM weiteranalysieren kann...

[curt]

Vielleicht auch noch zu dem hier aus dem list im Parallel-Thread:

Gefährlich - das hätte ich fast überlesen ... weil versteckt.

Da hätte ich auf der vorhandenen Basis erst mal folgende Verbesserungsvorschläge, die die Error-Einträge im Log beseitigen sollten:

Danke dafür.
Der Codevorschlag kam von @rcmcronny und ich war heilfroh, mal einen Anfang zu haben. Möglicherweise hatte sich Ronny das auch nur aus Forum-Versatzstücken genommen - ich weiß es nicht.

Zwei weitergehende Fragen (auch an die Experten und fortgeschritteneren User hier):
- zum einen irritiert mich der Dualismus von desiredTemp und setpointTemp.

desiredTemp ist auch von Ronny. Die Namenswahl ist hochgefährlich, da es ja auch noch das originäre desired-temp gibt, das ist mir durchaus klar. Ich hatte das 1:1 übernommen.

Wo taucht vor Schreck setpointTemp auf?

Wäre das nicht (in Teilen) eleganter durch eventMap zu lösen, also setpointTemp:desiredTemp? (oder kommt einem da die Einheit in die Quere?

Du redest mit einem Anfänger ... ich müsste nun nachlesen, was wieder ein eventMap sein soll. Ok, mal andersrum: Vielleicht ist es klug, wirklich eine (mehrere?) Beispielkonfiguration zu finden und auch zu präsentieren.

Überhaupt: das mit den Einheiten macht mich unruhig...)

Auf den ersten Blick geht das gut. Auf den zweiten Blick habe ich ab und an insb. im Zusammenspiel mit FTUI Seiteneffekte, die ich mir noch nicht erklären kann.

Warte, wird noch härter - lies das jetzt genau!
Der Thermostat gibt Dir keine Rückmeldung! Nie!

Du stellst beispielsweise den Sollwert um. Oder das Heizregime. Nun glaub mal nicht, dass das irgendwie in FHEM ankommt!

Sondern Du musst -hier kommen wieder Ronnys Erfahrungen ins Spiel- das eigentliche Kommando zweimal mit Zeitverzug (sleep 3) absenden, danach mit weiterem Zeitverzug abfragen, ob die Änderung ankam - damit wird dann FHEM vom neuen Status in Kenntnis gesetzt.

Ich hoffe, ich konnte das verständlich beschreiben.

[Beta-User]

Irgendwie ist die Suche ziemlich ermüdend, da ich keine Ahnung habe, wie ich ohne zusätzliche Log-Ausgaben in FHEM weiteranalysieren kann...

Sorry dafür, ich sehe das Problem im Moment auch nicht.
Jetzt warte ich mal, bis mein Spirit eintrifft und teste das selbst auch aus...
Ein kleines update (mit "global") ist jetzt zwar im svn, aber das war nur Kosmetik, weil ich wegen des zigbee2mqtt-Bruders sowieso was einchecken wollte.

@curt:
Sorry für "versteckt", aber bevor ich keine eigene Hardware habe, macht es keinen Sinn, über Hardwarespezifische Probleme zu diskutieren.
Dass da Teile nur auf explizite (mehrfache) Anforderung zurückkommen, war mir in dem Moment nicht präsent.

Nicht alles, was ich hier schreibe, gilt direkt dir, v.a. das mit eventMap war eigentlich eher in Richtung Rudi+krikan gerichtet. "Eigentlich" wäre ich der Ansicht, dass Rückmeldungen zu Datenpunkten (die Benennung war aus dem userReadings abgeleitet!) auch auf allen Readings landen, von denen ggf. die Anweisungen kommen, sonst ist der "Kreis" nicht sauber geschlossen. Sowas müßte man aber tendenziell innerhalb des Modulcodes fixen und nicht durch ein angeflanschtes (und hier auch noch unsauber getriggertes) Stück User-Code. Kann aber sein, dass ich mir damit ein Eigentor schieße, weil z.B. der auf Jalousie-Modus umgestellte FGR-223 uU. dann doch einen geringfügig vom gesetzten Wert abweichenden Endwert zurückgibt (was AutoShuttersControl nun wiederum gar nicht mag...)

Genauso ist das mit dem Einheiten-Thema. Das ist eigentlich ein "globales Developer-Ding" (=> Adressaten sind eher wieder Rudi und krikan), zu dem es keine wirklich befriedigende Lösung zu geben scheint (ich bin da aber auch nicht wirklich tief in der Materie drin).

Zurück zu dem mit den fehlenden Rückmeldungen (auch wieder eher in Developer-Richtung):
Wissen wir denn, zu welcher Nachricht ein "ACK" gehört (die Zeit bis zur Zustellung wird ja gemessen, also ist der Link vohanden, oder? Wäre es dann nicht sinnvoll, den Wert auch als "gesetzt" zu behandeln? (vermutlich gibt es dazu schon seitenweise Diskussionen und das hätte unangenehme Nebenwirkungen?)...

[krikan]

Sorry dafür, ich sehe das Problem im Moment auch nicht.

Ist ja nicht deine Schuld. Ich ärgere mich, dass ich das Problem hier nicht finde. Bin aber momentan zu faul mit cleanroom-FHEM-Installation zu testen. Sehe zwar (immer noch) keinen Einfluss meiner Installation auf attrTemplate, aber vielleicht liege ich falsch.
Andererseits, wenn attrTemplate Einsteigern helfen soll, muss doch bei einem Problem ein deutlicher Hinweis auftauchen bzw auffindbar sein.  Den finde ich nicht. 

[rudolfkoenig]

wird der Abschnitt "option { 1 }" im Template nicht ausgeführt. Ich hätte erwartet, das auch dies abgearbeitet wird!?

Es muss option:{1} heissen (Achtung auf dem Doppelpunkt), und vor/nach {} darf kein Leerzeichen/tab/etc sein. Da sowas in den Templates ofters der Fall ist, habe ich AttrTemplate.pm modifiziert, und Space ausserhalb von {} erlaubt. Der Doppelpunkt bleibt.

irritiert mich der Dualismus von desiredTemp und setpointTemp.

setPointTemp kam mit dem Patch rein, und ich habe nicht naeher nachgedacht, weiterhin ist setpointTemp natuerlich, wenn man die ZWave Doku in Code umwandelt.
desired-temp (desiredTemp kenne ich nicht) wird auch von anderen Modulen (z-Bsp. FHT) verwendet, und hatte eine Sonderbehandlung in FHEMWEB (falls vorhanden, wird prominent angezeigt). Diese Sonderbehandlung ist jetzt zwar weg, die desired-temp Einfuehrung war aber davor.

Wissen wir denn, zu welcher Nachricht ein "ACK" gehört.

Jein. Ich weiss, zu welcher Hex-Befelsfolge ein ACK gehoert, nicht aber zu welchem lesbaren FHEM-Befehl.
Eine "parse"-Routine haben wir nicht fuer jedes ZWave-Befehl, eine Alternative waere das Originalbefehl irgendwie mit diesem Hex-Sendstack zu verlinken. Bleibt noch die Aufgabe, Zwischenbefehle (z.Bsp. bei Security), die get Anfrage selbst, und evtl. noch andere Sonderbefehle auszusortieren.
Und zu entscheiden, ob das ACK auch ein Event ausloesen soll, oder nicht.
Und die Events alle umbauen, zuerst set_on, und dann on.
Und vmtl per Attribut aktivierbar, damit es kompatibel bleibt.

Andererseits, wenn attrTemplate Einsteigern helfen soll, muss doch bei einem Problem ein deutlicher Hinweis auftauchen bzw auffindbar sein.  Den finde ich nicht. 

Kannst du bitte das Problem mir nachstellbar beschreiben?
Egal wie kaputt ich option hinschreibe, ich kriege entweder eine Fehlermeldung im Log, oder Fehlermeldung als Ergebnis von "set attrTemplate".

[krikan]

Kannst du bitte das Problem mir nachstellbar beschreiben?
Egal wie kaputt ich option hinschreibe, ich kriege entweder eine Fehlermeldung im Log, oder Fehlermeldung als Ergebnis von "set attrTemplate".

Wenn ich mit der Fassung https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/AttrTemplate/zwave.template?rev=22968 und per update aktualisiertem FHEM teste, bekomme ich nirgends eine Fehlermeldung. Aufgerufen habe ich set-attrTemplate "Eurotronic_Spirit" über die Detailansicht des FHEM-Devices über Auswahl in der Box und dann per Ok die vorgegebene Auswahl bestätigen. Browser ist Firefox 81.0.2 unter Windows.

[rudolfkoenig]

Mit der alten Version von AttrTemplate und dem alten zwave.template gibt es "nur" eine Fehlermeldung im FHEM-Log:

2020.10.18 11:11:39.411 1: PERL WARNING: Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.32), passed through in regex; marked by <-- HERE in m/^({ <-- HERE  1 }  )$/ at fhem.pl line 1331.

Mit der aktuellen AttrTemplate und oder zwave.template gibt es keine Fehlermeldungen.

Ich habe AttrTemplate um debug-Ausgaben erweitert, um sie zu sehen muss man "attr device verbose 5 setzen".