Device stops accepting E1.31 packets and MQTT commands when MQTT is enabled as secondary input

[KHouse75]

--------- Instructions --------
Please provide answers directly below each section.
--------- Instructions ---------

ESPixelStick Firmware Version
4.0-beta5 and 4.0-ci12223533891

Hardware Version
Generic ESP8266 NodeMCU on an ESPixelNode and on Breadboard. Occurs on both.

Binary release or compiled yourself?
Binary Release

Operating System (and version)
Windows 11

Web Browser (and version)
Edge 131.0.2903.86

Access Point
Eero J010011 (2nd Gen), Linksys E2500. Occurs when using either

Describe the bug
I'm attempting to play fseq files from and SD card triggered by MQTT. When I have the primary input disabled or set to E1.31, the device will connect to my Mosquitto MQTT broker (2.0.11) and I can send MQTT commands. After a few seconds, minutes, etc, espixelstick will stop responding to MQTT commands and it also no longer responds to E1.31 packets. If I have have home assistant discovery enabled, it'll show the espixelstick connected but after seconds, minutes, etc, it'll show that the device became unavailable and I can no longer control it from there either. Same issue occurs if I disable home assistant discovery.

I've tried 3 different esp8266 devices, 2 different mqtt brokers on different machines, 2 different sd card readers, 2 different sd cards, different access point hardware and the same issue occurs.

No messages are displayed in serial console when the problem starts.

If disable MQTT as the secondary input, the device will receive E1.31 packets with no issues. I can come back hours later and send E1.31 packets and it'll receive and display the data on the pixels. The problem appears to only occur when MQTT is enabled even if I don't attempt to play an fseq file.

[MartinMueller2003]

Have you done any testing using Mosquitto broker? I do not have an HA install.

[KHouse75]

This is just odd. I used the same setup last year with no issues with MQTT. I haven't changed anything and I was using the same v4b5 espixelstick code. I've since tried with other mqtt software and had the same issue. I can see in the console that it just stops trying to connect to mqtt and that's when E1.31 stops as well. Nothing else in the console after that but I can access the web page and change settings, reboot, etc.

I ended up just disabling MQTT, running a network cable to the megatree and placed the access point next to it in a plastic bin. I have low-e argon windows and stucco on the house which causes issues with E1.31 as this type of widow can cause attenuation of WiFi signals. This is why I switched to using MQTT and an sd card. This is just a single megatree playing a sequence over and over.

Is there any plans to incorporate a scheduler into espixelstick? If I could just schedule it to lay an fseq file from the sd card from 3 PM to 1 AM, I would have no need to even use MQTT.

[MartinMueller2003]

I have this set up on my dig quad. Been turning E1.31 on for 6 hours off for 8-10 with mqtt pinging my broker a couple times a second. Have not had any issues after 31 hours of testing. Will keep testing tomorrow but it does not look like I can reproduce the issue.

[KHouse75]

Thanks for investigating. I've been running only E1.31 for 5 days with no issues. I set up another device for testing and I thought I had it working properly. I could see the espixelstick mqtt connection hitting the broker consistently for 15 minutes. I then saved another setting and it was broken again. Never could get it working again after that. It would make 1 connection then broken. Thought maybe it was something with the sd card reader so I removed it. Same problem. Completely remove the esp8266 from the espixnode, same problem.

I tried with an esp32 as well and had the same issue.

I'm leaning toward something wifi related that's causing this. Even with the wireless access point outside within a few feet of the esp8266, I'm still having issues with occasional high latency. I really just need to move to something ethernet base for next year.

[MartinMueller2003]

Up to 41 hours continuous operation and not seeing anything bad.