Ich möchte in einer Readingsgroup in getrennten Spalten die Sollwerte meiner Spirit Devices anzeigen.
Und zwar in einer Spalte die Sollwerte der Absenktemperatur und in einer weiteren, den des normalen Heizmodus.
Wie mache ich das?
Das hier hast du dir angesehen: https://wiki.fhem.de/wiki/ReadingsGroup
Ansonsten (wie immer!) bitte lists mind. eines deiner Thermostate!
Wie ist bei dir die Namensvergabe der Geräte!?
Lässt sich das als DevSpec nutzen!?
Ansonsten kann/muss man evtl. mit TYPE "arbeiten" etc.
EDIT:
Zitat von: commandref"
Geräte-Spezifikation (devspec)
[EN DE]
Die Befehle attr, set, get, usw. attr, deleteattr, displayattr, delete, get, list, set, setreading, setstate, trigger können eine komplexere Gerätespezifikation als Argumente enthalten, die auch eine Anzahl von Geräten betreffen kann. Eine Gerätespezifikation kann folgendes sein:
ein einzelner Gerätename. Dies ist der Normalfall
eine durch Komma(,) getrennte Liste von Gerätenamen
ein regulärer Ausdruck
ein NAME=WERT Ausdruck, wo NAME ein "Internal" Wert wie TYPE ist, ein Reading-Name oder ein Attribut. WERT ist ein regulärer Ausdruck. Um die Bedingung zu negieren, muss NAME!=WERT verwendet werden. Um die Suche einzugrenzen, kann man als Praefix i: für internal Werte, r: für Reading-Namen und a: für Attribute verwenden, siehe das Beispiel unten. Groß-/Kleinschreibung wird durch die Verwendung von ~ oder !~ ignoriert.
Falls die Spezifikation von :FILTER=NAME=WERT gefolgt wird, dann wird die zuvor gefundene Liste durch diesen neuen Ausdruck gefiltert.
Beispiele:
set lamp1 on
set lamp1,lamp2,lamp3 on
set lamp.* on
set room=kitchen off
set room=kitchen:FILTER=STATE=on off
set room=kitchen:FILTER=STATE!=off off
list disabled=
list room~office
list TYPE=FS20 STATE
list i:TYPE=FS20 STATE
Bemerkungen:
die Spezifikation kann keine Leerzeichen enthalten.
falls ein Gerätename exakt dem Spezifikation entspricht, dann werden keine reguläre Ausdrücke oder Filter ausgewertet.
zuerst wird die durch Komma getrennte Spezifikation abgearbeitet, dann folgen die regulären Ausdrücke und die Filter
die Befehlszeile kann die selbe Gerätebezeichnung mehrfach enthalten z.B.: "set lamp3,lamp3 on". Lamp3 wird hier zwei Mal eingeschalten.
um Strukturen mit komplexeren Anforderungen zu realisieren lesen Sie bitte den Abschnitt zu structure.
Und dann bitte noch mal genauer (mit den tatsächlichen ReadingNamen) was wo stehen soll.
Gruß, Joachim
Waaaaa - das hatte ich ja glatt übersehen/verdrängt!
@MadMax-FHEM
Du bist auf der falschen Baustelle unterwegs, es geht im Moment gar nicht um ReadingsGroup - erstmal müssen die Daten in FHEM.
Ich nehme mal @Beta-User und @krikan mit rein:
Kirkan weiß es, er hat ja den Wiki-Artikel geschrieben: https://wiki.fhem.de/wiki/Z-Wave-Eurotronic_Spirit_Thermostat#Solltemperaturen
Es gibt zwei unterschiedliche Solltemperaturen. Das hatte ich schon wieder verdrängt - dabei läuft einer meiner Thermostaten tatsächlich auch im Modus tmEnergySaveHeating.
BTW: Meine bisherigen Konfigurationen/Scripts habe ich von @rcmcronny (großen Dank nochmals!), das ist das berühmte "desiredTemp" im Gegensatz zu desired-temp, greifen nur auf den Sollwert für heating zu ... gna.
@omnior
Bevor Du mit ReadingsGroup was anstellen kannst, musst Du aktiv (siehe verlinkten Absatz im Wiki-Artikel) vermittels GET die Sollwerte abrufen. Denn der Thermostat meldet nicht aktiv zurück, in FHEM stehen dann veraltete Readings. Ronny gab mir dafür ein Script, welches das alle 30 Minuten tut - glaube ich wenigstens. Ich kann morgen nachsehen.
Aber der TE Omnior hat doch speziell und ausdrücklich (Threadtitel und Fragestellung) nach readungsGroup gefragt!!
Gruß, Joachim
Hallo Joachim,
Du hast recht, vielleicht habe ich zu weit gedacht.
Zitat von: curt am 19 Oktober 2020, 01:32:17
Hallo Joachim,
Du hast recht, vielleicht habe ich zu weit gedacht.
Auch das ist noch nicht raus... ;)
Wir werden es (vielleicht) erfahren...
Gruß, Joachim
Zitat von: MadMax-FHEM am 19 Oktober 2020, 02:09:20
Auch das ist noch nicht raus... ;)
Um mal abzuschweifen oder auch nicht abzuschweifen:
Das Problem ist, dass es für den zweiten Sollwert (tmEnergySaving) sowie für die Ventilstellung kein Reading gibt - das bastelt sich jeder selbst. Oder auch nicht.
Bei genauer, systematischer Betrachtung wird auch klar, warum das so ist: Der Thermostat ist nicht so gesprächig, dass er diese Werte freiwillig rausrückt, da muss man schon ein GET losschicken. Dieses systematische Problem war bei meiner battery-Sache (gleiche Baustelle) irgendwie schon in meinem Unterbewusstsein. Aber erst mit diesem Thread wurde mir das Problem wegen des 2. Sollwerts so richtig klar.
Im Moment denke ich tatsächlich, dass das Modul umgestaltet werden muss (ohne das ich das auch nur ansatzweise könnte): Es muss diese (neuen/zusätzlichen) Readings geben, sie sind ja Eigenschaft des Geräts, der Device. Und dafür muss ich die Möglichkeit haben, für jedes neue Reading einen Zeitintervall-Default der Abfrage durch das FHEM-Modul zu überschreiben.
Aber erzähl das mal jemandem. Vermutlich kann ich nicht gut erklären. Oder wirke angriffslustig. Oder alle sind dünnhäutig. - Die Dinge sind so, wie die Dinge sind - ich muss das erstmal so zur Kenntnis nehmen.
Zitat von: MadMax-FHEM am 19 Oktober 2020, 02:09:20Wir werden es (vielleicht) erfahren...
@omnior
Wie steht es um Dein Problem?
Komm, erzähl frei raus - je mehr, desto besser! Keine falsche Scham, Du kannst Dich nicht blamieren - die Rolle habe hier schon ich. ;)
P:S: Ich hatte schon mehrere Thermostate verschiedener Funkprotokolle in den Händen. Der hier in Rede stehende Thermostat ist ganz subjektiv kein Schrott. Sondern eine Perle ... die wir halt noch polieren müssen.
Danke erstmal für eure Überlegungen. Aktuell hab ich es so eingerichtet, dass in meinem Readingsgroup über Commands jeweil alternativ der eine (SollSpar) oder der andere (SollHeat) Sollwert abgerufen werden kann (er wird dann auch angezeigt aber eben immer nur als !setpointTemp den setppointSparTemp kennt er natürlich nicht), damit probier ich im Moment herum, schaff es aber nicht beide Werte gleichzeitig darzustellen.
Die Readingsgroup sieht folgendermaßen aus:
Internals:
DEF <Raum>,<SollSpar>,<SollHeat>,<SollNeu>,<Ist>,<Ventil>,<Änderung>,<Batterie>,<Modus>,<M>,<->,<d>,<+> .*:FILTER=alias!=.*OFF:FILTER=model=EUROtronic.*:!setpointSparTemp,!setpointTemp,<sollsetz>,!*[Tt]emperature,reportedState,<{ReadingsTimestamp($DEVICE,"temperature","")}>,battery,thermostatMode,!Mode,<{myUtils_HeizungUpDown($DEVICE,"up")}@desired-temp>,desired-new,<{myUtils_HeizungUpDown($DEVICE,"down")}@desired-temp>
FUUID 5ce9a64e-f33f-5aeb-6144-8a57afdd9d7234c6
NAME Temperatur2
NR 103
NTFY_ORDER 50-Temperatur2
STATE Initialized
TYPE readingsGroup
changed 0
mayBeVisible 1
CONTENT:
ZWave_THERMOSTAT_31 1
ZWave_THERMOSTAT_32 1
ZWave_THERMOSTAT_33 1
ZWave_THERMOSTAT_38 1
ZWave_THERMOSTAT_40 1
ZWave_THERMOSTAT_42 1
ZWave_THERMOSTAT_44 1
ZWave_THERMOSTAT_45 1
ZWave_THERMOSTAT_46 1
ZWave_THERMOSTAT_55 1
CONTENT2:
DEVICES:
ARRAY(0x4767ef0)
ARRAY(0x4ebf3f0)
ARRAY(0x4f0b330)
ARRAY(0x4ed71c0)
ARRAY(0x4ded330)
ARRAY(0x4e54060)
ARRAY(0x4ed0410)
ARRAY(0x4ef36c8)
ARRAY(0x4ef24a0)
ARRAY(0x4ef1d50)
ARRAY(0x4f0b798)
fhem:
lastDefChange 158
last_update 1603271877.79897
helper:
DEF
commands {'setpointSparTemp'=>'get $DEVICE setpoint 11','setpointTemp'=>'get $DEVICE setpoint 1', 'Temperatur2.sollsetz'=>'desired-temp:5.0,12.0,18.0,19.0,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0','Temperatur2.m' => 'set $DEVICE desired-temp =-1;get $DEVICE setpoint','Temperatur2.p' => 'set $DEVICE desired-temp 20;get $DEVICE setpoint','reportedState' => 'get $DEVICE swmStatus','Mode' => 'get $DEVICE thermostatMode;get $DEVICE setpoint'}
mapping %ALIAS
nameStyle style="color:blue"
valueColumn {\
setpointSparTemp => 1,
setpointTemp => 2,\
temperature => 3,\
Temperatur2 => 3,\
reportedState => 4,\
timestamp => 5,\
battery => 6,\
thermostatmode => 7,\
}
valueFormat {temperature => "%.1f°C",
AM2301_Temperature => "%.1f°C",
setpointTemp => "%.1f°C",
timestamp => {ReadingsTimestamp($DEVICE,"temperature","")},
avg => "%.1f°C"
}
valueStyle {($READING eq "temperature" && $VALUE < ReadingsNum($DEVICE, "setpointTemp",undef))?'style="color:red;text-align:right;font-weight:bold"':($VALUE eq "00")?'style="visibility:hidden"':'style="color:green;text-align:right",'}
positions:
ZWave_THERMOSTAT_31.Mode 10:9
ZWave_THERMOSTAT_31.battery 10:7
ZWave_THERMOSTAT_31.desired-new 10:11
ZWave_THERMOSTAT_31.reportedState 10:5
ZWave_THERMOSTAT_31.setpointSparTemp 10:1
ZWave_THERMOSTAT_31.setpointTemp 10:2
ZWave_THERMOSTAT_31.temperature 10:4
ZWave_THERMOSTAT_31.thermostatMode 10:8
ZWave_THERMOSTAT_32.Mode 7:9
ZWave_THERMOSTAT_32.battery 7:7
ZWave_THERMOSTAT_32.desired-new 7:11
ZWave_THERMOSTAT_32.reportedState 7:5
ZWave_THERMOSTAT_32.setpointSparTemp 7:1
ZWave_THERMOSTAT_32.setpointTemp 7:2
ZWave_THERMOSTAT_32.temperature 7:4
ZWave_THERMOSTAT_32.thermostatMode 7:8
ZWave_THERMOSTAT_33.Mode 6:9
ZWave_THERMOSTAT_33.battery 6:7
ZWave_THERMOSTAT_33.desired-new 6:11
ZWave_THERMOSTAT_33.reportedState 6:5
ZWave_THERMOSTAT_33.setpointSparTemp 6:1
ZWave_THERMOSTAT_33.setpointTemp 6:2
ZWave_THERMOSTAT_33.temperature 6:4
ZWave_THERMOSTAT_33.thermostatMode 6:8
ZWave_THERMOSTAT_38.Mode 9:9
ZWave_THERMOSTAT_38.battery 9:7
ZWave_THERMOSTAT_38.desired-new 9:11
ZWave_THERMOSTAT_38.reportedState 9:5
ZWave_THERMOSTAT_38.setpointSparTemp 9:1
ZWave_THERMOSTAT_38.setpointTemp 9:2
ZWave_THERMOSTAT_38.temperature 9:4
ZWave_THERMOSTAT_38.thermostatMode 9:8
ZWave_THERMOSTAT_40.Mode 8:9
ZWave_THERMOSTAT_40.battery 8:7
ZWave_THERMOSTAT_40.desired-new 8:11
ZWave_THERMOSTAT_40.reportedState 8:5
ZWave_THERMOSTAT_40.setpointSparTemp 8:1
ZWave_THERMOSTAT_40.setpointTemp 8:2
ZWave_THERMOSTAT_40.temperature 8:4
ZWave_THERMOSTAT_40.thermostatMode 8:8
ZWave_THERMOSTAT_42.Mode 3:9
ZWave_THERMOSTAT_42.battery 3:7
ZWave_THERMOSTAT_42.desired-new 3:11
ZWave_THERMOSTAT_42.reportedState 3:5
ZWave_THERMOSTAT_42.setpointSparTemp 3:1
ZWave_THERMOSTAT_42.setpointTemp 3:2
ZWave_THERMOSTAT_42.temperature 3:4
ZWave_THERMOSTAT_42.thermostatMode 3:8
ZWave_THERMOSTAT_44.Mode 4:9
ZWave_THERMOSTAT_44.battery 4:7
ZWave_THERMOSTAT_44.desired-new 4:11
ZWave_THERMOSTAT_44.reportedState 4:5
ZWave_THERMOSTAT_44.setpointSparTemp 4:1
ZWave_THERMOSTAT_44.setpointTemp 4:2
ZWave_THERMOSTAT_44.temperature 4:4
ZWave_THERMOSTAT_44.thermostatMode 4:8
ZWave_THERMOSTAT_45.Mode 5:9
ZWave_THERMOSTAT_45.battery 5:7
ZWave_THERMOSTAT_45.desired-new 5:11
ZWave_THERMOSTAT_45.reportedState 5:5
ZWave_THERMOSTAT_45.setpointSparTemp 5:1
ZWave_THERMOSTAT_45.setpointTemp 5:2
ZWave_THERMOSTAT_45.temperature 5:4
ZWave_THERMOSTAT_45.thermostatMode 5:8
ZWave_THERMOSTAT_46.Mode 2:9
ZWave_THERMOSTAT_46.battery 2:7
ZWave_THERMOSTAT_46.desired-new 2:11
ZWave_THERMOSTAT_46.reportedState 2:5
ZWave_THERMOSTAT_46.setpointSparTemp 2:1
ZWave_THERMOSTAT_46.setpointTemp 2:2
ZWave_THERMOSTAT_46.temperature 2:4
ZWave_THERMOSTAT_46.thermostatMode 2:8
ZWave_THERMOSTAT_55.Mode 11:9
ZWave_THERMOSTAT_55.battery 11:7
ZWave_THERMOSTAT_55.desired-new 11:11
ZWave_THERMOSTAT_55.reportedState 11:5
ZWave_THERMOSTAT_55.setpointSparTemp 11:1
ZWave_THERMOSTAT_55.setpointTemp 11:2
ZWave_THERMOSTAT_55.temperature 11:4
ZWave_THERMOSTAT_55.thermostatMode 11:8
recalc:
undef
undef
undef
undef
ARRAY(0x4c9fec0)
values:
formated:
undef
ARRAY(0x4afe040)
ARRAY(0x274f340)
undef
ARRAY(0x4ecf6c0)
ARRAY(0x4ec7520)
undef
ARRAY(0x4ebf1e0)
ARRAY(0x48f6860)
ARRAY(0x4eebc10)
undef
ARRAY(0x4ca65f8)
orig:
undef
ARRAY(0x4e02718)
ARRAY(0x4ee8140)
undef
ARRAY(0x4ec81b0)
ARRAY(0x4e674b8)
undef
ARRAY(0x4ca6400)
ARRAY(0x4ef4008)
ARRAY(0x4eee880)
undef
ARRAY(0x4e54d00)
prefixsuffix:
undef
ARRAY(0x4c396b8)
ARRAY(0x4e5b5d8)
undef
ARRAY(0x4c9cfb8)
ARRAY(0x4ef5060)
undef
ARRAY(0x4b80478)
ARRAY(0x4ebb990)
ARRAY(0x4e514d8)
undef
ARRAY(0x4dea9d0)
Attributes:
alias Thermostate
commands {'setpointSparTemp'=>'get $DEVICE setpoint 11','setpointTemp'=>'get $DEVICE setpoint 1', 'Temperatur2.sollsetz'=>'desired-temp:5.0,12.0,18.0,19.0,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0','Temperatur2.m' => 'set $DEVICE desired-temp =-1;get $DEVICE setpoint','Temperatur2.p' => 'set $DEVICE desired-temp 20;get $DEVICE setpoint','reportedState' => 'get $DEVICE swmStatus','Mode' => 'get $DEVICE thermostatMode;get $DEVICE setpoint'}
comment reported State in der Def war vorher: <{ReadingsVal($DEVICE,"reportedState","")}>
nun geändert auf reportedState
und funktioniert damit auch
group ReadingsGruppe
icon icoTemp
mapping %ALIAS
nameStyle style="color:blue"
room 5. Umwelt,Küche,Übersicht
sortDevices 1
sortby 99
valueColumn {\
setpointSparTemp => 1,
setpointTemp => 2,\
temperature => 3,\
Temperatur2 => 3,\
reportedState => 4,\
timestamp => 5,\
battery => 6,\
thermostatmode => 7,\
}
valueFormat {temperature => "%.1f°C",
AM2301_Temperature => "%.1f°C",
setpointTemp => "%.1f°C",
timestamp => {ReadingsTimestamp($DEVICE,"temperature","")},
avg => "%.1f°C"
}
valueStyle {($READING eq "temperature" && $VALUE < ReadingsNum($DEVICE, "setpointTemp",undef))?'style="color:red;text-align:right;font-weight:bold"':($VALUE eq "00")?'style="visibility:hidden"':'style="color:green;text-align:right",'}
Ich bin mal ehrlich: ich habe keine Ahnung was du machst/willst bzw. wo konkret das Problem ist!?
Will sagen: mit deiner Problembeschreibung (wenn man das so nennen kann, also: meine Sicht) kann ich nichts anfangen.
Wie wäre es denn mit einem list eines der Thermostate!?
Evtl. etwas ausführlicher was denn schon geht (wenn schon etwas von dem geht was du willst) und was genau nicht geht...
Und: wie bist du zu der aktuellen readingsGroup (die gepostet wurde) gekommen!?
Gruß, Joachim
Sorry, wenn das nicht verständlich war. Es geht mir darum die beiden Sollwerte (für EnergySaveHeating und für Heating) in der Readingsgroup darzustellen. Die im Laufe der Zeit von mir zusammengebaute Readingsgroup stellt alle meine 10 Thermostate mit den aktuellen Ist und Sollwerten dar. Sie ermöglicht mir auch für jeden Thermostat direkt einen neuen Sollwert zu setzen. Das Problem ist hierbei eben nur, dass ich nicht gleichzeitig beide Sollwerte abfragen bzw. darstellen kann. Das muss ich aber, da einzelne Thermostate eventuell bewußt im Absenkmodus sind und andere nicht. Also möchte ich übersichtlich den aktuellen Modus des einzelnen THermostats und seinen Soll und Istwert sehen können.
Hier wie gewünscht noch ein List eines der Thermostaten.
Internals:
DEF e8edde56 44
FUUID 5cff4032-f33f-5aeb-bcc9-1736534d73314be2
IODev ZBoard
LASTInputDev ZBoard
MSGCNT 442
NAME ZWave_THERMOSTAT_44
NR 151
STATE tmHeating
TYPE ZWave
ZBoard_MSGCNT 442
ZBoard_RAWMSG 0004002c0631050142070e
ZBoard_TIME 2020-10-21 16:36:13
ZWaveSubDevice no
cmdsPending 0
homeId e8edde56
isWakeUp
lastMsgSent 1603290600.06516
nodeIdHex 2c
webCmd desired-temp
READINGS:
2020-10-17 05:39:31 SEND_DATA failed:00
2019-10-05 13:58:05 UNPARSED SENSOR_BINARY 06300501420805
2020-10-21 12:42:13 battery 45 %
2020-10-21 12:42:13 batteryPercent 45
2020-10-21 12:42:13 batteryState ok
2019-12-21 22:06:36 configBacklight BacklightEnabled
2019-06-11 08:17:12 configMeasuredTemperatureReport 5
2020-10-15 22:55:38 desired-new 00
2019-09-24 12:57:51 model EUROtronic EUR_SPIRITZ Wall Radiator Thermostat
2019-09-24 12:57:51 modelConfig eurotronic/eur_spiritz.xml
2019-09-24 12:57:51 modelId 0148-0003-0001
2019-09-25 17:33:45 neighborList ZWave_THERMOSTAT_42 ZWave_THERMOSTAT_45
2020-10-17 05:59:42 reportedState dim 4
2020-10-21 11:10:53 setpointTemp 18.0 C heating
2020-10-21 16:30:00 state tmHeating
2020-10-21 16:36:13 temperature 18.06 C
2020-10-21 11:10:52 thermostatMode energySaveHeating
2020-10-16 23:35:46 thermostatSetpointSupported heating energySaveHeating
2020-10-21 11:10:53 timeToAck 0.095
2020-10-21 11:10:53 transmit OK
2019-09-24 12:57:52 zwavePlusInfo version:01 role:SleepingListeningSlave node:Z-Wave+Node installerIcon:1200 userIcon:1200
Attributes:
IODev ZBoard
alias Bad EG Thermostat
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 Bad EG,ZWave
sortby 50
userattr heizt heizt_map structexclude
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[code]
Ok.
Aber trotzdem (noch mal):
Was geht schon!?
Was geht noch nicht!?
Geht es für manche Thermostate!?
Für gar keines!?
Alle selber Typ!?
Weil: (wo immer du Sachen "her geklaut" hast) du hast (zumindest sehe ich es nicht) kein desired-temp! Darauf zielen aber die myUtils_HeatingUpDown ab... Was macht die myUtils_HeatingUpDown (ok, ja ich kann's mir denken ;) ) wo hast du das "Konstrukt" her? Aus wie vielen Quellen hast du "zusammenkopiert"? Wie war dein Vorgehen? Weil es ist eine ganz schön "üppige" readingsGroup, wenn du wirklich "nur" Ist/Soll mit "hoch/runter" haben willst...
Ich weiß auch nicht wieviel Arbeit du schon reingesteckt hast...
...aber ich würde erst mal (noch mal / überhaupt mal) beschreiben: welche Readings du wie dargestellt haben willst...
Ich sehe auch weitere Readings, die du in der readingsGroup haben willst, dein Device aber (noch) nicht hat...
Daher wohl auch die "!" (Ausrufezeichen) in der readingsGroup!?
Musste erst nachschauen wozu das überhaupt gut ist...
Ich habe ja auch eine Übersicht, so wie du sie evtl. willst.
Allerdings ganz ohne Ausrufezeichen etc.
Bild anbei...
DEF (nur bzgl. Wandthermostate) hier:
<Raum>,<Ist>,<Soll>,<>,<>,<Luft>,<Taupunkt>,<> NAME=Wand.*_Climate:measured-temp,desired-temp,<{my_HeatingUpDown($DEVICE,"up")}@desired-temp>,<{my_HeatingUpDown($DEVICE,"down")}@desired-temp>,humidity,dewpoint,<{my_SetHeatingModeIcon($DEVICE)}@controlMode>
Meine Wandthermostate heißen alle Wandthermostat_Raum
EDIT: liefern im _Clima Kanal (ist bei Homematic so) mit dem Reading temperature die IST und im Reading desired-temp eben die SOLL. In humidity noch die Luftfeuchte und in controlMode noch den aktuellen Modus (auto, manuell, ...)
Die sub my_HeatingUpDown stellt eine neue Soll ein und liefert ein entsprechendes Icon zurück (je nachedem ob "up" oder "down")...
Sieht aus wie bei dir ;)
ABER: wie geschrieben ich sehe kein Reading desired-temp bei dir...
EDIT: also wenn ich weiß welche Readings du in der readingsGroup anzeigen willst und welches Reading WAS ist (IST/SOLL) und wie du neue SOLL setzen kannst, dann können wir auch noch mal (parallel) anfangen und die readingsGroup aufbauen wie du sie haben willst. Deine umbauen ist mir zu kompliziert! (da bin ich ehrlich)
EDIT: und wie der Name readingsGroup ausdrückt damit ist es möglich Readings von Devices geordnet darzustellen (und mehr ;) )... Aber es müssen schon Readings sein, die das Device auch hat... ;) Wenn sie (noch) nicht so sind wie du sie möchtest/brauchst, gibt es auch userreadings (beim Device selbst!) damit kann man sich Readings "umbauen" etc.
EDIT: wenn das was ich im Bild zeige nicht das ist (in etwa) was du willst, dann sorry, dass ich hier geantwortet habe! Aber in dem Fall bin ich (total) raus...
Gruß, Joachim
Hallo Joachim, danke nochmal für deine Hilfe. Ich will versuchen es nochmal zu erklären.
Grundsätzlich funktioniert diese Readingsgroup wunderbar, mit allen Thermostaten so wie ich es will.
Die Zwave Eurotronics haben jeweils einen unterschiedlichen Sollwert für die Absenktemperatur und für die normale Temperatur. Das ist eigentlich sehr praktisch, weil man einfach nur den Modus "absenken" oder "normales Heizen" umstellen kann.
Das Problem ist jetzt dass in meiner Readingsgroup bisher immer nur ein Sollwert angezeigt wird und zwar derjenige des gerade eingestellten Modus. Nur das wollte ich ändern.
Den Sollwert kann man mit desired_temp setzen aber auch mit setpoint (mit zusätzlichem Parameter). Diese zweite Variante hat den Vorteil dass man mit setpoint 11 den Absenksollwert und mit setpoint 1 den normalen Sollwert setzen und entsprechend auch abfragen kann. Man erhält dann den setpointTemp und den Modus dazu. Desired_temp geht halt auf den Sollwert des gerade eingestellten Modus. Ich möchte aber beide Sollwerte hier anzeigen und das gelingt mir irgendwie nicht.
Der Grund ist sicherlich, dass das Device eben nur den Sollwert des gerade eingestellten Modus als reading hergibt (in setpointTemp). Wenn ich dieses Reading in der Readingsgroup benutze bekomme ich halt immer nur den aktuellen Sollwert (was prinzipiell ja auch ok ist). Ich möchte aber immer für jeden Thermostat aber beide Sollwerte anzeigen.
Ich dachte es ist ein Problem der Readingsgroup, irgendwie müsste man doch einen Befehl wie get $DEVICE setpoint 11 auch anzeigen können...soweit jedenfalls meine Überlegung.
Dann würde ich dafür (wie erwähnt) mal mit einem userreadings "rumspielen".
Evtl. 2 (ACHTUNG: beide müssen in das EINE Attribut userreadings! ;) ):
eines pro heating-Status
Ich habe allerdings (leider) noch nicht verstanden wie sich erkennen lässt, welcher Wert nun steht.
Steht der immer im selben Reading?
Und abhängig eines anderen Readings (Modus?) ist dann "erkennbar" wie die angezeigte Temperatur zu verstehen ist!?
Sorry aber ohne das Gerät/Device zu haben ist es schwer nachzuvollziehen ;)
Wenn es "erkennbar" ist, welche Temp wann was ist, dann sollte das mit einem (oder 2) userreadings gehen...
Und dann könntest du eben statt den/dem tatsächlichen Reading eben die beiden "selbst erstellten" anzeigen...
Mehr kann ich dann hier wohl leider nicht helfen...
Gruß, Joachim
oK, danke werde mit den userreadings mal rumprobieren.
@curt Die Sollwerte kann ich ja mit get setpoint 11 bzw. get setpoint 1 abfragen, mir ist nur nicht ganz klar wie ich diese Werte nun weiterverarbeiten kann bzw. z.B. in einer Readingsgroup anzeige. Wie hast Du das gelöst?
Zitat von: omnior am 21 Oktober 2020, 19:03:19
Wie hast Du das gelöst?
Gar nicht - durch Dich bin ich ja erst wieder auf das Problem gestoßen, das taucht ja auch an anderen Stellen auf. Klar hatte ich das mal im Wiki gelesen und auch ausprobiert - und halt wieder vergessen.
Erstmal zu den Fakten, für MadMax-FHEM , aber auch für andere Mitleser - es geht um folgendes Problem:
Es gibt zwei automatische Heizmodi, die stellt man via tmHeating bzw. tmEnergySaveHeating an bzw. um. Beiden kann man einen Sollwert mitgeben, es gibt also zwei Sollwerte.
Jetzt wird es spannend: Die stehen nicht etwa in Readings der Device. Die muss man (wie so vieles bei diesem Thermostaten) aktiv per GET abfragen. Das war das erste Problem. Jetzt kommt das zweite Problem: Beide landen in nur
einem Reading, je nachdem, was zuletzt abgefragt wurde.
Am Beispiel:
get Thermostat_Arbeitszimmer setpoint 1 --> Reading
setpointTemp "23.0 C heating"
get Thermostat_Arbeitszimmer setpoint 11 --> Reading
setpointTemp "18.0 C energySaveHeating"
@krikan kennt den Thermostat am besten, er kann sicher sagen, ob ich das richtig beschrieb oder irgend etwas übersehen habe.
@Beta-User nehme ich rein, weil er an sehr ähnlicher Front über andere Lösungswege nachdenkt. Er sollte auch über dieses Problem in Kenntnis gesetzt sein.
Ich persönlich finde ja, dass es systematisch korrekt wäre, wenn das Modul selbst diese Probleme lösen würde. Aber ich bin nicht der Nabel der Welt. Ich verstand @rudolfkoenig so, dass am fraglichen Modul in derartigen Sachen nichts geändert wird. Die Argumente habe ich (nur) teilweise verstanden, das liegt aber an mir. Ich bin wie gesagt nicht der Nabel der Welt und halte mich auch nicht dafür - ich schreibe das nur, damit wir alle auf gleichem Informationsstand sind.
Danke @omnior für Deine Antworten.
Hmm, ok.
Unschön (hoffentlich gibt es bessere Lösungen) aber dann sollte das mit den userreadings doch gehen!?
Es steht halt im jeweiligen userreadings eben immer der letzte Wert der dazugehörigen Abfrage (also z.B. enthält "energySaveHeating" oder eben enthält "heating" und dann im userreadings eben nur der "ausgefilterte" Temperaturwert / so meine Idee)...
Damit die (beiden) userreadings nat. halbwegs aktuell sind, müssten die get-Aufrufe halt zyklisch passieren (noch weniger schön)...
Allerdings bin ich jetzt mangels Geräten und somit Wissen darüber "raus" ;)
Gruß, Joachim
P.S.: wenn ich mir das so ansehe (in diesem und anderen Threads zu dem Thema) sind die Thermostate (aktuell) für mich kein Ersatz für meine Homematic "Classic"/BidCos (sollten die mal "ausverkauft" sein und dann "kaputt gehen")...
Zitat von: MadMax-FHEM am 22 Oktober 2020, 02:25:53
Unschön (hoffentlich gibt es bessere Lösungen) aber dann sollte das mit den userreadings doch gehen!?
Falscher Ansprechpartner. Ich muss mich da jedesmal durch die Dokus kämpfen und die mürrischen Profis fragen.
Zitat von: MadMax-FHEM am 22 Oktober 2020, 02:25:53
P.S.: wenn ich mir das so ansehe (in diesem und anderen Threads zu dem Thema) sind die Thermostate (aktuell) für mich kein Ersatz
Ich finde die wirklich prima, nichts auszusetzen. Bei 3 von 8 hatte/habe ich selten stochastisch Probleme, die Dinger hängen ab und an und heizen fröhlich weiter. Das mag aber an der Sonderkonstellation bei mir liegen: Mein Ventilhub ist bei gleichzeitig ordentlicher Federspannung nur 2, eher 1,5mm.
Die Probleme liegen auf der Treiberseite, wenn ich mal ein Modul für ein physikalisches Gerät als Treiber ansprechen darf: Da stelle ich mir die entsprechenden Readings vor - wozu gibt es Zeitstempel für Readings? Und ich stelle mir vor, dass der Treiber auf die Besonderheit des Geräts (alles abholen) eingeht und mir Optionen für die Abholfrequenz (von 0 für nie bis usw.) gibt. Ja, geht auf die Batterie - aber so ist das Leben: Ich muss mich immerzu entscheiden, was mir wichtiger ist.
Modulautor ist wohl @rudolfkoenig und er hat im anderen Thread gesagt, dass da nichts geändert wird. Seine von mir nur halb verstandenen Argumente kann und will ich nicht anzweifeln, wer bin ich denn? Anders als bei ganz wenigen anderen Themen kann ich Rudolf in dieser Frage nicht ansatzweise das Wasser reichen.
Zitat von: MadMax-FHEM am 22 Oktober 2020, 02:25:53
für meine Homematic "Classic"/BidCos (sollten die mal "ausverkauft" sein und dann "kaputt gehen")...
Ich habe eins, etwas angestaubt. Das liegt offen in der Ecke, in die ich es pfefferte. Ohne mit Wlan oder wie das bei HomeMatic heißt. Noch ein "altes". Ich schenke es Dir, damit Du im Notfall Ersatz hast: Postanschrift per PN rum und es geht los. Ja, meine ich ernst.
Und im Gegenzug beantwortest Du mir ab und an eine saublöde Frage nach userreadings oder so ... saublöde Fragen kann ich stellen, das ist meine Primärqualifikation. :)
Ok, danke Dir für die nochmalige Präzisierung. Ich bin mit den Thermostaten grundsätzlich auch sehr zufrieden, habe nur mit einem von 10 Stück ab und zu mal ein Problem.
Joachim hat ja vorgeschlagen, userreadings zu verwenden. Damit habe ich gestern abend rumprobiert bin aber noch nicht wirklich schlau ob es funktionieren könnte, einen oder beide der per
get $DEVICE setpoint 11
get $DEVICE setpoint 1
reingeholten Sollwerte irgendwie in die userreadings reinbringen könnte, sowas in der Art wie
attr $DEVICE userreadings SollSpar {fhem(get $DEVICE setpoint 11)}
das ist aber noch irgendwie von der Syntax falsch oder ich scheitere einfach an falschen Hochkommas oder Klammern. :'(
Ich bin ja auch kein userreadings-Experte...
Aber das mit dem get muss "woanders" zyklisch passieren (at oder so)...
userreadings dann "nur" für die "Anzeige"...
Ich probiere später mal rum...
...allerdings halt schwer ohne so ein Ding zu haben... ;)
Gruß, Joachim
Also nochmal und in FETT ;)
Ich bin BEI WEITEM KEIN userReadings-Experte!!! ;)
Ich habe mal mit einem dummy "rumgespielt" (ermangelung des tatsächlichen Devives) wie folgt:
defmod ZWave_THERMOSTAT dummy
attr ZWave_THERMOSTAT room Test
attr ZWave_THERMOSTAT userReadings desTempHeating:setpointTemp.* {my $SetpointTempAct = ReadingsNum($name,"desTempHeating",0);; my $Setpoint = ReadingsVal($name,"setpointTemp","n.a.");; my $SetpointTemp = ReadingsNum($name,"setpointTemp",0);; if($Setpoint =~ m/heating/){return $SetpointTemp}else{return $SetpointTempAct}},desTempSaving:setpointTemp.* {my $SetpointTempAct = ReadingsNum($name,"desTempSaving",0);; my $Setpoint = ReadingsVal($name,"setpointTemp","n.a.");; my $SetpointTemp = ReadingsNum($name,"setpointTemp",0);; if($Setpoint =~ m/energySaveHeating/){return $SetpointTemp}else{return $SetpointTempAct}}
setstate ZWave_THERMOSTAT 2020-10-22 09:33:31 desTempHeating 18.0
setstate ZWave_THERMOSTAT 2020-10-22 09:33:31 desTempSaving 20.0
setstate ZWave_THERMOSTAT 2020-10-22 09:33:31 setpointTemp 20.0 C energySaveHeating
und dann ein at für meinen dummy (da müssten dann bei euch/dir halt die get irgendwas Befehle rein):
defmod atZWave_THERMOSTAT at +*00:10:00 setreading ZWave_THERMOSTAT setpointTemp 18.0 C heating ;; sleep 10;; setreading ZWave_THERMOSTAT setpointTemp 20.0 C energySaveHeating
Das at "holt" quasi alle 10min die beiden Werte (Abstand zwischen den Werten 10s -> sleep).
Bei mir wird halt der dummy mit den hoffentlich richtigen Werten "versorgt"...
Danach steht im Reading desTempHeating der Wert der bei "heating" kommt und in desTempSaving eben der Wert der mit "energySaveHeating" kommt (zumindest so der Plan ;) ).
Wenn der jeweils andere Wert kommt, dann wird der aktuelle einfach noch mal ausgegeben.
Ob da ein leeres return auch ginge, also der jeweils andere Wert dann nicht (auch) aktualisiert wird: keine Ahung...
Aber da das userReadings eh nicht "super optimal" ist ;)
Wird daran sicher auch das noch verbessert...
...sofern diese "Lösung" überhaupt in Frage kommt... ;)
Ob es für das at auch eine andere, bessere Lösung gibt -> keine Ahnung.
EDIT: evtl. kann man noch am Trigger schrauben. Also jeweils schon den Trigger so einschränken, dass man nur noch ReadingsNum($name,"setpointTemp",0) zurückgeben muss. Also statt dem if-Match gleich eine passende RegEx beim Trigger des jeweiligen userReadings... Aber auch für RegEx gilt: bei WEITEM KEIN Experte! Daher diese "nicht so schöne" Lösung... Aber ich wollte ja auch "nur" meine "Idee" rüber bringen ;)
EDIT: naja auch nicht viel schön aber kürzer ;)
attr ZWave_THERMOSTAT userReadings desTempHeating:setpointTemp.*heating {return ReadingsNum($name,"setpointTemp",0)},desTempSaving:setpointTemp.*energySaveHeating {return ReadingsNum($name,"setpointTemp",0)}
Gruß, Joachim
P.S.: achja alles "Raw-Definitions" und für dich/euch nat. nur das userReadings (und ein abgeändertes at) relevant...
Zitat von: MadMax-FHEM am 22 Oktober 2020, 02:25:53
P.S.: wenn ich mir das so ansehe (in diesem und anderen Threads zu dem Thema) sind die Thermostate (aktuell) für mich kein Ersatz für meine Homematic "Classic"/BidCos (sollten die mal "ausverkauft" sein und dann "kaputt gehen")...
Bin mal gespannt, was mein persönliches Fazit am Ende sein wird, wenn mein Spirit denn irgendwann hier eingetroffen und konfiguriert ist...
Zitat von: MadMax-FHEM am 22 Oktober 2020, 08:52:11
Aber das mit dem get muss "woanders" zyklisch passieren (at oder so)...
ABSOLUT!
Mit sowas
Zitat von: omnior am 22 Oktober 2020, 08:21:56
attr $DEVICE userreadings SollSpar {fhem(get $DEVICE setpoint 11)}
baut man sich vermutlich einen - eventuell das komplette ZWave-Funknetz lahmlegenden (!!!) - Zirkel! Das "get" dürfte "asynchron" rausgehen und das Ergebnis triggert dann wieder ein Event an dem Device, worauf dann wieder das userReading "SollSpar" aktualisiert wird - das ist ohne Trigger, also geht das ganze von vorne los...
Daher nochmal für die "Nicht-userReadings"-Experten meine 2ct zu dem Thema:
- NIE userReadings OHNE Trigger definieren (selbst da, wo es eigentlich nicht nötig ist, schadet es in der Regel nicht);
- NIE andere als direkt abfragende Kommandos verwenden (ReadingsVal()&Co sind ok, bei get wird es schnell kritisch...).
Würde mal mit dem hier ins Rennen gehen (war schon fertig, als MadMax-FHEM auch mit seinem Vorschlag kam):
attr DEVICE userreadings energySaveHeating:setpointTemp.+energySaveHeating {ReadingsNum($name,"setpointTemp",0)}, heating:setpointTemp.+heating {ReadingsNum($name,"setpointTemp",0)}
Ansonsten @curt:
Ja, ich lese hier mit, und ich wäre ggf. auch an deinem CUL_HM-Elektroschrott interessiert...
Zitat von: Beta-User am 22 Oktober 2020, 09:54:30
Würde mal mit dem hier ins Rennen gehen (war schon fertig, als MadMax-FHEM auch mit seinem Vorschlag kam):
attr DEVICE userreadings energySaveHeating:setpointTemp.+energySaveHeating {ReadingsNum($name,"setpointTemp",0)}, heating:setpointTemp.+heating {ReadingsNum($name,"setpointTemp",0)}
Mir ist nur nicht klar, wie bzw. durch was hier die beiden Sollwerte (die man ja nur über get setpoint mit Parameter 11 oder 1 abfragen kann reinkommen sollen. In setpointTemp steht ja nur der zuletzt abgefragte Wert drin.
Wenn (über eine anderweitig zu veranlassende (!) Abfrage) Werte reinkommen, wird der dann darin enthaltene Zahlenwert entweder dem einen oder dem anderen Reading (energySaveHeating bzw. heating) zugeschlagen.
Mit der weiteren Frage, wie man ggf. den aktuellen Modus (möglichst ohne get) rausfinden kann, muß ich mich dann mal beschäftigen, wenn die Hardware da ist.
Aber wie gesagt: (Alle) userReadings setzen voraus, dass das Device (optimalerweise: passend) aktualisiert wird, was man ggf. dann irgendwie anders (ein at, z.B.) veranlassen muss, wenn es nicht von alleine zurückkommt (ob man nicht doch "eigentlich" schon mit dem Ack eine Rückmeldung hat, war in dem anderen Thread die Diskussion und wäre ggf. dann m.E. auch dort weiterzuführen).
Zitat
attr DEVICE userreadings energySaveHeating:setpointTemp.+energySaveHeating {ReadingsNum($name,"setpointTemp",0)}, heating:setpointTemp.+heating {ReadingsNum($name,"setpointTemp",0)}
Hä!!?
Das hat mit meinem userReadings ÜBERHAUPT NICHTS zu tun!!!!EDIT: ok so überhupt nichts auch nicht ;) ABER: statt dem Plus doch einen Stern! (also soweit ich das in RegEx verstehe, bin aber [siehe weiter oben] KEIN Spezialist), also dann: sorry! ;)EDIT: und das Leerzeichen nach dem Komma zum Trennen der beiden NEUEN Readingnamen MUSS WEG! (also soweit ich userReadings verstehe [auch hier: KEIN Spezialist ;) ])... Komma-separated vs. Komma-und-Leerzeichen-separated... ;)Warum nimmst du nicht meines!?
(so viel Mühe gegeben ;) )Hier noch mal:EDIT: Raw-Def wieder gelöscht (ist ja "oben" schon)... ;)
EDIT: auch ich finde das at nicht toll aber für den dummy brauchte ich das ja (eh) und bei den Thermostaten habe ich keine Ahnung, ob die Werte auch anders kommen können, drum
Zitat
Aber wie gesagt: (Alle) userReadings setzen voraus, dass das Device (optimalerweise: passend) aktualisiert wird, was man ggf. dann irgendwie anders (ein at, z.B.) veranlassen muss, wenn es nicht von alleine zurückkommt (ob man nicht doch "eigentlich" schon mit dem Ack eine Rückmeldung hat, war in dem anderen Thread die Diskussion und wäre ggf. dann m.E. auch dort weiterzuführen).
Bitte gerne dort weiter...
Bzw. habe ich mehr zu dem Thema eh nicht mehr beizutragen... ;)
(und jetzt wirklich ;) )
Naja:
also wenn du per get die Werte holst (ich mache das für den dummy über das at, gut ich versuche auch noch ein at für deine "Problematik" / ob dazu ein at notwendig ist oder ob das auch anders geht: keine Ahnung), dann wird das Reading setpointTemp doch mit einem Wert versorgt.
EDIT: hier (trotzdem) noch das at (damit werden eben zyklisch die get-Befehle abgesetzt, damit dann das userReadings was zu tun hat ;) und die ANDEREN Readings befüllen kann)
defmod atZWave_THERMOSTAT at +*00:10:00 get ZWave_THERMOSTAT setpoint 11;; sleep 10;; get ZWave_THERMOSTAT setpoint 1
Also entweder steht dann:
setpointTemp 23.0 C heating
-> darauf triggert das "1te" userReadings und setzt dann das "neue" Reading: desTempHeating eben auf 23.0
oder
setpointTemp 18.0 C energySaveHeating
darauf triggert das "2te" userReadings und setzt dann das "neue" Reading: desTempSaving auf 18.0
Mal bei userReadings nachlesen:
attr Device userReadings NeuerReadingName1:Trigger1 {so wird's "berechnet" und hier wird der Wert für NeuerReadingName1 zurückgegeben},NeuerReadingName2:Trigger2 {so wird's "berechnet" und hier wird der Wert für NeuerReadingName2 zurückgegeben}
Gruß, Joachim
Vielleicht habe ich dein userreadings bzw. die dort benutzte if Abfrage noch nicht ganz verstanden...
Zitat von: MadMax-FHEM am 22 Oktober 2020, 11:17:42
Also entweder steht dann:
setpointTemp 23.0 C heating
-> darauf triggert das "1te" userReadings und setzt dann das "neue" Reading: desTempHeating eben auf 23.0
oder
setpointTemp 18.0 C energySaveHeating
darauf triggert das "2te" userReadings und setzt dann das "neue" Reading: desTempSaving auf 18.0
Wieso entweder oder? Es passiert eben beides hintereinander. Es ist ja nicht so, dass in Abhängigkeit des Modus das Ergebnis ein anderes ist, sondern der get setpoint Befehlt schreibt einfach den jeweils abgefragten Sollwert immer in das gleiche setpointTemp Reading rein. Also durch das at wird so wie du es geschrieben hast, erst der heating Sollwert und nach dem sleep der EnergySaveSollwert geschrieben.
Wie gesagt, vielleicht hab ich aber nur dein userreadings Definition nicht ganz verstanden.
attr ZWave_THERMOSTAT userReadings desTempHeating:setpointTemp.* {my $SetpointTempAct = ReadingsNum($name,"desTempHeating",0);; my $Setpoint = ReadingsVal($name,"setpointTemp","n.a.");; my $SetpointTemp = ReadingsNum($name,"setpointTemp",0);; if($Setpoint =~ m/heating/){return $SetpointTemp}else{return $SetpointTempAct}},desTempSaving:setpointTemp.* {my $SetpointTempAct = ReadingsNum($name,"desTempSaving",0);; my $Setpoint = ReadingsVal($name,"setpointTemp","n.a.");; my $SetpointTemp = ReadingsNum($name,"setpointTemp",0);; if($Setpoint =~ m/energySaveHeating/){return $SetpointTemp}else{return $SetpointTempAct}}
Wann wird das userreading denn genau "getriggert"? Zwei mal? Erstes mal nach dem Setzen des heating Sollwerts und dann nach dem Sleep 10 Befehl nochmal?
Nochmal:
1. du musst irgendwie DAS Reading setpointTemp aktualisieren -> get ZWave_THERMOSTAT setpoint 11 bzw. get ZWave_THERMOSTAT setpoint 1
Dafür habe ICH mal das at. Wenn es einen anderen/besseren Weg gibt: juhu! ;)
2. ja bei der "langen" Version des userReadings (mit den if-Abfragen) wird JEDESMAL wenn sich setpointTemp ändert getriggert. Darum ja "intern" das if. Also ob es der eine oder der andere get war bzw. dessen "Ergebnis"... Je nachdem wird eben dann das eine "neue Reading" mit einem AKTUELLEN (den eben "empfangenen") Wert "versorgt" und das andere (für den KEIN neuer Wert gekommen ist, weil die get-Abfrage ja für "das andere" war) eben mit dem bisherigen Wert erneut "gefüllt"... (ist halt unschön/unnötig/doof/... ;) daher ja die 2te/kurze Variante)...
ABER: nimm doch die "kurze" Variante:
attr ZWave_THERMOSTAT userReadings desTempHeating:setpointTemp.*heating {return ReadingsNum($name,"setpointTemp",0)},desTempSaving:setpointTemp.*energySaveHeating {return ReadingsNum($name,"setpointTemp",0)}
Die triggert genau nur je nachdem welcher Wert "ge-getted" wurde... ;)
(sofern das was ich an lists gesehen und du geschrieben hast stimmen)
ABER: "irgendjemand"/"irgendetwas" muss eben (trotzdem) dafür sorgen, dass die Werte "ge-getted" werden (noch mal: bei mir eben das at)...
Gruß, Joachim
So, nachdem mein Spirit hier auch gelandet ist, mal vorab ein list von dem (fast) jungräulichen Ding (war aber gebraucht, kann natürlich sein, dass da jemand schon dran rumgespielt hatte; einen reset (Batterie raus, Knopf drücken, Batterie rein) hatte ich gemacht):
defmod ZWave_THERMOSTAT_20 ZWave 12345678 20attr 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 ZWave
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 associationAdd 1 1
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-23 08:13:49 configTemperatureReportThreshold 5
setstate ZWave_THERMOSTAT_20 2020-10-23 08:13:49 configValveOpeningPercentageReport 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-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-23 08:10:16 state associationAdd 1 1
setstate ZWave_THERMOSTAT_20 2020-10-23 08:13:49 timeToAck 0.130
setstate ZWave_THERMOSTAT_20 2020-10-23 08:13:49 transmit OK
setstate ZWave_THERMOSTAT_20 2020-10-23 08:11:04 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:1200Dann dachte ich, es sei eine gute Idee, mal diese gets auszuführen und das mit den userReadings zu testen etc..
Daher erst mal wieder ein list - nachdem ich (in etwa) folgendes gemacht habe:
- die Solltemperatur am Thermostaten verändert (über die Knöpfe);
- die Batterie entfernt;
- danach nochmal die desired-temp geändert:
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 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)=~(heating|
energySaveHeating)?$1:undef)}
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 desired-temp 24
setstate ZWave_THERMOSTAT_20 2020-10-23 08:25:17 alarm System: hardware
failure with OEM proprietary failure code, arg 102
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-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-23 08:13:49
configTemperatureReportThreshold 5
setstate ZWave_THERMOSTAT_20 2020-10-23 08:13:49
configValveOpeningPercentageReport 0
setstate ZWave_THERMOSTAT_20 2020-10-23 08:18:45 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-23 08:24:14 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-23 08:24:14 setpointTemp 18.0 C heating
setstate ZWave_THERMOSTAT_20 2020-10-23 09:22:19 state desired-temp 24
setstate ZWave_THERMOSTAT_20 2020-10-23 08:23:07 thermostatMode heating
setstate ZWave_THERMOSTAT_20 2020-10-23 08:23:15 timeToAck 1.406
setstate ZWave_THERMOSTAT_20 2020-10-23 09:22:46 transmit NO_ACK
setstate ZWave_THERMOSTAT_20 2020-10-23 08:11:04 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:1200Danach kann ich diesem Vorschlag nicht mehr viel abgewinnen:
Zitat von: MadMax-FHEM am 22 Oktober 2020, 17:20:04
1. du musst irgendwie DAS Reading setpointTemp aktualisieren -> get ZWave_THERMOSTAT setpoint 11 bzw. get ZWave_THERMOSTAT setpoint 1
Dafür habe ICH mal das at. Wenn es einen anderen/besseren Weg gibt: juhu! ;)
Welchen Zweck hat die periodische Abfrage über das get? Mein Verständnis ist das: Das ist eine Einstellung, die man ändern kann (dazu soll die ReadingsGroup dienen, oder? Dann müßte man die entsprechenden configByte-Befehle ausführen, und danach (vielleicht! s.u.) wieder einmalig (!) den get-Befehl absetzen ?), die aber ansonsten unveränderlich sind.
Die eigentliche Temperaturregelung (so man nicht den valve-Modus nutzt) findet darüber statt, dass man entweder zwischen diesen beiden Punkten umschaltet (tm.*-setter) oder eben über die (synonymen) desired-temp/setpointTemp die Solltemperatur vorgibt.
Problematisch scheint nur zu sein, dass es
- keinen wirklich guten Link zwischen den set-Befehlen und den Readings gibt und
- man immer unterstellen muß, dass set-Befehle auch angekommen sind, also die Theorie der "Praxis" entspricht.
MAn. sollte man genau das tun: Annehmen, dass ZWave-Befehle auch angekommen sind. Das Protokoll ist bidirektional, und WENN es Probleme gibt, steht es in "transmit". Kann sein, dass es Ausnahmen gibt, aber deswegen gleich das Kind mit dem Bade auszukippen und das Funkbudget durch völlig unnötige (just my2ct) und - noch schlimmer - ggf. irreführende Abfragen zu belasten, das geht in die völlig falsche Richtung.
Ansonsten werde ich bei Gelegenheit mal versuchen, das mit der Konsistenz der Readings irgendwie hinzubiegen. Rückmeldung erfolgt dann aber eher in dem/den anderen Threads.
Zitat
Danach kann ich diesem Vorschlag nicht mehr viel abgewinnen:
Zitat von: MadMax-FHEM am Gestern um 17:20:04
1. du musst irgendwie DAS Reading setpointTemp aktualisieren -> get ZWave_THERMOSTAT setpoint 11 bzw. get ZWave_THERMOSTAT setpoint 1
Dafür habe ICH mal das at. Wenn es einen anderen/besseren Weg gibt: juhu! ;)
Konnte ich noch nie...
...war aber ja Input des TE, dass das so sein sollte/müsste ;)
Und: ich habe die Dinger ja (noch länger ;) ) nicht...
Viel Erfolg, Joachim
Zitat von: MadMax-FHEM am 23 Oktober 2020, 10:25:54
Konnte ich noch nie...
...war aber ja Input des TE, dass das so sein sollte/müsste ;)
Und: ich habe die Dinger ja (noch länger ;) ) nicht...
Viel Erfolg, Joachim
War nicht persönlich gemeint :) .
Mein erster Eindruck von dem Spirit, falls es dich interessiert:
Der wirkt ganz ok, Laufgeräusche sind eher auf dem Niveau der besseren meiner HM-Teile, Optik finde ich deutlich besser, auch wenn man über die (austauschbare) graue Kappe geteilter Meinung sein kann.
Handling (Inclusion, Reaktion auf Befehle usw.) war völlig unproblematisch. Man muß bei diesen Dingern halt darauf vertrauen, dass FHEM zuverlässig läuft, aber da hätte ich zwischenzeitlich nicht die großen Bedenken. Muß jetzt erst mal einen Adapter suchen, meiner kam ohne daher, aber ich sollte noch den einen oder anderen aus der HM-Welt übrig haben, dann kann das Ding mal in den Probebetrieb gehen (ich wollte eh' die WeekdayTimer/weekprofile-Kombi mal selbst austesten, aber @CUL_HM gab es dafür nicht den großen Bedarf...).
Von daher, _falls du je irgendwann_ Ersatz für CUL_HM suchst: Ein Blick (auch) in die ZWave-Richtung schadet vermutlich nicht ;) .
Mach mal langsamer. Nicht gleich Profile. Du möchtest erst die Fallstricke kennenlernen.
Keine Zeit - heute Abend genauer.
Zitat von: curt am 23 Oktober 2020, 10:45:03
Mach mal langsamer. Nicht gleich Profile. Du möchtest erst die Fallstricke kennenlernen.
Keine Zeit - heute Abend genauer.
Keine Sorge, ich werde schon versuchen, immer einen Fuß auf dem Boden zu behalten...
(Andererseits: Das Ding soll in den Abstell-/und (manchmal) Trockenraum; da fehlt eh' noch ein Temp./Hum-sensor, und in dem Gesamtpackage war neben dem HomeCenter lite auch noch ein Switch. Vielleicht sollte ich den AEOTEC mal umbetten und dann gleich "das volle Testlabor" aus der Abstellkammer machen...? Oder doch lieber einer der noch ungenutzen BT-Teile für "systemübergreifende" externe Sensorik...? (Nein, eins nach dem anderen :P ))
Zitat von: Beta-User am 23 Oktober 2020, 10:41:44
War nicht persönlich gemeint :) .
Mein erster Eindruck von dem Spirit, falls es dich interessiert:
Der wirkt ganz ok, Laufgeräusche sind eher auf dem Niveau der besseren meiner HM-Teile, Optik finde ich deutlich besser, auch wenn man über die (austauschbare) graue Kappe geteilter Meinung sein kann.
Handling (Inclusion, Reaktion auf Befehle usw.) war völlig unproblematisch. Man muß bei diesen Dingern halt darauf vertrauen, dass FHEM zuverlässig läuft, aber da hätte ich zwischenzeitlich nicht die großen Bedenken. Muß jetzt erst mal einen Adapter suchen, meiner kam ohne daher, aber ich sollte noch den einen oder anderen aus der HM-Welt übrig haben, dann kann das Ding mal in den Probebetrieb gehen (ich wollte eh' die WeekdayTimer/weekprofile-Kombi mal selbst austesten, aber @CUL_HM gab es dafür nicht den großen Bedarf...).
Von daher, _falls du je irgendwann_ Ersatz für CUL_HM suchst: Ein Blick (auch) in die ZWave-Richtung schadet vermutlich nicht ;) .
Keine Angst ;) habe ich nicht persönlich genommen 8)
Danke für die Einschätzung!
Ich hatte auf die (als möglichen Ersatz) auch schon ein Auge geworfen...
Daher verfolge ich "das hier" aufmerksam :)
Bin aber froh, dass meine Homematic-Dinger (noch) gut laufen! :)
Gruß, Joachim
Zitat von: MadMax-FHEM am 23 Oktober 2020, 10:25:54
Konnte ich noch nie...
...war aber ja Input des TE, dass das so sein sollte/müsste ;)
Wußte ich gar nicht ;) ...es ging ja eigentlich gar nicht um die Aktualisierung des setpoints, egal ob mit einem AT oder sonstwas, es ging um die Darstellung der beiden nicht direkt gespeicherten unterschiedlichen Sollwerte.
Dies hab ich jetzt halbwegs über die von MadMax-FHEM vorgeschlagene Lösung (danke Joachim) der userreadings realisiert und bin damit vorerst halbwegs zufrieden. Vielleicht gibt es ja irgendwann doch nochmal eine bessere Lösung oder sogar Anpassung des Moduls ;-)
Zitat von: omnior am 23 Oktober 2020, 13:02:28
Wußte ich gar nicht ;) ...es ging ja eigentlich gar nicht um die Aktualisierung des setpoints, egal ob mit einem AT oder sonstwas, es ging um die Darstellung der beiden nicht direkt gespeicherten unterschiedlichen Sollwerte.
Dies hab ich jetzt halbwegs über die von MadMax-FHEM vorgeschlagene Lösung (danke Joachim) der userreadings realisiert und bin damit vorerst halbwegs zufrieden. Vielleicht gibt es ja irgendwann doch nochmal eine bessere Lösung oder sogar Anpassung des Moduls ;-)
Gerne!
Und dann habe ich das wohl "falsch interpretiert" ;)
Heißt aber die Readings zeigen den Stand, der halt "irgendwann" mal bestanden hat ;)
Gruß, Joachim
Zitat von: omnior am 23 Oktober 2020, 13:02:28
Wußte ich gar nicht ;) ...es ging ja eigentlich gar nicht um die Aktualisierung des setpoints, egal ob mit einem AT oder sonstwas, es ging um die Darstellung der beiden nicht direkt gespeicherten unterschiedlichen Sollwerte.
Dies hab ich jetzt halbwegs über die von MadMax-FHEM vorgeschlagene Lösung (danke Joachim) der userreadings realisiert und bin damit vorerst halbwegs zufrieden. Vielleicht gibt es ja irgendwann doch nochmal eine bessere Lösung oder sogar Anpassung des Moduls ;-)
...vielleicht einige Anmerkungen dazu:
- Vermutlich braucht man keine (großen) Anpassungen am Modul. Bestimmte Dinge sind halt wie sie sind, und das ist im Prinzip auch ok, man muß halt wissen, wie man das lesen muß. Mit etwas Glück erarbeiten wir eine Lesehilfe.
- Diese Lesehilfe wird aber eines mit ziemlicher Sicherheit nicht: nochmal irgendwelche neuen Begrifflichkeiten einführen.
Letzteres war u.A. der Grund, warum in meiner Variante (die btw. trotz der Leerzeichen nach dem Kommata funktioniert...) von vornherein vorhandene Textbausteinchen als (neue) Readingnamen verwendet. Kann sein, dass das alles nochmal anders wird, aber mein persönliches Ziel wäre es, am Ende eine konsistente Lösung zu haben, die jeder User ohne größere Klimmzüge direkt in sein System übernehmen kann.
Mal sehen, ob und wie wir dahin kommen.
(Will sagen: verwende besser meinen userReadings-Vorschlag (ggf. auch direkt in der Variante aus meinem 2. list) ;) , das _könnte_ die allgemeine Diskussionsgrundlage werden. Wer sachlich zielführende andere Vorschläge hat, darf mich gerne damit verhauen...)
Am Rande teile ich mit, dass ich unter https://forum.fhem.de/index.php/topic,112955.150.html
im Beitrag #152 meine Konfiguration meiner Thermostate veröffentlichte.
Ich steh grad auf dem Schlauch, weil ich nicht mehr nachvollziehen kann, wie ich die Sollwerte der beiden unterschiedlichen Heizmodi (Heating und Energysaveheating) einstellen kann.
Im Handbuch des Device steht ja explizit, dass über das Gerät nur der Heating (Komfort) Modus verstellt werden kann, die Sollwertverstellung des Energiesparmodus geht nur über Funk.
Eigentlich dachte ich es ging doch über einen set $DEVICE setpoint Befehl und dieser hatte auch zwei Parameter, die Temperatur und den Wert 1 (01) bzw. 11 (0B) für die beiden Heizmodi.
Ich finde diesen Set Befehl aber nicht mehr und kann mit set desired-temp immer nur den Heating Modus verstellen, auch wenn das Gerät selbst im Energysavemodus ist.
Übersehe ich etwas? Wie verstelle ich in fhem den Sollwert des Energiesparmodus? Ist irgendwas am Modul geändert worden?
Niemand dasselbe Problem? Einstellen des Sollwerts für den Energiesparmodus beim Eurotronics Spirit..
Zitat von: omnior am 13 Dezember 2020, 13:25:16
Ich steh grad auf dem Schlauch, weil ich nicht mehr nachvollziehen kann, wie ich die Sollwerte der beiden unterschiedlichen Heizmodi (Heating und Energysaveheating) einstellen kann.
Nur auf die Schnelle:
Das steht irgendwo im Wiki-Artikel. Es gibt eine Kurzversion und eine Langversion des Befehls, in der Langversion kannst Du beide adressieren.
Sorry, bin in Eile.
Zitat von: curt am 16 Dezember 2020, 04:59:12
Nur auf die Schnelle:
Das steht irgendwo im Wiki-Artikel. Es gibt eine Kurzversion und eine Langversion des Befehls, in der Langversion kannst Du beide adressieren.
https://wiki.fhem.de/wiki/Z-Wave-Eurotronic_Spirit_Thermostat#Solltemperaturen (https://wiki.fhem.de/wiki/Z-Wave-Eurotronic_Spirit_Thermostat#Solltemperaturen)
Danke, das hat geholfen. Mein Problem war dass ich immer nur zwei Parameter angegeben habe (also Temperaturwert z.B. 18 und dann die 11 für den Energiesparmodus). Damit funktioniert es nicht und der Befehl übernimmt den Sollwert immer in den Standardmodus.
Notwendig ist noch der dritte Parameter (im Fall von Celsius das C) dann klappt es auch.
also:set $device thermostatSetpointSet 18 C 11