emsesp / EMS-ESP

ESP8266 firmware to read and control EMS and Heatronic compatible equipment such as boilers, thermostats, solar modules, and heat pumps
https://emsesp.github.io/docs
GNU Lesser General Public License v3.0
303 stars 97 forks source link

Include MM200 module #299

Closed PhillyGilly closed 4 years ago

PhillyGilly commented 4 years ago

With the encouragement of @MichaelDvP in issue #270 I decided to try to commission my Bosch MM200 module.

In testing I had the module configured with the selector dials set to positions 1 and 2, and the MM200 was recognised as: Mixing Module: MM200 Mixing Module (DeviceID:0x20 ProductID:161 Version:29.04) Mixing Module: MM200 Mixing Module (DeviceID:0x21 ProductID:161 Version:29.04) and the EMS-ESP returned a json like: {"hc1":{"flowTemp":23,"pumpMod":0,"valveStatus":0},"hc2":{"flowTemp":37.5,"pumpMod":0}}

However when I configured the module with the selector dials set to positions 9 and 10 image t is recognised as: Mixing Module: MM200 Mixing Module (DeviceID:0x28 ProductID:161 Version:29.04) Mixing Module: MM200 Mixing Module (DeviceID:0x29 ProductID:161 Version:29.04) but there is no returned data.

Here is a copy of my telnet: shortlog14012019.txt

Would it be possible to return dhw1 and dhw2 data-sets for cylinder temperature, valve (pump?) status, operation, etc?

proddy commented 4 years ago

did you ever get data back from the MM200? I see it uses different telegram types, 0x231, 0x232 instead of 0x1D7, 0x1D8:

type 0x0232, telegram: A9 00 FF 00 02 32 02 6C 00 3C 00 3C 3C 46 02 03 03 00 3C 
type 0x0231, telegram: A8 00 FF 00 02 31 02 35 00 3C 00 3C 3C 46 02 03 03 00 3C

and comparing to what I would expect from a MM100 I get valve status at 2, so 0x00 flowtemp at 3 so 0x3C00 pumpmod at 5 so 0x3C

which looks odd

PhillyGilly commented 4 years ago

I have't got the detail of the MM10 telegram but comparing the 0x0231 with the SM200 telegrams where there are two byte temperatures, one byte temperatures, and one byte status data, this is what I can see: image

(I am numbering left to right starting at zero)

MichaelDvP commented 4 years ago

I found a MM200 manual at https://www.buderus.de/de/technische-dokumentation?query=MM200&searchType=query Two warm water circuits are only in a complex system on page 41, but i have a little idea how it works.
In telegram 0x34 the boiler says he has no WW: (19:45:51) UBAMaster -> All, type 0x34, telegram: 88 00 34 08 00 (CRC=88) #data=1 and 0x33 no WW on boiler, 60 C (0x3C) Setpoint, 70°C (0x46) desinfection. (19:45:54) UBAMaster -> Mixing Module, type 0x33, telegram: 88 29 33 00 00 FF 3C FB 00 28 00 00 46 00 FF (CRC=61) #data=11 Now in 0x0232 we find many 0x3C and one 0x46 and in position 0 something looks like the WW-temperature: 026C -> 62.0 °C and 0235 -> 56.5°C for telegram 0x0231. (19:45:55) Mixing Module -> All, type 0x0232, telegram: A9 00 FF 00 02 32 02 6C 00 3C 00 3C 3C 46 02 03 03 00 3C (CRC=57) #data=13 Maybe it's sufficient to take only the temperatures from telegrams 0x0231 and 0x232, the setpoint is already in 0x33. I see that also the solar module talks to the mixer: (19:45:47) Solar Module -> Mixing Module, type 0x0245, telegram: B0 28 FF 00 02 45 64 01 01 (CRC=36) #data=3 the 0x64 in pos 0 could be an pump command 100% flow. @PhillyGilly Check what changes if you change the setpoint, check when the pump starts and serch this time in log, than you can indentify the right position of values in the telegram.

PhillyGilly commented 4 years ago

Hello @MichaelDvP . Thank you for your help. The MM200 isn't sold in the UK (probably too complicated for the average plumber, and certainly too complicated for Worcester-Bosch UK!!) I have the manual (leider nür auf Deutsche) that came with the unit I imported form Germany and the nearest configuration is shown as the left MM200 in Figure 31.

Are the 0x33 telegrammes showing that my overall system is configured with HC1 connected to the boiler and WW1 and WW2 connected to the module? I don't know why the SM200 is talking to the MM200 as the Solar system isn't configured to know that there is a boiler too.

I think you right that 0x0231 and 0x0232 will be enough monitor the module. Here are the results of the tests you suggested. image

In summary: The temperature in the cylinder (B6&7) rises until it reaches the setpoint (B11). The gas burner switches off and temperature status (B17) goes from 1 to 2 and the Pump run down period of three minutes starts. At the end of the pump rundown Pump status (B8 and B15) change and temperature status (B17) goes to 0.

So it would be perfect if the EMS-ESP could generate Json containing B6&7, B17, and B15 to represent cylinder temperature, temperature status, and pump status for hw1 and hw2.

[note: the temperature over-run is due to the fact that cylinders 1 and 2 are still wired to operate in parallel. The purpose of fitting the MM200 is to get independent operation. That should be achieved shortly.]
The Data for both HW circuits are in this spreadsheet. MM200analysis.xlsx

MichaelDvP commented 4 years ago

@PhillyGilly the MM100 manual have a few more languages. https://webservices.buderus.at/download/pdf/file/6720813621.pdf page 106, fig. 27 shows a identical configuration with two MM100 instead of MM200.

I think the measured temperature is clearly located, B17 as a status probably. 8 could be a bit-field, but which is the pump, and what is the other. for the values of 15 i have no idea. I have tried a modfication of 1.95b17 for the mixer. Test at your own risk. If it works i'll make a pr.

EMS-ESP-1_9_5b17m-d1_mini.zip

PhillyGilly commented 4 years ago

@MichaelDvP Thank you for both. I’ll try it and report back.

PhillyGilly commented 4 years ago

1.9.5b17m loaded and running: image also: image

As you can see l am recieving Json: mixing_data { "wwc1":{"flowTemp":42.1,"pumpMod":6,"tempStatus":1}, "wwc2":{"flowTemp":37.4,"pumpMod":6,"tempStatus":1} }

That's great. Now the element names aren't critical as I can change them in HA, but:

image

Before you move this to a pr, I would like to look at the differences between the configuration on page 16 of the MM100 installation manual and seite 6 of the MM200 Installationsanleitung. For my set up it looks like using TW1 and VC1 might actually be better but I don't know if that is feasible. I will have to try changing the wiring

MichaelDvP commented 4 years ago

@PhillyGilly Can you please also check the output of terminal and mqtt for different switch-settings. Only mixing circuits (1+2), mixing and water (2+9 or 1+10, ...), and water (9+10). Pos 3, 4 will not work, proddy has prepared for it, but not fully implemented. If you want to check, i'll complete it. I think the naming should fit in proddys concept, it's always "warm water" cut to ww not DHW. Suggestion: mqtt: wwc1: wwTemp, pumpeStatus, tempStatus Terminal: Warm Water Circuit %d, Current warm water temperature, Current pump status, Current temp status.

proddy commented 4 years ago

@MichaelDvP @PhillyGilly I've been following your work, it's awesome and great to see others expanding the functionality. Let me know if you need any help.

PhillyGilly commented 4 years ago

@PhillyGilly Can you please also check the output of terminal and mqtt for different switch-settings. Only mixing circuits (1+2), mixing and water (2+9 or 1+10, ...), and water (9+10). Pos 3, 4 will not work, proddy has prepared for it, but not fully implemented. If you want to check, i'll complete it. I think the naming should fit in proddys concept, it's always "warm water" cut to ww not DHW. Suggestion: mqtt: wwc1: wwTemp, pumpeStatus, tempStatus Terminal: Warm Water Circuit %d, Current warm water temperature, Current pump status, Current temp status.

Regarding naming: Absolutely fine to use ww for the abbreviation. BTW most of the Bosch codes are the initials of English words, but ww is short for Warmwasser. This can cause a bit of confusion to English speakers as in English warm means not hot. That is why we say DHW (domestic hot water). Can we stick with pumpStatus as before (no 'e' like your release version 1.9.5b17m) So: mqtt: wwc1: wwTemp, pumpStatus, tempStatus Terminal: ww Circuit %d, Current ww temperature, Current pump status, Current temp status.

Regarding testing: Obviously the MM200 won't work with the coding card switches set to values that don't reflect what's wired and installed, but I think that it sends some EMS telegrams is how I got the mqtt in that I posted in #270 {"hc1":{"flowTemp":23,"pumpMod":0,"valveStatus":0},"hc2":{"flowTemp":37.5,"pumpMod":0}} I think that was with switches set at 1+2.

Is this the kind of test that you want?

  1. Use control system to0 set all hc and ww demand to off.
  2. Power MM200 down. Set coding card switches (to 1+2, 1+10, or 2+9),
  3. Set up a log v
  4. Power MM200 up.
  5. Watch switches go solid green
  6. Wait 2 min or until switches start flashing green.
  7. Set log n
  8. Loop to step 2 for next set of switch values.
PhillyGilly commented 4 years ago

Quick test results: 19012020.txt

MichaelDvP commented 4 years ago

Oh, you have 2 MM200. Timestamp:08:31:08 Topic:mixing_data Payload:{"hc1":{"flowTemp":50.6,"pumpMod":0,"valveStatus":0},"hc2":{"flowTemp":39 .5,"pumpMod":30,"valveStatus":0},"wwc1":{"flowTemp":50.7,"pumpMod":0,"tempStatus":0},"wwc2":{"flowTemp":39.5,"pumpMod":6 ,"tempStatus":1}} looks as expected. Can you please also post the teminal output for the info command.

PhillyGilly commented 4 years ago

No I only have one MM200 but it looks like the EMS-ESP (or possibly the Sense II) remembers devices. I will run some tests again and power cycle the EMS-ESP between tests and also capture the info.

proddy commented 4 years ago

the MM200 is subscribing itself to the EMS bus on two device IDs, 0x28 and 0x29 as seen in devices. Not sure why. But this is why they are both included.

MichaelDvP commented 4 years ago

@PhillyGilly ok, i see, you have started with pos 9/10 and MM200 has device IDs 28/29 with messages 0231 and 0232, then you switched pos10 to pos2 and MM200 changed ID29 to ID21. EMS-ESP detects a new MM200 with message 01d8 for hc2. The same when you switched pos9 to pos1, it appears a 4. mixer with ID20 and message 01d7. You have to restart or maybe a autodetect command will do to clear the devicelist. But it's nice to see that json is right with two hc and two wwc.

PhillyGilly commented 4 years ago

the MM200 is subscribing itself to the EMS bus on two device IDs, 0x28 and 0x29 as seen in devices. Not sure why. But this is why they are both included. The MM200 is essentially two MM100 devices in one box so each of the MM100s is subscribing on its own address. the addresses relate to the code carding switches on the module where 01 = address 0x20 through to position 10 = address 0x29.
Here is the results of my last test.
0102.txt I set the code carding switches to 1 + 2 and ran autodetect but the MM200 is still reporting wW values, however they're all good :-). The info is reporting all mixing data on one address. Should it be two? It may be that longer testing possible including reconfiguring the system from my Sense II would produce better results, but I can't run any more tests with heating off right now.

MichaelDvP commented 4 years ago

@PhillyGilly the autodetect only clears the device list, but not values that have been retrieved before. The now missing devices will not change the values anymore. You have to do a restart to init all values and detect the devices. The mentioned single MM device in info is wrong. The existing MM100 code assumes a single mixer-device with up to 4 circuits, like thermostat or solar. But the MM200 mixer work as two devices with each one channel. The data structure has to be changed to show the different devices instead of circuits. For now i have changed the naming and merged to proddys 1.9.5b18. Please check the info after restart if only the active circuits are displayed. EMS-ESP-1_9_5b18m-d1_mini.zip

PhillyGilly commented 4 years ago

Looks good to me: log22012020.txt MM200YAML.txt

image

FWIW I am having increasing trouble getting the web Interface to load. It either does not arrive or the screen appears but log in box fails to appear. I got lucky this morning and managed to upload your firmware. (I have got espota.py so I'm not stuck irrevocably.)

proddy commented 4 years ago

@PhillyGilly I actually hate the web interface. I am working on a re-write but my available time is short.

PhillyGilly commented 4 years ago

@proddy Appreciate the comment about web interface. I'm looking forward to 1.9.6 with @MichaelDvP latest code merge :-)

MichaelDvP commented 4 years ago

@PhillyGilly: proddy has merged my suggestions to 1.9.5b22. @proddy: afair the problem of web-interface is mainly the authentication. Do you really need it? Telnet is open and i think espota too and noone will open the interface to the internet (imho). Is there an easy way to disable authentication?

PhillyGilly commented 4 years ago

@MichaelDvP my experience is that I get the log in pop-up the first time I open the browser after a re-boot. If I close the browser tab, the next time I try to log in, most times the pop-up doesn't appear. As the device is on a private network logging in serves no purpose and I haven't even bothered changing the default password. If removing the security is a quick fix, that might buy time before a Web front-end re-create.

proddy commented 4 years ago

i would just forget the web and use espota. It's only two commands you need to copy & paste each time to upload the firmware. https://emsesp.github.io/docs/#/Uploading-firmware?id=via-ota-over-the-air

PhillyGilly commented 4 years ago

@PhillyGilly: @proddy has merged my suggestions to 1.9.5b22. Installed and running. Thank you.

PhillyGilly commented 4 years ago

@proddy I thnk this one can be closed too.