Is it possible to get debug logs

[sorb42]

Hi,
currently I am facing the following situation:
I uploaded the configuration to ESPBell-MAX in order to connect to my WiFi. For testing purpose I connect "ET to battery +" to wake up the device. This works initially, the device is also detected in Homeassistant and properly configured.

When I connect "ET to battery +" for a second time, I don't get any MQTT message anymore. Also the "PW" LED stays active... it doesn't shut off after the configured 15 seconds. I have to remove the battery to power down the ESPBell-MAX. Even after re-insterting the battery, connecting "ET to battery +", it won't send any MQTT messages and won't power down the device. It will only work again, after several hours of downtime. Then it will only work for one single message and any further triggers will bring the device in the same state as described above.

Is there any way to debug what is happening and why it is either not sending messages, or not shutting down the device? Maybe some way to get log output during operation?

[PricelessToolkit]

Hi,

Let's go through a few steps to better understand the issue:

1. "ET to battery+" – Are you connecting it briefly (momentary connection) or is it a hard, continuous connection?
2. During the initial test, did the device power off automatically as expected?
3. How are you monitoring the MQTT messages – using MQTT Explorer or directly from Home Assistant?
4. When testing the second time, what is the status of the bell sensor in Home Assistant? Does it show "Closed" or "Open"?
5. Have you made any changes to "bell status" or sent any commands from Home Assistant before the second test?

The ESPBell-MAX uses two MQTT topics:

• homeassistant/binary_sensor/espbell-max/state:

  • It publishes "on" when triggered and "off" just before the device shuts down.
  • In Home Assistant, this corresponds to the "open" and "closed" states.

• homeassistant/sensor/espbell-max/command:

  • This topic is used to clear previous commands by publishing "00" before the shutdown.

Could you please check the following?

• Verify if the "command" topic exists.
• Check the payload of the "state" topic during and after the trigger.

This information will help us narrow down the root cause of the behavior.

[sorb42]

Thanks for the quick reply.

1. "ET to battery+" – Are you connecting it briefly (momentary connection) or is it a hard, continuous connection?
   ==> connecting briefly, like simulating pushing the doorbell button
2. During the initial test, did the device power off automatically as expected?
   ==> for the first test it powers off after the predefined 15 seconds
3. How are you monitoring the MQTT messages – using MQTT Explorer or directly from Home Assistant?
   ==> using a MQTT client like MQTT Explorer (actually I'm using MQTTX) directly connecting to the Mosquitto server inside HA.
4. When testing the second time, what is the status of the bell sensor in Home Assistant? Does it show "Closed" or "Open"?
   ==>
5. Have you made any changes to "bell status" or sent any commands from Home Assistant before the second test?
   ==> no, there are interactions from HA towards ESPBell

Both command and state topics exist. See attached JSON files for the received messages.

I just took a closer look at the timings. Between connecting "ET and battery+" and actually receiving the MQTT message, it takes about 20 seconds. The devices powers down right after the messages are sent out. You can see in the MQTT logs, that they all arrive more or less at the same time. Hence that state = ON is only for a very short period of time.

While debugging I had 2 different error scenarios. Always started with removing the battery from ESPBell-MAX to have the same starting point:

Error Scenario 1:

• I could only trigger one event... this didn't contain a state=off (see screenshots and log)
• Second trigger didn't send out any event and device didn't power off

error1_mqtt_log.json

Error Scenario 2:

• I could trigger 3 events... all looked more or less the same. Strange behavior: state=off is sent twice.
• triggering a 4th time, didn't send out any events and the device didn't power off.

error2_mqtt_log.json

My network shows the device as connected to the WiFi, but I don't know the timeout it has to mark a device as offline.
I'm using a fixed IP address in ESPBell, so no DHCP roundtrip.

[PricelessToolkit]

Thanks for the detailed tests. If the device can power off the first time, it means the hardware is working properly. The issue may be related to one of the following:

1. The Wi-Fi channel might be changing, preventing the device from connecting to Wi-Fi (and therefore from subscribing to or publishing topics).
2. For another reason, it might not be publishing to the state topic.

Please try the following additional tests:

1. Publish 11 to the /command topic and then test it as normal.
2. Try the latest code I added, which includes changes to the delays between operations and added debug prints to Serial.
   "ESPBell-MAX_MQTT_Auto_Discovery_Test"
3. If none of this works, give me 1-2 days to replicate the behavior so I can find out what's going on.

ESPBell-MAX_MQTT_Auto_Discovery_Test Repository

[PricelessToolkit]

added some config in config.h which will help with debugging.

// Connection timeouts (in milliseconds)
// If the board cannot connect to WiFi within TimeToConnectWIFI, it powers off.
const long TimeToConnectWIFI = 30000;
// If the board cannot connect to the MQTT server within TimeToConnectMQTT, it powers off.
const long TimeToConnectMQTT = 40000;

[sorb42]

Well, it might take some time to give you an update! :(
Seems I killed my ESPBell after updating, when trying to read the serial log... not sure what happened in detail, but it seems one of the cables created a shortcut.
Will need to get a new ESPBell. Ordering might take some time.

[sorb42]

Sorry for the late reply. I finally had the time to do some more debugging with my new device.
I connect ESPBell MAX via the USB-TTL 3.3v adapter to my mac, to get the debug logs (no Li-Ion battery connected).

• As soon as I plug the USB-TTL 3.3v adapter into the mac, the power LED on the ESPBell board lights up.
• After ~25 seconds I get the first 3 lines of below log (I didn't shortcut any wires to simulate ringing bell)
  • WiFi connection status: 1
  • Attempting MQTT connection...Buffer Size increased to 380 byte connected
  • Message arrived [homeassistant/sensor/espbell-max/command] 00```
• After ~15 seconds it starts to constantly print the following 4 lines, over and over again in an endless loop.
  • Reseting Bell State to off
  • Reseting Open Command to 00
  • UpTime reached. Powering OFF.
  • Message arrived [homeassistant/sensor/espbell-max/command] 00
• the power LED stays on and I continuously get the log entries until I unplug the USB.

I only changed my wifi settings in the config.h file, I didn't change any of the code logic.

The "full" log looks like this:

WiFi connection status: 1
Attempting MQTT connection...Buffer Size increased to 380 byte
connected
Message arrived [homeassistant/sensor/espbell-max/command] 00
Reseting Bell State to off
Reseting Open Command to 00
UpTime reached. Powering OFF.
Message arrived [homeassistant/sensor/espbell-max/command] 00
Reseting Bell State to off
Reseting Open Command to 00
UpTime reached. Powering OFF.
Message arrived [homeassistant/sensor/espbell-max/command] 00
Reseting Bell State to off
Reseting Open Command to 00
UpTime reached. Powering OFF.
Message arrived [homeassistant/sensor/espbell-max/command] 00
Reseting Bell State to off
Reseting Open Command to 00
UpTime reached. Powering OFF.
Message arrived [homeassistant/sensor/espbell-max/command] 00
Reseting Bell State to off
Reseting Open Command to 00
UpTime reached. Powering OFF.
Message arrived [homeassistant/sensor/espbell-max/command] 00
Reseting Bell State to off
Reseting Open Command to 00
UpTime reached. Powering OFF.
...

[PricelessToolkit]

Is the WIFI channel fixed?

[PricelessToolkit]

I have the impression that the "fast wifi" method is not working, and it's scanning, for me it's 0.2s for all

[PricelessToolkit]

But with normal scanning it's 3-4 sec, not 20

[PricelessToolkit]

What about IP addresses? its outside of the DHCP range ? Is the gateway and netmask correct?

[sorb42]

WIFI channel is fixed, IP address is outside the DHCP range, gateway and netmask should be correct.
It is technically working. Just takes long to connect.
What would the connect command look like, if I would try with DHCP, just for testing purpose?

[sorb42]

After countless iteratoins of adjusting code and re-flashing to the device, I have found my issue:
The BSSID was wrong! My network managing software actually displays a wrong value.

I updated the code to connect only via SSID and password using DHCP, afterwards I printed the wifi details to the log. There I found, that ESP is displaying a different BSSID as my managing UI does. Updating my config.h file with the correct values finally worked.

It takes about 1.7 seconds to trigger the MQTT message when someone rings at the door. That is okay.

Thanks for all the support.