Let me know when you publish it for permanent. It works good, but brightness may not be fully there but everything is working for sure.
please also check if it works in this configuration:
- add a ws281x bus as the first output (choose any pin, does not matter)
- add your TM1815 as the second output, same pin as you already have
check if there is any flickering (uses a different driver with slightly different timings)
edit: what issues are you seeing with brightness?
So far there has been zero flickering and I have tried several preset settings to challenge that. That goes for both settings, being set up as string 1 and 2. The brightness did not change regardless the way I hooked it up. It’s not like it is super dim, it just looks to the eye like maybe 2 - 7% dimmer. It is doable and works very stable. I will take that over using the Govee app for sure. Let me know what other testing you would like me to perform. This is amazing that you got it working so quickly. Hats off to you!
thanks, its not hard to get it running if you know a little something about the protocol.
The brightness not being at max comes from a very old piece of hard-coded limit values, it limits the current to 22.5mA of the full 38mA the chip can actually do. Reason is that some of the govee’s use that as a max limit, so just setting it to 38mA could kill a lot of setups.
Sounds great. Are you going to roll this into the next WLED version ? I am going to save the settings and not update. I like what you did a lot! Being able to get rid of the Govee app all together is nice because it is fairly unreliable, requires other integrations into home assistant, and don’t match the color scheme of all the lights I have outside that are run on WLED. Simpy amaziing!!!
I already have the code as a proof of concept, did it as a “test run” for something else I am working on. No need to update neo pixel bus, we can define new timings also in WLED and pass them on to NPB when instantiating a bus, which is what I want to do for some other timing options.
Appreciate the help and support for sure!
Still enjoying WLED driving my Govee lights!!! Every night!!!
I noticed that the option for 1815 has not made it’s final way to WLED version 0.15.4 yet. Any idea of when the official rollout is going to be safe for the stable version? Or do I need to put an official updated request in for that?
It was never going to go into 15.x, only 16.0 and the way to do it is a bit of an ongoing debate. I shifted focus and wrote a new bus library from scratch which will make adding new LED types a breeze.
It is unknown when this new library will be ready but it will solve many issues we have with neo pixel bus.
Appreciate the reply! I will keep an eye out for that and make sure to update when that time comes. The lights have been working great since our last post! Have a great day!
I’m desperately trying to flash all my available devices to run this alpha and test these H7050 lights. But I don’t seem to specifically have a v4. Is that the only option? I have an ESP32-D0WD-V3 revision v3.1. I have dig-quads, I have a bunch of gledopto’s, some with esp32’s, but I don’t know what the shortest path is at this point? Continue randomly applying this .bin or just ordering the exact esp32 this was designed for. When I try to flash the bin on my classic ESP32 WROOM I get repeating invalid header: 0x6f422063 errors in the serial log and the device boot loops continuously. Help? Thanks.
there are several artifacts for all controllers. You should be able to OTA even if you have a V3 build if it was uploaded properly using the web installer.
Update: Got further with OTA upload - thank you! Boot log confirms CPU: ESP32-D0WD-V3 rev.3. The binary runs but the strip is blocking the entire loop — seeing Strip took 907-914ms per frame which prevents WiFi from staying connected and makes the UI unusable. Interestingly the lights did come on at power-up so the timing is close! When I reduced LED count to 1 the loop returned to normal speed confirming the strip output is the culprit. Is there a rev.3 compatible build or a timing adjustment needed for this chip revision?
EDIT: I have many boards, but most don’t allow me serial/usb access and I can’t risk bricking any. So therefore, what board on amazon or alixpress should I order to be able to test this out? Clearly the one V3 board I have is just not working out.
it should not take so long, definitely something wrong there. that happens only if you select TM1815?
I do have an alternative: I am working on a new driver that replaces all currently used driver but its very far from finished or even ready for alpha testing but it works on my TM1814 strip which apart from the timing is identical. I can give it a checkup and you can see if that works, there will be bugs though and it may even cash as it is a work in progress and highly experimental still.
Is there an ESP32 that can be used to get these tested ASAP? What is everyone else using in the thread that got it working? I’ll buy one from Amazon or AliExpress.
Yes, the 900ms loop only happens when TM1815 is selected — any other LED type and the loop runs normally. I’m happy to be a guinea pig for the experimental driver! I understand it’s a work in progress and may crash. My setup is a simple bench test so no risk of damaging anything permanent. Please send it when ready!
I do not remember exactly but follow the text above.
I need to check what the current state of the experimental driver is regarding TM1815 and then test if it works on ESP32
Just to let you know grodzilla, I was using a controller from Athom Tech and it compiled with no issues. Athom Tech Controller
oh man, i worked with claude and we decided to order these not knowing what version of the chip we would get. i was hasty. worst case, i can just return them or use them for something else.
AITRIP 2 Sets ESP-WROOM-32 ESP32 ESP-32S Type-C USB Development Board Type-C USB CH340C WiFi+Bluetooth Ultra-Low Power Dual Core ESP32-DevKitC-32 ESP-WROOM-32 Expansion Board for Arduino