E13 and MQTT only

[Lonestar78]

Dear visualapproach and team,

i still cannot get arround the E13 error, tried async Websocket as well as setting the timeout down to 100ms for Websocket. This breaks the web interface, but this is really not an issue.

I am wondering how much effort it would be to just build a robust MQTT only version, OTA enabled.
Configuration over config.h only.
What do you think? Is this worthwhile the effort?

Thanks and kind regards
Christian

[visualapproach]

I'll look at it. What level shifter do you use?

[Lonestar78]

Hi, txs0108e, as recommend.
Sorry for not getting back faster.

[Lonestar78]

Ok, i deep-dived the E13 Error some more. I can trigger it by bad Wifi Connectivity and lonng times for reconnects, this blocks the main loop and therefore interrupts the serial communication between display and control unit. So how about either having the WIFI reconnect somehow in a non blocking way? Or...Have the serial communication to somehow run over interrupts to have priority over Wifi connectivity. Not sure how to do that properly though.

Second idea: In the PCB layout we want might to add a relay in order to reset power to the display, which, at least in my case resets the errors by restarting the display.

[visualapproach]

WIFI reconnect somehow in a non blocking way

I'm not sure how to do that if it isn't already. I thought it was the websockets library that was blocking, rather than the wi-fi core? Building a MQTT only version wouldn't help if it's the wi-fi that's the problem.

Have the serial communication to somehow run over interrupts to have priority over Wifi connectivity

Maybe. I have to look into it. I guess the most important thing is to never stop sending messages to DSP to keep it from throwing errors.

Second idea: In the PCB layout we want might to add a relay in order to reset power to the display, which, at least in my case resets the errors by restarting the display.

I exposed the D0/D8 GPIO pins to be able to expand the PCB functionality in cases like this. I don't think I want to add it to the PCB though because it will be oversize and more expensive. And relays needs some power to drive the coil. Not sure the power supply will cope. I rather leave it to the users to find out :-)

Third idea: if Eried (or me or someone else) makes an ESP32 port it would take care of blocking problems since it has two cores. One for wi-fi and one for the application.
I appreciate your constructive thoughts and suggestions. Thank you.

[Lonestar78]

I assume it is the wifi, because i removed everything from the 4 wire version except MQTT. In a good wifi strength scenario it works for some time until presumably a reconnect happens (then E13). In a bad Wifi Strength scenario i get E13 almost immediately.

I have not dived into the protocoll itselv yet between DSP and CTRL, but i read somewhere there needs to be communication at least every 500ms. So if data is unchanged maybe install a timer on when last send and force to send same package again triggered via interrupt if approaching the 500ms....

and thanks for the pin hint, i totally forgot about that.

[visualapproach]

You can check if latest dev version is working better.