Junkers FW200/FB10 can't change selected room temperature independent of the currently active mode

[YvesPrnt]

Setup:

EMS-ESP Version: v3.4.4
Interface: BBQKees Bus interface board V3
Boiler: Junkers Cerapur Top
Connected devices:

Boiler: Condens 2500/Logamax/Logomatic/Cerapur Top/Greenstar/Generic HT3 (DeviceID:0x08, ProductID:95, Version:18.11) (63)
Thermostat: Junkers FW200 (DeviceID:0x10, ProductID:106, Version:12.14) (27)
Thermostat: Junkers FB10 (DeviceID:0x19, ProductID:109, Version:16.05) (1)
Mixer: Junkers IPM (DeviceID:0x20, ProductID:102, Version:20.07) (4)
Mixer: Junkers IPM (DeviceID:0x21, ProductID:102, Version:20.07) (2)
Controller: HT3 (DeviceID:0x09, ProductID:95, Version:18.11) (0)

The FW200 is set up in the living room which is heated with underfloor heating. The FB10 is mounted in the bathroom and controls the upstairs radiators. The dual circuit (low temp underfloor heating and high temp radiators) is controlled by the IPM2 mixer module.

Issue:

The selected room temperature and the currently active mode (nofrost, eco or heat) value can not be changed independantly.
For instance, with my HC2 settings as follows:

hc2 selected room temperature: 10.0 °C
hc2 mode: auto
hc2 mode type: nofrost
hc2 heat temperature: 21.5 °C
hc2 eco temperature: 15.0 °C
hc2 nofrost temperature: 10.0 °C

If I change the selected room temperature, the nofrost temperature also changes to the same value. The reverse is also true: when the nofrost temp is changed, the selected room temp also changes.

hc2 selected room temperature: 12.0 °C
hc2 mode: auto
hc2 mode type: nofrost
hc2 heat temperature: 21.5 °C
hc2 eco temperature: 15.0 °C
hc2 nofrost temperature: 12.0 °C

Now, if I want to change the set temp or nofrost temp to e.g. 16°C, it won't work since the eco temperature is set at 15° and the nofrost can never be higher than the eco. The same goes for eco and heat temperature. If I first change the eco temperature to 16° or higher (but <= 21.5°C)
So the EMS-ESP doesn't allow for a change of the room temperature without also changing the value of the currently active mode with the limitation that: nofrost <= eco <= heat

Physically changing the temps on the FW200 or FB10 does not have this limitation. Below you see the log of when such a change is made (changing the HC2 setpoint, which is controlled by the FB10, via the FW200)

> 2022-11-06 11:35:01.064 TRACE 3986: [emsesp] Thermostat(0x10) -> All(0x00), JunkersMonitor(0x0170), data: 01 02 00 CD 00 B8 00 D2 00
> 2022-11-06 11:35:01.540 TRACE 3987: [emsesp] Thermostat(0x10) -> Mixer(0x21), JunkersSetMixer(0x23), data: 3C
> 2022-11-06 11:35:01.580 TRACE 3988: [emsesp] Thermostat(0x10) -> Thermostat(0x19), ?(0x0122), data: FF 2A
> 2022-11-06 11:35:01.580 DEBUG 3989: [emsesp] No telegram type handler found for ID 0x122 (src 0x10)
> 2022-11-06 11:35:01.637 TRACE 3990: [emsesp] Thermostat(0x10) -> All(0x00), JunkersMonitor(0x0170), data: 01 02 00 D7 00 B8 00 D2 00
> 2022-11-06 11:35:01.868 TRACE 3991: [emsesp] Boiler(0x08) -> All(0x00), UBAMonitorFast(0x18), data: 00 02 77 42 00 00 02 40 C0 02 0A 80 00 02 1A FF FF 10 00 00 00 00 00 00 00
> 2022-11-06 11:35:02.109 TRACE 3992: [emsesp] Boiler(0x08) -> All(0x00), UBAMonitorWW(0x34), data: 3C 02 0C 80 00 A0 00 00 01 00 00 CA C2 00 8C DE 00
> 2022-11-06 11:35:02.451 TRACE 3993: [emsesp] Mixer(0x21) -> All(0x00), IPMStatusMessage(0x010C), data: 01 (offset 1)
> 2022-11-06 11:35:02.791 TRACE 3994: [emsesp] Thermostat(0x10) -> Thermostat(0x19), ?(0x0122), data: FF 2B
> 2022-11-06 11:35:02.791 DEBUG 3995: [emsesp] No telegram type handler found for ID 0x122 (src 0x10)
> 2022-11-06 11:35:02.945 TRACE 3996: [emsesp] Mixer(0x21) -> Boiler(0x08), UBASetPoints(0x1A), data: 3C
> 2022-11-06 11:35:02.945 DEBUG 3997: [emsesp] No telegram type handler found for ID 0x1A (src 0x21)

Looking at all the logs I notices that the EMS-ESP is sending the change directly to the thermostat Me(0x0B) -> Thermostat(0x10), JunkersSet(0x0165). When the change is made physically on the device, the change is sent to Thermostat(0x10) -> All(0x00), JunkersMonitor(0x0170)
Could the telegram type handler IDs have something to do with it?

When I change the temperature directly with the FB10 from 10°C -> 21°C I see the following commands in the log:

15:16:31.507 T 26919: [emsesp] Thermostat(0x19) -> Thermostat(0x10), JunkersRemote(0x0123), data: 00 C0 15 00
15:16:31.556 T 26920: [emsesp] Thermostat(0x19) -> Thermostat(0x10), JunkersRemote(0x0123), data: 00 C0 17 00
15:16:32.128 T 26922: [emsesp] Thermostat(0x19) -> Thermostat(0x10), JunkersRemote(0x0123), data: 00 C0 1D 00
15:16:32.724 T 26932: [emsesp] Thermostat(0x19) -> Thermostat(0x10), JunkersRemote(0x0123), data: 00 C0 1F 00
15:16:32.773 T 26933: [emsesp] Thermostat(0x19) -> Thermostat(0x10), JunkersRemote(0x0123), data: 00 C0 21 00
15:16:33.377 T 26940: [emsesp] Thermostat(0x19) -> Thermostat(0x10), JunkersRemote(0x0123), data: 00 C0 22 00
15:16:33.965 T 26952: [emsesp] Thermostat(0x19) -> Thermostat(0x10), JunkersRemote(0x0123), data: 00 C0 25 00
15:16:34.626 T 26959: [emsesp] Thermostat(0x19) -> Thermostat(0x10), JunkersRemote(0x0123), data: 00 C0 28 00
15:16:35.280 T 26966: [emsesp] Thermostat(0x19) -> Thermostat(0x10), JunkersRemote(0x0123), data: 00 C0 2A 00

I'd really like to control the selected room temperature of the hc2 just like I would turn the dial on the FB10 or the FW200 😊

[MichaelDvP]

This is a known issue, we have checked it in #167. Buderus thermostats have a field for setting temporary temperature, but the junkers does not publish the setting change, it's only published in the (not writable) monitor telegram.

I'm not sure how the remote telegram works, Is it always 0x123 and the master-thermostats checks the sender (0x19 hc2, 0x18 hc1) (the way rc35 handles remotes), or have different hc different telegrams, hc2: 0x123, hc1:0x122 (the way rc300 handles remotes)?
Try if you can change the temperature by
call system send "0B 08 FF 02 00 23 28" (set hc2 to 20,0°C)
call system send "0B 08 FF 02 00 22 28" (set hc1 to 20,0°C)
I don't think it will work, normally remotes have to be configured, but it's worth a try.

[YvesPrnt]

I tried your suggestion but like you thought it didn't work.
I don't know enough of the workings of the telegrams to really know a possible way forward, but wouldn't it be possible to 'spoof' the message from the FB10 (0x19)?

[MichaelDvP]

Was there a response?

Its not possible to spoof a reponse from 0x19 if 0x19 is present: The master polls for 0x19 and 0x19 replys, if we also reply it's a collision. We can only simulate a non present device.

[YvesPrnt]

this was the response I got in the terminal

001+07:01:39.385 E 1: [telegram] Last Tx Read operation failed after 3 retries. Ignoring request: 8B 88 FF 00 19 00 23
001+07:01:39.385 I 2: [emsesp] Boiler(0x08) -> Me(0x0B), JunkersRemote(0x0123), data: <empty>

Looking at the log:

2022-11-07 19:19:47.832 DEBUG 233428: [command] Calling command 'system/send' (send a telegram) with value 0B 08 FF 02 00 23 28
2022-11-07 19:19:47.878 DEBUG 233429: [telegram] Sending write Tx [#192], telegram: 8B 08 FF 02 00 23 28
2022-11-07 19:19:47.895 TRACE 233430: [emsesp] Me(0x0B) -> Boiler(0x08), JunkersRemote(0x0123), data: 28 (offset 2)
2022-11-07 19:19:47.895 DEBUG 233431: [emsesp] No telegram type handler found for ID 0x123 (src 0x0B)
2022-11-07 19:19:47.914 DEBUG 233432: [emsesp] Last Tx write successful
2022-11-07 19:19:47.914 DEBUG 233433: [telegram] Sending post validate read, type ID 0x123 to dest 0x08
2022-11-07 19:19:48.221 DEBUG 233434: [telegram] Sending read Tx [#193], telegram: 8B 88 FF 00 19 00 23
2022-11-07 19:19:48.221 TRACE 233435: [emsesp] Me(0x0B) <- Boiler(0x08), JunkersRemote(0x0123), length: 0x19
2022-11-07 19:19:48.688 TRACE 233436: [emsesp] Mixer(0x21) -> Boiler(0x08), ?(0x1E), data: 00 D7
2022-11-07 19:19:48.688 DEBUG 233437: [emsesp] No telegram type handler found for ID 0x1E (src 0x21)
2022-11-07 19:19:48.783 DEBUG 233438: [telegram] Sending read Tx [#194], telegram: 8B 88 FF 00 19 00 23
2022-11-07 19:19:48.801 TRACE 233439: [emsesp] Me(0x0B) <- Boiler(0x08), JunkersRemote(0x0123), length: 0x19
2022-11-07 19:19:49.345 DEBUG 233440: [telegram] Sending read Tx [#195], telegram: 8B 88 FF 00 19 00 23
2022-11-07 19:19:49.345 TRACE 233441: [emsesp] Me(0x0B) <- Boiler(0x08), JunkersRemote(0x0123), length: 0x19
2022-11-07 19:19:49.875 DEBUG 233442: [telegram] Sending read Tx [#196], telegram: 8B 88 FF 00 19 00 23
2022-11-07 19:19:49.875 TRACE 233443: [emsesp] Me(0x0B) <- Boiler(0x08), JunkersRemote(0x0123), length: 0x19
2022-11-07 19:19:50.162 ERROR 233444: [telegram] Last Tx Read operation failed after 3 retries. Ignoring request: 8B 88 FF 00 19 00 23
2022-11-07 19:19:50.162 INFO 233445: [emsesp] Boiler(0x08) -> Me(0x0B), JunkersRemote(0x0123), data: <empty>
2022-11-07 19:19:50.162 DEBUG 233446: [emsesp] No telegram type handler found for ID 0x123 (src 0x08)

[YvesPrnt]

Maybe it helps if I give the call system info device information. I noticed it show the handlers
Still don't get how any of this works. Is there a resource somewhere where I can learn the inner workings of the HT3 protocol?

"Devices": [
    {
      "type": "Boiler",
      "name": "Condens 2500/Logamax/Logomatic/Cerapur Top/Greenstar/Generic HT3",
      "device id": "0x08",
      "product id": 95,
      "version": "18.11",
      "entities": 63,
      "handlers received": "0x10 0x11 0x15 0x1C 0x18 0x19 0x34 0x2A",
      "handlers fetched": "0x14 0x16 0x33",
      "handlers pending": "0xBF 0xC2 0x1A 0x35 0x26"
    },
    {
      "type": "Thermostat",
      "name": "FW200",
      "device id": "0x10",
      "product id": 106,
      "version": "12.14",
      "entities": 27,
      "handlers received": "0x06 0x23",
      "handlers fetched": "0x016F 0x0170 0x0165 0x0166 0xBB",
      "handlers pending": "0xA3 0xA2 0x12 0x0171 0x0172 0x0167 0x0168 0x0123",
      "handlers ignored": "0x35 0x1A 0xBE 0x01D3 0x0122"
    },
    {
      "type": "Thermostat",
      "name": "FB10",
      "device id": "0x19",
      "product id": 109,
      "version": "16.05",
      "entities": 1,
      "handlers received": "0x0123",
      "handlers pending": "0xA3 0x06 0xA2 0x12 0x016F 0x0170 0x0171 0x0172 0x0165 0x0166 0x0167 0x0168 0xBB 0x23",
      "handlers ignored": "0xBE 0x011F"
    },
    {
      "type": "Mixer",
      "name": "IPM",
      "device id": "0x20",
      "product id": 102,
      "version": "20.07",
      "entities": 4,
      "handlers received": "0x010C",
      "handlers pending": "0x011E",
      "handlers ignored": "0x1A 0xBE 0x010B"
    },
    {
      "type": "Mixer",
      "name": "IPM",
      "device id": "0x21",
      "product id": 102,
      "version": "20.07",
      "entities": 2,
      "handlers received": "0x010C",
      "handlers pending": "0x011E",
      "handlers ignored": "0x1E 0x1A 0xBE 0x010B"
    },
    {
      "type": "Controller",
      "name": "HT3",
      "device id": "0x09",
      "product id": 95,
      "version": "18.11",
      "entities": 0
    }
  ]

[MichaelDvP]

Thanks for the log. I see "Last Tx write successful", but it seems without any effect.

Is there a resource somewhere where I can learn the inner workings of the HT3 protocol?

See #714