ems-esp is disabeling the internet interface (integrated / km200)

[tp1de]

When I connect to the ems-bus (by service jack) the km200 interface does not work anymore. So I can't access the heating system by App or Web-Interface anymore.

As far as I can recognize this happens when I restart the heating and the boiler / controller scans the bus for devices.
When the heating system is running and I connect on a running system, then everything is working fine and the km200 interface keeps running. At the end I want to connect hardwired to the ems-bus and when switching of for maintenance, the system including ems-esp should work stable. For the moment this is not secured. I feel that using the service jack address is bringing some problems as well. (....I am not sure...)

{
"System": {
"version": "2.1.0",
"uptime": "003+13:22:21.021",
"freemem": 44,
"fragmem": 5
},
"Settings": {
"enabled": "on",
"publish_time_boiler": 10,
"publish_time_thermostat": 10,
"publish_time_solar": 0,
"publish_time_mixer": 10,
"publish_time_other": 0,
"publish_time_sensor": 10,
"mqtt_format": 2,
"mqtt_qos": 0,
"mqtt_retain": "on",
"tx_mode": 2,
"ems_bus_id": 15,
"master_thermostat": 0,
"rx_gpio": 13,
"tx_gpio": 15,
"dallas_gpio": 14,
"dallas_parasite": "off",
"led_gpio": 2,
"hide_led": "off",
"api_enabled": "off",
"bool_format": 1,
"analog_enabled": "off"
},
"Status": {
"bus": "connected",
"bus protocol": "Buderus",
"#telegrams received": 926224,
"#read requests sent": 56359,
"#write requests sent": 0,
"#incomplete telegrams": 12,
"#tx fails": 3,
"rx line quality": 100,
"tx line quality": 99,
"#MQTT publish fails": 0,
"#dallas sensors": 0
},
"Devices": [
{
"type": "Boiler",
"name": "Buderus GB125/Logamatic MC110 (DeviceID:0x08 ProductID:133, Version:01.44)",
"handlers": "0x10 0x11 0x14 0x15 0x16 0x18 0x19 0x1A 0x1C 0x2A 0x33 0x34 0x35 0xD1 0xE3 0xE4 0xE5 0xE6 0xE9 0xEA"
},
{
"type": "Thermostat",
"name": "RC300/RC310/Moduline 3000/1010H/CW400/Sense II (DeviceID:0x10, ProductID:158, Version:18.03)",
"handlers": "0xA3 0x06 0xA2 0x2A5 0x2B9 0x2AF 0x2A6 0x2BA 0x2B0 0x2A7 0x2BB 0x2B1 0x2A8 0x2BC 0x2B2 0x2F5 0x31B 0x31D 0x31E 0x23A 0x267 0x240"
},
{
"type": "Mixer",
"name": "MM100 (DeviceID:0x21, ProductID:160, Version:24.05)",
"handlers": "0x2D8"
},
{
"type": "Gateway",
"name": "KM200/MB LAN 2 (DeviceID:0x48, ProductID:189, Version:04.07)",
"handlers": ""
},
{
"type": "Controller",
"name": null,
"handlers": ""
}
]
}

[proddy]

This problem rings a bell, think we've seen it before. Need to refresh my memory.

[tp1de]

In general I would recommend to implement a "waiting time / start delay" when restarting the wemos before scanning the bus (1-2 minutes). I had similar problems while restarting that my mm100 mixer went into error state (led blinking).

There might be interferences with the controller ems-bus scan when restarting and the ems-esp interface when running same time.

[MichaelDvP]

Is there a special reason why you use

"ems_bus_id": 15,

This is a clock-module and maybe the KM200 tries to request a time from it.
If you change to standard 11 (service-key) does it give the same issue?
Do you have a log (with watch) from the blocked start?

[tp1de]

I started with standard 11 (service key) but had problems with mm100 module running into error state (led blinking) and errors displayed in RC310. With other id's this did not happen ... but I will test again with this new development version.

Do you have a log (with watch) from the blocked start?

How shall I watch on hardware reset?

[tp1de]

By the way:

A scan devices

kills the ems-esp interface working (error state) and my Buderus heating is in error state and needs a hardware reset.

[tp1de]

So I tried different bus id's. Same behavior independent from the id:

When ems-esp is connected while restarting heating (including bus scan) then km200 internet gateway is disabled.
When connected after bus scan, then km200 is working fine.

[proddy]

@tp1de what do you mean by "bus scan". Are you manually hitting the 'SCAN DEVICES" button in the web UI? Why?

[tp1de]

Just by instance in the web UI driven by curiosity while have ems-esp newly bought.
Any ems-bus scan seems to produce some trouble. Either initiated by the heating device (by switching on e.g. after maintenance) or by the web UI.

[bartplessers]

same over here.
Hardware:

• Buderus GB192iT40
• RC310 thermostat
• KM200 gateway
• EMS-ESP v2.1.0

From time to time, I can not use the app connected to the gateway.
Seems that rebooting the ems on a running boiler induces this problem, but I'm not sure.

kind regards,
Bart

[proddy]

when EMS-ESP starts it sends one message to the UBAMaster (boiler on device ID 0x08) requesting a telegram which shows us which other devices have been registered on the EMS bus. Then for each device we send a Tx telegram asking it for more details (which is where we get the version number and product ID). We can try excluding the KM200 gateway from this batch of requests and see if that helps?

[tp1de]

I believe that we should try to exclude KM200 gateway (0x48) from batch request. I would like to test this.
Next to the km200 problematic I have for the moment some additional severe stability problems with the mm100 mixer as well.

Actually the EMS-ESP looses connection to ems-bus every 3-4 days. Then the led on the mm100 (0x21) is blinking and a heating device failure is displayed on my RC310 Thermostat. Floorheating circuit (hc2) is not working anymore ! Sometimes while trying to reconnect to WEB-UI a reboot of the EMS-ESP device takes place. Seems to be a software stability problem. Could it be related to the mqtt interface to my mqtt server?

A restart from WEB-UI does not solve the problem to reconnect ems-bus again. While disconnecting the hardware from service jack and then reconnecting, it works again. Should the restart option from WEB-UI not be the same as the hardware reset? (rebooting the device). While uploading the firmware again by WEB-UI the restart works fine as well (connected to ems bus). Just a restart does not be the same.

Nevertheless the EMS-ESP should not stop my heating system (hc2) every 4-5 days. How could I help to debug?
For the moment I disconnected the device to have my central heating operating stable.

[bartplessers]

Hi,

Situation:

• ems + mqtt + homeassistant --> ok
• gateway --> app NOT working

Now I rebooted gateway: unplugged service jack, waited few seconds and plugged in again.

• ems + mqtt + hass --> ok
• gateway + app --> ok

I will keep an eye on it for the next days.

Kind regars
Bart

[glitter-ball]

Plugging and unplugging the service jack with the boiler live can short the EMS bus - may not be relevant to this problem but worth knowing.

I did it once and it caused my thermostat to cold start, presumably because it lost power due to the short. Now I'll only connect and disconnect EMS-ESP with the boiler off (which also cold starts the thermostat, but at least it isn't shorting the bus out!)

A quick short is probably OK and Bosch must have known this would happen with a 3.5mm jack plug but you might want to avoid it.

[tp1de]

To add some more findings:

1. Yes I have the same experience as Bart: EMS-ESP must be connected some 30 seconds after start of heating system
2. I connected the EMS-ESP to USB-power and the ems-cable to the mm100 mixer, so that it keeps up running when restarting the heating system
3. The disabling of some parts of the internet interface (heating circuits / warm water) stays the same.
   Some other data is still transferred by the km200 web interface -> system preasure and temp

I might believe that the scan of the ems-bus by the master controller (mc110) is disabling km200.
Is EMS-ESP answering to the poll request of the master controller? How?
Could this be the reason for the km200 problems?

Best regards
Thomas

[proddy]

@tp1de if you're comfortable with building the firmware from source we can try and few things out, like tracing the polls and blocking the bus scan on startup. One method is to compile with the -DEMSESP_DEBUG flag set and set logging to trace and use a syslog server to see what is happening. Or if you have an ESP32 it'll be about 10 times easier to debug. Let me know and I'll help

[tp1de]

@proddy since I am retired I am fine to spend quite some time for debugging and hopefully adding more functionality. I just need some help how to do the firmware building from source and how to do the debugging. The ESP8266 is new for me since I used Raspberry PI's or VM's before.

I do have the BBQKees EMS-gateway with the wemos board (ESP8266) since 2 weeks because I came to limitations with the km200 interface for my homeautomation system (ioBroker). It is important for me to use both in parallel and to keep it longtime stable working.

Just tell me what to do ...

[MichaelDvP]

Just tell me what to do ...

Only to analyse what's blocking, use a syslog server and connect ems-esp to this server with syslog-setting log all.
And post the logs here.

To build the firmware: https://emsesp.github.io/docs/#/Building-firmware

To try a delay on startup for the ems-bus activity you can add in emsesp.cpp line 926 after the if (length == 1) {

       // first send after 60 sec
        if (uuid::get_uptime_ms() < 60000ULL) {
           return;
        }

[tp1de]

I switched off my heating system. The EMS-ESP kept on running powered by USB.
I then switched on syslog-setting to all and after a few seconds I started the heating system again.
EMS-ESP kept running and was the whole time connected to the ems-bus.

I tried to connect to km200 web interface - connection itself was succesfull but no data available and some error messages were shown. I then ended syslog-setting. But when trying to reconnect to EMS-ESP a reboot of the EMS-ESP gateway took place.

When restarting the heating without EMS-ESP beeing powered up everything waorked fine. Connecting the gateway some 1-2 minutes later.

Here is the syslog of the startup-procedure out of my synology diskstation syslog server:

All_2020-12-1-17 2 13.zip

[MichaelDvP]

If you switch ems-esp to tx_mode 0, only listening, is the KM200 than accessible?

[tp1de]

with tx_mode 0 km200 is working but:

In dashboad recieved telegrams are shown - but no devices !
After a while WEB-UI is not accessible anymore and blue led is blinking.

A hard reset does not work.

[tp1de]

Some new findings:

The km200 internet gateway itself does not seems to be the problem. The gateway is accessible and data like boiler temp, pressure etc is provided. Just all data from heating circuits and ww circuit is not available. This data comes from RC310 thermostat. The communication between gateway (0x48) and thermostat (0x10) seems to be blocked.

Going into the installers menu on the RC310 and starting a new configuration scan makes the km200 working again.
Somehow the presence of the ems-esp disturbes the communication between km200 and rc310.
Any idea why?

[MichaelDvP]

Too many clients on the ems-bus? Bad bus-topologie? Just a guess.

[tp1de]

I don't believe .... just the boiler with master controller, mm100 mixer 1 m distance and rc300 Thermostat with 3-4 m cable distance.
Gateway was in service jack now with 1m cable connected to ems-out on the mm100. This is not a bus topology problem.

Too many telegrams per time send by the ems-esp gateway that blocked communication during startup?

[bartplessers]

I will keep an eye on it for the next days.

Kind regars
Bart

Small update: everthing keeps running for now, but noticed in HomeAssistant that "set temperature" is not displayed anymore:

Regards,
Bart

[proddy]

@bartplessers could you do a http://ems-esp/api?device=thermostat&cmd=info

[proddy]

@tp1de

with tx_mode 0 km200 is working but:

In dashboad recieved telegrams are shown - but no devices !
After a while WEB-UI is not accessible anymore and blue led is blinking.

A hard reset does not work.

a TxMode of zero prevents any Tx traffic being sent out, and we need to send version requests to the Master to find out which devices are on the bus. This is why you'll see no devices.

Are you able to compile the code yourself? If so I can suggest some lines to change to see what is causing the interference with the km200 gateway

[bartplessers]

@bartplessers could you do a http://ems-esp/api?device=thermostat&cmd=info

[proddy]

wow, that was quick (and fancy!). I'll create a new bug for this - don't think it has anything to do the km200.

[tp1de]

I kept EMS_BUS_TIMEOUT unchanged. And did the coding changes.

IT IS WORKING AS EXPECTED ! After 30 secs EMS-Bus is disconnected when heating is powered off and any restart of the heating system and / or the gateway has a delay of 60 secs for tx telegrams
KM200 problems are solved

Coding in emsesp.cpp is now from line 923 onwards: (correct?)

static uint64_t delayed_tx_start_ = 0;
// check for poll
 if (length == 1) {
        if (!rxservice_.bus_connected()) {
            delayed_tx_start_ = uuid::get_uptime_ms();
        }
        //EMSbus::last_bus_activity(uuid::get_uptime()); // set the flag indication the EMS bus is active
        if ((first_value ^ 0x80 ^ rxservice_.ems_mask()) == txservice_.ems_bus_id()) {
            EMSbus::last_bus_activity(uuid::get_uptime()); // set the flag indication the EMS bus is active
        }
        // first send delay 60 sec after connect
        if (uuid::get_uptime_ms() - delayed_tx_start_ < 60000ULL) {
            return;
        }

Are you adding this to the standard coding (new dev version)?

Topic can be closed.

[MichaelDvP]

I'll set an option to the setting page for a user defined delayed tx-start ( 0 - 120 sec) in beta after new release.
(see https://github.com/proddy/EMS-ESP/issues/632#issuecomment-738741849)

@bartplessers and other KM200 owners: if you need a binary in advance, tell us.

[MichaelDvP]

@tp1de thanks for your help and tests, i added a tx-delay-setting to b7 settings page.
@bartplessers can you check with your KM200 if this is a general solution.

[tp1de]

@MichaelDvP
I was not sure if the b7 bin file has all changes included. So I downloaded from your github directory and compiled myself. All working just b6 shown in web ui.

I may recommend to set initial tx delay to 60 secs in settings.

[bartplessers]

@MichaelDvP :

• currently running EMS-ESP v2.1.1b7
• TX delayed start: 60 seconds
• repowered my whole installation

for now, everything looks fine.
I will keep an eye on this and keep you informed.

CORRECTION:

• for some reason: no EMS devices found

• thermostat is not found anymore

• Bad Rx line quality
  

So I'm in some kind of trouble here...

[bartplessers]

addendum:

• running EMS-ESP v2.1.1b7
• TX delayed start --> back to 0 seconds
• rebooted ems-espx (NOT my whole installation, only esm-esp)

Now:

• devices found again
  

• API is working again
  

• Buderus app NOT working yet (no current temp, no schedule):

[MichaelDvP]

"No EMS device found" will disappear after the tx-delay. Without tx the devices can not be found (only if device is sending it's version information). If you set a delay you have to be patiently.

[tp1de]

I am a little confused what you have done in what sequence. A reboot of ems-esp does not have any influence on km200 internet gateway. The gateway is blocked when the boiler restarts after beeing powered off and scans for devices and ems-esp sends tx telegrams during this time (within the first minute).

The internet gateway needs about 5-7 minutes to send the data to the buderus server.
Have you waited long enough?

[bartplessers]

1
"No EMS device found" will disappear after the tx-delay.
I definitly waited longer than 60 seconds.

2
The internet gateway needs about 5-7 minutes to send the data to the buderus server.
I did another test: rebooted the whole system without ems-esp attached.
Everything (including buderus app) worked fine within a minute.

On this test I attached the ems-esp AFTERWARDS. To be clear:

1. power off everything
2. power on boiler (thermostat, gateway and external sensor attached)
3. waited +/-1 minute
4. attached bbqkees ems-esp device

Everythings works fine now

• Rx/Tx: good quality
• buderus app works fine
• mqtt + hass works fine

So in my experience: the Tx delay does not have the same impact as starting the ems-esp device.

Some other thing: since I use ems-esp I do have an error on my thermostat on regulary base:

According to documentation this has something to do with external temp sensor, but I doubt that: I checked the connections and the installation is brand new.
Maybe there is some interference between some devices?

If I can be of any help to debug this: just tell me what to do.

kind regards,
Bart

[tp1de]

Do you still have connected the ems-esp to the thermostat?

I got similar messages when I connected to my mm100 mixer without usb power supply. The MM100 was in error mode (led blinking) and same message (just in German)

[bartplessers]

indeed. ems-esp connected directly to thermostat

You think this will be a power issue? Should I try USB powering the device?

[tp1de]

YES try USB powering
Without usb power it works for me only if connected to service jack - which I do not want.
Without USB power I have the same errors on ems bus and same messages on the display.

[bartplessers]

Is it worth trying the other EMS bus? I have an orange one (attached to the thermostat) and a white one (unused). Or are they internally connected to the same power supply?

[tp1de]

Additionally I got longterm stability problems with the wemos d1 mini board (esp8266) and bought an esp32 d1 mini board.
SInce then everything is fine and stable.

[MichaelDvP]

@bartplessers: You have connected ems-esp to the orange connector as split connection with thermostat, there is another unused white bus-connector on the lower end, I think it's also worth trying that.

[tp1de]

try it but I had 2 as well and I used ems out which should be powered. It worked but not longterm. All of us should have some old usb adapters.

[bartplessers]

Okay,

new test:

• TX delayed start --> 0 seconds
• power down
• ems-esp connected to OTHER bus now
• power up

findings

• ems-esp starts, but I think it reboots again after a minute or so. maybe underpowered? I noticed that "system uptime" did not correspond with the time I powerd everything up
• after "a while" (+/- 2 minutes) --> every device is discovered on dashboard
• Rx/Tx quality fairly good (80%/98%)
• buderus app working
• still an error message on Thermostat

I will let it like this for few minutes/hours/days, but will keep an eye on it and keep you posted.

regards,
B

[bartplessers]

FYI:

• had same error message on themostat again (A11/1037)
• added external USB power now (2.5A)

hopefully error message will dissapear

@tp1de
I got longterm stability problems with the wemos d1 mini board (esp8266) and bought an esp32 d1 mini board.
On the documentation of ems-esp, you can find on the first page:

• Note, EMS-ESP requires a small hardware circuit that can convert the EMS bus data to be read by the microcontroller. These can be ordered at https://bbqkees-electronics.nl.

...what I did (it's a esp8266 board)

Is the esp32 more powerfull? Are there somewhere instructions how to connect/flash/... that board with ems-esp?

B

[tp1de]

I bought 4 weeks ago the same gateway and had system crashes while using web api and mqtt too heavily. So I bought on Amazon a new esp32 board for 9 Euro delivered next day #649
Flashing with platformio based on source code compiled.

But look if you have similar problems

[bartplessers]

Okay,
some new interesting testresults here:

• I tested alread all kind of power options on my esp-ems:
  • jack
  • ems bus 1
  • ems bus 2
  • ems bus 2 + external USB power 2.5A

none of the above solutions worked perfectly. Most of the time, my thermostat went into an error mode.

But now:

• I unplugged my KM100 gateway and rebooted my system
• NO errors anymore since that point in time (18:13)!
• modulation is more stable (see also issue https://github.com/proddy/EMS-ESP/issues/656 )

(1) with KM100 attached
(2) without KM100

So my conclusion (for now :-) ) :
there is some interference between my KM100 and ems-esp, and it's not a power-related problem.

If I can be of any help by debugging this issue, let me know.

kind regards,
B

PS.
@tp1de : I will order also an esp32 module to see what happens.

[bartplessers]

some update

• system running without KM100 now for +/- 18h (since 2020-12-11 18:17)

• Rx/Tx rates are perfect (100%)
  

• Boiler power consumption is much more stable
  

(1) start boiler
(2) turned down temperature from 21.5 --> 21.0. Power drops to 0% and boiler starts a little bit later to keep temp at 21
(3) temp set to 17
(4) automatic start, temp set to 21
(5) automatic stop, temp set to 17
(6) manual start, temp set to 21
(7) shower
(8) maintenance to keep temp at 21

Compare to statistics at left side of green line!

[proddy]

@bartplessers still running ok?

[bartplessers]

@proddy
yup, thanx for asking!
Everything working fine now.
So, as mentioned in "nervous modulation" #656, my problems were probably a result of underpowered device.

If you want more analysis, I'm willing to uncouple usb-power again and do test again with latest firmware (running EMS-ESP v2.2.0 now) and powerd by EMS-bus.

kind regards,
Bart

[proddy]

ok, @tp1de I'm closing this issue now as looks like we have a workaround for the KM200. Let us know how you get on with the ESP32 version.

[tp1de]

@proddy my ESP32 Version is working 100% stable without any problems. The km200 problems were solved with the delayed start of tx telegrams. The stability problems with underpowered device are still existing when I go back to ems-bus powering other then service jack. USB powering is 100% stable and a good alternative. Anyhow it is an advantage for me if the ems-esp gateway stays alive when maintenance on the boiler is done ...
OK to close.

[proddy]

thanks @tp1de . I'm working on a revised version of EMS-ESP that is optimized for the ESP-32 and hopefully can be powered via the EMS bus lines. It'll take some time though as it requires both software and hardware tweaking.