FredericMa commented 4 years ago

Question At the moment I'm using the setup from Norbert (https://github.com/norberts1/hometop_HT3) but I want to move to EMS-ESP to free a Raspberry Pi and for the easier setup and maintenance your project offers.

One of my colleagues modified the pitiny (https://github.com/norberts1/hometop_ht_transceiver/blob/master/hw/pitiny/HT_pitiny_1.png) so it could work with this project (don't ask me the details. I can provide a picture if wanted). I wired everything up and installed 2.0.0a27.

My heating system contains a CerapurSmart A TOP 14-3CE ZSB heater, FW200 thermostat, a pump unit (IPM1), a solar system (ISM1) and a 300l tank (only temperature sensor from heater and solar module connected). The pump unit controls 2 circuits, one mixed for floor heating and one unmixed for radiators.

Remark: Also the pitiny from Norbert is still connected and collecting/sending data.

A few things don't seem to work at the moment. These are my observations at the moment:

There seem to be 2 unrecognized devices (maybe the IPM1 module?):

000+04:20:24.602 N 3: [emsesp] Unrecognized EMS device with device ID 0x20 with product ID 102. Please report on GitHub.
000+04:20:24.978 N 4: [emsesp] Unrecognized EMS device with device ID 0x21 with product ID 102. Please report on GitHub.

show values gives me the following results:


Boiler: Condens 2500/Logamax/Logomatic/Cerapur Top/Greenstar/Generic HT3 (DeviceID:0x08, ProductID:95, Version:23.04)
Hot tap water: off
Central heating: off
Warm Water activated: on
Warm Water charging type: 3-way valve
Warm Water circulation pump available: off
Warm Water circulation pump freq: 1x3min
Warm Water circulation active: off
Warm Water comfort setting: Hot
Warm Water disinfection temperature: 75°C
Warm Water selected temperature: 50°C
Warm Water set temperature: 50°C
Warm Water current temperature (intern): 77.6°C
Warm Water current temperature (extern): 77.6°C
Warm Water current tap water flow: 0.0l/min
Warm Water # starts: 797
Warm Water active time: 12 days 10 hours 44 minutes
Warm Water charging: off
Warm Water disinfecting: off
Selected flow temperature: 0°C
Current flow temperature: 29.0°C
Gas: off
Boiler pump: off
Fan: off
Ignition: off
Burner selected max power: 100%
Burner current power: 0%
System service code:  (0)
Heating temperature setting on the boiler: 66°C
Boiler circuit pump modulation max power: 100%
Boiler circuit pump modulation min power: 10%
Outside temperature: 31.0°C
Pump modulation: 0%
Burner # starts: 104908
Total burner operating time: 364 days 10 hours 54 minutes
Total heat operating time: 352 days 0 hours 10 minutes

Boiler: HT3 (DeviceID:0x09, ProductID:95, Version:23.04) Warm Water activated: on Warm Water charging type: 3-way valve Warm Water circulation pump available: off Warm Water circulation pump freq: 1x3min Warm Water comfort setting: Hot Warm Water disinfection temperature: 75°C Warm Water selected temperature: 50°C Heating temperature setting on the boiler: 66°C Boiler circuit pump modulation max power: 100% Boiler circuit pump modulation min power: 10% Outside temperature: 31.0°C Pump modulation: 0% Burner # starts: 104908 Total burner operating time: 364 days 10 hours 54 minutes Total heat operating time: 352 days 0 hours 10 minutes

Thermostat: Junkers FW200 (DeviceID:0x10 ProductID:106, Version:12.14) Clock: 15:20:15 24/06/2020

Solar Module: Junkers ISM1 (DeviceID:0x30 ProductID:101, Version:23.04) Collector temperature (TS1): 90.6°C Bottom temperature (TS2): 78.1°C Pump (PS1) active: on Pump working time: 194 days 2 hours 0 minutes Energy last hour: 67226867.2Wh

- As you can see, there are 2 boiler devices detected but I only have one and also the data from the second instance is a limited data set of the first boiler.
- Also the IPM isn't listed but I guess it is not implemented yet.
- The thermostat is recognised as a FW200 but only shows the current time. (I guess it should also display the status of both circuits?)

**Device information**

These EMS devices are currently active:

Boiler: Condens 2500/Logamax/Logomatic/Cerapur Top/Greenstar/Generic HT3 (DeviceID:0x08, ProductID:95, Version:23.04) This Boiler will respond to telegram type IDs: 0x10 0x11 0x18 0x19 0x34 0x1C 0x2A 0x33 0x14 0x35 0x15 0x16 0x1A 0xD1 0xE3 0xE4 0xE5 0xE9 Subscribed MQTT topics: boiler_cmd boiler_cmd_wwactivated boiler_cmd_wwonetime boiler_cmd_wwcirculation boiler_cmd_wwtemp

Boiler: HT3 (DeviceID:0x09, ProductID:95, Version:23.04) This Boiler will respond to telegram type IDs: 0x10 0x11 0x18 0x19 0x34 0x1C 0x2A 0x33 0x14 0x35 0x15 0x16 0x1A 0xD1 0xE3 0xE4 0xE5 0xE9 Subscribed MQTT topics: boiler_cmd boiler_cmd_wwactivated boiler_cmd_wwonetime boiler_cmd_wwcirculation boiler_cmd_wwtemp

Thermostat: Junkers FW200 (DeviceID:0x10 ProductID:106, Version:12.14) master device This Thermostat will respond to telegram type IDs: 0xA3 0x06 0x6F 0x65 0x70 0x66 0x71 0x67 0x72 0x68 Subscribed MQTT topics: thermostat_cmd thermostat_cmd_temp thermostat_cmd_mode

Solar Module: Junkers ISM1 (DeviceID:0x30 ProductID:101, Version:23.04) This Solar Module will respond to telegram type IDs: 0x103 0x101

EMS Bus info: Tx mode: 3 Bus protocol: HT3

telegrams received: 18260

read requests sent: 2537

write requests sent: 0

corrupted telegrams: 0 (0%)

tx fails (after 3 retries): 562

Rx Queue is empty

Tx Queue is empty



It should be rather easy to analyse stuff since I can use the software from Norbert to check stuff in parallel for example for the IPM1 module or thermostat.
Thanks for looking at this.

proddy commented 4 years ago

Hi @FredericMa , wow lots of interesting information here. And thanks for using version 2.0 which is still in development and we're in need of some real live use-cases from people with Junkers devices.

A few initial observations:

@BBQKees also has a version of his ESP8266 Gateway board that works with a RPi so if you run into hardware issues check that out.
The two devices 0x20 and 0x21 are mixing units. So this is your IPM. I'll add them to the database so they get recognized next time and then we can work on fine tuning the data. Luckily Nobert has mapped a lot of this information already for us.
Why you get too boilers is strange and most likely a bug.
You should be seeing the FW200 Thermostat data too. That's also a bug that we need to fix.
on the Solar module that energy last hour is crazy high. That's a bug too.

I'll need you to send some raw data over so we can take a look and simulate your environment in the tests. Use telnet (e.g. putty) then in the ems menu, log info, watch raw and leave it running for a few minutes. Send over the log.

FredericMa commented 4 years ago

Happy to help! Thanks for the quick reply. Here you can find the requested log: raw_ems-esp_log.txt

I had a few PCBs and components left of the pitiny so tried to recycle that first 😄 Except the Last Tx Read operation failed after 3 retries. Ignoring request. all looks OK for now.
Yes indeed, I also noticed the wrong last hour energy for the solar. In the log file, the value should correspond to 1185W.

MichaelDvP commented 4 years ago

The last TX Read operation failed comes very regular but after a lot of successfull Tx, i'm not sure if it is a timing issue or it's due to false thermostat requests or requests to the controller which is irratically identified as boiler. @FredericMa can you do a second log with watch raw but with also set to log debug , than we can see which telegrams causes this. Can you please also check if other tx_modes working on your system. Try with set tx_mode 7, If working, try 6, 5, 4, if not set to 10 and 17. You can change tx_modes while logging, than wait for last Tx successfullor last Tx_failed than change to next mode. After the test go back to mode 3, as we know this is working most of the time.

FredericMa commented 4 years ago

I made a new log with debug enabled and tested the suggested modes but they all generate the last TX Read operation failed message.

ems-esp_debug_log.txt

FredericMa commented 4 years ago

I just uploaded the new build after PR #411 and made a new log. Only with tx_mode=3 now. ems-esp_debug_log_2.txt

show values still shows 2 boiler devices but the thermostat, IPM and energy last hour for the solar are correct:

ems-esp:/ems# show values
Boiler: HT3 (DeviceID:0x08, ProductID:95, Version:23.04)
  Hot tap water: off
  Central heating: off
  Warm Water activated: on
  Warm Water charging type: 3-way valve
  Warm Water circulation pump available: off
  Warm Water circulation pump freq: 1x3min
  Warm Water circulation active: off
  Warm Water comfort setting: Hot
  Warm Water disinfection temperature: 75°C
  Warm Water selected temperature: 50°C
  Warm Water set temperature: 50°C
  Warm Water current temperature (intern): 75.0°C
  Warm Water current temperature (extern): 75.0°C
  Warm Water current tap water flow: 0.0l/min
  Warm Water # starts: 797
  Warm Water active time: 12 days 10 hours 44 minutes
  Warm Water charging: off
  Warm Water disinfecting: off
  Selected flow temperature: 0°C
  Current flow temperature: 29.4°C
  Gas: off
  Boiler pump: off
  Fan: off
  Ignition: off
  Burner selected max power: 100%
  Burner current power: 0%
  System service code:  (0)
  Heating temperature setting on the boiler: 66°C
  Boiler circuit pump modulation max power: 100%
  Boiler circuit pump modulation min power: 10%
  Outside temperature: 29.8°C
  Pump modulation: 0%
  Burner # starts: 104908
  Total burner operating time: 364 days 10 hours 54 minutes
  Total heat operating time: 352 days 0 hours 10 minutes

Boiler: HT3 (DeviceID:0x09, ProductID:95, Version:23.04)
  Warm Water activated: on
  Warm Water charging type: 3-way valve
  Warm Water circulation pump available: off
  Warm Water circulation pump freq: 1x3min
  Warm Water comfort setting: Hot
  Warm Water disinfection temperature: 75°C
  Warm Water selected temperature: 50°C
  Heating temperature setting on the boiler: 66°C
  Boiler circuit pump modulation max power: 100%
  Boiler circuit pump modulation min power: 10%
  Outside temperature: 29.8°C
  Pump modulation: 0%
  Burner # starts: 104908
  Total burner operating time: 364 days 10 hours 54 minutes
  Total heat operating time: 352 days 0 hours 10 minutes

Thermostat: Junkers FW200 (DeviceID:0x10 ProductID:106, Version:12.14)
  Clock: 12:33:05 25/06/2020
  Heating Circuit 1:
    Current room temperature: 25.2°C
    Setpoint room temperature: 15.0°C
    Mode: manual
    Mode Type: day
    Program is set to Summer mode
  Heating Circuit 2:
    Current room temperature: 25.2°C
    Setpoint room temperature: 18.0°C
    Mode: manual
    Mode Type: day
    Program is set to Summer mode

Mixing Module: Junkers IPM (DeviceID:0x20 ProductID:102, Version:20.08)
  Heating Circuit: 1
    Current pump modulation: 0%

Mixing Module: Junkers IPM (DeviceID:0x21 ProductID:102, Version:20.08)
  Heating Circuit: 2
    Current flow temperature: 28.3°C
    Setpoint flow temperature: 0°C
    Current pump modulation: 0%
    Current valve status: 0

Solar Module: Junkers ISM1 (DeviceID:0x30 ProductID:101, Version:23.04)
  Collector temperature (TS1): 73.0°C
  Bottom temperature (TS2): 70.3°C
  Pump (PS1) active: off
  Pump working time: 194 days 3 hours 0 minutes
  Energy last hour: 53.0Wh

MichaelDvP commented 4 years ago

The second boiler is the builtin controller, the problem is that it shares the productID with the boiler. It's the same device, so only the values are double. @proddy Strange that name (HT3), DeviceID (0x09), etc. are correct matched to the controller in the database, but than mapped to boiler.

proddy commented 4 years ago

@proddy Strange that name (HT3), DeviceID (0x09), etc. are correct matched to the controller in the database, but than mapped to boiler.

yes, odd. I'm working on a test to try and reproduce this.

MichaelDvP commented 4 years ago

000+00:08:03.475 D 386: [telegram] Sending read Tx [#38], telegram: 8B 90 FF 00 20 00 6F 20 8D
000+00:08:03.751 D 387: [telegram] [DEBUG] Last Tx Read operation failed. Retry #1.

The requests are one byte to long.

FredericMa commented 4 years ago

I've uploaded the latest a28 build and the controller is recognized correctly now. The failed read operations are less but I still see one every minute. I've uploaded a new log: ems-esp_debug_log.txt

Thanks for the quick and good support guys!

MichaelDvP commented 4 years ago

The fails are version requests to a modem. I think that's the raspberry identifying itself as modem, but do not answer to version request.

FredericMa commented 4 years ago

Yes that must be it!

Something else I noticed is that if the esp is in read-only mode, the devices and values don't get listed. Is this intended behavior? I would expect that it is able to process all incoming data. scan devices doesn't solve but I guess it should send messages in order to perform the scan?

This is the output (I removed some frames from the TX queue):

┌──────────────────────────────────────────┐
│ EMS-ESP version 2.0.0a28                 │
│ https://github.com/proddy/EMS-ESP        │
│                                          │
│ type help to show available commands     │
└──────────────────────────────────────────┘

000+00:03:20.023 E 0: [telegram] Tx is not active. Please check connection.
ems-esp:/$ ems
ems-esp:/ems$ set
Tx mode = 3
Bus ID = 0B
Read-only mode is on
ems-esp:/ems$ show
No EMS devices detected. Try using 'scan devices' from the ems menu.

EMS Bus info:
  Tx mode: 3
  Bus protocol: HT3
  #telegrams received: 206
  #read requests sent: 0
  #write requests sent: 0
  #corrupted telegrams: 0 (0%)
  #tx fails (after 3 retries): 0

Rx Queue is empty

Tx Queue (23 telegrams):
 [00 ] READ  Me(0x0B) -> 08(0x08), ?(0x07), data: 20 (offset 0)
...
 [22 ] READ  Me(0x0B) -> 30(0x30), Version(0x02), data: 20 (offset 0)

ems-esp:/ems$ show values
No EMS devices detected. Try using 'scan devices' from the ems menu.

000+00:03:30.024 E 1: [telegram] Tx is not active. Please check connection.
ems-esp:/ems$

proddy commented 4 years ago

that's correct. The read-only mode switches of any Tx sending. And what's ironic is that we need to send Tx in scan devices and also at boot up to query what the device is and fetch its product ID, version etc..

I can't remember why I added this option, perhaps as a fail-safe when I was writing the core because I didn't want to damage the boiler with garbage.

So I'm thinking this feature it's pretty useless!

Is there a reason you need something like this?

FredericMa commented 4 years ago

The reason is use this at the moment is because there is something weird going on with the "Warm Water selected temperature". During the night the selected temperature changes from 50° to 15°. I don't know exactly what is causing this since I didn't find any setting to change the temp during the night in the settings of the thermostat so I'm guessing that it is coming from the software that's running on the RPi. If the esp TX is enabled it continuously toggles between 50° and 15°. That's why I disable TX in the evening as long as I'm not fully migrated to EMS-ESP (if I don't forget).

Here you can see it in a graph (orange line): So at 22:52 it changes from 50° to 15° and while the esp tx is enabled it toggles every minute. Around 23:15 I disabled tx on the esp.

proddy commented 4 years ago

ah ok. The telegrams holding the ww selected temperature value are 0x33 and 0xE9 and I expect you may be receiving both of them and they are conflicting. It's worth checking. Set watch on in the ems menu and then in the boiler menu do a read 33 and read e9 and see what comes back from these two types.

FredericMa commented 4 years ago

Ok, I did some monitoring during the toggling. The read 33 gives a reply but the read e9 doesn't seem to give a result. The read I did appear in the first 250 lines of the log file.

I checked when the toggling occurred and it happened around the 00:11:01 and 00:12:01 mark. It went from 15 to 50 and back to 15 after a 3-5 seconds. The same behavior can probably also be seen at every 00:xx:01 mark in the log.

ems-esp_debug_log_warm_water.txt

MichaelDvP commented 4 years ago

I think the graph was taken by the raspberry? There are two different temperatures, one called selected tempt from parameter-message and one called Settemp from Monitormessage. SelTemp is manual set at boiler and can be overrided by the thermostat program. I your case Seltemp is always 50°C and Settemp is always 15 (in night mode i think). ems-esp requestes the different messages and the raspi interpretes both as setpoint, changing when the different messages coming in. The monitormessage is also broadcasted by the boiler, the 15°C coming also without requesting.

000+00:10:04.121 N 279: [emsesp] Boiler(0x08) -> Me(0x0B), UBAParameterWW(0x33), data: 08 FF *32* 00 00 46 00 01 4B 00 FF FF 000+00:10:05.345 N 283: [emsesp] Boiler(0x08) -> All(0x00), UBAMonitorWW(0x34), data: *0F* 02 F8 02 F8 A1 00 00 03 00 00 46 04 00 03 1D 00

proddy commented 4 years ago

also from looking at all your log files, the selected temperature is always 50 degrees (from the 0x33 telegram). If it's switching every minute in the evening you can double check by trying and catch the change in the Telnet console. So wait until 11pm, go into the console, enable Tx and type show and see if it switches values every 30 seconds. Also note only the selected temperature is sent via MQTT, the set temperature is only displayed in the console.

MichaelDvP commented 4 years ago

Sorry, i described a bit unclear. I'll try to clearify: There is no switching of setpoint temperature. It is a misinterpretation of Norrberts Hometop, which only happens if emsesp is working in tx-mode.

Message 0x34 is broadcasted every minute, publishing the setpoint of 15°C in pos 0. The hometop shows settemp of 15 °C. Without ems-esp that's all. But now ems-esp comes into play...
Message 0x33 is not broadcasted, but with tx_mode active on ems-esp this message is requested every minute, In 0x33 there is the selTemp in pos2, which is always 50°C.
ems-esp shows stable selected Temp: 50°C, set Temp 15°C
Hometop shows setTemp 15°C after receiving message 0x34, but shows 50°C after receiving message 0x33.
both telegrams come in every minute but with a time difference of some seconds. Therefor on hometop it looks like the temperature is switching, but it's that hometop showing alternating two different temperatures.

FredericMa commented 4 years ago

I think the graph was taken by the raspberry?

Correct it is the MQTT data via grafana coming from the raspberry. The toggling indeed only happens on the raspberry (left ems-esp, right hometop):

I can also confirm that the values are shown as expected in ems-esp:

Warm Water selected temperature: 50°C
Warm Water set temperature: 15°C

If I understand correctly, during the night, no warm water heating will occur unless the temperature goes below 15°C?

Thanks for clarifying this!

FredericMa commented 4 years ago

A few other observations while trying to control via MQTT:

It looks like I can only control HC 1 at the moment. Topics like thermostat_cmd_temp1 and thermostat_cmd_temp2 don't seem to be available. Also the generic command only seems to work for HC 1.
The mode of the heating circuits always show manual or unknown while it is actually in "nofrost" or "heat" mode. It shows "unknown" after sending a command to change the mode and goes back to manual after a few seconds (I guess after receiving a message). I included a log and there you can see the change off mode on line 60 and 285. The thermostat shown mode "unknown" at 356 and 445. In all other cases it shows manual.

ems-esp_debug_log_3.txt

MichaelDvP commented 4 years ago

You can use the thermostat_cmd but the syntax has changed. {"hc":2,"cmd":"temp","data":21} or with nested commands {"hc1":{"temp":20},"hc2":{"temp":21,"nighttemp":17}}

MichaelDvP commented 4 years ago

Yes, the modes for Junkers are a bit mixed. I'll change it to fit Norberts list. If this is right, than your protocol shows: Start with manual - nofrost, at 2+12:08:25.35 it's manual - heat, at 2+12:08:53.155 again manual - nofrost

FredericMa commented 4 years ago

Yes, that's correct. Those are the 2 modes I use in OpenHAB at the moment. If you want I can also do a test with other modes if it helps.

FredericMa commented 4 years ago

Another thing I noticed is that if I execute the thermostat_cmd {"hc2":{"mode":"heat","heattemp":"21"}} doesn't set the temperature. The following does work for nofrost: {"hc2":{"mode":"nofrost","nofrosttemp":"16"}} EDIT: looks like it isn't listed this function: https://github.com/proddy/EMS-ESP/blob/b06f3eb41f5b50d17d32e82fa5f33df4fc2dd24c/src/devices/thermostat.cpp#L232

Are these temperatures written to the memory of the thermostat? At the moment I change the setpoint of the radiators circuit 1 regularly to not full throttle the boiler if I need only a small amount of heat for one room for example. If multiple rooms need heat, I increase the setpoint which also increases the Selected flow temperature. If this setpoint is also written to the nvram or other memory of the thermostat, it might not be a good idea to do this very often.

joanwa commented 4 years ago

* The two devices 0x20 and 0x21 are mixing units.  So this is your IPM. I'll add them to the database so they get recognized next time and then we can work on fine tuning the data. Luckily Nobert has mapped a lot of this information already for us.

hey @proddy could you please also add the IPM1 mixing unit to the v1 device list?

proddy commented 4 years ago

hey @proddy could you please also add the IPM1 mixing unit to the v1 device list?

that was added in a29 last week. doesn't it work?

joanwa commented 4 years ago

yes, in v2 it's added. I was talking about dev branch for a potential new v1 release. Also happy to send a PR

FredericMa commented 4 years ago

Last question before I'll close this issue since it's growing a bit out of control. I tested 2.0.0a31 and modes are displayed correctly and also setting heattemp works. Thanks!

One thing I noticed is that if I change modes, sometimes the mode becomes unknown and the mode type becomes day for a few seconds before showing the correct changed states. I attached a debug log in case you want to take a look at it. There is a good example that starts at line 1400. A short overview:

At line 1400 I set heating circuit 1 to nofrost and temp to 16.
I did a few fast show commands after each other and noticed that the circuit changes to nofrost immediately (line 1481).
At line 1646 it sudenly shows
```
Mode: unknown
Mode Type: day
```
At line 1958 it goes back to the correct state:
```
Mode: manual
Mode Type: nofrost
```

This is not really a show stopper for me since in the end the commands are executed correctly. Just wanted to let you guys know in case it is a bug.

ems-esp_debug_log_200701.txt

MichaelDvP commented 4 years ago

Oh, i see. In line 1590 we get: Rx: 90 00 FF 00 00 6F 01 01 00 96 00 F5 F3 34 00 E6 and all is ok, but in line 1593 we get a short telegram Rx: 90 00 FF 00 00 6F 01 C7 and here the CRC C7 is misinterpreted as unknown mode.

@proddy The boundary check in telegram.h read_value (line 107) and read_bitvalue (line 91) should be set to message_length - 1 to check against message without CRC.

FredericMa commented 4 years ago

So this short message influences both the mode and mode type? I would expect that one of both should remain correct if only the last byte if incorrectly handled?

MichaelDvP commented 4 years ago

Good that you ask, there is also a bug in Thermostat::HeatingCircuit::get_mode_type where mode is used instead of mode_type.

FredericMa commented 4 years ago

Everything seems to work just fine now. Thanks guys for your support!

proddy commented 4 years ago

great! That's all the good work Michael has been doing so all kudos to him

emsesp / EMS-ESP

(v2) Questions on my Junkers setup #410

telegrams received: 18260

read requests sent: 2537

write requests sent: 0

corrupted telegrams: 0 (0%)

tx fails (after 3 retries): 562