Advanced workflows with AI integration through N8N

🇳🇱 Nederlands (Dutch) Ideeën & Suggesties
1

Al een tijd speel ik met de gedachte om mijn gehele Homey Pro setup te besturen via een autonoom denkende AI engine. Ja, ik weet het, het is scary, maar het is een experiment.

Mijn droom is om een soort digitale butler te bouwen. Een goede butler geef je geen opdrachten, die anticipeert en voert proactief uit, nog voordat je het zelf bedacht hebt. Ik ben gewoon ultiem lui.

Ik heb mijn hele huis zoveel mogelijk in Homey Pro gekoppeld, circa 317 devices. Hue lampen, Tado thermostaten, keuken apparatuur, warmtepomp, energiemeters, gordijnen en markiezen, sensoren, ramen Sonos, tv’s, camera’s, etc, etc.

Mijn idee is het volgende:

  1. maak een API koppeling voor een externe AI om de status van alles in Homey Pro uit te lezen (iedere minuut).
  2. laat AI die analyseren en met aanbevelingen voor acties komen, in gewone tekst.
  3. laat een 2de AI die gewone tekst omzetten naar instructies voor Homey Pro
  4. voer die instructies uit via een api in Homeypro

Ik snap dat dit niet zonder risico is en dat dit de boel ernstig kan ontregelen. Maar dat is voor nu nog niet een issue. Als eerste stap heb ik 1. en 2. gemaakt in N8N die ik lokaal in een Docker container heb draaien. Op dit moment vraag ik alleen om de status van Devices en Zones. Ik gebruik nu (Google) Gemini-2.5-Flash als AI engine, maar dat kan makkelijk vervangen worden door iets anders.

Schermafbeelding 2025-09-05 om 00.06.52
Schermafbeelding 2025-09-05 om 00.06.523622×1182 306 KB

De output is wat lastig lezen in een database. Maar als ik die even laat samenvatten krijg ik nu bijvoorbeeld dit advies voor acties:

“Kort gezegd raadt deze output het volgende aan (lekentaal):

  1. Zet lampen uit in de Zitkamer

  • Er staan ’s avonds laat heel veel lampen aan in de Zitkamer.

  • Advies: als er niemand is, zet ze uit (voorwaarde: geen aanwezigheid gedetecteerd in de Zitkamer).

  1. Vervang twee lege batterijen van Hue Tap Dial’s

  • Floortje – tap dial – rechts: batterij is kritiek (5%) → meteen vervangen.

  • Mijntje – tap dial – rechts: batterij is laag (15%) → snel vervangen.

  1. Check een niet-beschikbare lamp in de werkkamer

  • Werkkamer 1.5 verschijnt als “unavailable”.

  • Advies: controleer stroom/verbinding (is de lamp uit het netwerk, kapot, of schakelaar uit?).

  1. Temperatuur ’s avonds omlaag in meerdere kamers

  • Keuken, Floortje, Waskamer, Chillkamer, Badkamer 2de en Werkkamer zitten rond/bo­ven 22,5 °C laat op de avond.

  • Advies: zet een nacht-setback (’s avonds/’s nachts wat lager) als er niemand aanwezig is → scheelt energie zonder comfortverlies.

Ultrakorte samenvatting:
• Onnodige lampen uit in de Zitkamer (bij geen aanwezigheid) • 2 x batterij vervangen (Floortje direct, Mijntje snel) • Probleemlamp in Werkkamer nalopen • Nacht-temperaturen in paar ruimtes wat lager zetten.”

Ik kan deze N8N workflow verder gaan optimaliseren (snelheid, “guardrails” aanbrengen, kosten reduceren van AI). Ik gebruik Gemini omdat ik vermoed (maar dat moet ik nog testen) dat het gebruik ervan goedkoper is dan OpenAI. Maar op termijn kan ik ook een lokale LLM draaien in bijvoorbeeld Ollama in een andere Docker container.

De mogelijkheden voor automatisering zijn oneindig. Je kan nu heel makkelijk een AI (Voice) Chatbot koppelen, of een AI home security bouwen, reports genereren, etc, etc. Ik heb werkelijk nog geen idee waar dit toe kan leiden. I’m just scratching the surface.

Hebben anderen hier ervaring met advanced AI en AI control in Homey Pro?

3 Likes
2

Mijn idee zou zijn om alle device info op te vragen via de reguliere Homey node API, zodat je de AI vraagt naar afwijkende patronen om daar advies over uit te brengen. Via natuurlijke taal geef je aan wat je wel of niet wenselijk vind in een instructie prompt vooraf.

Ikzelf heb een complete app middels Claude Code gerealiseerd met daarin de nodige (sub) agents in gebruik genomen om dit soort taken te automatiseren.

Om de homey via MCP aan te sturen zie oa:

3

Ik wil dit ook erg graag in mijn Homeys implementeren, ik ga in oktober beginnen met mijn huis volledig opnieuw te installeren en daarbij 2 homeys gebruiken 1 voor het alarmsysteem te hosten en de pro 23 Word voor alle andere apparaten gebruikt en ik zou het super vinden als ik daarin ai ook kan implementeren. Ik hoor graag of jullie daar informatie over willen delen.

Ik wil ook wel mee gaan testen ik wil daar de pro 23 wel voor inzetten, dan is het alarmsysteem veilig.

4

OK, ik ben een stap verder en tegelijkertijd een stap terug. Ten eerste bleek de billing van Gemini lagging te zijn en kwam ik er later achter dat ik voor ca €30 aan API kosten in een dag gemaakt had. En dit was nog maar het begin! Daarnaast had ik een (free) Supabase nano account, maar de data limieten kwamen al in zicht. En ik ben verder na gaan denken over optimalisaties.

Ook heb ik geprobeerd een webhook te maken om bij een state-change van Homey automatisch alle states binnen te krijgen in N8N. Probleem vormen “chatty” devices zoals energiemeters die iedere seconden een update hebben. Vrijwel direct crashte alles vanwege een overflow.

De metafoor met een butler hielp. Zou die iedere seconde alle informatie van alles willen hebben in huis? Nee. Dus ik heb besloten eerst met minuut polls te werken. Ik kan real-time hooks later altijd nog toevoegen.

Om te beginnen heb ik cron processen lopen om diverse data feeds van Homey te krijgen. Devices, en Notifications iedere minuut, device snapshots sla ik iedere 5 minuten als json op voor auditing en archivering. Daarnaast verwerk ik elke snapshot iedere minuut tot een devices_diff. Dat zijn alleen de wijzigingen. Maar dat doe ik met beleid. Ik heb quantization thresholds ingesteld per capability. wijzigingen in energy bv, hoef ik alleen op te slaan als er wat significant verbruik is, niet bij elke Wh. Zo beperk ik het aantal relevante changes per uur, wat de performance, storage en kosten (voor verwerking met AI) ten goede komt.

Zelfde voor zones en users, maar met lagere frequentie (iedere dag een update).

Je wil zoveel mogelijk deterministisch afhandelen en zo min mogelijk data (tokens) naar AI-agents sturen. En AI-agents zijn niet gelijk. Het idee is om de devices_diff eerst naar een simpele (snelle en goedkope) router agent te sturen die bepaalt welke info naar welke specialisten agent gaat (mogelijk duurder). Aparte agents voor bijvoorbeeld Energy, Security, Comfort, Scheduling, etc. Die bepalen actie binnen hun eigen domein. Uiteindelijk komen die acties weer samen bij een Evaluator agent, die bepaalt of de samenhang van verschillende acties klopt en of het zinnig is. De output is een gesaniteerde set instructies. Die moet dan door een onafhankelijke Governance agent, die ervoor moet waken dat de hele zooi niet ontspoort en een eigen leven gaat leiden (Space Oddessey!). En tenslotte is er een node (of agent?) die er executional code van maakt die hij dan naar Homey terug kan sturen.

Dit is high-level het idee waar ik aan werk en begonnen met de data-acquisitie. een device snapshot met meer dan 300 devices blijkt meer dan 1500 capabilities en hun waarde te bevatten. Bij een snapshot per 1 minuut zijn dat meer dan 2 miljoen datapunten per dag en bijna een miljard per jaar! Door met state_diff en quantization te werken kon ik dat terug brengen naar circa 30 mer minuut, ca 16 miljoen per jaar. data opslag en processen is wel echt een concern.

Voor dataopslag heb ik een docker container gemaakt met postgres met lokale opslag. Werkt prima. Maar de data acquisitie gaat zo hard dat database performance wel een ding wordt. Dus moet ik misschien binnenkort iets met hypertables gaan doen… Daarnaast moet ik gaan bedenken of ik alle informatie per minuut tot in het oneindige wil bewaren. Waarvoor? Naar AI ga je alleen het minimale sturen ivm performance en kosten. dus een jaar aan data met een granulariteit van 1 minuut is waarschijnlijk onwerkbaar en onzinnig.

En tenslotte wil ik nog met AI dynamisch stochastische rules gaan definiëren. Dat is wat abstract, maar elke state-change van een parameter (capability) die je meet heeft een trigger en een intentie. Lastige is dat je die vooraf meestal niet weet. Het licht gaat aan, maar door een motion detection, door een user actie op een schakelaar, door een flow? Kan allemaal. En waarom gaat dat licht aan, voor security, voor comfort, als notificatie, etc? Ook dat kan je vaak niet direct afleiden. Maar je kan aan elke trigger-event-intent combinatie wel een bepaalde weging geven. En die weging stochastisch laten bepalen. Zeker als het er miljoenen zijn… Er komt dan op enig moment een event binnen en een AI engine kan dan kijken welke trigger-event-intent paren er zijn met welke wegingsfactoren en die mee laten wegen in het achterhalen van de trigger en de intent. Zeker als die meerdere events (state_changes) bij elkaar binnen krijgt. bv Motion detection + lights is dan niet user initiated. Kan dan nog wel een flow zijn maar de intent kan zowel een wenselijke automatisering zijn of vanwege security. etc… Zeker als je dit over een korte tijd-reeks aan snapshots doet, kan je met beperkte data en slimme wegingen denk ik een heel eind komen. bij 30 state changes per minuut en 5 minuten heb je schat ik aan ene paar kB aan data voldoende om AI echt slim aan het werk te zetten.

Ook loont het om goed te kijken welk AI model je gebruikt voor welk doel. En dan zijn er van een model vaak ook nog verschillende aanbieders, met elk hun een pricing… Loont de moeite!

Al met al ben ik het stapje voor stapje aan het uitbouwen. Als ik een nacht aan snapshots naar AI smijt en vraag, “Welke top 5 relevante dingen zijn er gebeurd en welke top 5 aanbevelingen heb je”, krijg je al opvallende uitkomsten. En je kan bijvoorbeeld vragen: hoeveel energie heeft warm water gekost ten opzichte van al het energieverbruik (alles via 1 warmtepomp). Dan kan hij dat met slim correleren van bijvoorbeeld het aanslaan van de recirculatiepomp voor warmwater en het energieverbruik van de warmtepomp schatten hoeveel verwarming is en hoeveel warmwater.

En tenslotte kan ik het systeem gaan voeden met stochastische regels. Regels zoals “bewoner A gaat gebruikelijk rond 23:00 naar bed en staat rond 7:00 op”. En je kan devices extra informatie meegeven. Ik heb bv die waterpomp voor recirculatie aangesloten op een Hue powerplay, die Philips Hue als een lamp herkent. Zo’n uitzondering kan je dan handmatig definiëren. Dat kan handmatig, wat je je maar bedenkt, maar kan ook automatisch gegenereerd worden uit lange termijn data-sets.

Doel is uiteindelijk om een systeem te maken dat:

  1. schaalbaar is
  2. dynamisch uitbreidbaar is
  3. zelflerende is
  4. maximaal automatiserend is
  5. veilig is
  6. transparant is
  7. niet uit de bocht vliegt

En uiteindelijk ben ik wel benieuwd of zoiets te realiseren is met lokale LLM agents op nog enigszins betaalbare hardware. Mijn droom zou zijn een dedicated M4 Mac Mini hiervoor te hebben. Maar dan moet de LLM niet te zwaar zijn. Misschien in de toekomst (M5, M6, etc…)?

Ik heb het systeem overigens wel al HAL-9000 genoemd…

1 Like
5

Ik zag net je andere topic, je bent lekker bezig man!

waarom zou je voor je testen niet de Deepseek modellen gebruiken via de API, deze zijn echt een stuk goedkoper (kwaliteit is wel anders natuurlijk, maar voor het begin).

6

Volgens mij is de truck om eerst met Bayesian Inference technieken zoveel mogelijke acties af vangen. Dit is namelijk snel, goedkoop en weinig resource intensief. Wat er over blijft, meer complexe afwegingen en situaties, kan je dan aan een LLM voeren. Welke dat is, is minder van belang, zolang het er maar weinig zijn. Mijn inschatting is dat met slim voorselecteren je slechts 0,5% van de potentiële trigger-intent-actions via een LLM hoeft te laten bepalen. De overige 99,5% kan je op echt heel bescheiden hardware lokaal afvangen en oplossen. Mijn beperking echter is dat ik geen handige IT-er ben, maar een conceptuele techneut. Ik kan het dus wel bedenken, maar niet bouwen.