Dig quad with tm1814 losing data

I have two implementations of a dig quad with tm1814 running WLED 0.14.0-b1. One implementation has 4 segments with a mix of length and AWG wire while the other is a bench setup to diagnose problems. The bench setup is 12 inches from power to the dig quad and 12 inches to a 18 inch strip using 16 awg wire throughout. In both setups, the LEDs briefly go into demo mode/lose data/flash red periodically. This happens when on or “off”. The 4 segment strip seems to affect all segments at the same time which makes me believe this is a software issue and not a wiring issue. I have a similar issue with the bench setup with just the one segment. I’d like to start troubleshooting this and looking for some direction. The problem has been present while running both 0.13.3 and 0.14-b1. Anecdotally, 0.14-b1 seems worse.

So maybe some more information to help track this down. 0.14-b1 was crashing on both setups which explains the frequency increase. I’ve reverted back to 0.13.3 and have noticed that the first “pixel” (6 LEDs on the 24v tm1814) is unaffected when “off” but the rest of the segment is. So, when the segment flashes red (presume to be demo mode), LED “0” or pixel 0 remains off while the rest of the strip flashes red.

OK, compiled 0.14.0-b2, (March 8), with WLED_DEBUG and right near the last entry the TM1814 strip goes into demo mode for sub 1 sec and returns. I have a SK6812 as segment 1, GPIO 16, and the TM1814 as segment 2 on GPIO 4. There is nothing on GPIO 3 and 1 so that I can debug over serial. I don’t see anything in the logs that would provide a hint on the root cause but hoping someone else does. Only the TM1814 strip has an issue but then again, they behave differently when they “lose” the data line.

---DEBUG INFO---
Runtime: 18488109
Unix time: 1678340616,142
Free heap: 201240
Wifi state: 3
State time: 0
NTP last sync: 4398
Client IP: 192.168.100.158
Loops/sec: 1782
UM time[ms]: 0/1
Strip time[ms]: 0/7
Segments: 1 -> 72B
Modes: 4*187=748B
Data: 4*187=748B
Map: 2*0=0B
Not-Found HTTP call:
URI: /presets.json
FileRead: /presets.json
JSON buffer locked. (17)
JSON buffer size: 2088 for request: 3
JSON buffer released. (17)
Not-Found HTTP call:
URI: /presets.json
FileRead: /presets.json
JSON buffer locked. (17)
JSON buffer size: 2088 for request: 3
JSON buffer released. (17)
Not-Found HTTP call:
URI: /presets.json
FileRead: /presets.json
JSON buffer locked. (17)
JSON buffer size: 2088 for request: 3
JSON buffer released. (17)
Local time: 05:44
---DEBUG INFO---
Runtime: 18518122
Unix time: 1678340646,155
Free heap: 201240
Wifi state: 3
State time: 0
NTP last sync: 4398
Client IP: 192.168.100.158
Loops/sec: 1776
UM time[ms]: 0/1
Strip time[ms]: 0/10
Segments: 1 -> 72B
Modes: 4*187=748B
Data: 4*187=748B
Map: 2*0=0B
Not-Found HTTP call:
URI: /presets.json
FileRead: /presets.json
JSON buffer locked. (17)
JSON buffer size: 2088 for request: 3
JSON buffer released. (17)
Not-Found HTTP call:
URI: /presets.json
FileRead: /presets.json
JSON buffer locked. (17)
JSON buffer size: 2088 for request: 3
JSON buffer released. (17)
Not-Found HTTP call:
URI: /presets.json
FileRead: /presets.json
JSON buffer locked. (17)
JSON buffer size: 2088 for request: 3
JSON buffer released. (17)
---DEBUG INFO---
Runtime: 18548135
Unix time: 1678340676,168
Free heap: 201240
Wifi state: 3
State time: 0
NTP last sync: 4398
Client IP: 192.168.100.158
Loops/sec: 1776
UM time[ms]: 0/1
Strip time[ms]: 0/3
Segments: 1 -> 72B
Modes: 4*187=748B
Data: 4*187=748B
Map: 2*0=0B
Not-Found HTTP call:
URI: /presets.json
FileRead: /presets.json
JSON buffer locked. (17)
JSON buffer size: 2088 for request: 3
JSON buffer released. (17)
Not-Found HTTP call:
URI: /presets.json
FileRead: /presets.json
JSON buffer locked. (17)
JSON buffer size: 2088 for request: 3
JSON buffer released. (17)
Not-Found HTTP call:
URI: /presets.json
FileRead: /presets.json
JSON buffer locked. (17)
JSON buffer size: 2088 for request: 3
JSON buffer released. (17)
Local time: 05:45
---DEBUG INFO---
Runtime: 18578148
Unix time: 1678340706,181
Free heap: 201240
Wifi state: 3
State time: 0
NTP last sync: 4398
Client IP: 192.168.100.158
Loops/sec: 1781
UM time[ms]: 0/1
Strip time[ms]: 0/1
Segments: 1 -> 72B
Modes: 4*187=748B
Data: 4*187=748B
Map: 2*0=0B
Not-Found HTTP call:
URI: /presets.json
FileRead: /presets.json
JSON buffer locked. (17)
JSON buffer size: 2088 for request: 3
JSON buffer released. (17)
Not-Found HTTP call:
URI: /presets.json
FileRead: /presets.json
JSON buffer locked. (17)
JSON buffer size: 2088 for request: 3
JSON buffer released. (17)
Not-Found HTTP call:
URI: /presets.json
FileRead: /presets.json
JSON buffer locked. (17)
JSON buffer size: 2088 for request: 3
JSON buffer released. (17)
---DEBUG INFO---
Runtime: 18608161
Unix time: 1678340736,194
Free heap: 201240
Wifi state: 3
State time: 0
NTP last sync: 4398
Client IP: 192.168.100.158
Loops/sec: 1782
UM time[ms]: 0/1
Strip time[ms]: 0/45
Segments: 1 -> 72B
Modes: 4*187=748B
Data: 4*187=748B
Map: 2*0=0B
Not-Found HTTP call:
URI: /presets.json
FileRead: /presets.json
JSON buffer locked. (17)
JSON buffer size: 2088 for request: 3
JSON buffer released. (17)
Not-Found HTTP call:
URI: /presets.json
FileRead: /presets.json
JSON buffer locked. (17)
JSON buffer size: 2088 for request: 3
JSON buffer released. (17)
Not-Found HTTP call:
URI: /presets.json
FileRead: /presets.json
JSON buffer locked. (17)
JSON buffer size: 2088 for request: 3
JSON buffer released. (17)
Local time: 05:46
---DEBUG INFO---
Runtime: 18638174
Unix time: 1678340766,207
Free heap: 201240
Wifi state: 3
State time: 0
NTP last sync: 4398
Client IP: 192.168.100.158
Loops/sec: 1783
UM time[ms]: 0/1
Strip time[ms]: 0/2
Segments: 1 -> 72B
Modes: 4*187=748B
Data: 4*187=748B
Map: 2*0=0B

Chad -
I think I am seeing the same thing. Curious, have you found a fix? If not, are you running Home Assistant? If so, this may be the issue.

Might also be worth an update to 14.0-b5(6?) as there were a number of communications issues handled in the interim.

Unfortunately HA has caused issues with ‘over polling’ WLED (trying not to finger-poinr).

@divsys I am running 14.0-b6 currently, and it seemed to have the same issue at 14.0-b5 as well. I don’t recall exactly what version I originally noticed this with, but it was certainly 14 something, but it didn’t seem to change with any of the updates provided on that front.

Not a long term solution, but what happens if you “disconnect” HA from the process (either disable HA connection to WLED or drop WLED off the WiFi net so it’s unreachable)?

There is some HA support available from the writers of HA, but it tends to be more problematic than what we’re used to from WLED. I have run HA myself, but most was Sunrise/Sunset on-off via Node-red interfacing. Since the Time/Date Macro stuff was introduced, my WLED setups have been largely standalone.

When I disable/disconnect from HA, the problem seems to resolve itself. Clearly there is some issue here in how HA polls WLED for information, and due to the type of LED connected - it goes into a data loss mode and begins to flash the lights. I posted on the WLED integration for HA github and hopefully they will help rectify this issue.