ems-esp MQTT

moustic999 · 01 November 2019, 23:23:52

hello,
I'm trying to use ems-esp (https://github.com/proddy/EMS-ESP) with my fhem. I don't have big knowledge of fhem and certainly not using mqtt.

Could you help me to build something usable ?

here are message published by ems-esp :

Code Auswählen

  Topic:status Payload:online
  Topic:start Payload:start
  Topic:shower_data Payload:{"timer":"0","alert":"0"}
  Topic:boiler_data Payload:{"wWComfort":"Hot","wWSelTemp":60,"wWDesiredTemp":70,"selFlowTemp":51,"selBurnPow":100,"curBurnPow":0,"pumpMod":51,"wWCircPump":0,"outdoorTemp":10.1,"wWCurTmp":54.5,"wWCurFlow":0,"curFlowTemp":45.9,"retTemp":41.1,"switchTemp":0,"sysPress":1.1,"boilTemp":42.4,"wWActivated":"on","wWOnetime":"off","burnGas":"off","flameCurr":0,"heatPmp":"on","fanWork":"off","ignWork":"off","wWCirc":"off","heating_temp":90,"pump_mod_max":100,"pump_mod_min":30,"wWHeat":"off","wWStarts":2647,"wWWorkM":47311,"UBAuptime":2042484,"burnStarts":70463,"burnWorkMin":424195,"heatWorkMin":376884,"ServiceCode":"0Y","ServiceCodeNumber":204}
  Topic:tapwater_active Payload:0
  Topic:heating_active Payload:0
  Topic:thermostat_data Payload:{"hc1":{"seltemp":21,"daytemp":0,"nighttemp":2,"mode":"auto"}}

and the Subscribed ones

Code Auswählen

MQTT subscriptions:
  Topic:home/ems-esp/restart
  Topic:home/ems-esp/start
  Topic:home/ems-esp/thermostat_cmd_temp1
  Topic:home/ems-esp/thermostat_cmd_mode1
  Topic:home/ems-esp/thermostat_cmd_temp2
  Topic:home/ems-esp/thermostat_cmd_mode2
  Topic:home/ems-esp/thermostat_cmd_temp3
  Topic:home/ems-esp/thermostat_cmd_mode3
  Topic:home/ems-esp/thermostat_cmd_temp4
  Topic:home/ems-esp/thermostat_cmd_mode4
  Topic:home/ems-esp/thermostat_cmd
  Topic:home/ems-esp/boiler_cmd
  Topic:home/ems-esp/boiler_cmd_wwactivated
  Topic:home/ems-esp/boiler_cmd_wwonetime
  Topic:home/ems-esp/boiler_cmd_wwtemp
  Topic:home/ems-esp/generic_cmd
  Topic:home/ems-esp/shower_data

I already connected to my mosquitto server using MQTT2_CLIENT and a MQTT2_DEVICE has been autocreated.

Code Auswählen

define ems_esp MQTT2_DEVICE mqttBroker
setuuid ems_esp 5db9b940-f33f-c58d-4499-a29c0fe0d7f1fa7b
attr ems_esp IODev mqttBroker
attr ems_esp readingList mqttBroker:home/ems-esp/boiler_data:.* { json2nameValue($EVENT) }\
mqttBroker:home/ems-esp/heating_active:.* heating_active\
mqttBroker:home/ems-esp/thermostat_data:.* { json2nameValue($EVENT) }\

attr ems_esp room MQTT2_DEVICE
attr ems_esp setList temperature home/ems-esp/thermostat_cmd_temp1 $EVTPART1\
auto home/ems-esp/thermostat_cmd_mode1 auto\
manual home/ems-esp/thermostat_cmd_mode1 manual

as a test I created a small readingsgroup :

Code Auswählen

define Buderus_Heater readingsGroup ems_esp:<%sani_domestic_waterworks>,<Pression>,sysPress ems_esp:<%sani_supply_temp>,<Temp.depart>,curFlowTemp ems_esp:<%sani_return_temp>,<Temp.retour>,retTemp\

and I successfully created another MQTT2_DEVICE to set the mode :

Code Auswählen

define buderus.thermostat MQTT2_DEVICE
setuuid buderus.thermostat 5dbc5776-f33f-c58d-6657-0d77e45cd1e175d6
attr buderus.thermostat IODev mqttBroker
attr buderus.thermostat devStateIcon auto:time_automatic:heat manual:time_manual_mode:auto
attr buderus.thermostat eventMap /auto:auto/heat:manual
attr buderus.thermostat readingList mqttBroker:home/ems-esp/thermostat_data:.* { json2nameValue($EVENT) }
attr buderus.thermostat room Chauffage
attr buderus.thermostat setList auto home/ems-esp/thermostat_cmd_mode1 auto\
heat home/ems-esp/thermostat_cmd_mode1 manual\
temp home/ems-esp/thermostat_cmd_temp1 $EVTPART1
attr buderus.thermostat stateFormat hc1_mode

I can now change the mode, but it takes few seconds to have the state updated. Is there an way to improve that ?

second point, I would like to have a number field where I can set the temperature to send to the heater via the home/ems-esp/thermostat_cmd_temp1.

I made lot of trial, but with no luck.

Finally, I think this could be integrated into few templates for ems-esp depending thermostat type ( mine is a RC300)

TomLee · 01 November 2019, 23:45:10

Zitatsecond point, I would like to have a number field where I can set the temperature to send to the heater via the home/ems-esp/thermostat_cmd_temp1.

I hope I'm not completely wrong

Code Auswählen

attr buderus.thermostat setList temp2:19,20,21,22,23 home/ems-esp/thermostat_cmd_temp1/set $EVTPART1

Beta-User · 03 November 2019, 08:35:24

Thx for sharing your first experience with ems-esp.

Would be fine to add some templates to attrTemplate and support you in finding reasonable settings

. As a first step, I added ems-esp to the general CLIENT template, hope this works as expected (see below).

For testing purpose, it's easier to excange data as "RAW" definitions (see pictures here), so I can build "identical" devices in my test environment (without communication though) and you can keep a working copy with states while testing.

Sounds like this is your first mqtt2-device? As autocreate will use "CID" to determine which of all existing mqtt2-device-devices will "get" any new subscription, your "ems_esp"-Device will also get everything else from your future further MQTT-speaking devices.

So first step should be to assign a differen CID to it:

Code Auswählen

defmod ems_esp MQTT2_DEVICE ems-espAfter tomorrow's update, you might define an additional MQTT2_DEVICE (with CID "mqttBroker" - for all others: use the name of the IO) and assign the template "MQTT2_CLIENT_general_bridge"
This should help to distinguish between different sources and directly build additional devices when needed.
Then we should decide on how many MQTT2-DEVICEs are needed and if additional readingsGroup devices make sense. To get an impression on the possibilities how to visualize a lot of data, see TomLee's thread here: https://forum.fhem.de/index.php/topic,104858.0.html. So until now, I tend to stick with just one device for all (see also webCmdLabel), as also the setting options seem to be quite standardized and not very specific to the hardware used. But I might be wrong in this.

Wrt. to the time difference between set and reaction I'd assume, that's ok (or even a good sign). Afaik it takes some time to write on the bus and also to read reaction, so that way we seem to have a real feedback and not only a "I received it and will _try_ to process the command"...

moustic999 · 03 November 2019, 15:33:32

Thanks for the anwser. I chenged the CID as per your recommendation.

regardig the amount of device, I imagine at least 2 parts, 1 for controlling the Thermostat ( set the mode /get current mode, set the temp, get current target temp) and 1 for reading all values from the heater such as pressure, flow temp, return temp, outdoor temp etc...
not sure we can do that in 1 device.

I read the wiki for RAW, I was not aware of this feature, very interesting.

I removed all readings waited to have them back, so here are them :

Code Auswählen

defmod ems_esp MQTT2_DEVICE ems-esp
attr ems_esp IODev mqttBroker
attr ems_esp readingList mqttBroker:home/ems-esp/boiler_data:.* { json2nameValue($EVENT) }\
mqttBroker:home/ems-esp/tapwater_active:.* tapwater_active\
mqttBroker:home/ems-esp/heating_active:.* heating_active\
mqttBroker:home/ems-esp/shower_data:.* { json2nameValue($EVENT) }\
mqttBroker:home/ems-esp/status:.* status\
mqttBroker:home/ems-esp/start:.* start
attr ems_esp room MQTT2_DEVICE
attr ems_esp setList mode1 home/ems-esp/thermostat_cmd_mode1 $EVTPART1\
temp1 home/ems-esp/thermostat_cmd_temp1 $EVTPART1

setstate ems_esp 2019-11-03 15:31:34 ServiceCode 0Y
setstate ems_esp 2019-11-03 15:31:34 ServiceCodeNumber 204
setstate ems_esp 2019-11-03 15:31:34 UBAuptime 2045583
setstate ems_esp 2019-11-03 15:27:39 alert 0
setstate ems_esp 2019-11-03 15:31:34 boilTemp 33.9
setstate ems_esp 2019-11-03 15:31:34 burnGas off
setstate ems_esp 2019-11-03 15:31:34 burnStarts 70704
setstate ems_esp 2019-11-03 15:31:34 burnWorkMin 424488
setstate ems_esp 2019-11-03 15:31:34 curBurnPow 0
setstate ems_esp 2019-11-03 15:31:34 curFlowTemp 34.2
setstate ems_esp 2019-11-03 15:31:34 fanWork off
setstate ems_esp 2019-11-03 15:31:34 flameCurr 0
setstate ems_esp 2019-11-03 15:31:34 heatPmp on
setstate ems_esp 2019-11-03 15:31:34 heatWorkMin 377088
setstate ems_esp 2019-11-03 15:31:34 heating_active 0
setstate ems_esp 2019-11-03 15:31:34 heating_temp 90
setstate ems_esp 2019-11-03 15:31:34 ignWork off
setstate ems_esp 2019-11-03 15:31:34 outdoorTemp 13.7
setstate ems_esp 2019-11-03 15:31:34 pumpMod 45
setstate ems_esp 2019-11-03 15:31:34 pump_mod_max 100
setstate ems_esp 2019-11-03 15:31:34 pump_mod_min 30
setstate ems_esp 2019-11-03 15:31:34 retTemp 33.4
setstate ems_esp 2019-11-03 15:31:34 selBurnPow 100
setstate ems_esp 2019-11-03 15:31:34 selFlowTemp 40
setstate ems_esp 2019-11-03 15:27:39 start start
setstate ems_esp 2019-11-03 15:27:39 status online
setstate ems_esp 2019-11-03 15:31:34 switchTemp 0
setstate ems_esp 2019-11-03 15:31:34 sysPress 1
setstate ems_esp 2019-11-03 15:31:34 tapwater_active 0
setstate ems_esp 2019-11-03 15:27:39 timer 0
setstate ems_esp 2019-11-03 15:31:34 wWActivated on
setstate ems_esp 2019-11-03 15:31:34 wWCirc off
setstate ems_esp 2019-11-03 15:31:34 wWCircPump 0
setstate ems_esp 2019-11-03 15:31:34 wWComfort Hot
setstate ems_esp 2019-11-03 15:31:34 wWCurFlow 0
setstate ems_esp 2019-11-03 15:31:34 wWCurTmp 57.5
setstate ems_esp 2019-11-03 15:31:34 wWDesiredTemp 70
setstate ems_esp 2019-11-03 15:31:34 wWHeat off
setstate ems_esp 2019-11-03 15:31:34 wWOnetime off
setstate ems_esp 2019-11-03 15:31:34 wWSelTemp 60
setstate ems_esp 2019-11-03 15:31:34 wWStarts 2652
setstate ems_esp 2019-11-03 15:31:34 wWWorkM 47400

maybe it is better to share them via a file ?

Beta-User · 04 November 2019, 11:02:32

OK, sounds reasonable to split things up, especially as the two devices seem to have different functions in the entire system.

So first version for a central heating device (?). It's more intended to make you familiar with variables, widgets and devStateIcon options, it pretty sure contains some suggestions not very reasonable; feel free to replace them as needed and desired:

Code Auswählen


name:ems-esp_heater_device
filter:TYPE=MQTT2_DEVICE
desc:EMS-ESP is a open-source system to communicate with EMS (Energy Management System) based boilers, thermostats and other modules from manufacturers like Bosch, Buderus, Nefit, Junkers and Sieger, see <a href="https://github.com/proddy/EMS-ESP">project page</a>. First version, to contribute see <a href="https://forum.fhem.de/index.php/topic,104968.0.html">Forum Thread</a>.
order:E_02a
par:DEVTYPE;Internal TYPE of the device; { InternalVal("DEVICE","TYPE",undef)}
par:BASE_ID;base topic set, default is "home";{ AttrVal("DEVICE","readingList","") =~ m,[^:]+:?[/]?([^/])+[/][^/]+[/].*:, ? $1 : undef }
par:DEV_ID;ID topic set, default is "ems-esp";{ AttrVal("DEVICE","readingList","") =~ m,[^:]+:?[/]?BASE_ID[/]([^/]+)[/].*:, ? $1 : undef }
par:ICON;ICON as set, defaults to sani_boiler_temp;{ AttrVal("DEVICE","icon","sani_boiler_temp") }
attr DEVICE icon ICON
attr DEVICE  readingList BASE_ID/DEV_ID/boiler_data:.* { json2nameValue($EVENT) }\
  BASE_ID/DEV_ID/tapwater_active:.* tapwater_active\
  BASE_ID/DEV_ID/heating_active:.* heating_active\
  BASE_ID/DEV_ID/shower_data:.* { json2nameValue($EVENT) }\
  BASE_ID/DEV_ID/status:.* status\
  BASE_ID/DEV_ID/start:.* start
attr DEVICE  setList mode1:auto,manual BASE_ID/DEV_ID/thermostat_cmd_mode1 $EVTPART1\
  temp1:selectnumbers,45,0.5,65,1,lin BASE_ID/DEV_ID/thermostat_cmd_temp1 $EVTPART1
attr DEVICE stateFormat Interface: \
status \
Tapwater: \
1:tapwater_active\
Heating: \
2:heating_active\
<br>Uptime: formatedUptime
attr DEVICE devStateIcon online:it_net offline:it_net@red  2.1:lan_rs485 2.0:lan_rs485@red
attr DEVICE autocreate 1
attr DEVICE model ems-esp_heater_device

For testing, you may copy the code to a new file located in the attrTemplate directory (typically: opt/fhem/FHEM/lib/AttrTemplate/), then issue "{ AttrTemplate_Initialize() }" (also after every change to one of the templates), then it should be available in the selection list of every MQTT2_DEVICE.

For the template "language" see this posting (unfortunately in german), for widgets this wiki article should be more or less self-explaining.

In general, sharing the code in code-tags is ok for me.

Looking forward to your feedback

.

moustic999 · 28 November 2019, 11:38:50

hello,

I made little progress on implmenting stuff.

I'm now blocked for this simple device. Maybe you can help

Getting values and settings values are not done via the same, so my slider is not updated with current value as well as my radio is not aligne with current choice.

here is the raw :

Code Auswählen

defmod buderus.heater.thermostat.hc1 MQTT2_DEVICE
attr buderus.heater.thermostat.hc1 IODev mqttBroker
attr buderus.heater.thermostat.hc1 devStateIcon auto:time_automatic:heat manual:time_manual_mode:auto set_auto:time_automatic@yellow set_heat:time_manual_mode@yellow
attr buderus.heater.thermostat.hc1 readingList mqttBroker:home/ems-esp/thermostat_data:.* { json2nameValue($EVENT) }
attr buderus.heater.thermostat.hc1 room Chauffage
attr buderus.heater.thermostat.hc1 setList mode:uzsuSelectRadio,auto,manual home/ems-esp/thermostat_cmd_mode1 $EVTPART1\
temp:slider,15.0,0.5,30.0,1 home/ems-esp/thermostat_cmd_temp1 $EVTPART1
attr buderus.heater.thermostat.hc1 setStateList mode hc1_mode
attr buderus.heater.thermostat.hc1 stateFormat hc1_mode\
hc1_seltemp °C
attr buderus.heater.thermostat.hc1 webCmd mode:temp

setstate buderus.heater.thermostat.hc1 auto\
26 °C
setstate buderus.heater.thermostat.hc1 2019-11-28 11:35:31 hc1_daytemp 0
setstate buderus.heater.thermostat.hc1 2019-11-28 11:35:31 hc1_mode auto
setstate buderus.heater.thermostat.hc1 2019-11-28 11:35:31 hc1_nighttemp 0
setstate buderus.heater.thermostat.hc1 2019-11-28 11:35:31 hc1_seltemp 26
setstate buderus.heater.thermostat.hc1 2019-11-15 16:17:07 mode set manual
setstate buderus.heater.thermostat.hc1 2019-11-15 16:19:04 state set_mode
setstate buderus.heater.thermostat.hc1 2019-11-28 11:35:27 temp set 26.0

also when changing mode /temp, there is a delay until we receive values from heater, during that time mode icon is yellow, I would like to have same for the temp, but I don't know how to change text color.

Beta-User · 28 November 2019, 12:23:33

To get "the circle closed" you have tu use the same reading names in sending and receiving direction.
Atm this e.g. seems to be "mode" when sending from FHEM, but "hc1_mode" when receiving.

There are two ways to solve that kind of trouble:
- "easy way" is to name the setters the same as the return values are named in the JSON. This would lead to:

Code Auswählen

attr buderus.heater.thermostat.hc1 setList hc1_mode:uzsuSelectRadio,auto,manual home/ems-esp/thermostat_cmd_mode1 $EVTPART1\
temp1:slider,15.0,0.5,30.0,1 home/ems-esp/thermostat_cmd_temp1 $EVTPART1

- second option is to do the renaming when receiving:

Code Auswählen

attr buderus.heater.thermostat.hc1 readingList mqttBroker:home/ems-esp/thermostat_data:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr buderus.heater.thermostat.hc1 jsonMap hc1_mode:mode temp1:temp

Imo, the second option should be prefered in this case, as I assume, there _could_ exist more than one thermostat on the bus, as renaming of the other readings is more open to the user and confusion could be more easy avoided. You may even use a combination of both methods (e.g. setter and jsonMap entry for "desiredTemperature"). This would lead to the following "side-effect": The device would be automatically recognized by WeekdayTimer (maybe others also) as a heating device. I'm currently working with @Risiko to get WeekdayTimer to accept temperature profiles from (Module) "weekprofile" side. So most likely in some few day, it's finally a piece of cake to synchronize e.g. temparature profiles all over the place without hassling about what TYPE they are, including HomeMatic (-IP), MAX or ZWave thermostats...

Wrt. colouring of "not yet confirmed" set actions, this would be possible when using the Perl variant of devStateIcon. Would showing a different icon (instead of text) when things are to be processed would also be an option? Then I'd suggest to show the "edit_settings"-icon, when "^set.*°C$".

moustic999 · 28 November 2019, 17:30:38

I tried the second option with Jsonmap but it does not work. I think it is due to the json data itself :

here is the raw content for thermostat_data topic :

Code Auswählen

{"hc1":{"seltemp":24,"daytemp":0,"nighttemp":0,"mode":"auto"}}

there is no direct hc1_mode neither hc1_seltemp, this is genereated by json2nameValue I guess.

Beta-User · 28 November 2019, 17:47:40

OK, the reading to be mapped is called "hc1_seltemp".
Pls. try to use jsonMap with that instead of temp1 (first started with the mode thing, didn't thoroughly check the latter).

moustic999 · 29 November 2019, 08:56:15

I used the right reading, but jsonmap is not applied whatever I try

here is the raw :

Code Auswählen

defmod buderus.heater.thermostat.hc1 MQTT2_DEVICE
attr buderus.heater.thermostat.hc1 IODev mqttBroker
attr buderus.heater.thermostat.hc1 devStateIcon auto:time_automatic:heat manual:time_manual_mode:auto set_auto:time_automatic@yellow set_heat:time_manual_mode@yellow
attr buderus.heater.thermostat.hc1 jsonMap hc1_seltemp temp
attr buderus.heater.thermostat.hc1 readingList mqttBroker:home/ems-esp/thermostat_data:.* { json2nameValue($EVENT, '', $JSONMAP) }
attr buderus.heater.thermostat.hc1 room Chauffage
attr buderus.heater.thermostat.hc1 setList mode:uzsuSelectRadio,auto,manual home/ems-esp/thermostat_cmd_mode1 $EVTPART1\
temp:slider,15.0,0.5,30.0,1 home/ems-esp/thermostat_cmd_temp1 $EVTPART1
attr buderus.heater.thermostat.hc1 setStateList mode hc1_mode
attr buderus.heater.thermostat.hc1 stateFormat hc1_mode\
hc1_seltemp °C
attr buderus.heater.thermostat.hc1 webCmd mode:temp

setstate buderus.heater.thermostat.hc1 auto\
24 °C
setstate buderus.heater.thermostat.hc1 2019-11-29 08:50:01 hc1_daytemp 0
setstate buderus.heater.thermostat.hc1 2019-11-29 08:50:01 hc1_mode auto
setstate buderus.heater.thermostat.hc1 2019-11-29 08:50:01 hc1_nighttemp 0
setstate buderus.heater.thermostat.hc1 2019-11-29 08:50:01 hc1_seltemp 24
setstate buderus.heater.thermostat.hc1 2019-11-15 16:17:07 mode set manual
setstate buderus.heater.thermostat.hc1 2019-11-15 16:19:04 state set_mode
setstate buderus.heater.thermostat.hc1 2019-11-28 11:35:27 temp set 26.0

and the topic data which is in topic home/ems-esp/thermostat_data

Code Auswählen

{"hc1":{"seltemp":24,"daytemp":0,"nighttemp":0,"mode":"auto"}}

If I understand you work on WeekdayTimer, having the reading named "desiredTemperature" would be enough to support it ? Will it be working for KNX as well ? that would be wonderful !

Beta-User · 29 November 2019, 09:18:50

wrt. to jsonMap, your syntax should be: "oldreadingname1:newreadingname1 oldreadingname2:newreadingname2".

So pls. try again with:

Code Auswählen

attr buderus.heater.thermostat.hc1 jsonMap hc1_mode:mode hc1_seltemp:temp

Wrt. to WeekdayTimer, there are several keywords indicating a device to be a "heater/thremostat type". "desiredTemp" is just one of them. In general it shouldn't be a big issue. If there's a risk to mess up with other devices (meaning: setter-reading isn't named in a way to avoid confusion with "normal" temperature readings), you could use an attribute "switchInThePast" to get a similar behaviour.
You could post a list/RAW definition of you device, but discussion on that thing shouldn't take too much room in this thread.

moustic999 · 29 November 2019, 10:11:29

I already fixed the jsomap syntax but not helped

I let the broker to create again a new device via autocreate "complex" and at that time it works

here is the raw

Code Auswählen

defmod MQTT2_mqttBroker MQTT2_DEVICE ems-esp
attr MQTT2_mqttBroker IODev mqttBroker
attr MQTT2_mqttBroker devStateIcon auto:time_automatic:heat manual:time_manual_mode:auto
attr MQTT2_mqttBroker jsonMap hc1_mode:mode1 hc1_seltemp:temp1
attr MQTT2_mqttBroker readingList mqttBroker:home/ems-esp/thermostat_data:.* { json2nameValue($EVENT, '', $JSONMAP) }\

attr MQTT2_mqttBroker room MQTT2_DEVICE
attr MQTT2_mqttBroker setList mode1:uzsuSelectRadio,auto,manual home/ems-esp/thermostat_cmd_mode1 $EVTPART1\
temp1:slider,15.0,0.5,30.0,1 home/ems-esp/thermostat_cmd_temp1 $EVTPART1
attr MQTT2_mqttBroker stateFormat mode1\
temp1 °C
attr MQTT2_mqttBroker webCmd mode1:temp1

setstate MQTT2_mqttBroker manual\
24 °C
setstate MQTT2_mqttBroker 2019-11-29 10:05:57 hc1_daytemp 0
setstate MQTT2_mqttBroker 2019-11-29 10:05:57 hc1_nighttemp 0
setstate MQTT2_mqttBroker 2019-11-29 10:05:57 mode1 manual
setstate MQTT2_mqttBroker 2019-11-29 10:05:57 temp1 24

What I have found is that if I try to rename it to whatever, jsonmap does not work anymore. I don't understand why.

I tried :

Code Auswählen

rename MQTT2_mqttBroker buderus.thermostat

reverting to original name make it work again.

Beta-User · 29 November 2019, 10:21:54

Thx for the feedback, I already was a little worrying if I had some misunderstanding of the jsonMap feature...

Wrt. the renaming: I assume this either has to do with the name (points are special in a Perl environment), or there's a problem when updating the info at runtime.

Can you please make a short test and
1. rename the device, but avoid points in the naming; (if that leads to problems: still existent after save+FHEM-restart?)
2. rename e.g. temp1 to desiredTemp (esp. in jsonMap attribute).

I'd assume the first will again to cause the problem, even after restart (we'll have to inform Rudi then), but the latter to work without trouble.

moustic999 · 29 November 2019, 10:39:20

you were right. the dot in the name give the issue.

I renamed to 'thermostat' and it is fine. I also updated to desiredTemp with no issue.

except for "pending changes" not shown properly in the state ( yellow ... ) I'm pretty satisfied with current stuff. I will try to put this in the template.

Beta-User · 29 November 2019, 10:57:57

Now you could make a test, if WDT correctly identifies your device as heating: Just use a profile with a switchtime for today that already has passed, e.g.:

Code Auswählen

defmod Buderus_Timer WeekdayTimer thermostat !$we|06:45|22.5 $we|08:00|22.5 $we|10:30|22.0 56|23:00|18.0 56|23:30|18.0 0-4|22:00|18.5

For direct use with weekplan, see this thread https://forum.fhem.de/index.php/topic,105521.0.html for the test variants of the modules (you may ask for help in English in case you need some translation; feedback about the commandref would be fine also...).