Z-WavePlus Thermostat Eurotronic Spirit: Schrittweise Inbetriebnahme

Begonnen von curt, 17 Juli 2020, 22:36:14

Vorheriges Thema - Nächstes Thema

omnior

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).

ToKa

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
RaspberryPi3 mit RaZberry2 und Conbee II
Fibaro: FGWPE/F-101 Switch & FIBARO System FGWPE/F Wall Plug Gen5, FGSD002 Smoke Sensor
EUROtronic: SPIRIT Wall Radiator Thermostat Valve Control
Shelly2.5 Rollladenaktoren
Zipato Bulb 2, Osram und InnrLight

rudolfkoenig

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?

ToKa

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
RaspberryPi3 mit RaZberry2 und Conbee II
Fibaro: FGWPE/F-101 Switch & FIBARO System FGWPE/F Wall Plug Gen5, FGSD002 Smoke Sensor
EUROtronic: SPIRIT Wall Radiator Thermostat Valve Control
Shelly2.5 Rollladenaktoren
Zipato Bulb 2, Osram und InnrLight

rudolfkoenig

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.

omnior

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.

ToKa

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
RaspberryPi3 mit RaZberry2 und Conbee II
Fibaro: FGWPE/F-101 Switch & FIBARO System FGWPE/F Wall Plug Gen5, FGSD002 Smoke Sensor
EUROtronic: SPIRIT Wall Radiator Thermostat Valve Control
Shelly2.5 Rollladenaktoren
Zipato Bulb 2, Osram und InnrLight

omnior

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.0


Der 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?

rudolfkoenig

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.

Deckoffizier

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

FHEM 5.8 auf "yakkaroo Emu A1FL.1" mit CUL 868MHz, SIGNALduino,2 1Wire USB Busmaster, diverse 1 Wire Sensoren,Landroid,Aeotec USB Dongle Z-Wave Plus