Discovery in HomeAssistant don't work with custom base topic

[saper-2]

Bug description
If I set custom base topic like home/esp/ems - because I want to have order in my MQTT (and not everything dumped 💩 under "root node"), the auto discovery don't work in HA. In MQTT-Explorer I see then this:

So basically it get too-deep nested for HA to understand this.

Steps to reproduce
Set MQTT topic in MQTT Settings: Base to be deeper than one level. For example: home/esp

Expected behavior
I can think of 3 ways to handle this:

1. If in MQTT: Base is character / then pull out from it "the last node name", and use it in discovery topics. E.g.: if I set home/esp/ems then extract from it ems and use it for discovery topics (homeassistant/sensor/ems/...) - this seems to be easiest to implement without much changes to UI.
2. Add new option: "root_topic" (by default can be empty), e.g.: if I set base to ems and root_topic to home/esp, then full topic will be /home/esp/ems-esp , if it's empty (default behavior) then full topic will be as usual /ems , and discovery topic /homeassistant/sensor/ems/.....
3. Use Hostname as base name, then MQTT: Base will serve as what I call "root topic", so the full topic would have "syntax": <mqtt_base>/<hostname> , e.g.: hostname=boiler , mqtt_base=home/basement ▶️ full topic /home/basement/boiler .

Device information
For now I tinkering with just the ESP32 - my boiler is in state of being installed so I can't connect to it (until it'll be fully connected to gas, central heating and water) - so there is no EMS devices.

{
  "System Status": {
    "version": "3.4.1",
    "uptime": "000+00:27:34.484",
    "freemem": 179,
    "reset reason": "Power on reset / APP CPU reset by PRO CPU"
  },
  "Network Status": {
    "connection": "WiFi",
    "hostname": "ems",
    "RSSI": -70,
    "IPv4 address": "192.168.0.000/255.255.255.0",
    "IPv4 gateway": "192.168.0.000",
    "IPv4 nameserver": "192.168.0.000",
    "static ip config": false,
    "enable IPv6": false,
    "low bandwidth": false,
    "disable sleep": false,
    "AP provision mode": "disconnected",
    "AP security": "wpa2",
    "AP ssid": "ems-esp"
  },
  "NTP Status": {
    "network time": "connected",
    "enabled": true,
    "server": "192.168.0.000",
    "tz label": "Europe/Warsaw"
  },
  "OTA Status": {
    "enabled": false,
    "port": 8266
  },
  "MQTT Status": {
    "MQTT status": "connected",
    "MQTT publishes": 136,
    "MQTT publish fails": 0,
    "enabled": true,
    "client_id": "ems-esp",
    "keep alive": 60,
    "clean session": false,
    "base": "home/esp/ems",
    "discovery prefix": "homeassistant",
    "nested format": 2,
    "ha enabled": true,
    "mqtt qos": 0,
    "mqtt retain": false,
    "publish time boiler": 30,
    "publish time thermostat": 30,
    "publish time solar": 30,
    "publish time mixer": 30,
    "publish time other": 30,
    "publish time sensor": 30,
    "publish single": false,
    "publish2command": false,
    "send response": false
  },
  "Syslog Status": {
    "enabled": false
  },
  "Sensor Status": {
    "temperature sensors": 2,
    "temperature sensor reads": 660,
    "temperature sensor fails": 0,
    "analog sensors": 0,
    "analog sensor reads": 0,
    "analog sensor fails": 0
  },
  "API Status": {
    "API calls": 0,
    "API fails": 0
  },
  "Bus Status": {
    "bus status": "disconnected"
  },
  "Settings": {
    "board profile": "CUSTOM",
    "tx mode": 1,
    "ems bus id": 11,
    "shower timer": false,
    "shower alert": false,
    "rx gpio": 23,
    "tx gpio": 5,
    "dallas gpio": 18,
    "pbutton gpio": 0,
    "led gpio": 2,
    "hide led": false,
    "notoken api": false,
    "readonly mode": false,
    "fahrenheit": false,
    "dallas parasite": false,
    "bool format": 1,
    "bool dashboard": 1,
    "enum format": 1,
    "analog enabled": true,
    "telnet enabled": true
  },
  "Devices": []
}

Additional context
Add any other context about the problem here.

[proddy]

This is indeed a bug. In MQTT Discovery I'm using the base as the node (https://www.home-assistant.io/docs/mqtt/discovery/#discovery-topic) which is not allowed to used nesting sub nodes. I think the easiest fix here is to use the hostname instead of the base when building the Discovery topics. Does that fix it for you?

Also, FYI only, I run 90% of all my EMS-ESP tests without being connected to the EMS lines. First compile with the DEBUG flags uncommented in pio_local.ini and either

• using Linux (Windows WSL2 or plain linux distro) use make run
• upload to a plain ESP32

Then from the console (serial) type in test which loads some dummy devices and simulates all the MQTT and API calls.

[saper-2]

No problem, I was suggesting it too.

oh, just no wsl 😵 that's heresy 😄 .

Thanks for info, I'll see if I'm that desperate to grab the source and build it 😀 (I think VSCode w/h pio should do the trick too on windows, in any case I have some lying around machines with linux too so no problem).

Ps. Good that you have in README flashing cmd, because I'm not used to few separate files to flash at different addresses (A habit from esp8266 and tasmota - there is one binary, that is flashed from 0x000000000). Would be nice to have one big file just for flashing new devices, and for update like usual 🙃 .

[proddy]

Fixed in next release