Timer processing in RC310

[proddy]

Discussed in #1593

^{Originally posted by Nxtway January 30, 2024}
ems-esp supports timer processing of the RC35, #979
Could these functionality also implemented for the RC310, please ?

The type-id's in RC310 are:
circulation timer: thermostat(0x10) type(0x0309) | ON - FF | OFF - 00
warm water timer: thermostat(0x10) type(0x02FF) | COMFORT - 02 | ECO - 01 | OFF - ??, maybe 00
heating timer 1: thermostat(0x10) type(0x0683)
heating timer 2 thermostat(0x10) type(0x068D)

Log files attached:
WW_timer.txt
circulation_timer.txt
heating_timer1.txt
heating_timer2.txt

An additional improvement might be the holiday timer, but I didn't find the type-id up to now.

[MichaelDvP]

Oh, the heating timer for RC300 are 0x1C3-ff, and 0x349-ff. with mode instead of temperature setting. We have to split RC300 - RC310 - BC400. But product-id 158 includes RC300 and RC310, maybe second identifier (unknown).

But as mentioned in the lot of discussions before, i don't know how we get that much data in ram and mqtt.
Each program has 42 entries with Day-of-week, time and mode/temperature for progA, progB, DHW, circulation:
504 entities to display, holiday modes are in similar range.
For RC35 we use only a single switchpoint to show/edit with a command to change the index, but this way was always not accepted by the users.

[Nxtway]

but this way was always not accepted by the users.

yes, I can understand that argument.
Does it still make sense to raise the RC310 to the same level as the RC35 or leave it as it is?

[MichaelDvP]

For the holiday modes check #275. Same problem with a lot of entities.

The RC35 is dfferent, it's also 42 entries, but each has day, time, mode stored, We can set all 42 to monday, or 1.entry to Tu, second to monday, 3rd not set, 4th to mo, etc. The RC3x0 have groups with 6 entries for mo, 6 for tu, etc. To index them makes no sense, or count 0-5 for each day. Don't know how to manage.

Im thinking of store the raw telegram and generate a program json on api command (and maybe as own mqtt topic). We need to modify the api to forward the json to command. For web page this also can not be an entity in the thermostat section, it need a own editor page.
I'm asking the question if it is usefill to change the program via ems-esp? I've never changed the program online. Sometimes i use the "pause" function if nobdy is at home for the whole day, but never touched the program.

[Nxtway]

I agree. It's would be nice to display the timer entries in ems-esp but changing them is not the use-case.

With a JavaScript function in node-red:

The RC310 timers could be display in a node-red dashboard:

The timers can enabled or disabled with the wwmode, wwcircmode, etc. .
You can postpone this feature request

[Nxtway]

And here are the addresses of the vacation timers in the RC310:

vacation1:
000+04:41:20.516 T 386: [emsesp] Me(0x0B) -R-> thermostat(0x10), ?(0x0269), length: 0x19
000+04:41:20.580 N 388: [emsesp] thermostat(0x10) -W-> Me(0x0B), ?(0x0269), data: 18 03 08 18 03 0E 02 11 02 FF 00 00 00 00 00 00 00 FF 00
data 0..2, start: 2024.03.08 ---> 18 03 08
data 3..5, end : 2014.03.14 ---> 18 03 0E
data 6, heating mode: 0x01=as Saturday; 0x02=const temp; 0x03= off; 0x04=reduce
data 7, heating temp: 0x11 = 17°C
data 8, hot water: 0x01=as Saturday; 0x02=off: 0x03=off with disinfect
data 9, used for heating: FF=YES | 00=NO
data 17,used for hotwater: FF=YES | 00=NO

with a few lines of JS code in node-red it looks like:

[proddy]

what shall we do here @MichaelDvP ?

[proddy]

I don't have these features on my thermostat so not sure how to proceed. I'll remove this issue from the backlog.

[tp1de]

I am using a Buderus gas boiler with RC310 thermostat and 2 heating circuits I can decode 4 switchTimes per hc.
Each hc has 2 switchPrograms A and B and 2 variants with level and temps. Dhw has another 2 switchPrograms.
So in total I have 10 with 2 hc's. (Would be up to 18 with 4 hc's)

For dhw there are 2 switchPrograms:
01FF for warm water buffer load and 0209 for circulation pump - switch between off, eco, hot, on and on, off

The heating circuits can be set to use levels (eco/comfort) or absolute temps per switchTime.
These are different telegram types the to be used. (see below all types are raw)

The switch is done by the entity hcx/switchprogmode for each heating circuit between levels and absolute (temps).
These entities have been build-in just recently.

switchProgram A: hc1 telegrams level/temps are: 01C3 / 0583 and hc2: 01C4 / 0584
switchProgram B: hc1 telegrams level/temps are: 0349 / 058D and hc2: 034A / 058E

Within #1934 long custom entities in raw are now realized and could be used to maintain the long 84 bytes telegrams.
Open questions is where to deconstruct these telegrams and which home automation systems should be supported.

Since quite some time I implemented this in my ioBroker adapter in read/write mode creating the same JSON-objects as the original km200 gateway does. But I needed to implement the right timing for getting the long telegrams and writing them back.
It is much better to do this in the EMS-ESP gateway.

[tp1de]

Each switchProgram has 6 switchTimes per day, 42 switchTimes per week combined with 42 values.
My 10 switchPrograms would create up to 420 mqtt entities if 1:1 implemented and enabled. (2 hc's and dhw with circ. pump)

[MichaelDvP]

@tp1de Please use the ems-esp notation for telegram-types. e.g. 0x2FF for dhw1. Thanks.

Can you confirm the value order:
first byte state, second byte time in 15min steps. --- time 0xFF stands for not_set? (i'm not sure)
first 6 pairs for monday, next 6 for tuesday, etc. (or other day order?) -- are the 6 pairs in row or can only first and last pair be set?
state is for:
dhw1, type 0x2FF, 0x01 for low, 0x02 for high --- other states, eg. 0 for off?
circulation dhw1, type 0x309, 0xFF for on, 0x00 for off
switchtime1 hc1 type 0x2C3, 0x03 for eco, --- ? for comfort -- are there other values?
switchtime2 hc1 type 0x683, temperature in 0,5°C steps -- is there min/max?

switchtime 1/2 is selected by program, 0x2B9, offset 11
mode/temperature telegrams (2C3/683) is selected by switchprogmode, offset 19

We can read the whole telegram in ram and generate a json on API command.
For RC35 i have done this a while ago to test. The byte order is different, RC35 have 42 switchtimes and each have also coded the day of week, there is no order in the settings, eg. offset 0/1 can be Fr evening, offset 6/7 mon morning, and 2-5 not set.
Here is the output for ems-esp.local/api/thermostat/hc2/switchtime
RC35_timer.txt

for RC300 i think the json should look

"value":{
  "mo":{
    "01:{
      "time":"07:00","mode":"comfort"
    },
    "02": {
       ...
    }
  },
  "tu":{
  }
}

For commands we can use the same json structure ans json object in value field.
Maybe only a single switchpoint per command, or more, to be discussed if additive or overwriting. to not set values.

But i have no idea

• how we can publish it to mqtt
• what HA needs to interprete this
• how to display in webUI

We need a complete concept before starting to code.

[tp1de]

Please use the ems-esp notation for telegram-types. e.g. 0x2FF for dhw1. Thanks.

EMS+ and EMS2.0 switchPrograms (For me RC310 and Moduline 2050)

1st step is to select the right telegram type defined by reading the new entities switchprogmodes.
If switchprogmode does not exist then use levels for hc.

hc1 - Mode A level 02C3 and absolute temps 0683 (A == program(1))
hc1 - Mode B level 0449 and absolute temps 068D (B == program(2))

hc2 - Mode A level 02C4 and absolute temps 0684 (A == program(1))
hc2 - Mode B level 044A and absolute temps 068E (B == program(2))

dhw1 - Mode A 02FF
dhw1 - cp (circulation pump) 0309

Each telegram has a length of 84 bytes:
per day there is a maximum of 6 switch points. Each switchpoint is represented by 2 bytes. Therefore each day is 12 bytes:
Mo offset 0 0x00
Tu offset 12 0x0C
We offset 24 0x18
Th offset 36 0x24
Fr offset 48 0x30
Sa offset 60 0x3C
Su offset 72 0x48

Telegram structure of one day looks like this with 2 active switchpoints:
P1 P2 P3 P4 P5 P6 ...........................P12
14 01 58 03 FF 03 FF 03 FF 03 FF 03

P1: time of 1st sp: unit 15 minutes --> 0x14 = 20 *15 = 300 minutes = 05:00 hours
FF: no active switchpoint

P2 are either levels or absolute temps depending on type. Valid for hc and dhw:

Levels: "FF": "on" / "03": "comfort" / "02": "high" / "01": "eco/low" / "00": "off"
temps: Number("0x" + hex) / 2

[tp1de]

km200 API JSON uses time in minutes:
[
{
"dayOfWeek": "Mo",
"setpoint": "high",
"time": 330
},
{
"dayOfWeek": "Mo",
"setpoint": "low",
"time": 600
},
{
"dayOfWeek": "Mo",
"setpoint": "high",
"time": 1050
},
..........
]

[tp1de]

Within ioBroker I write times:
[
{
"dayOfWeek": "Mo",
"setpoint": "high",
"time": "5:30"
},
{
"dayOfWeek": "Mo",
"setpoint": "eco/low",
"time": "10:00"
},
{
"dayOfWeek": "Mo",
"setpoint": "high",
"time": "17:30"
},
.......

[tp1de]

I think we do not need the index 01, 02 etc ... in JSON

Important: Any change in switchprogmode will require to re-read different telegram type for hc switchprogram.

[tp1de]

The API version with JSON will deliver the similar data object compared to the original Bosch API.
Using MQTT for HA I can not identify the right object yet.

At the end JSON structure is not nice to manipulate - neither in ioBroker nor in HA.
I am reading the km200 data with node-red as well and create the entities by using mqtt discovery.
This works nice and it would be possible to create single entities for all switchpoints. while reading the JSON.
Today the switchPrograms are just read-only sensors with JSON-content (text).

[MichaelDvP]

Telegram structure of one day looks like this with 2 active switchpoints:
P1 P2 P3 P4 P5 P6 ...........................P12
14 01 58 03 FF 03 FF 03 FF 03 FF 03

Ah, ok, first time, second mode. (RC35 have reverse order).
My question is: is this ordered? Or is it possible to have two setpoints this way (second and last set, others unset, last is before second):
FF 03 58 03 FF 03 FF 03 FF 03 14 01

I think we do not need the index 01, 02 etc ... in JSON

If it is not ordered and we want to skip all unset points, we need the number to edit/delete a position. Or we always have to publish/write all unset values.

Levels: "FF": "on" / "03": "comfort" / "02": "high" / "01": "eco/low" / "00": "off"

Does this affect all? Is it really possible to set a cirulation pump to "comfort", or heatingscircuit to "on"?
Or (what i think is more logical) does it depend on telegram: hc: comfort/eco, dhw: high/low, circulation on/off?

temps: Number("0x" + hex) / 2

Again: is there a limit? Is it possible to set temp to 3 (1.5°C) or 0xFF (127,5°C)? Or can we use the number to show mode for FF, 3, 2, 1, 0 and temp for all other values.

[tp1de]

Ah, ok, first time, second mode. (RC35 have reverse order).
My question is: is this ordered? Or is it possible to have two setpoints this way (second and last set, others unset, last is before second):

I have never seen non-ordered telegrams. An index is not necessary and is not used within original Bosch API
All unset values use "0xFF" for time and in my case "03" for value. (hc's with level). Temp values can be between 5 (off) and 30.

If it is not ordered and we want to skip all unset points, we need the number to edit/delete a position. Or we always have to publish/write all unset values.

I do always publish a full day if changed (12 bytes including unset points) - So max 7 telegrams
But writing just 2 switchPoints (4) bytes should work as well. (if there has been 2 before)

Levels: "FF": "on" / "03": "comfort" / "02": "high" / "01": "eco/low" / "00": "off
Does this affect all? Is it really possible to set a cirulation pump to "comfort", or heatingscircuit to "on"?
Or (what i think is more logical) does it depend on telegram: hc: comfort/eco, dhw: high/low, circulation on/off?

Decoding for reading telegram is as defined. But possible enum values for writing are:
hc level: "eco/low", and "comfort" (for my gas boiler - we might need to check heatpumps maybe "off" as well")
dhw (buffer): "off", "eco/low" and "high"
dhw cp: "off" and "on"

Again: is there a limit? Is it possible to set temp to 3 (1.5°C) or 0xFF (127,5°C)? Or can we use the number to show mode for FF, 3, 2, 1, 0 and temp for all other values.

Minimum temp is 5°C (off) and maximum is 30°C - the same for manual hc values. Only used for absolute temp telegrams.
Absolute temp telegram have a separate type and can be identified easily depending on value of switchprogmode.

[MichaelDvP]

The switchtimes do not deliver any values / results yet.

Upps, added the missing register/fetch for the telegrams in 3.7.0-test32

[tp1de]

@proddy @MichaelDvP

I implemented a prototype to manage EMS2.0 and EMS+ switchPrograms within Home Assistant using the HACS Scheduler compoment and Node-Red. This solution uses raw hex telegrams send / read by MQTT. It works fine, but was quite tricky for my RC310 thermostat.

I wrote a document about my findings during this process and some analysis I have done on my original Bosch / Buderus gateway.
I made a proposal what needs to be done within EMS-ESP to support these entities in a better way.
Please have a look. I hope that I have been clear enough ....

EMS switchPrograms.pdf

[MichaelDvP]

I've updated the test build https://github.com/MichaelDvP/EMS-ESP32/releases/tag/test
this should give a json structure for

• api/thermostat/hc1/switchtime1
• api/thermostat/hc1/switchtime2
• api/thermostat/dhw/switchtime
• api/thermostat/dhw/circswitchtime

the switchtime1/2 depends on setting of hc1/switchprogmode.

I have not tested writing yet, the implementation is to send a single time in one command as json: "value":{"day":"mo","time":"06:15","mode":"comfort","id":0}. Writing a complete program needs 42 commands, but editing is much easier.

Also mqtt is not implemented. I think of an extra topic thermostat_swichtimes as nested or thermostat_switchtime1_hc1, thermostat_circswitchtime_dhw, etc as not nested.

[tp1de]

I installed your testbuild. 1st test (read) is ok.
I would just recomment to keep the modes in English - today the are translated. This makes any logic flow to integrate in UI components (e.g. HASS scheduler) language dependend.

Writing should be per day with up to 6 switchTimes. How do you indicate otherwise deleted switchTimes?

... and may I repeat my recommandation to name the entities switchprograms. The switchtimes are the times to switch within...

[MichaelDvP]

I would just recomment to keep the modes in English

Ok

Writing should be per day with up to 6 switchTimes.

Does not work with RC20, RC30 and RC35 where day is coded and can be anywhere in the 42 data, Then i have to write all 42 at once.

How do you indicate otherwise deleted switchTimes?

Reading: values are ignored, writing with {"mode":"not_set",...}

.. and may I repeat my recommandation to name the entities switchprograms. T

We have translated word switchtimes, so i take this. Renaming and translating is a lot of work. If we have a complete concept and stick to it, we can rename. For now i dont make all the translations.

I've updated, setting should work now.

[tp1de]

I still get some errors, but much less than before.
Is it a timing issue between the telegrams?

[MichaelDvP]

Please add a log, are the broadcast responses from thermostat now on the same offset as sended?
Maybe we need split to single days, e.g. 12 bytes by telegram?

Is it a timing issue between the telegrams?

I don't think so, Emsesp sends only when the master polls, there is no other timing possible.

[tp1de]

Could you please check your code another time. The telegrams do not look right for me:

9/8/2024, 12:44:26 PM | 0B 10 FF 42 01 C3 01 FF 01 FF 01 FF 03 16 01 58 01 FF 01 FF 01 FF 01 FF 3B
9/8/2024, 12:44:26 PM | 10 00 FF 3C 01 C3 03 16 01 58 01 FF 01 FF 01 FF 01 FF 4F
9/8/2024, 12:44:26 PM | 10 00 FF 24 01 C3 03 17 01 56 01 FF 01 FF 01 FF 01 FF 03 17 01 56 01 FF 01 FF 01 FF 01 FF 12
9/8/2024, 12:44:25 PM | 10 00 FF 18 01 C3 03 17 01 56 01 FF 01 FF 01 FF 01 FF 03 17 01 56 01 FF 01 FF 01 FF 01 FF 59
9/8/2024, 12:44:25 PM | 0B 10 FF 2C 01 C3 01 FF 01 FF 03 17 01 56 01 FF 01 FF 01 FF 01 FF 03 16 01 58 01 FF 75
9/8/2024, 12:44:24 PM | 10 00 FF 00 01 C3 03 17 01 56 01 FF 01 FF 01 FF 01 FF 03 17 01 56 01 FF 01 FF 01 FF 01 FF 77
9/8/2024, 12:44:24 PM | 0B 10 FF 16 01 C3 01 FF 03 17 01 56 01 FF 01 FF 01 FF 01 FF 03 17 01 56 01 FF 01 FF A4
9/8/2024, 12:44:23 PM | 0B 10 FF 00 01 C3 03 17 01 56 01 FF 01 FF 01 FF 01 FF 03 17 01 56 01 FF 01 FF 01 FF 41

I tested with sending raw telegrams - each telegram 2 days = 24 bytes of data. Send by mqtt.
Without any wait time inbetween I get the same errors: [emsesp] Last Tx write rejected by host
Wait time between commands > 500msec is ok and without errors.

EDIT: Wait time between commands > 500msec is not ok anymore. Sometimes yes - but otherwise not.

[MichaelDvP]

I think you have picked a intermediate buggy version that was only a few minutes online. Murphys law.

[tp1de]

These are the telegrams when I send raw using your last version:

9/8/2024, 7:13:35 PM | 10 00 FF 3C 01 C3 03 16 01 56 01 FF 01 FF 01 FF 01 FF 03 16 01 56 01 FF 01 FF 01 FF 01 FF 87
9/8/2024, 7:13:35 PM | 10 0B FF 3C 01 C3 03 16 01 56 01 FF 01 FF 01 FF 01 FF 03 16 01 56 01 FF 01 FF 01 FF 01 FF F8
9/8/2024, 7:13:35 PM | 10 00 FF 30 01 C3 03 16 01 56 01 FF 01 FF 01 FF 01 FF 39
9/8/2024, 7:13:35 PM | 0B 10 FF 3C 01 C3 03 16 01 56 01 FF 01 FF 01 FF 01 FF 03 16 01 56 01 FF 01 FF 01 FF 01 FF 10
9/8/2024, 7:13:34 PM | 10 0B FF 30 01 C3 03 16 01 56 01 FF 01 FF 01 FF 01 FF 23
9/8/2024, 7:13:34 PM | 10 00 FF 18 01 C3 03 16 01 56 01 FF 01 FF 01 FF 01 FF 03 16 01 56 01 FF 01 FF 01 FF 01 FF E2
9/8/2024, 7:13:34 PM | 0B 10 FF 30 01 C3 03 16 01 56 01 FF 01 FF 01 FF 01 FF 13
9/8/2024, 7:13:32 PM | 10 0B FF 18 01 C3 03 16 01 56 01 FF 01 FF 01 FF 01 FF 03 16 01 56 01 FF 01 FF 01 FF 01 FF 9D
9/8/2024, 7:13:32 PM | 0B 10 FF 18 01 C3 03 16 01 56 01 FF 01 FF 01 FF 01 FF 03 16 01 56 01 FF 01 FF 01 FF 01 FF 75
9/8/2024, 7:13:31 PM | 10 00 FF 00 01 C3 03 16 01 56 01 FF 01 FF 01 FF 01 FF 03 16 01 56 01 FF 01 FF 01 FF 01 FF CC
9/8/2024, 7:13:31 PM | 10 0B FF 00 01 C3 03 16 01 56 01 FF 01 FF 01 FF 01 FF 03 16 01 56 01 FF 01 FF 01 FF 01 FF B3
9/8/2024, 7:13:31 PM | 0B 10 FF 00 01 C3 03 16 01 56 01 FF 01 FF 01 FF 01 FF 03 16 01 56 01 FF 01 FF 01 FF 01 FF 5B

and these are the telgrams when I send to json:

9/8/2024, 7:20:35 PM | 10 00 FF 3C 01 C3 03 16 01 56 01 FF 01 FF 01 FF 01 FF 03 16 01 56 01 FF 01 FF 01 FF 01 FF 87
9/8/2024, 7:20:34 PM | 10 00 FF 3C 01 C3 03 16 01 56 01 FF 01 FF 01 FF 01 FF D1
9/8/2024, 7:20:34 PM | 10 00 FF 24 01 C3 03 16 01 56 01 FF 01 FF 01 FF 01 FF 03 16 01 56 01 FF 01 FF 01 FF 01 FF A9
9/8/2024, 7:20:34 PM | 0B 10 FF 42 01 C3 01 FF 01 FF 01 FF 03 16 01 56 01 FF 01 FF 01 FF 01 FF A5
9/8/2024, 7:20:33 PM | 0B 10 FF 2C 01 C3 01 FF 01 FF 03 16 01 56 01 FF 01 FF 01 FF 01 FF 03 16 01 56 01 FF 15
9/8/2024, 7:20:33 PM | 10 00 FF 24 01 C3 03 16 01 56 01 FF 01 FF 01 FF 01 FF 18
9/8/2024, 7:20:33 PM | 10 00 FF 0C 01 C3 03 16 01 56 01 FF 01 FF 01 FF 01 FF 03 16 01 56 01 FF 01 FF 01 FF 01 FF DB
9/8/2024, 7:20:32 PM | 10 00 FF 00 01 C3 03 16 01 56 01 FF 01 FF 01 FF 01 FF 03 16 01 56 01 FF 01 FF 01 FF 01 FF CC
9/8/2024, 7:20:32 PM | 0B 10 FF 16 01 C3 01 FF 03 16 01 56 01 FF 01 FF 01 FF 01 FF 03 16 01 56 01 FF 01 FF 9D
9/8/2024, 7:20:32 PM | 0B 10 FF 00 01 C3 03 16 01 56 01 FF 01 FF 01 FF 01 FF 03 16 01 56 01 FF 01 FF 01 FF A5

[MichaelDvP]

Could you please check your code another time. The telegrams do not look right for me:

Checked again. Your log shows:
0B 10 FF 00 01 C3 03 16 01 56 01 FF 01 FF 01 FF 01 FF 03 16 01 56 01 FF 01 FF 01 FF A5
22 bytes long and next telegram with offset 22, also 22 bytes long.
0B 10 FF 16 01 C3 01 FF 03 16 01 56 01 FF 01 FF 01 FF 01 FF 03 16 01 56 01 FF 01 FF 9D

And now look at this commit: MichaelDvP@1be2eea

This is not the same software.

[tp1de]

I took from here
https://github.com/MichaelDvP/EMS-ESP32/releases/tag/test

[MichaelDvP]

I've made a commit only to update version, so you can check if you have the latest version installed.
For me it gives telegrams with 24 bytes and no errors:

2024-09-08 21:25:58.972 INFO 52: [thermostat] Reading jsonArray
2024-09-08 21:25:58.972 INFO 53: [thermostat] id: 0, day: mo, mode: on, time: 05:50
2024-09-08 21:25:58.972 INFO 54: [thermostat] id: 1, day: mo, mode: off, time: 21:30
2024-09-08 21:25:58.972 INFO 55: [thermostat] id: 2, day: tu, mode: on, time: 05:50
2024-09-08 21:25:58.972 INFO 56: [thermostat] id: 3, day: tu, mode: off, time: 21:30
2024-09-08 21:25:58.972 INFO 57: [thermostat] id: 4, day: we, mode: on, time: 05:50
2024-09-08 21:25:58.972 INFO 58: [thermostat] id: 5, day: we, mode: off, time: 21:30
2024-09-08 21:25:58.972 INFO 59: [thermostat] id: 6, day: th, mode: on, time: 05:50
2024-09-08 21:25:58.972 INFO 60: [thermostat] id: 7, day: th, mode: off, time: 21:30
2024-09-08 21:25:58.972 INFO 61: [thermostat] id: 8, day: fr, mode: on, time: 05:50
2024-09-08 21:25:58.972 INFO 62: [thermostat] id: 9, day: fr, mode: off, time: 21:30
2024-09-08 21:25:58.972 INFO 63: [thermostat] id: 10, day: sa, mode: on, time: 06:20
2024-09-08 21:25:58.972 INFO 64: [thermostat] id: 11, day: sa, mode: off, time: 21:30
2024-09-08 21:25:58.972 INFO 65: [thermostat] id: 12, day: su, mode: on, time: 07:00
2024-09-08 21:25:58.972 INFO 66: [thermostat] id: 13, day: su, mode: off, time: 21:30
2024-09-08 21:25:58.972 INFO 67: [command] Called command thermostat/switchprog (program switchtime) with value [{"no":0,"day":"mo","time":"05:50","mode":"on"},{"no":1,"day":"mo","time":"21:30","mode":"off"},{"no":2,"day":"tu","time":"05:50","mode":"on"},{"no":3,"day":"tu","time":"21:30","mode":"o
2024-09-08 21:25:59.378 TRACE 72: [emsesp] Me(0x4A) -W-> thermostat(0x10), RC35Timer(0x49), data: 01 23 00 81 21 23 20 81 41 23 40 81 61 23 60 81 81 23 80 81 A1 26 A0 81
2024-09-08 21:26:00.266 TRACE 81: [emsesp] Me(0x4A) -W-> thermostat(0x10), RC35Timer(0x49), data: C1 2A C0 81 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF (offset 24)
2024-09-08 21:26:00.891 TRACE 86: [emsesp] Me(0x4A) -W-> thermostat(0x10), RC35Timer(0x49), data: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF (offset 48)
2024-09-08 21:26:01.383 TRACE 89: [emsesp] Me(0x4A) -W-> thermostat(0x10), RC35Timer(0x49), data: FF FF FF FF FF FF FF FF FF 90 E7 90 (offset 72)

This was a test with 3.7.0.test34 from my github. (not compiled here).

[tp1de]

Sorry Michael, this is difficult for me to understand.
I installed your latest version test35 . Result in respect to length and offset is unchanged.

[tp1de]

My gateway crashed this morning again and lost wifi connection.
Restarted at 6:30 and connected afterward for 14 minutes and then lost connection.
Without parameter changes.
I am not at home and can't restart.
Something is instable in current firmware.

Edit:

I recognized that the wifi disconnect is due to protected management frames pmf on wifi, which was activated in my fritzbox mesh master. This has been activated for a long time.
A couple of days ago, the fb firmware was updated for my fb7590, which is used as a mesh slave accesspoint.
I see regular disconnects and reconnects in the last days with errors on pmf, but at the end, reconnects were working. Just today morning, not.

[tp1de]

@MichaelDvP
I installed the node-red scripts for switchprograms as well on my second installation and compared the telegrams:

1. Moduline 2050
   Telegrams have the right length and offset and thermostat replies are fine as well as far as I can judge.
   Why are errors shown in log?
   moduline 2050.txt

2. RC310
   Telegram length and offsets are different -why? Do they depend on thermostat type?
   RC310.txt

In both cases the post commands are executed and the switchprograms are changed.
Both ems-esp gateways are using your latest test version

[MichaelDvP]

Seems the moduline does not like the 24bytes telegrams, no error for the 12byte part. Let's try to send 12byte telegrams.
I'll push test36 version.

RC310 is still test34 with 22 byte. I think you need to clear browser cache before updating, There were some changes in update-code of dev34 that i've merged to keep up to date with the dev.

[tp1de]

Seems the moduline does not like the 24bytes telegrams, no error for the 12byte part. Let's try to send 12byte telegrams.
I'll push test36 version.

Does not make it better:
moduline 2050 2.txt

[tp1de]

Doing changes on moduline 2050 for mo-fr sends this telegrams:

9/10/2024, 3:51:35 PM | 18 00 FF 30 01 C3 03 18 01 1A 03 FF 01 FF 03 FF 01 FF 3D
9/10/2024, 3:51:34 PM | 18 00 FF 18 01 C3 03 18 01 1A 03 FF 01 FF 03 FF 01 FF 03 18 01 1A 03 FF 01 FF 03 FF 01 FF 0D
9/10/2024, 3:51:34 PM | 18 00 FF 00 01 C3 03 18 01 1A 03 FF 01 FF 03 FF 01 FF 03 18 01 1A 03 FF 01 FF 03 FF 01 FF 23

[tp1de]

Doing changes on RC310 using the cloud app and the gateway for monday and then copying to all other days sends this telegrams:

Copy Monday to other days:
9/10/2024, 3:38:25 PM 10 00 FF 3C 01 C3 03 16 01 56 03 FF 03 FF 03 FF 03 FF 03 16 01 56 03 FF 03 FF 03 FF 03 FF 00
9/10/2024, 3:38:25 PM 10 00 FF 24 01 C3 03 16 01 56 03 FF 03 FF 03 FF 03 FF 03 16 01 56 03 FF 03 FF 03 FF 03 FF 2E
9/10/2024, 3:38:24 PM 10 00 FF 0C 01 C3 03 16 01 56 03 FF 03 FF 03 FF 03 FF 03 16 01 56 03 FF 03 FF 03 FF 03 FF 5C
9/10/2024, 3:38:24 PM 48 10 FF 3E 01 C3 01 56 FF FF FF FF FF FF FF FF 03 16 01 56 FF FF FF FF FF FF FF FF E4
9/10/2024, 3:38:23 PM 48 10 FF 25 01 C3 16 01 56 FF FF FF FF FF FF FF FF 03 16 01 56 FF FF FF FF FF FF FF FF 03 16 EE
9/10/2024, 3:38:23 PM 48 10 FF 0C 01 C3 03 16 01 56 FF FF FF FF FF FF FF FF 03 16 01 56 FF FF FF FF FF FF FF FF 03 A9

Monday changes:
9/10/2024, 3:37:23 PM 10 00 FF 00 01 C3 03 16 01 56 03 FF 03 FF 03 FF 03 FF FF
9/10/2024, 3:37:22 PM 48 10 FF 00 01 C3 03 16 01 56 FF FF FF FF FF FF FF FF 71

[MichaelDvP]

moduline 2050 2.txt

Aha, a complete log, so i can see the context. There is a issue with tx to the master , the master echo is incomplete (one byte too long). Try another tx-mode.

[tp1de]

I tried all TX modes. They are all worse compared to EMS. Moduline is a EMS 2.0 thermostat.

[MichaelDvP]

repeated wrong master echos that shows different receive from sending (in this case an extra byte after crc):
Incomplete Rx: 0B 18 FF 24 01 C3 03 18 01 58 01 FF 01 FF 01 FF 01 FF 14 89
Last Tx Write operation failed after 3 retries. Ignoring request: 0B 18 FF 24 01 C3 03 18 01 58 01 FF 01 FF 01 FF 01 FF
is wrong timing (tx-mode) or bad cabeling.

[tp1de]

is wrong timing (tx-mode) or bad cabeling.

I agree that this is a timing problem. I tested with sending raw telegrams per days - so 7 telegrams without delay:
The result could be

(1) moduline 2050 3.txt
or
(2) moduline 2050 4.txt

In (1) there are a lot of errors and more other telegrams send by thermostat
In (2) there are no errors and just very few other telegrams send by thermostat

And it can be recognized that the send commands are processed in reverse order - the last one first.

I do not think that this a cabeling problem. (ems-esp connected by service jack and thermostat with 5 m cable)
Could it be that the thermostat is processing rather slow and blocks other requests when occupied?
Or could it be a controller problem? (BC10 - deviceID : "0x09" - productID : 190)

[MichaelDvP]

Does your boiler use buderus or ht3 protocoll? You'll find it in support info.
The bad telegrams always ends with an extra byte after the CRC, sometimes 98, sometimes 89. In ht3 this could be sending from thermostat (0x18 | 0x80) and controller (0x09 | 0x80). But the controler normally
does not send.
Or the master misses the the break, timeouts, and this is the (buderus-protocol) poll to next device.
But, on the other hand, we get the message last Tx write rejected by host, this means, the thermostat get's the same corrupted message and reject the telegram by sending a 0x04 to emsesp, which is echoed by the master. So the master seems not to be in polling mode. I don't have an explanation for this.

And it can be recognized that the send commands are processed in reverse order - the last one first.

Yes, all tx messages are queued and waiting for the master poll. The periodic reads go to end of queue, writes go to top of queue to be send first. If you queue many writes each new goes to top and is sended out first.

[tp1de]

The boiler is a Netfit Trendline II from Bosch. It uses the EMS protocoll.

[proddy]

I have the same boiler..the Dutch Nefit variant, but a Trendline II CW5. Can I help test something?

[MichaelDvP]

I've already figured out that it's buderus protocoll. The Incomplete Rx is sent before the ht3-bit stripped.
So the extra byte is not from thermostat, but the thermostat also receives it and sends NACK back.

@proddy Do you have seen such effects on writing something to thermostat (i know you have RC20, but it's also a write to device 0x18).

[proddy]

@proddy Do you have seen such effects on writing something to thermostat (i know you have RC20, but it's also a write to device 0x18).

No I'm not seeing that here on my old RC20/Moduline 300 - adjusting the Thermostat's hc1/seltemp from EMS-ESP, nothing else is sent to the thermostat after other than the fetched ones we trigger

[tp1de]

The moduline 2050 supports the ems protocol and as well open therm.
Could this be the reason for special protocol handling?

[MichaelDvP]

@proddy afaik the RC20 has timer on telegram 0x8F, does this work with my testbuild?
@tp1de Do you see the same appended byte on short telegrams like seltemp? And if you write only a single switchtime in the program (not asarray [{...},{..}], only as jsonObject {...})?

[tp1de]

Do you see the same appended byte on short telegrams like seltemp?

No. And as explained comparing the two logs moduline 2050 3 and 4 you can see, that under certain conditions the 7 switchtimes writes work without any appended byte as well. It is a matter of other telegrams send inbetween. (total traffic during processing the changes)

It is a guess: Does the appended byte indicate that the telegram should be resend or that the telegrams is stored and not written immediately but delayed ....??

[proddy]

@proddy afaik the RC20 has timer on telegram 0x8F, does this work with my testbuild?

I tested your build, saw the hp1 program switchtime command in the WebUI, entered the value [{"no":0,"day":"mo","time":"05:50","mode":"on"}] to see what happens and I see the telegrams sent, no errors. I checked on the physical RC20, and all the clock programs have been erased. So something is working! Do you have any test data I can use?

[MichaelDvP]

all the clock programs have been erased.

Oh,bad. have you sent the command direct after starting before the telegram was read?. I will add a check for this.

Do you have any test data I can use?

Only for RC300, i have no telegram data for RC20, just a notice about timer telegram typeid. For RC20_N i don't know the timer-telegram(s).

@tp1de

Does the appended byte indicate that the telegram should be resend or that the telegrams is stored and not written immediately but delayed ....??

No, the thermostat also gets the wrong bytes appended and answers with a "not-ack"-byte. It's something from the busmaster.
On ems bus the master provides the voltage and sends to the client with voltage modulation. The clients (and emsesp) only reads voltage modulation(rx), but sends as current modulation. Only the master can read current modulation and repeats byte by byte the sending of the client, so other clients can receive it. Here emsesp sends via current modulation the correct telegram and the master repeats with an extra byte. emsesp and the thermostat receives now a wrong telegram and the thermostats send (as current modulation) the NACK which is repeated (as voltage modulation) by the master and received from emsesp.

[tp1de]

I do have difficulties to interprete the consequences of errors when writing the switchtimes.
The log shows:

Last Tx Write operation failed after 3 retries. Ignoring request:0B 18 FF 00 01 C3 03 16 01 58 03 FF 03 FF 03 FF 03 FF

I would expect that changes are not written. But this not the case.
All changes are updated correctly.

See log:
moduline 2050 5.txt