(gelöst)Unterschied setpointHeating und desired-temp bei Thermostat

Begonnen von Damu, 30 Dezember 2020, 13:14:40

Vorheriges Thema - Nächstes Thema

Damu

Hallo

Habe einen Fibaro und ein Aeotec Thermostat.
Wie stell ich hier die gewünschte temperatur ein?
Es gibt setpointHeating und desired-temp.
Was ist hier der unterschied?

Beta-User

Es gibt uU. den Unterschied, das bei dem ersteren nur ganzzahlige Werte zulässig sind (es kann aber auch sein, dass das nur einen dritten Setter betrifft, der nochmal dasselbe machen könnte).

Tendenziell würde ich vor dem Hintergrund der aktuellen Threads rund um den Spirit (v.a. https://forum.fhem.de/index.php/topic,112955.0.html) empfehlen, "setReadingOnAck" am IO zu aktivieren und dann mit desired-temp zu arbeiten. Damit sollten sich die Thermostate am ehesten wie die anderer Typen verhalten.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rudolfkoenig

Zitat aus dem commandref:
ZitatsetpointHeating value
    set the thermostat to heat to the given value.  The value is an integer in celsius.
    See thermostatSetpointSet for a more enhanced method.
...
desired-temp value
    same as thermostatSetpointSet, used to make life easier for helper-modules

Damu

Vielen Dank.
Werde meine Thermostate mal nach dieser Vorlage einrichten.
https://forum.fhem.de/index.php/topic,112955.msg1096047.html#msg1096047
Das mit der Batteriebafrage, muss ich mich noch etwas besser anschauen.
Das muss nicht alle Tage sein?
Irgend ein Feriendummy auf "Ferien", braucht es das sicher auch nicht.
Alle Tage vielleicht unter 35% und davor alle Wochen, oder so?



Beta-User

Falls wirklich der erste Beitrag in dem Thread gemeint war: Grusel...

Das "get" ist bei der Batterie nur selten erforderlich, in den allermeisten Fällen muss man den Thermostat einfach nur passend konfigurieren, dann sendet der von alleine einmal am Tag den Batteriewert.

Weiter ist das "get" auf den Status mAn. auch überholt, wenn du das bereits genannte Attribut setzt...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Damu

Bein der Beitrag:
ZitatAntwort #152 am: 28 Oktober 2020, 07:01:22 »

Bin da für mich aber noch auf was Anderes gestossern:
PID120 und Externer Thermometer.

Geht das bei Fibaro auch?
Habe 3 Fibaro
1 ist mit Fibaro Thermo Sensor, die anderen 2 ohne.
Bei dem Fibaro wo der Thermo Sensor angemeldet ist, ist wirklich schlecht weil der Thermostat direkt beim Fernseher, Verstärker etc... hängt.
Wäre eventuel besser das mit FHEM oder mit einem guten Sensor zum machen.
Denke hier an Secure SES301, SES302 oder SES303.

Beta-User

Es sollte kein Problem (mehr) sein, einen externen Temperaturwert als Messgröße an jedes beliebige ZWave-Gerät zu senden, das das versteht. Evtl. muß das Zielgerät aber dafür konfiguriert sein, dass es den externen Wert verwendet.

Und prinzipiell kann das über FHEM auch jeder x-beliebige Thermometer sein, ich würde dafür z.B. einen BT-Xiaomi (eckig und umgeflasht) hernehmen. Gut, günstig, lange Batterielaufzeit und mit Display...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

ToKa

#7
Hallo Beta-User,

das mit dem BT-Xiaomi klingt interessant und sieht chic aus. Wie wird denn der BT-Xiaomi an fhem angebunden? Wie genau ist die Messung und die Reichweite? Hast Du da Erfahrungen?

Beste Grüße und einen guten Rutsch
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

Beta-User

Bei mir laufen die über zwei OpenMQTTGateway (=>MQTT2_DEVICE, ESP32), zumindest mit der Standardfirmware sollte auch das Modul von CoolTux gehen (Pi-BT-Schnittstelle).

Reichweite ist "so so la la", wobei das eher an den ESP32 liegt und es besser wird, wenn man da eine alternative firmware drauf macht (https://github.com/atc1441/ATC_MiThermometer). Dann reicht "passive listening"...

Genauigkeit würde ich mit "schwer ok" bezeichnen, aber Doku oder Messungen habe ich dazu wenig anzubieten. Man könnte die mit der alternativen firmware dann auch kalibrieren (0-Punktverschiebeung), wenn man unbedingt möchte...
Jedenfalls sind meine Mitbewohner zufrieden, seit ich die als (virtuelle) Peers für meine HM-CC-RT im Einsatz habe, von daher habe ich das jetzt so nach und nach in diese Richtung auch ausgebaut (wegen der Displays in BT und nicht in ZigBee).

Wer ZigBee im Einsatz hat: Es gibt auch da zwischenzeitlich welche von diesem Hersteller mit Display, afaik (bezahlbar).

Ich habe auch zwei runde (LYWSDCGQ) mit LCD im Einsatz, die laufen auch noch mit der ersten Batterie, seit etwas mehr als einem Jahr (38 und 57%, was immer das bedeuten mag)...

Guten Rutsch zurück!
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Damu

Bei meinen Aeotec Thermostaten hab ich:
StateFormat heist bei mir:
Zitat{
sprintf(
        "Ist: %.1f Soll: %.1f Ventil: %d %% Mode: %s %s",
        ReadingsNum($name,"temperature",0),
        ReadingsNum($name,"desired-temp",0),
        ReadingsNum($name,"valve",0),
        ReadingsVal($name,"thermostatMode",0),
        ReadingsVal($name,"transmit",0)
    )
}
Hab als Reading: desiredTemp und desired-temp.

Für was ist:
ZitatuserReadings valve:reportedState.* { ReadingsNum("$name","reportedState",0) }, desiredTemp:setpointTemp.* { ReadingsNum("$name","setpointTemp",0)}
Braucht mann das?




Damu

ZitatEs sollte kein Problem (mehr) sein, einen externen Temperaturwert als Messgröße an jedes beliebige ZWave-Gerät zu senden, das das versteht. Evtl. muß das Zielgerät aber dafür konfiguriert sein, dass es den externen Wert verwendet.
Senden schon, aber ob er die Temperatur wirklich akzeptiert ist was anderses, da Fibaro ja seine eigenen Externen Thermeraturfühler für den Thermostat verkaufen will.

set Thermostat desired-temp 7-28
Ist bei mir ein Schieberegler und läst nur Ganzzahlen zu.
Ist das so gewollt??

Das Vorgeschlagene DOIF ist etwas kompliziert und hat bei mir nicht funktioniert, ist das korrekt so?
Zitatdefine 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

Ist "SollArbeitszimmer" ein Dummy oder erzeugt das das DOIF selbst?
"attr di_Thermostat_Arbeitszimmer stateFormat gewaehlt: SollArbeitszimmer" "gewaehlt:"?

Und noch ein Frohes Neues JAHR.



ToKa

Zitat von: Beta-User am 31 Dezember 2020, 15:09:17
Bei mir laufen die über zwei OpenMQTTGateway (=>MQTT2_DEVICE, ESP32), zumindest mit der Standardfirmware sollte auch das Modul von CoolTux gehen (Pi-BT-Schnittstelle).

Reichweite ist "so so la la", wobei das eher an den ESP32 liegt und es besser wird, wenn man da eine alternative firmware drauf macht (https://github.com/atc1441/ATC_MiThermometer). Dann reicht "passive listening"...

...

Hallo Beta-User,

vielen Dank für die weiteren Hinweise und Informationen. Habe das Modul von Cooltux gefunden und damit bräuchte ich nicht einmal weitere Hardware außer den Thermometern. OpenMQTTGateway klingt auch sehr spannend, aber setzt ja weitere Hardware voraus, wenn ich es richtig verstanden habe.

Werde mal schauen, wo ich günstig die eckigen von Xiaomi finden kann.

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

Beta-User

Zitat von: ToKa am 01 Januar 2021, 14:31:01
[...] Modul von Cooltux gefunden und damit bräuchte ich nicht einmal weitere Hardware außer den Thermometern. OpenMQTTGateway klingt auch sehr spannend, aber setzt ja weitere Hardware voraus, wenn ich es richtig verstanden habe.
Bitte frage aber ggf. vor dem Umflashen der Sensoren nach, ob das Modul das dann auch kann, und ja, die Dinger sind wirklich günstig ;) . Habe ca. 6 Euro/Stk. bezahlt, kann schon sein, dass die jetzt noch billiger zu haben sind.
Die "weitere Hardware" ist ein ESP32, Kostenpunkt ~5 Euro, zzgl. der Hardware für's Flashen (nix besonderes, einfach irgendein USB-seriell-Wandler).

Zitat von: Damu am 01 Januar 2021, 13:21:25
Senden schon, aber ob er die Temperatur wirklich akzeptiert ist was anderses, da Fibaro ja seine eigenen Externen Thermeraturfühler für den Thermostat verkaufen will.
Wenn die externen, die Fibaro verkauft auch ZWave sind, würde ich mal behaupten, dass das Protokoll so stark standardisiert ist, dass das auch mit dem "fake"-FHEM-Wert klappt!

Und irgendwie scheint noch nicht angekommen zu sein, dass das "get" NICHT MEHR NOTWENDIG ist, das DOIF in der Form ist also neuerdings nicht mehr erforderlich, wenn du "setReadingOnAck" auf 1 stellst (am ZWDongle).
Auch der zitierte userReadings-Code ist weitestgehend überholt, bei Gelegenheit muss ich allerdings mal checken, ob das alles noch zusammenpasst (ist leider liegen geblieben).
Aktuell sieht das bei mir 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)}, \
desired-temp:(setpointTemp.+heating|thermostatSetpointSet.*|.*tmEnergySaveHeating|.*tmHeating) {ReadingsAge($name,'setpointTemp',100) > 0 ? ReadingsNum($name,'thermostatSetpointSet',0) : ReadingsAge($name,'state',100) > 0 ? ReadingsNum($name,'setpointTemp',0) : ReadingsVal($name,'state',"unknown") eq "tmEnergySaveHeating" ? ReadingsNum($name,'energySaveHeating', 18) : ReadingsVal($name,'state',"unknown") eq "tmHeating" ? ReadingsNum($name,'heating', 22) : undef }, \
thermostatSetpointSet:desired-temp.* { ReadingsNum($name,'desired-temp',0) }

Da ich mir auch nicht sicher bin, ob das in allen Zeilen so sinnvoll ist, kann ich "braucht mand das" nicht abschließend beantworten. MAn. sollte es - wenn es fertig ist - dafür sorgen, dass es
a) "wurst" ist, welchen Setter man benutzt, alle "funktionsgleichen" Readings sollten dann synchron sein;
b) die Werte für die Betriebsmodus "energySaveHeating" und "heating" erfassen und als Reading hinterlegen und
c) einen Ventilwert als separates Reading liefern. "valve" ist vermutlich nicht gelungen, im Moment neige ich dazu, das "ValvePosition" zu nennen (wie bei CUL_HM), dann könnte man es auch für das Hilfsmodülchen "VALVES" nutzbar machen usw. usf..
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Damu

#13
Hallo
ZitatWenn die externen, die Fibaro verkauft auch ZWave sind, würde ich mal behaupten, dass das Protokoll so stark standardisiert ist, dass das auch mit dem "fake"-FHEM-Wert klappt!
http://manuals-backend.z-wave.info/make.php?lang=en&sku=FIBEFGBRS-001&cert=
Ist glaub nicht Z-Wave.
Ich denke das sich der FGBRS-001 nicht so einfach an FHEM anlernen lässt.
Hat glaub noch niemand gemacht.
ZitatUnd irgendwie scheint noch nicht angekommen zu sein, dass das "get" NICHT MEHR NOTWENDIG ist, das DOIF in der Form ist also neuerdings nicht mehr erforderlich, wenn du "setReadingOnAck" auf 1 stellst (am ZWDongle).
Ist schon angekommen.
Ich meine aber auch gelesen zu haben das es nicht zuverlässig funktioniert.



Damu

So hab gestern das Batterie "get Doif" gestoppt.
Hab bis jetzt noch kein Batterie_Update erhalten (2 x Aeotec 3 x Fibaro Thermostate).
classes und vclasses hab ich bei meinen Aeotec Thermostaten dieselbe eingetragen wie curt im Beitrag.

Zitatclasses   
Aeotec   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
Fibaro   ZWAVEPLUS_INFO VERSION MULTI_CHANNEL_ASSOCIATION SENSOR_MULTILEVEL THERMOSTAT_MODE THERMOSTAT_SETPOINT NETWORK_SCHEDULE SECURITY SECURITY_S2 TRANSPORT_SERVICE CRC_16_ENCAP ASSOCIATION_GRP_INFO DEVICE_RESET_LOCALLY MULTI_CHANNEL SUPERVISION ALARM MANUFACTURER_SPECIFIC PROTECTION BATTERY CONFIGURATION CLOCK FIRMWARE_UPDATE_MD POWERLEVEL APPLICATION_STATUS ASSOCIATION

Zitatvclasses   
Aeotec   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
Fibaro   ALARM:8 APPLICATION_STATUS:1 ASSOCIATION:2 ASSOCIATION_GRP_INFO:2 BATTERY:1 CLOCK:1 CONFIGURATION:1 CRC_16_ENCAP:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:4 MANUFACTURER_SPECIFIC:2 MULTI_CHANNEL:4 MULTI_CHANNEL_ASSOCIATION:3 NETWORK_SCHEDULE:1 POWERLEVEL:1 PROTECTION:1 SECURITY:1 SECURITY_S2:1 SENSOR_MULTILEVEL:5 SUPERVISION:1 THERMOSTAT_MODE:3 THERMOSTAT_SETPOINT:3 TRANSPORT_SERVICE:2 VERSION:2 ZWAVEPLUS_INFO:2
AssociationAdd hab ich nicht gemacht, das wird doch beim anlernen automatisch gemacht?


Beitrag 152 von curt

Zitat1) associationAdd - den korrekten Befehl reicht sicher jemand nach, mir nicht momentan.

Das Attribut setReadingOnAck hab ich bei diesem ZWDongle auf 1.
Das ZWDongle zeigt mir "Z-Wave 6.02 STATIC_CONTROLLER"
Das ist das Uart_ZWave Dongle von zwave.me (Z-Wave Plus 5th gen chip ZM5101    2018-)