Hulp bij board keuze

Update:
Het duurde even voordat ik tijd had om een testopstelling te bouwen en dit allemaal te testen. De resultaten zijn niet goed. Dit is het verhaal.

Ik draai ESPHome. Oorspronkelijk was ik dit van plan
7 temp sensors. Uiteindelijk allemaal via 2x ADS1115 gedaan.
10x PWM led.
1x PWM fan (dit heb ik nog niet getest bedenk ik me nu al verwacht niet veel issues, en anders offer ik dit op)
Dat ging goed totdat ik ook dit toe ging voegen.
4x SK6812
1x RF receive
1x IR send

Dit gaat voor geen meter. Om te beginnen krijg ik 4x SK6812 al niet voor elkaar. De combinatie van 1x SK6812 met RF reive ging ook al fout. Het helpt waarschijnlijk niet dat mijn RF receiver een raw signaal naar de ESP stuurt.

1x RF receive en 1x IR send ging dan wel weer goed tot mijn verbazing. Ik had hier timing issues verwacht. Al heeft de RF afstandbediening geen 100% succes percentage. Maar ik twijfel of dat aan de ESP ligt.

Al met al is het duidelijk dat de SK6812 de deur uit moet. Dit gaat wel tot tig meer PWM kanalen zorgen omdat ik RGB strips ga gebruiken. Dus dat zal ik op moeten vangen met 2x PCA9685. Wat dan wel meteen als voordeel heeft dat ik die lokaal kan plaatsen, wat mijn bedrading wel wat op schoont. Ik hoop dat 0.5m nog wel wil lukken met I2C. Ik kan altijd nog de frequentie wat omlaag zetten van de I2C. Het zijn maar LEDs niet waar

Een RF receiver die zelf de codering doet van het signaal zou ook nog iets verlichting kunnen geven voor de ESP. Maar mogelijk kan ik wel zonder.

Ik mag de testsetup weer gaan wat gaan verbouwen

Kun je iets meer toelichten wat er fout gaat? Want op het eerste oog zou de combinatie prima moeten kunnen werken.
Plus als je ir commando’s aan het ontvangen bent hoef je niets met de leds op dat moment te doen. Bendes benieuwd wat er exact misgaat en hoe je de code hebt opgebouwd

Die SK6812 is een serial led die behoorlijk tijdkritisch zijn (1 bits= 1.25μs±600ns) aka neopixel leds. Je moet daarvoor alle interrupts uitschakelen om dat stabiel werkend te krijgen (1 rij led updates).

Er zijn ook leds die een serial clk gebruiken waarbij je dit probleem niet hebt, ik weet even zo de type nummers niet. Daar kun je fatsoenlijke software voor maken zonder timing ellende.

Wil je toch die "timing kritische" leds gebruiken zou je een truuk met DMA kunnen doen, dan vul je een buffer met data waarvan je alleen Bit 0 gebruikt om je timing patroon in te zetten. Dan gebruikt je de DMA controller om de data naar een I/O pin te schrijven. Je bent dan 4-5 bytes per bitje kwijt oid.
Op een RPi heb ik eens gevonden dat iemand dat deed. Kost wel veel RAM.

-edit-
APA102 is er zo een. Ook in led-strips te krijgen, je hebt dan 1 I/O pinnetje extra nodig.

Nog een paar: SK9822 / HD107 / APA107

Klopt. Daar komt het wel op neer.
Dat raw RF signaal zorgt voor heel wat interrupts. Of ik kon het al niet eens compilen. Ik weet het niet meer.

Dan zat je met die SK6812 nog met het probleem dat je framework Arduino moest gaan, anders mocht je volgens mij vrij weinig leds hebben. Op framwork arduino heb 4x SK6812 strips geconfigureerd maar uiteindelijk werden die 4 allemaal aan het laatste strip variabele geknoopt en waren ze dus niet afzonderlijk te besturen. ALs ik chat GPT even mag citeren (altijd dubieus)
eps32_i2s --> 1 strip only
esp32_rmt --> Several strips but conflicts with RF

Zoiets was het volgens mij.
Al met al, heel veel timing ellende.

Ik had je post nog nooit gelezen, nu pas. Anders had ik je op voorhand kunnen vertellen dat het niet gaat werken met die neopixel dingen zonder clock.
10 jaar geleden al de APA102 gevonden wat tig keer makkelijker is als je wat meer in je CPU wilt doen dan alleen de ledjes aansturen.

[Bericht gewijzigd door henri62 op maandag 23 maart 2026 19:54:56 (31%)]

ESP32 blijft een beetje een raar ding. Hij heeft wel veel rekenkracht met zijn dualcore 240MHz CPU. Maar hij heeft ook de firmware in een externe seriele flash chip. Dus dat betekent dat de code telkens bit voor bit door een 25MHz SPI pin moet worden binnengehaald. En dat kost tijd. Dus de processor moet regelmatig toch even wachten op de code voor de volgende instructies. En dat is niet zo handig voor real-time processen.

Toch begrijp ik het niet. Als je bezig bent met je RF luisteren of zenden (als dat aan de orde is) dan ben je toch niet bezig met de leds anders instellen?
Na een RF commando stop je even de RF. Pas je de leds aan. En zet je RF weer aan. Alle functies hoeven toch niet perse tegelijk te gebruiken te zijn?

Ha, leuk dat dit project nog loopt.

Staat je code ergens online? (github, gitlab, codeberg.org)

Goed, ledstrips aansturen is timing-kritisch. Maar eenmaal aangestuurd blijven die LED's doen wat de vorige opdracht was. Dus dat hoeft niet continue. Daar kun je waarschijnlijk tijd winnen. Als je ze alleen ververst als er wat veranderd is... Of voor animaties zeg 20x per seconde... Dan kan de chip ondertussen wat anders.

IR kun je pollen, maar als je ondertussen wat anders wilt doen wellicht beter in een interrupt. Hetzij een flankgestuurde interrupt op de de IR ingang. Hetzij een timer-interrupt om sneller-dan-de-baudrate zo af en toe eens naar die pin te kijken (te samplen). Daar kun je waarschijnlijk tijd winnen.

Raw RF geeft teveel interrupts zeg je. Zit dat nu op een flankgestuurde interrupt? Tsja, je hebt geen idee wat de "ruis" in de lucht doet, misschien is "sneller dan de baudrate samplen" op een timer-interrupt daar iets. Timer loopt af -> pin samplen en bitje in register schuiven -> return from interrupt. En na 8 bitjes het byte in een buffer schuiven en pas daarna return. En dan af en toe eens in die buffer kijken of je er wat mee moet. Elke seconde ofzo... Of als de buffer vol begint te raken...

Met wat mazzel kun je zelfs een hardware SPI module oid gebruiken in plaats van zelf in de interrupt met bitjes te schuiven. Win je nog meer tijd. Ik ken de ESP-32 hardware niet echt goed, dus ik weet niet of die een bruikbare SPI heeft maar zou het vermoeden. Zowel voor data in als voor het aansturen van de LEDstrips. Maar ik denk dat die ESP dit (makkelijk) kan. (En anders... Probeer 's een Raspberry Pi Pico met wifi als het moet)

ChatGPT kan je misschien meer aanknopingspunten geven op bovenstaande, maar houd er rekening mee dat het slechts grammaticaal correcte zinnen ophoest. Technisch inhoudelijk hoeft het niet te kloppen. Idealiter geeft het een bronvermelding en kun je het aldaar zelf nagaan.

(Als ik dingen vraag over boeken worden er soms bestaande schrijvers gekoppeld aan boeken die ze niet geschreven hebben... Immers: "Kuifje van de bolhoeden-flat, ISBN 0131969188, is geschreven door Paulien Cornelisse" is een grammaticaal correcte zin. Het is zelfs een bestaande schrijfster, en een bestaand ISBN, en een plausibele boektitel.)

Je zult je eigen verstand moeten toevoegen wil het wat werkends worden. Anders krijg je code die in het beste geval niet compiled, en in het slechtste geval lijkt te doen wat lijkt op wat het zou moeten doen, met wat ongedocumenteerde verassingen. (dat is een typefout, maar we hadden het over worst-case, dus ik laat 'm staan).

Op maandag 23 maart 2026 20:34:01 schreef rudig76:
Toch begrijp ik het niet. Als je bezig bent met je RF luisteren of zenden (als dat aan de orde is) dan ben je toch niet bezig met de leds anders instellen?
Na een RF commando stop je even de RF. Pas je de leds aan. En zet je RF weer aan. Alle functies hoeven toch niet perse tegelijk te gebruiken te zijn?

Als je via RF je lampen wil aan/uit doen, wil je toch niet dat de kleurfading van de leds stopt. Des te meer leds, des te meer bits dienen er verzonden.

Waarschijnlijk zit het probleem in het gelijktijdig gebruik van tijd kritische zaken.

Aan de andere kant is het wel wat dubbel op. Gebruik van ESP-home, RF en IR. BT en BTSerial is ook nog een mogelijkheid. Ik zou het bij 1 oplossing houden.

Dat is ook waar ik denk dat het fout gaat. Ik zit nu nog met 2 tijdkritische dingen. RF ontvangen en IR zenden. Dat leek nog goed te gaan totdat ik de dimmer knip op de RF afstandbediening toe ging voegen aan het project. Kennelijk zendt die op een hoger tempo signalen uit. Nu komt er alleen nog maar brij uit de IR zender. Ik moet dit nog verder onderzoeken.

Het zou een idee zijn met de RF ontvanger uit te schakelen tijdens het verzenden van IR. Ik weet alleen niet of ik daar vrolijk van ga worden omdat ik dan RF commando's ga missen. Ik moet dit nog bekijken.

@Lucky Luke
Leuk je weer te zien in een topic van mij! Je hebt me inderdaad al eerder geholpen bij dit project.
Ik moet beschamend toegeven dat dit project nog steeds loopt ja. Ik heb er jaren niet meer aan gewerkt. Maar elke keer als ik zo'n pod uit de kast haal en hem aanzet weet ik weer dat dit project afgemaakt moet worden. Die pods zijn zo waanzinnig mooi! Het komt helaas niet goed over op foto's.

Ik heb eigenlijk geen idee wat die libraries allemaal uitspoken bij dat ESP32 project en of ze inderdaad gebruik maken van interruptpinnen. Je zou verwachten van wel voor tijdkritische dingen.

De code staat niet op github, maar je mag hem zo hebben. Even om mij zelf in te dekken, deze code is enkel bedoelt om de functionaliteit te testen is dus gewoon een beunproject met bijna niets erin Ooit zal ik alles compleet herschrijven en functioneel maken. Maar dat doe ik wel als de lamp aan het plafond hangt
Code

Ik heb jullie hulp weer nodig. Ik kom ergens niet uit. Ik zal wel iets fout doen.

Ik bedacht, laat ik die RF ontvangen en IR zenden loskoppelen van elkaar door het door 2 chips te laten doen. IR zenden doet de ESP32 en RF ontvangen een Arduino uno. De uno stuurt zijn informatie door via UART. Dat zou niet timing gevoelig moeten zijn heb ik begrepen.

Echter, het wil maar niet werken. Zelfs als ik het heel basaal weet ik te maken. De Uno stuurt een signaal. Ik gebruik een level converter om naar 3,3V te gaan en de ESP32 lijkt het te negeren. Ik zie wel dat de UART op start maar er komt niets binnen. Ik ben er al een tijdje mee bezig maar krijg niets voor elkaar. Ik kan met mijn scoop zien dat er wel een signaal naar de ESP32 gaat.

Zo ziet het er uit.

Code Arduino

#include <SoftwareSerial.h>
#include <Arduino.h>

// TX only (pin 11)
SoftwareSerial espSerial(-1, 11);

void setup() {
  espSerial.begin(9600);
}

void loop() {
  espSerial.println("HELLO");
  delay(1000);
}

Code ESP32

esphome:
  name: eettafellamp
  friendly_name: Eettafellamp

esp32:
  board: esp32dev
  framework:
    type: arduino
api:

wifi:
  networks:
  - ssid: "iets"
    password: "iets"

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
      ssid: "Iets"
      password: "Iets"

ota:
  - platform: esphome
    password: "Iets"

packages:


uart:
  rx_pin: 16
  baud_rate: 9600
  debug:
    direction: RX
    after:
      timeout: 10ms
      
logger:
  level: VERY_VERBOSE
  baud_rate: 0

Überhaupt geen slim idee dit?

Probeer eens eerst gewoon communicatie tot stand te brengen. Gebruik RX2 en TX2 van de ESP. SoftwareSerial vermijd ik ten alle tijden. Dan zit je weer interrupt gebonden. Terwijl hardware serial zijn eigen timers heeft. Welk IC zit er op de Arduino? Heeft die een 2de RX en TX, gebruik die.

Van je ESP32 code kan ik geen speculaas maken. Dit is toch niet geschreven in de arduino omgeving en/of in C.

Ik verwacht eerder iets als:

void setup(){
    Serial2.begin(9600, SERIAL_8N1, RXD2, TXD2);
}

Verder kan je best kijken naar een tutorial voor UART ontvangst met start en eind markers. Zit alles dicht bij elkaar, dan is ISP of I2C ook een mogelijkheid.

Bij 9600Bd is de timing met zowat elk kristal op de arduino uit te voeren. Vanaf 57 600Bd kan je beter kiezen voor een communicatie kristal zoals 18,4320MHz of 14,7456MHz.

Op dinsdag 24 maart 2026 19:46:56 schreef Frankyie:
Code

Dank je, maar dat is een berg YAML files. Daar is niet aan te zien waar je timing-probleem zit. Dat is netjes "gebruiksvriendelijk" weg-geabstraheerd.

Welke taal is dit / waar programmeer je dit in?

Het lijkt een-of-andere "hoog niveau" taal, waarmee je dusdanig ver van de hardware af zit dat je niet meer met interrupts etc. bezig bent. Dus ook de timing niet meer kunt bepalen.

https://esphome.io/guides/yaml/

Dat is er gewoon niet voor bedoeld... Het is geen programmeertaal, maar een configuratie-iets. Je gebruikt een lambourgini om je pizzadeeg uit te rollen...

Dat gevoel begon ik ook al te krijgen ja.
Het is sowieso de vraag of ESPHome niet te beperkend is voor wat ik eigenlijk wil.
Na de opmerking van buckfast_beekeeper heb ik ESPHome maar eens even achterwegen gelaten en heb ik een simpel stukje arduino code geschreven. En warempel, de UART werkt uitstekend. Niets aan de hand. ESPHome loopt te prutsen.

Dat was de verklaring dus.
Voorlopig maar eens ESPHome achterwegen laten en alles zelf gaan schrijven.

Update
Beste mede hobbiesten!
Ik kan jullie advies weer eens goed gebruiken. Ik ben in alle rust al een tijdje bezig de software voor de lamp te schrijven en testen aan het doen van de elektronica. Het gaat goed, op 1 punt na. De communicatie tussen de bovenbak en de pods. Hier ben ik niet happy mee.

Om te beginnen hier het schema van hoe ik nu de zaak opgebouwd heb. Ik heb bewezen dat dit op mijn werkbank werkt.

Echter, de keuze om met IR te communiceren met de pods is een verkeerde geweest. In dit plaatje kan je het oorspronkelijk plan zien. Ter info Die filters zijn een gevolg van het filteren van het zichtbare ligt. IR is daar tussen verstop. Die lucht tunnel wordt veroorzaakt door het glas van de pod.

Het idee was om IR te reflecteren vanaf te tafel. Echter, ik maak mijn ernstig zorgen hoe zwaar de IR lampen moeten zijn om dit werkend te krijgen.

Om een idee te geven. Dit is de IR zender die ik op het moment gebruik voor testen. Een zwak dingetje.
https://www.tinytronics.nl/nl/componenten/led's/led's/ir-led…

Dit is de ontvanger in de pod.
https://www.tinytronics.nl/en/communication-and-signals/wireless/infra…

Op het moment moet ik die led zowat in de pod leggen om überhaupt met de pod te communiceren. Met name als de pod zelf vol ligt geeft is dit een probleem. Dan heeft de IR er nog meer moeite mee. Ik weet niet hoe sterk de IR moet gaan worden om dit voor elkaar te krijgen, maar ik denk heel sterk. Daarnaast vind ik het ook niet zo netjes dat de ESP32 redelijk lam gaat tijdens het IR zenden. Iets wat best tijd in beslag neemt als de 3 pods verschillende instellingen doorgestuurd moeten krijgen (64 bit per lamp). Tijd om dit alles te heroverwegen.

Dus hoe moet dit wel? De Arduino pro in de pods is niet heilig. Ik heb wel een beetje een voorkeur voor Iets dat mijn ESP32 in de bak niet doet haperen tijdens communicatie, hoewel ik altijd meer IC's kan plaatsen zoals ik nu ook met de RF receiver gedaan heb. Wat ideeën.

• IR ontvanger boven op de pod plaatsen in plaats van erin --> Wil ik niet. Dit tast het uiterlijk aan en lichtlekkage is ook een probleem als ik gaten bovenin de pod moet maken.
• Communicatie over de kabel naar de pod --> Niet als dit extra aders vergt. Ik wil de kabel dun proberen te houden. Communiceren over power kabels lijkt me lastig? De pods met hun pwm leds zullen wel flink wat storing geven.
• Draadloos --> bluetooth? De lamp moet wel stand alone blijven, dus de pods moeten communiceren met de bak. Niet via een wifi router. Bij voorkeur

Wat denken jullie?

_{Dit project is niet uit de hand gelopen hoor. Hoe kom je bij het idee Wel leerzaam}

ESP32 heeft Bluetooth aan boord. Die kan je dus gebruiken voor afstanden tot een paar meter. Ik gebruik bluetooth serial voor communicatie tussen ESP en aaitelefoon. Werkt goed. Seriële communicatie tussen 2 ESP zal ook wel werken. Als het in 1 richting moet verlopen zal het niet direct een lastige klus worden.

Reflectie via een tafel is niet de beste oplossing. Zelfs als het zou mogelijk zijn, is het een heel onzekere oplossing. Staat er toevallig iets onder wat niet weerkaatst heb je een probleem. Heb je er iets onder staan wat het licht afbuigt heb je weer een probleem.

De IR ontvanger die je gebruikt heeft een bijhorende 38kHz zender nodig. Bijvoorbeeld iets zoals dit. Deze vorm van transmissie wordt ook gebruikt in afstandsbedieningen.

edit:@Lucky Luke: De led zal wel een 38kHz signaal uitzenden. Wordt ook aangeboden in combinatie met de gekende 38kHz ontvangertjes. https://www.bitsandparts.nl/infrarood-zender-ontvanger-set-38khz-hx183…

[Bericht gewijzigd door buckfast_beekeeper op maandag 4 mei 2026 21:11:28 (11%)]

Hoe zit de software in elkaar die de IR zend? Maak je daadwerkelijk 38 kHz? (Dat moet wel)
Het zou ook de ESP32 niet lam moeten leggen... Is er niet een hardware timer die je hiervoor kunt gebruiken? (Ik ken de ESP32 hardware niet goed). Er is mogelijk zelfs een library voor. Wat gebruik je nu? En hoe veel stroom stuur je door je IR led(s)? (Je zou het maken van de 38 kHz ook aan hardware over kunnen laten, maar ik weet niet of de module die buckfast_beekeeper linkt dat doet of dat het alleen een led en weerstand is en je zelf alsnog 38 kHz moet maken).

Dat gezegd hebbende, ik zou gekozen hebben voor bedrade communicatie via een extra aderpaar. Gewoon omdat het simpeler en betrouwbaar is.

Houdt je difuse filter geen IR tegen?

Edit @buckfast: Dank voor die link, ik kon de onderkant van het printje niet vinden. Daar zit dus niks op. Ik denk dat er alleen een 'power on' led tussen VCC en GND zit, en de IR led tussen DAT en GND, met elk hun eigen weerstand.... (Je zou op zich iets kunnen met een NAND, 1 ingang naar DAT, de andere met een RC aan de uitgang... Of iets met een 555 uiteraard. Maar dat zit er niet op.)

[Bericht gewijzigd door Lucky Luke op maandag 4 mei 2026 23:06:18 (21%)]

Klopt dit wel, moet dat esp er wel bij? espSerial.begin(9600)

Een Bluetooth netwerkje met 1 zender 3 ontvangers lijkt mogelijk, maar ik moet me er nog meer in verdiepen. Van het idee wordt ik wel enthousiast.
Ook moet ik me nog verdiepen of je bluetooth allebei kan doen op 1 chip. Anders moet ik dat ook nog uitsplitsen. Ik heb nog wat leeswerk te doen.

Kijkend naar de raw data die ik ontvang klopt die hele communicatie van de IR wel. Het werkt ook als een tierelier op de testbank. Geen enkel probleem. Dat heb ik wel voor elkaar gekregen. Ik heb alleen 0 vertrouwen in het bereik van deze oplossing in combinatie met dat reflectie concept.

Dat diffuse filter helpt natuurlijk niet, maar de impact is niet heel groot.

Update
Ik dacht, ik laat nog even weten wat ik uiteindelijk gekozen heb. De lamp zal als volgt gaan werken.

Het hele probleem met de IR communicatie met de pods is opgelost door een ESP-NOW communicatie. Oorspronkelijk had ik de ESP-NOW verbinding vanuit de centrale ESP-32 en niet met die extra ESP32-C6. Echter, tijdens strestesten liep ik tegen problemen. Als de wifi uitviel en weer aanging, ging de ESP-NOW connectie zich misdragen. Als ESP-NOW connectie naar 1 van de pods weg viel, ging de wifi zich misdragen en nog meer van die ongein. Ik heb niet de moeite genomen om dat allemaal uit te zoeken en heb besloten om de functionaliteit te splitsen. Dit was effectief want zowel de wifi als de ESP-NOW connectie zijn super robuust geworden. Dit was een van mijn harde eisen. De lamp moet altijd werken, ook als de wifi de weg helemaal kwijt is of een pod helemaal de weg kwijt is.

Ik had mogelijk de ESP32-C6 die de ESP-NOW connectie doet ook nog de RF kunnen laten afhandelen. Maar ik vond het niet de moeite om dat uit te zoeken. De hele setup zoals hij nu is werkt stabiel. Eindelijk!

Leerzaam projectje Nu maar eens de lamp gaan bouwen.

5 ESP-32's? D'r zit straks meer rekenkracht in die lamp dan in de Apollo boordcomputer waarmee ze destijds de maanlandingen hebben uitgevoerd

Zonder gekheid: heeft u niet overwogen om ook een vorm van noodverlichting (op accu) toe te voegen? Dat heb ik zelf wel overwogen voor de lampen die ik hier binnenkort ga maken. Helaas in mijn geval niet makkelijk uitvoerbaar dus zie ik ervan af. Maar is een functionaliteit die ik zelf eigenlijk wel zou willen hebben, in geval van stroomstoring.

Ben een groot liefhebber van RVS, vind uw lamp er verdraaid goed uitzien. Ik heb zelf echter toch voor hout (eiken) gekozen als materiaal, vermits er al redelijk veel RVS in de woonkamer verwerkt zit (en nog gaat worden). Bij mij gaat de bediening trouwens ook heel wat simpeler worden: gewoon twee secties die apart ingeschakeld kunnen worden met schakelaars.

Nu maar eens de lamp gaan bouwen.

Da's het leukste deel van het project. Overigens, hou er rekening mee bij het bewerken van het RVS dat u gereedschap gebruikt dat niet met gewoon staal in contact is geweest (zagen, vijlen, schuur-en polijstmiddelen); anders kan dit na langere tijd aanleiding geven tot roestplekken op het RVS. Heb een zelfgemaakte RVS buitenlamp die hierdoor toch enigszins ontsierd is. Binnenshuis zal het probleem zich hopelijk wat minder snel voordoen, maar toch. Voorkomen is beter dan genezen.

No better kill than an over kill.
Die jongens bij het Apollo programma programmeerde heel wat netter. Ze hadden ook geen keuze.
Overigens ben ik meer functionaliteit uit aan het splitsen omdat dat allemaal problemen gaf, dan dat ik tegen rekenkracht problemen aan loop.

Ik ben bekend met de gevoeligheid van RVS. Al verwacht niet dat je daar problemen mee krijgt binnen.
Ik verwacht overigens dat ik bijna alles uit aluminium ga maken. De lamp is al zwaar zat. Laat staan dat hij van RVS wordt.

Een accu gaat mij te ver. Elke telefoon is een zaklamp. Ik red me wel.
Laatst hadden we een hele avond stroomuitval. Het is bizar hoeveel apparaten een mens bezit met een accu en een felle lamp.

Even nog een opmerking over die serial leds. Volgens mij heeft de ESP ook een DMA controller aan boord.
Die kun je gebruiken om autonoom de LED data naar buiten te sturen.
Dezelfde truuk wordt ook gebruikt op een RPI om die WS leds te sturen onder linux (waar je hetzelfde timing probleem hebt).

Je bent nu om het probleem heen aan het werken met losse arduino & esp bordjes en meer meuk wat uiteindelijk denk ik meer frustraties gaat opleveren.

Dan ben je van het hele timing probleem af en kun je je software normaal schrijven.
Dus de IR/RF/Wifi etc gewoon interrupt based gebruiken zoals het bedoeld is.

De rekenkracht van de ESP zou absoluut geen probleem moeten zijn.

Zoek maar eens op "Espressif RMT led strip". Er is zelfs een standaard library voor die leds.

De ESP32 heeft een speciale hardware module voor IR remote control. Dan moet de software de data klaarzetten en vervolgens wordt die door speciale hardware (RMT peripheral) verstuurd. De 38kHz modulator is daarbij ook voorzien.
https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-refere…

Dus met de juiste libraries moet je IR kunnen doen (zowel transmit als receive) zonder timing issues.

In dit geval lijkt wifi de weg te gaan. Dat kan via de thuis wifi router (Station mode). En dat kan ook met een eigen lokaal netwerkt (Acces point mode). Beide modes kun je ook combineren als je wilt.

Dus dan kun je een AP mode wifi netwerk opzetten voor communicatie tussen de verschillende modules in de lamp, en de Station mode gebruiken om alles aan te sturen vanuit een browser op je PC of telefoon.

Er zijn velen wegen naar Rome. Het kan vast compacter met minder ESP32 bordje. Aan de andere kant, dit maakt je leven wel erg makkelijk. De software is erg simpel geworden. Je moet eenmalig die serial communicatie schrijven en dat kopieer je eindeloos door

IR zit er overigens niet meer in. De IR is vervangen door RF en ESP-NOW. En serial leds zijn er ook niet meer. Het zijn uiteindelijk domme led strips geworden die worden aangestuurd door zowel rechtstreeks door de hoofd ESP32 of via de PCA9685. Die oplossing bevalt me wel omdat ik die PCA lokaal kan plaatsen. Bespaart weer een hoop kabels vanuit de hoofd ESP32. Het wordt toch al vol in die bak.