Migrating to 3.9.0 first experience and observations

[VlastiBroucek]

So, I have bit the bulet and decided to migrate to 3.9.0 from latest stable 3.8.3. After making sure I have read everything and did my preparations (making backup of my settings!!!), I "went for it".

Hope my experience can help others.

First, I downloaded the new bin file (for just in a case), by pressing Download

Then I clicked Install and that failed with error message. I did not record it, but I think it was something about file - maybe same as #3086 - so I decided to upload the previously downloaded file throught here

that seemed to work, but after reboot nothing. Some strange screens, some red pop-ups about not being authorised and finally nothing.

At that time, I started panicking a bit since this is my only device and is "production". So, apologies for not having any screen captures.

I could not connect to it. Not with usual name, not with IP address that it should have had assigned by DHCP, nothing.

Thought something wrong with Ethernet, but AP was not visible either...

So, run to the cupboard where it is located, hook console and check what's happening...

Aha, the ethernet has completely different MAC address than it had originally and hence not the reserved IP, but completely random one...

Using that IP, I finally connected, logged in as default user, uploaded my backup, restarted and voila...

So overall not a really bad experience but could have been better.

[proddy]

Thanks for sharing your experience @VlastiBroucek . It looks like we have some fine-tuning to do. I will also create an article and pin it to the GitHub discussion board with instructions using some of your findings.

I did a test on an E32 (Ethernet) board with a fresh EMS-ESP v3.8.3 and then auto-installing to v3.9.0-dev, and I get the same error. The logs say "Firmware upload failed - invalid size". When installing a firmware, we have a check for the file size and disregard anything less than 2097152 bytes (2MB). The firmware EMS-ESP-3_9_0-dev_1-ESP32-16MB+.bin is 2021904 bytes (1.92MB) after all the optimisations, which is why it fails. I'll fix it. But sadly it won't solve the problem, so in this case, a manual download and drag-and-drop is the only way forward.

[MichaelDvP]

@proddy Was it intended that you fixed it direct in the main branch? 02caaef
But the bins are not updated, so source and bins is not in sync.

[proddy]

It was a mistake; I rushed it this morning before heading out for work. Didn't realise I wasn't in the fork. I'll force a new build so it's in sync again. For 3.9.0-dev I'm testing some new code that downloads the MD5 first to validate against the firmware before uploading. Those checks in the code is only to ensure we're uploading a true espressif .bin file and not some 2MB junk file (and become a cyber risk)

[VlastiBroucek]

Thanks @proddy - BTW, upgrade from dev.0 to dev.1 worked OK with the Install button.
There is also new error HA log file after each reboot:

Can this be coming from the new bootTime sensor?

This is in info topic now,

{
  "version": "3.9.0-dev.1",
  "systemName": "EMS-ESP",
  "bootTime": "2026-08-03T17:51:41+1000",
  "network": "ethernet",
  "hostname": "ems-esp"
}

EDIT:

I think "val_tpl": "{{value_json['bootTime'] if value_json['bootTime'] is defined else 0}}" is the problem. HA does not accept 0, it expects ISO 8601 datetime.

[proddy]

yes, that's the issue. A fix would be to change to "val_tpl":"{{value_json['bootTime'] if value_json['bootTime'] is defined else ''}}".

[joris62nl]

Just updated, and basically I was facing the same issues as @VlastiBroucek. Here the error from the log file regarding the installation file (as excepted):

[proddy]

yup, same problem. Solution is to drag&drop

[bbqkees]

What would be the reason the Ethernet MAC address is changed?
This will cause a lot of issues everywhere.

One thing I encountered so far:
I tried loading 3.9.0dev1 on a few E32 V2.2 boards with the EMS-ESP flash tool (Keep Setting OFF).
On some boards that already had 3.8.x, Ethernet works fine, but when I load 3.9.0dev1 Ethernet does not always work.
The RJ45 LEDs are just solid on or in a random state, Ethernet is not accessible.
Flashing 3.8.4 resolves the Ethernet issue.
If I update again to 3.9.0dev1 via drag and dropping the bin file in the web interface Ethernet works fine.

I also see the RGB LED is now default off when EMS-ESP has finished booting. I believe this is not intentional.
I have a board here without active EMS bus, just Ethernet and the RGB LED is off.
When I write to the LED (f.i. call system led red:rgb) the RGB LED pops back to its normal behavior when the sequence is over.
(So in the case of my board with NO EMS but YES Ethernet the RGB LED blinks blue)

[VlastiBroucek]

@proddy, 100% Ethernet MAC address on my device changed from FC:B4:67:D7:C5:CB to FE:B4:67:D7:C5:C9.

And actually, I believe only Base MAC Address is baked to the chip.

[proddy]

you're right. I looked into the Tasmota code (which we're using for the core v3), and Tasmota's SDK is built with two universal MAC addresses and not 4 like in core 2.0.17, which gives Ethernet a locally administered address instead of base+3.

The fix is to make EMS-ESP seed the MAC table before the driver reads it, using esp_iface_mac_addr_set() and the EMAC driver esp_read_mac(emac->addr, ESP_MAC_ETH) before the ETH.begin() call. I'll add it now.

I also checked WiFi; that's not affected. It's only ETH on ESP32's (not C3, S3 etc).

[VlastiBroucek]

The fix is to make EMS-ESP seed the MAC table before the driver reads it, using esp_iface_mac_addr_set() and the EMAC driver esp_read_mac(emac->addr, ESP_MAC_ETH) before the ETH.begin() call. I'll add it now.

In the light of what I wrote below and IEEE rules, I would not do it and leave it as it is now. The "new" way is more correct. It's just one more thing people will need to consider.

[proddy]

Ok. I'll leave it. The code is there but commented-out in case we want to go back to the old MAC addresses.

[proddy]

Can you give an example of a time when Ethernet does not work after flashing? Is this via the Python Flash Tool, the Python CLI tool, the https://install.emsesp.org/ website or from within EMS-ESP via the WebUI? That way I can try and reproduce.

@bbqkees see question above. Let me know how you were flashing the firmware that caused Eth to be unresponsive, so I can try and reproduce.

[VlastiBroucek]

@proddy , my reading says this is change in ESP-IDF versions...

Older ESP-IDF versions (pre‑v4.4, and some Arduino cores) derived Ethernet MAC like this:
Code
ethernet_mac = base_mac + 3

So from your base:
Base: ...C8
Ethernet: ...C8 + 3 = CB

This matches exactly what you saw.

This was the original Espressif rule.

3. Why Ethernet now shows FE:B4:67:D7:C5:C9
Newer ESP-IDF versions (v4.4+, v5.x, and ESPHome builds using them) changed the rule:

Derived MACs must be locally administered.
Meaning:

The first byte gets the local bit set

The OUI (FC:B4:67) is not reused

The last byte still increments from the base

So the new Ethernet MAC is:

First byte changed: FC → FE (local bit set)

Last byte incremented: C8 → C9

This is exactly what ESP-IDF now does.

Why did Espressif change this?
Because using the manufacturer OUI for multiple interfaces violates IEEE rules:

Only the factory MAC may use the vendor OUI

Derived MACs must be locally administered

So Espressif updated the stack to comply.

Sorry for messy text - just got that from Copilot

[VlastiBroucek]

I will admit I don't recall if it was like this in 3.8.x and I am lazy to downgrade to see, but I am finding the arrow at the end (circled in red) confusing.

I have already twice restarted my system accidentally, thinking that clicking on that arrow will open details of the command settings (thinking it is an accordion).

It is even so more confusing considering that hovering anywhere on that line highlights all of it, but clicking just on the arrow does something else than the rest of the line.

Huh, the arrow works differently here:

it asks for confirmation to run the command, albeit bit confusingly asking whether to Execute Schedule not command.

Could the similar confirmation be added to the Commands screen?

[proddy]

good point. will change

[proddy]

done.

[VlastiBroucek]

EDIT: This has 100% been introduced by core3 - I have been doing this for almost a year now, never had issue with it.

@proddy and @MichaelDvP, there really is something strange probably with networking and how core3 works with commands. I have now observed following twice, but unfortunately did not have console connected, so don't have any data to support it. I'll hook up console and monitor next time this is scheduled.
I'll try to describe in as much detail what I observed. For clarity, my EMS-ESP is connected directly to one of the ETH ports on my high-end router. So now what's happening:

• everything is working OK
• scheduled reboot of router happens at 00:30 Sunday morning
• after about 2 minutes everything comes back but no data coming back from EMS-ESP to HA
• scheduled reboot on EMS-ESP happens at 00:40 Sunday morning
• when I check my HA at ~8am, there are no data coming from EMS-ESP to HA
• I connect to EMS-ESP using GUI and it says System Uptime is more than 3 days so obviously no reboot about 7.5 hours ago
• my bad here - I did not look to log files and went straight to Settings->EMS-ESP Firmware->RESTART
• usual dialog box appears but it never ends and EMS-ESP does not restart
• I reload EMS-ESP page and all seems to be still working including Uptime over 3 days
• I try again Settings->EMS-ESP Firmware->RESTART, and it again hangs one the deialog box
• I have to power off and on to get it working correctly again

I am torn thinking if this is caused by networking or the new way commands are processed. But I just tried to do restart again (both manually and through scheduler) and it worked as expected. So, think it's a combination of networking and commands?

As I said I'll connect console before next scheduled restarts but would appreciate if you could look into it in the meantime. Maybe @bbqkees have some more insights into his ethernet observations too?

There is one strange thing I've noticed in Mosquitto broker log (between 2026-08-09 01:57:50 and 2026-08-09 02:21:01) though:

2026-08-09 00:31:21: New connection from 192.168.50.132:58114 on port 1883.
2026-08-09 00:31:21: Client esp32-d767b4fc [192.168.50.132:58027] disconnected: session taken over.
2026-08-09 00:31:21: New client connected from 192.168.50.132:58114 as esp32-d767b4fc (p4, c0, k60, u'mqttuser').
2026-08-09 00:57:48: Saving in-memory database to /data//mosquitto.db.
2026-08-09 01:27:49: Saving in-memory database to /data//mosquitto.db.
2026-08-09 01:57:50: Saving in-memory database to /data//mosquitto.db.
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0x7f9516f043a8]
goroutine 17 [running, locked to thread]:
github.com/jellydator/ttlcache/v3.(*Item[...]).Value(0x7f95174b9ce0?)
	/root/go/pkg/mod/github.com/jellydator/ttlcache/v3@v3.3.0/item.go:131 +0x28
github.com/iegomez/mosquitto-go-auth/cache.(*goStore).checkRecord(0xc000214980, {0x6fc23ac00?, 0xc00032ed50?}, {0xc000400d80, 0x7c}, 0x16?)
	/usr/src/mosquitto-go-auth/cache/cache.go:211 +0xf8
github.com/iegomez/mosquitto-go-auth/cache.(*goStore).CheckACLRecord(0xc000214980, {0x7f95174a60a0, 0x7f9517cddf40}, {0xc000322456?, 0x3f004000aac630?}, {0xc00032ed50?, 0x7f951640e4ec?}, {0xc00003ab58?, 0x7f94c87c2128?}, 0x1)
	/usr/src/mosquitto-go-auth/cache/cache.go:194 +0xa9
main.authAclCheck({0xc00003ab58?, 0xc0000bde38?}, {0xc000322456?, 0x6?}, {0xc00032ed50, 0x23}, 0x1)
	/usr/src/mosquitto-go-auth/go-auth.go:377 +0x14c
main.AuthAclCheck(0x55a453f35e10, 0x55a453f7bd60, 0x55a453f85310, 0x1)
	/usr/src/mosquitto-go-auth/go-auth.go:349 +0xe5
[02:21:00] INFO: Service restart after closing
[02:21:01] INFO: Starting mosquitto MQTT broker...
2026-08-09 02:21:01: Info: running mosquitto as user: root.
2026-08-09 02:21:01: Warning: Mosquitto should not be run as root/administrator.
2026-08-09 02:21:01: Restored 146 base messages
2026-08-09 02:21:01: Restored 146 retained messages
2026-08-09 02:21:01: mosquitto version 2.1.2 starting
2026-08-09 02:21:01: Config loaded from /etc/mosquitto/mosquitto.conf.
2026-08-09 02:21:01: Bridge support available.
2026-08-09 02:21:01: Persistence support available.
2026-08-09 02:21:01: TLS support available.
2026-08-09 02:21:01: TLS-PSK support available.
2026-08-09 02:21:01: Restored 2 clients
2026-08-09 02:21:01: Restored 15 subscriptions
2026-08-09 02:21:01: Restored 0 client messages
2026-08-09 02:21:01: Websockets support available.
2026-08-09 02:21:01: Loading plugin: /usr/share/mosquitto/go-auth.so
2026-08-09 02:21:01:  ├── Username/password checking enabled.
2026-08-09 02:21:01:  ├── TLS-PSK checking enabled.
2026-08-09 02:21:01:  └── Extended authentication not enabled.
2026-08-09 02:21:01: Plugin has registered to receive 'reload' events.
2026-08-09 02:21:01: Plugin has registered to receive 'basic-auth' events.
2026-08-09 02:21:01: Plugin has registered to receive 'acl-check' events.
2026-08-09 02:21:01: Plugin has registered to receive 'psk-key' events.
2026-08-09 02:21:01: Opening ipv4 listen socket on port 1883.
2026-08-09 02:21:01: Opening ipv6 listen socket on port 1883.
2026-08-09 02:21:01: Opening ipv4 listen socket on port 1884.
2026-08-09 02:21:01: Opening ipv6 listen socket on port 1884.
2026-08-09 02:21:01: Opening ipv4 listen socket on port 8883.
2026-08-09 02:21:01: Opening ipv6 listen socket on port 8883.
2026-08-09 02:21:01: Opening ipv4 listen socket on port 8884.
2026-08-09 02:21:01: Opening ipv6 listen socket on port 8884.
2026-08-09 02:21:01: mosquitto version 2.1.2 running
2026-08-09 02:21:01: New connection from ::1:39340 on port 1883.
2026-08-09 02:21:01: Protocol error from ::1:39340: First packet not CONNECT (0A).
2026-08-09 02:21:01: Client ::1 [::1:39340] disconnected: protocol error.
[02:21:01] INFO: Successfully send discovery information to Home Assistant.
[02:21:01] INFO: Successfully send service information to the Supervisor.
2026-08-09 02:21:02: New connection from 172.30.33.1:46276 on port 1883.
2026-08-09 02:21:02: New client connected from 172.30.33.1:46276 as mqtt-explorer-52dfac40 (p4, c1, k60, u'vlasti').
2026-08-09 02:21:10: New connection from 172.30.32.1:35711 on port 1883.
2026-08-09 02:21:10: New client connected from 172.30.32.1:35711 as 3XVRb7LOus9f40Y1LrZrIt (p5, c1, k60, u'homeassistant').
2026-08-09 02:51:02: Saving in-memory database to /data//mosquitto.db.
2026-08-09 03:21:03: Saving in-memory database to /data//mosquitto.db.
2026-08-09 03:51:04: Saving in-memory database to /data//mosquitto.db.
2026-08-09 04:21:05: Saving in-memory database to /data//mosquitto.db.
2026-08-09 04:51:06: Saving in-memory database to /data//mosquitto.db.
2026-08-09 05:21:07: Saving in-memory database to /data//mosquitto.db.
2026-08-09 05:51:08: Saving in-memory database to /data//mosquitto.db.
2026-08-09 06:21:09: Saving in-memory database to /data//mosquitto.db.
2026-08-09 06:51:10: Saving in-memory database to /data//mosquitto.db.
2026-08-09 07:21:11: Saving in-memory database to /data//mosquitto.db.
2026-08-09 07:51:12: Saving in-memory database to /data//mosquitto.db.
2026-08-09 07:59:39: New connection from 192.168.50.132:51190 on port 1883.
2026-08-09 07:59:39: Client esp32-d767b4fc [(null):0] disconnected: session taken over.
2026-08-09 07:59:39: New client connected from 192.168.50.132:51190 as esp32-d767b4fc (p4, c0, k60, u'mqttuser').

never seen that before and it might be completely unrelated. But it also clearly shows that EMS-ESP reconnected at 2026-08-09 00:31:21when network came back, but did not reconnect after scheduled reboot until power cycle at 07:59:39

[VlastiBroucek]

I think setting val_tpl to None or to Unix epoch time should suffice. I notice that some cheaper routers use epoch after cold reboot and before they get clock from NTP.

[MichaelDvP]

You can test with https://github.com/MichaelDvP/EMS-ESP32/releases/tag/latest and power on reset.
(i don't use HA, so can't test).

[VlastiBroucek]

It wasn't urgent, but I will test tomorrow. Getting late here now.

[VlastiBroucek]

@MichaelDvP, that works absolutely perfect.

[proddy]

confirmed the "None" works great, no more warnings in HA. Thanks @MichaelDvP for the fix, even though you don't use Home Assistant (yet!)

[VlastiBroucek]

There is another issue I noticed being different from 3.8.x branch.
There are several sensors that during reboot send zero value to HA via MQTT. I have not notice it before, just with core3 dev and not even in dev.0 and dev.1 but cannot be sure.
I have noticed that whenever I reboot, there are zero values coming for at least following sensors (there might be more):

• boiler_nrgtotal
• boiler_curflowtemp
• boiler_dhw_curtemp

I am guessing it is because "val_tpl": "{{value_json['nrgtotal'] if value_json['nrgtotal'] is defined else 0}}",

There probably was not else 0 in the past, hence HA just had missing value. But what happens now is HA records:

real value
0
real value

which then looks messy in graphs (you can see there two soft and one hard restart of EMS-ESP) and in a first case can completely mess statistics.

Looking to the code, it seems the val_tpl used to be like that for a while. So I am now guessing that perhaps due to some internal changes, mqtt starts working much faster and the values are not populated yet which I think is supported by:

2026-08-11T09:36:06.425 I 14: [mqtt] MQTT connected
2026-08-11T09:36:08.854 I 15: [system] NTP connected
2026-08-11T09:36:12.268 I 16: [emsesp] Detected EMS device: boiler (0x08)
2026-08-11T09:36:12.420 I 17: [emsesp] Detected EMS device: controller (0x09)
2026-08-11T09:36:12.585 I 18: [emsesp] Detected EMS device: thermostat (0x18)

Would it be possible to wait with starting MQTT until all devices are detected, values populated etc? That would probably save lots of issues with weird values sent to HA.

It would also fix
2026-08-11 09:33:34.095 WARNING (MainThread) [homeassistant.components.mqtt.climate] Invalid modes mode: off
that now appears again regularly and is IMHO caused by the fact that MQTT starts way before anything else.

[MichaelDvP]

How about

Typical AI generated ;-(

1. first telegrams received help nothing, we need all telegrams for all values. Only way is to active request every telegram and wait the answer, blows the tx queue and on 4M systems the memory.
2. HA config is retained in broker, we send it as a value is received first time, but the old one exists before. If you clean the homeassistant configs in mqtt before starting ems-esp you'll see only valid values.

I don't see any change in dev.3 regarding the mqtt values,only mqtt changes are bootttime and mqtt disconnect for non-psram systems with mqtt running sync. The default fallback is the same as in 3.8.x.

Let's wait for proddy is back, he has HA running and can check different solution.

[VlastiBroucek]

I think that's for the best...

Thanks for all the extra info. It helps...

[VlastiBroucek]

Hi @MichaelDvP, I have tried your dev.4 and using None instead of 0 helped. No drops in the data now.

But, I think we should still wait for @proddy - there is a new MQTT related issue (#3189) reported by someone else.

[MichaelDvP]

Good. It is also working for climate mode, or do you get now Invalid modes mode: None?

[VlastiBroucek]

Good question. No I have not seen any climate related error so it seems to be working for it too...

[fragger42]

I found another issue in 3.9.0 dev3 (see my system info in #3189): In order for cooling for my Bosch CS5800i to work, I have to send "RT800" first to thermostat/hc/control and afterwards a value for temperature and humidity (see https://emsesp.org/de/Special-Functions ). This leads to a "request failed" and in the log

2026-08-12T08:59:14.906 W 403: [command] Command control: RT800 failed (Error)
2026-08-12T08:59:14.906 W 404: [emsesp] Command 'Set_RT800Control': Command control: RT800 failed (Error)
2026-08-12T08:59:14.906 E 405: [emsesp] Action 'executeCommand' failed

Sending temperature and humidity works without an error and it works in the kind of that it triggers the special function for a virtual RT800 to come up so it is more a cosmetical issue for me.

The same happens when I try to change the thermostat/hc/control via the normal GUI. I can set it to Off successfully but it is not possible to set it to RT800 again. It seems to not send out the value?

[MichaelDvP]

This leads to a "request failed" and in the log

You've set controlin the command field, commands should always be <device>/<optional_hc>/<command>, see http://ems-esp.local/api/thermostat/commands` for a list of thermostat commands.

he same happens when I try to change the thermostat/hc/control via the normal GUI. I can set it to Off successfully but it is not possible to set it to RT800 again. It seems to not send out the value?

Please set status->systemlog to log_all and then try to change the value in the webUI->devices->thermostat->hc1 control
Your system info shows the virtual thermostat RT800/RC220 with handlers received, so the control was set.

[fragger42]

No I did not set only control. I send it like this:

A Log with "ALL" does not really bring up anything more on info:

2026-08-12T10:59:39.215 W 30: [command] Command control: RT800 failed (Error)
2026-08-12T10:59:39.215 W 31: [emsesp] Command 'Set_RT800Control': Command control: RT800 failed (Error)
2026-08-12T10:59:39.215 E 32: [emsesp] Action 'executeCommand' failed
2026-08-12T10:59:40.522 T 33: [emsesp] boiler(0x08) B all(0x00), UBAMonitorSlowPlus2(0xE3), data: 00 00 00 00 00 00 00 00 00 00 00 00 EE 00 00 00 00 00 00 00
2026-08-12T10:59:40.712 T 34: [emsesp] boiler(0x08) B all(0x00), UBAMonitorFastPlus(0xE4), data: 00 00 EE 00 00 00 00 00 00 00 00 01 EE 00 00 12 00 02 11 (offset 6)
2026-08-12T10:59:40.883 T 35: [emsesp] boiler(0x08) B all(0x00), UBAMonitorFastPlus(0xE4), data: 00 00 (offset 36)
2026-08-12T10:59:40.138 T 36: [emsesp] boiler(0x08) B all(0x00), UBAMonitorWWPlus(0xE9), data: 37 02 30 02 30 00 00 00 00 46 3C 00 00 00 00 00 00 00 00 00 00 00 00 37
2026-08-12T10:59:49.960 T 37: [emsesp] thermostat(0x10) W boiler(0x08), ?(0xE7), data: 01 01 00
2026-08-12T10:59:49.985 T 38: [emsesp] thermostat(0x10) W boiler(0x08), ?(0x02EA), data: 00
2026-08-12T10:59:49.019 T 39: [emsesp] thermostat(0x10) W boiler(0x08), ?(0x04F2), data: 01 5A 00 00 01
2026-08-12T10:59:49.061 T 40: [emsesp] thermostat(0x10) B all(0x00), ?(0x0506), data: 00 00 00 00 00 00 00 00 03
2026-08-12T10:59:49.258 T 41: [emsesp] thermostat(0x10) B all(0x00), ?(0x0507), data: 00 00 00 00 00 00 00 00
2026-08-12T10:59:50.422 W 42: [command] Command control: RT800 failed (Error)
2026-08-12T10:59:50.422 W 43: [emsesp] Command 'Set_RT800Control': Command control: RT800 failed (Error)
2026-08-12T10:59:50.422 E 44: [emsesp] Action 'executeCommand' failed
2026-08-12T10:59:50.497 T 45: [emsesp] thermostat(0x10) B all(0x00), RC300Monitor(0x02A5), data: 80 00 40 25 5A 00 25 00 00 00 00 03 00 00 00 00 00 00 00 11
2026-08-12T10:59:50.702 T 46: [emsesp] thermostat(0x10) B all(0x00), RC300WWmode2(0x031D), data: 00 00 00 00 00 00 00 00 01 02 50 0A
2026-08-12T10:59:50.900 T 47: [emsesp] thermostat(0x10) B all(0x00), ?(0x0508), data: 00 00 00 00 00 00 00 00
2026-08-12T10:59:50.136 T 48: [emsesp] boiler(0x08) B all(0x00), UBAMonitorSlowPlus2(0xE3), data: 00 00 00 00 00 00 00 00 00 00 00 00 EE 00 00 00 00 00 00 00
2026-08-12T10:59:50.326 T 49: [emsesp] boiler(0x08) B all(0x00), UBAMonitorFastPlus(0xE4), data: 00 00 EE 00 00 00 00 00 00 00 00 01 ED 00 00 12 00 02 11 (offset 6)
2026-08-12T10:59:51.497 T 50: [emsesp] boiler(0x08) B all(0x00), UBAMonitorFastPlus(0xE4), data: 00 00 (offset 36)
2026-08-12T10:59:51.740 T 51: [emsesp] boiler(0x08) B all(0x00), UBAMonitorWWPlus(0xE9), data: 37 02 30 02 30 00 00 00 00 46 3C 00 00 00 00 00 00 00 00 00 00 00 00 37

The other two entries are entered the same way and work fine:

Changing it via the devices view like this:

brings also the same error and the log looks pretty same and useless:

2026-08-12T11:02:49.914 T 165: [emsesp] thermostat(0x10) W boiler(0x08), ?(0xE7), data: 01 01 00
2026-08-12T11:02:49.939 T 166: [emsesp] thermostat(0x10) W boiler(0x08), ?(0x02EA), data: 00
2026-08-12T11:02:49.973 T 167: [emsesp] thermostat(0x10) W boiler(0x08), ?(0x04F2), data: 01 5A 00 00 01
2026-08-12T11:02:49.016 T 168: [emsesp] thermostat(0x10) B all(0x00), ?(0x0506), data: 00 00 00 00 00 00 00 00 03
2026-08-12T11:02:49.030 W 169: [command] Command control: RT800 failed (Error)
2026-08-12T11:02:49.212 T 170: [emsesp] thermostat(0x10) B all(0x00), ?(0x0507), data: 00 00 00 00 00 00 00 00
2026-08-12T11:02:50.474 T 171: [emsesp] thermostat(0x10) B all(0x00), RC300Monitor(0x02A5), data: 80 00 40 25 5A 00 25 00 00 00 00 03 00 00 00 00 00 00 00 11
2026-08-12T11:02:50.680 T 172: [emsesp] thermostat(0x10) B all(0x00), RC300WWmode2(0x031D), data: 00 00 00 00 00 00 00 00 01 02 50 0A
2026-08-12T11:02:50.915 T 173: [emsesp] thermostat(0x10) B all(0x00), RC300Monitor(0x02A5), data: 03 00 00 00 00 00 00 00 00 00 00 FF 00 21 00 00 00 FF 00 00 00 00 00 01 54 (offset 20)

Sending the remotetemp works:

2026-08-12T11:06:16.242 I 270: [command] Called command thermostat/remotetemp (Raumtemperatur Remote) with value 23 and id 1 on device 0x10
2026-08-12T11:06:16.347 T 271: [emsesp] thermostat(0x38) W thermostat(0x10), RemoteTemp(0x042B), data: 00 E6 08 FC 01 09

[MichaelDvP]

Yes, it's a bug in handling the this command for the UI800 thermostat since v3.8.3-dev.5, fixed now in my 3.9.0-dev.6.(also made source for 3.8.4-patch.2)

[fragger42]

I can confirm, that this works now in dev.6. Thanks a lot!

[VlastiBroucek]

Unfortunately, the reboot issue (#3181 (comment)) came back.

I tested twice after @proddy posted this (#3181 (reply in thread)) and it was OK.

However, this morning it failed again. Then I tried to replicate it later on, and it failed again. So, it must have been re-introduced somewhere between "official" dev.3 and dev.6 created by @MichaelDvP in response to other issues with MQTT. I am actually suspicious that reverting one of the changes in dev.3 (#3189 (comment)) could be causing it.

Why? I am attaching full console log later, but here are some observations:

1. I start console
2. at 09:45, I restart my router
3. shortly after that I see MQTT disconnect, Host unreachable, NTP disconnect

[09:45:50.495] �[0;92m�[1mems-esp�[0m:$ �[0G�[K2026-08-16T09:45:53.256 W 545: [mqtt] �[0;31mMQTT disconnected: TCP
[09:45:53.454] �[0m�[0;92m�[1mems-esp�[0m:$ [7028262][E][NetworkClient.cpp:252] connect(): connect on fd 49, errno: 118, "Host is unreachable"
[09:45:56.133] �[0G�[K2026-08-16T09:45:56.940 T 546: [emsesp] boiler(0x08) B all(0x00), UBAMonitorFast(0x18), data: 00 02 35 00 00 00 22 40 C0 01 90 80 00 80 00 FF FF FF 00 00 00 00 00 00 00
[09:45:56.147] �[0;92m�[1mems-esp�[0m:$ �[0G�[K2026-08-16T09:45:56.026 W 547: [network] �[0;31mEthernet connection lost
[09:45:56.224] �[0m2026-08-16T09:45:56.026 W 548: [system] �[0;31mNTP disconnected

4. Again after about 1 minute

[09:46:36.848] �[0;92m�[1mems-esp�[0m:$ �[0G�[K2026-08-16T09:46:41.026 I 571: [network] �[0;33mNetwork connected via Ethernet (IP: 192.168.50.132)
[09:46:41.243] �[0m2026-08-16T09:46:41.026 I 572: [emsesp] �[0;33mStarting mDNS Responder service for ems-esp.local
[09:46:41.251] �[0m2026-08-16T09:46:41.026 I 573: [emsesp] �[0;33mStarting NTP service
[09:46:41.256] �[0m�[0;92m�[1mems-esp�[0m:$ �[0G�[K2026-08-16T09:46:41.316 I 574: [mqtt] �[0;33mMQTT connected
[09:46:41.523] �[0m�[0;92m�[1mems-esp�[0m:$ �[0G�[K2026-08-16T09:46:46.886 T 575: [emsesp] boiler(0x08) B all(0x00), UBAMonitorFast(0x18), data: 00 02 33 00 00 00 22 40 C0 01 8E 80 00 80 00 FF FF FF 00 00 00 00 00 00 00

5. From that point, console does not react to anything... No keystrokes nothing. There is no heartbeat coming to HA, no new data, nothing seen in MQTT Explorer running in HA... Even my three temperature sensors are lost from HA
6. I wait until 10:00 when EMS-ESP is scheduled to restart itself at 09:55 - nothing happens
7. I can connect to EMS-ESP via GUI, so I navigate to Status->System Log which is completely empty!!! Uptime since I installed dev.6, so over 36 hours.
8. I wait another 5 minutes and do power off/power on restart. Everything comes back and works OK.

I am not going to speculate about what is causing it, but it is absolutely weird. Happened twice - once unintentional, my routine reboot and then simulating the same sequence to collect whatever is possible to collect.

One thing I know for sure - it cannot be my set up. I have been doing exactly this for over a year and it started only with core3. Oh actually, I did one change based on @proddy remark - I changed AP from its default to "Never".

esp32_debug_20260816.log

[proddy]

@VlastiBroucek I tried to reproduce this and couldn't. I rebooted the router (Unifi USG), waited 10 minutes and then restarted EMS-ESP. It all came back nice. Are you able to reproduce this every time?

[VlastiBroucek]

@proddy , I just tried with dev.4 and surprise, surprise, everything worked OK. The only difference was that I did not use schedulers, just initiated reboots manually, first in the router, then in ems-esp. Will try again later today using schedulers.

Interestingly also, this time, after reboot, the log file in ems-esp GUI did not get cleared and I saw following (before rebooting):

2026-08-21T09:11:58.000 I 1: [emsesp] EMS-ESP version 3.9.0-dev.4
2026-08-21T09:11:58.000 I 2: [emsesp] Last system reset reason Core0: Software reset CPU, Core1: Software reset CPU
2026-08-21T09:11:58.000 I 3: [emsesp] Loaded board profile E32V2 (PSRAM: 4096 KB)
2026-08-21T09:11:58.000 I 4: [emsesp] Starting Commands service
2026-08-21T09:11:58.000 I 5: [emsesp] Starting Custom Entity service
2026-08-21T09:11:58.000 I 6: [emsesp] Starting Scheduler service
2026-08-21T09:11:58.000 I 7: [emsesp] Library loaded: 129 EMS devices, 569 device entities, 11 languages (en,de,nl,sv,pl,no,fr,tr,it,sk,cs)
2026-08-21T09:11:58.000 I 8: [temperaturesensor] Starting Temperature Sensor service
2026-08-21T09:11:58.000 I 9: [emsesp] Starting Web Server
2026-08-21T09:11:58.000 I 10: [emsesp] Starting Modules service
2026-08-21T09:12:07.141 I 11: [network] Network connected via Ethernet (IP: 192.168.50.132)
2026-08-21T09:12:07.141 I 12: [emsesp] Starting mDNS Responder service for ems-esp.local
2026-08-21T09:12:07.141 I 13: [emsesp] Starting NTP service
2026-08-21T09:12:07.929 I 14: [system] NTP connected
2026-08-21T09:12:08.530 I 15: [emsesp] Starting MQTT service
2026-08-21T09:12:08.575 I 16: [mqtt] MQTT connected
2026-08-21T09:12:14.511 I 17: [emsesp] Detected EMS device: boiler (0x08)
2026-08-21T09:12:14.889 I 18: [emsesp] Detected EMS device: controller (0x09)
2026-08-21T09:12:15.088 I 19: [emsesp] Detected EMS device: thermostat (0x18)
2026-08-23T08:28:10.477 W 51: [network] Ethernet connection lost
2026-08-23T08:28:10.477 W 52: [system] NTP disconnected
2026-08-23T08:28:10.484 W 53: [mqtt] MQTT disconnected: TCP
2026-08-23T08:28:57.947 I 54: [network] Network connected via Ethernet (IP: 192.168.50.132)
2026-08-23T08:28:57.947 I 55: [emsesp] Starting mDNS Responder service for ems-esp.local
2026-08-23T08:28:57.947 I 56: [emsesp] Starting NTP service
2026-08-23T08:28:58.485 I 57: [emsesp] Starting MQTT service
2026-08-23T08:28:58.525 I 58: [mqtt] MQTT connected
2026-08-23T08:29:02.947 W 59: [emsesp] versions.json: HTTP error code 0
2026-08-23T08:29:28.624 I 60: [system] NTP connected

in all previous cases, the log file was empty when I connected to GUI in the 10 minutes between reboots...

[VlastiBroucek]

Well, this is mystery now. If "proper" dev.4 is exactly same as was Michaels dev.8 then I don't know what to say.

I tested his dev.8 twice and it crashed twice (#3181 (reply in thread)).

However, I am not sure that it is exactly the same because of this in (#3181 (reply in thread)):

I've looked into the version check and changed to use the http_request from shuntingYard, so blocking can also be checked by calling from command/scheduler with same function. Also removes a lot of double code.

I now tested dev.4 three times and no problem. Beats me!

[MichaelDvP]

If "proper" dev.4 is exactly same as was Michaels dev.8 then I don't know what to say.

There were a few changes since my dev.8, i guess 88f258d makes the difference.

in all previous cases, the log file was empty when I connected to GUI in the 10 minutes between reboots...

I've missed that, so the main task was already blocked after router reboot.

026-08-23T08:29:02.947 W 59: [emsesp] versions.json: HTTP error code 0

I think this is at a time the LAN is up, but WAN has no connection. My router responses with http:302 in this case, yours does not answer (code 0)

Good that it seems to be solve now.

[VlastiBroucek]

Let's hope so...

[fragger42]

After 5 days with dev6 version, my MQTT does not update anymore since yesterday evening:

The system log is completely empty:

RAM seems ok:

There was no restart of network or any internet issues. I'm using wifi, not ethernet.

[VlastiBroucek]

There was no restart of network or any internet issues. I'm using wifi, not ethernet.

But there could have been WiFi dropouts... Or can you categorically rule those out? Your WiFi access point could give you some indication...

[fragger42]

The wifi access point (Unifi U7 Lite) is in the same room about 2 meters away. From the log of it, the device is connected since 12.08. 17:47, there are no disconnects recorded.
Another strange thing from my current status: I cannot restart EMS ESP from the GUI. When I press restart, it shows the restart window/animation ("Preparation" "EMS-ESP is restarting") but it still stays online and shows 5 day uptime. Probably I have to remove the EMS cable to restart it...

[VlastiBroucek]

Probably I have to remove the EMS cable to restart it...

That's correct... Only way to restart when this happens.

That strange thing is what's happening to me too...

So finally I know it's not me only... This is probably more serious than it appeared to be...

We all knew core3 will bring issues, let's hope we can quickly polish them out...

[VlastiBroucek]

@MichaelDvP, @proddy,

I have now tried Michael's dev.7 and still the same problem. And it seems quite a few other issues...

Some observations, also supported by @fragger42 post above.

• Loss of upstream network stops MQTT, System log (appears empty), prevents soft reboot
• Some limited testing suggests that disconnecting ethernet cable behaves differently than upstream network loss
• @fragger42 post suggests that it can happen even without network loss, perhaps over extended uptime...
• Interestingly one can still connect to GUI, but basically nothing works, not even possible to restart from GUI
• Only power cycling can get the device back working.

Yet again, this must be caused by core3 changes since I have been doing exactly the same successfully for more than year.

Should we create an issue for this as it appears to be rather significant for core3?

[proddy]

Hi @MichaelDvP , if you merge your v3.9.0-dev.8 into the EMS-ESP dev branch, I can take that as the base and start investigating what is causing the hanging states. I wil start with following @VlastiBroucek's steps and rebooting main Unifi network to see how it responds. And then the same tests with just throwing the EMS-ESP off the network to see if it's a DHCP timing issue.

I'll also look at the HA availability check and see if the None fix works everywhere

[MichaelDvP]

Should i change version back to dev.4 for official PR merge?
I've looked into the version check and changed to use the http_request from shuntingYard, so blocking can also be checked by calling from command/scheduler with same function. Also removes a lot of double code.
Still can't reproduce, even on rebooting the router a few times.

[proddy]

yes, please make it "3.9.0-dev.4". If I accept the merge now it'll create dev.8 and may confuse people.

[fragger42]

After a few days with the new official dev.4 I get a problem with MQTT again. It seems disconnected in HomeAssistant and the log shows

2026-08-25T12:07:39.345 I 8863: [mqtt] MQTT connected
2026-08-25T12:07:39.490 W 8864: [mqtt] MQTT disconnected: TCP
2026-08-25T12:07:41.490 I 8865: [emsesp] Starting MQTT service
2026-08-25T12:07:41.963 I 8866: [mqtt] MQTT connected
2026-08-25T12:07:42.106 W 8867: [mqtt] MQTT disconnected: TCP
2026-08-25T12:07:44.106 I 8868: [emsesp] Starting MQTT service
2026-08-25T12:07:44.573 I 8869: [mqtt] MQTT connected
2026-08-25T12:07:44.735 W 8870: [mqtt] MQTT disconnected: TCP
2026-08-25T12:07:46.735 I 8871: [emsesp] Starting MQTT service
2026-08-25T12:07:47.227 I 8872: [mqtt] MQTT connected
2026-08-25T12:07:57.346 W 8873: [mqtt] MQTT disconnected: TCP
2026-08-25T12:07:59.346 I 8874: [emsesp] Starting MQTT service
2026-08-25T12:07:59.794 I 8875: [mqtt] MQTT connected
2026-08-25T12:07:59.928 W 8876: [mqtt] MQTT disconnected: TCP
2026-08-25T12:08:01.928 I 8877: [emsesp] Starting MQTT service
2026-08-25T12:08:02.421 I 8878: [mqtt] MQTT connected
2026-08-25T12:08:02.570 W 8879: [mqtt] MQTT disconnected: TCP
2026-08-25T12:08:04.570 I 8880: [emsesp] Starting MQTT service
2026-08-25T12:08:05.042 I 8881: [mqtt] MQTT connected
2026-08-25T12:08:05.042 W 8882: [mqtt] MQTT disconnected: TCP
2026-08-25T12:08:07.042 I 8883: [emsesp] Starting MQTT service
2026-08-25T12:09:40.064 I 8884: [emsesp] Starting MQTT service
2026-08-25T12:09:40.557 I 8885: [mqtt] MQTT connected
2026-08-25T12:09:40.710 W 8886: [mqtt] MQTT disconnected: TCP
2026-08-25T12:09:42.710 I 8887: [emsesp] Starting MQTT service
2026-08-25T12:09:43.184 I 8888: [mqtt] MQTT connected
2026-08-25T12:09:53.305 W 8889: [mqtt] MQTT disconnected: TCP
2026-08-25T12:09:55.315 I 8890: [emsesp] Starting MQTT service
2026-08-25T12:09:54.762 I 8891: [mqtt] MQTT connected
2026-08-25T12:09:54.902 W 8892: [mqtt] MQTT disconnected: TCP
2026-08-25T12:09:56.902 I 8893: [emsesp] Starting MQTT service
2026-08-25T12:11:30.053 I 8894: [emsesp] Starting MQTT service
2026-08-25T12:11:30.522 I 8895: [mqtt] MQTT connected
2026-08-25T12:11:30.677 W 8896: [mqtt] MQTT disconnected: TCP
2026-08-25T12:11:32.677 I 8897: [emsesp] Starting MQTT service
2026-08-25T12:11:33.169 I 8898: [mqtt] MQTT connected
2026-08-25T12:11:43.285 W 8899: [mqtt] MQTT disconnected: TCP
2026-08-25T12:11:45.285 I 8900: [emsesp] Starting MQTT service
2026-08-25T12:11:46.753 I 8901: [mqtt] MQTT connected
2026-08-25T12:11:46.902 W 8902: [mqtt] MQTT disconnected: TCP
2026-08-25T12:11:48.902 I 8903: [emsesp] Starting MQTT service
2026-08-25T12:11:49.358 I 8904: [mqtt] MQTT connected
2026-08-25T12:11:59.468 W 8905: [mqtt] MQTT disconnected: TCP
2026-08-25T12:12:01.468 I 8906: [emsesp] Starting MQTT service
2026-08-25T12:12:01.939 I 8907: [mqtt] MQTT connected
2026-08-25T12:12:12.060 W 8908: [mqtt] MQTT disconnected: TCP
2026-08-25T12:12:14.060 I 8909: [emsesp] Starting MQTT service
2026-08-25T12:12:14.553 I 8910: [mqtt] MQTT connected
2026-08-25T12:12:14.688 W 8911: [mqtt] MQTT disconnected: TCP
2026-08-25T12:12:16.688 I 8912: [emsesp] Starting MQTT service

Actually, when I look into MQTT Explorer, it seems to still update the values but as "status=offline" in MQTT ems-esp, HomeAssistant ignores everything. Actually, "status" changes to "online" for a few milliseconds and gets offline again. Seems the same as I had in Ticket #3189. I never had this before 3.9.0 and I did not change anything in the network.

[proddy]

@fragger42 let's use #3189 to troubleshoot this.