Tuya-apparaten lokaal besturen via Home Assistant — zonder cloudgedoe
Er zijn van die momenten waarop je denkt: dit kan slimmer.
Dat had ik dus met Tuya.
Tuya is groot. Heel groot. Van lampen en stopcontacten tot kachels en ventilatoren — de kans is groot dat er bij jou thuis ook iets van draait. En eerlijk is eerlijk: het werkt. Tot je erachter komt hoe het werkt.
Elke actie die je uitvoert, gaat via de cloud.
Jouw knop → internet → Tuya servers → terug naar jouw apparaat.
Dat betekent:
- vertraging
- afhankelijkheid van internet
- en een derde partij die nét iets te veel weet over jouw huis
Dat voelde… onnodig.
Dus heb ik het anders gedaan.
Maar wacht… er is toch LocalTuya?
Klopt. En laten we eerlijk zijn: LocalTuya is goed.
Sterker nog, dat was mijn eerste route.
Ik heb daar serieus naar gekeken en ook mee gewerkt.
Alleen liep ik tegen iets aan waar je pas achter komt als je nét wat verder gaat dan “lamp aan/uit”.
🔥 De heater-case (waar het mis ging)
Mijn infraroodkachel heeft:
- 9 vermogensstanden
Maar:
- LocalTuya → ondersteunde er 7
- Officiële Tuya integratie → zelfde verhaal
Gevolg:
- standen klopten niet
- mapping was beperkt
- gedrag was… laten we het “creatief” noemen
En dat is precies het punt waar standaard oplossingen stoppen.
Niet omdat ze slecht zijn — maar omdat ze generiek moeten blijven.
Ik wilde:
👉 volledige controle
👉 alle standen gebruiken
👉 exact weten wat er gebeurt
En daar begon VUN-Tuya-Hassio.
De oplossing: VUN-Tuya-Hassio
VUN-Tuya-Hassio is mijn eigen brug tussen Tuya en Home Assistant.
Geen cloud, geen omwegen. Gewoon lokaal.
Alles draait op een Ubuntu Server als native service (dus geen Docker-circus), en stuurt apparaten direct aan via het lokale netwerk. Home Assistant krijgt updates via MQTT en denkt: dit ziet er verrassend netjes uit.
En dat is precies de bedoeling.
Hoe het werkt (zonder magie, gewoon logisch)
De applicatie bestaat uit drie lagen die samen één ding doen: controle terugpakken.
1. Tuya Cloud synchronisatie (eenmalig nodig)
Bij de eerste setup haalt VUN-Tuya-Hassio alles op uit jouw Tuya IoT project:
- Device ID’s
- Productinformatie
- Datapoints (DP codes)
- En vooral: local keys
Die local key is de sleutel. Letterlijk.
Daarmee kun je een apparaat direct aanspreken op je eigen netwerk.
Na deze stap? Cloud optioneel. Rustig ademhalen.
2. Lokale besturing via tinytuya
Alle commando’s gaan direct via het LAN naar je devices.
Geen vertraging. Geen internet nodig. Gewoon:
klik → reactie
Hiervoor gebruik ik tinytuya, een Python library die het Tuya-protocol spreekt alsof het er zelf onderdeel van is.
En ja — als een functie écht alleen via de cloud werkt, dan valt het systeem netjes terug. Maar dat is de uitzondering, niet de regel.
3. MQTT Discovery voor Home Assistant
Hier wordt het leuk.
De applicatie publiceert automatisch MQTT discovery berichten.
Dat betekent:
- apparaten verschijnen vanzelf in Home Assistant
- met de juiste entiteiten (light, fan, climate, sensor)
- zonder YAML-ellende
En dankzij retained topics weet Home Assistant altijd de laatste stand. Ook na een herstart.
Multi-function devices (oftewel: Tuya houdt van verrassingen)
Een Tuya-device is zelden “gewoon een lamp”.
Vaak is het:
- lamp + ventilator
- heater + fan
- stekker + energiemeter
Dus VUN-Tuya-Hassio doet niet aan aannames.
1 device → meerdere entities
Voorbeeld:
- light.slaapkamer_lamp
- fan.slaapkamer_ventilator
Alles netjes opgesplitst. Geen creatieve interpretaties meer.
De echte uitdaging (en waar het interessant werd)
🔥 Protocol 3.5 en dp_id drama
Mijn favoriete moment: een infraroodkachel.
- Tuya protocol 3.5
- 9 vermogensstanden
- lokaal bereikbaar
- maar… deed precies niks
Na wat detectivewerk bleek het probleem simpel:
De Tuya Cloud API geeft je mooie namen zoals level,
maar verzwijgt de bijbehorende dp_id’s.
En die heb je lokaal dus keihard nodig.
Dus dan ga je praten met het apparaat zelf:
d.status()
# {'dps': {'1': False, '5': '6', '19': 'cancel', '20': 0, '102': '6'}}Daar stond het antwoord:
- dp_id 5 = vermogensniveau
Niet 2. Niet 3. Gewoon 5.
En ineens snap je ook waarom standaard integraties moeite hebben:
ze missen gewoon een deel van de waarheid.
🤦 Sync die je werk “even opruimt”
Na elke cloud sync waren mijn handmatige fixes verdwenen.
Systeem: “ik heb dit voor je opgelost”
Ik: “nee, je hebt het kapot gemaakt”
Oplossing:
- bestaande mappings bewaren
- na sync terugzetten
- slimme regels:
- bekende dp_id wint
- grotere range wint
- lege data? negeren
Sindsdien blijft alles netjes staan waar het hoort.
🔁 MQTT en oneindig veel apparaten
Elke sync gaf een nieuwe unique_id.
Home Assistant dacht:
“Oh, nog een apparaat! Leuk!”
Spoiler: dat was niet leuk.
Fix:
- unique_id gebaseerd op entity_id
- bijvoorbeeld:
climate.badkamer_heater
En ineens bleef alles stabiel.
De stack (kort en krachtig)
- Backend: Python 3.11 + FastAPI
- Database: SQLite
- Lokale communicatie: tinytuya
- MQTT: Mosquitto
- Deployment: systemd op Ubuntu Server
- Frontend: eigen dashboard (vanilla JS + CSS)
- Styling: strak, donker en functioneel
Resultaat
- 61 apparaten volledig lokaal
- geen cloud latency
- heaters schakelen soepel tussen alle 9 standen
- verlichting dimt zonder vertraging
- energieverbruik inzichtelijk
- alles via Home Assistant
En vooral:
👉 alles onder controle
👉 alles lokaal
👉 alles snel
🛠️ Zelf bouwen: waar je écht aan begint
Nu komt het eerlijke stuk.
Dit project bouw je niet “even snel”.
Maar het is ook geen hogere wiskunde.
Het is vooral:
structuur aanbrengen in iets wat daar totaal geen zin in heeft
🧠 De juiste mindset
Als je denkt:
“ik bouw een tool”
dan wordt het lastig.
Zie het zo:
jij bouwt een vertaler tussen drie werelden
- Tuya (chaos)
- jouw netwerk (logisch)
- Home Assistant (strak)
Jij zit ertussen en zorgt dat het klopt.
🧱 Bouw het in lagen (anders krijg je spaghetti)
1. 🔌 Begin met data ophalen
Zonder dit heb je niks.
- devices
- local keys
- dp codes
Log alles. Echt alles.
Later ga je jezelf bedanken.
2. 🧠 DP-analyse (hier begint het echte werk)
DP codes zijn… creatief.
Voorbeeld:
- dp_2 = 0
- dp_5 = “6”
Succes ermee.
Wat je moet doen:
- live status uitlezen
- veranderingen volgen
- verbanden leggen
Cloud = hint
Device = waarheid
3. 🔍 Mapping (van chaos naar logica)
Hier maak je er iets bruikbaars van.
- device → light / fan / climate
- of gewoon alles tegelijk
Ja, dat gebeurt.
4. 📡 MQTT (niet te vroeg!)
Eerst begrijpen, dan publiceren.
Anders debug je jezelf gek.
5. 🖥️ Dashboard (je controlepaneel)
Niet om mooi te zijn.
Wel om te zien wat er gebeurt.
😅 Wat je sowieso tegenkomt
- “Waarom doet dit niks?” → verkeerde dp_id
- “Waarom werkt dit half?” → deels cloud-only
- “Waarom is 100 ineens 1000?” → Tuya-logica
- “Waarom is alles weg?” → sync
Welkom bij het spel.
🧩 Slimme keuzes (scheelt je uren frustratie)
- ✔ templates
- ✔ confidence score
- ✔ entity preview
- ✔ handmatige override
- ✔ logging
⚙️ Praktische setup (Ubuntu)
Hou het simpel:
/opt/vun-tuya-hassio/.envvoor config- Python venv
- systemd service
Geen Docker. Geen magie. Gewoon controle.
🚀 Wat je uiteindelijk bouwt
Als je dit goed doet:
- een eigen Tuya backend
- volledige controle
- automatische HA integratie
- en iets dat sneller werkt dan de officiële oplossing
Niet slecht voor een “bijproject”.
💡 Laatste tip
Bouw dit iteratief.
Niet:
“ik wil alles tegelijk”
Maar:
- 1 device werkend
- mapping klopt
- MQTT zichtbaar
- uitbreiden
En eerlijk…
De eerste keer dat je een Tuya-device:
👉 lokaal bestuurt
👉 zonder cloud
👉 direct reageert
…dan weet je:
“oké, dit was het waard”
