nervous modulation about ems-esp32

[bbqkees]

@bartplessers @MichaelDvP I did add a note in the wiki a while ago about removing the jumper for USB power.
But I just noticed that although I ran a build of the updated wiki on my machine at the time, I did not upload it to the server. So doing that just now.

With the Wemos D1 Mini board there is no way to detect on the Gateway board if the USB is plugged in so I could not auto-disconnect the bus power supply via f.i. a MOSFET.

Indeed the highest voltage source usually delivers all power. In all but the latest batch of Gateways the voltage regulator of the board was set to 5,2V to provide a bit of headroom. But the voltage of USB on the Wemos board is 4,7V (there is a diode in the USB line on the Wemos board).
So this combination means that if you plugin a USB adapter to the Wemos and if the jumper is set to bus power, the bus power side will still power most or all of the Wemos.
On the last batch the voltage was decreased from 5,2V to 4,5V.

[tp1de]

This is a hydraulic problem, that the heat out of the boiler can not be transported fast enough to the room radiators. I have the same components but a floorstanding boiler with 22KW KB192i 22. I heat 2 houses with 250 sqm and 22 KW is still too much. I limited the heating power to 60% and the waiting time to 30 minutes.
Buderus boilers start with approx 50% modulation for 2-3 minutes .... in your case 15 KW.
Try to increase the pump power if possible. Do you have a mixer for floor heating?

[tp1de]

In your case I would recommend to start with max 50% heating power unless you have a more then 250 sqm house.

[glitter-ball]

As @tp1de says, it's because the heat demand of your system is less than the minimum output of the boiler. Limiting the maximum output might help a bit. But... my burner lights at 100% and then ramps down quickly before coming up slowly to the required value. Sometimes the 100% start is enough for the flow temperature to pass the setpoint by +4ºC, so the burner shuts down.

Other things to try:

• Increase pump speed
• Set boiler time/temperature hysteresis - mine is set to 10 minutes / 10ºC before the burner is allowed to fire again
• Wait for colder weather... Below about 7ºC outside, my boiler doesn't have the problem because heat losses are bigger

The spike at 18:50 is a problem one. 17:00 and 18:30 are hot water demand. Other peaks are heating - 100% spike at start as boiler fires, then it ramps down to 30%, ramps up to target flow temperature and then back down to 30% as flow temperature reached. When flow exceeds setpoint by 4ºC, the burner cuts out.

[bartplessers]

Hi @glitter-ball ,
thanx for sharing your graph. Very interesting!

In emsesp/EMS-ESP#628 you can see I'm currently struggling with my ems-esp setup.
I have both an KM100 and ems-esp gateway connected.
However, just discovered that unplugging the KM100 gives me a much more stable behaviour:

(1) with KM100
(2) without KM100

It's still to early to draw some serious conclusions, but if my curve will be more like yours, than this has nothing to do with heat demands, but more with interference KM100/ems-esp. That was in fact also the reason why I started this post :-)

I will leave my installation now like this, and see what happens.

Thanx again for sharing your experiences!
B

[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!

[glitter-ball]

That's weird - don't understand why the km100 is changing the behaviour unless it's causing some issue with the bus or the boiler or thermostat to crash. The actual and target flow temperatures out of ems-esp are also very useful on a separate graph. You can then see what the system is trying to achieve and then check the boiler's response to it. It would also show whether the burner is cutting out because the flow temperature is too high (i.e. heating load too small) or whether there's another problem here.

[tp1de]

I can't confirm depedencies on the internet gateway. The km100 is a seperat gateway module powered by ems-bus. The km200 has a seperate power supply and more connectivity. I think that km100 and ems-esp together consume too much power on the ems-bus. Try usb power on the ems-esp gateway.

[bartplessers]

Hi @tp1de : I already used an external usb power supply 2.5A. No improvement then.

Ofcourse, there can also be some problem with the KM100...

But I do more believe in the track of interference on the bus.
I will try to setup a syslog to have more logging.

Is there something other I can do?

Grtz
B

[tp1de]

Do you have a seperate km100 gateway? (Or the integrated version?)
How old?

Are the modulation problems still existing if you set tx = 0?

[bartplessers]

Do you have a seperate km100 gateway? (Or the integrated version?)
How old?

Are the modulation problems still existing if you set tx = 0?

• separate KM100
• tx = 1. I will keep this for few more days to first analyse current configuration

[bartplessers]

New interesting results:

temperature

boiler power

Here my conclusion is

• my thermostat comfort temp is set on 21
• roomtemperature was never below 21
• whole night/day, my boiler was at 17% power
• there were some drops in power (08:00; 11:43; 13:50; 15:43; 17:00)

My theory now:

• if thermostat is "on" (temp set to 21 in my case), boiler is ALWAYS on, despite the real temp in the room
• boiler sets itself on lowest power (in my case 17%) because heat demand is minimal/not existing
• from time to time, it sets power to 0%. Can not explain this behavior. No correlation to something else detected...

Can somebody confirm/debunk this?

Another strange thing:

• in hass, it seems like there are no registered points: last registered power
  

• however: in mqtt explorer, I can see that my broker receives every 10 seconds its data from ems-esp:
  

but this is maybe just a rendering issue in hass? maybe it takes only the points that have a different value than the previous one?

sincerely,
B

[tp1de]

Hi Bart,
km100 is ems-bus powered. km200 has seperate power supply. Maybe a defect with km100 or ems-bus power generally low. Since you have a ems+ system you should use tx=2.

In respect to your graphs you should look at the boiler flow temp. In my case being on lowest modulation temp is still increasing and after a certain time temp is above upper switchoff point.

Thomas

[realthk]

My theory now:
* if thermostat is "on" (temp set to 21 in my case), boiler is ALWAYS on, despite the real temp in the room

If the thermostat is in weather controlled mode, that is certainly true: the heating is always on, and the current room temperature is only one parameter in calculating the required water flow temp.
If you switch it to room controlled mode, then it would switch off the boiler when it is not required as the room is warm enough.

[bartplessers]

@realthk : thanx for clearing this out.
It feels strange for me, but from the other hand, I noticed that the roomtemp was very stable around 21.4C.
Do you know what happens if there is even less heating demand? I would expect the boiler goes lower then 17% power, but don't know if this is physically possible. I read somewhere that buderus has 6 modulation levels what corresponds with a minimum level of +/- 17%.
So if it can't go lower, I suppose there will be more interuptions?

Grtz
B

[glitter-ball]

@bartplessers - without room influence, the flow temperature is controlled solely by the outside temperature and the heating curve programmed in the boiler/thermostat. Properly configured, the heat loss from the building will be exactly matched by the heat input from the boiler, so the inside temperature should stay constant. But, the pump will run most of the time, since the system has no way of knowing whether the internal temperature has been reached or not.

It can be tricky to get the heat curve right and it can be thrown out by other heat sources / losses in the building - heat from cooking, heat from open fire or log stove, heat from solar gain through windows, loss from open window or into unheated rooms etc. All this can be mitigated by using room influence. Now the basic flow temperature is calculated from the outside temperature and heating curve, with a positive/negative correction applied from the error between the set and actual room temperatures. When the room is warm enough, the boiler can stop the pump, too. But this needs a sensor in the heated space in order to work, unless you can feed your thermostat the temperature another way.

The boiler will modulate to maintain the target flow temperature. Mine modulates between 30 and 100% (7.2kW and 24kW). With demand less than 7.2kW, the boiler cannot modulate any lower, so it has to cycle on and off to produce an average output, over time, of something less than 7.2kW. Yours will be the same - if the heating needs less than 17% power, the boiler will have to cycle on and off to deliver this. Not ideal, but the only solution. Moral - don't buy a massively over-sized boiler (like I did!). Buy what you need to do hot water and try and match maximum space heating output to worst-case heat demand.

You can lessen the effect of cycling by setting the time and temperature hysteresis to stop the boiler cycling too much in warmer weather but this will not stop it cycling completely.

[glitter-ball]

@bartplessers - all this becomes much clearer if you get the boiler's target flow temperature and actual flow temperature displayed. Here's the last hour from my system...

It's mild here today (10.9ºC) so the boiler cannot modulate low enough. There are two spikes at 20:15 and 20:27 where the flow temperature rose too high just from the burner lighting! Once flow temp exceeds the target by 4ºC, the burner shuts down. At 20:39, the burner lit and the flow temperature stayed less than 4ºC over the target. The burner quickly modulated down to its minimum (30%) and stayed lit until 20:47 when the flow temp exceeded the 4ºC upper target and the burner shut down.

The pump runs for 4 minutes every 10 minutes to check the flow temperature. At 20:57 the pump started on this cycle, but the flow temperature was too high, so the burner stayed off.

Does this explain what you're seeing on system if you look at these values too?

[realthk]

@bartplessers : exactly. The minimum power with my Bosch 2500 is 15%. Should it be too high, it is switched off, until the water cools down enough.

Lets says the hysteresis of the boiler is set to 5C (you can configure this) and the thermostat requires 30C water flow temp. I only have 8 radiators in my small house, so when the rooms are already warm enough the water temp will rise even at 15% power. When it reaches 35C, the gas burner is switched off, only the pump runs on, so the water starts to cool down slowly, until it reaches 25C, when the gas is switched back on. And so on...

In weather controlled mode, the boiler is normally never switched off, at least the pump runs all day (though there is an optional set-back mode for night, when it can be switched off). Only the water temp is changed by the thermostat depending on mostly the outside temp, the heating curve parameters, and to some extent by how much the room temp differs from the setpoint.

I'm still playing with the settings, but it seems when it is not too cold outside, I'm better off with the simple room-controlled mode, because then heating is only required a few times a day, no need to run all day.
But when it is freezing outside, the weather controlled mode is much more comfortable as the radiators never get too cold (or too hot), and the room temperature is spot on, so it worth to set it up.

The dev branch of EMS ESP now can switch between these modes, so it even can be automated.

[bartplessers]

@glitter-ball , @realthk : coool!! Thank you so much for the info.

The dev branch of EMS ESP now can switch between these modes, so it even can be automated.

Great! Looking forward to this. Although I was expecting this kind of "intelligence" from my thermostat/boiler itself.

I have to analyze this further, but here are mine graphs for the last four hours

I understand the behavior of @glitter-ball's graphs, but main difference with mine is that I don't have a fixed "target flow temp", what is kind of weird.

grtz
B

[glitter-ball]

My target flow temp isn't fixed either - it's calculated dynamically:

So, the boiler fired just after 15:00 to start warming for 16:30 target time. You can see blue target flow temp drops as the room influence error reduces. The jump at 17:40 is me changing the target temp from 18.5ºC to 19ºC, which changed the target flow from 33ºC to 50ºC.

@bartplessers - I think we see this on your trace too? In between the hot water spikes you can see small changes in the flow temp?

Remember, too, that your thermostat may have at least three modes:

• Weather compensation alone

• Room compensation alone (basically on/off thermostat)

• Weather compensation with room influence - this is the one I use as it takes external temp and room temp into account. When it's set up right, this should still give you low radiator temperatures (not too hot or too cold) and errors in the heating curve setup are largely covered by the room temperature correction.

I still have some playing to do with my system. In mild weather, the system takes too long to reach target temperature, so I suspect the underlying heat curve is not quite right.

[glitter-ball]

Once the thermostat/boiler are set up OK, you should not need to switch modes. You can program heating times and the system will operate at those times, matching building heat loss to weather conditions. There are other settings (setback, summer) which you can adjust to shut the heating down when it's not needed - when the heating times are off, especially overnight.

Here's 24 hours on my system - I haven't touched the controls at all, other than to increase the room temperature at 17:40 today. All the rest is done by the thermostat / boiler:

You can see system is off completely overnight / outside heating times. When heating is set, pump cycles 4 min on / 6 min off until heat is needed, then it runs close to 100% while the burner is lit.

I have radiators so this is OK. If you have underfloor heating, it's usually better to keep it running overnight at a lower temperature, rather than switch it off completely because the large thermal mass would otherwise take a long time to heat up again in the morning. At my church's office, where we have underfloor heating, we set the room temperature to 18-19ºC in the day and 15ºC overnight.

[glitter-ball]

@bartplessers - One other point... I found my pump modulated down to perhaps 60%. At this speed, the water flow was too slow to distant parts of the heating circuit and the flow temperature often rose very quickly and shut the burner down. So, I have increased my pump speed closer to max to try and stop this. It means the pump is running faster than needed some of the time but that's better than the burner keep cutting out and cycling.

This is not helped by the boiler software, which is silly. Often it will light the burner and then start the pump... *8(. It would be much better if it started the pump, waited perhaps 30 seconds for temperatures to stabilise and then lit the burner but that's how the software is...

[bartplessers]

@glitter-ball : so great to see your info, thanx again.
It has been since I was studying for engineer that I have to take a look at energy diagrams :-) (and most of them at the time, it was about steam machines!)

Anyway: thanx for clearing this out for me. I think I understand the whole process now.
BUT: this makes me more suspicious about the boiler (or it's interaction with ems-esp)...:

Here are my graphs for last night.

I colored 2 strokes green, where the behavior is normal in my opinion:

• thermostat was set to 21C, no changes made
• boiler "knows" that for a given outer temp en desired inner temp, it has to set target flow on +/-40C
• 7:00 PM: current flow temp >> target flow temp, so it turns itself off
• 8:00 PM: current flow temp << target flow temp so it starts
• boilers starts and sets modulation almost immediately at 17% power
• water is heating, current flow temp rises
• 9:30 PM: current flow temp >> target flow temp --> boiler shuts down
• current flows temp drops slowly till 10:00PM
• 10:00 PM: current flow temp << target flow temp --> boiler starts, modulation 17%

This behavior is a very logic. It means that:

• given the parameters of my building/installation/outdoor temp, the ideal target flow is to be calculated at +/- 40C by the system
• my boiler is under this circumstances a bit over-dimensioned. Even at 17%power, The flow temperature raises to fast, so it has to shut it down itself from time to time.

BUT:
what about the other parts of my graph (the non-green marked strokes)???
I really don't understand why the target flow has so many spikes between 11:00PM and 2:AM

In your graphs, I see a much more modest behavior: target flow temp changes, but not abrupt as in my installation.
I can also see in your graphs, that the boiler starts and stops, but this is explainable: heat production to high, pump can not transport the heat fast enough, boiler modulates and and in the end shuts down.

Of course if the target flow in my installation raises suddenly for some reason, this induces the boiler to start at 100% power which creates a surplus on heat. The pump can not transport the heat so fast, boiler shuts down, etc...

I also notices this morning, that there was an issue (again):

When I take a look at the error code A11/1037, it means there is a problem with the outdoor sensor.
This could explain a lot: if there is no feedback from outdoor temp, the system can not calculated the ideal flow temp, so if there is a heat demand, it just puts it on +/- 70C in my case.

What has this all to do with ems-esp? Well: the error message on my thermostat only appears if ems-esp is connected to my boiler. So I'm more and more convinced that there is a problem with the combination ems-esp/boiler because of some interference between ems-esp and the boiler/sensor

My current hardware:

• BUDERUS Logamax plus GB192iT40
• BOSCH RC310 thermostaat
• BBQkees Gateway Premium II (with external usb power supply)
• ems-esp v2.1.1b7
  (note hat I disconnected the BUDERUS Gateway Logamatic web KM100 for now)

And that brings me to the one million dollar question:
Is there a problem with the combination of ems-esp and my boiler or not?

I think here is some proof:
With a running boiler, I powered off my ems-esp

with ems-esp running:

ems-esp turned off:

Notice the outdoor temp being displayed without ems-esp running immediately. Seems that ems-esp prevents data coming from outdoor sensor. (something else I learned in my engineering days: according to the quantumtheory you can't measure things without having any interference, which is clearly the case here :-) )

In my opinion there is definitely something going wrong here...

The only thing I can do right now is disconnecting the ems-esp module, and take a look at my gas meter for a while to see if there is a continuous small demand of gas (which is good, because that means the boiler is in balance) or weather there is a heavy varying demand of gas (which means that even without ems-esp the boiler has a problem)

any thoughts about this?

kind regards,
Bart

[tp1de]

Hi Bart,

the error code A11/1037 means, that the outside temp-sensor is defect and the boiler goes to default temp mode which is set by standard to 60°C or even higher (look at your parameters). There seems to be a temporary contact problem or the sensor itself is defect. Check the cabling of your sensor for loose contacts. If there is warranty on your system, then call the installer.

In your case it would explain the hc1 target temp changes between normal and default operations mode and vice versa as shown in your diagrams. The boiler just reacts on this fluctuating target temp changes.

You could try to disconnect the outside temp sensor and change parameters to room controlled heating. What is happening then?

rgds Thomas

[bbqkees]

It's quite a specific problem as it only seems to affect the outdoor temp on a RC310.
The error you get is a hardware error, but the thermostat will think its a hardware error because it can't get the right value or no value at all when it does expect one.
The outdoor sensor is connected to the boiler so the value of the sensor is transferred to the RC310 via a telegram on the EMS bus. Let's assume the outdoor temp sensor is functioning normally and the value is sent on the bus, then it means something on the bus prevents the RC310 from getting the real value.

As all other bus communication appears to go as normal, maybe the RC310 falsely interprets a telegram of EMS-ESP as being the telegram with the outdoor temp, corrupts the value, and thus fails to acquire the real value.

[bbqkees]

There was someone else who emailed me a while ago from Germany with a RC310 (but different boiler) with error code A11, but I have not heard from him again if it was solved in the end.

[tp1de]

A s all other bus communication appears to go as normal, maybe the RC310 falsely interprets a telegram of EMS-ESP as being the telegram with the outdoor temp, corrupts the value, and thus fails to acquire the real value.

When I used the original ESP8266 I got sporadic error messages as well but related to my mm100 mixer.
Since I use the ESP32 insted everything is stable on the bus. Could it be some memory problems related to the ESP8266 with the actual firmware and mqtt? ... just a guess.

KB192i with integrated ip-gateway (km200), rc310, mm100 and 2 heating circuits. Now 100% stable with ems-esp 32

[bartplessers]

the error code A11/1037 means, that the outside temp-sensor is defect and the boiler goes to default temp mode which is set by standard to 60°C or even higher (look at your parameters). There seems to be a temporary contact problem or the sensor itself is defect. Check the cabling of your sensor for loose contacts. If there is warranty on your system, then call the installer.

Hi @tp1de : that's my whole point...:
There is a correlation between

• ems-esp connected --> outdoor temp sensor "looks" defect
• ems-esp disconnected --> no error messages at all
  I can reproduce this easily.

So in my opinion, it's not the sensor that is defect, but rather something wrong with messages from/to ems-esp on the communication bus and that the system can not understand.

So I doubt that my sensor is physically defect or bad wiring.

Current setup:

• power-on boiler system
• wait 10 minutes
• power-on and connect ems-esp (I added a hardware switch on the ems-bus, so ems-esp will not power up on system)
• wait 10 minutes

then everything works perfect "for a while".
Current stats look very promising (I have to find out how to connect the measuring points horizontally in grafana) and values correspond to theory

however, I expect a "failure"

• when thermostat is set by homeassistant (and ems-esp) OR
• when thermostat schedule will change room temperature (will be at 17:00 this afternoon) OR
• at random OR
• something else :)

for now: I wil not touch anything, so I just will observe error state of thermostat...

kind regards,
B

[tp1de]

Strange behavior. I will flash the original esp8266 with the same sw-version and will connect it to the gateway instead of the esp32 and check if the stability will change. I will keep you informed.

[bartplessers]

@tp1de : great! thanx

[tp1de]

I exchanged the esp boards and I am runnung v2.1.1b7 now with the original esp8266 board from Kees.
For the moment everything works fine, the km200 interface as well.

@bartplessers Are you using tx_mode = 2 (ems+) like I do?

[tp1de]

@bartplessers There is one thing I recognized:

I changed the mqtt topic length to 128 (I believe that this is the standard setting) and the ems-esp crashes and my heating went into error state. The led on my mm100 mixer was blinking and the web-ui of ems-esp was not accessible anymore.

So I am back on my (so far) stable settings:

• tx_mode =2 (ems+), bus id modem (0x0D)
• mqtt enabled, max topic length = 255, mqtt format = nested, QoS = 0

Pre-conclusion:

• The mqtt functionality seems to be not as robust as needed.
• Ems-esp software crashes will disturb the ems-bus !

[bartplessers]

@tp1de : waaw, thanx for the effort

first: my graphs till now. everything perfect and predictable:

also: Tx/Rx quality

both at 100%

Settings:

• ems-esp
  • settings: Tx = 2
• mqtt
  • max topic length: 128
  • format: homeassistant
  • QoS: 0

Right now (16:00), the program of my thermostat will "change" the temperature to 21C. This will hopefully do nothing, because I already set this temp at 11:42 manually.
At 17:00, the schedule of the thermostat will change the temp back to 17C.
Will see what happens then.
Meanwhile I will not change anything to keep test consistant.

If changing the MQTT parameters would solve this issue, that would be really great!!
But I think that @bbqkees and documentation should mention this and give some more error feedback. At least because potentially the ems-esp can really mess up the default behavior of your installation.

However, let's not be too fast drawing conclusions, and see what happens the coming hours/days

kind regards,
B

[glitter-ball]

@bartplessers - some more questions!

1. Do you have hot water on your system? If yes, flow/combi boiler or storage cylinder? Just checking spikes are not hot water production - unlikely, especially at 02:00, but I'll ask! The outdoor sensor looks the likely problem.
2. Do you have an outdoor temperature history on your thermostat / boiler? If so, what does the graph look like?
3. What does your outside temperature graph look like in HA when you get the problems?

[bartplessers]

Hi @glitter-ball

Its a combination of CentralHeatingSystem+WarmWater
Warm water production is very unlikely at 02:00 :-)
Also: last week I was at home alone (explains why I could spend so much time on this :-) ), so no much warm water used...

I just setup grafana+influxdb today, so have no good historical graphs right now
Here are some screenshots of standard hass-logging.
Please take into account:

• timeframe 23:00-03:00 --> "problematic" situation. Probably generating the A11/1037 error on my thermostat
• timeframe 11:43-now --> after reset complete system, and with ems-esp starting 15min later dan boiler started

Outdoor temp

selected flow temp

current flow temp

current power

indoor temp

as you can see

Period 1 (23:00-03:00)

• too many spikes in current power
• room temp too high (+/- 22C) and unstable

Period 2 (11:43 - now)

• almost flat indoor temp curve (+/- 21C)
• nice distribution of current power, with modulation at 17%

More details will follow in the future with grafana/influxdb, but here you have a snapshot of the "ideal" situation right now:

In this situation

• powerd up boiler at 11:30
• ems-esp powerd up at 11:40
• set room temp to 21C at 11:40
• thermostat set temp to 21C at 16:00 (so no effective change in temp)
• thermostat set temp to 17C at 17:00
• manual temp set to 21C at 17:30
• no warmwater heating demand during this period (didn't use any warm water at all)

Conclusion:

• this is a stable system
• as you explained: room temp is regulated by setting a selected flow temp (taking into account some parameters like outdoor temp, building properties, etc...). Boiler will try to approuch this selected flow temp by modulation (in my case: current power 17%, or even 0% if heat can not be dissipated fast enough) and pump modulation

this is comprehensive for me

However, I did not touch my esm-esp at all. I will leave the system as is till 12:00 tomorrow (to have a cycle of 24h at least). In the afternoon I will change my room temp to something else with ems-esp.
I expect that -after a while- there will be an error (A11/1037) because of interference between ems-esp and the boiler system.
With no external sensor available, the system reacts total different, and starts at 100% modulation, can't transport the heat fast enough (because there is no much demand right now), shuts down, start over again, etc...

If I can't induce this error, I will reboot the whole system, without rebooting ems-esp (it has external usb supply right now). In this case I will almost certain get the A11/1037 error....

let's wait until tomorrow and see what happens.

Kind regards,
Bart

[glitter-ball]

@bartplessers - I was going to say the external temperature graph from HA looks OK. But, when I think a bit and look closer...

... is the temperature perfectly flat when the spikes happen? If so, that would tie in with the sensor 'failing' - HA gets no update, so there's a flat line when there should be a small variations.

Do you have an external temperature graph display on the boiler or thermostat themself? Curious what that looks like? I have one on my thermostat.

Anyway... all this is pointing in the same direction. Something is stopping the system logging external temperature. HA might just see a flat line then. The boiler raises the A11/1037 error and has to go into fallback mode which causes the problem behaviour.

[bartplessers]

Eat this!
as promised: the details of last 24h, a perfect curve!

• initial: room set temp 21C
• at 07:30: room set temp 17C by thermostat program

Everything looks smooth and predictable, except for a small working period of the boiler at 09:32. I will ignore this, because it's probably a maintenance job or something else.

Next step: I will fiddle around with changing room temp via ems-esp.

keep you informed,
Grtz,
B

PS:
@glitter-ball :

Do you have an external temperature graph display on the boiler or thermostat themself? Curious what that looks like? I have one on my thermostat.

See pictures of my thermostat earlier in this converstation.
Main conclusion:

• when in error: outdoor temp is NOT displayed on thermostat
• detaching ems-esp --> outdoor temp is almost immediatly displayed on thermostat
  Seems that the ems-esp prevents communication between sensor and system....

Further: I'm not sure if every measured value is registered in home assitant.
In example: every 10 seconds I register following on my MQTT broker:

But I don't see all these values on grafana/homeassistant. I think only different values are registered. This can be seen if I take a look at the data in MQTT-explorer: every point is registered here:

So to answer your question: I'm not sure if the outdoor temp has a flat curve because of not registering, or because it just IS a flat curve in reality..

[tp1de]

@bartplessers @bbqkees

Hi Bart, as promised I tested the original esp8266 vs. esp32.

After around 24 hours running with the esp8266 (original D1 wemos board) on the gateway premium II, I got an error on my ems-bus. My ems-esp gateway is connected to ems-out on my mm100 mixer. The mm100 was on error state - green led blinking, error message on RC310 thermostat and on ems-esp the ems status was on "disconnected". Web-ui / API / and MQTT was still running but without actual data. This might be related to timing problems on the bus, so that the error is on the device where the ems-esp gateway is physically connected. (boiler or for me mm100).

I now went back to the esp32 which was running stable for around 10 days before.
I don't know if this is related to the hardware (memory limitations) or different libraries for compilation of the source code into binary. For me, the esp8266 is not working stable for the moment.

@bartplessers : Your problem might be different - I can not judge.

[bartplessers]

@tp1de : interesting! I already ordered some esp32 boards, but will arrive late january 🥴
Thanx for feedback

My system is still stable. For now. I have done some roomtemp changes with hass. But everything works fine now. Later on the evening I will do a soft reboot (restart from within the web interface) and see what happens.

[realthk]

@tp1de and how could you clear this error? A boiler reboot solved it?

I experienced somewhat similar issues:

• upgraded from 2.1.1b4 (which was working OK since installed, for over a week) to 2.1.1b6 compiled on my machine. After uploading through the web interface, it could not establish connection at all, and after a while, my CW400 thermostat displayed system failure which I could clear only by rebooting the boiler without the EMS-ESP
• instead of building the fw from source on my machine, I downloaded 2.1.b6 precompiled bin from here. It was working for a few days fine, until
• 2 days ago it did the same: lost connection and system failure came on the CW400... now it also could not connect even after boiler reboot, so I dismantled the EMS-ESP (it is not from bbqkees, I've built it on a test board), flashed the ESP8266 with 2.1.1b4 through USB. Put it back on the boiler and it seems to work fine since.

Now I don't know, if it is a fw related issue of 2.1.1b6, or hardware, perhaps the esp8266 as you suggest... but I do not yet have ESP32 to try (first I suspected my 2x200mA multifuses on the board might have tripped, but on second thought I doubt it, as it should be cleared in seconds, and I power the board from a USB charger, so there should not be high load on the EMS bus)

With which fw version have you experienced this?

[bartplessers]

Small update: till now I could not reproduce the problem.
What I already did:

• (soft) rebooted ems-esp
• (soft) rebooted my mqtt broker
• (soft) rebooted hass
• played with room set temperature in hass to introduce some changes

Nothing of above created an error or unexpected behaviour.

Only thing I can see in graph below, is that there is a small peak at 05:56, but again: I will ignore this, because probably a maintenance job in the boiler itself

next step: when I'm back home (I'm now remote) I will:

• (hard) reboot boiler system (power off/on) with ems-esp still running on usb-power. Remember that all my latest test were done with ems-esp started 10min later then the boiler did
• after that test, I will unplug usb-power from ems-esp and reboot whole system to see what happens then (ems-esp powered by ems-bus)
• if this will still not introduce the error, I will do the same, but with Rx=0 (now Rx=2) . Then I'm back on my original setup when logging this problem.

[tp1de]

@realthk
I had the stability problem with the esp8266 with all versions since I use the ems-esp gateway (6 weeks).
After 24-48 hours there where ems-bus errors displyed by my heating system.
Especially the b6 version was not working at all. When the gateway started I got errors on the ems-bus and the heating system went into error state.

I am using the km200 internet gateway for 2 1/2 years now with rest-api calls (encrypted / decrypted) with integration into my home automization system build on ioBroker. Because of some limitations I decided to install the ems-esp gateway in parallel. (When I have the time I will document the differences and pro & cons).

I worked with @MichaelDvP on code changes to make the km200 and ems-esp to work stable when both are installed.
With dev version b7 this is achieved and some data-points where added or corrected. So far so good.

But with the esp8266 I never got my system stable. So I ordered already in bad mood a esp32 with Amazon next day delivery.
I just needed to find out how to flash with platformIO since I had never done esp sw builds.
Actually I am using the b7 bin file from @proddy's github download section.

Since then the esp32 b7 sw-version works technically stable and is not interfering / stopping the ems-bus anymore. #15
Still other open issues exists which have to be corrected.

[realthk]

@tp1de
Thanks, I've just ordered an ESP32 from China, and I'll stick to 2.1.1b4 until it arrives. That version seems to work fine here (knock on wood)

As there aren't many complaints (I've seen only yours similar to mine) maybe this issue is related to the boiler and components in use, perhaps also the MQTT config or simply the make of the ESP8266
(I have a small Bosch 2300 boiler and a CW400 thermostat connected to Home Assistant, and Wemos D1 Minis bought from Aliexpress: otherwise fine for every other project, but maybe this one puts higher load on its chip)

[bbqkees]

Especially the KM100/KM200 seem to be unhappy having EMS-ESP around. Maybe they are jealous on EMS-ESP's bigger device database and throw a fight every time EMS-ESP comes to their neighbourhood :-)

Most people plug the Gateway in their boiler, do a Home Assistant MQTT discovery or load the Domoticz plugin and that's basically it. Everything runs fine for those users.
I think there are actually less than 1% of users that encounter issues at all.
There are a few of them that occasionally ask a question via email and there are like 5 to 10 active 'power users' here and on Gitter. Only those with problems tend to come to the repository so the number of Github issues here does not represent the entire user base properly.

So given the low amount of issues here, there seem to be certain specific combinations of hardware that do not play all that well together.
It might be things in EMS-ESP, the boards, the KM's, the newer EMS+ thermostats, the boiler, noise, wire lenght or a specific combination of those. That's one of the downsides not having the actual EMS bus spec. But with every step in the reverse engineering we are getting closer.

@realthk if you want to buy additional D1 Mini's do not buy clones but get the original Lolin ones: https://www.aliexpress.com/item/32529101036.html. Most clones have an underpowered LDO.

[bartplessers]

Hi @bbqkees

f you want to buy additional D1 Mini's do not buy clones but get the original Lolin ones: https://www.aliexpress.com/item/32529101036.html. Most clones have an underpowered LDO.

Damned. I already ordered
https://nl.aliexpress.com/item/1005001651025278.html

any experience with those?

(Anyway, I ordered now also a couple of https://www.aliexpress.com/item/32529101036.html)

Are there somewhere instructions how to use this board on your BBQkees Gateway II? Not very familiar with this, so any help is welcome...

[tp1de]

Hi @bartplessers @bbqkees
I ordered the AZDelivery ESP32 D1 Mini NodeMCU WiFi Modul + Bluetooth Internet board from Amazon for 8.60€ and next day delivery because I do not wanted to wait. This one is working fine. I haven't found a software to flash the bin by usb directly like ESP8266Flasher.exe - but I haven't spent a lot of time searching. So I used PlatformIO to build from source.

[realthk]

@bbqkees Thanks, I'll try this Lolin D1 Mini then also. Last time I've ordered this type (have no clue what's under the metal shield), which is fine for reading i2c sensors, but perhaps not for EMS ESP, we'll see.

If there was too much noise on the wires, I guess it would show in the quality numbers? I only had quality issue, when I was trying to power my circuit from the EMS bus, but since I've switched to USB powering the Wemos, that is always 100% while it works, either with 2.1.1b4 or b6.

[MichaelDvP]

esptool works for usb-flashing esp8266 and esp32, if you dont like commandline there is a GUI for it here, also for esp8266 and esp32. It has also a erase option, usefull for clean install.

[bartplessers]

small update

• 14:36

  • power off boiler system
  • wait
  • rebooted ems-esp: usb power off / usb-power on.
  • wait
  • power on boiler system
    no problems then, although I was expecting problems here (but no long term testresults either)

• 17:02

  • I unplugged usb-power from ems-esp
  • reboot whole system (thus ems-esp powered by ems-bus)

bingo:
here a log of the error:
see the light blue color around 17;24. This color code means "error A11(1037)"

and power consumption starts to fluctuate again

so final (?) conclusion:

• the hardware is unstable without external power
• with external usb power: even then some errors

have a nice day!

b

[MichaelDvP]

I'm not sure if understand correctly.

I unplugged usb-power from ems-esp

There should only be one power source: bus OR service-jack OR usb. If you power usb you should pull the jumper/dc-dc.

Also with usb-power use a usb supply with stable regulated 5V, some chargers works only with the voltage smoothing of a large batterie on secondary and produces large ripple if powering a esp.

[proddy]

Would be interesting if these anomalies are related to the KM100. It's hard to tell whether its the EMS-ESP code (uart timing causing misfires on the bus), the hardware circuit (creating interference) or the KM100 just by being the annoying kid at the party and disrupting everything. Have we tried remove the KM100 gateway and still using bus-powered? What about a special build of EMS-ESP that completely ignores all devices except the boiler (on device ID 0x08).

[bartplessers]

@MichaelDvP : oops.

There should only be one power source: bus OR service-jack OR usb. If you power usb you should pull the jumper/dc-dc.

I placed the jumper according to
https://bbqkees-electronics.nl/wiki/gateway/connecting-to-the-boiler.html as follows

So, I moved it from "jack" position to "EMS" position. Because the ems-esp has of course to be connected with the EMS-bus, it gets its power from there. At some point in time I added external usb-power. So indeed, I was not sure how the device was actually powered....

@proddy:
those anomalies were totally isolated from KM100: at some point of time I removed that gateway to keep test binary.

So errors ware induced on this setup:

• BUDERUS Logamax plus GB192iT40
• BOSCH RC310 thermostaat
• BBQkees Gateway Premium II, running ems-esp v2.1.1b7

My "feeling" is that (lack of) power however is a secundary reason for this behaviour. I would guess that there is something wrong with communication, handshakes, ... between devices.

What about a special build of EMS-ESP that completely ignores all devices except the boiler

To have a overview of all the parameters, I think you need information from the thermostat too (room set temp, room current temp, etc...) ...., so I think this would not be enough.

kind regards,
B

[tp1de]

@bartplessers you should take the jumper completely off as @bbqkees told you.
With ems power enabled and usb power in parallel my system is not stable as well.

[glitter-ball]

Would be interesting if these anomalies are related to the KM100. It's hard to tell whether its the EMS-ESP code (uart timing causing misfires on the bus), the hardware circuit (creating interference) or the KM100 just by being the annoying kid at the party and disrupting everything. Have we tried remove the KM100 gateway and still using bus-powered? What about a special build of EMS-ESP that completely ignores all devices except the boiler (on device ID 0x08).

Set TX Mode = 0 so we're only listening and see if there are still problems? Presumably that removes the possibility of the UART screwing the bus timing?

[bartplessers]

@tp1de

you should take the jumper completely off

Will do. I probably overlooked that post of @bbqkees and on his website this was not mentioned

@glitter-ball

Set TX Mode = 0

In the first posts of this conversation, Tx = 0, and there were problems too. Do you want me to redo those test?

@proddy
the most predictive factor is Rx/Tx quality. When I see the Rx decreasing, the system will definitely go in error. But even when this is a result of underpowered device (it's still not clear to me that this is the only reason), It should not mess up communication between boiler and outdoor temp sensor...

Next step: this evening I will

• pull off the jumper
• set Tx = 0
• power off/on everything

keep you informed,
grtz
B

[glitter-ball]

Sorry - forgot the TX Mode bit earlier! If the UART then just sits passively listening and the problems still happen then it’s not going to help.

Maybe the power issues are causing an EMC problem on the bus? Let’s see what your tests find.

[MichaelDvP]

result of underpowered device

The main problem is not underpowering of the esp, it is overloading the bus. The clients send to the bus by current loop, if there is to much load on the bus, the sending breaks down the bus and you get communication errors.
Underpowering the esp will mainly result in reset while sending wifi.

Having two supplies parallel can cause many unwanted effects, the lowest is that the supply with higher voltage will supply the complete current and the other do nothing. Other possible effects are oszillations that disturbing the bus or getting heavy and can damage hardware. Parallel supply is only safe for batteries and supplys that are constructed for parallel redundancy (expensive).

[bartplessers]

Okay, the ultimate test now:

• BUDERUS Logamax plus GB192iT40
• BOSCH RC310 thermostaat (connected to EMS-bus1)
• BUDERUS Gateway Logamatic web KM100 (connected to service jack)
• BBQkees Gateway Premium II ( connected to EMS-bus2), with
  • ems-esp v2.1.1b7
  • external usb powersupply, and jumper switch removed

So to be clear: there was some confusion about how the ems-esp device was powered. Because I removed the jumper now it can only be powered by external power supply, so no ambiguity more about that.
Furthermore: because I hope this will run for longer time, I immediately attached the KM100 back again, because this would be my desired configuration. Thus both:

• out-of-the box supported config by buderus by app and KM100
• playground with ems-esp and homeassistant to add fancy things and features.

A big thank you for you all to help me out of this. I learned a lot about working process of modern boilers, esp-boards, usb supplies and even jumpers :-)

Hopefully the bus will not be saturated with messages again so the whole breaks down in error again. It still feels not good having attached a device that can mess up things that much, so I will keep a close eye on in for the coming days.

love this community!

cheers
Bart

[glitter-ball]

@bartplessers - let us know how it goes....

[bartplessers]

Hi @glitter-ball

Everything works perfect now, thanx for asking!

So it looks like the whole thing can be reduced to lack of power. As @tp1de mentioned from the beginning (what I didn't believe...)
It's still hard to believe, but that's the only conclusion I may draw. It's still weird that such a small defect can have such a profound effect on the whole boiler system, so I think there is some room for improvement heren.

kind regards,
Bart

[glitter-ball]

@bartplessers - glad you got it fixed! This is a brilliant project with some very clever people involved so it's great when everyone can chip in to explore problems and fix them. Merry Christmas from Tier 4!