random Disconnects from Door Motor - how to debug?

[Tysonpower]

I got some issues that after some Hours the Garage Door motor shuts down the BUS power and seems to have disconnected from the Device. The Motor doesen't show any error, so it should be a clean shutdown initiated from the Deice right? Is there maybe such a function in the firmware of the ESP?

I'm not sure exactly what causes this problem and i also would like to debug it, but how? i saw that there are LOGD commands in the hoermann.h file, but how do i activate the debug mode? Also: where are the outputted? on the Serial bus?

[Gifford47]

Hi!

As far as i know we don´t have such a "shutdown" function implemented. The only thing that the motor automatically does is to detach any external equipment if any issues appear on the hcp bus.

But some questions before: which motor do you have? which branch/release did you use? which peripherals (bme280, HCsr04, ...) did you use?

The Firmware has two different log options:

• esp32 core logging which is enabled by default and prints it output on serial console.
• mqtt debugging which currently only outputs reboot reason and a hörmann state message under "DEBUGTOPIC" in configuration.h

if you can´t get any effort of it, try the wifimanager branch which does run (a bit) another timing.

but it seems to me that the root cause is a hardware issue. maybe a unstable supply voltage or a spooky rs485 module?

[Tysonpower]

thx for the reply, i use no external sensors and the master branch, motor is a promatic 4.

I will update to the latest Firmware, on master, if this doesen't help i will try the wifi manager one.

Will keep you updated., yesterday it worked fine for 3h.

[Gifford47]

When no error 07 message appears, it means that the esp is always responding to the bus. So what do you exactly mean with "disconnect"? Doesn´t the esp respond to any mqtt command but the motor can still operate manually? Is the "disconnect" related to any command or movement of the motor?

[Tysonpower]

I connected the ESP yesterday evening to the Motore, had a look after 2h, still worked fine. This Morning i saw that it was offline, walked to my garage from the back door (without opening it) and the ESP had no Power anymore. The Motor didn't display the 07 error (blinking red on my promatic motor). The LED was green on the Motor and i was able to use my normal remote control to open and close it. then is just initiated another bus scan over the dip switch (without disconnecting the cable) and it works fine again since then so far.

[Tysonpower]

Short update, flashed the same Hardware with the asyncwifimanager branch and all works fine, any idea what the issue could be?

[14yannick]

@kfroeschl is there maybe something missing in the modbus implementation needed for the promatic 4 doors which is present in the asyncwifimanager code?

[14yannick]

@Tysonpower did you used my dev branch in the past. Do you have also the disconnection just to make sure that we haven't an issue on the code takeover we have done?

[Tysonpower]

@Tysonpower did you used my dev branch in the past. Do you have also the disconnection just to make sure that we haven't an issue on the code takeover we have done?

wil give your dev branch a test tomorrow

[Tysonpower]

@14yannick Gave your branch a good test and all works fine, so maybe something broke on the merge?

[kfroeschl]

It seems that AsyncMqttClient and AsyncWebServer uses AsyncTcp and depending on the compile option "CONFIG_ASYNC_TCP_RUNNING_CORE" it either pins all the work to a specific core (xTaskCreatePinnedToCore) or uses xTaskCreate which could also run on the engine core that handles modbus.

per default it uses xTaskCreate.

So my assumption is that at some point the esp was too busy and scheduled mqtt/http onto the MODBUS core which broke the communication and shut down the power.

It can be tried to pin http/mqtt to the core 0 (-D CONFIG_ASYNC_TCP_RUNNING_CORE=0)

Though i cannot gurarantee for a stable behaviour of http/mqtt then.

What are your thoughts?

[Tysonpower]

It seems that AsyncMqttClient and AsyncWebServer uses AsyncTcp and depending on the compile option "CONFIG_ASYNC_TCP_RUNNING_CORE" it either pins all the work to a specific core (xTaskCreatePinnedToCore) or uses xTaskCreate which could also run on the engine core that handles modbus.

per default it uses xTaskCreate.

So my assumption is that at some point the esp was too busy and scheduled mqtt/http onto the MODBUS core which broke the communication and shut down the power.

It can be tried to pin http/mqtt to the core 0 (-D CONFIG_ASYNC_TCP_RUNNING_CORE=0)

Though i cannot gurarantee for a stable behaviour of http/mqtt then.

What are your thoughts?

The Strange thing is that the DEV Version from @14yannick also uses the AsyncMqttClient and works just fine. Also checked the Build options and there are none specified.

[14yannick]

Yes I just went trough the code change between the code taken over and there is non. Meaning the code has been taken over 1 by 1. The only difference is that it has been wrapped in a #ifnotdef who should have no impact on it.

[Tysonpower]

Yes I just went trough the code change between the code taken over and there is non. Meaning the code has been taken over 1 by 1. The only difference is that it has been wrapped in a #ifnotdef who should have no impact on it.

Which ifdef are you referring to?

[14yannick]

I meaning line 1 and 2 from this file hoermann.h

[Tysonpower]

i flashed a board again with the newest dev branch here, let's see what it does after some hours

[Tysonpower]

not sure why but in the newest version of this repo all works fine, only had a few MQTT only disconnects, but this could also be due to having multiple devices hitting my mqtt server from Testing PCBs :)