Hallo Wissende,
die Inklusion ist gescheitert, ich weiß nicht weiter.
Ich habe entsprechend Anleitung die Batterien eingesetzt, danach "set ZWave addNode onNw". Danach am Ventil kurz den mittleren Knopf gedrückt: Er zählt von 120 runter, zeigt irgendwann "22". Danach Ventil angebaut, nochmals den mittleren Knopf gedrückt: Der Motor dreht fröhlich, dann wird "21,5°" angezeigt. Aber leider ist kein Device angelegt. (autocreate ist on).
"get ZWave nodeList" zeigt mir UNKNOWN_21 und UNKNOWN_22. (Leider kann ich nicht sicher sagen, ob die 21 schon vorher da war, wegen eines China-Steckers, der FI-Schutz auslöste möglicherweise.)
Im Wiki steht noch, dass ich "set ZWave createNode 22" ganz schnell nach *** eingeben könnte, ich habe da den mittleren Knopf kurz gedrückt.
Zur Sicherheit: Genau dieses Ventil: https://www.amazon.de/dp/B075X257NC/
Ich weiß nicht weiter: Was kann/muss ich jetzt tun?
P.S: Betreff angepasst
Hallo!
Bitte das Attribut "ignoreTypes" von "autocreate" kontrollieren, ob das die automatische Anlage verhindert.
Gruß, Christian
2020-07-20_22:06:05 ZWave_THERMOSTAT_26 modelId: 0148-0003-0001
2020-07-20_22:06:11 ZWave_THERMOSTAT_26 zwavePlusInfo: version:01
Hallo Christian,
danke für Deinen Hinweis. Es kamen mehrere Punkte zusammen: Die beigelegte Kurzanleitung des Ventils beschreibt die Exklusion faktisch nicht. Im Internet fand ich https://eurotronic.org/wp-content/uploads/2018/08/Spirit_Z-Wave_BAL_web_DE_view_V5.pdf - aber so funktioniert mein Ventil auch nicht. Sondern für Exklusion muss ich einmal (!) etwa 10 Sekunden drücken. Weiterhin war der Abstand offenbar zu groß. Das Ventil ist nun momentan an der Heizung direkt neben dem FHEM-Raspberry, da funktioniert alles, zumindest im Moment.
Darf ich bitte weitere Fragen stellen?
Ich muss das Ventil ja irgendwann an den eigentlichen Heizkörper bauen. Offenbar muss ich laut https://wiki.fhem.de/wiki/Z-Wave dann "set <ZWave-Devicename> neighborUpdate" eingeben. Ich setze da den Devicenamen des Ventils ein? Oder den Devicenamen des ZWave-Gateways?
Ich muss das Rad ja vielleicht nicht neu erfinden: Die Seite https://wiki.fhem.de/wiki/Z-Wave-Eurotronic_Spirit_Thermostat hält sich mit der praktischen Nutzung in FHEM dezent zurück. Könnt ihr mir bitte sagen, wo ich "best practices" finde, also wie ihr das in die FHEM-Oberfläche integriert habt?
tmManual hängt vielleicht damit zusammen? Auch dazu wäre ein Tipp schön.
Ich danke Dir/euch herzlich für eure Hilfe.
Hallo an Alle,
mir geht es genausso. Ich habe 5 Stück Z-WavePlus Thermostat Eurotronic Spirit, sie sind nur zum Teil Ansprechbar von FHEM aber so richtig Bedienen kann ich nicht. Ich meine damit z.B. : die Wunschtemperatur verstellen, Absenken oder Hochheizen von FHEM aus oder Heizungspläne abarbeiten.
Dankeschön für eventuellen Lesestoff.
Hallo FHEM-User22, curt
Zitatmir geht es genausso. Ich habe 5 Stück Z-WavePlus Thermostat Eurotronic Spirit, sie sind nur zum Teil Ansprechbar von FHEM aber so richtig Bedienen kann ich nicht. Ich meine damit z.B. : die Wunschtemperatur verstellen, Absenken oder Hochheizen von FHEM aus oder Heizungspläne abarbeiten.
hmmm also Lesestoff findet Ihr hier im Zwave Bereich genug auch fertige Code Beispiele + Bilder von mir.
Die Spirits funktionieren soweit ganz gut bis auf einen den auf Grund von Softwarefehler ich zurückgeben musste.
Einziges Manko ist das mehr mal weniger Meldungen wie ZWave: No ACK from SZ_ZW_THERMOSTAT after 5s for sentset:1324032601002575
welches aber am funktionieren keine weiteren Auswirkungen hatte.
Gruß
Hans-Jürgen
Hi,
ich hab auch 3 Stück davon, es gibt einen älteren Thread, wo paar Infos enthalten sind:
https://forum.fhem.de/index.php/topic,77598.0.html
Denke das hilft euch weiter. In einigen Punkten ist es etwas speziell, teilweise meldet er keine Temperaturen , Ventilstände usw , je nach Firmwareversion wohl.
Wenn was unklar ist, dann gezielt Fragen, dann kann man sicher eine Lösung finden, die sollte halt dann auch ins Wiki über kurz oder lang :D
Zitat
Darf ich bitte weitere Fragen stellen?
Ich muss das Ventil ja irgendwann an den eigentlichen Heizkörper bauen. Offenbar muss ich laut https://wiki.fhem.de/wiki/Z-Wave dann "set <ZWave-Devicename> neighborUpdate" eingeben. Ich setze da den Devicenamen des Ventils ein? Oder den Devicenamen des ZWave-Gateways?
Hier sollte das Device (aka Thermostat) gemein sein ;)
Ronny
Hallo,
hier noch mal etwas genauer nach etwas mehr Zeit.
https://forum.fhem.de/index.php/topic,105272.msg995598.html#msg995598 (https://forum.fhem.de/index.php/topic,105272.msg995598.html#msg995598)
Gruß
Hans-Jürgen
Ich möchte mich melden um nicht undankbar oder unhöflich zu wirken.
Derzeit steht mein Projekt still.
Das liegt daran, dass der Stift (heißt das so?) meines Ventils (28x1,5) nur 2mm Spiel hat. Im Moment ist unklar, ob der in Rede stehende Thermostat damit überhaupt umgehen kann - das ist beim Hersteller des Thermostats in Klärung: Ich bin ständiger Gast bei deren Service-Mailadresse.
Selbst testen geht bei den Temperaturen schlecht: Die Heizung selbst hat einen primären Außensensor, der derzeit signalisiert, dass im Moment nirgendwo zu heizen ist.
Ich melde mich zu gegebener Zeit zurück.
Zitat von: curt am 29 Juli 2020, 05:38:18
Das liegt daran, dass der Stift (heißt das so?) meines Ventils (28x1,5) nur 2mm Spiel hat.
Ein Heizkörperventil bei dem, bauartbedingt, der Ventilstift nur zwei Millimeter Hub hat ist sehr unwahrscheinlich Im Normalfall beträgt der Hub 5 mm. Oft setzen sich die Ventilstifte bei längerem Stillstand einfach fest. Standard Thermostatköpfe von Danfoss, Heimer usw. kämen mit so einem Heizkörperventil mit 2mm Hub überhaupt nicht zurecht.
Grüße Jörg
Hallo curt,
ZitatDas liegt daran, dass der Stift (heißt das so?) meines Ventils (28x1,5) nur 2mm Spiel hat.
hmm... eventuell Ventilsitz verkalkt? Mal mit der der Zange vor zurück bewegt?
Vielleicht Heizungsbauer befragen, es gibt so eine Art Rohrschleuse womit sich das Ventil ohne große Sauerei wechseln lässt.
ZitatDie Heizung selbst hat einen primären Außensensor, der derzeit signalisiert, dass im Moment nirgendwo zu heizen ist.
Kenne Deine Heizung ja nicht, aber eventuell am Kesselschaltfeld(Reglung) lässt sich da bestimmt auch zeitweise etwas verstellen.
Gruß
Hans-Jürgen
@Deckoffizier
Zitat von: Deckoffizier am 29 Juli 2020, 21:59:15
hmm... eventuell Ventilsitz verkalkt?
Negativ. Das ist so, weil - das muss so.
Zitat von: Deckoffizier am 29 Juli 2020, 21:59:15
Mal mit der der Zange vor zurück bewegt?
Ich bin nicht lebensmüde.
Zitat von: Deckoffizier am 29 Juli 2020, 21:59:15
Vielleicht Heizungsbauer befragen, es gibt so eine Art Rohrschleuse womit sich das Ventil ohne große Sauerei wechseln lässt.
Never touch a running system: Das läuft so seit 22 Jahren, ist ordentlich eingekeimt und daher dicht. Ohne vernünftigen Grund wird da nichts verändert.
Der durchaus freundliche und schnelle Support meint nach vielen Mails und Fotos, dass der Adapter "für ein Comap (Diana) Ventil" (700 100 007) passen würde, den ich in deren Shop bestellen kann - leider sind grad Wartungsarbeiten ... http://shop.eurotronic.org/
Oha, denen ist die Datenbank aber schön abgeschmiert.
Hans-Jürgen,
vielleicht kannst Du mir aber ganz anders helfen:
Den Thermostat habe ich mit einem offensichtlich falschen Adapter an den Heizkörper gebaut, dann angelernt, dann Adaptierungslauf (der halt ins Leere griff). Das ist die Ausgangsbasis.
Nun kommt irgendwann der richtige Adapter, ich werde den anbauen, dann den schon angelernten Thermostaten da ranschrauben. Aaaaaaber ...
Wie überzeuge ich denn den Thermostat zu einem neuen Adaptierungslauf - also ohne Exklusion / neue Inklusion? Wie geht das denn?
Hast Du da mal einen schönen Tipp? Oder kann das jemand anders sagen?
Hallo curt,
na ja verkneife mir lieber weiteren Kommentar auch mit passenden Adapter bei 2mm Ventilhub usw.
Nur soviel, habe bei mir auch einige Adapter in Benutzung.
Zur Adaption, eigentlich müsste Anschrauben und Batterien einlegen reichen.
Gruß
Hans-Jürgen
Zitat von: curt am 29 Juli 2020, 05:38:18
Selbst testen geht bei den Temperaturen schlecht: Die Heizung selbst hat einen primären Außensensor, der derzeit signalisiert, dass im Moment nirgendwo zu heizen ist.
Ich melde mich zu gegebener Zeit zurück.
Hier bin ich wieder: Es ist kühl genug, der Außensensor findet, dass die Heizung heizen darf.
@Deckoffizier @JoWiemann
Nicht alles, was man nicht kennt, gibt es nicht: Meine Ventile haben einen Hub von 2mm. Das ist ein österreichisches Haus, vermutlich war das um 1995 in Österreich so üblich. Das ist aber auch egal: Ich habe nun auch den passenden Adapter, ich kann den Thermostaten steuern - funktioniert gut.
Bei der Stelle
Fenster auf bin ich allerdings blond - ich benötige eure Hilfe:
Ansich eine simple Sache: Wenn das Fenster aufgemacht wird, soll der Thermostat auf 8°C gestellt werden.
define Fenster_Heizung_Gaestezimmer DOIF ([Gaeste_Fenster_Strasse:FensterStatus] eq "open") (set Thermostat_Gaestezimmer desired-temp 8) DOELSE ())
Das tut leider nicht. Was mache ich da falsch?
Ist "eq" an der Stelle richtig? Sind die Anführungsstriche bei "open" korrekt? Oder was ist da falsch an dem Konstrukt?
Hallo curt,
bin zwar nicht blond ;) aber schon grau und in Sachen DOIF
ziemliche Glatze.
Diese Stelle ([Gaeste_Fenster_Strasse:FensterStatus] eq "open") hmm
hast Du ein userReading mit status open ? Dafür auch attr. event on change gesetzt?
Bei mir reicht eigentlich ([fk_bad:"Offen"]) an den Fensterkontakten habe ich ein Eventmap für
open und closed gemacht auf Offen bzw. Geschlossen.
Hier mal mein DOIF für Fenster
Internals:
DEF ## öffnen des Fenster setzt pidregler auf 12 Grad Anzeige auf 12
## Schutz des Thermostat gegen manuelles verstellen
## schliessen des Fenster alles retour
([fk_bad:"Offen"])
(set pidregler_bad desired 12)
(setstate bad_wunschtemp Fenster ist auf,
setreading bad_wunschtemp mantemp 12,
set bad_wunschtemp mantemp 12)
(set Thermostat_Bad protectionOn)
DOELSEIF ([fk_bad:"Geschlossen"])
(set Thermostat_Bad protectionOff)
(setstate bad_wunschtemp Manuell inaktiv,
setreading bad_wunschtemp mantemp 0,
set bad_wunschtemp mantemp 0)
(set pidregler_bad desired [wdtimer_bad:currValue])
und das 2. DOIF
DEF ## verhindert verstellen der Wunschtemperatur bei
## Fenster offen mit Anzeige noch auf
([bad_wunschtemp:mantemp:d] > 12 and [?fk_bad:fenster] ne "closed")
(setstate bad_wunschtemp Fenster noch auf,
set pidregler_bad desired 12,
set bad_wunschtemp mantemp 12)
Vielleicht kannst Du damit etwas anfangen
Gruß
Hans-Jürgen
@Deckoffizier
gestatten an Bord kommen zu dürfen?
Zitat von: Deckoffizier am 05 September 2020, 10:44:11
Dafür auch attr. event on change gesetzt?
Natürlich nicht. Ok, alles neu gebaut.
Aber mit DOIF stehe ich auf Kriegsfuß, ich löse das jetzt mit notify:
define Gaeste_Fenster_Strasse_notify_1 notify Gaeste_Fenster_Strasse:status:.open set Thermostat_Gaestezimmer desired-temp 8
...
define Gaeste_Fenster_Strasse_notify_2 notify Gaeste_Fenster_Strasse:status:.closed set Thermostat_Gaestezimmer desired-temp 17
Zitat von: Deckoffizier am 05 September 2020, 10:44:11
Hier mal mein DOIF für Fenster
Ich habe schon in der anderen Veröffentlichung nicht verstanden, was Du da mit dem Thermostaten treibst. Das liegt vielleicht auch daran, dass nicht auf den ersten Blick erkennbar ist, was da naturgegebene Attribute (usw.) sind und was Du zusätzlich definiert hast. Ok, lass mich mal fragen:
* Was hast Du eigentlich für Thermostaten?
* Du gibst irgendwie Auswahlwerte vor - für das Interface von FHEM?
* Du blockierst händische Verstellung des Thermostaten, wenn das Fenster offen ist - das verstehe ich am wenigsten:
** Bezieht sich das auf die Verstellung bei FHEM?
** Oder auf die Verstellung beim Thermostaten selbst?
* Was hast Du noch für Zauberdinge in Deinem Code versteckt?
Hallo curt,
versuche mal etwas Licht rein zu bringen.
Zitat* Was hast Du eigentlich für Thermostaten?
Betreibe die Fibaro Spirit Thermostate im manuellen Modus.
Zitat* Du blockierst händische Verstellung des Thermostaten, wenn das Fenster offen ist - das verstehe ich am wenigsten:
Eigentlich Art Kindersicherung damit keiner bei offenen Fenster aus Versehen direkt am Thermostaten die Temperatur verstellen kann.
Zitat** Bezieht sich das auf die Verstellung bei FHEM?
** Oder auf die Verstellung beim Thermostaten selbst?
Eigentlich beides, habe noch zwei weitere DOIF es muss ja auch bedacht werden wenn der Weekdaytimer zuschlägt und das Fenster ist gerade offen,
dass der Absenkmodus bei mir 12 Grad erhalten bleibt.
Wenn Du die 2 restlichen DOIF noch sehen möchtest ?
Betone noch mal die Regelung der einzelnen Thermostate(Ventilstellung) läuft über das PID20 FHEM Modul mit Modul Weekdaytimer.
Die Temperaturen kann ich temporär über set List verändern.
Hänge mal 2 Bilder an.
In Punkto Deckoffizier, war damals zufällig bei Niederdeutscher CD hören aufm
Schiff von Schlettwein "die haben aber auch an alles Gedacht" war etwas anderes mit gemeint ;)
Nun ja, würde ich jetzt am liebsten ändern hört sich zu großspurig an, war eben damals aus dem Moment heraus.
Gruß
Hans-Jürgen
Zitat von: Deckoffizier am 08 September 2020, 18:18:11
versuche mal etwas Licht rein zu bringen.
Betreibe die Fibaro Spirit Thermostate im manuellen Modus.
Das ist ZWave-Protokoll? Wie zufrieden bist Du mit den Dingern? Und hast Du da mal einen Kauf-Link, zum Beispiel bei Amazon?
Ich habe hier im Moment 4x Eurotronic Z-Wave Plus https://www.amazon.de/dp/B075X257NC/ und es ist grauselig: Ehe man da einen einzigen angelernt hat, sind Tage vergangen. Und ich weiß nicht, woran das liegt, die werden ständig als UNKNOWN erkannt.
Zitat von: Deckoffizier am 08 September 2020, 18:18:11
Eigentlich Art Kindersicherung damit keiner bei offenen Fenster aus Versehen direkt am Thermostaten die Temperatur verstellen kann.
...
Eigentlich beides
Das Problem bei den Eurotronic Z-Wave Plus Dingern ist, dass man da am Thermostat verstellen kann, aber die Zentrale bekommt davon nichts mit. Also wenn ich das recht verstehe.
Zitat von: Deckoffizier am 08 September 2020, 18:18:11
Wenn Du die 2 restlichen DOIF noch sehen möchtest ?
Im Moment noch nicht. Immer schön schrittweise, ich bin noch sehr am Anfang.
Zitat von: Deckoffizier am 08 September 2020, 18:18:11
Betone noch mal die Regelung der einzelnen Thermostate(Ventilstellung) läuft über das PID20 FHEM Modul mit Modul Weekdaytimer.
Was auch immer ein PID20-Modul ist.
Zitat von: Deckoffizier am 08 September 2020, 18:18:11
Die Temperaturen kann ich temporär über set List verändern.
Hänge mal 2 Bilder an.
Das muss ich mir genauer ansehen.
Sowas ist es vermutlich: Das verstehen der Konzepte - also was Du Dir als Problem gedacht hast - und wie Du das Problem dann löst.
@curt: UU. liegt es an fehlenden Assoziationen, wenn Werte nicht an den Controller gesendet werden (ich kann da aber keine nähere Angaben bzgl. des konkreten Typs machen, das ist nur ein Hinweis auf das allgemeine Verhalten von ZWave).
@deckoffizier:
Zitat...es muss ja auch bedacht werden wenn der Weekdaytimer zuschlägt und das Fenster ist gerade offen,
dass der Absenkmodus bei mir 12 Grad erhalten bleibt.
Der WDT sollte eigentlich über entsprechende "delayed..."-Attribute so eingestellt werden können, dass er erst dann neue Soll-Werte schickt, wenn das/die Fenster zu sind.
@Beta-User
Zitat von: Beta-User am 09 September 2020, 07:40:56
@curt: UU. liegt es an fehlenden Assoziationen, wenn Werte nicht an den Controller gesendet werden
Nein, es liegt daran, dass "attr autocreate ignoreTypes" bei der Inklusion weg muss - und zwar selbst dann, wenn der Device-Typ da gar nicht gefiltert wird. In später Nacht erinnerte ich mich daran, dass mir das eine treue Seele schon mal im Forum schrieb ... auf sowas muss man erstmal kommen.
Aktuell krampfe ich daran, dass der Thermostat (anders als der erste Thermostat) mir kein Reading "temperature" gibt - warum auch immer.
Ich habe ZWave allerdings nicht die Thermostate...
Dennoch möchte ich mich der Aussage von Beta-User noch mal anschließen: bei ZWave hängen Meldungen ans System/Zentrale (und andere "Partner") an den jeweils "eingerichteten" Assoziationen...
Und: autocreate macht das nicht unbedingt immer "richtig" (manchmal zu viel -> mehr Funkverkehr als nötig [hatte ich schon] / manchmal zu wenig [hatte ich noch nicht glaube ich] -> Infos fehlen)...
Evtl. liegt es an eingestellten "Thresholds"!?
Also wann jeweils eine Nachricht geschickt wird.
Gruß, Joachim
Zitat von: MadMax-FHEM am 09 September 2020, 08:45:14
Ich habe ZWave allerdings nicht die Thermostate...
Dann kauf Dir mal einen. Oder soll ich Dir einen leihen?
Du kriegst die Dinger ums Verrecken nicht inkludiert - außer wenn Du tatsächlich das autocreate-Attribut rausnimmst. Ich meine, dass der Tipp (den ich vergessen hatte) von einem anderen heavy-User kam.
(Einzelne) batteriebetriebene Geräte sind nach meiner Erfahrung in fast allen Technologien für Überraschungen und Frust gut...
Vermutlich wäre es zielführend, wenn wir (bzw. Rudi) dazu etwas mehr Infos hätten um zu klären, warum das mit dem autocreate-Ding ein Problem darstellt. Dann bestünde ggf. die Chance, dass nicht wieder jemand in ferner zukunft drüber stolpert.
Was das unterschiedliche Verhalten der bereits inkludierten Geräte angeht, wären vermutlich lists hilfreich, allerdings erst, wenn diverse get-Befehle abgesendet wurden: https://wiki.fhem.de/wiki/Z-Wave#Welche_Infos_sollten_Anfragen_im_ZWave-Forum_enthalten.3F. Irgendwer hatte ja bereits darauf hingewiesen, dass das Verhalten von den Dingern teils unterschiedlich sein kann, wenn die firmware unterschiedlich ist (oder ggf. einfach Assoziations- oder Konfigurationsbefehle nicht angekommen waren).
Leider bin ich in dem ZWave-Thema noch nicht tief genug drin, aber zumindest auf die Schnelle habe ich auch keine Option gefunden, eventuelle Konfigurationsbefehle, die im Rahmen von autocreate bereits abgesetzt wurden (? gibt es die überhaupt?), nochmal vollständig abarbeiten zu lassen. Aber soweit ich das in Erinnerung habe, werden zumindest teilweise (also bei anderen Devices) auch Assoziationen zum IO gesetzt?
Was bei ZWave (zumindest bei den Geräten die ich habe / und nein, brauche/will keine[n] ;) noch bin ich glücklich mit meinen Homematic-Dingern! :) ) dazu kommt ist das "Abrufen" von model und den Assoziationen und den ganzen Dingen, nachdem sie "autom. angelegt" wurden...
D.h. bei mir war noch kein ZWave-Device nach dem "Anlernen" (autom. Anlegen) "vollständig" und "brauchbar"...
Und bei den Batteriebetriebenen kommt dann immer noch das "Aufwecken" dazu, da die meisten ZWave Geräte echt lange Aufweck-Intervalle haben ist das für das Einrichten echt "übel"...
...und wenn verbaut für das "Nachjustieren" auch (z.B. meine schönen Bewegungs-Augen ;) )...
Das ist auch etwas was mich an ZWave "stört", fast alle meine Geräte sehen "minimal" anders aus, obwohl ich versuche immer alles gleich "abzurufen"...
Daher ist ZWave (für mich) (noch) keine Alternative zu Homematic, zumindest noch (lange) nicht bzgl. Heizkörper-/Wandthermostate...
Gruß, Joachim
Falls ich autocreate Probleme debuggen soll, dann brauche ich ein "attr ZWDongle verbose 5" Mitschnitt der fehlgeschlagenen Inklusion.
Am besten mit _zusaetzlichen_(!) "attr global verbose 5".
Sonstige ZWave-Weisheiten, die evtl. nicht jedem klar sind:
- ZWave ist eine Technologie, was von vielen Herstellern implementiert wird.
- die Funktionalitaet wird ueber "Command-Classes" implementiert, jeweils in mehreren Versionen.
- damit ein neues Geraet in FHEM unterstuetzt wird, muss normalerweise nichts in FHEM gemacht werden, da die meisten Klassen implementiert sind.
- das FHEM Modul implementiert nicht alle Klassen in allen Versionen, sondern nach dem Motto: wenn jemand was vermisst, und jemand Zeit hat zu implementieren.
- die FHEM Implementation ist "clean-room", d.h. es entstand aus Doku lesen und reverse-engeneering, und verwendet keine Fermdbibliotheken. Die openzwave Dateien wurden nur fuer Hilfe bzw. Config-Beschreibung einzelner Endgeraete "ausgeliehen", notwendig sind sie nicht.
- autocreate wird ausgeloest, falls ein unbekanntes Geraet ein ZW_APPLICATION_UPDATE Nachricht sendet, das beruehmt beruechtigte "dreimal schnell klicken"
- daraufhin versucht FHEM je nach gemeldeten Klassen weitere Befehle abzusetzen, wie get model, set associationAdd <zwdongleId> 1, usw. Diese Befehle findet man, wenn man im 10_ZWave.pm nach init sucht.
- falls nicht alle init Befehle erfolgreich abgesetzt sind, ist das Geraet unvollstaendig mit FHEM verbunden, und die fehlenden Befehle sollten wiederholt werden.
Hallo curt,
ZitatDu kriegst die Dinger ums Verrecken nicht inkludiert - außer wenn Du tatsächlich das autocreate-Attribut rausnimmst. Ich meine, dass der Tipp (den ich vergessen hatte) von einem anderen heavy-User kam.
Hmm nach meinen Erfahrungen halte ich das für ein Gerücht.
Habe die gleichen Thermostate wie in Deinem Link!
Also autocreate an dann mit addNode onNw am ZWave Dongle und nach Bedienungsanleitung vorgehen klappt
includieren nach Bedienungsanleitung eigentlich bei mir problemlos.
ZitatDas ist ZWave-Protokoll? Wie zufrieden bist Du mit den Dingern? Und hast Du da mal einen Kauf-Link, zum Beispiel bei Amazon?
Hat nix mit ZWave-Protokoll zu tun ist ein Betriebsmodus des Thermostaten wie z.B. Absenkmodus(Energiesparmodus) etc. als Parameter.
Steht auch in der Anleitung.
Ja und ich bin sehr Zufrieden mit den Teilen auch von Amazon.
Das Teil von Danfoss ausprobiert hat mir nicht gefallen und ist etwas eingeschränkt.
Andere Frage, hast Du vielleicht ALLE zur selben Zeit gekauft, das DU zufällig eine Charge erwischt hast wo der Wurm drin ist?
Hatte mal den Fall wo einer von den Spirit mal eine Macke hatte, hat man mir beim Hersteller anstandslos umgetauscht.
Irgendwie schwere Geburt bei Dir, bin jetzt auch überfragt.
ZitatWas auch immer ein PID20-Modul ist.
Hmm Sorry bei über 1000 Beiträge eigentlich aber mal in die commandref schauen oder Tante google mit fhem Wiki PID20
bemühen ?
Falls Dir ein List vom Thermostaten Hilft.....
Internals:
DEF e769ab5c 15
FUUID 5cbcd8b4-f33f-cca1-732b-1801b718d8ff1b40
IODev ZWDongle_0
LASTInputDev ZWDongle_0
MSGCNT 540
NAME Thermostat_Bad
NR 293
STATE dim 0
TYPE ZWave
ZWDongle_0_MSGCNT 540
ZWDongle_0_RAWMSG 00136b000080
ZWDongle_0_TIME 2020-09-09 20:05:52
ZWaveSubDevice no
cmdsPending 0
homeId e769ab5c
isWakeUp
lastMsgSent 1599674751.28657
nodeIdHex 0f
webCmd desired-temp
READINGS:
2020-07-30 17:58:12 SEND_DATA failed:00
2019-09-28 19:45:34 assocGroup_1 Max 1 Nodes ZWDongle_0
2019-09-28 19:45:34 assocGroups 1
2020-09-09 04:48:48 battery 100 %
2020-07-15 00:16:19 batteryLevel 100
2020-09-09 04:48:48 batteryPercent 100
2020-09-09 04:48:48 batteryState ok
2019-09-28 19:45:45 configBacklight BacklightEnabled
2019-09-28 19:45:45 configBatteryReport SendOnceADay
2019-09-28 19:45:45 configLCDInvert Normal
2019-09-28 19:45:45 configLCDTimeout 0
2019-09-28 19:45:45 configMeasuredTemperatureOffset 0
2019-09-28 19:45:45 configOpenWindowDetection Disabled
2019-09-28 19:45:45 configTemperatureReportThreshold 0
2019-09-28 19:45:46 configValveOpeningPercentageReport 0
2019-08-11 21:13:42 fwMd fwMdManId: 0148, fwMdFwId_0: 0301, fwMdChkSum_0: 7f13, fwMdUpgradeable: ff, fwMdNrTarg: 01, fwMdFrqSize: 0028, fwMdFwId_1: 0001
2019-09-28 19:45:15 model EUROtronic EUR_SPIRITZ Wall Radiator Thermostat
2019-09-28 19:45:15 modelConfig eurotronic/eur_spiritz.xml
2019-09-28 19:45:15 modelId 0148-0003-0001
2019-08-05 21:19:01 neighborList Thermostat_Buero fk_ost_buero SZ_DECKE_ZW_DIM WOH_ZW_THERMOSTAT_OST ZWave_SWITCH_BINARY_10 fk_ug_wz Steckd_POPP ZWave_SWITCH_BINARY_16 fk_bad KUECHE_ZW_THERMOSTAT MotionSensor_UG_WZ BUERO_ZW_FK_WEST WZ_ZW_STECKDOSE1 BUE_ZW_STECKDOSE1 Flur_ZW_STECKDOSE1 SZ_ZW_THERMOSTAT SZ_ZW_STECKDOSE1
2020-02-08 17:55:15 neighborUpdate done
2020-05-01 07:39:26 power 0 W
2020-02-23 23:07:23 setpointTemp 18.0 C heating
2020-09-09 20:05:52 state dim 0
2019-08-14 04:34:52 temperature 20.07 C
2019-08-14 08:57:19 thermostatMode manual
2019-08-19 09:10:44 thermostatSetpointSupported heating energySaveHeating
2020-09-09 20:05:52 timeToAck 1.280
2020-09-09 20:05:52 transmit OK
2019-07-20 23:05:03 version Lib 3 Prot 4.61 App 0.16 HW 49 FWCounter 1 FW 0.10
2019-08-11 21:13:23 zwavePlusInfo version:01 role:SleepingListeningSlave node:Z-Wave+Node installerIcon:1200 userIcon:1200
Attributes:
DbLogExclude .*
IODev ZWDongle_0
WNMI_delay 2.0
alias Thermostat Bad
classes ZWAVEPLUS_INFO ASSOCIATION ASSOCIATION_GRP_INFO VERSION MANUFACTURER_SPECIFIC DEVICE_RESET_LOCALLY PROTECTION SENSOR_MULTILEVEL SWITCH_MULTILEVEL THERMOSTAT_MODE THERMOSTAT_SETPOINT BATTERY CONFIGURATION ALARM POWERLEVEL SECURITY SECURITY_S2 TRANSPORT_SERVICE SUPERVISION FIRMWARE_UPDATE_MD
comment 20.02.20 aufladb. Li Akku eingelegt
devStateIcon .*::noFhemwebLink
event-on-change-reading state
group Heizung und Temperatur
icon hc_wht_regler
room Wohnung->Bad,ZWave
sortby 1
stateFormat state
vclasses ALARM:8 ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 BATTERY:1 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:3 MANUFACTURER_SPECIFIC:1 POWERLEVEL:1 PROTECTION:1 SECURITY:1 SECURITY_S2:1 SENSOR_MULTILEVEL:5 SUPERVISION:1 SWITCH_MULTILEVEL:1 THERMOSTAT_MODE:3 THERMOSTAT_SETPOINT:3 TRANSPORT_SERVICE:2 VERSION:2 ZWAVEPLUS_INFO:2
verbose 0
webCmd :Gruß
Hans-Jürgen
Freunde und Mitverschwörer,
zuerst neue Erkenntnisse/Entwicklungen: Die temperature-Rückmeldung war einen Tag später automatisch da.
Die Gattin (Dipl.-Ing. tech.) erfuhr -genauer gesagt gestand ich- von meinem Plan. Ein fröhliches "
NEVER TOUCH A RUNNING SYSTEM", gefolgt von der Drohung "
wenn das schief geht, schläfst Du im Winter im Schuppen!" kam dann noch nach ...
Zitat von: Deckoffizier am 09 September 2020, 20:13:00
ZitatDu kriegst die Dinger ums Verrecken nicht inkludiert - außer wenn Du tatsächlich das autocreate-Attribut rausnimmst. Ich meine, dass der Tipp (den ich vergessen hatte) von einem anderen heavy-User kam.
Hmm nach meinen Erfahrungen halte ich das für ein Gerücht.
Habe die gleichen Thermostate wie in Deinem Link!
Warst Du nicht der, der mir schon erzählte, dass es meine Heizungsventile (2mm Hub) gar nicht gibt? Du, das Verhalten kann ich reproduzieren! Es gibt dort ja zig Möglichkeiten ... eine weitere wäre, dass mein ZWave-Dongle irgendwie anders ist als die anderen Kinder. Wobei - ein freundlicher Nutzer hatte das offensichtlich auch schon - und gab mir ja den Tipp mit autocreate. Ich denke mir sowas doch nicht aus!
(Deine Steuerungskonzepte halte ich für interessant, das ist aber eine weitere Ebene.)
Zitat von: MadMax-FHEM am 09 September 2020, 09:35:44
Daher ist ZWave (für mich) (noch) keine Alternative zu Homematic, zumindest noch (lange) nicht bzgl. Heizkörper-/Wandthermostate...
Bei mir ist es genau umgekehrt: Den Homematic-Thermostaten und diese lustigen Augen habe ich völlig entnervt in die Ecke gepfeffert. Ich finde ZWave sooo schlecht nun nicht: WENN man die Dinger erstmal am Laufen hat, dann tun die.
Halten wir also fest: Heimautomation ist großer Mist. Und die IoT-Gegenstellen sind das Schlimmste, was einem begegnen kann ... von Datenschutz und -sicherheit habe ich noch nicht einmal angefangen. ;) Aber gut - wir haben ja nichts anderes, so gesehen ist es das beste, was wir haben.
Zitat von: Beta-User am 09 September 2020, 09:15:21
(Einzelne) batteriebetriebene Geräte sind nach meiner Erfahrung in fast allen Technologien für Überraschungen und Frust gut...
Da sagst Du was ...
Zitat von: Beta-User am 09 September 2020, 09:15:21
Vermutlich wäre es zielführend, wenn wir (bzw. Rudi) dazu etwas mehr Infos hätten um zu klären, warum das mit dem autocreate-Ding ein Problem darstellt. Dann bestünde ggf. die Chance, dass nicht wieder jemand in ferner zukunft drüber stolpert.
Genau da ist die Falle. Niemand von uns inkludiert täglich 10 Thermostate. Und bei solchen Problemen ist das Frustpotential wirklich hoch: Man hat ja noch keine Erfahrungen ... Wenn ich es nicht vergesse, trage ich das Problem im zuständigen Wiki-Artikel ein.
Zitat von: rudolfkoenig am 09 September 2020, 10:11:54
Falls ich autocreate Probleme debuggen soll, dann brauche ich ein "attr ZWDongle verbose 5" Mitschnitt der fehlgeschlagenen Inklusion. Am besten mit _zusaetzlichen_(!) "attr global verbose 5".
Ich benötige einen weiteren Hinweis.
Ich habe vorhin einen weiteren Thermostaten angelernt, mit beiden unterschiedlichen Bedingungen. Im Log ist recht viel los, auch bei ZWave - hast Du irgend einen Filter (grep), den ich anwenden könnte?
OT: Und damit wir alle was zum Lachen haben: Bei der Gelegenheit (autocreate) hat er mir gleich wieder sämtliche Wetterstationen, Garagensteuerungen, Alarmanlagen aller Nachbarn inkludiert ...
Hallo,
bei mir auch. Die laufen auch 1a, ein paar UserReadings und Doifs rundrum, und die laufen seit >2Jahren nun wie sie sollen ;)
Ronny
ZitatIch habe vorhin einen weiteren Thermostaten angelernt, mit beiden unterschiedlichen Bedingungen. Im Log ist recht viel los, auch bei ZWave - hast Du irgend einen Filter (grep), den ich anwenden könnte?
Ich wuerde nach "UNDEFINED... please define it" suchen, und aus dem FHEM-Log die Zeilen -0.1 bis +1.0 Sekunden ausschneiden.
ZitatOT: Und damit wir alle was zum Lachen haben: Bei der Gelegenheit (autocreate) hat er mir gleich wieder sämtliche Wetterstationen, Garagensteuerungen, Alarmanlagen aller Nachbarn inkludiert ...
Die Loesung dieses Problems ist nicht autocreate abzuschalten, sondern die angelegten Geraete mit dem ignore Attribut zu versehen.
Hallo curt,
ZitatWarst Du nicht der, der mir schon erzählte, dass es meine Heizungsventile (2mm Hub) gar nicht gibt?
WO?
MfG
Hans-Jürgen
Zitat von: rudolfkoenig am 10 September 2020, 09:47:47
Ich wuerde nach "UNDEFINED... please define it" suchen, und aus dem FHEM-Log die Zeilen -0.1 bis +1.0 Sekunden ausschneiden.
Per Mail an Dich versendet.
P.S: @rudolfkoenig
Das Problem ist das Attribut "irgnoreTypes" bei autocreate. (Bei Chargen, die derzeit über Amazon verkauft werden, ist das Problem reproduzierbar.)
Ich habe den Wiki-Artikel https://wiki.fhem.de/wiki/Z-Wave-Eurotronic_Spirit_Thermostat entsprechend angepasst.
Schaut fuer mich so aus, als ob autocreate deaktiviert waere. z.Bsp, weil kein autocreate definiert ist, oder einer der Attribute disable, ignoreTypes oder autocreateThreshold gesetzt ist.
Zitat von: rudolfkoenig am 12 September 2020, 09:20:24
Schaut fuer mich so aus, als ob autocreate deaktiviert waere. [...] ignoreTypes [...] gesetzt ist.
Ja, das habe ich doch gesagt:
ZitatDas Problem ist das Attribut "irgnoreTypes" bei autocreate.
Wir haben entweder ein Missverständnis oder ich habe etwas falsch verstanden, das sollten wir mal genauer aufdröseln:
https://wiki.fhem.de/wiki/Fremdger%C3%A4te_ignorieren erklärt mir unter Pkt. 3, dass ich mir die wirklich großen Mengen der Devices der Nachbarn via "ignoreTypes" vom Hals halten könne. Und wenn es so eine Option gibt, darf man die auch nutzen: Ich ging bis gestern davon aus, dass selbstverständlich die nicht zu ignorierenden Devices dem autocreate unterliegen. Oder liegt hier schon (m)ein Missverständnis, mein Fehler?
Ich kann und will nun nicht ausschließen, dass eine der Filterregeln zuschlägt, obwohl sie das gar nicht soll. Ich sehe in meiner Naivität aber keine derartige Regel - der Einfachheit halber zeige ich mal mein autocreate-Device):
define autocreate autocreate
attr autocreate autosave 0
attr autocreate filelog ./log/%NAME-%Y.log
attr autocreate ignoreTypes TRX_.*|RUBICSON_.*|TFA_.*|VIKING_.*|TH.*|Hideki_.*|IT_.*|BTHR.*|WT.*|SD_.*
attr autocreate room 99 System
Also aus meiner recht naiven Sicht sollte mit genau diesen Regeln eine Inklusion eines "Z-Wave-plus-Eurotronic Spirit Thermostat" problemlos gelingen. Das funktioniert aber nicht.
Nochmals präzisiert: Wenn ich "ignoreTypes" für die Zeit der Inklusion rausnehme, geschieht die Inklusion in 2..3 sec.
Hallo curt,
Schuss ins Blaue....
ZitatIch kann und will nun nicht ausschließen, dass eine der Filterregeln zuschlägt, obwohl sie das gar nicht soll.
bei Auswahl attr autosave folgender Text
Zitatautosave
Nach der Erzeugung eines neuen Gerätes wird automatisch die Konfigurationsdatei mit dem Befehl save gespeichert. Der Standardwert ist 1 (d.h. aktiviert), eine 0 schaltet die automatische Speicherung aus.
Achtung: Dieses Attribut ist unerwünscht, bitte stattdessen das global autosave Attribut verwenden.
MfG
Hans-Jürgen
Der ignoreTypes - Attributwert
ZitatTRX_.*|RUBICSON_.*|TFA_.*|VIKING_.*|TH.*|Hideki_.*|IT_.*|BTHR.*|WT.*|SD_.*
schließt die autocreate-Anlage von Devices mit dem Namen ZWave_THERMOSTAT_id und damit die Device-Anlage für das Spirit aus.
Bei dem Attributwert
(TRX_.*|RUBICSON_.*|TFA_.*|VIKING_.*|TH.*|Hideki_.*|IT_.*|BTHR.*|WT.*|SD_.*)würde ignoreTypes beim Spirit afaik nicht matchen. Vielleicht ist das eher gemeint.
Das Wort "Types" im Attributnamen ist übrigens etwas irreführend, da der Gerätename geprüft wird und nicht der Typ.
Gruß, Christian
Zitat von: krikan am 13 September 2020, 10:31:38
ZitatTRX_.*|RUBICSON_.*|TFA_.*|VIKING_.*|TH.*|Hideki_.*|IT_.*|BTHR.*|WT.*|SD_.*
Der ignoreTypes - Attributwert schließt die autocreate-Anlage von Devices mit dem Namen ZWave_THERMOSTAT_id und damit die Device-Anlage für das Spirit aus.
Autsch, böse Falle. Ich ging davon aus, dass mit dem Anfang des Strings verglichen wird. Und wenn man wahlfrei innerhalb des Strings verglichen werden soll, man
.*TH.* zu nehmen habe.
Danke für den Hinweis.
ZitatIch ging davon aus, dass mit dem Anfang des Strings verglichen wird.
Der Code im autocreate.pm packt zwar den Inhalt von ignoreTypes in ^$ (genauso wie notify,FileLog,etc), aber ohne Klammer passiert nicht das, was man erwartet.
Rudi, gehört der Link im Zitat hier wirklich hin? Ich verstehe den Zusammenhang nicht. :-\
Danke fuer den Hinweis, natuerlich nicht, habs geaendert.
Wie man sieht, kaempfe ich noch mit meinem neuen Computer :)
Freunde der warmen Stube,
mal weiter zum eigentlichen Thema (ggf. benenne ich das nachher entsprechend Threaddrift etwas um).
(M)ein Problem ist ja immer: Da hat man so ein schönes neues Spieldings und weiß gar nicht, was das so alles in Zusammenhang mit FHEM kann - und wie ich das in FHEM mir erstmal ansehe. Und dann gibt es (zu Recht) oft Hinweise, dass das Spieldings irgendwie auch Murks sei. Na jedenfalls hatte ich Glück: Ein sehr freundlicher Mensch nahm mich per PN an die Hand und zeigte seine scheinbar simple, aber tolle Konfiguration. Vielleicht zeigt er das auch noch hier im Thread, späteren Lesern wäre es zu wünschen.
Übrigens fehlt bei manchen Thermostaten das Reading "thermostatMode" ... keine Ahnung warum. Da ist es wieder - mein Problem: Wegen Amazon in mehreren Tranchen bestellt, verschiedene Verpackungen zudem: Es könnte schon sein, dass verschiedene Versionen vorliegen. Aber das sieht man den Dingern ja auch in FHEM nicht an. Oder - ich habe bei den fraglichen Thermostaten irgendwas vergessen, ein GET oder ein SET. Sowas ist als Widerspruch kaum auflösbar.
Bitte nicht falsch verstehen: Ich habe niemanden kritisiert, das liegt mir fern. Ich weiß nicht nur, wie toll FHEM (als Ergebnis der Arbeit vieler) ist, ich weiß auch, dass jeder hier schreibt ohne das bezahlt zu bekommen. Danke an alle!
Zitat von: curt am 17 September 2020, 01:05:16
Vielleicht zeigt er das auch noch hier im Thread, späteren Lesern wäre es zu wünschen.
Warum nicht du!? ;)
Gruß, Joachim
P.S.: dass "vermeintlich" gleiche ZWave Geräte dann doch (minimal) "anders" aussehen habe ich auch schon bemerkt. Z.B. Fibaro Bewegungsmelder. Je nachdem wann ich die wo bestellt habe etc. Bis hin zu ganz anderem "Verhalten" bzgl. Motion/NoMotion bzw. "Alarmauslösung"... Allerdings sollte man evtl. sowas wie FW sehen in fhem!? Evtl. gibt es ja da einen Unterschied...
Zitat von: curt am 17 September 2020, 01:05:16
Vielleicht zeigt er das auch noch hier im Thread, späteren Lesern wäre es zu wünschen.
Evtl. gäbe es eine weitere Variante, wie man sowas "verstetigen" könnte...:
https://forum.fhem.de/index.php/topic,114109.0.html
Zitat von: Beta-User am 17 September 2020, 09:25:52
Evtl. gäbe es eine weitere Variante, wie man sowas "verstetigen" könnte...:
https://forum.fhem.de/index.php/topic,114109.0.html
In dem dortigen Beitrag steigst Du für meine Begriffe zu hoch ein, damit hast Du mich als möglichen Zulieferer/Mitarbeiter schon verloren: Da gibt es offenbar XML-Files für jedes Gerät, in Deinem Beitrag wird aber nicht klar, ob das "weggefundene" XML sind oder irgendwas FHEM-spezifisches. Und so zieht sich das durch den kompletten Beitrag: Du erklärst nichts, setzt aber voraus. Klar kannst Du sagen "musste halt mal googlen" - aber selbst mein Tag hat nur 24 Stunden.
Ich würde mal sagen: Du verlierst damit jede Menge Träger von Erfahrungen. Nimm es nicht persönlich, es ist einfach so.
Zitat von: MadMax-FHEM am 17 September 2020, 09:13:30
Warum nicht du!? ;)
Ich mache zunächst mal was ganz anderes, ich fasse zunächst meine Erfahrungen allgemein zusammen - speziell kann ich später noch vortragen.
Als erstes muss man bedenken, dass niemand fortlaufend die gleichen Geräte kauft, es wird immer riskantes Neuland sein!Summa: Z-Wave-Geräte sind stabil, robust, machen im Betrieb wenig Ärger. Es gibt allerdings Wandprobleme.
Tatsächlich scheint mir die Einstiegshürde für Z-Wave im Zusammenhang mit FHEM recht hoch: Zwar gibt es einen recht guten allgemeinen Wiki-Artikel zu Z-Wave sowie zu einigen konkreten Geräten. Aber im Grunde haut man für eine neue Funktion, neues Gerät immer blind 50 Euro auf den Kopf, man kauft die Katze im Sack. Es kann das machen, was man will, das muss aber nicht so sein.
Einigermaßen dramatisch ist die Inklusion. Mal abgesehen von der autocreate-Falle (siehe oben) ist der Funkverkehr bei der Inklusion offenbar instabil. Entfernungen im Normalbetrieb werden während der Inklusion nicht ansatzweise erreicht, das zu inkludierende Gerät muss bezogen auf den Z-Wave-FHEM-Baustein im gleichen Raum, ca. 3m entfernt sein. (Bei fehlerhafter Inklusion wird es dramatisch: Man muss via FHEM dem Z-Wave-FHEM-Baustein klarmachen, dass UNKNOWN_DEVICE gelöscht werden muss.)
Damit sind wir beim Thermostat (ich habe acht, also reichlich Übung): Den habe ich also neben dem FHEM-Server in der Hand. Falls die Inklusion gelingt, sind flinke Füße angesagt. Denn der Thermostat hat auch Ideen und quengelt rum: Er will nun unbedingt einen Adapterlauf (der Motor testet mal das Ventil des Heizkörpers) - also rennen und anbauen und Knöpfchen drücken ... und beten.
Dann ist es wichtig, den kompletten Zirkus aus https://wiki.fhem.de/wiki/Z-Wave#Welche_Infos_sollten_Anfragen_im_ZWave-Forum_enthalten.3F durchzuziehen:
Zitat
get <device> associationAll
get <device> configAll
get <device> versionClassAll
get <device> mcaAll
get <device> wakeupInterval
Denn sonst ist FHEM bezogen auf das neue Device blind. Das sagt Dir nur niemand (wenn ich meinen treuen Freund
@Beta-User nicht hätte ...) - anzumerken ist an der Stelle, dass nicht jedes GET bei jedem Gerät vorhanden ist.
Aus meiner ganz naiven Sicht:
Wünschenswert wäre, wenn die o.g. Befehlskette ganz automatisch am Ende der Inklusion ausgeführt würde!Hinweis dazu: Mein PN-Freund meint, dass es erfahrungsgemäß wichtig sei, vermittels "sleep 3" Pausen einzulegen, um dieses Netz nicht zu überlasten.
Warum dieses, warum mein Vorschlag, diese Befehlskette als Teil der Inklusion auszuführen?
Weil niemand jede Woche neue Z-Wave-Geräte kauft. Weil man immer wieder mit Z-Wave-Geräten vor der gleichen Baustelle steht: Einen Prozessweg aus zig Wiki- und Forenartikeln rauszusuchen. Das ist nervig und hat vor allem eine sehr hohe Fehlerquote.
Die einigermaßen vernünftige Integration von Thermostaten in FHEM ist dann die nächste Baustelle: Was kann man sich sinnvollerweise anzeigen lassen? Wie mache ich eine Temperatursteuerung? Wie mache ich das mit dem "Fenster-auf - Fenster-zu"? Also Fenster hat jeder, eigentlich kann es nicht sein, dass jeder sich mühselig durch notify- und DOIF-Themen kämpft. Ja, habe ich dank einiger Hilfe. Offen ist noch das, was @Deckoffizier da mit readingList und setlist macht - beide sind nirgendwo hinreichend (mit Beispielen!) beschrieben. Vermutlich so eine Art Runterklappmenü - aber das rate ich nur.
Um mal zu den positiven Dingen zu kommen:
Also wenn es (Z-Wave) läuft, dann läuft es. Zwar meint mein PN-Freund, dass man jeden Befehl nach "sleep 3" nochmals absetzen müsse. Mir war noch gar nicht aufgefallen, dass es da ein Problem geben könnte: Ich habe im zweietagigen Haus 14 aktive Z-Wave-Steckdosen, die scheinen für hohe Stabilität des Z-Wave-Netzes zu sorgen.
Dafür ist allerdings notwendig, dass "set neighborUpdate" für jedes Z-Wave-Gerät ausgeführt wird. Auch so eine Baustelle: Man freut sich ohne Ende, dass der Thermostat da unten läuft - auf diese Idee kommt man gar nicht ...
Im Grunde bräuchte man im Raum ZWave einen Knopf "neighborUpdate", den man alle vier Monate mal drücken kann: An jedes Gerät geht der Befehl. Immer mit "sleep 3" dazwischen.Als problematisch stellt sich der Übergang von Haus zu Garten dar: Ich habe Z-Wave-Steckdosen im Garten. Das ist nun aber ein Niedrigenergiehaus mit geilen Fensterscheiben - das geht es grad noch so. Wenn aber die Rolläden (auch Isolation) runter sind, dann wird das wacklig. Und das selbst mit einem Z-Wave-Repeater-Stecker, den ich auch habe.
Vorab mal Sorry, wenn dir der verlinkte Thread jetzt nicht unmittelbar weitergeholfen hat.
Im Kern wollte ich sagen: Hier im Forum bei passender Gelegenheit eine funktionierende Konfiguration (und optimalerweise den Vorgehensweg bis dahin und das, was sich ggf. daran anschließt) zu posten ist ein guter Anfang, aber was wir mAn. eigentlich brauchen, ist ein strukturierter Erfahrungsaustausch _pro Gerät_: "FHEM-ZWaver aller Länder, tauscht euch aus!"...
Das Problem ist in der Tat, dass FHEM erst mal "nichts weiß", also vor der Bestimmung des Models (mit Hilfe der von außen kommenden, weltweit und in fast allen Systemen (also auch der Lösung von Fibaro etc.) verwendeten XML's - der get model-Befehl wird am Ende des Inclusions-Vorgangs afaik abgesetzt) schon gar nicht in der Lage ist, die passenden "Anschlussbefehle" zu ermitteln und erst recht nicht wissen kann, wie der Anwender ein ZWave-Gerät denn verwenden will. Das muss er (fast) immer selber entscheiden.
Genau an dem Punkt setzt dein Problem an, und auch meine Überlegung, OB attrTemplate als Mechanismus denn dazu eine Lösung bieten könnte. Das können ggf. nur Leute beantworten, die in der Materie tiefer drin sind wie wir beide, ich kann von meiner Seite "nur" das Wissen bereitstellen, welche Optionen man mit dem attrTemplate-Baukasten an sich hat. Von daher war mein Post auch (mit) die Aufforderung an den freundlichen pm-Helfer, dieser Diskussion an der einen oder anderen Stelle beizutreten, er scheint jedenfalls auf der ZWave-Seite deutlich weiter zu sein wie ich.
Ansonsten _glaube_ ich nicht, dass das mit dem "immer riskantes Neuland" so sein muß. Bereits heute entspricht das nicht unbedingt ("immer" ist schlicht falsch...) meiner Erfahrung, es ist eben "nur" in Teilen so.
Mal schauen, wie sich die Dinge entwickeln, ansonsten kann ich in Teilen den Frust nachvollziehen, der da zwischen den Zeilen steckt, warum es weder was spezielles zur konkreten Verwendung dieser Thermostate im Wiki gibt noch sowas wie eine (oder mehrere) "Musterlösung/en" für Heizungssteuerung allgemein oder PID20. (Es gibt aber durchaus viele kleine Bausteinchen, die allerdings mAn. irgendwie nicht richtig verzahnt sind).
(Vielleicht ist das eine "einfachere" Baustelle, um die sich mal jemand intensiver bemühen mag?)
PS: FHEM als Gesamtsystem "an sich" wird wegen ein paar attrTemplates kaum einfacher, das ganze Zusammenwirken der Komponenten wird immer komplex bleiben. Das Ziel kann daher kaum sein, jeden "mach ich mal, wird schon werden..."-Anfänger damit "glücklich" zu machen...
Hi,
Ich weiss nicht, ob ich gemeint bin mit dem PM Freund, Kontakt hatten wir zumindest und ich stehe zu meinen Nachrichten :D
ZWave ist ein Thema, wo man sich bei jedem neuen Gerät erstmal mit beschäftigen muss, mit Glück gibt es schon Infos im Forum hier und man kann daraus für seinen Zweck alles rauslesen. Wenn nicht oder wenn die Infos unklar sind, dann kann es schnell passieren , das man frustriert ist. Ich habe auch noch so ein Multisensor 6 Zwave liegen, der nicht tat was ich wollte (Falls den Jemand will -> PM (neuwertig , Batterien sind auch da und usb Kabel sollte auch da sein, kann ich gern checken wenn jemand braucht).
Vielleicht können wir ja auch im Wiki die Infos verbessern, auchdie Templates finde ich als eine Variante die Unterstüzen / helfen kann. Letztlich ist ZWave aber mE kein System, was einfach läuft ohne das man etwas Wissen aufbaut und sich etwas beschäftigt damit. Das ist aber letztlich bei allem so :)
Das mit den Sleep 3 kommt jedenfalls von mir, und ist darauf begründet, das DOIFs teilweise Daten von meinen 3 Thermostaten anfordern, weil die es nicht hinbekommen, die zu senden (Firmware Gründe wohl)
Ich hatte da immer Probleme mit NoAck usw das einfach zuvieles gleichzeitig passierte und lass im Forum oder Wiki, das man es serialisieren soll, also nacheinander mit Pausen dazwischen.
Genau das macht das Sleep, was nonblocking ausgeprägt ist, es rennt also im Hintergrund und macht seinen Job. Es dauert vielleicht dann 1-2 Minuten gesamt, aber dafür passt alles :)
Ronny
Den Multisensor kenne ich nicht, aber da ich bisher keine Batterie-ZWaves habe und vermutlich einfach Testhardware für das eine oder andere benötige: Was hattest du dir dafür vorgestellt? (Details gerne per pm; falls jemand anderes was taugliches hat: gerne auch leihweise, das ist allerdings kein Versprechen, dass ich dann auch zeitnah dazukomme...)
Ansonsten: Wenn du die Konfiguration(-sanweisungen) für den Eurotronic zusammenstellst, kann ich gerne mal versuchen, das zu "vertemplaten", und gehe davon aus, dass curt dann gerne den Tester macht?
Btw.: "firmware" wäre ein anderes Thema, wo wir uns ggf. zusammentun müssen und dem einen oder anderen Hersteller mal auf die Füße treten... (Es gab da auch vor ein paar Wochen einen völlig unbeachteten Thread "user alliance" oder so ähnlich)
Und so wie ich Rudi kenne, ist er auch gerne bereit, im Modul ggf. sinnvolle "Begleitcodes" bereitzustellen, falls das erforderlich wäre. Setzt halt einen "konsolidierten Wissensstand" voraus. Macht ja keinen großen Sinn, wenn man für jede Hardware dann einen "typischen Zoo" von "Begleitmodulen" braucht, nur um diese Hardware zu nutzen...
(
Threaddrift)
Zitat von: rcmcronny am 18 September 2020, 13:51:06
Ich weiss nicht, ob ich gemeint bin mit dem PM Freund, Kontakt hatten wir zumindest und ich stehe zu meinen Nachrichten :D
Und ich stehe dazu, dass ich Dir via PN meinen goldenen Papp-Orden "Freundlicher Helfer des Tages" verliehen habe, danke nochmals!
Zitat von: Beta-User am 18 September 2020, 14:10:37
Den Multisensor kenne ich nicht,
Damit ist vermutlich dieses Fibaro-Auge gemeint. Auch aus einer Sicht ein übles Drecksding, ich hatte drei davon ... wieder vertickert. Aber als Testobjekt ist der vermutlich nicht schlecht: Da darfst Du mit wirklich zig Readings und Hastenichgesehen rumspielen. Und natürlich mit dem wakeup-Zirkus, in meiner Erinnerung ist der heikel, Du kriegst nicht alle Nachrichten durch - irgendwann nach Tagen hat das Auge sind dann wieder erholt.
Zitat von: Beta-User am 18 September 2020, 14:10:37
aber da ich bisher keine Batterie-ZWaves habe und vermutlich einfach Testhardware für das eine oder andere benötige:
Da habe ich was für Dich, das würde ich Dir zusätzlich empfehlen (ernsthaft!). Das ist aus dem Urlaubsprojekt "Nachbarin muss Gartenpumpe schalten" und genau so ranzig, wie die Bewertungen vermuten lassen. Beispielsweise ist mir bis heute AssoziationAdd nicht gelungen, aber es funktioniert ganz grundsätzlich. Zudem kannst Du die vier Taster völlig frei belegen. Es ist für Tests ideal, weil Du Entfernungsprobleme bekommst. Und die WakeUp-Probleme gibt es kostenlos dazu, so gesehen ein unschlagbarer Preis, schau hier: https://www.amazon.de/gp/product/B00M2JK69M/
Zitat von: Beta-User am 18 September 2020, 14:10:37
Ansonsten: Wenn du die Konfiguration(-sanweisungen) für den Eurotronic zusammenstellst, kann ich gerne mal versuchen, das zu "vertemplaten",
Kannst Du bitte kurz erklären, was das "vertemplaten" rein praktisch bewirkt? Wo ist der Unterschied zu der Idee, dass Rudolf das einbezieht? - Ansich kann ich das aber gern nochmal aufschreiben: Das ist AssoziatonAdd sowie die bis zu 5 weiteren Befehle, auf die Du mich hingewiesen hast. Das kann ich der Lesbarkeit wegen gern in weiterem Beitrag konkret zusammenfassen.
Zitat von: Beta-User am 18 September 2020, 14:10:37
und gehe davon aus, dass curt dann gerne den Tester macht?
Ich habe seit wenigen Tagen acht Thermostaten in Betrieb, die sind naheliegenderweise batteriegestützt. Und weil mein Freund @Deckoffizier gesagt hat, dass es da auch mal eine Fehlcharge geben kann, habe ich einen weiteren bestellt, der wäre für Tests frei. (Blöd ist halt, dass man den real an die Heizung schrauben muss, sonst will der nicht mit mir spielen. Aber ok: No risk, no fun.)
Zitat von: Beta-User am 18 September 2020, 14:10:37
Und so wie ich Rudi kenne, ist er auch gerne bereit, im Modul ggf. sinnvolle "Begleitcodes" bereitzustellen, falls das erforderlich wäre. Setzt halt einen "konsolidierten Wissensstand" voraus.
Bevor da irgendwas los geht, ist eine ganz zentrale Frage zu klären: Was passiert, wenn eine ZWave-Device einen ungültigen Befehl erhält? Also beispielsweise ein kabelbetriebenes Gerät einen Befehl, den es nur für batteriegestützte Geräte gibt. Was passiert dann, was darf man auf der Protokollebene voraussetzen?
Die Antwort darauf ist immes wichtig. Denn falls das in der allgemeinen Spezifikation Fehlertoleranz befohlen ist, kann man das aus meiner Froschperspektive recht allgemein halten.
Ontopic
Ich schrieb:
Zitat von: curt am 17 September 2020, 01:05:16
Übrigens fehlt bei manchen Thermostaten das Reading "thermostatMode" ... keine Ahnung warum. Da ist es wieder - mein Problem: Wegen Amazon in mehreren Tranchen bestellt, verschiedene Verpackungen zudem: Es könnte schon sein, dass verschiedene Versionen vorliegen. Aber das sieht man den Dingern ja auch in FHEM nicht an. Oder - ich habe bei den fraglichen Thermostaten irgendwas vergessen, ein GET oder ein SET. Sowas ist als Widerspruch kaum auflösbar.
Boah, unglaublich. Das ist ja unterirdisch ... ich hab's.
Vorbemerkung:
Normalerweise bestellt man eins, schaut mal was geht (wenn es ideal kommt, hilft einem eine treue Seele im Forum) und wirft es wieder weg. Ich hatte mich entschieden, acht zu kaufen. Das hat nun den Vorteil, dass ich wirklich vergleichen kann.
Wenn man den Inklusionszirkus mit anschließend mehreren händischen Schritten überstanden hat, laufen alle Thermostaten im Modus Heating, sie empfangen und senden fein. Das ist auch sehr stabil für ein batteriegestütztes Gerät. Je nach konkretem Thermostat ist das Reading "thermostatMode" oder nicht gesetzt. Obwohl wie gesagt alle im Modus "heating" sind.
Der Trick (Zufallsfund) besteht nun darin, dass man einen set- Befehl der Gruppe tm* absetzen muss, dann wird das manchmal fehlende Reading gesetzt.
Auch da muss man gleich an zwei Stellen aufpassen: tmCooling et al wird zwar angeboten, greift natürlich aber ins Leere. Und selbstbei funktionierendem "tmoff" hat man halt anschließend keinen heizenden Heizkörper mehr ... das steht aber nur in diesem Reading. Also zurück mit "set tmHeating".
P.S: Da in vorherigen Beiträgen gleich zwei Leute schrieben ich würde frustriert klingen: Ach Quatsch. Dann hätte ich FHEM 2017 in die Ecke gehauen. Es ist anders: Ich schreibe direkt - weil ich denke, dass man Probleme präzise als Probleme benennen muss, Kuschelformulierungen halte ich persönlich für wenig zielführend. - Mir geht es gut, ich freue mich über FHEM, über meine Thermostaten, über meine vielen Freunde im Forum: Seid alle freundlich gegrüßt.
Zur Auflockerung zeige ich euch mal, was dann machbar ist - wenn viele FHEM-Ebenen zusammengreifen (und ich vielen Forum-Freunden über die Jahre danken darf):
Im Gästezimmer sind
* batteriegestützter Temperatursensor der Marke LaCrosse/Jeelink
* Fenstermelder Homematic
* Heizkörperthermostat Z-WavePlus Thermostat Eurotronic Spirit
Dazu kommen die vielen Hinweise seit Jahren und rein optisch FTUI @setstate und Chart @eki .
Zu sehen ist eine FTUI-Grafik, darin
* rot - Temperatur-IST im Raum
* grün - Temperatur-IST des Thermostat
* gelb - Temperatur-SOLL des Thermostat, völlig automatisiert vorgegeben (!)
* grau - Fenster offen?
* blau - Ventilstellung des Thermostat (0-100%) (alle 30min erhoben)
Da lacht das Techniker-Herz. (Und ich hörte im letzten Jahrtausend zwei Semester Automatisierungstechnik, mein Herz hüpft vor Freude!)
Sieht hübsch aus :) .
[OT: Mein aktuelles setup, was Thermostate angeht: HM-RT-CC-DN@CUL_HM<->(ZigBee|BT-LE|CUL_HM)-Temperatursensoren + Tür-FK's in CUL_HM (indirekt gepeert, öffnen mit Zeitverzögerung)
Ich "durfte" übrigens bei der Gelegenheit einen deftigen Logikfehler im Wiki beseitigen, was die Funktionalität mit virtuellen Temp-Sensoren angeht, der da seit Jahren unwidersprochen stand...]
Spannender ist aber die Frage, wie die Solltemperatur jeweils vorgegeben wird (und wie das an den Aktor kommt, also als Solltemperatur (CUL_HM kann afaik eigentlich nichts anderes, bei mir meistens via temp-Liste im Aktor, wenn jemand da ist oder (Umschaltung des Betriebsmodus) als manuelle Temperatur bei Abwesenheit (da ist bei mir hier die (ausdifferenzierte) Erkennung noch irgendwie unfertig)) oder als Vorgabe des Öffnungsgrads (das ist afaik ein Alleinstellungsmerkmal dieses Eurotronic-Thermostattyps! (=>PID20, wenn ich's richtig verstanden habe). Vergleichbares läßt sich wohl mit anderen derzeit käuflichen Thermostaten nur durch viel Getrickse erreichen...)
Was jetzt attrTemplate angeht:
- Das funktioniert nicht von ganz allein, der Anwender muß es "anschubsen";
- Es kann nur, was FHEM/Perl kann, Befehle, die unbekannt sind, kann man auch nicht absetzen. Der Anwender kann (nach meinem Verständnis und ohne das Absetzen von kryptischen "configWord/Byte ..." ) immer nur das an Befehlen wählen, was sich aus den XML ergibt. Sind da bugs drin, kann (oder zumindest sollte) man die nur zentral beheben.
- im attrTemplate kann (bzw. sollte) man ggf. die Klartextbefehle durch die "eigentlichen" Byte/Word/...-Konfigurationsbefehle ersetzen, denn das "wording" hängt am XML und kann sich jederzeit ändern
- Zeitlich gestaffelte Befehle sind möglich, da ist allerdings die (gedankliche?) Schwierigkeit, dass die Dinge teils aufeinander aufbauen und es uU. nicht mehr klappt, wenn irgendwo was schiefgeht (s.u.).
- Unklar ist auch, wie man verhindern kann, dass ein Anwender "das falsche template" auswählt und dann eben am Ende ein "komisches" Gerät hat (aber afaik sieht man wenigstens, was passiert ist, wenn die Antworten auf diverse gets da sind).
Na ja, jedenfalls könnte man im Falle dieses Thermostats so dann auch sicherstellen, dass zumindest dieser ominöse tm*-setter einmalig abgesetzt wird. Die XML enthält zwar die Option, aber (afaik) keinerlei Instruktion an die Controller-Software, irgendwas effektiv zu senden.
"vertemplaten" meint also eigentlich nur sowas in diese Richtung:
- Die FHEM-Befehle, die zu einem funktionierenden Device führen aufschreiben und "auf einen Rutsch" ausführbar machen, das ganze ggf. in mehreren Varianten (Bsp. Solltemp vs. Ventilsteuerung oder Rollladenaktor vs. Jalousiesteuerung)
- Dem Anwender vorab anzuzeigen, was es machen wird (dann kann man es auch manuell & anders machen, wenn man will) und ggf. darauf hinweisen, wie lange er ggf. warten soll, bis alles fertig ist;
- Links bereitstellen, aus denen man (möglichst ohne umfangreiche Suche) rauslesen kann, warum es soherum gemacht wurde und nicht anders, wo eventuelle Probleme herkommen, whatever you like...
Ich habe übrigens doch zwei Batteriegeräte, die allerdings nicht wirklich mit Stress beim Einbinden verbunden waren (soweit ich das heute noch in Erinnerung habe) - Fernbedienungen/Scene-Controller... heatit 8-push und einen (devolo?) 4-fach-Taster. Da war es nur so, dass ich von dem recht teuren heatit deutlich mehr Event-Variationsmöglichkeiten erwartet hätte, (irgendwo hier auch schon berichtet), und beide mussten recht häufig aufgeweckt werden, damit die Konfiguration schneller übertragen wird, was nicht eben batterieschonend genannt werden kann. Auch solche Erfahrungen könnte man sammeln und in der Beschreibung verfügbar machen (zumindest, soweit es die eher technischen Aspekte angeht, sonst wird amaz.* ja funktionslos ;D )...
Von daher bin ich etwas am Zweifeln, ob ich mir grade den Stress mit dieser FB geben soll, die kommt aber auf alle Fälle mal auf meine "Liste".
Generell kommt bei ZWave immer mal wieder durch, dass (vereinzelt) Befehle verloren gegangen zu sein scheinen (gestern erst wieder unter dem Stichwort "merten" gemeldet). Da fehlt mir noch ein Gefühl dafür, wo es herkommt, ob aus der Sendelogik oder ob es ein prinzipbedingtes Thema (beschränkt auf ältere Produkte?) ist. (Da erwarte ich keine direkte Antwort, muß wohl erst auch nochmal die Doku ein 10tes Mal lesen, vermutlich steht's da schon und ich versteh's irgendwann...).
Sowas wäre halt hinderlich auf dem Weg zu funktionierenden Konfigurationen (via attrTemplate) ::) .
Zitat von: Beta-User am 19 September 2020, 06:45:25
Sieht hübsch aus :) .
<kämmt sich nochmal> Danke!
Zitat von: Beta-User am 19 September 2020, 06:45:25
Spannender ist aber die Frage, wie die Solltemperatur jeweils vorgegeben wird (und wie das an den Aktor kommt
Rein technisch über "
set Thermostat_Gaestezimmer desired-temp 14.7"
Aber Du meinst vermutlich was anderes. Dazu muss ich mit meinen zwei Semestern kurz ausholen:
Allein mit der Vorgabe einer Temperatur für den Thermostat hast Du einen Regelkreis. Leider hast Du (sehr oft) einen übergeordneten Regelkreis: Die Heizung selbst "denkt" auch noch mit: Da wird normalerweise Außentemperatur gemessen, irgend eine Innentemperatur, damit hat die Heizung dann Vorgaben. Aus Automatisierungssicht ist das hässlich: Da greifen zwei Regelkreise ineinander, das Ergebnis ist kaum vorhersagbar. Ok, in Normalsituationen kann man darüber hinwegsehen.
Wenn Du nun aber für einen konkreten Raum den Sollwert irgendwie steuern oder gar regeln willst, dann hast Du den dritten Regelkreis - das wird dann wirklich heikel. Sowas will man nicht. Wirklich nicht.
Im Grunde will man was anderes, das nennt sich Steuerung: Man will für einen Raum eine Wohlfühltemperatur. Oder zwei, eine für den Tag, die andere für die Nacht. Das Problem besteht darin, den SOLL-Wert dafür experimentell zu bestimmen - auf alle Fälle grätscht der erste Regelkreis (Heizung selbst) da rein. Und sowohl bei Regelung als auch bei Steuerung hast Du den Zeitversatz, das Einschwingverhalten - darauf hast Du keinen Einfluss. Ich halte es für nicht realistisch, als Laie (ich bin einer) im dritten Regelkreis eine Nachführung zu machen. Nicht nur, weil das sehr komplex würde, vor allem fehlt Dir ein Wert: Ich darf daran erinnern, dass das Device batteriegestützt ist und mit der Konstruktion meines Freundes alle 30 Minuten meldet. Öfter geht nicht, Du kannst ja nicht jede Woche Batterien wechseln.
Zitat von: Beta-User am 19 September 2020, 06:45:25
Was jetzt attrTemplate angeht:
Überlesen. Ich weiß nicht ansatzweise, was ich mit einem Template machen könnte. Vermutlich ein GET oder ein SET auf ein Device. Und warum ich das tun sollte, wo ist da mein konkreter Gewinn? Sag mal bitte.
Neh Du: Das funktioniert grad schön.
Zitat von: Beta-User am 19 September 2020, 06:45:25
Ich habe übrigens doch zwei Batteriegeräte, die allerdings nicht wirklich mit Stress beim Einbinden verbunden waren
Ich empfehle nochmals die von mir schon genannte Fernbedienung.
Zitat von: Beta-User am 19 September 2020, 06:45:25
Generell kommt bei ZWave immer mal wieder durch, dass (vereinzelt) Befehle verloren gegangen zu sein scheinen
Wir müssen sehr klar zwei Situationen unterscheiden:
1) Inklusion
2) Betrieb
zu 1) Inklusion:
Da nachweisbar die Entfernung zur Basis eine Rolle spielt, muss geschlussfolgert werden, dass bei mehreren/vielen Telegrammen entweder das Zeitfenster zu klein ist oder die Device mit Fehlern schlecht umgehen kann. Dafür spricht im Grunde auch der Hinweis auf "sleep 3" für den Normalbetrieb von @rcmcronny . Das gilt übrigens nicht nur für Thermostate, selbst bei Funksteckdosen (die ja kein wakeup haben) hatte ich jedesmal den gleichen Zirkus.
zu 2) Betrieb
Im Normalbetrieb sind ZWave-Devices deutlich stabiler. Wirklich stabil.
Batteriebegestützte ZWave können offenbar aber nicht zu viele Telegramme bei Wakeup annehmen, zudem blockieren die Quittungen den Kanal, siehe Hinweis "sleep 3" von @rcmcronny.
Tatsächlich gehe ich mit der Idee schwanger, jeden Befehl (mit sleep 3) doppelt abzusenden - ich will doch nicht im Schlaf erfrieren.
Zitat von: curt am 19 September 2020, 07:40:34
Rein technisch über "set Thermostat_Gaestezimmer desired-temp 14.7"
Ich _glaube_: Jein!
- Entweder so, oder
- über die Vorgabe eines Öffnungsgrades des Ventils (!) oder
- über ein Wochenprogramm, das AUTONOM auf dem Thermostat abläuft (irgendwo meine ich gelesen zu haben, dass das mit anderer Controller-Software ginge, und der (vermutlich ähnlich programmierte?) ZigBee-Verwandte kann es - nach entsprechender Nacharbeit - afaik auch)
ZitatAber Du meinst vermutlich was anderes. Dazu muss ich mit meinen zwei Semestern kurz ausholen:
[...]
Na ja, das mit der Abstimmung der verschiedenen (teil-) autonomen Regelungsmechanismen (da gibt es ja noch mehr Teilsysteme, angefangen bei intelligenten Umwälzpumpen für's Heizungswasser oder die Solarthermie) ist ein allgemeines Thema, und mein Hinweis, dass da etwas mehr Wiki-Arbeit eigentlich ganz sinnvoll wäre, ging in etwa in diese Richtung.
Sollten wir aber einstweilen an dieser Stelle nicht vertiefen
ZitatIch empfehle nochmals die von mir schon genannte Fernbedienung.
Habe schon verstanden, dass die "besonders spassig" ist; wie gesagt: kommt auf die Liste, hat aber low prio.
ZitatÜberlesen. Ich weiß nicht ansatzweise, was ich mit einem Template machen könnte. Vermutlich ein GET oder ein SET auf ein Device. Und warum ich das tun sollte, wo ist da mein konkreter Gewinn? Sag mal bitte.[...]
Wir müssen sehr klar zwei Situationen unterscheiden:
1) Inklusion
2) Betrieb
"Sag mal bitte" = attrTemplate liegt eigentlich "zwischen" 1) und 2).
ad 1) Ohne fertige Inklusion gibt es keine vernünftige Kommunikation mit FHEM, prinzipiell müßte dann alles weitere scheitern. Ausnahme: bestimmte zur Inklusion gehörende Funktelegramme gehen verloren; die könnte man ggf. via attrTemplate wiederholen lassen (vermute: geht mit den originären Bodrmitteln besser, da zielgerichtet)
2) Ein "Betrieb" setzt voraus, dass das Gerät fertig konfiguriert ist. Wenn es Sinn machen sollte, die Queue zu optimieren oder Quittungsverfahren "zu härten", gehört das m.E. ins (IO-) Modul, solche würgarounds sollten überflüssig sein. Ggf. brauchen wir Möglichkeiten für den User, dem IO seine Anwendungssituation mitzuteilen. Sowas wäre ggf. über Attribute zu regeln.
Damit sind wir eben bei der Frage, wie man die Geräte optimal für den Regelbetrieb konfigurieren kann. Dazu gehören einmalige Konfigurationsbefehle nach der Inklusion sowie ggf. individuelle Einstellungen, die irgendwie zusammenpassen sollten. Das kann man vercoden, that's all.
Bringt dem nichts, der den Code liefert, sondern erst dem nächsten.
(Zu eventuellen Funktionserweiterungen - Stichwort Wochenprogramm als Beispiel - schreibe ich bei Gelegenheit noch was).
Zitat- Unklar ist auch, wie man verhindern kann, dass ein Anwender "das falsche template" auswählt und dann eben am Ende ein "komisches" Gerät hat
Im Template anhand das model Reading filtern.
Zitat von: Beta-User am 19 September 2020, 08:27:33
ZitatRein technisch über "set Thermostat_Gaestezimmer desired-temp 14.7"
Ich _glaube_: Jein!
Ich
weiß: Nur so und nicht anders.
Zitat von: Beta-User am 19 September 2020, 08:27:33
- über die Vorgabe eines Öffnungsgrades des Ventils (!) oder
Wer das kann, hat einen Tagessatz von um die 2.000 und meinen höchsten Respekt. Da lassen wir die Finger von.
Zitat von: Beta-User am 19 September 2020, 08:27:33
- über ein Wochenprogramm, das AUTONOM auf dem Thermostat abläuft
Würde ich sofort ausschalten.
Zitat von: Beta-User am 19 September 2020, 08:27:33
Na ja, das mit der Abstimmung der verschiedenen (teil-) autonomen Regelungsmechanismen
Ok, lernen in 30 Sekunden:
1) Steuerung: Sollwert vorgegeben, Istwert folgt. Geprüft wird nix.
2) Regelung: Ein Kreis. Sollwertgeber prüft immerzu wo der Istwert ist und regelt nach.
Obiges bitte fünfmal lesen, ist wichtig.Schlussfolgerung:
Wenn verschiedene Regelungen ineinandergreifen, ist das Ergebnis faktisch nicht kontrollierbar. Das sind Projekte, die ganz schnell im Millionenbereich sind. Dafür sind wir mit FHEM alle deutlich zu arm.
Anders gesagt: Wir müssen eher verhindern, dass verschiedene Regelkreise ineinander greifen.
Zitat von: Beta-User am 19 September 2020, 08:27:33
2) Ein "Betrieb" setzt voraus, dass das Gerät fertig konfiguriert ist. Wenn es Sinn machen sollte, die Queue zu optimieren oder Quittungsverfahren "zu härten", gehört das m.E. ins (IO-) Modul,
Genau das wünschte ich mir, siehe meine letzten Beiträge.
Zitat von: Beta-User am 19 September 2020, 08:27:33
Damit sind wir eben bei der Frage, wie man die Geräte optimal für den Regelbetrieb konfigurieren kann. Dazu gehören einmalige Konfigurationsbefehle nach der Inklusion
Genau das wünschte ich mir, siehe meine letzten Beiträge.
Zitat von: curt am 19 September 2020, 09:09:46
Ich weiß: Nur so und nicht anders.
OK, dann sprechen wir vermutlich von einem anderen Produkt. In der openzwave_device.xml finde ich zu "KOMFORTHAUS Spirit Z-Wave Plus" (mehr habe ich mit "spirit" nicht gesucht) folgendes:
Zitat
<Value genre="user" index="0" instance="1" label="Mode" type="list">
<Help> Off: No heating, only frost protection. Heat: Room temperature will be kept at the configured setpoint. Heat Eco: Energy save heating mode. Room temperature will be lowered to the configured eco setpoint in order to save energy. Full Power: Full power heating. This mode is left automatically after 5 minutes. Manufacturer Specific: Direct valve control mode. The valve opening percentage can be controlled using the switch multilevel command class. </Help>
<Item label="Off" value="0"/>
<Item label="Heat" value="1"/>
<Item label="Heat Eco" value="11"/>
<Item label="Full Power" value="15"/>
<Item label="Manufacturer Specific" value="31"/>
Den Einzelbeitrag mit der Sache mit den Wochenprofilen habe ich jetzt nicht gesucht, vermutlich geht es da dann auch um andere Hardware...
ZitatWer das kann, hat einen Tagessatz von um die 2.000 und meinen höchsten Respekt. Da lassen wir die Finger von.
Welchen Tagessatz die betreffenden User verlangen, entzieht sich meiner Kenntnis, aber ich bin ziemlich sicher, dass es die gibt. Stichwort war u.a. PID20, wenn ich die Puzzleteile richtig zusammensetze. Damit wird nach meinem Verständnis die "Regelung" gemacht.
ZitatWürde ich sofort ausschalten.
Bislang hattest du dich nicht auf eine Variante festgelegt, sondern erst jetzt mitgeteilt, dass für dich nur die Variante mit dem (aktuellen) desired-temp in Frage kommt. Das ist ok, aber es ist völlig klar, dass da jeder User seine eigene Meinung dazu hat...
Dementsprechend sollte er
a) irgendwo erfahren, welche Optionen er eigentlich hat und was er sinnvollerweise an Steuerung, Regelung und Umfeldinfos, -Modulen usw. braucht, damit es am Ende jeweils so warm ist, wie er oder seine Familie das gerne hätte ;) .
b) dann ein vereinfachtes Verfahren haben, um zumindest das betreffende Einzeldevice entsprechend seinen (Ziel-) Vorstellungen zu konfigurieren...
Zitat von: rudolfkoenig am 19 September 2020, 08:29:20
Im Template anhand das model Reading filtern.
Na ja, filter: (und prereq:) kamen mir hier nicht so richtig zielführend vor: filter: bewirkt nur, dass man das Template nicht sieht (=> man kann es aber via Kommandozeile ausführen!), und die Sichtbarkeit von (vielleicht!) vergleichbaren Konkurrenzprodukten, was die Konfiguration angeht, war grade was, was m.E. sinnvoll wäre...
(Da sind noch ein paar andere Punkte in den Beiträgen vergraben, zu denen mir auch ein paar noch ungeordnete Gedanken gekommen waren, dazu folgt ggf. irgendwann noch was).
Hallo curt,
ZitatOffen ist noch das, was @Deckoffizier da mit readingList und setlist macht - beide sind nirgendwo hinreichend (mit Beispielen!) beschrieben. Vermutlich so eine Art Runterklappmenü - aber das rate ich nur.
anbei ein Bild
für setlist ergibt sich z.B nach Auswahl einer zwischenzeitlichen Temperatur z.B. bei 24 Grad nebenstehender Text manuell aktiv oder wie Fenter offen oder Fenster noch offen.
Zur Regelung steige da jetzt nicht mehr ganz durch, aber "meine" Erklärung dazu, entweder nutze ich die Regelstrategie des Thermostaten selber
mit seiner eigenen Temperaturmessung(find ich nicht so optimal) intern vielleicht auch PID20 Logik (heating Modus).
Oder in tmManual Modus mit externen Tempsensor und eigenen PID20 Einstellungen oder wie auch immer und z.B. weekdaytimer für die Schaltzeiten.
Hier schon mal irgendwo gelesen, zur Vorlauftemperaturreglung der Heizungsteuerung benutzt man nicht die Außentemperatur(gängig) als Eingabe, sondern "nur" die Raumtemperatur eines Referenzraumes zum ? Energiesparen.
Und Ja, ich benutze für die Raumtemperatur Messung die Fibaro Multisensor(Magische Auge) Teile und bin damit soweit Zufrieden.
Habe die Sensoren auf die ober unter Teile einer Messing Duftöllampe geschraubt und hat somit einen gewissen Schick ;)
Kann es mir leider nicht verkneifen, anbei meine Freunde suche ich mir alleine aus.
Gruß
Hans-Jürgen
Hallo curt,
an bei ein Bildschirmfoto von der
Regelung ala PID20 muss dazu sagen hatte über Tag die Heizung komplett abgeschaltet da es Heute
fast Sommerlich war und die Regelung des Thermostaten ohne Heizwasservolumenstrom im Plattenheizkörper
ins Leere ging.
Im Schnitt komme ich mit einmal im Jahr mit Akku nachladen aus.
Gruß
Hans-Jürgen
Hallo curt,
mein Senf vage ausgedrückt zur Heizungsregelung.....
im OPTIMAL Fall sind bei entsprechender Heizungsanlage Thermostatventile überflüssig.
Sie sollen eigentlich nur den Fremdwärmeanteil wie Z.B. Sonneneinstrahlung, Kochen etc.
regeln.
Bei richtiger Heizkennlinie und Hydraulischen Abgleich(Durchfluss) wären sie immer auf 100% offen.
Eine Art der Regelung wie vorher schon angedeutet wäre eben die Regelung des Kesselschaltfeldes
mit seiner Heizkennlinie und eventuell Mischer nur über die Auswertung der einzelnen Ventilöffnungen in den einzelnen
Räumen wie hier im Forum schon mal vorgestellt.
Heizungsregelung ist ein weites Feld und schwer pauschal zu händeln Stichwort Fußbodenheizung Trägheit, Plattenheizkörper, Wärmepumpe etc.
Gruß
Hans-Jürgen
Hoi,
die Ventilsteuerung geht mit dem Spritis, dazu muss man aber in den Manuellen Modus schalten (per tmManual glaube) dann kann man per Dim 0-99 den Öffnungsgrad steuern. Macht aber nur Sinn mit PID oder was vergleichbaren meiner Meinung nach ;)
Ronny
Freunde der warmen Wohnküche([@Deckoffizier inbegriffen), in diesem Beitrag Antworten, allgemeine Anmerkungen.
Zitat von: Beta-User am 19 September 2020, 14:00:35
OK, dann sprechen wir vermutlich von einem anderen Produkt.
Nein, wir sprechen über den im Subject angegebenen Thermostat. (Ich vermute aber, dass Deckoffizier einen anderen Thermostaten am Start hat.)
Zitat von: Beta-User am 19 September 2020, 14:00:35
Bislang hattest du dich nicht auf eine Variante festgelegt, sondern erst jetzt mitgeteilt, dass für dich nur die Variante mit dem (aktuellen) desired-temp in Frage kommt. Das ist ok, aber es ist völlig klar, dass da jeder User seine eigene Meinung dazu hat...
Da waren zwei Diskussionsebenen im Spiel. Ja -ich- werde die temperaturgeführte Steuerung (bei mir ist dieser Teil Steuerung, nicht Regelung) nehmen.
Nochmal zu den Begrifflichkeiten, das scheint mir wichtig:
* Moderne Heizungsanlagen sind oft Regelungen, abhängig von der Außentemperatur
* Thermostaten sind (außer: Mode manual) insich autonome Regler
* Wenn ich als Person dem Thermostaten 22°C vorgebe, steuere ich ihn quasi - Sollwertvorgabe ohne meine Nachführung
Tatsächlich hat der Thermostat die via
set ansprechbaren Modi (immer "tm" vorn)
* off (Frostschutz, Regelung 6°C),
* heating (temperaturgeführte Regelung im Thermostaten)
* ernergysaveheating (vmtl. stärkere Dämpfung des Regelglieds)
* manual (man kann von 0-100 drehen, das nutzt Steuermann)
(In den angebotenen FHEM-Optionen für diesen Thermostaten taucht auch noch cooling und auto auf. cooling steht nur zur Verwirrung des Publikums drin, natürlich kühlt der nicht. Bei auto bin ich mir nicht sicher, müsste nachsehen.)
Zitat von: Beta-User am 19 September 2020, 14:00:35
Dementsprechend sollte er
a) irgendwo erfahren, welche Optionen er eigentlich hat und was er sinnvollerweise an Steuerung, Regelung und Umfeldinfos, -Modulen usw. braucht, damit es am Ende jeweils so warm ist, wie er oder seine Familie das gerne hätte ;) .
Ich glaube, Du bist auf der falschen Ebene. Oder zu schnell die Treppe hoch ... ich bin noch auf dem Punkt, dass das neu inkludierte Device einige Attribute und settings und gets nicht hat, was in JEDEM Modus erforderlich ist. Da wäre es halt schön, wenn nicht jeder sich tagelang mit dem Dingens rumärgern muss. Allerdings ist das nicht so einfach, wie es auf den ersten Blick aussieht: Das Dingens ist batteriegestützt, da können Kommandos schon mal verloren gehen - das muss auch abgesichert werden.
OT: Die Anmerkung mit dem Tagessatz bezog sich nicht auf FHEM. Das war für die Situation, dass ein Dipl-Ing. Automatisierungstechnik mehrere voneinander abhängige Regelungen konfigurieren muss.
Zitat von: Beta-User am 19 September 2020, 14:00:35
b) dann ein vereinfachtes Verfahren haben, um zumindest das betreffende Einzeldevice entsprechend seinen (Ziel-) Vorstellungen zu konfigurieren...
Ich verstehe, wo Du hin willst. Aber ich denke, dass das der zweite Schritt ist.
Zitat von: Deckoffizier am 20 September 2020, 23:57:02
Hier schon mal irgendwo gelesen, zur Vorlauftemperaturreglung der Heizungsteuerung benutzt man nicht die Außentemperatur(gängig) als Eingabe, sondern "nur" die Raumtemperatur eines Referenzraumes zum ? Energiesparen.
Es gibt zig Versionen. Nur mal EIN Beispiel: Ich habe ein Niedrigenergiehaus mit einer Brennwertgasheizung. Bei 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.
Zitat von: Deckoffizier am 20 September 2020, 23:57:02
Und Ja, ich benutze für die Raumtemperatur Messung die Fibaro Multisensor(Magische Auge) Teile und bin damit soweit Zufrieden.
Habe die Sensoren auf die ober unter Teile einer Messing Duftöllampe geschraubt und hat somit einen gewissen Schick ;)
Magst Du zwecks Auflockerung mal ein Foto zeigen?
Zitat von: Deckoffizier am 21 September 2020, 09:20:43
mein Senf vage ausgedrückt zur Heizungsregelung.....
im OPTIMAL Fall sind bei entsprechender Heizungsanlage Thermostatventile überflüssig.
Sie sollen eigentlich nur den Fremdwärmeanteil wie Z.B. Sonneneinstrahlung, Kochen etc. regeln.
Es ist viel komplexer: Da spielt der k-Wert (Wärmedurchgangskoeffizient) von Wand und Fenster (und deren Flächengrößen) eine Rolle. Und wenn die Rolläden runter sind, ändert das nochmal alles.
Zitat von: Deckoffizier am 21 September 2020, 09:20:43
Bei richtiger Heizkennlinie und Hydraulischen Abgleich(Durchfluss) wären sie immer auf 100% offen.
Eine Art der Regelung wie vorher schon angedeutet wäre eben die Regelung des Kesselschaltfeldes
mit seiner Heizkennlinie und eventuell Mischer nur über die Auswertung der einzelnen Ventilöffnungen in den einzelnen
Räumen wie hier im Forum schon mal vorgestellt.
Ach, so einfach ist das alles nicht, das wäre ja der ideale Mensch. Das mag die Dame des Hauses mit ihrem Gatten noch hinkriegen, ansonsten scheitert es: Den einen ist wichtig, Energie zu sparen. Andere mögen es kuschlig warm im Wohnzimmer. Im Schlafzimmer soll es recht kühl sein - oder manche mögens heiß. Gästezimmer sollen kühl sein - außer: Gäste sind da. Aber jeder Gast ist anders. Bei Damen ist das Wärmeempfinden im Laufe des Monats unterschiedlich - Männer sind aber auch mit subjektiver Wärmeempfindung ausgestattet ...
Zitat von: Deckoffizier am 21 September 2020, 09:20:43
Heizungsregelung ist ein weites Feld und schwer pauschal zu händeln Stichwort Fußbodenheizung Trägheit, Plattenheizkörper, Wärmepumpe etc.
Du sagst es, wir sind uns völlig einig.
Dieser Beitrag geht fragend an alle: DOIF, readingList, setlist.
Zitat von: Deckoffizier am 20 September 2020, 23:57:02
ZitatOffen ist noch das, was @Deckoffizier da mit readingList und setlist macht - beide sind nirgendwo hinreichend (mit Beispielen!) beschrieben. Vermutlich so eine Art Runterklappmenü - aber das rate ich nur.
für setlist ergibt sich z.B nach Auswahl einer zwischenzeitlichen Temperatur z.B. bei 24 Grad nebenstehender Text manuell aktiv oder wie Fenter offen oder Fenster noch offen.
Also ich glaube verstanden zu haben, dass Du vermittels eines Klapp-runter-Menüs Temperaturen allgemein vorgibst, aus denen Du Dir eine Temperatur auswählst. Ich würde gern verstehen, wie man das macht.
(Wie Du das dann in Regelung für Deine Manualregelung umsetzt, spielt für meine Fragestellung keine Rolle - nur dieser erste Teil.)
In https://forum.fhem.de/index.php/topic,105272.msg995598.html#msg995598 lese ich (auf das Relevante gekürzt):
defmod eg_kue_wunschtemp DOIF ([Wunschtemp_temp_eg_kue])
attr eg_kue_wunschtemp do always
attr eg_kue_wunschtemp readingList mantemp
attr eg_kue_wunschtemp setList mantemp:12,17,18,19,20,21,21.5,22,22.5,23,23.5,24,26
attr eg_kue_wunschtemp webCmd mantemp
Es mag ja an meiner mangelhaften Kenntnis von DOIF liegen, Wiki hilft auch nicht (nur ein Stub für setlist, readinglist fehlt völlig), alte Forenbeiträge helfen auch nicht:
In der eckigen Klammer muss ja eigentlich eine Testbedingung stehen, dieses "Wunschtemp_temp_eg_kue" finde ich aber in dem Beitrag nicht wieder - wo kommt das her, was steht da drin?
Bei Gültigkeit der Testbedingung werden offenbar die folgenden Attribute gesetzt, richtig?
Aber was ist "mantemp"? Auf den ersten Blick scheint das ja ein Zahlenwert für Temperatur zu sein. Aber was macht das webCmd da? Steht in mantemp vielleicht ganz was anderes?
Können wir (das muss jetzt wirklich nicht nur Deckoffizier sein) mal bitte schrittweise aufdröseln, was da passiert? (Und was da ggf. fehlt?)
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).
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.
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
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 :)
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
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 (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...
@krikan: Danke fuer die Erklaerung, ich bleibe bei dann weiterhin bei der "Designentscheidung". Je weniger Funkverkehr, desto weniger kann schiefgehen.
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
##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
## 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
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.
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.
@Deckoffizier
Ok, nochmalige Nachfrage.
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.
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:
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
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.
(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?)
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
ZitatWä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?
Ja :)
Es gibts jetzt schon eine Schlange pro Device, und eine pro Controller, mit diversen Timeouts. Batteriegeraete und Security haben spezielle Erfordernisse, set und get ist unterschiedlich zu behandeln, usw.
Eigentlich muesste es komplett neu gebaut werden (ich wuerde nur eine Pro Controller haben wollen, die aber Security und get kennt, nicht nur Low-Level "ACK" fuer die USB-Kommunikation zum Controller), aber ich scheue den Aufwand.
Hallo zusammen,
nachdem das attrTemplate-Framework@ZWave jetzt so halbwegs ein paar Beispiele hat, aus denen man sich bedienen kann, würde ich anbieten, daraus mal das erste "Fremdgeräte-attrTemplate" zu basteln.
Erforderlich wäre dann halt ein kompletter Satz Konfigurationsbefehle, gerne einschließlich der Korrekturen bzgl. "cooling" (Classes...-Attribute)...
(ist halt nicht veränderungfest, wenn get model aufgerufen wird, wie neulich hier in anderem Zusammenhang zu lesen war.)
Wir können die Diskussion auch gerne auslagern, falls dich @curt das stört...
Zitat von: rudolfkoenig am 01 Oktober 2020, 09:09:27
Ja :)
OK, ist verstanden, scheint ja auch so zu funktionieren...
Zitat von: Beta-User am 09 Oktober 2020, 11:03:43
Wir können die Diskussion auch gerne auslagern, falls dich @curt das stört...
Vielleicht ist es wirklich klug, einen neuen Thread zu beginnen. Aber nicht weil mich irgend etwas stören würde. Sondern weil es aus meiner Sicht schön wäre, wenn Du auf Leute wie mich Rücksicht nimmst und gleich im ersten Beitrag des Threads erläuterst, was das soll. Und was man konkret machen muss - in der Art eines Kochrezepts: Nehmen Sie den Kochlöffel, dann rühren Sie mit dem Kochlöffel im Kochtopf rechtsdrehend um, dann nehmen Sie die Salzmühle ...
Der Ersatzthermostat wurde vom Online-Buchladen nicht geliefert, ich muss da nochmal neu bestellen. Aber als ständiger Test ist das vielleicht auch nicht so der Bringer, ich kann ja nicht ständig Thermostate umschrauben. Mal geht das sicher, aber nicht jeden Tag. Ich überlege gerade, was sonst noch so als ZWave-Testobjekt sinnvoll sein könnte ... hat da jemand eine Idee? Haben die batteriebetriebene Bewegungsmelder?
BTW:
Ich muss noch meine Thermostat-Konfiguration hier zeigen. Habe ich nicht vergessen.
Zitat von: curt am 10 Oktober 2020, 02:42:38
Vielleicht ist es wirklich klug, einen neuen Thread zu beginnen. Aber nicht weil mich irgend etwas stören würde.
Dann würde ich eher gerne erst mal hier bleiben, denn , es geht ja grade darum, das "Kochrezept" aufzuschreiben.
Zitat
was man konkret machen muss
"eigentlich" wäre erst mal nur eine geraffte Fassung der Konfigurationsbefehle hilfreich sowie ggf. der weiteren Konfiguration für FHEMWEB.
Zu letzterem: Ich verstehe z.B. nicht, warum du die Soll-Temperatur nicht einfach über ein widgetOverride am Device selbst regelst sondern dafür ein Extra-Device verwendest - das macht m.E. nur dann Sinn, wenn du die Temperatur "indirekt" z.B. über die Ventilstellung regeln willst...
Da du irgendwann das Ersatzgerät geliefert bekommst, wäre das m.E. ideal, um das attrTemplate dann auszutesten (wie das geht, erkläre ich dann schon oder habe ein paar Links...).
ZitatIch überlege gerade, was sonst noch so als ZWave-Testobjekt sinnvoll sein könnte ... hat da jemand eine Idee? Haben die batteriebetriebene Bewegungsmelder?
Das wäre dann ggf. tatsächlich was für einen anderen Thread. Einen Bewegungsmelder habe ich selbst als Tester genommen, nämlich den 6-fach AEOTEC.
Der "kann" übrigens auch Temperatur und könnte - so verstehe ich jedenfalls das Handbuch zu dem Spirit - auch mit dem assoziiiert werden, also als Ist-Temperaturgeber dienen (analog zu dem, was ein Raumthermostat in der HM-Welt machen würde), um solche Probleme (https://forum.fhem.de/index.php/topic,114895.0/topicseen.html) zu lösen oder das Regelverhalten zu verbessern, da nicht direkt an der Heizung gemessen wird...
(und ggf. findet sich auch jemand, der eine Idee hat, wie man dem Teil Wochenprofile beibringt; lt. Handbuch kann der das nämlich, ich habe allerdings bisher nirgendwo was dazu gefunden, was man dazu ggf. wohin senden müßte...).
Zitat
Ich muss noch meine Thermostat-Konfiguration hier zeigen. Habe ich nicht vergessen.
Wie gesagt: das wäre hilfreich, ggf. kann ich dann auch leichter erklären, was ich mit dem widgetOverride meine usw...
Zitat von: Beta-User am 10 Oktober 2020, 06:16:39
Ich verstehe z.B. nicht, warum du die Soll-Temperatur nicht einfach über ein widgetOverride am Device selbst regelst sondern dafür ein Extra-Device verwendest - das macht m.E. nur dann Sinn, wenn du die Temperatur "indirekt" z.B. über die Ventilstellung regeln willst...
Leider verstehe ich Deine Fragestellung nicht.
Beziehst Du Dich darauf, dass ich diese DOIF-Fragen stellte? Oder auf etwas anderes?
Der Thermostat hat zwei grundsätzliche Modi: Entweder temperaturgeführt (das ist meins) oder Ventilöffnung (nach der alten Väter Sitte: Man dreht zu sagen wir 3/4 auf, das nutzt @Deckoffizier ).
Bei der Temperaturführung gibt man dem Thermostat via set eine Sollwerttemperatur vor. Das geht ganz schnöde über die FHEM-Kommandozeile. Der DOIF-Zirkus war nur, weil ich das auch in FHEMWEB "schön" haben will; ansich läuft das bei mir via FTUI-Oberfläche.
Zitat von: Beta-User am 10 Oktober 2020, 06:16:39
nämlich den 6-fach AEOTEC.
Zeige mal bitte Link bei Amazon.
Zitat von: curt am 10 Oktober 2020, 06:25:12
Leider verstehe ich Deine Fragestellung nicht.
Beziehst Du Dich darauf, dass ich diese DOIF-Fragen stellte? Oder auf etwas anderes?
Genau. Das ganze geht auch in FHEMWEB "hübsch", wenn man widgetOverride+webCmd direkt am Thermostaten verwendet.
Beispiel für meine HM-Dinger (Bild mit devStateIcon im Anhang, das betrifft nur das Element ganz rechts):
attr Thermostat_Esszimmer_Gang_Clima webCmd desired-temp
attr Thermostat_Esszimmer_Gang_Clima widgetOverride desired-temp:knob,min:4.5,max:31.5,angleArc:180,width:40,height:40,fgColor:#FF9900,bgColor:#CCCCCC,step:0.5,lineCap:round,angleOffset:225
Zitat
Der Thermostat hat zwei grundsätzliche Modi: Entweder temperaturgeführt (das ist meins) oder Ventilöffnung (nach der alten Väter Sitte: Man dreht zu sagen wir 3/4 auf, das nutzt @Deckoffizier ).
...mir war das schon sehr lange klar, und wenn man die 3/4 errechnen will, braucht man auch das zusätzliche Element... ;D
Link bei Amazon (https://smile.amazon.de/Aeotec-Multi-Sensor-ZW100-C-Z-Wave-Plus/dp/B0141FQDJQ/ref=sr_1_4?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=20RKGAXRPMQ4X&dchild=1&keywords=z-wave+multisensor&qid=1602306091&sprefix=z-wave+mu%2Caps%2C165&sr=8-4) (das soll aber nicht heißen, dass das Ding toll wäre, aber damit kannst du das attrTemplate-feature derzeit testen... Bisher fand ich das jedenfalls nicht so "speziell" wie es angekündigt worden war - abgesehen davon, dass die firmware nicht aktuell ist. Es gibt übrigens noch ein paar 6-fach-Sensoren, die irgendwie alle miteinander verwandt zu sein scheinen (?))
Hallo curt,
ZitatDer Thermostat hat zwei grundsätzliche Modi: Entweder temperaturgeführt (das ist meins) oder Ventilöffnung (nach der alten Väter Sitte: Man dreht zu sagen wir 3/4 auf, das nutzt @Deckoffizier ).
Ist schon etwas missdeutig... die Regelung der Ventilöffnung ist letztendlich auch temperaturgeführt wenn man nicht andere Eingangsgrößen definiert
mit PID20. ;)(zur Gartenbewässerung oder...)
Unter Modi verstehe ich eher bei den set Kommandos beginnend mit tm...... in der Auswahl des Thermostaten.
Bei tmHeating wird letztendlich über internen PID? auch die Ventilöffnung verstellt.
@Beta-User
Zitat...mir war das schon sehr lange klar, und wenn man die 3/4 errechnen will, braucht man auch das zusätzliche Element...
Kommt drauf an was Du mit zusätzlichen Element meinst, wie PID20 oder andere Eigenzüchtung.
Wenn Du externen Temperatursensor meinst es geht auch der innere des Thermostaten selbst!
Es hat bei mir schon seinen Grund warum ich lieber über tmManual gehe.
@curt
vielleicht ein Tipp versuche mal den Ersatzthermostat direkt über den Hersteller zu tauschen hat bei dem einen
defekten bei mir problemlos geklappt.
Gruß
Hans-Jürgen
Zitat von: Deckoffizier am 10 Oktober 2020, 19:07:50
Bei tmHeating wird letztendlich über internen PID? auch die Ventilöffnung verstellt.
Ja, natürlich. Da besteht der Regelkreis aus dem Sollwert als Temperaturvorgabe, dem internen Thermometer, dem Ventilmotor. Wie die Entwickler den Regelkreis auslegten, verraten sie uns nicht.
Da ich in einem Fall vermutlich einen anderen Regelkreis brauche (da muss ein externes Thermometer genutzt werden) kannst Du mir vielleicht bitte mit einer Erklärung helfen: Du erwähnst immer PID20, was ist das denn genau? Ein FHEM-Modul oder wie genau?
Zitat von: Beta-User am 10 Oktober 2020, 07:12:24
ZitatLeider verstehe ich Deine Fragestellung nicht.
Beziehst Du Dich darauf, dass ich diese DOIF-Fragen stellte? Oder auf etwas anderes?
Genau. Das ganze geht auch in FHEMWEB "hübsch", wenn man widgetOverride+webCmd direkt am Thermostaten verwendet.
Ich habe mich gerade in readingsgroup verbissen: Da müsste jeweils das zuständige DOIF in der Zeile mit angezeigt werden. Und das scheint auch zu gehen: Sowohl inner- als auch außerhalb des Forums gibt es entsprechend andeutende Beiträge. Wie es immer so ist: Mit konkreten Beispielen kommt niemand um die Ecke. Und auch meine Anfrage im Forum war bislang erfolglos ... mal ganz abgesehen von meinen eigenen Versuchen.
Zitat von: Beta-User am 10 Oktober 2020, 07:12:24
Link bei Amazon (https://smile.amazon.de/Aeotec-Multi-Sensor-ZW100-C-Z-Wave-Plus/dp/B0141FQDJQ/ref=sr_1_4?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=20RKGAXRPMQ4X&dchild=1&keywords=z-wave+multisensor&qid=1602306091&sprefix=z-wave+mu%2Caps%2C165&sr=8-4) (das soll aber nicht heißen, dass das Ding toll wäre, aber damit kannst du das attrTemplate-feature derzeit testen...
Ok, ich bestelle nachher eins.
Wenn ich das auspacke, mache ich einen neuen Thread auf, dann erzähle ich von der Inklusion und Du erzählst, was ich mit Deinem xml-Dingens anstellen muss? So machen wir das zwecks Belehrung und Erheiterung des Publikums, ja?
Zitat von: Beta-User am 10 Oktober 2020, 07:12:24
Bisher fand ich das jedenfalls nicht so "speziell" wie es angekündigt worden war - abgesehen davon, dass die firmware nicht aktuell ist.
Kann man dem abhelfen?
Zitat von: Beta-User am 10 Oktober 2020, 07:12:24
Es gibt übrigens noch ein paar 6-fach-Sensoren, die irgendwie alle miteinander verwandt zu sein scheinen (?))
Das dürfte an der polnischen Fabrik liegen. Ich weiß nicht mehr ganz genau, wo das war: Irgendwo nahe der polnischen A4, Liegnitz, Breslau, irgendwie diese Ecke. Da steht eine funkelniegelnagelneue Fabrik, ein riesiges Ding, ich stand davor. Die produzieren da SmartHome ohne Ende, vor allem ZWave. Ich vermute, dass erfolgreiche Produkte fleißig gelabelt werden.
Zitat von: curt am 11 Oktober 2020, 03:00:21
Ich habe mich gerade in readingsgroup verbissen: Da müsste jeweils das zuständige DOIF in der Zeile mit angezeigt werden. [...].
Zu DOIF kann ich nichts sagen, meine Vermutung zu dem betreffenden Post in den anderen Thread war schlicht, dass das DOIF-Gerät da nicht von der devspec umfasst war.
Dazu aber noch zwei Anmerkungen:
1. DOIF hat afaik eigene Mechanismen, um was ähnliches wie readingsGroup zu generieren, nennt sich DOIF-uiTable oder so. Ich nutze das nicht, daher nur das Stichwort zur eigenen Vertiefung, falls gewünscht.
2. Du brauchst hier kein DOIF, da du eigentlich ja was an dem Thermostaten selbst regeln willst...! Also wäre meine Empfehlung, dich darauf zu konzentrieren, die notwendigen Dinge ans Laufen zu bekommen, und ein "widgetOverride-aufgehübschtes" Bedienelement erscheint btw. auch genau so in einer readingsGroup. Beispiele zu diversen Thermostat-Varianten sind auch im Wiki zu readingsGroup zu finden.
ZitatWenn ich das auspacke, mache ich einen neuen Thread auf, [...]
Es gibt zu diesem attrTemplate eigentlich schon einen Thread, in den du dich auch einklinken könntest (wenn du magst, sonst kannst du auch was eigenes aufmachen). Den Thread findest du dann z.B. auch über das attrTemplate (das sollte auch über den Spirit zu erreichen sein. Kochrezept: Defailseite aufrufen, setter "attrTemplate" auswählen, die Liste mit den Pfeiltasten durchgehen, dann erscheint direkt drunter ein Abschnitt, in dem Erläuterungstext steht und das, was das betreffende template dann eigentlich tun würde. In dem "Trenner" zu AEOTEC steht dann auch ein Link zu dem Infobereich, in dem die Fa. Infos zu allen Geräten bereithält.
ZitatKann man dem abhelfen?
Dort gibt es dann auch eine Windows-Software, mit der man das tun könnte - vorausgesetzt, man hätte ein passendes Gerät zur Hand (daran hapert es bei mir grade...).
ZitatDas dürfte an der polnischen Fabrik liegen. [...] dass erfolgreiche Produkte fleißig gelabelt werden.
...so in der Richtung war meine Gedankenführung auch; ist doch schön, dass es EU-Produkte sind :) . Wenn wir die Jungs von Fibaro jetzt noch überzeugen könnten, dass es verkaufsfördernd wirken würde, wenn sie firmware-updates auch allgemein zugänglich machen, wären wir wieder einen Schritt weiter (wobei alle ZWave-Geräte in meinem Zoo bisher anstandslos funktioniert haben, wenn man mal davon absieht, dass die Beipackzettel eben ggf. zu aktuell waren, wie im Fall von dem (gebraucht erworbenen) 6-fach-Sensor).
Hallo curt,
ZitatJa, natürlich. Da besteht der Regelkreis aus dem Sollwert als Temperaturvorgabe, dem internen Thermometer, dem Ventilmotor. Wie die Entwickler den Regelkreis auslegten, verraten sie uns nicht.
Ja ist auch meine denke.
zu
ZitatDa ich in einem Fall vermutlich einen anderen Regelkreis brauche (da muss ein externes Thermometer genutzt werden) kannst Du mir vielleicht bitte mit einer Erklärung helfen: Du erwähnst immer PID20, was ist das denn genau? Ein FHEM-Modul oder wie genau?
gerne nochmal, ja es ist ein FHEM Modul schau sonst mal ins FHEM Wiki.
Externes Thermometer muss nicht sein, man kann ja auch das interne des Thermostaten nutzen aber macht nicht unbedingt Sinn.
;) Wenn Du nicht gerade in einem Bunker wohnst oder KWL hast ist die Fenster offen Beachtung bei der Regelung nicht so relevant.
Aber wenn Du es in Deiner von Deiner Heizung entfernten "Kuschelecke" warm haben möchtest macht die Platzierung dort (ok. Gegenargument Offset)
eines externen Thermometers schon Sinn, dazu wenn Du es hinbekommst mit PID20 besser zu sein als die original Regelstrategie?
Auch lässt sich sehr gut das Regelverhalten visualisieren und eventuelle Schwachpunkte an der Heizungsreglung erkennen
(Ventilöffnungszeiten,Abweichungen vom Soll,Wettereinfluss etc.)
Mach noch ein List vom PID20 dran.
Internals:
DEF Kuechesensor:temperature KUECHE_ZW_THERMOSTAT:dim
FUUID 5cbcf503-f33f-cca1-5cc5-64f58c16b53df6e5
NAME pidregler_kueche
NR 296
NTFY_ORDER 50-pidregler_kueche
STATE processing
STILLDONETIME 0
TYPE PID20
VERSION 1.0.0.9
Helper:
DBLOG:
actuation:
myDbLog:
TIME 1602403954.06508
VALUE 11
actuationCalc:
myDbLog:
TIME 1602403954.06508
VALUE 10.5200000000051
desired:
myDbLog:
TIME 1602403954.06508
VALUE 22
measured:
myDbLog:
TIME 1602403954.06508
VALUE 21.9
p_i:
myDbLog:
TIME 1602403773.49874
VALUE 5.46000000000499
p_p:
myDbLog:
TIME 1602403954.06508
VALUE 5.00000000000007
READINGS:
2020-10-11 10:12:34 actuation 11
2020-10-11 10:12:34 actuationCalc 10.5200000000051
2020-10-11 10:12:34 delta 0.100000000000001
2020-10-11 10:12:34 desired 22
2020-10-11 10:12:34 measured 21.9
2020-10-11 10:12:34 p_d 0
2020-10-11 10:12:34 p_i 5.52000000000499
2020-10-11 10:12:34 p_p 5.00000000000007
2020-10-11 10:12:34 state processing
helper:
actor KUECHE_ZW_THERMOSTAT
actorCommand dim
actorErrorAction errorPos
actorErrorPos 5
actorInterval 300
actorKeepAlive 3600
actorLimitLower 0
actorLimitUpper 99
actorThreshold 1
actorTimestamp 2020-10-11 10:12:34
actorValueDecPlaces 0
adjust
calcInterval 180
deltaGradient 0
deltaOld 0.100000000000001
deltaOldTS 2020-10-11 09:56:09
deltaTreshold 0
desiredName desired
disable 0
factor_D 0
factor_I 0.2
factor_P 50
isWindUP
measuredName measured
reading temperature
regexp ^([\+,\-]?\d+\.?\d*$)
reverseAction 0
sensor Kuechesensor
sensorTimeout 7200
stopped 0
updateInterval 600
Attributes:
DbLogExclude state,delta,p_d
DbLogInclude measured,desired,actuation,p_p,p_i,actuationCalc
event-min-interval actuation:300,actuationCalc:300,delta:300,desired:300,measured:300,p_d:300,p_i:300,p_p:300
event-on-change-reading actuation:1,actuationCalc:0.5,delta:0.5,desired,measured:0.5,p_d:0.1,p_i:1.0,p_p:1.0
group Thermostate
pidActorErrorAction errorPos
pidActorErrorPos 5
pidActorInterval 300
pidActorKeepAlive 3600
pidActorLimitLower 0
pidActorLimitUpper 99
pidActorTreshold 1
pidActorValueDecPlaces 0
pidCalcInterval 180
pidDeltaTreshold 0
pidFactor_D 0
pidFactor_I 0.2
pidFactor_P 50
pidSensorTimeout 7200
room Wohnung->KücheGruß
Hans-Jürgen
Vielleicht noch ein paar Fragen von meiner Seite an die ZWave-Experten hier:
Im Wiki zum Spirit steht nichts zur Assotiation mit einem externen, abgesetzten Thermometer. Lt. Doku sollte das aber gehen. Warum ist das nicht im Wiki zu finden? Hat es nur noch keinen interessiert, oder gab es dazu erfolglose Versuche?
Und wenn es geht, und man ggf. z.B. den AEOTEC im Batteriemodus dafür nimmt: Wie geht das dann mit den Timings? Die müssten ja zur selben Zeit Sende- bzw. empfangsbereit sein (bei HM machen die Geräte da eine Zeit aus, wenn ich's richtig verstanden habe)? Oder wird die Nachricht einfach "irgendwo" gepuffert? (Auf dem im Mesh nächstgelegenen Repeater-Device? Wenn ja, wie lange, bzw. mit welchem Verfallsdatum...?)
Und gäbe es ggf. auch die Möglcihkeit, virtuelle Devices anzulegen und mit denen zu assoziieren?
Steht sowas im Paetz? (Braucht man den als ZWave-User unbedingt...?)
Fragen über Fragen... ::)
Zitat von: Beta-User am 11 Oktober 2020, 14:58:23
Im Wiki zum Spirit steht nichts zur Assotiation mit einem externen, abgesetzten Thermometer. Lt. Doku sollte das aber gehen. Warum ist das nicht im Wiki zu finden? Hat es nur noch keinen interessiert, oder gab es dazu erfolglose Versuche?
Schau mal unter https://wiki.fhem.de/wiki/Z-Wave-Eurotronic_Spirit_Thermostat#Links . Dort sind zumindest die mir bekannten Forenbeiträge verlinkt. Wer es ausführlich im Wiki haben möchte, darf das gerne einbauen. :)
ZitatUnd wenn es geht, und man ggf. z.B. den AEOTEC im Batteriemodus dafür nimmt: Wie geht das dann mit den Timings? Die müssten ja zur selben Zeit Sende- bzw. empfangsbereit sein (bei HM machen die Geräte da eine Zeit aus, wenn ich's richtig verstanden habe)? Oder wird die Nachricht einfach "irgendwo" gepuffert? (Auf dem im Mesh nächstgelegenen Repeater-Device? Wenn ja, wie lange, bzw. mit welchem Verfallsdatum...?)
Das Spirit lauscht immer, da FLiRS-Gerät. Da muss nichts abgestimmt und zwischengespeichert werden.
ZitatUnd gäbe es ggf. auch die Möglcihkeit, virtuelle Devices anzulegen und mit denen zu assoziieren?
Schau bitte noch mal unter dem oben genannten Wiki-Links bzw. dem dort verlinkten Forenbeitrag. 8)
ZitatSteht sowas im Paetz? (Braucht man den als ZWave-User unbedingt...?)
Im speziellen vermutlich nicht. Paetz ist ein allgemeiner Überblick über ZWave. Hat mir zumindest zum Verständnis geholfen und ist meines Wissen nach die einzige ausführliche ZWave-Beschreibung die halbwegs anwenderverständlich ist. Man braucht es definitiv nicht; alles steht auch irgendwo im Netz, in den Specs usw.
Gruß, Christian
Zitat von: Beta-User am 11 Oktober 2020, 14:58:23
Im Wiki zum Spirit steht nichts zur Assotiation mit einem externen, abgesetzten Thermometer.
Vermutlich diese beiden kryptischen Beiträge: https://forum.fhem.de/index.php/topic,77598.msg701397.html#msg701397
Ihr seid aber gedanklich immer so schnell, ich bitte um Aufklärung:
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?
Ich frage nicht ohne Grund:
In einem Raum gibt es bei mir schon das Problem, dass es eigentlich einen Regelkreis mit einem externen Thermometer geben muss ... die Gattin schümpft schon dolle.
Zitat von: Beta-User am 11 Oktober 2020, 14:58:23
Steht sowas im Paetz? (Braucht man den als ZWave-User unbedingt...?)
Und wer ist nun wieder Herr Paetz? Bzw: Wo kann man dessen Werk einsehen?
Zitat von: Beta-User am 11 Oktober 2020, 14:58:23
Fragen über Fragen... ::)
Du sprichst mir aus dem Herzen.
EDIT: verunglückter Edit, ursprünglicher Text ist leider weg, war ein Verweis auf myUtils-Code aus https://forum.fhem.de/index.php/topic,77598.msg710737.html#msg710737
Zitat von: curt am 12 Oktober 2020, 05:29:33
Und wer ist nun wieder Herr Paetz? Bzw: Wo kann man dessen Werk einsehen?
https://www.thalia.de/shop/home/artikeldetails/ID40364151.html
Zitat von: curt am 12 Oktober 2020, 05:29:33
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:
ZitatSpirit 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).
Jetzt habe ich versehentlich den vorherigen Beitrag editiert, statt nur ein Zitat daraus zu verwenden...
Zitat
[...] 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 (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....)
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
Es gibt eine 4. Variante über den setter, den Rudi aaO. eingebaut hat:
Zitat von: rudolfkoenig am 06 Dezember 2019, 11:46:38
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:
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.
ZitatEs 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.
ZitatWü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?
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:
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
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.
Hallo Beta-User,
Danke für die Erläuterung zu Variante 4 macht einiges klarer!
ZitatUnd 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
@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
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.
Zitat von: rudolfkoenig am 12 Oktober 2020, 20:05:26
Meiner Ansicht nach gehoert das als setList Attribut an das Geraet, mit der Liste der gewuenschten Befehle, in der Art
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?
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.)).
Zitat von: Beta-User am 13 Oktober 2020, 10:16:30
(v.a.) @krikan: Deine Meinung dazu?
Bisher: Keine. :) Habe keine Ahnung wie genau ich mir das vorstellen darf und wie Rudi das umsetzen will.
Zitat(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
Zitat.. wie Rudi das umsetzen will.
Bisher gar nicht, ich habe ja nur geschrieben, wie ich das vorstelle :)
ZitatUnd 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.
ZitatEs müsste doch einen Controller geben, über den man die betreffenden Messages ersniffen könnte...?
Hurrah, ein neuer
OpferTester fuer mein eingeschlafenes ZWCUL Projekt :)
Zitat von: krikan am 13 Oktober 2020, 10:51:45
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.
attr <spirit> setList sml_temperaturezu konfigurieren und könnte dann den setter sml_temperature benutzen:
set <spirit> sml_temperature 22.4Das ZWave-Modul würde dann das ganze in den passenden Sendecode umwandeln und dem betreffenden Spirit als externe Temperatur übermitteln. That's all...
ZitatWenn Du das auf das Spirit beziehst und der Aussage auf https://eurotronic.org/produkte/z-wave-heizkoerperthermostat/spirit-z-wave-plus/ (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:
ZitatSchaltzeiten 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... ;D
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).
Zitat von: rudolfkoenig am 13 Oktober 2020, 11:02:00
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...
Zitat von: rudolfkoenig am 13 Oktober 2020, 11:02:00
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...
Zitat von: Beta-User am 13 Oktober 2020, 11:58:51
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... ;D
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.
...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 (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 (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... ::)
Zitat von: krikan am 13 Oktober 2020, 13:14:19
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.
Zitat von: Beta-User am 13 Oktober 2020, 13:59:44
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.
Ich habe das oben erwaehnte setList Attribut implementiert:
ZitatsetList
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.
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.
Zitat von: curt am 14 Oktober 2020, 03:05:33
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.
...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 { 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!
Zitat von: krikan am 14 Oktober 2020, 08:13:09
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?
Zitat von: Beta-User am 14 Oktober 2020, 08:28:07
...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.
Zitat von: Beta-User am 14 Oktober 2020, 08:28:07
@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.
Zitat von: Beta-User am 14 Oktober 2020, 08:28:07
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. ;)
Zitat von: Beta-User am 14 Oktober 2020, 08:28:07
OK, verstanden, Hersteller Eurotronics kommt auf die "zwilichtig"-Liste...
Überfliege mal unauffällig https://forum.fhem.de/index.php?topic=114669.msg1088958#msg1088958
Zitat@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.
@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.
Zitat von: rudolfkoenig am 14 Oktober 2020, 09:51:11
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.
Zitat von: Beta-User am 14 Oktober 2020, 10:07:15
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.
ZitatEvtl. 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.
Zitatden 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.
Zitat von: rudolfkoenig am 14 Oktober 2020, 10:52:37
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.
Wir reden ueber Daten, die im Normalfall nicht benoetigt werden, siehe diesen Wiki Abschnitt (https://wiki.fhem.de/wiki/Z-Wave#Welche_Infos_sollten_Anfragen_im_ZWave-Forum_enthalten.3F).
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.
Zitat von: rudolfkoenig am 14 Oktober 2020, 10:52:37
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.
ZitatIch 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" :) .
Zitat von: curt am 14 Oktober 2020, 08:55:24
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
Zitat von: Beta-User am 14 Oktober 2020, 08:28:07
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!?
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 ::) .
Zitat von: krikan am 15 Oktober 2020, 18:52:40
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?".
Zitat von: curt am 16 Oktober 2020, 02:06:39
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 (https://wiki.fhem.de/wiki/AttrTemplate#Syntax) und ziemlich viele Beispiele 8) . (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?
Zitat
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!)
Zitat von: Beta-User am 16 Oktober 2020, 07:20:06
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:
Zitatdeleteattr 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.
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).
Vielleicht auch noch zu dem hier aus dem list im Parallel-Thread:
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:
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 (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"...
Zitat von: Beta-User am 16 Oktober 2020, 10:01:46
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...
Zitat von: Beta-User am 16 Oktober 2020, 13:57:28
Vielleicht auch noch zu dem hier aus dem list im Parallel-Thread:
Gefährlich - das hätte ich fast überlesen ... weil versteckt.
Zitat von: Beta-User am 16 Oktober 2020, 13:57:28
Da hätte ich auf der vorhandenen Basis erst mal folgende Verbesserungsvorschläge, die die Error-Einträge im Log beseitigen sollten:
Zitat
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.
Zitat von: Beta-User am 16 Oktober 2020, 13:57:28
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?
Zitat von: Beta-User am 16 Oktober 2020, 13:57:28Wä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.
Zitat von: Beta-User am 16 Oktober 2020, 13:57:28Ü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.
Zitat von: krikan am 16 Oktober 2020, 19:39:32
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?)...
Zitat von: Beta-User am 17 Oktober 2020, 07:49:06
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. :(
Zitatwird 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.
Zitatirritiert 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.
ZitatWissen 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.
ZitatAndererseits, 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".
Zitat von: rudolfkoenig am 17 Oktober 2020, 11:56:24
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.
Mit der alten Version von AttrTemplate und dem alten zwave.template gibt es "nur" eine Fehlermeldung im FHEM-Log:
Zitat2020.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".
Zitat von: rudolfkoenig am 17 Oktober 2020, 11:56:24
Es muss option:{1} heissen
Die template-file hatte ich zwischenzeitlich irgendwann auf "global" geändert gehabt; (der Doppelpunkt war und ist schon immer vorhanden).
Zitat
desired-temp [...] hatte eine Sonderbehandlung in FHEMWEB
...nicht nur in FHEMWEB, auch WeekdayTimer (bzw. Heating_Control) behandelt das anders (werde bei Gelegenheit auch noch setpointTemp dazunehmen).
Zitat
Jein. Ich weiss, zu welcher Hex-Befelsfolge ein ACK gehoert, nicht aber zu welchem lesbaren FHEM-Befehl. [...]
Hmm, ok, ich kann so langsam die Probleme erahnen...
Vielleicht einfach eine Rückmeldung von einem relativen ZWave-Neuling:
Zum einen hat mich schon immer irritiert, dass ziemlich viele Anweisungen in state landen (mehr oder weniger alle (?) set-( und get-) Anweisungen?). Bei reinen Aktoren (wie ich sie bisher hatte) ist das nicht weiter dramatisch, irgendwann landet dann ja auch wieder was "normales" in state.
Grundsätzlich bin ich weiter - wie wir das auch schon @MQTT2_DEVICE mal (im Zusammenhang mit der Entstehung von setStateList) diskutiert hatten - ein Fan davon, dass man bei bidirektionalen Protokollen die Übergangszustände (hier z.B. set <device> on => (state:) set_on => ACK => on) "sichtbar" macht und ggf. auch entsprechende Events generiert.
Tendenziell vermute ich auch, dass das "das kleinere Übel" gegenüber dem Beibehalten des fehlenden "Rückwärtsmappings" wäre. In vor liegendem Fall v.a. auch, weil sonst jeder user irgendwelche Workarounds bastelt wie das mit der regelmäßigen Abfrage der aktuellen Solltemperatur, nur um rauszufinden, ob denn die Anweisung wirklich angekommen war. Solche Abfragen führen letztlich nur zum früheren Batterie-Tausch...
In meiner vereinfachenden Denkweise könnte man ggf. auch einfach anhand des Zeitstempels entscheiden, zu welchem Reading ggf. ein ACK gehört und ob es Events auslösen soll. Sowas würde eventuell (auch bei secure?) "nur" voraussetzen, dass man aus dem HEX-Code des ACK in etwa ablesen könnte, zu welchem Reading es gehört?
Ist aber zugegebenermaßen alles irgendwie noch nicht zu Ende gedacht.
Hallo ,
@curt
bin mir bei den ganzen Problemen nicht mehr sicher ob Du auch
Schwierigkeiten mit der Anzeige der Ventilstellung hattest, oder nur beim ausprobieren des neuen Template für den Spirit?
aus dem List vom Spirit von Dir hast Du
2020-10-16 01:42:26 configValveOpeningPercentageReport 0
setze es mal auf eins.
Gruß
Hans-Jürgen
Zitat von: Deckoffizier am 19 Oktober 2020, 19:28:40
bin mir bei den ganzen Problemen nicht mehr sicher ob Du auch
Schwierigkeiten mit der Anzeige der Ventilstellung hattest, oder nur beim ausprobieren des neuen Template für den Spirit?
Nein, habe ich nicht.
In den Modi Heating und EnergySaveHeating kommt die Ventilstellung im Reading
reportedState, selbst wenn "configValveOpeningPercentageReport 0" gesetzt ist.
Keine Ahnung warum - sonderlich logisch klingt das auch nicht, da hast Du recht.
Zitat von: Deckoffizier am 19 Oktober 2020, 19:28:40
aus dem List vom Spirit von Dir hast Du
2020-10-16 01:42:26 configValveOpeningPercentageReport 0
setze es mal auf eins.
Da ist übrigens ein Fehler in "lies doch mal commandref" - da wird behauptet, dass ich auf "0" oder "1-100" setzen kann.
Hallo curt,
ZitatDa ist übrigens ein Fehler in "lies doch mal commandref" - da wird behauptet, dass ich auf "0" oder "1-100" setzen kann.
Wieso Fehler "1-100" bezieht sich doch auf Delta laut Hilfetext, also 1 wäre schon mal die kleinste Änderung.
Komisch..... habe es bei mir mal auf 0 gesetzt reportedState ist dann off ??
Fang mich an zu wundern, nach höherer Temp einstellen in FHEM lese ich direkt am Thermostaten 100 soweit ok,
aber in kurzen Abständen höre ich den Motor immer wieder takten(kurz arbeiten) obwohl bleibt bei 100.
Stelle es mal wieder zurück auf 1. Probiere es doch ruhig mal aus, kann ja nicht schaden?
Gruß
Hans-Jürgen
Zitat von: Deckoffizier am 21 Oktober 2020, 11:55:17
Komisch..... habe es bei mir mal auf 0 gesetzt reportedState ist dann off ??
Das liegt möglicherweise daran, dass Du Deine Thermostaten in diesem Ventilstellungsmodus betreibst, ich die aber im Heating-Modus betreibe. Es ist jedenfalls so, dass der Wert bei allen Thermostaten auf 0 steht, ich aber die Ventilstellungen bekomme und in FTUI darstelle. Ok, einen habe ich jetzt auf 1.
Ich bin Dir für Deine Hinweise dankbar, immer. Das weißt Du. - Im Moment, sei nicht böse, ist das für mich ein Nebenkriegsschauplatz. Und selbst battery ist derzeit ein Nebenkriegsschauplatz: Ich halte alle Werte alle 24h aktiv ab und gut ist. Und ich habe allen erzählt, dass das bei mir nicht automatisch geht - irgendwann liest jemand das und schreibt "aber so geht das doch" oder schreibt "battery fehlt bei mir auch" oder noch was anderes. Ziel erreicht.
Zitat von: rudolfkoenig am 18 Oktober 2020, 11:18:36
Mit der alten Version von AttrTemplate und dem alten zwave.template gibt es "nur" eine Fehlermeldung im FHEM-Log [..]
Ich fand und finde nichts. Schiebe es mal auf Perl 5.24.
Danke für die Logmeldungen.
Zitat von: Beta-User am 19 Oktober 2020, 10:32:14
Vielleicht einfach eine Rückmeldung von einem relativen ZWave-Neuling:
Zum einen hat mich schon immer irritiert, dass ziemlich viele Anweisungen in state landen (mehr oder weniger alle (?) set-( und get-) Anweisungen?). Bei reinen Aktoren (wie ich sie bisher hatte) ist das nicht weiter dramatisch, irgendwann landet dann ja auch wieder was "normales" in state.
https://wiki.fhem.de/wiki/Z-Wave#Warum_bleibt_der_Status_.28STATE.29_des_neu_inkludierten_Ger.C3.A4tes_dauerhaft_auf_.22associationAdd_.3CassociationGroup.3E_.3CCtrlNodeId.3E.22_stehen.3F sollte darauf hinweisen. Ist leider nicht optimal formuliert.
ZitatGrundsätzlich bin ich weiter - wie wir das auch schon @MQTT2_DEVICE mal (im Zusammenhang mit der Entstehung von setStateList) diskutiert hatten - ein Fan davon, dass man bei bidirektionalen Protokollen die Übergangszustände (hier z.B. set <device> on => (state:) set_on => ACK => on) "sichtbar" macht und ggf. auch entsprechende Events generiert.
Das Attribut showSetInState beim ZWDongle-Device kennst Du?
Gruß, Christian
Zitat von: krikan am 25 Oktober 2020, 08:52:23
Das Attribut showSetInState beim ZWDongle-Device kennst Du?
Ups, war mir neu...
Hab's jetzt mal aktiviert. Allerdings ist das in zweierlei Hinsicht dem ersten Empfinden nach nicht ganz optimal. Zum einen ist es nicht der default, und der wird nicht ganz ohne Grund so gesetzt sein. Wenn ich das jetzt (für attrTemplate-Zwecke) zum "Quasistandard" erheben wollte, wäre das schon deswegen nicht optimal, weil jeder andere vermutlich auch wieder über diese Kleinigkeit stolpert oder ggf. ein neues Verhalten von anderen Devices sehen würde.
Gravierender finde ich (vorläufig!), dass das alles in "state" stattfindet. Wenn man z.B. "thermostatSetpointSet" setzt, bekommt man entsprechende Veränderungen in "state", aber das (m.E. dazu passende Reading (?!?) setPointTemp macht keinen Mucks.
Von daher beschränkt sich der Vorteil auf "on/off"-Devices (da hat man "normale" Übergänge) und den Effekt, dass man überhaupt ein Event an dem Gerät hat, das man dann ggf. wieder auswerten kann, so jedenfalls mein vorläufiges Verständnis.
Was mich andererseits etwas wundert, ist das etwas "stiefmütterliche Dasein" von "transmit". Das wird hübsch aktualisiert, allerdings nicht triggernd (so deute ich jedenfalls meine Beobachtungen iVm. Zeilen 5081ff). Kann ich auf den ersten Blick nachvollziehen, soweit alles ok ist, aber dass sich niemand "die Mühe macht", über eventuelle Probleme zu informieren, finde ich seltsam, spontan hätte ich zumindest NO_ACK (auch) in state erwartet.
Bin mit den Gedanken dazu noch nicht am Ende, aber wäre es nicht eine Idee, beim Erhalt von "ACK"-Messages eine Art "extendedUserReadings"-Logik anzuflanschen? Darüber könnten eventuell zu setzende Readings als Hash zurückgeliefert werden, man könnte feststellen, was in state an set-Anweisungen drin war (anhand des Zeitstempels abzuschichten!) und dann z.B. eben auch "desired-temp" mit dem füttern, was via "desired-temp" ODER "thermostatSetpointSet" verschickt worden war? Wäre m.E. besser, als erst ein "nachgelagertes Event" über das IO-Attribut zu erzeugen, damit man hinterher ggf. in anderen Readings "aufräumen" kann.
Gedanklich hänge ich dabei noch etwas an get-Abfragen. Die "sieht" man nach dem Absenden vermutlich nicht mehr, so dass es schwierig ist zu unterscheiden, ob eine setPointTemp-Info jetzt wegen einer lokalen Aktion über die Knöpfe am Thermostat reinkommt oder als Rückgabe einer entsprechenden Anfrage...
(Schwierig, puh; hoffe, es ist wenigstens verständlich, was ich meine?).
Zitat von: curt am 26 Oktober 2020, 05:27:43
@Beta-User , [...] kommt bei Dir automatisch das Reading battery?
(Ich hoffe, Du bist nicht maulig, ich hab noch Außenstände. Ich weiß.)
Bin nicht maulig, sondern versuche erst mal zu beobachten, was passiert, wenn ich eines nach dem anderen an Einstellungsmöglichkeiten ausprobiere... (nebenbei will ich das Twilight-Ding wieder reparieren, das hat Prio).
battery kommt (ohne separate Anfrage, jedenfalls jetzt in 2 Nächten), ich habe aber mit 0.9 scheinbar nicht die neueste firmware-Version; das scheint 0.10 zu sein?
Gemessene Temperatur wurde bisher scheinbar genau nur 1x übertragen, den Threshold habe ich jetzt mal auf 2 gesetzt, was aber bis dato auch nicht dazu geführt hat, dass das Ding dazu nochmal was gesagt hätte.
Weiter habe ich jetzt den Valve-Wert mal auf 1 gesetzt, aber auch da: Funkstille bisher. Das Ding hängt aber in einem Abstellraum, kann sein, dass das Ventil einfach unverändert "zu" ist...
In meinem userReadings-Versuch war btw. noch ein bug drin, das verbesserte lautet aktuell:
attr ZWave_THERMOSTAT_20 userReadings energySaveHeating:setpointTemp.+energySaveHeating {ReadingsNum($name,"setpointTemp",0)}, heating:setpointTemp.+heating {ReadingsNum($name,"setpointTemp",0)}, thermostatMode:setpointTemp.+ {ReadingsVal($name,"setpointTemp",0)=~m/(heating|energySaveHeating)/;; $1?$1:undef}
Zitat von: Beta-User am 26 Oktober 2020, 13:12:17
battery kommt (ohne separate Anfrage, jedenfalls jetzt in 2 Nächten), ich habe aber mit 0.9 scheinbar nicht die neueste firmware-Version; das scheint 0.10 zu sein?
Vermutlich 0.20. Jedenfalls sind meine acht alle 0.20. Aber wer weiß das schon genau.
Zitat von: Beta-User am 26 Oktober 2020, 13:12:17
Gemessene Temperatur wurde bisher scheinbar genau nur 1x übertragen, den Threshold habe ich jetzt mal auf 2 gesetzt, was aber bis dato auch nicht dazu geführt hat, dass das Ding dazu nochmal was gesagt hätte.
Da ist es wieder, das Problem. Das Ding ist wenig gesprächig, man muss da viel mit GET abholen. Womit wir wieder bei meiner Bringeschuld sind - ich muss meine Konfiguration mal zeigen (und der Kritik stellen).
Hallo curt,
Dein Text
ZitatVermutlich 0.20. Jedenfalls sind meine acht alle 0.20. Aber wer weiß das schon genau.
Also sind wir erst mal bei 4 verschiedenen Firmware wenn ich bei mir
App 0.15 HW 49 FWCounter 1 FW 0.10 nicht mit zähle.
Wenn bei Dir FW 0.20.
nicht version:Lib 3 Prot 4.61 App 0.16 HW 49 FWCounter 1 FW 0.2 ist bist Du von den Meldungen erst mal damit alleine?
Gruß
Hans-Jürgen
Nochmal vollständig - bei mir:
version:Lib 3 Prot 4.61 App 0.16 HW 49 FWCounter 1 FW 0.2
Ok, das mit 0.20 oder 0.2 scheint ja geklärt zu sein. Damit ist meines mit 0.9 neuer als deine mit 0.2, oder?
Nach dem hier (https://community.home-assistant.io/t/eurotronic-spirit-thermostats-firmware-issues/142058/2) zu urteilen gibt es seit ca. Okt. 19 eine fw 0.16, von daher würde ich mal tippen, dass die einfach hinter dem Punkt weiterzählen.
Habe da mal eine Supportanfrage gestartet und darum gebeten, zum einen mitzuteilen, wo man aktuelle firmware bekommt und zum anderen, wie diese komische Werbeaussage mit den Schaltzeiten zu verstehen ist... Mal sehen, (ob) was von da kommt, die scheinen ja eher für beredtes Schweigen berühmt zu sein ::) . Über das HCL (https://forum.fhem.de/index.php/topic,115218.msg1095744.html#msg1095744) gab es jedenfalls kein update-Angebot (und auch AEOTEC hat auf der homepage nichts für den nahen Verwandten im Angebot).
Das Regelverhalten mit 0.16 scheint aber lt. der obigen Quelle bei home-assistant.io deutlich besser zu sein...
Hallo Beta-User,
kann leider kein Englisch und will jetzt keine Verwirrung stiften.
ZitatAll of the thermostats run application_version 0.16, except the slightly older one in the bathroom which seems to run on 0.15.
Sprechen wir jetzt von App 0.16, App 0.15 oder von FWCounter 1 FW 0.2 , FWCounter 1 FW 0.10 ?
Was ist bei Dir 0.9 davon?
Meine Versionen...
version:Lib 3 Prot 4.61 App 0.16 HW 49 FWCounter 1 FW 0.10 und
version:Lib 3 Prot 4.61 App 0.16 HW 49 FWCounter 1 FW 0.2
version:Lib 3 Prot 4.61 App 0.15 HW 49 FWCounter 1 FW 0.10
Gruß
Hans-Jürgen
Ups, vermutlich muss ich mir dazu mal ansehen, was die Teile im Detail bedeuten; ich hatte nur auf den letzten Teil (FW) geschaut, das war wohl eine Fehlinterpretation... (scheint jedenfalls als link hier zu stehen: https://wiki.fhem.de/wiki/Z-Wave#Wie_kann_man_die_SDK-Version_eines_Ger.C3.A4tes_herausfinden.3F).
Was ist denn dann die aktuellste Firmware? 0.10?
Hallo Beta-User,
ZitatWas ist denn dann die aktuellste Firmware? 0.10?
Gute Frage ! 0.10 mit App 16 statt App15 mit 0.10 meine bescheidene Vermutung?
Gruß
Hans-Jürgen
Zitat von: Beta-User am 27 Oktober 2020, 13:01:53
Ok, das mit 0.20 oder 0.2 scheint ja geklärt zu sein. Damit ist meines mit 0.9 neuer als deine mit 0.2, oder?
Da bin ich mir eben nicht so sicher.
In einem Beitrag von 2018 taucht schon App 0.16 FW 0.10 auf, siehe https://forum.fhem.de/index.php?topic=77598.45
Meine acht Thermostaten habe ich ab März diesen Jahres in mehreren Tranchen bei Amazon gekauft, die gelten eigentlich nicht als Verkäufer von Ladenhütern.
Da ich mir kürzlich auch einen Spirit zugelegt habe, hier noch eine neue Variante:
Lib 3 Prot 4.61 App 0.16 HW 26 FWCounter 1 FW 0.2
Eine Version mit HW 26 habe ich bisher hier noch nicht gesehen.
Batterie wird aber auch nicht täglich aktualisiert.
Ok, an diesem Punkt möchte ich @rudolfkoenig etwas zur Sache fragen.
Rudolf, es geht um "get [thermostatdevice] version". Wenn ich recht verstand, hast Du das zuständige Modul gecodet. Wenn ich weiter recht verstand, läuft alles auf Byte-Folgen hinaus, die ausgetauscht werden. Vermute ich recht, wenn ich sage, dass Lib, Prot, App, HW, FWCounter, FW quasi schon "Übersetzungen" von Dir sind?
Wenn dem so sein sollte: Kannst Du bitte sagen, was sich dahinter im Original verbirgt?
Liebe Freunde der wohltemperierten Wohnstube, <langer Beitrag>
ich versprach es mehrmals: Ich zeige meine Konfiguration. Es geht mir darum, diese öffentlich zu zeigen - und den Weg, den man dazu nehmen muss. Ich versuche so zu schreiben, dass auch spätere Nutzer mit diesem Beitrag etwas anfangen können. Mir ist bewusst, dass ich möglicherweise Fehler machte, dazu ganz unten.
Ich habe mich entschlossen, auf die Darstellung in meinem Frontend (FTUI) in diesem Beitrag zu verzichten, das würde sonst zu komplex. Aber auch das kann ich gern nachreichen.
Ich habe acht identische Thermostate aus zeitlich verschiedenen Lieferungen (2020-03 bis 2020-09), alle via Amazon. "get version" liefert bei allen
version:Lib 3 Prot 4.61 App 0.16 HW 49 FWCounter 1 FW 0.2
Inbetriebnahme:
Das stellte sich bei fummelig heraus, aus zwei Gründen:
1) Der Thermostat muss relativ nahe (sagen wir 2 Meter) an die Antenne der Basis.
2) Laut Forum bin ich nicht der Einzige, bei dem "UNKOWN" Devices erstellt wurden: Es ist klug, das Attribut "ignoreTypes" bei "autocreate" für die Zeit der Assoziation auszuschalten.
FHEM sagt man nun
set <ZWDongle> addNode onNw
und drückt anschließend den mittleren Knopf am Thermostat. Dort läuft nun ein Countdown ab 120 (Sekunden). Im Idealfall stoppt das Ganze nach sicher mehr als 45 Sekunden, eine Zahl wird angezeigt. Gleichzeitig meldet FHEM, dass die Device xxx_zahl angelegt wurde.
Nun geht man mit dem Thermostat in aller Ruhe in den Raum, in dem der Heizkörper beglückt werden soll, schraubt den Thermostat an. Danach drückt man dort wieder die mittlere Taste: Man hört den Stellmotor, er vermisst quasi das Ventilspiel.
Wir gehen zurück zum Computer, es lauert viel Arbeit: Erstmal den neuen Stand speichern. Danach ist da die eigentliche Arbeit:
1) associationAdd - den korrekten Befehl reicht sicher jemand nach, mir nicht momentan.
2) Wir müssen einige GET absenden, sonst fehlen uns Readings:
get <device> associationAll
get <device> configAll
get <device> versionClassAll
Danach ergibt sich ein Device wie in der Anlage gezeigt (list). Als Raw stellt sich das so dar - nächste Anlage (Das stateFormat ist nicht schön, aber schön geklaut).
In der Folge gehe ich davon aus, dass wir vermittels SET den Modus tmHeating einstellten.
Wirklich dramatisch ist, dass der Thermostat im Grunde nichts zurückmeldet. Es ist schnuppe, ob Du die Temperatur-Soll via SET über FHEM ansagst oder die Dame des Hauses direkt am Thermostat die Temperatur verstellt: FHEM bekommt das nicht mit. Auch die Veränderungen der verschiedenen möglichen Heizungsmodi bekommt FHEM nicht mit. Manche Thermostate bekommen zudem den Batterie-Status nicht mitgeteilt.
Also frisch ans Werk (Anmerkung: Ein Nutzer sagte mir: Alle wichtigen Befehle zweimal, immer "sleep 3 " dazwischen):
Alle halbe Stunde holen wir uns den Status aller Thermostaten, das mache ich in einem Rutsch in einem Befehl, zeige Euch aber nur den ersten Thermostaten:
define Cron.PollZwaveThermostat DOIF ([+00:30]) {fhem("get Thermostat_Arbeitszimmer smStatus;;sleep 3;;get Thermostat_Arbeitszimmer swmStatus;;sleep 3;;get Thermostat_Arbeitszimmer setpoint;;sleep 3;; <weitere Thermostate>")}
attr Cron.PollZwaveThermostat do always
attr Cron.PollZwaveThermostat room 97 Heizung
Bei mir kommt der Batterie-Status nicht freiwillig, also zwingen wir den:
define Thermostat_battery_at_1 at *05:10 get Thermostat_Arbeitszimmer battery;; sleep3;; <weitere-Thermostate>
attr Thermostat_battery_at_1 room 97 Heizung
Und die Sache mit den offenen Fenstern (Geber ist nicht ZWave), da muss ich auf das Gästezimmer zurückgreifen:
define Gaestezimmer_doif DOIF ([Gaeste_Fenster_Strasse:status] =~ "open") \
{fhem("set Thermostat_Gaestezimmer tmOff;;sleep 3;;set Thermostat_Gaestezimmer tmOff;;sleep 3;;get Thermostat_Gaestezimmer thermostatMode;;")} \
DOELSEIF ([Gaeste_Fenster_Strasse:status] =~ "closed") \
{fhem("set Thermostat_Gaestezimmer tmHeating;;sleep 3;;set Thermostat_Gaestezimmer tmHeating;;sleep 3;;get Thermostat_Gaestezimmer thermostatMode;;")}
attr Gaestezimmer_doif room 97 Heizung
Um einem Thermostaten via FHEM-Standard-Interface mit Klapp-Runter-Menü einen neuen Sollwert vorzugeben (da wart Ihr echt zickig) habe ich nach anstrengenden Betteleien dieses:
define di_Thermostat_Arbeitszimmer DOIF ([$SELF:"SollArbeitszimmer"])\
(set Thermostat_Arbeitszimmer desired-temp [$SELF:SollArbeitszimmer];; sleep 3;; set Thermostat_Arbeitszimmer desired-temp [$SELF:SollArbeitszimmer];; sleep 3;; get Thermostat_Arbeitszimmer setpoint)
attr di_Thermostat_Arbeitszimmer do always
attr di_Thermostat_Arbeitszimmer event-on-change-reading SollArbeitszimmer
attr di_Thermostat_Arbeitszimmer readingList SollArbeitszimmer
attr di_Thermostat_Arbeitszimmer room 10 Heizung
attr di_Thermostat_Arbeitszimmer setList SollArbeitszimmer:8,17,18,19,20,21,21.5,22,22.5,23
attr di_Thermostat_Arbeitszimmer stateFormat gewaehlt: SollArbeitszimmer
attr di_Thermostat_Arbeitszimmer webCmd SollArbeitszimmer
Mir geht es in diesem Beitrag grundsätzlich darum, meine Konfiguration zu zeigen. Sie könnte als Basis der weiteren Diskussion dienen. Selbstverständlich und sehr gern darf man kritisieren. Oder weitere Hinweise geben. Ich bin bei sachlicher Kritik nicht nur schmerzbefreit - ich bin sogar sehr dankbar. - (Vielleicht fangen wir aber beim Grundsätzlichen an. Fehlen da wichtige Befehle zum Start?)
Und abschließend noch ein Dank, das liegt mir am Herzen: Sehr viele sehr freundliche Menschen halfen mir, teils auch via PN: Danke!
Hmm, also vorab mal meine eigenen Erfahrungen:
Ich hatte onNw includiert, das ging stressfrei, und es ist bisher auch _kein einziger_ der set- und get-Befehle verloren gegangen, den ich abgesendet hatte.
(Temperaturwerte bekomme ich zwischenzeitlich auch rein, nachdem ich auf "1" gestellt habe).
Von daher _glaube ich_, dass diese Art der Konfiguration eher dazu führt, bestehende Probleme in der Konfiguration des ZWave-Mesh eher zu überdecken oder gar zu verstärken - Rudi ist bestimmt aus guten Gründen sehr sparsam mit Abfragen an welches Gerät auch immer...
Wenn man also überhaupt (@Rudi: was ist mit der Frage nach der ACK-Auswertung?) irgendeinen "ist es angekommen"-Mechanismus braucht, sollte man den wenigstens so "intelligent" machen, dass erneute Anfragen (die nach dem sleep) nur dann gestellt werden, wenn der erwartete Rückgabe-Wert "zu alt" ist.
Wenn wir dafür Code entwicken wollen, sollte das mMn. myUtils-Code sein, ich habe ehrlich gesagt keine Lust, mich wegen dieser Sache hier in DOIF einzudenken und finde myUtils-Code auch einfacher zu (ver-)teilen...
@curt: Irgendwas ist an deinem Mesh komisch, vermutlich würde es Sinn machen, erst mal damit anzufangen, bevor wir workarounds optimieren.
Zitat von: Beta-User am 28 Oktober 2020, 10:04:56
(Temperaturwerte bekomme ich zwischenzeitlich auch rein, nachdem ich auf "1" gestellt habe).
Bitte sehr präzise formulieren: Was hast Du auf "1" gestellt?
Zitat von: Beta-User am 28 Oktober 2020, 10:04:56
Von daher _glaube ich_, dass diese Art der Konfiguration eher dazu führt, bestehende Probleme
Bitte sehr präzise formulieren: Was ist konkret "diese Art der Konfiguration"? Und was ist die andere Art der Konfiguration? Und wie erreicht man diese?
Zitat von: Beta-User am 28 Oktober 2020, 10:04:56
@curt: Irgendwas ist an deinem Mesh komisch
Bitte sehr präzise formulieren: Was erscheint Dir komisch? Und wie hast Du das erkannt?
(Ich habe einen Repeater im ZWave-Netz, das technisch nebenbei.)
Genau
das empfinde ich oft in diesem Forum als störend (bitte fühle Dich nicht persönlich angegriffen): Es kommt nie eine klare Ansage. Nichtmal als "ich glaube, Du hast xyz falsch gemacht". Sondern es kommen nebulöse Andeutungen. Mit denen kann niemand was anfangen.
Zitat von: curt am 28 Oktober 2020, 10:16:34
Bitte sehr präzise formulieren: Was hast Du auf "1" gestellt?
configTemperatureReportThreshold 1
ZitatBitte sehr präzise formulieren: Was ist konkret "diese Art der Konfiguration"? Und was ist die andere Art der Konfiguration? Und wie erreicht man diese?
Das DOIF (wenn ich es richtig verstehe) als Teil der FHEM-Konfiguration ist eigentlich nur ein at, das stumpf wiederholt dieselben "was ist der Status von..."- Befehle raushaut, ohne zu berücksichtigen, ob es eine schon Rückmeldung gab.
MMn. sollte man ReadingsAge() des angefragten Werts prüfen, und dann nur nochmal anfragen, wenn man nicht schon eine Antwort hat. Code dazu liefere ich bei Bedarf bzw. dann nach, wenn das allg. als sinnvolles Vorgehen angesehen wird.
Zitat
Bitte sehr präzise formulieren: Was erscheint Dir komisch? Und wie hast Du das erkannt?
(Ich habe einen Repeater im ZWave-Netz, das technisch nebenbei.)
Eingangs hatte ich geschrieben: Bei mir kommen ALLE Befehle anstandslos an, ich habe aber auch eine ganze Anzahl von netzbetriebenen (230V-) Komponenten, die das Mesh ohne "expliziten Repeater" bereitstellen. Über die hat auch die Inklusion an einer vom USB-Dongle weit entfernten Stelle funktioniert.
Wie man ZWave-Netz optimiert, ist auch für mich relatives Neuland, von daher bitte ich zu entschuldigen, dass ich da eben im Moment auch nicht mehr wie das Stichwort liefern kann und die Überlegung, dass man sich erst mal damit beschäftigen sollte: Ursachenbekämpfung statt workaround eben.
Zitat von: Beta-User am 28 Oktober 2020, 10:38:19
Das DOIF (wenn ich es richtig verstehe) als Teil der FHEM-Konfiguration ist eigentlich nur ein at, das stumpf wiederholt dieselben "was ist der Status von..."- Befehle raushaut, ohne zu berücksichtigen, ob es eine schon Rückmeldung gab.
Da es nie Rückmeldungen gibt, ist das sinnvoll.
Das habe übrigens nicht ich mir ausgedacht, das machten andere, die mit dem Thermostat deutlich vor mir den gleichen Trödel hatten und logischerweise noch haben.
Hier kommen wir übrigens zum Kern:
Wenn das bislang alle (oder viele) falsch machten, Du aber sagen kannst, wie man es richtig macht, wird es höchste Zeit.
Zitat von: Beta-User am 28 Oktober 2020, 10:38:19MMn. sollte man ReadingsAge() des angefragten Werts prüfen, und dann nur nochmal anfragen, wenn man nicht schon eine Antwort hat. Code dazu liefere ich bei Bedarf bzw. dann nach, wenn das allg. als sinnvolles Vorgehen angesehen wird.
Von diesem Absatz habe ich nichts verstanden.
Aber ich ahne da was. Neh, das ist der falsche Ansatz. Wenn ein Reading sich nicht (weil Device von sich aus sendet) aktualisiert, bringt das nichts. Es passiert ja nie.
Zitat von: Beta-User am 28 Oktober 2020, 10:38:19Eingangs hatte ich geschrieben: Bei mir kommen ALLE Befehle anstandslos an, ich habe aber auch eine ganze Anzahl von netzbetriebenen (230V-) Komponenten, die das Mesh ohne "expliziten Repeater" bereitstellen. Über die hat auch die Inklusion an einer vom USB-Dongle weit entfernten Stelle funktioniert.
Du hattest unterstellt, dass in meinem ZWave-Netz was nicht stimmt. Das will ich gar nicht ausschließen. Es hilft mir (und anderen Mitlesern) aber wenig, wenn Du auf die Nachfrage, woran Du das erkanntest, Dich in Allgemeinplätze flüchtest.
Abschließend:
Das ist kein Angriff auf Dich, ganz im Gegenteil. Sondern Du kannst helfen.
Ich bin nicht allein, meine Erkenntnisse gerade in Sachen Readings fielen nicht vom Himmel. Das waren andere User, teils via PN. Klar kann man unterstellen, dass die alle doof sind - und ich auch. Ich sag mal so: Ich bin der
laute, der die Probleme öffentlich macht. Ich kann das, weil mein Fremdbild in diesem Forum mir eher egal ist.
Es geht um etwas ganz anderes:
So ein Thermostat ist keine Rakete. Das darf keine Geheimwissenschaft sein. Ein mittelmäßig begabter Mensch muss in der Lage sein, das Dingens in Betrieb zu nehmen, ohne 300 Schalter zu erraten. (Das Thema hatten wir übrigens schon, warum ist denn zum Beispiel "configTemperatureReportThreshold" nicht standardmäßig auf 1? Weil die Profis sich freuen, dass jeder erstmal drei Wochen rumübt, ja?)
Genau das müssen wir abstellen. Man muss den Thermostat unter FHEM in Betrieb nehmen können, selbst wenn man nicht Deine beeindruckende Kenntnis hat. Das ist doch der Punkt.
P.S. Im Furor Fehlerchen macht .. "configTemperatureReportThreshold" ist auf 5. Bei allen.
Sorry, Fehlinterpretation des DOIF.
Zum Rest: ein andermal, evtl. versuche ich mal, den Zwischenstand zu vertemplaten, damit "Nachahmer" z.B. das mit der "1" bei der Temperatur-Meldung gleich "richtig" haben....
ZitatWenn dem so sein sollte: Kannst Du bitte sagen, was sich dahinter im Original verbirgt?
Ich habe die Bedeutung der Bytes aus der offiziellen ZWave Doku, meine aktuelle Kopie ist SDS13782-Z-Wave-Management-Command-Class-Specification.pdf . Mag sein, dass diese Funktion im Modul anhand einer aelteren Version erstellt wurde, und/oder dass da noch Fehler drin sind.
ZitatRudi ist bestimmt aus guten Gründen sehr sparsam mit Abfragen an welches Gerät auch immer...
Ich habe bei meiner Mini-Installation mit 4 Geraeten mit ZWCUL monitoring gesehen, dass aus nicht nachvollziehbaren Gruenden ein Telegramm ueber 2 Hops geroutet wurde, was pro Richtung 7, beim get mit Antwort 14 Funktelegramme bedeutet. Bei einer grossen Installation nach vielen Daten ohne Grund zu fragen bedeutet mAn nach ueberfluessigen Problemen zu suchen.
Zitat@Rudi: was ist mit der Frage nach der ACK-Auswertung?
Was genau ist damit gemeint?
Bei NACK oder anderen Problemen wird z.Zt. ein Reading gesetzt und ein Event erzeugt.
Zitatwarum ist denn zum Beispiel "configTemperatureReportThreshold" nicht standardmäßig auf 1?
Weil der Hersteller, aus welchem Grund auch immer, meint, dass das so richtig ist, hoffentlich begruendet.
Wir (als FHEM) koennen zwar versuchen, "bessere" defaults zu setzen, bei den vielen ZWave Geraeten ist das aber eine echte Herausforderung, und womoeglich mit neuen Problemen verbunden, die der Hersteller schon analysiert hat.
Zitat von: rudolfkoenig am 28 Oktober 2020, 12:30:33
Ich habe die Bedeutung der Bytes aus der offiziellen ZWave Doku, meine aktuelle Kopie ist SDS13782-Z-Wave-Management-Command-Class-Specification.pdf . Mag sein, dass diese Funktion im Modul
Eine aktuelle vom 6.7.2020 gibt es hier:https://www.silabs.com/documents/login/miscellaneous/SDS13783-Z-Wave-Transport-Encapsulation-Command-Class-Specification.pdf (https://www.silabs.com/documents/login/miscellaneous/SDS13783-Z-Wave-Transport-Encapsulation-Command-Class-Specification.pdf)
Edit:
Leider nicht richtig gelesen....
Die Version von @rudolfkoenig ist aktuell
Zitat von: rudolfkoenig am 28 Oktober 2020, 12:30:33
Was genau ist damit gemeint?
Bei NACK oder anderen Problemen wird z.Zt. ein Reading gesetzt und ein Event erzeugt.
Na ja, der Punkt ist folgender: "eigentlich" ist für das Herstellen eines auch in den Readings konsistenden Zustands - jedenfalls mAn. und bei diesem Device (vermutlich zumindest bei jedem "clima"-Type-Device) - eigentlich eine Auswertung der zugestellten Nachrichten erforderlich. An sich klappt das sogar über userReadings-Code. Aus irgendwelchen Gründen dachte ich bisher, dafür wäre ein "echter" trigger (=Event) erforderlich, was aber gar nicht stimmt, siehe dieses list:
defmod ZWave_THERMOSTAT_20 ZWave 12345678 20
attr ZWave_THERMOSTAT_20 IODev zwaveme
attr ZWave_THERMOSTAT_20 classes ZWAVEPLUS_INFO ASSOCIATION ASSOCIATION_GRP_INFO VERSION MANUFACTURER_SPECIFIC DEVICE_RESET_LOCALLY PROTECTION SENSOR_MULTILEVEL SWITCH_MULTILEVEL THERMOSTAT_MODE THERMOSTAT_SETPOINT BATTERY CONFIGURATION ALARM POWERLEVEL SECURITY SECURITY_S2 TRANSPORT_SERVICE SUPERVISION FIRMWARE_UPDATE_MD
attr ZWave_THERMOSTAT_20 room Steuerung->ZWave
attr ZWave_THERMOSTAT_20 userReadings energySaveHeating:setpointTemp.+energySaveHeating {ReadingsNum($name,"setpointTemp",0)}, heating:setpointTemp.+heating {ReadingsNum($name,"setpointTemp",0)}, thermostatMode:setpointTemp.+ {ReadingsVal($name,"setpointTemp",0)=~m/(heating|energySaveHeating)/;; $1?$1:undef}, testAck:transmit.* {ReadingsVal($name,"timeToAck",0)}
attr ZWave_THERMOSTAT_20 vclasses ALARM:8 ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 BATTERY:1 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:3 MANUFACTURER_SPECIFIC:1 POWERLEVEL:1 PROTECTION:1 SECURITY:1 SECURITY_S2:1 SENSOR_MULTILEVEL:5 SUPERVISION:1 SWITCH_MULTILEVEL:1 THERMOSTAT_MODE:3 THERMOSTAT_SETPOINT:3 TRANSPORT_SERVICE:2 VERSION:2 ZWAVEPLUS_INFO:2
setstate ZWave_THERMOSTAT_20 tmEnergySaveHeating
setstate ZWave_THERMOSTAT_20 2020-10-27 08:17:59 SEND_DATA failed:00
setstate ZWave_THERMOSTAT_20 2020-10-24 08:49:58 alarm System: Event cleared: State Idle
setstate ZWave_THERMOSTAT_20 2020-10-23 08:15:58 assocGroup_1 Max 1 Nodes zwaveme
setstate ZWave_THERMOSTAT_20 2020-10-23 08:15:58 assocGroups 1
setstate ZWave_THERMOSTAT_20 2020-10-29 02:49:54 battery 100 %
setstate ZWave_THERMOSTAT_20 2020-10-29 02:49:54 batteryPercent 100
setstate ZWave_THERMOSTAT_20 2020-10-29 02:49:54 batteryState ok
setstate ZWave_THERMOSTAT_20 2020-10-23 08:13:47 configBacklight BacklightEnabled
setstate ZWave_THERMOSTAT_20 2020-10-23 08:13:48 configBatteryReport SendOnceADay
setstate ZWave_THERMOSTAT_20 2020-10-23 08:13:48 configLCDInvert Normal
setstate ZWave_THERMOSTAT_20 2020-10-23 08:13:48 configLCDTimeout 0
setstate ZWave_THERMOSTAT_20 2020-10-23 08:13:48 configMeasuredTemperatureOffset 0
setstate ZWave_THERMOSTAT_20 2020-10-23 08:13:49 configOpenWindowDetection MediumSensibility
setstate ZWave_THERMOSTAT_20 2020-10-27 08:18:05 configTemperatureReportThreshold 1
setstate ZWave_THERMOSTAT_20 2020-10-26 06:54:07 configValveOpeningPercentageReport 1
setstate ZWave_THERMOSTAT_20 2020-10-26 11:46:39 energySaveHeating 18.0
setstate ZWave_THERMOSTAT_20 2020-10-23 08:10:54 fwMd fwMdManId: 0148, fwMdFwId_0: 0301, fwMdChkSum_0: e455, fwMdUpgradeable: ff, fwMdNrTarg: 01, fwMdFrqSize: 0028, fwMdFwId_1: 0001
setstate ZWave_THERMOSTAT_20 2020-10-26 21:03:41 heating 18.0
setstate ZWave_THERMOSTAT_20 2020-10-23 08:10:18 model EUROtronic EUR_SPIRITZ Wall Radiator Thermostat
setstate ZWave_THERMOSTAT_20 2020-10-23 08:10:18 modelConfig eurotronic/eur_spiritz.xml
setstate ZWave_THERMOSTAT_20 2020-10-23 08:10:18 modelId 0148-0003-0001
setstate ZWave_THERMOSTAT_20 2020-10-29 07:27:53 reportedState off
setstate ZWave_THERMOSTAT_20 2020-10-26 21:03:41 setpointTemp 18.0 C heating
setstate ZWave_THERMOSTAT_20 2020-10-29 07:28:30 state tmEnergySaveHeating
setstate ZWave_THERMOSTAT_20 2020-10-29 06:49:54 temperature 19.63 C
setstate ZWave_THERMOSTAT_20 2020-10-29 07:28:32 testAck 1.236
setstate ZWave_THERMOSTAT_20 2020-10-26 21:03:41 thermostatMode heating
setstate ZWave_THERMOSTAT_20 2020-10-29 07:28:32 timeToAck 1.236
setstate ZWave_THERMOSTAT_20 2020-10-29 07:28:32 transmit OK
setstate ZWave_THERMOSTAT_20 2020-10-26 21:11:51 version Lib 3 Prot 4.61 App 0.15 HW 49 FWCounter 1 FW 0.9
setstate ZWave_THERMOSTAT_20 2020-10-23 08:10:22 zwavePlusInfo version:01 role:SleepingListeningSlave node:Z-Wave+Node installerIcon:1200 userIcon:1200
Denn eigentlich interessiert einen bei einem Thermostaten mMn. praktisch immer, welche Zieltemperatur gerade eingestellt ist und (optimalerweise) welcher aktuelle Messwert dagegen steht; interessant ist auch der Öffnungsgrad, aber das ist eigentlich eher zur Problemanalyse hilfreich, wenn die beiden anderen Werte nicht in etwa in Deckung zu bringen sind.
Jetzt kann man bei dem Ding aber eben (im normalen Betriebsmodus) die Solltemperatur über einige setter vorgeben: desired-temp (findet sich nur im state), tm.*Heating, tmOn, tmOff, tmFullPower (was witzigerweise dim-Rückmeldungen ergibt und nach Ende des boost-Modus dann auf energySaveHeating, ohne dass dies allerdings über das userReading gekommen wäre, denn setpointTemp bleibt unverändert :o ...), thermostatSetpointSet.
Meine Idee wäre, aus dem state rauszulesen, was denn die letzte Anweisung war und dann ein Reading (desired-temp?) triggernd zu generieren, das halbwegs verlässlich ist, ohne dass man - in welchem Zyklus auch immer - die betreffende Info vom Thermostat erfragen muss...
Muß aber bei Gelegenheit mal noch ein paar Tests machen, was da eigentlich im Moment schon möglich wäre, und was wir ggf. noch bräuchten (ich habe den Verdacht, dass das nicht-triggernde readingsSingleUpdate in ZWave.pm geringfügig verändert werden müßte, damit man weitere triggernde readingsBulkUpdate dazwischenschieben kann).
ZitatWir (als FHEM) koennen zwar versuchen, "bessere" defaults zu setzen, bei den vielen ZWave Geraeten ist das aber eine echte Herausforderung, und womoeglich mit neuen Problemen verbunden, die der Hersteller schon analysiert hat.
Na ja, bei diesem Device ist nach Lektüre diverser Quellen mein Vertrauen in den Hersteller erst mal nicht so hoch - schließlich hätte man ja auch irgendwo mal "offiziell" erklären können, warum "5" der default ist - das ist jedenfalls iVm. dem Vergleich mit der vorhergehenden Messung (ob an das assoziierte Device versendet oder nicht) jedenfalls mir völlig räteslhaft...
Was wir tun können, ist eben die Erfahrungen zu sammeln und das ganze irgendwie zu verstetigen...
Moin.
Mal folgende Zwischeninfo: valve hatte ich - aus welchen Gründen auch immer - als eigenes Reading erwartet, was aber natürlich zu kurz gegriffen war. Via userReadings klappt das aber... Aktueller Zwischenstand:
energySaveHeating:setpointTemp.+energySaveHeating {ReadingsNum($name,"setpointTemp",0)}, heating:setpointTemp.+heating {ReadingsNum($name,"setpointTemp",0)}, thermostatMode:setpointTemp.+ {ReadingsVal($name,"setpointTemp",0)=~m/(heating|energySaveHeating)/; $1?$1:undef}, valve:reportedState.+(dim.[0-9.]+|off) {my $val = ReadingsVal($name,"state",0); return 0 if $val eq "off"; ReadingsNum($name,"state",0)}
Dazu hatte ich dann noch ergänzt:
, testAck:transmit.* {ReadingsVal($name,"timeToAck",0)}, testAck2:transmit.* { FHEM::attrT_ZWave_Utils::desiredTemp($name) }
Der Code wird auch aufgerufen, allerdings klappte das nicht, darüber weitere Readings zu erzeugen. 10_ZWave.pm ist bei der "transmit"-Verarbeitung dazu auch testweise von readingsSingleUpdate() auf den bulk-Mechanismus umgestellt, der betreffende Code in der myUtils sieht aktuell so aus, dann wird evtl. klarer, was eigentlich beabsichtigt ist:
sub desiredTemp {
my $name = shift // return;
my $call = shift // 'OK';
my $hash = $defs{$name} // return;
my $now = time;
my $state = ReadingsVal($name,'state','unknown');
my $stateNum = ReadingsNum($name,'state',20);
#Log3($name, 3, "ZWave-utils desiredTemp called");
#return if ReadingsAge($name,'state',10000000) > 3;
if ($state =~ m,desired-temp|thermostatSetpointSet,) {
readingsBulkUpdate($hash, 'desired-temp',$stateNum,1);
return;
}
if ($state =~ m,tmAuto|tmManual|tmHeating,) {
readingsBulkUpdate($hash, 'desired-temp',ReadingsVal($name,'heating','unknown'),1);
return;
}
if ($state =~ m,tmEnergySaveHeating,) {
readingsBulkUpdate($hash, 'desired-temp',ReadingsVal($name,'energySaveHeating','unknown'),1);
return;
}
if ($state =~ m,off,) {
readingsBulkUpdate($hash, 'desired-temp',6,'unknown',1);
return;
}
return;
}
(Ob das überhaupt eine gute Idee ist, kann ich noch nicht sagen).
Hallo Beta-User,
Sorry
ZitatNa ja, bei diesem Device ist nach Lektüre diverser Quellen mein Vertrauen in den Hersteller erst mal nicht so hoch - schließlich hätte man ja auch irgendwo mal "offiziell" erklären können, warum "5" der default ist - das ist jedenfalls iVm. dem Vergleich mit der vorhergehenden Messung (ob an das assoziierte Device versendet oder nicht) jedenfalls mir völlig räteslhaft.
Komme in meinem hohen Alter schon mal etwas durcheinander :(
Worauf bezieht sich die 5 ? configTemperatureReportThreshold ausgegeben als configMeasuredTemperatureReport ?
Also + - 0,5 Grad ist doch eigentlich für den Hausgebrauch soweit als default ok?
Vermute mal durch wenig Meldungen in den Standarteinstellungen soll die Batterielebensdauer
gestreckt werden.
Gruß
Hans-Jürgen
Diese Vermutung habe ich auch, und ja, es ging um configTemperatureReportThreshold.
ABER: der Threshold bezieht sich auf den letzten Messwert, nicht auf den letzten übermittelten Wert (wann auch immer gemessen wird...). Hat man also langsame, aber trotzdem große Schwankungen, wird NIE gesendet. Und das ist imo noch größerer Schwachsinn als ein etwas erhöhter Batterieverbrauch (zumal die Sendefrequenz gefühlt trotzdem weit unter dem ist, was z.B. die Homematic-Dinger machen).
Ich habe das jedenfalls jetzt so eingestellt, dass beide Threasholds auf 1 sind (für temp+valve) und bin mal gespannt, wie lange die Batterien halten.
Hallo Beta-User,
ZitatABER: der Threshold bezieht sich auf den letzten Messwert, nicht auf den letzten übermittelten Wert (wann auch immer gemessen wird...). Hat man also langsame, aber trotzdem große Schwankungen, wird NIE gesendet. Und das ist imo noch größerer Schwachsinn als ein etwas erhöhter Batterieverbrauch (zumal die Sendefrequenz gefühlt trotzdem weit unter dem ist, was z.B. die Homematic-Dinger machen).
Hmmm kan mich irren, für mich bezieht sich das auf den eingestellten Sollwert.
Ein Thermostat ist nun mal kein Thermometer bzw. Multisensor wie das sogenannte Fibaro "Auge".
Zu wird NIE gesendet habe gerade die Erfahrung gemacht durch externen Sensor Ausfall auf den internen
TempSensor umgestellt(bei Man.Modus!), es dauert natürlich lange wenn ich den Sollwert von 22 Grad auf 18 Grad mittels Weekdaytimer
abgesenkt habe ehe dann bei +-0,5 eine neue Meldung(Reading,Zeitstempel) kommt.
Na ja Bad war Heute Morgen trotzdem warm.
Der Haken ist natürlich, genaue Temp Kurve lässt sich schlechter plotten.
Tut der Funktionalität aber keinen Abbruch.
Wenn ich es es richtig überblicke versucht Du über Bit und Bytes Einstellungen den Thermostaten als
Thermometer zu überreden laienhaft gesprochen? ;)
An sich müsstest Du bei Dir gut an Hand des Zeitstempels erkennen wie oft der interne Temp Sensor
bei minimal 0,1 Schwankung abgefragt wird?
Vielleicht kann der Hersteller dazu was sagen.
Auch vermute ich das die Anwendung des Thermostaten über entsprechende Zentralen gedacht ist
also Klicki Bunti und für den "Normalo" Anwender ohne tieferes config Wissen gedacht ist.
Wo wir wieder bei den Templates wären?
Gruß
Hans-Jürgen
Zitat von: Deckoffizier am 03 November 2020, 08:52:54
Hmmm kan mich irren, für mich bezieht sich das auf den eingestellten Sollwert.
Na ja, in der xml heißt es nur lapidar:
1-50: Report temperature at 0.1-5.0°C temperature differenceDass sich das auf das Delta zur Solltemperatur bezieht, wäre eine mögliche Interpretation, irgendwo in den Untiefen des Inet habe ich das andere gefunden, und die Bedienungsanleitung (https://eurotronic.org/wp-content/uploads/2018/08/Spirit_Z-Wave_BAL_web_DE_view_V5.pdf) meint:
Die vom Spirit Z-Wave Plus gemessene Raumtemperatur wird automatisch bei einer Änderung von ±0,5°C gesendet. Der Schwellwert kann konfiguriert werden.
Das spräche eher für "meine" Interpretation, dass es entweder das Delta zur vorangegangenen Messung ist oder zum vorangegangenen übertragenen Messwert (was wohl auch eine Interpretation deiner Aussage zu von "22=>18" wäre) - jedenfalls habe ich für diese KW insgesamt ca. 120 Zeilen im Log (für alles), vorher hatte ich tagelang gar keinen Wert (ist aber ein Nebenraum, in dem die Temperatur eher nicht so schwankt bzw. der vom Hauptraum auch was an Wärme abbekommt). Als besonders gesprächig würde ich das daher im Moment nicht bezeichnen (gedanklicher Vergleichspunkt sind die HM-CC-RT-DN, die alle 2,5 Minuten "alles mögliche" senden).
Zitat
Ein Thermostat ist nun mal kein Thermometer bzw. Multisensor wie das sogenannte Fibaro "Auge".
Das ist schon klar, aber zunächst will ich ja erst mal verstehen, wie das Ding "tickt", und dafür brauche ich halt erst mal Daten - optimalerweise von dem Teil selbst, notfalls eben dann doch von Zusatzequipment, mal sehen...
Zitat
Wenn ich es es richtig überblicke versucht Du über Bit und Bytes Einstellungen den Thermostaten als
Thermometer zu überreden laienhaft gesprochen? ;)
An sich müsstest Du bei Dir gut an Hand des Zeitstempels erkennen wie oft der interne Temp Sensor
bei minimal 0,1 Schwankung abgefragt wird?
Wie gesagt: Wenn ich wirklich einen Thermometer brauche, dann nehme ich einen anderen, ich will nur erst mal wissen, wie das Ding intern tickt und was man damit am besten so "anstellt" - und an sich finde ich "hin und wieder eine Meldung" auch gar nicht schlecht. In jedem Fall sind die workarounds, die hier teils geteilt werden (mit den regelmäßigen get-Abfragen) mAn. die schlechtere Variante gg. automatischen Pushes des Devices selbst.
Zitat
Vielleicht kann der Hersteller dazu was sagen.
Der schweigt sich bisher jedenfalls zur firmware-Anfrage aus. Außer einer "kann sich situationsbedingt verzögern"-Antwort ist da seit der Anfrage vor einer Woche Funkstille.
Aber in der Bedienungsanleitung habe ich eben noch was interessantes gefunden:
Um den vollen Funktionsumfang des Spirit Z-Wave Plus nutzen zu können wird ein Security Enabled Z-Wave Controller benötigt.Werde das Ding also nochmal exkludieren und dann mit Security includieren. Vielleicht gibt es dann auch "clock"? (Dass sich die verfügbaren Kommandos _auch bei sowas simplem wie einem Thermostaten_ unterscheiden könnten, darauf wäre ich von alleine wohl auch nicht gekommen... Muß mal suchen, ob dazu hier im Forum schon was zu finden ist.)
Zitat
Auch vermute ich das die Anwendung des Thermostaten über entsprechende Zentralen gedacht ist
also Klicki Bunti und für den "Normalo" Anwender ohne tieferes config Wissen gedacht ist.
Wo wir wieder bei den Templates wären?
Na ja, besonders intuitiv fand ich jetzt weder das HomeCenter lite noch z-way. Vermutlich müßte man sich auch mit dieser Art Zentrale intensiver befassen - aber am Ende wird das so ähnlich sein wie bei deconz: Letztlich kann man nur sehr schwer nachvollziehen, was denn tatsächlich abläuft (ob z.B. die Hardware direkt miteinander spricht oder die Zentrale erforderlich ist). Da mache ich doch lieber noch etwas Experimente mit FHEM, da weiß ich am Ende wenigstens, woran ich bin... ;D
Zitat von: Beta-User am 03 November 2020, 15:01:09
Aber in der Bedienungsanleitung habe ich eben noch was interessantes gefunden:
Um den vollen Funktionsumfang des Spirit Z-Wave Plus nutzen zu können wird ein Security Enabled Z-Wave Controller benötigt.
Wobei sich mir bei der Tabelle auf Seite 15 der Bedienungsanleitung die Frage stellt, welche Befehlsklasse durch S0 oder S2 zusätzlich zur Verfügung stehen soll.
Eigentlich sagt die Tabelle doch aus, dass bei S0 oder S2 die Befehlsklassen "Security", "Transport Service" und "Z-Wave Plus Info" nicht unterstütz werden.
Fehlinterpretation meinerseits?
Zitat von: Nobbynews am 06 November 2020, 07:14:09
Wobei sich mir bei der Tabelle auf Seite 15 der Bedienungsanleitung die Frage stellt, welche Befehlsklasse durch S0 oder S2 zusätzlich zur Verfügung stehen soll.
Eigentlich sagt die Tabelle doch aus, dass bei S0 oder S2 die Befehlsklassen "Security", "Transport Service" und "Z-Wave Plus Info" nicht unterstütz werden.
Fehlinterpretation meinerseits?
Gedanklich hatte ich diesen Hänger auch schon, und nachdem ich die Hinweise von Rudi zum Thema Funklast bei Security in letzter Zeit gesehen habe, macht das für mich eigentlich keinen großen Sinn mit "Security" für das Ding, zumal ja auch die xml (die auch von anderen Lösungen zugrundegelegt werden) keine Unterscheidungen zu enthalten scheinen... Damit würde man auch wieder im Nebel rumtappen.
Es ist mir jetzt übrigens gelungen, über den userReadings-Weg das desired-temp-Reading zu erzeugen und zu füllen - das scheint im wesentlichen zu klappen, allerdings (wg. des Einklinkens in die ACK-Schleife) nur nicht-triggernd. Könnte man anders machen, wenn man sich in die state-Verarbeitung einklinkt, aber wie geschrieben wäre das de facto eine Änderung des defaults in den Gateway-Einstellungen... (leider reagiert das gar nicht mehr, wenn ich versuche, das von "nicht-triggerndem" Readings-Udate auf ein entsprechendes Bulk-Verfahren umzustellen (Versuch ist auskommentiert, ab Zeile 5092):
readingsSingleUpdate($hash, "transmit", $lmsg, 0);
#readingsBeginUpdate($hash);
#readingsBulkUpdate($hash, "transmit", $lmsg, 0);
#readingsEndUpdate($hash,1);
Den myUtils-Code habe ich eingecheckt (kann man über contrib/das template holen), das userReadings-Attribut dazu sieht so aus:
attr ZWave_THERMOSTAT_20 userReadings energySaveHeating:setpointTemp.+energySaveHeating {ReadingsNum($name,"setpointTemp",0)}, heating:setpointTemp.+heating {ReadingsNum($name,"setpointTemp",0)}, thermostatMode:setpointTemp.+ {ReadingsVal($name,"setpointTemp",0)=~m/(heating|energySaveHeating)/;; $1?$1:undef}, valve:reportedState.+(dim.[0-9.]+|off) {my $val = ReadingsVal($name,"state",0);; return 0 if $val eq "off";; ReadingsNum($name,"state",0)}, testAck2:transmit.*OK { FHEM::attrT_ZWave_Utils::desiredTemp($name) }
An sich könnte man auch die ersten paar in den Code integrieren, das war noch die Auswertung der "get"-Anfragen, aber auch da wäre es m.E. konsistenter, sich in die set-ACK-Schleife einzuklinken.
Ziel sollte eigentlich mAn. sein, auf sämtliche get-Anfragen möglichst zu verzichten, denn die führen immer mal wieder zu Problemen, jedenfalls scheint auch das hier eine Bestätigung dieser These zu sein: https://forum.fhem.de/index.php/topic,115561.0.html
Anbei auch mal ein log mit den 1/1 Einstellungen bei valve- und temp-Differenz - alles ganz ohne get-Anfragen. MAn wäre das völlig ok so (wenn es denn bei allen Devices mit diesen Einstellungen auch entsprechende Rückmeldungen gäbe).
Meinungen/Kritik/Anregungen dazu...?
Zitat von: Beta-User am 06 November 2020, 07:59:27
Gedanklich hatte ich diesen Hänger auch schon, und nachdem ich die Hinweise von Rudi zum Thema Funklast bei Security in letzter Zeit gesehen habe, macht das für mich eigentlich keinen großen Sinn mit "Security" für das Ding, zumal ja auch die xml (die auch von anderen Lösungen zugrundegelegt werden) keine Unterscheidungen zu enthalten scheinen... Damit würde man auch wieder im Nebel rumtappen.
Ich habe mir zu Vergleichszwecken zusätzlich zum Spirit noch den von Aeotec geholt und per secure inkludiert.
Version ist:
Lib 3 Prot 4.61 App 0.16 HW 49 FWCounter 1 FW 0.2Scheinen also so ziemlich identisch zu sein.
Was den Batteriestatus angeht, macht es aber keinen Unterschied zum non secure inkludierten Spirit.
Freiwliig spucken die nichts aus, obwohl beide auf SendOnceADay stehen.
Nachdem du das Teil secure inkludiert hast: Vermutlich ändert das ja nichts an den CLASSES. Aber _wenn_ es dann ginge, Wochenprogramme zu fahren (was ich jetzt nicht wirklich glaube), dann müßte das Ding eine Uhrzeit haben wollen bzw. setzen lassen.
Mein ursprünglicher "Versuchsplan" war, daher schlicht das CLOCK (?) zu ergänzen und dann zu versuchen, mal eine Uhrzeit zu setzen und den Wert abzufragen (k.A., wie das genau geht). Wenn auch das nicht geht, steht m.E. fest, dass nicht nur die Werbung falsch ist, sondern wohl auch die Aussage aus der Bedienungsanleitung... Dann macht secure nur zusätzliche Funklast und wäre daher - jedenfalls für den üblichen Hausgebrauch - nicht zu empfehlen.
Was das mit der Batterie angeht, ist es wirklich seltsam. Im Zweifel könnte man da aber ein "halbtägiges at" (oä.) definieren, das dann alle Spirit, die nicht innerhalb der letzten 24h ein Reading geliefert haben auffordert das nachzureichen? Wenn man das über eine Routine abbildet, müßte sich die Abfrage auch entzerren lassen, indem man für jedes Element eine entsprechende Verzögerung dazubaut.
ZitatMein ursprünglicher "Versuchsplan" war, daher schlicht das CLOCK (?) zu ergänzen und dann zu versuchen, mal eine Uhrzeit zu setzen und den Wert abzufragen (k.A., wie das genau geht)
Ich staune ueber die vielen Versuche, die Firmware durch setzen von FHEM-Attributen zu erweitern: ich gehe davon aus, dass ein Firmware-Schreiber, der die Muehe macht, die Funktionalitaet zu implementieren, der verschweigt das nicht.
Die CLOCK Befehle/Events sind dokumentiert.
Zitat von: Beta-User am 06 November 2020, 10:46:10
Nachdem du das Teil secure inkludiert hast: Vermutlich ändert das ja nichts an den CLASSES. Aber _wenn_ es dann ginge, Wochenprogramme zu fahren (was ich jetzt nicht wirklich glaube), dann müßte das Ding eine Uhrzeit haben wollen bzw. setzen lassen.
Nein, wollte das Teil nicht. Und wenn ein Wochenprogramm von Haus aus im Gerät ginge, dann sollte das doch eigentlich irgendwo beschrieben und auch einstellbar sein.
Stattdessen gibt es z.B. bei Eurotronic im Datenblatt nur den dezenten Hinweis, dass zur Nutzung der "energieeffizienten Steuerung" eine Z-Wave Zentrale erforderlich ist.
Bei Aeotec hießt es auch nur:
ZitatYou can automate it, and you can manually control it. Radiator Thermostat can be intelligently automated or scheduled via Z-Wave, or it can be manually controlled from an app or its on-device buttons and backlit, LCD screen.
Ich würde daher mal sagen, die Dinger sind im Vergleich zu z.B. MAX ziemlich "dumm".
...bescheuert ist eigentlich nur, dass die "Werbung" suggeriert (ich hatte das die Tage mal irgendwo zitiert), das Ding wäre intelligenter...
Aber mit FHEM ist es dann auch kein Problem, "unendlich" viele Werte in ein Wochenprogramm einzubauen, von daher ist dann auch wieder die Werbeaussage in die andere Richtung bescheuert (oder andere Controller-Software ist beschränkt? Dass "unendlich" nicht sinnvoll ist, ist auch klar...).
Wie dem auch sei, dann bleibt das Ding hier jedenfalls inkludiert "as is" und meine Versuche werden dann eher in Richtung der "Verbesserung" der Readings gehen. Dazu braucht es aber vermutlich mindestens noch eine Unterscheidung in "durch get angefragt" und "vom Thermostaten gesendet" bei der Rückmeldung der "heating"-Werte.
@Nobbynews: bekommst du denn eine Rückmeldung, wenn du manuell am Thermostaten selbst die Soll-Temperatur änderst oder bleibt das Ding auch in der Beziehung stumm?
@Rudi (und ggf. krikan): Eine Rückmeldung wäre nett, ob ich mit den ganzen Überlegungen zur "Nachverarbeitung nach ACK" (notfalls über userReadings auf state-Trigger+entsp. Einstellung am IO) irgendwie auf dem Holzweg bin... Eventuell habt ihr da ja vor langer Zeit schon mal intensiv drüber nachgedacht und sowas verworfen?
Zitat von: Beta-User am 06 November 2020, 11:57:10
@Nobbynews: bekommst du denn eine Rückmeldung, wenn du manuell am Thermostaten selbst die Soll-Temperatur änderst oder bleibt das Ding auch in der Beziehung stumm?
Bei beiden Thermostaten kommt die Rückmeldung über:
2020-11-06_14:57:03 HK_Flur setpointTemp: 23.0 C heatingUnverändert bleibt:
state desired-temp 22.0
:) dass überhaupt eine Rückmeldung kommt ist gut...
...muß mal bei Gelegenheit damit noch ein wenig rumspielen, aber vermutlich bastle ich für den userReadings-trigger setPointTemp noch was neues, das in die folgende Richtung geht:
Ein "get" müßte eigentlich auch ein ACK auslösen (muß ich noch prüfen), was bedeutet, dass (mit ziemlicher Sicherheit) eine ReadingsAge-Abfrage auf transmit ausreichen müßte, um zwischen "ungefragt" (=manuelle desired-temp-Änderung) und "gefragt" (nicht für desired-temp relevant) unterscheiden zu können...?
Dementsprechend könnte man dann zusätzlich (ungefragter Fall) das desired-temp setzen, was dann auch in Log landen könnte, da dieser Auslöser triggernd ist.
Zitat von: Beta-User am 06 November 2020, 11:57:10
@Rudi (und ggf. krikan): Eine Rückmeldung wäre nett, ob ich mit den ganzen Überlegungen zur "Nachverarbeitung nach ACK" (notfalls über userReadings auf state-Trigger+entsp. Einstellung am IO) irgendwie auf dem Holzweg bin... Eventuell habt ihr da ja vor langer Zeit schon mal intensiv drüber nachgedacht und sowas verworfen?
Da mir das Problem nicht wirklich klar ist, halte ich mich zurück. :)
Gruß, Christian
Das "Problem" besteht imo im wesentlichen darin, dass ziemlich viele User unsicher zu sein scheinen, wie sie den aktuellen "Sollzustand" ihrer Thermostaten "überwachen" können. Das führt dazu, dass "alles mögliche" an workarounds gebastelt wird - allerdings ohne, dass das wirklich in jedem Fall erforderlich wäre oder gar sinnvoll; eher sind diese Ansätze - vom Bauchgefühl her jedenfalls - kontraproduktiv, weil der Funkverkehr (teils zum unpassenden Zeitpunkt) vermehrt wird.
Bei CUL_HM hat man das Problem nicht, da wird alle 2,5 Minuten eben das Reading "desired-temp" unaufgefordert aktualisiert (und eine ganze Menge mehr, einschließlich des Öffnungsgrades am Ventil).
Diese "Schweigsamkeit" der Spirits säht einen gewissen Zweifel an der Zuverlässigkeit der tatsächlichen Ausführung angewiesener Schaltvorgaben.
Ein Teilziel wäre daher, zumindest das an Info vollständig auszuwerten, was wir eben "eigentlich" sowieso haben - kommt z.B. ein ACK auf eine Schaltanweisung, wird das betreffende Reading (welches auch immer dazu "gut" sein mag) aktualisiert (und nicht nur state, wenn man das am IO mit den showSetInState aktiviert). Im Moment landet eben jeweils eine Teilinfo dazu "irgendwo", ohne dass es konsistent zu sein scheint (oder ist dir direkt klar, welche Temperatur denn eingestellt wird, wenn du "eco" anweist? Und bring das mal einem SVG-plot bei, was du "auf einen Blick" erkennen kannst, aber auch nur solange, wie du die setPoints nicht anfasst...).
Hoffe, das trägt eher zur Klarheit bei als es verwirrt...?
Habs verstanden, dass es Dir wichtig ist.
Kommt bei mir auf die TODO-Liste, wird aber vmtl. erst naechste Woche was.
Vorab mal danke!
Da wir das Thema "korrekte Rückwärts-Auswertung der Ack-Messages" hier schon mal angerissen hatten: Aus meiner Sicht besteht eigentlich nicht unbedingt der Bedarf nach einer (EDV-mäßig gedacht) 100% korrekten Lösung. Mein Ansatz über das simple "es ist irgendwas korrekt angekommen" dürfte ausreichen, um den "Praktikerbedarf" abzudecken, und - sofern es in diese Richtung gehen würde - die Aufnahme gerätespezifischen Codes sollte auch nicht unbedingt der Weg sein (Geräteklassen-spezifisch wäre ggf. was anderes). Gerätespezifika könnte man m.E. genausogut durch "add-ons" abdecken.
Ich habe ZWDongle mit dem setReadingOnAck Attribut erweitert:
ZitatIf the attribute is set to 1, and a set command with an argument is issued to a ZWave device, then a reading with the same name will be updated upon reception of the corresponding ZWave ACK radio telegram.
Bei Mehrfach-Befehlen (ich meine damit mit ; getrennte sets/gets) an Security Geraete wurden Fehlermeldungen ab den zweiten Befehl ignoriert. Das habe ich jetzt gefixt.
showSetInState ist mehrfach kaputt: bei Security wird es ignoriert, bei Mehrfach-Befehlen landet sofort der letzte Befehl als set_XXX in state, und state wird zu XXX, nachdem der erste ACK empfangen wurde. Das habe ich (noch?) nicht gefixt.
setReadingOnAck habe ich mit Mehrfach-Befehlen bei zwei "always on" Geraeten getestet, einmal mit Security, einmal ohne.
Brauche noch Feedback, insb. fuer WAKE_UP Geraete.
Hab's mit dem Spirit kurz angetestet, das sieht jetzt schon mal viel besser aus :) .
Allerdings besteht weiter das Problem, dass man unterschiedliche Ergebnisse hat, je nachdem, wie man die Wunschtemperatur vorgibt...
An sich sollten set DEVICE desired-temp 19, set DEVICE thermostatSetpointSet 18.5 und das "Knöpfedrücken" am HT selbst auf diese Temperatur immer (fast) dieselben Ergebnisse liefern, tatsächlich sieht das aber noch so aus:
setstate ZWave_THERMOSTAT_20 2020-11-12 08:17:40 desired-temp 19
setstate ZWave_THERMOSTAT_20 2020-11-12 08:18:37 thermostatSetpointSet 18.5
setstate ZWave_THERMOSTAT_20 2020-11-12 08:20:44 setpointTemp 19.0 C heatingDas sollte sich (wie die noch nicht getesteten tm-Befehle) aber jetzt auch außerhalb des eigentlichen Moduls/via userReadings lösen lassen :) .
Zitat von: rudolfkoenig am 11 November 2020, 22:27:02
Brauche noch Feedback, insb. fuer WAKE_UP Geraete.
MMn. sollte man das neue feature auch offensiver bewerben... Von daher fände ich es angebracht, dazu einen eigenen Thread zu starten; hier liest ggf. nur eine eher kleine Anzahl (neuer ZWave-) User und Experten mit...
Und sollte man das nicht per feature_level 6.1 zum default machen?
ZitatUnd sollte man das nicht per feature_level 6.1 zum default machen?
Darueber denken wir dann nach, wenn es keine Nebeneffekte hat => ich brauche mehr Feedback.
Ich weiß jetzt nicht ob es mit dieser Änderung zusammenhängt, aber seitdem habe ich beim schalten folgende Einträge im Log:
Zitat2020.11.14 23:01:32 3: ZWave set ZWave_SWITCH_BINARY_9.06 on
2020.11.14 23:01:32 1: readingsUpdate(ZWave_SWITCH_BINARY_9.06,state,on) missed to call readingsBeginUpdate first.
2020.11.14 23:01:32 1: stacktrace:
2020.11.14 23:01:32 1: main::readingsBulkUpdate called by ./FHEM/10_ZWave.pm (5112)
2020.11.14 23:01:32 1: main::ZWave_Parse called by fhem.pl (4005)
2020.11.14 23:01:32 1: main::Dispatch called by ./FHEM/00_ZWDongle.pm (981)
2020.11.14 23:01:32 1: main::ZWDongle_Parse called by ./FHEM/00_ZWDongle.pm (876)
2020.11.14 23:01:32 1: main::ZWDongle_Read called by fhem.pl (3809)
2020.11.14 23:01:32 1: main::CallFn called by fhem.pl (755)
Da ich das Attribut "showSetInState" gesetzt habe, bleiben die Geräte auch in diesem set Zustand stehen.
Eine Änderung des neuen Attributes "setReadingOnAck" brachte keine Änderung.
Gruß
Danny
Solche Einträge habe ich auch:
2020.11.14 18:47:32 3: ZWave set Jalousie_WZ dim 75
2020.11.14 18:47:32 1: readingsUpdate(Jalousie_WZ,dim,75) missed to call readingsBeginUpdate first.
2020.11.14 18:47:32 1: stacktrace:
2020.11.14 18:47:32 1: main::readingsBulkUpdate called by ./FHEM/10_ZWave.pm (5122)
2020.11.14 18:47:32 1: main::ZWave_Parse called by fhem.pl (4005)
2020.11.14 18:47:32 1: main::Dispatch called by ./FHEM/00_ZWDongle.pm (981)
2020.11.14 18:47:32 1: main::ZWDongle_Parse called by ./FHEM/00_ZWDongle.pm (876)
2020.11.14 18:47:32 1: main::ZWDongle_Read called by fhem.pl (3809)
2020.11.14 18:47:32 1: main::CallFn called by fhem.pl (755)
2020.11.14 18:47:35 3: ZWave set ZWave_SWITCH_MULTILEVEL_8.02 dim 30
2020.11.14 18:47:35 1: readingsUpdate(ZWave_SWITCH_MULTILEVEL_8.02,dim,30) missed to call readingsBeginUpdate first.
2020.11.14 18:47:35 1: stacktrace:
2020.11.14 18:47:35 1: main::readingsBulkUpdate called by ./FHEM/10_ZWave.pm (5122)
2020.11.14 18:47:35 1: main::ZWave_Parse called by fhem.pl (4005)
2020.11.14 18:47:35 1: main::Dispatch called by ./FHEM/00_ZWDongle.pm (981)
2020.11.14 18:47:35 1: main::ZWDongle_Parse called by ./FHEM/00_ZWDongle.pm (876)
2020.11.14 18:47:35 1: main::ZWDongle_Read called by fhem.pl (3809)
2020.11.14 18:47:35 1: main::CallFn called by fhem.pl (755)Das Zielgerät ist ein FGR-223, das erste dim ging an den .01-Kanal, meine Vermutung für diesen Fall wäre, dass Auslöser je ein userReading war.
Der Ausloeser wahr falscher Code fuer MULTI_CHANNEL Geraete.
Hoffentlich habe ich es gefixt, getestet habe ich es mangels passendes Testgeraet nur mit "einfachen" Geraeten.
Bitte um Feedback.
Eben mal ein Update gemacht und getetstet.
Alles wieder so wie gewohnt.
Besten Dank
Danny
Zitat von: rudolfkoenig am 15 November 2020, 11:09:38
Der Ausloeser wahr falscher Code fuer MULTI_CHANNEL Geraete.
Hoffentlich habe ich es gefixt, getestet habe ich es mangels passendes Testgeraet nur mit "einfachen" Geraeten.
Bitte um Feedback.
Zitat von: rudolfkoenig am 11 November 2020, 22:27:02
Ich habe ZWDongle mit dem setReadingOnAck Attribut erweitert
Vielen Dank, das sollte einige Probleme beheben mit denen auch ich schon seit Jahren kämpfe
Zitat von: rudolfkoenig am 11 November 2020, 22:27:02
showSetInState ist mehrfach kaputt: bei Mehrfach-Befehlen landet sofort der letzte Befehl als set_XXX in state, und state wird zu XXX, nachdem der erste ACK empfangen wurde
stimmt, auch eines der alten Probleme für die man bisher immer mit "Workarounds nachbessern" musste
Zitat von: rudolfkoenig am 11 November 2020, 22:27:02
setReadingOnAck habe ich mit Mehrfach-Befehlen bei zwei "always on" Geraeten getestet, einmal mit Security, einmal ohne.
Brauche noch Feedback, insb. fuer WAKE_UP Geraete
Bin selbst gespannt, Test läuft (ohne Security), im Einsatz sind 20 WAKE_UP-Geräte (FIBARO Motion+Door-Sensoren sowie Heizungsthermostate von EUROtronic und Danfoss) sowie 20 weitere "always on" Geräte aus der gesamten FIBARO-Serie
Ich hab ein Problem mit einem unserer Spirits.
Das erste hat viele Befehle zum setzen von diversen Config-Parametern (unter anderem den Befehl, den ich gerade benötige: configMeasuredTemperatureOffset)
Das zweite, eigentlich Baugleiche Gerät, hat diesen (und andere Config-Befehle) nicht!
Alle Befehle des "richtigen" Gerätes:
Unknown argument ?, choose one of alarmnotification associationAdd associationDel configBacklight configBatteryReport configByte configDefault configLCDInvert configLCDTimeout configLong configMeasuredTemperatureOffset configOpenWindowDetection configTemperatureReportThreshold configValveOpeningPercentageReport configWord desired-temp dim dimUpDown fwUpdate neighborUpdate off on powerlevel powerlevelTest protectionBytes protectionOff protectionOn protectionSeq returnRouteAdd returnRouteDel secSupportedReport setpointCooling setpointHeating stop sucRouteAdd sucRouteDel thermostatSetpointSet tmAuto tmCooling tmEnergySaveHeating tmFan tmFullPower tmHeating tmManual tmOff off-till blink off-till-overnight on-till-overnight off-for-timer on-for-timer intervals on-till toggle attrTemplate
und hier die Befehle des "falschen" Gerätes:
Unknown argument ?, choose one of alarmnotification associationAdd associationDel configByte configDefault configLong configWord desired-temp dim dimUpDown fwUpdate neighborUpdate off on powerlevel powerlevelTest protectionBytes protectionOff protectionOn protectionSeq returnRouteAdd returnRouteDel secSupportedReport setpointCooling setpointHeating stop sucRouteAdd sucRouteDel thermostatSetpointSet tmAuto tmCooling tmEnergySaveHeating tmFan tmFullPower tmHeating tmManual tmOff off-till-overnight on-till-overnight off-till blink on-till toggle off-for-timer on-for-timer intervals attrTemplate
vClasses und Classes sind gleich. Selbst die gemeldete ModelId.
Einziger Unterschied den ich feststellen kann ist das "model" was gemeldet wird.
bei dem wo es geht:
EUROtronic EUR_SPIRITZ Wall Radiator Thermostat
bei dem anderen:
EUROtronic EUR_SPIRIT Wall Radiator Thermostat Valve Control
Wie bekomm ich das jetzt "berichtigt"?
:)
Danke euch!
mit get model
Das war ja einfach.
Aber genau diesen Befehl hatte ich zuvor schon ausgeführt, da ich gesehen hatte das die Model Bezeichnungen unterschiedlich waren...
Jetzt geht's aber ;D danke nochmals.
Guten Morgen in die Runde,
ich habe mir jetzt noch einen weiteren Spirit zugelegt und abweichend vom Ersten per Secure eingebunden und einen WeekdayTimer zusammen mit weekprofile erstellt. In der Log-Datei ist mir etwas merkwürdiges aufgefallen. Vielleicht kann mir jemand auf die Sprünge helfen.
2020-12-13_00:46:22 HK_Keller temperature: 17.17 C
2020-12-13_04:54:17 HK_Keller temperature: 16.64 C
2020-12-13_05:30:00 HK_Keller desired-temp 20.0
2020-12-13_05:30:04 HK_Keller desired-temp: 20.0
2020-12-13_05:44:04 HK_Keller temperature: 17.17 C
2020-12-13_05:50:09 HK_Keller temperature: 17.61 C
2020-12-13_05:58:17 HK_Keller temperature: 18.14 C
2020-12-13_06:08:27 HK_Keller temperature: 18.66 C
2020-12-13_06:18:36 HK_Keller temperature: 19.10 C
2020-12-13_06:41:58 HK_Keller desired-temp: 22.0
2020-12-13_06:41:58 HK_Keller temperature: 19.63 C
Den Eintrag von 6:41:58 desired-temp: 22.0 kann ich mir nicht erklären. Aktuell zeigt der Thermostat am Display wie gewünscht 20°C an.
Hier das List vom device:
Internals:
CFGFN
DEF d246e259 8
FUUID 5fcf9362-f33f-8873-6066-f4fcdf71ffca9171
IODev ZWave
LASTInputDev ZWave
MSGCNT 311
NAME HK_Keller
NR 891359
STATE desired-temp 20.0
STILLDONETIME 0
TYPE ZWave
ZWaveSubDevice no
ZWave_MSGCNT 311
ZWave_RAWMSG 000400081a98815b48d7c0bf1bdd6c8cd68bdbd8c490e19d2ce6dfcc610875b000
ZWave_TIME 2020-12-13 06:41:58
cmdsPending 0
homeId d246e259
isWakeUp
lastMsgSent 1607838118.89294
nodeIdHex 08
secTime 1607838118.89233
webCmd desired-temp
READINGS:
2020-12-08 15:53:27 SECURITY ENABLED
2020-12-08 15:58:28 assocGroup_1 Max 1 Nodes ZWave
2020-12-08 15:58:28 assocGroups 1
2020-12-08 15:53:32 associationAdd 1 1
2020-12-12 06:20:00 battery 100 %
2020-12-12 06:20:00 batteryPercent 100
2020-12-12 06:20:00 batteryState ok
2020-12-11 17:28:04 configBacklight BacklightEnabled
2020-12-11 17:28:04 configBatteryReport SendOnceADay
2020-12-11 17:28:04 configLCDInvert Normal
2020-12-11 17:28:04 configLCDTimeout 0
2020-12-11 17:28:05 configMeasuredTemperatureOffset 0
2020-12-11 18:24:33 configOpenWindowDetection Disabled
2020-12-11 17:28:05 configTemperatureReportThreshold 5
2020-12-11 17:28:05 configValveOpeningPercentageReport 0
2020-12-13 06:41:58 desired-temp 22.0
2020-12-11 17:38:40 model EUROtronic EUR_SPIRITZ Wall Radiator Thermostat
2020-12-11 17:38:40 modelConfig eurotronic/eur_spiritz.xml
2020-12-11 17:38:40 modelId 0148-0003-0001
2020-12-11 17:47:50 neighborList ZWave HK_Flur
2020-12-13 05:30:01 state desired-temp 20.0
2020-12-13 06:41:58 temperature 19.63 C
2020-12-11 17:48:38 thermostatMode heating
2020-12-13 06:41:58 timeToAck 0.046
2020-12-13 06:41:58 transmit OK
2020-12-08 15:59:17 version Lib 3 Prot 4.61 App 0.16 HW 49 FWCounter 1 FW 0.2
2020-12-08 15:59:09 zwavePlusInfo version:01 role:SleepingListeningSlave node:Z-Wave+Node installerIcon:1200 userIcon:1200
secMsg:
secNonce:
Attributes:
IODev ZWave
classes ZWAVEPLUS_INFO ASSOCIATION ASSOCIATION_GRP_INFO VERSION MANUFACTURER_SPECIFIC DEVICE_RESET_LOCALLY PROTECTION SENSOR_MULTILEVEL SWITCH_MULTILEVEL THERMOSTAT_MODE THERMOSTAT_SETPOINT BATTERY CONFIGURATION ALARM POWERLEVEL SECURITY SECURITY_S2 TRANSPORT_SERVICE SUPERVISION FIRMWARE_UPDATE_MD
room 08_Heizung,ZWave
secure_classes VERSION ASSOCIATION ASSOCIATION_GRP_INFO MANUFACTURER_SPECIFIC DEVICE_RESET_LOCALLY POWERLEVEL PROTECTION SENSOR_MULTILEVEL SWITCH_MULTILEVEL THERMOSTAT_MODE THERMOSTAT_SETPOINT BATTERY CONFIGURATION ALARM SUPERVISION FIRMWARE_UPDATE_MD
vclasses ALARM:8 ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 BATTERY:1 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:3 MANUFACTURER_SPECIFIC:1 POWERLEVEL:1 PROTECTION:1 SECURITY:1 SECURITY_S2:1 SENSOR_MULTILEVEL:5 SUPERVISION:1 SWITCH_MULTILEVEL:1 THERMOSTAT_MODE:3 THERMOSTAT_SETPOINT:3 TRANSPORT_SERVICE:2 VERSION:2 ZWAVEPLUS_INFO:2
Hier noch das List vom WeekdayTimer:
Internals:
CFGFN
COMMAND
CONDITION
DEF HK_Keller weekprofile:HK_ZWave
DEVICE HK_Keller
FUUID 5fcf9827-f33f-8873-5a12-bf9f050de53f9fb8
GlobalDaylistSpec
LANGUAGE de
NAME wdT_Keller
NR 892770
Profil 0: Sonntag 00:10:00 14.0, 05:30:00 20.0, 20:00:00 14.0,
Profil 1: Montag 00:10:00 14.0, 05:30:00 20.0, 20:00:00 14.0,
Profil 2: Dienstag 00:10:00 14.0, 05:30:00 20.0, 20:00:00 14.0,
Profil 3: Mittwoch 00:10:00 14.0, 05:30:00 20.0, 20:00:00 14.0,
Profil 4: Donnerstag 00:10:00 14.0, 05:30:00 20.0, 20:00:00 14.0,
Profil 5: Freitag 00:10:00 14.0, 05:30:00 20.0, 20:00:00 14.0,
Profil 6: Samstag 00:10:00 14.0, 05:30:00 20.0, 20:00:00 14.0,
STATE 20.0
STILLDONETIME 0
TYPE WeekdayTimer
READINGS:
2020-12-13 05:30:00 currValue 20.0
2020-12-13 05:30:00 nextUpdate 2020-12-13 20:00:00
2020-12-13 05:30:00 nextValue 14.0
2020-12-13 05:30:00 state 20.0
2020-12-11 18:31:12 weekprofiles HK_ZWave:Keller:Ferien
SWITCHINGTIMES:
5|00:10|14.0
5|05:30|20.0
5|20:00|14.0
1|00:10|14.0
1|05:30|20.0
1|20:00|14.0
6|00:10|14.0
6|05:30|20.0
6|20:00|14.0
0|00:10|14.0
0|05:30|20.0
0|20:00|14.0
4|00:10|14.0
4|05:30|20.0
4|20:00|14.0
2|00:10|14.0
2|05:30|20.0
2|20:00|14.0
3|00:10|14.0
3|05:30|20.0
3|20:00|14.0
TIMER:
wdT_Keller_10:
HASH wdT_Keller
MODIFIER 10
NAME wdT_Keller_10
wdT_Keller_11:
HASH wdT_Keller
MODIFIER 11
NAME wdT_Keller_11
wdT_Keller_12:
HASH wdT_Keller
MODIFIER 12
NAME wdT_Keller_12
wdT_Keller_SetTimerOfDay:
HASH wdT_Keller
MODIFIER SetTimerOfDay
NAME wdT_Keller_SetTimerOfDay
SETTIMERATMIDNIGHT 1
wdT_Keller_delayed:
HASH wdT_Keller
MODIFIER delayed
NAME wdT_Keller_delayed
helper:
daysRegExp (so|mo|di|mi|do|fr|sa|\$we|\!\$we)
daysRegExpMessage (so|mo|di|mi|do|fr|sa|$we|!$we)
SWITCHINGTIME:
0:
00:10:00 14.0
05:30:00 20.0
20:00:00 14.0
1:
00:10:00 14.0
05:30:00 20.0
20:00:00 14.0
2:
00:10:00 14.0
05:30:00 20.0
20:00:00 14.0
3:
00:10:00 14.0
05:30:00 20.0
20:00:00 14.0
4:
00:10:00 14.0
05:30:00 20.0
20:00:00 14.0
5:
00:10:00 14.0
05:30:00 20.0
20:00:00 14.0
6:
00:10:00 14.0
05:30:00 20.0
20:00:00 14.0
WEDAYS:
0 1
6 1
profil:
1:
EPOCH 1607814600
PARA 14.0
TIME 00:10
WE_Override 0
TAGE:
5
10:
EPOCH 1607814600
PARA 14.0
TIME 00:10
WE_Override 0
TAGE:
0
11:
EPOCH 1607833800
PARA 20.0
TIME 05:30
WE_Override 0
TAGE:
0
12:
EPOCH 1607886000
PARA 14.0
TIME 20:00
WE_Override 0
TAGE:
0
13:
EPOCH 1607814600
PARA 14.0
TIME 00:10
WE_Override 0
TAGE:
4
14:
EPOCH 1607833800
PARA 20.0
TIME 05:30
WE_Override 0
TAGE:
4
15:
EPOCH 1607886000
PARA 14.0
TIME 20:00
WE_Override 0
TAGE:
4
16:
EPOCH 1607814600
PARA 14.0
TIME 00:10
WE_Override 0
TAGE:
2
17:
EPOCH 1607833800
PARA 20.0
TIME 05:30
WE_Override 0
TAGE:
2
18:
EPOCH 1607886000
PARA 14.0
TIME 20:00
WE_Override 0
TAGE:
2
19:
EPOCH 1607814600
PARA 14.0
TIME 00:10
WE_Override 0
TAGE:
3
2:
EPOCH 1607833800
PARA 20.0
TIME 05:30
WE_Override 0
TAGE:
5
20:
EPOCH 1607833800
PARA 20.0
TIME 05:30
WE_Override 0
TAGE:
3
21:
EPOCH 1607886000
PARA 14.0
TIME 20:00
WE_Override 0
TAGE:
3
3:
EPOCH 1607886000
PARA 14.0
TIME 20:00
WE_Override 0
TAGE:
5
4:
EPOCH 1607814600
PARA 14.0
TIME 00:10
WE_Override 0
TAGE:
1
5:
EPOCH 1607833800
PARA 20.0
TIME 05:30
WE_Override 0
TAGE:
1
6:
EPOCH 1607886000
PARA 14.0
TIME 20:00
WE_Override 0
TAGE:
1
7:
EPOCH 1607814600
PARA 14.0
TIME 00:10
WE_Override 0
TAGE:
6
8:
EPOCH 1607833800
PARA 20.0
TIME 05:30
WE_Override 0
TAGE:
6
9:
EPOCH 1607886000
PARA 14.0
TIME 20:00
WE_Override 0
TAGE:
6
profile_IDX:
0:
00:10:00 10
05:30:00 11
20:00:00 12
1:
00:10:00 4
05:30:00 5
20:00:00 6
2:
00:10:00 16
05:30:00 17
20:00:00 18
3:
00:10:00 19
05:30:00 20
20:00:00 21
4:
00:10:00 13
05:30:00 14
20:00:00 15
5:
00:10:00 1
05:30:00 2
17:45:00 3
18:15:00 4
20:00:00 3
6:
00:10:00 7
05:30:00 8
20:00:00 9
weekprofiles:
HK_ZWave:
PROFILE Keller:Ferien
PROFILE_JSON {"Sun":{"temp":["14.0","20.0","14.0"],"time":["05:30","20:00","24:00"]},"Thu":{"temp":["14.0","20.0","14.0"],"time":["05:30","20:00","24:00"]},"Mon":{"time":["05:30","20:00","24:00"],"temp":["14.0","20.0","14.0"]},"Fri":{"time":["05:30","20:00","24:00"],"temp":["14.0","20.0","14.0"]},"Sat":{"time":["05:30","20:00","24:00"],"temp":["14.0","20.0","14.0"]},"Wed":{"temp":["14.0","20.0","14.0"],"time":["05:30","20:00","24:00"]},"Tue":{"time":["05:30","20:00","24:00"],"temp":["14.0","20.0","14.0"]}}
SunAsWE 0
PROFILE_DATA:
Fri:
temp:
14.0
20.0
14.0
time:
05:30
20:00
24:00
Mon:
temp:
14.0
20.0
14.0
time:
05:30
20:00
24:00
Sat:
temp:
14.0
20.0
14.0
time:
05:30
20:00
24:00
Sun:
temp:
14.0
20.0
14.0
time:
05:30
20:00
24:00
Thu:
temp:
14.0
20.0
14.0
time:
05:30
20:00
24:00
Tue:
temp:
14.0
20.0
14.0
time:
05:30
20:00
24:00
Wed:
temp:
14.0
20.0
14.0
time:
05:30
20:00
24:00
Attributes:
commandTemplate set $NAME desired-temp $EVENT
room 08_Heizung
userattr weekprofile
Mysteriös...
Der WDT dürfte das nicht verursacht haben: Wenn der (oder sonst was aus FHEM heraus) Anweisungen gibt, dann ist erst mal _kein_ Doppelpunkt im Log, erst die Rückmeldung vom Device hat den Doppelpunkt im Event, oder deute ich das falsch?
Außerdem hat der WDT gar keinen 22-Grad-Schaltzeitpunkt, das kann also eigentlich auch nicht mit einem "switch-in-the-past" bei FHEM-restart oä. zusammenhängen (das ist ein Heizungsdevice, da sendet WDT also ggf. schon was raus, wenn FHEM neu startet).
Neu gestartet habe ich Fhem nicht.
Kann es sein, dass es sich dabei ggf. um dieTemperaturen handel, die mit setpoint gesetzt werden?
Das habe ich am neuen Spirit noch nicht gemacht und Angaben über eine Standardeinstellung habe ich nicht gefunden.
ZumTesten habe ich jetzt mal PercentageReport auf 1 gesetzt, um die Regelungsaktivitäten besser zu erkennen.
Hm, eigentlich _glaube_ ich nicht, dass das eine Antwort auf "setpoint" ist. Zum einen müßte dann ggf. auch das "Gegenstück" im Log auftauchen, und zum anderen wäre es was neues, dass das tatsächlich nach "desired-temp" gemappt würde.
Alelrdings muss ich zugeben, dass der ZWave-Teil meines FHEM-Projekts grade etwas stiefmütterlich vor sich hin kümmert, kann also durchaus sein, dass das mit den jüngsten Änderungen von Rudi als "device-spezifisch" reingekommen ist; das müßte dann aber im Changelog im svn zu finden sein.
Eine lokale Änderung eines Mitbewohners war es auch nicht (wobei mich auch in dem Fall das Mapping nach desired-temp wundern würde)?
Nach einigem Rumprobieren hatte ich gestern das Log voll mit diesen Einträgen:
2020.12.14 00:35:56 1: HK_Keller: Error, no send_nonce to decrypt message available
2020.12.14 00:39:03 1: HK_Keller: Error, no send_nonce to decrypt message available
2020.12.14 00:57:14 1: HK_Keller: secDecrypt: Authentification code not verified, command b028f2 will be dropped!
2020.12.14 00:57:15 1: HK_Keller: Error, no send_nonce to decrypt message available
Heute habe ich den Spirit mal aus dem Netzwerk entfernt und dann ohne Verschlüsselung neu eingebunden.
Bei Abfragen kam dann ständig ein TimeOut.
Vermutlich lag es also an einer grottigen Funkverbindung. Habe den Stick jetzt mal an einer anderen Stelle posstioniert und dann aktzebtable Reaktionszeiten.
Ich werde das mal beobachten.
Die Probleme mit dem Spirit und das merkwürdige Verhalten des WDT bzw. die nicht nachvollziehbaren Log-Einträge haben sich nach dem Neupositionieren des Z-Wave Sticks erledigt. Jetzt funktioniert (ersteinmal) alles sauber.
2020-12-15_00:30:50 HK_Keller temperature: 17.43 C
2020-12-15_02:58:10 HK_Keller temperature: 16.99 C
2020-12-15_05:30:00 HK_Keller set_desired-temp 20.0
2020-12-15_05:30:03 HK_Keller desired-temp 20.0
2020-12-15_05:30:03 HK_Keller desired-temp: 20.0
2020-12-15_05:55:58 HK_Keller temperature: 17.43 C
2020-12-15_06:11:12 HK_Keller temperature: 17.96 C
2020-12-15_06:19:20 HK_Keller temperature: 18.40 C
2020-12-15_06:32:32 HK_Keller temperature: 18.93 C
2020-12-15_06:50:50 HK_Keller temperature: 19.46 C
2020-12-15_07:43:40 HK_Keller temperature: 19.90 C
2020-12-15_20:00:00 HK_Keller set_desired-temp 14.0
2020-12-15_20:00:03 HK_Keller desired-temp 14.0
2020-12-15_20:00:03 HK_Keller desired-temp: 14.0
2020-12-15_20:54:07 HK_Keller temperature: 19.46 C
2020-12-15_21:27:39 HK_Keller temperature: 18.93 C
2020-12-15_22:03:12 HK_Keller temperature: 18.49 C
2020-12-15_23:00:06 HK_Keller temperature: 17.96 C
Das Verstellen des Displays (normal oder auf dem Kopf) erfordert neben
set $DEVICE configLCDInvert
einen weiteren Parameter (entweder Normal oder UpsideDown).
Diesen weiteren Parameter kann man aber bei der Eingabe gar nicht machen, da kein Feld für einen weiteren Parameter vorgesehen ist.
Es geht im Moment nur manuell über die Kommandozeile.
Kann ich nicht bestätgien.
Es wird eine Auswahlliste "Normal" oder "UpsideDown" angeboten.
Hört sich für mich nach diesem Fehler an:
https://forum.fhem.de/index.php/topic,116748.0.html (https://forum.fhem.de/index.php/topic,116748.0.html)
Das war es... Danke für den Hinweis und danke an Rudolf für das schnelle fixen.
Wie ist denn euer Fazit mittlerweile mit den Geräten?
Sind sie zuverlässig?
Sind sie abseits von den Smarthome Fähigkeiten auch sonst anständige Thermostate was die Temperaturregelung angeht?
Wir werden wenn die Renovierungsarbeiten dann irgendwann durch sind nächstes Jahr von unserer Wohnung mit komplett Fußbodenheizung in ein Haus wechseln, in dem nur im Erdgeschoss eine Fußbodenheizung liegt und in den oberen Stockwerken normale Heizkörper verbaut sind.
Da ich ungern nur für Heizung in ein weiteres System wie Homematic investieren würde, kämen mir diese ZWave Geräte ganz gelegen...
Zitat von: Beta-User am 12 November 2020, 11:39:21
Allerdings besteht weiter das Problem, dass man unterschiedliche Ergebnisse hat, je nachdem, wie man die Wunschtemperatur vorgibt...
An sich sollten set DEVICE desired-temp 19, set DEVICE thermostatSetpointSet 18.5 und das "Knöpfedrücken" am HT selbst auf diese Temperatur immer (fast) dieselben Ergebnisse liefern, tatsächlich sieht das aber noch so aus:
setstate ZWave_THERMOSTAT_20 2020-11-12 08:17:40 desired-temp 19
setstate ZWave_THERMOSTAT_20 2020-11-12 08:18:37 thermostatSetpointSet 18.5
setstate ZWave_THERMOSTAT_20 2020-11-12 08:20:44 setpointTemp 19.0 C heating
Damit sollte man ja ein über alle 3 Events triggerndes Userreading erstellen können, welches die wirkliche Solltemperatur enthält.
Hallo
Hatte zuerst Danfoss und Devolo.
Hab dann in der Wohnung zwei Fibaro eingebaut.
Und zuletzt noch zwei Aeotec im Bad und Eingang.
Der Danfoss und Devolo hat Batterie die gewechselt werden muss.
Hab zuerst gedacht das Teil ist schlecht, aber mitlerweilen ist das der beste Thermostat.
Der Nachteil ist das die Innere Uhr sehr ungenau läuft.
Er muss gewekt werden, bei Temperatur Umstellung.
Der Vorteil er ist leise.
Der Fibaro ist gut aber leider zu laut.
Der musste bei mir in der Wohnung gleich wieder raus, hab diese jetzt in zwei Zimmer.
Vieleicht werden sie nach der Einstelphase etwas leiser.
Der Fibaro hat ein Akku und muss geladen werden.
Diesen gibt es auch mit Externem Themperatursensor.
Dieser Thermostat muss nicht gewekt weden, Themperatusumstellung etc geht hier schnell.
Der Aeotec hat auch Batterien die getauscht werden muss.
Ist leiser als der Fibaro aber etwas lauter als der Devolo.
Umstellen geht auch ohne aufzuweken.
Ist Softwaremäsig wohl am besten von allen drei.
Der Aeotec ist eventuel Baugleich mit dem Eurotronic Spirit.
Was mir bei allen noch fehlt ist ein Batterie_Modul für FHEM das die Batterie Überwacht und das vor Ausfall meldet.
Jeder hat hier sein eigenes Doif oder so.
Etwas das die Akkustände selbstständig holt und berechnet wann sie zu wechseln sind.
Das mit battery state manuell abholen hab ich bei dem einen oder anderen exotischen ZWAVE Gerät auch.
Würde ich hier also auch überleben wenn solche Dinge die einzigen größeren Macken sind ...
Sonst noch jemand mit Langzeiterfahrung ne Meinung dazu, ob er das Spirit weiterempfehlen würde? :)
Hallo zusammen,
man muss sich eben mit den Besonderheiten arrangieren. Bei mir funktioniert das mit dem Batteriestatus übrigens problemlos. Ärgerlichher ist, dass die Temperatur und die Ventilwerte nicht anhand der Einstellungen geschickt werden.
Für die verschiedenen Möglichkeiten Temperaturen einzustellen, habe ich mir ein doif gebaut, das mit entsprechend alle notwendigen readings versorgt.
Generell bin ich mit der Qualität sehr zufrieden und habe meine schon seit mehreren Jahren in Einsatz.
Viele Grüße
Torsten
Super danke dir. :)
Bin Leid gewohnt was den SmartHome Bereich angeht.
Wichtiger ist, dass die Grundfunktion (Heizen) anständig funktioniert und man Besonderheiten eben zuverlässig mit solchen Workarounds in den Griff bekommt.
Zitat von: Thyraz am 14 März 2021, 10:30:12
Wie ist denn euer Fazit mittlerweile mit den Geräten?
Sind sie zuverlässig?
Ich bin nach Anfangsschwierigkeiten recht zufrieden. Insbesondere die Anlernerei ist unzuverlässig und übel. Wegen der nicht freiwillig rausgerückten Werte sowie meines Federspannungsproblems (Hubweg nur 1,5 .. 2mm) habe ich einiges an Konfiguration drumrum - wobei das meiste durch die Diskussion in diesem Thread entstand. Wollte ich eigentlich komplett zeigen, stimmt.
Ich bin recht zufrieden.
Hallo,
ich bin am Überlegen den Spirit an einer Problemheizung einzusetzen. Bei dieser Heizung kommt nur die manuelle Steuerung per PID und gesendetem Stellwert in Frage.
Dazu habe ich allerdings eine paar Fragen ... ich hab nix gefunden:
1. Verhalten bei Batterie leer. Wie verhält sich der Spirit hier. Fährt er auf 50% auf? Oder bleibt er dumm auf der letzten Position stehen?
2. Verhalten bei Kommunikationsverlust: Wie verhält sich der Spirit im Stellwertmodus, wenn die Zentrale nicht verfügbar ist? Von anderen Reglern kenne ich es, dass sie auf den Automatik-Modus umschalten und dann wieder auf Stellwert zurück, wenn
das Funksignal wieder da ist.
Hi,
zu1: Wenn du das Thermostat leer werden lässt, dann bleibt es auf dem aktuellen Wert stehen. In der Regel merkt man aber, wenn die Batterien schwächer werden. Entweder über die Rückmeldung der Batterie-Ladung, oder aber passiv über komisches Verhalten der Themostate ...
zu2: Da es ja keinen Heartbeat gibt, wartet das Thermostat einfach auf Stellwerte. Wenn es keine mehr bekommt, z.B. weil die Zentrale ausfällt, dann bleibt es einfach beim alten Stellwerk stehen.
Ich denke das ZWave solche Heartbeat-Szenarien nicht sinnvoll abdecken kann ...
Vielen Dank für die Antwort. Dann ist das Spirit für mich das falsche Thermostat/Stellantrieb. Bei Enocean gibt es Thermostate/Stellantriebe,
die das können. Diese fehlenden Features in der Firmware erklären dann warum das Spirit so preiswert ist im Vergleich zu den Enos.
Zitat von: rudolfkoenig am 11 November 2020, 22:27:02
Ich habe ZWDongle mit dem setReadingOnAck Attribut erweitert:
"If the attribute is set to 1, and a set command with an argument is issued to a ZWave device, then a reading with the same name will be updated upon reception of the corresponding ZWave ACK radio telegram."
Bei den Spirits besteht ja das Problem dass man den Thermostatmodus mit diversen unterschiedlichen Befehlen setzt, also z.B. set <device> tmOn, tmOff, tmHeating, tmEnergySaveHeating und den Status aber immer nur mit get <device> thermostatmode abfragen kann.
Das automatische Update auf ein gleichen Namen hilft hier nicht viel und gerade das Abfragen des Modus in dem sich der Thermostat befinet wäre aber sehr wichtig.
ZitatDas automatische Update auf ein gleichen Namen hilft hier nicht viel und gerade das Abfragen des Modus in dem sich der Thermostat befinet wäre aber sehr wichtig.
Ich habe jetzt ein zusaetzliches Befehl "thermostatMode" hinzugefuegt. Wenn man statt tmOff, etc diesen verwendet, dann duerfte die Abfrage des aktuell eingestellten Wertes einfacher sein.
Zitat von: rudolfkoenig am 08 Januar 2023, 13:29:21
Ich habe jetzt ein zusaetzliches Befehl "thermostatMode" hinzugefuegt. Wenn man statt tmOff, etc diesen verwendet, dann duerfte die Abfrage des aktuell eingestellten Wertes einfacher sein.
Perfekt! Diese Änderung ist genial und hilft sehr und die unendlichen Klimmzüge die man bei den ZWave Spirits teilweise machen musste um aktuelle Werte zu erhalten sind damit Vergangenheit!
Was noch eine weitere sehr sinnvolle Ergänzung wäre, würde man auch die Abfrage der Ventilstellung (wird gesetzt mit set $DEVICE dim xx) ebenfalls mit einem get abfragbar erhalten (beim Spirit mit get $DEVICE swmStatus).
Hallo Rudi,
m.E. werden jetzt beim Set und get thermostatmode aber zu viel und unpassende Modi angezeigt z.B. cooling, fan, furnace...
VG
Torsten
Zitatm.E. werden jetzt beim Set und get thermostatmode aber zu viel und unpassende Modi angezeigt z.B. cooling, fan, furnace...
Und warum genau ist das gefaehrlich?
Hallo Rudi,
ich habe nichts von gefährlich geschrieben, aber die Übersichtlichkeit geht verloren, man muss durch lange Liste scrollen, um die richtigen Modi zu finden und es sitzen nicht nur Experten davor, die sinnvolle und unsinnige Modi unterscheiden können.
Mit anderen Worten, einfach nicht alltagstauglich.
VG
Torsten
ZitatMit anderen Worten, einfach nicht alltagstauglich.
Das mag man so sehen, der neue Befehl duerfte aber kein Rueckschritt im Vergleich zu den (weiterhin vorhandenen) expliziten Befehlen tmOff, tmHeating, tmCooling, usw. sein.
Die Aenderung sollte auch nicht die Menge des Auswahls reduzieren, sondern das Problem von @omnior loesen, dass der aktuelle Status einfach ablesbar ist, und die Loesung scheint ihm zu genuegen.
Torsten, ich verstehe auch deine Problem nicht. Auch wenn ich direkt mit den tm... Befehlen wie bisher die Modi setzen wollte muss ich mich durch genauso lange Listen scrollen, die Übersichtlichkeit ist die gleiche.
Hier ging es aber darum dass eben die set und get Befehle bei den spirits nicht identisch verwendbar waren und gerade beim Modus (aber auch nach wie vor bei der Ventilstellung ;)) war es extrem nervig dass man in vielen Übersichten oder readingsgroups keine automatische Aktualisierung erhielt wenn aufgrund irgendeiner Zustandsänderung, Timers, DOIF oder sonstwas sich der Modus änderte. Natürlich haben sich dafür Lösungen gefunden, die waren aber teilweise recht kompliziert und aufwändig, ich würde eher diesen Zustand als nicht alltagstauglich beschreiben und mit der jetzigen Änderung dürften sich viele in der Zukunft leichter damit tun.
Hallo Ihr Beiden,
es geht mir doch gar nicht um die neue Funktionalität, die ich auch sinnvoll finde.
Was mich stört sind einfach die unpassenden Modi für ein Heizkörperventil im allgemeinen und speziell für den Sprit. In den beigefügten Screenshots findet Ihr die Doku zu den Modi des Spirit (Off, Heat=Heating in fhem, Energy Heat = EnergySaveHeating in fhem, full Power und Manufactuar specific = manual in fhem).
Im zweiten Screenshot seht Ihr was zumindest in meiner fhem Installation an Modi zur Auswahl steht. Und da sind eben Modi dabei, die machen keinen Sinn. Vielleicht gibt es die auch schon länger unabhängig von der jetzigen, funktionalen Änderung, wodurch ich darüebr gestolpert bin.
Letztendlich kann ich damit leben, da ich bei mir alles automatisiert habe und selten über das device selbst steuere. Aber vielleicht gibt es andere Anwender, die mit den "falschen" Modi nicht zurecht kommen.
Viele Grüße
Torsten
Zitat von: rudolfkoenig am 08 Januar 2023, 13:29:21
Ich habe jetzt ein zusaetzliches Befehl "thermostatMode" hinzugefuegt. Wenn man statt tmOff, etc diesen verwendet, dann duerfte die Abfrage des aktuell eingestellten Wertes einfacher sein.
Diese Änderung ist im Prinzip klasse, ich benutzte weekdayTimer und weekprofile um die Thermostate zu steuern. Ich habe nun festgestellt, dass "manchmal" die Befehle aber nicht ankommen oder nicht ausgeführt werden und suche nun eine Möglichkeit wie fhem feststellen kann ob der Befehl tatsächlich angekommen ist. Als Beispiel: Der Thermostat soll in der Früh um 6:00 Uhr auf thermostat heating gestellt und dann um 6:01 die Temperatur auf 20 Grad gestellt werden, das ist über den weekdayTimer so eingestellt und funktioniert auch grundsätzlich.
Hier mal ein Beispiel aus dem Log, gestern tadellos, jeweils das Set und direkt dahinter das automatische Get.
2023-01-24_06:00:00 ZWave_THERMOSTAT_46 thermostatMode Heating
2023-01-24_06:00:07 ZWave_THERMOSTAT_46 thermostatMode: Heating
2023-01-24_06:01:00 ZWave_THERMOSTAT_46 desired-temp 20.0
2023-01-24_06:01:02 ZWave_THERMOSTAT_46 desired-temp: 20.0
Heute sieht der log folgendermaßen aus:
2023-01-25_06:00:00 ZWave_THERMOSTAT_46 thermostatMode Heating
2023-01-25_06:01:00 ZWave_THERMOSTAT_46 desired-temp 20.0
2023-01-25_06:01:01 ZWave_THERMOSTAT_46 desired-temp: 20.0Der Set Heating Befehl kam wohl beim Thermostat an denn er wurde geloggt, aber er wurde tatsächlich nicht ausgeführt, denn der Thermostat ist immer noch im Zustand Off. Der Get Befehl scheint zu fehlen kam offenbar nie an bzw. wurde nicht ausgelöst. Zwar wurde im nachfolgenden Schritt die Solltemperatur auf 20 Grad gestellt, aber solange das thermostatMode Heating nicht ankommt, gilt natürlich immer noch der vorherige Zustand Off.
Was könnte ich hier tun um irgendwie sicherzustellen dass Befehle auch ankommen und verarbeitet werden?
ZitatWas könnte ich hier tun um irgendwie sicherzustellen dass Befehle auch ankommen und verarbeitet werden?
Wg. Ankommen:
Ich wuerde erst ein "set neighborUpdate" auf alle Geraete durchfuehren, und danach jeweils ein "get neighborList".
Mit diesen Daten kann man Verbindungen im ZWDongle Detailansicht visualisieren (Show neighbor map), und, wenn noetig, einen Router an richtigen Stelle spendieren.
Wenn ich mich recht erinnere, gibt es Probleme wenn man die o.g. Befehle in Batch ausfuehrt.
Erst wenn das nicht funktioniert, ueber eine Software-Loesung nachdenken.
Eigentlich(TM) muesste der Transceiver ein NO_ACK generieren, falls die Nachricht vom Endgeraet nicht bestaetigt wurde, was wiederum im FHEM-Log und im transmit Reading hinterlegt wird. setReadingOnAck funktioniert natuerlich auch nur, wenn ein ACK kommt.
Falls keine NO_ACK Nachrichten im Log stehen, dann spricht das fuer einen Verarbeitungsfehler, in diesem Fall habe ich aber keine sinnvollen Ratschlaege.
Hallo omnior,
lese leider nur mehr sporadisch mit...
habe bei mir auch einige dieser Thermostate mit Weekdaytimer im
Einsatz.
Habe aber eine andere heran gehens weise und zwar sind die
Thermostate dauernd im Thermostat Mode Manual und steuere sie
dann über das PID20 Modul an.
Funktioniert soweit ganz gut, habe aber trotzdem einige no Ack
Meldungen im Log pro Tag. Wurde hier aber schon öfter moniert
ohne wirkliche Lösung.
Auch sind im Haus einige ZWave Steckdosen + Relais als Repeater verbaut.
Generell versuche ich jetzt wenn es irgend geht alles weiter auf 1Wire umzustellen.
Gruß
Hans-Jürgen