Tado stelt limiet van 100 apiverzoeken per dag in voor gebruikers zonder abo

Tado stelt een dagelijkse limiet van 100 verzoeken naar zijn REST-api in voor gebruikers zonder een Auto-Assist-abonnement. Voor gebruikers met een Auto-Assist-abonnement geldt een dagelijkse limiet van 20.000 verzoeken per dag.

Tado meldt in een brief aan gebruikers dat een 'klein deel' van de gebruikers verantwoordelijk is voor een relatief hoog aandeel in de serverkosten. De fabrikant van slimme verwarmingsproducten besluit daarom om dagelijkse gebruikslimieten voor apiaanroepen in te stellen, naar eigen zeggen om de 'langetermijnstabiliteit te waarborgen' en te voorkomen dat het bedrijf de toegang voor iedereen moet beperken.

Voor gebruikers zonder betaald abonnement geldt een limiet van 100 apiverzoeken per dag, terwijl gebruikers met een Auto-Assist-abonnement 20.000 apiaanroepen per dag kunnen gebruiken. Tado heeft al contact gehad met Home Assistant en de ontwikkelaars gevraagd om meer gebruik te maken van tado's lokale api's. Het quotum biedt volgens tado nog genoeg ruimte voor 'basisgebruiksscenario's' die niet beschikbaar zijn via tado's lokale api's.

Tado erkent dat de maatregel 'uitdagingen' oplevert voor communityprojecten. Daarom zegt het bedrijf de limieten de komende maanden 'langzaam' te implementeren. Hoe dat precies gebeurt, is niet bekend.

Door Imre Himmelbauer

Redacteur

05-09-2025 • 17:01

155

Submitter: Vincent1468

Reacties (155)

155
155
43
9
0
111

Sorteer op:

Weergave:

Als Tado echt wilde besparen op serverkosten dan zorgden ze wel dat niet letterlijk alles via de server verliep. Zelfs een tijdschema, een feature die domme thermostaten van 20, 30 jaar oud al hebben, werkt bij Tado via de cloud. Waarbij op de ingestelde tijd de server de temperatuur aanpassing naar de Tado Bridge stuurt. Ligt internet er uit doet het schema het dus ook niet meer. En heb je een schema dat precies op het (half) uur bv is ingesteld, iets dat velen toch zullen doen, merk je vaak vertragingen van minuten. Zet je het schema 1 of 2 minuten eerder zal het wel altijd exact op tijd plaatsvinden. Dus de server is ook traag als die voor vele klanten op een exact tijdstip iets moet doen.

Daarnaast ligt hun "oplossing" totaal niet voor de hand. Hun "oplossing" is dat je bij de V3+ maar HomeKit moet gebruiken waar mogelijk. Maar HomeKit ondersteund natuurlijk niet alle features die Tado heeft (bv de "modus" terug zetten naar automatisch / het schema), en het zou mij ook niks verbazen als Tado niet alle features van HomeKit implementeert. (En los daarvan, zit aansturing van warm water alleen in de API en niet in HomeKit). En bv bij een project als Home Assistant verloopt alles via integraties per merk/product. Waarbij Home Assistant dienst kan doen als HomeKit controller en de Tado Bridge dus te integreren is, maar je hebt dus ook de cloud based Tado integratie. En die twee hebben geen enkele weet van elkaar en kunnen ook niet met elkaar gekoppeld worden. Dus Tados voorstel "doe de temperatuur, setpoint, ... maar lokaal via HomeKit uitlezen (en aanpassen)" is niet echt haalbaar om vanuit HA te realiseren. En "handmatig" kun je het wel doen, maar dat lost niks op. Ik heb nu ook de HomeKit controller integratie en de Tado integratie ingesteld. Maar die twee "praten" onderling niet met elkaar, en de Tado integratie blijft dus ook gewoon continu pollen naar zaken die HomeKit ook "weet" (temperatuur, setpoint dus). Maar de Tado is wel nodig voor andere zaken (aansturen warm water bv, of uitlezen batterij status, of het percentage dat een zone verwarmd wordt (dus of de verwarming echt aan of uit is voor een zone / "hoe ver de knop open is gedraaid"). Maar als je de Tado integratie instelt voor specifiek de features die niet via HomeKit kunnen zal die nog steeds ook continu de "status" uitlezen van de zaken die je wellicht niet perse nodig hebt. (Je kunt niet voorkomen dat die elke X minuten de temperatuur in een zone ophaalt terwijl je bv alleen de batterij status wilt weten).
En bij andere projecten kan het zomaar zijn dat die uberhaupt niet met HomeKit overweg kunnen en daar nu semi de verplichting komt om dat toe te voegen.

En "hipper" hebben ze de Tado X, met Matter. Maar wat ik daar zo van lees is de situatie daar niet veel beter. Beperkte data beschikbaar via Matter, en buggy. Potentieel ben je daar dus zelfs beter af als je de Tado bridge de deur uit doet en je ze via een eigen thread border router integreert in bv HA? (but then again: thread is uiteindelijk IP, en Matter is een protocol over IP, als je een eigen TBR hebt zal die nog steeds hetzelfde Matter protocol babbelen neem ik aan. De Tado bridge van de X series zal ook in de basis een TBR zijn die als het goed is puur het IP verkeee over Thread omzet naar IP verkeer over een (W)LAN).
Het is in mijn ogen heel simpel: koop NIETS wat niet zonder cloud kan. Local first, local only.

Cloud = planned obsolesence.
Ja, ik heb Tado V3's en daarna verder het HA konijnenhol in gedoken. Ondertussen denk ik had ik maar gewoon Zigbee radiatorknoppen gekocht, dan had ik alles lokaal gewoon in de hand icm. Home Assistant ipv. dat ik regelmatig meldingen krijg dat de api opnieuw geverifieerd moet worden (gevolg van dat men een poos geleden met api keys is gaan werken). Maar om nou weer een paar 100 euro uit te geven aan knoppen...

[Reactie gewijzigd door XElD op 5 september 2025 17:29]

Het is een kromme manier van uitdrukken, maar van mij hoeven al die smarthome dingen niet echt smart smart te zijn. Als ze gewoon dom smart zijn dan knoop ik het wel met een gateway aan elkaar. Deze zigbee radiatorknoppen (van Nedis):

https://www.bol.com/nl/nl...roid-ios/9300000027619108

En een paar mooie temperatuur meters van de Ikea:
https://www.ikea.com/nl/n...eitsensor-smart-00498231/

Klaar.

In het aller aller ergste geval kan jezelf nog altijd een draai geven aan de knop om een temperatuur in te stellen. Voor de rest wordt alles lokaal gemeten en aangestuurd, externe communicatie is ook nergens voor nodig.

[Reactie gewijzigd door TechSupreme op 5 september 2025 19:17]

Maar dan heb je toch nog wat nodig die je cv een slinger geeft dattie moet gaan stoken?
Ligt er aan. Mijn klokthermostaat hangt naast de ketel. Zo’n Honeywell Chronoterm met modulerende aansturing. Er zit een temperatuursensor aan gekoppeld die buiten hangt en wordt dus op basis van de buitentemperatuur gestuurd ipv de temperatuur in huis. Die stelt op basis daarvan de CV-watertemperatuur in op de Intergas-ketel.

Vervolgens is er een losstaande aan/uit-thermostaat in de woonkamer (zo’n simpele Honeywell round) die de vloerverwarmingspomp aan stuurt. En thermostaatknopen op de radiatoren boven. Als de vloerverwarming gaat lopen of een thermostaatknop gaat open, dan loopt het CV-water erdoor waardoor de watertemperatuur in de ketel natuurlijk zakt. Dat is het signaal voor de ketel om wat bij te stoken om weer terug op de door de thermostaat ingestelde temperatuur te komen.

Ik heb dus simpel de thermostaatknoppen op de radiatoren vervangen door knoppen van Fritz! die een ingesteld programma volgen zodat bijvoorbeeld mijn werkkamer op thuiswerkdagen warm is in de winter. En dat werkt dan gewoon zonder dat ik zelf hoef te prutsen aan de ketelaansturing.

Het kan dus wel, maar dan moet het wel zo ingeregeld zijn.
Dat hoeft toch ook niet als je de warm water kraan aan zet? Als het water gaat lopen, dan gaat ie het vanzelf verwarmen.

Disclaimer: ik ben een IT nerd, geen monteur. Neem wat ik zeg met een korrel zout ;)

[Reactie gewijzigd door ComputerGekkie op 5 september 2025 21:07]

Euhm nee... Zo werkt het dan weer net niet :)
Nouja, bij mij thuis wel maar dat komt doordat ik stadsverwarming met een directe afleverset heb 😉
Bij warmwater vraag is er als eerste een flow sensor in je ketel die detecteert dat hij de warmwaterkraan open zet. De controller zet dan je driewegklep op warmwater, de ketel gaat stoken, en het tapwater wordt verwarmt. (Bij een doorstroom ketel althans). Bij een ketel met warmwatervat (oudere type combiketel) is de temperatuursensor van dat buffervat de schakelaar die de ketel aan zet.

In het CV circuit moet je op een of andere manier warmtevraag detecteren. Dat kan via een thermostaat die de ketel inschakelt, of via een combinatie van retour temperatuur sensor en een tweede informatiebron. Vaak is dat een buitenvoeler en weersafhankelijke regeling. Die laatste definieert een minimale retour temperatuur, en als de gemeten retour temperatuur hier onder zit, gaat de ketel stoken en de CV pomp draaien. Net zo lang tot de retour op temperatuur is (want dan is er geen afgifte meer).

Is niet moeilijk, als je een paar principes door hebt.
Daar zou bij een cv een simpel zigbee relais bij tweedraad aansturing voor moeten volstaan. Of anders een openterm interface...
Ik heb gewoon een relais hangen aan de on/off pinnen van de CV, dat is de netste oplossing. Maar je kan ook een Zigbee Kamerthermostaat pakken en die via een automatisering aanslingeren. Dat is hoe ik het eerst deed. Werkt wel, maar is niet netjes.
dit is ons laatste probleem, hebben zigbee knoppen van aqara, maar onze standaard thermostaat die de cv een duw geeft is een beetje vreemd, maar volgens mij is een simpel relais met een bepaalde weerstand in serie genoeg.

Hadden eerst een kastje van plugwise, maar daar kun je niks mee aansturen vanuit HA dus waardeloos.
Check je ketel wat die praat. Het is ofwel potentiaalvrij aan/uit contact, ofwel OpenTherm, ofwel een ketel-eigen bus protocol. Nefit heeft een eigen bus protocol (Honeywell kloon), maar praat ook aan/uit. ATAG een gemodificeerd ebus protocol maar ook standaard OpenTherm en aan/uit.

Als je weet wat je ketel praat, kan je ook een interface er tussen zetten die je via HA kan aansturen.

Idealiter ook wel iets dat ook zonder HA in de basis gewoon werkt.
De ketel geeft een lagere spanning AC signaal naar de thermostaat, deze lijkt vervolgens via de hoeveelheid stroom de ketel aan en uit te zetten.

Maar het signaal kortsluiten werkt ook, nadeel is dat er dan nog een externe voeding nodig is.

Ik heb helaas nog niks kunnen vinden wat dit signaal out of the box kan simuleren, dus het idee is voornu dus een externe voeding voor een simpel zigbee relaistje.
Dan heb je denk ik een wat ouder model ketel. Die leveren vaak een laagspanning op de thermostaat aansluiting, zodat die thermostaat ook daadwerkelijk werkt. Nefit Moduline bijvoorbeeld heeft gewoon voeding nodig. Die wordt dan geleverd door de ketel. Op het moment dat de thermostaat warmtevraag heeft, wordt die laagspanning in feite kortgesloten. Dus zodra de ketel spanning ziet op de andere ader van de tweedraads aansluiting, gaat die stoken.

Als het in jouw geval een Nefit is, met een Nefit thermostaat, dan zou je kunnen overwegen er een OpenTherm converter tussen te zetten, dan kan je die converter aansturen met OpenTherm, terwijl die converter netjes een PWM signaal naar je ketel stuurt.
het is inderdaad een oudere ketel, benraad met een ronde honeywell thermostaat, iets met "power stealing"?

Een laag spanning signaal zou ik normaal vinden, maar ik vind het apart dat het AC is en niet DC
Tegenwoordig is een DC voeding inderdaad veel goedkoper dan een AC voeding, maar dat komt omdat het vermogen op DC geleverd wordt door electronica, en niet meer door een trafo. AC voedingen werken nog steeds met een ouderwetse gewikkelde trafo, en dat is in verhouding duur. Maar in de tijd van de Nefit Ecomline bijvoorbeeld had de print sowieso al 24V AC nodig voor onder andere de driewegklep en dan is het goedkoper om ook de thermostaat te voeden met 24V AC. Mede ook omdat je over AC wel een PWM (Pulse Width Modulation) signaal kan zetten, en over DC niet.
Toevallig al ooit Zigbee radiatorknoppen tegen gekomen waarbij je de besturing vanuit extern kan doen?


Ik wil gewoon de stand van de kleppen doorgeven en het regelen centraal doen, aangezien die knoppen altijd slecht meten doordat ze direct naast de warmtebron zitten in de kamer.
Daarnaast kun je dan ook dingen doen als een regeling waarbij er altijd minimaal 1 klep open blijft, zodat een bypass niet zo nodig is als de ketel een vaste nadraaitijd heeft.
je zou 230v thermische motors (zoals je die ook wel bij kantoren ziet) achter slimme schakelaars kunnen hangen. Sterker nog, zo heb ik het thuis gedaan om de hoofdafsluiter van m'n stadsverwarming dicht te kunnen zetten als er geen warmtevraag is als beveiliging dat er niet ongecontroleerd warm water gaat lopen nadat een van m'n Tado knoppen een keer per ongeluk een etmaal los had gezeten... het was erg warm op die kamer 😅.
Ik heb meeontwikkeld aan een van de populairste vloerverwarmingsregelaars in Nederland, dus die ken ik zeker. 😉

Maar, in mijn jaren '70 woning wat lastig qua bedrading om iedere radiator daar van te voorzien.
Ah kijk, dan ken je het zeker idd. :)
Zigbee radiatorknoppen dat klinkt wel erg cool en handig. Denk dat dit bij niet gaat werken met de Gravity heating in het huis. Ik moet nog eens uitzoeken hoe ik de airco's (Midea) kan koppelen aan de Home Assistant.
De SLWF-01.

Werkt al jaren prima via LAN direct met aan home assistant.
Het is wel bizar inderdaad. Dit riekt naar gewoon naar een vette nudge om een abonnement te nemen. Het is net als mijn Slides, die gingen ook via de servers van IIM destijds. Sinds ik ze lokaal draai nooit meer problemen gehad.
Over het gedeelte over Tado X. Dat is Matter over Thread, dus je hebt idd een thread border router (TBR) nodig zoals bv. een tado TBR (is niet echt een vendor-specifieke bridge voor cloud aansluiting, dat doet je hoofd thermostaat. bridge . Dat vind ik zelf geen probleem, die heb ik toch al in huis ook voor andere producten.

Schedules worden bij Tado X dus ook op je radiator thermostaat opgeslagen of gecached eigenlijk (als je via Tado thermostaat gaat tenminste). Die werken dan dus wel offline grotendeels en ook als je TBR even is gaan lunchen.

Je kan dan dus wel zonder Tado bridge en ook zonder abo van alles implementeren, roosters, geofencing, open window detection, combinatie met andere producten (van een andere fabricant, wink wink,) en dat allemaal lokaal en zonder overgeleverd te zijn aan het bedrijf erachter, wat toch al een tijdje bezig is om het vertrouwen van de klant op het spel te zetten.

Het artikel gaat vooral over Tado v3. Voor Tado X is er wel een cloud API en integratie voor HA, maar die werkt bij bijna niemand en wordt nauwelijks gebruikt. HA via Matter eraan hangen is hier the way to go.

Geen correctie in die zin, gewoon aanvulling op je inzichtvolle bijdrage.
Klopt, echter een paar kanttekeningen. Het heeft me heel wat hoofdbrekens gekost om de Tado Bridge op hetzelfde Thread netwerk te krijgen als mijn HA Bridge. Want je wilt wel al je knoppen op hetzelfde Thread netwerk

Ja, Tado X ondersteunt Matter. Echter de Matter implementatie exposed niet alle sensors. Zo is de humidity sensor niet zichtbaar over Matter, en werkt ook de Open Window Detectie niet. Die moet je dan zelf bouwen middels een steile Delta T detectie op de temperatuursensor.

En als je een ruimte hebt met meerdere radiatoren wordt het ook lastig om in HA een temperatuur kaart te krijgen die het gewogen gemiddelde van meerdere knoppen weergeeft...

Sowieso moet je de knoppen eerst via je Tado app koppelen, voordat je de knop in Matter kunt toevoegen. Dus helemaal van de Cloud ben je niet zomaar af. Een schedule in de knop krijgen kan alleen maar via de app. Je kan in HA wel eigen schedules maken, maar ook dan kan je niet een knop instrueren om bijv. 25% open te gaan. Je kan via Matter alleen de SOLL temperatuur aanpassen, waarna de knop open zal gaan om die temp te gaan halen.
Ik heb mij destijds goed ingelezen voor ik Tado kocht en het was toen al duidelijk dat alles via de cloud loopt inclusief zaken die je echt wel lokaal verwacht. Het aanpassen van de thermostaat op een klokschema loopt via cloud, als je internet weg is springt je thermostaat dus niet op!

Alles achter een cloud steken om vervolgens te kunnen monetizen is altijd al Tado hun strategie geweest! Heel dat Homekit verhaal was geen optie die Tado aanbood, het was een achterdeur omdat ze het niet konden maken geen Homekit te ondersteunen en Homekit lokale toegang afdwingt.

En wat betreft het slimme gedeelte, echt ketel optimalisatie zit er niets eens in, dan bedoel dat je pakweg via opentherm echt de ketel temp en pompsnelheid kan overnemen vanuit je slimme thermostaat (waar de echte besparing zit). Al moet ik wel zeggen dat de meeste zogenaamde "slimme thermostaten" dit niet doen, is een selecte minderheid. En wat betreft selectie van het circuit als je meer dan 1 hebt, kan je niet zelf en diegene die wisten hoe bij Tado support werken er niet meer dus nu beweren ze bij hoog en laag dat Tado dit niet kan (ik heb oude mails waar ze het tegendeel zeggen)

Al bij al is mijn advies, ga met een heel grote boog rond Tado. Ikzelf heb het dik tegen mijn zin gekocht maar ik had geen andere keuze, mijn ketel spreekt een obscuur Viessman bus protocol wat enkel Tado V3 ondersteund vanwege een oude samenwerking tussen Viesmann en Tado toen Viesmann zelf nog geen eigen vergelijkbare producten had.
https://www.laggner.info/posts/connect-can-bus-vitocal/

zou mij werkelijk verbazen als viessman voor andere communictatie echt heel andere dingen doet. Vaak is het copy paste binnen zo’n bedrijf
Dat is veel moderner spul, voor de warmtepompen en gekoppelde thermostaten gebruikte Viessman de KM bus om te communiceren met thermostaten en accessoires zoals externe mixers. Opgevolgd door PlusBus, later zijn ze meer open protocollen gaan gebruiken zoals opentherm en can bus

KM bus is volledig intern Viesmann spul met 0 open documentatie hoe die werkt en dus 0 compatibiliteit met 3th party systemen. Omdat ze toen enkel hun eigen simpele thermostaten hadden met KM bus en sommige klanten daar niet mee akkoord gingen heb je 2 opties

-Tado V3 die toen een samenwerking had met Viessmann en waar men reclame van maakte (bijna niets meer van terug te vinden maar hij spreekt KM bus, het nieuwere Tado spul spreekt het niet)

- KM bus naar opentherm omvormer uitgebracht door Viesmann zelf. Behalve een zeer pittig prijskaartje (dacht 700 euro), niets van terug te vinden wat het effectief kan gelet je met limitaties van de KM bus gaat zitten en ook al heel lang nergens meer te krijgen.
De maximale aanvoertemperatuur kan je tegenwoordig wel instellen. Die kan op een vast getal, of weersafhankelijk gemaakt worden.
Blij dat ik plugwise heb alles lokaal mogelijk.
De tijd inbouwen met een casio achtig uurwerk? Kost geen drol.
"En heb je een schema dat precies op het (half) uur bv is ingesteld, iets dat velen toch zullen doen, merk je vaak vertragingen van minuten. Zet je het schema 1 of 2 minuten eerder zal het wel altijd exact op tijd plaatsvinden. Dus de server is ook traag als die voor vele klanten op een exact tijdstip iets moet doen."

Dat voelt overduidelijk als een verkeerde ontwerpkeuze. Het systeem is blijkbaar niet in staat om de tijdschema's in de thermostaat of radiatorknop zelf te programmeren maar is afhankelijk van realtime aansturing. Zelfs voor gebeurtenissen waarvan je 24 uur vooraf weet dat ze gaan plaatsvinden. Op die manier hebben ze voor zichzelf enorme piekmomenten gecreëerd waardoor ze waarschijnlijk tien keer zoveel instances nodig hebben dan stikt noodzakelijk. Een serverpark dat 99% van de tijd niest zit te doen en 1% van de tijd op volle belasting moet aanpoten komt helaas wel vaker voor, denk aan online ticket verkoop en dergelijke, maar voor een toepassing waarbij je de activiteiten vooraf kunt plannen, zoals en schakelklok van een verwarming is het compleet onnodig en dom om alles in realtime aan te sturen.

Als een stagiair met een dergelijk ontwerp aankomt dan zou die daarvoor een onvoldoende hebben gekregen. Maar bij sommige bedrijven draait dit soort onzin dus kennelijk gewoon in productie.

Het is geen wonder dat ze de graag meer abonnementsgeld willen innen, ze hebben het geld nodig om al die server instances te bekostigen.
Daarom moet je dus nooit producten kopen die alleen goed werken via een (betaalde) cloud.
Het probleem is ook dat sommige merken het door firmware-updates naar de cloud toe trekken. Ik dacht dat het TP Link was die aanvankelijk lokale besturing ondersteunde en na een firmware-upgrade een account nodig had en connectie met de cloud servers. Niet updaten is dan een optie, maar dan moet je wel weten dat de bewuste upgrade je lokale functionaliteit om zeep helpt. Dat zetten ze niet in de release notes.
Ik las dat TP-LInk die beslissing later weer had teruggedraaid. Ook Signify heeft het gedaan met de Hue Bridge. Daar is ook veel kritiek op gekomen, maar zij komen er wel mee weg. Ik ben na dit soort acties klaar met zo'n merk omdat het aantoont hoe er over klanten wordt gedacht.

Home Assistant scrijft er vaak over en probeert bedrijven over te halen pruducten te maken die geen cloud nodig hebben om te functioneren. Ik meen me te herinneren dat ze daar een keurmerk voor hadden geïntroduceerd of een productlijst hadden, maar ik kan het niet meer vinden.
Probleem is dat je eigenlijk nauwelijks met Tado in contact kan komen, behalve via support@tado.com. Maar reageren op de brief kan niet, en ze hebben geen echt klachten adres.

Ondertussen onderstaande tekst naar TADO support gemailt.

Geachte Tado

Graag wil ik melden dat deze wijziging in strijd is met EU regeling EU2023/2854 (https://eur-lex.europa.eu/eli/reg/2023/2854/oj/eng) , VERORDENING (EU) 2023/2854 VAN HET EUROPEES PARLEMENT EN DE RAAD van 13 december 2023 betreffende geharmoniseerde regels  inzake eerlijke toegang tot en eerlijk gebruik van data en tot wijziging van Verordening (EU) 2017/2394 en Richtlijn (EU) 2020/1828 (Dataverordening)

Deze verordening stelt in artikel 5 met name dat

Deze verordening waarborgt dat gebruikers van een verbonden product of gerelateerde dienst in de Unie tijdig toegang hebben tot de gegevens die door het gebruik van dat verbonden product of die gerelateerde dienst worden gegenereerd en dat die gebruikers de gegevens kunnen gebruiken, onder meer door die te delen met derden van hun keuze. De verordening verplicht gegevenshouders om gegevens in bepaalde omstandigheden ter beschikking te stellen van gebruikers en door de gebruiker gekozen derden. Daarnaast zorgt de verordening er ook voor dat gegevenshouders hun gegevens onder eerlijke, redelijke en niet-discriminerende voorwaarden en op transparante wijze ter beschikking stellen van gegevensontvangers in de Unie.

 Het beperken van de API toegang tot 100 requests per dag voor accounthouders zonder Auto-Assist abonnement is discriminerend, en mag niet volgens deze verordening.

Deze verordening is per 12 september 2025 in Nederland in wetgeving omgezet, wat de gewijzigde API toegang in Nederland onwettelijk maakt.

Ik snap echt wel dat een aantal hoog-volume API callers een grote hoeveelheid kosten genereren, maar dan moet met de excessen blokkeren, en niet de gewone gebruiker afsluiten. Of bijkans dwingen een abonnement te nemen op een dienst die men zelf niet nodig acht.
Daarnaast vereist deze verordening ook dat er geen verschil mag zijn tussen data toegang van een lokale API en van een remote online API. Dus men moet ook de Matter toegang dusdanig aanpassen dat je door lokaal uitlezen dezelfde data kan ophalen dan via de online API.

Maar eens afwachten waar dit toe leidt.  
al antwoord gehad? Of komt de mail in >/dev/null uit?
Nog geen antwoord, behalve

Hallo,

Dit is Fabrizio, Hoofd Klantenservice. Uw case is naar mij doorgestuurd. Sorry voor de late reactie, maar we wachten op een antwoord op uw punt over de API-beperking.
Tado heeft al contact gehad met Home Assistant en de ontwikkelaars gevraagd om meer gebruik te maken van tado's lokale api's.
Als er lokale api's beschikbaar zijn, waarom zou je dan uberhaupt verbinding willen maken met de cloud api's? Zijn er veel functionaliteiten die niet lokaal beschikbaar zijn?
Vaak willen ze geen lokaal omdat de cloud ze enorm veel inzicht geeft in hun klanten. Waar wonen ze, hoeveel apparaten hebben ze, hoe gebruiken ze die, wat hebben ze nog meer voor spullenboel.

De marketinggasten lopen echt te watertanden hierbij. Ik heb bij ons op het werk ook wel eens gevraagd, waarom doen we geen open standaarden maar marketing moet en zou die flut app er in houden.
Marketing: de grootste plaag in software land...
*Verkoopmarketing: de grootste plaag.
Inderdaad, wij weten wat de klant wil... 8)7

Eerder van: hoe maken we het de klant zo miserabel mogelijk en melken we die zo veel mogelijk uit zonder dat ie vertrekt?

[Reactie gewijzigd door Wim Cossement op 6 september 2025 10:58]

Op de eerste plaats kunnen we stellen dat verkoopmarketing alleen goed is voor het bedrijf. Niet voor de gebruiker/klant. Verkoopmarketing (waar adverteren onder valt) is veelal gebaseerd op het bezig moeten zijn met één merk. Namelijk. Dat van hen. In de basis is dat een begrijpelijke werkwijze, alleen gaat dit vrijwel altijd ten koste van de klant, omdat één van de methoden om dat te bewerkstelligen is, is 'ecosysteempjes' bouwen. Zorgen dat je product alleen met jouw dienst werkt en dat in de breedste zin.

Jouw apparaten werken alleen met jouw apparaten. Apple was hier bijvoorbeeld heel lang, heel erg in. Of denk aan merken als B&O.

We zien het nu gebeuren met IOT-apparaten.
Die 'moeten' veelal per se via de app van de fabrikant om alles eruit te kunnen halen wat er in zit. En dat tot op het niveau, dat je wel 'moet', al wil je het niet. Anekdotisch: Ik heb een inductiekookplaat van Siemens. Dat apparaat het allerlei leuke functies zoals 'warmhouden' en 'een korte boost'. Die functies staan in de papieren handleiding, maar moeten 'ingesteld worden', dat je die wilt hebben. De lokale bediening heeft twee 'instelbare' functieknoppen. (precies 2). Om die in te kunnen stellen, 'moet' hij een firmware-update krijgen. (dit staat in de papieren handleiding). Om die firmware-update te krijgen, moet je hem op het internet aansluiten via de app.

Toen hij eenmaal die firmwareupdate had, kon ik die functies dus instellen op de knoppen op het apparaat. (twee keuzes voor twee knoppen). Ik kan die kookplaat niet van het internet afhalen. Althans. Dat kan met een 'reset naar fabrieksinstellingen', maar dan ben ik die functies weer kwijt.

Ofwel. Ik word effectief gedwongen om m'n kookplaat het internet op te zetten, om functies die ik lokaal gebruik te kunnen gebruiken. Dat gaat natuurlijk helemaal nergens over.

Om het extra grappig te maken. Ik heb die kookplaat in een eigen VLAN gehangen, waardoor hij niet meer op het internet kan, maar de app werkt nog wel lokaal (dat is al heel wat.) Nou heb ik toevallig de kennis en de spullen om dit voor elkaar te krijgen, maar dat is natuurlijk lang niet voor iedereen weggelegd.
Ik heb ook Home Assistant. Die bedient m'n kookplaat ook lokaal. Zonder 'de cloud'. Ofwel. Het apparaat kan het prima. Maar vanuit Siemens willen ze toch per se dat dat ding altijd aan het internet hangt. Er is geen officiele ondersteuning naar iets anders toe. Siemens wil dus dat ik per se met hun advertentie-app bezig ben. (de app is effectief een soort portaal naar andere Siemens/Bosch/enz. reclames, met een knopje om naar de bediening van je apparaat te gaan.) Ofwel. De marketingmolken wil natuurlijk dat ik met 'hun app' (hun merk) bezig ben. Die app staat stijf van de reclames/logo's van Siemens. Ik word daar niet beter van. Niemand wordt daar beter van. Behalve Siemens.

Mijn kookplaat is bewust ontworpen, zodat ik de functies die in de papieren handleiding heb staan, pas kan gebruiken als ik hem op internet zet. Dit vind ik een compleet verwerpelijke manier van werken.
Belachelijk gewoon! En is dat wel legaal?
Goed dat jij nog het verstand hebt om dat ding te blokkeren, maar echt slimmerds zouden contact met de server vereisen eer je het met een app kan bedienen. Wat ik trouwens echt niet veilig of praktisch vind, maar dat is een ander probleem.

Misschien eens tijd voor de EU om hier ook iets mee te doen, mijn frigo moet niet op internet kunnen bijvoorbeeld. Idem met al die abonnementen voor van alles, je bent geen eigenaar meer van je spul. Of functies die achter een betaalmuur zitten zoals verwarmde zetels bij BMW of je optreksnelheid beperken van je auto.
Dat ze abonnementen hebben vind ik nog tot daar aan toe (of ze nou die serverkosten vooraf in het product stoppen, of dat je die granulair betaalt.) Maar geef me de optie het lokaal te doen zonder hun cloud. En dat het dan niet via internet werkt, dat is dan voor mij om te bepalen dat ik dat wel niet belangrijk vind.

Sowieso vind ik het vervelend dat je voor veel apparatuur cloud-accounts moet hebben. Kijk naar de Homey van LG. Die doet 'alles lokaal' (claimen ze, ondanks dat ze een partij webdiensten hebben.) En toch heb je een cloud-account nodig om het apparaat überhaupt te kunnen gebruiken.
En dat niet alleen, ook Homey kent 3rd party integraties, waar je nog steeds gewoon een account bij de betreffende leverancier-cloud nodig hebt. Bijvoorbeeld de Husqvarna (automower) integratie kan alleen maar via de Husqvarna API, en die is alleen online beschikbaar.
Dat is nog tot daar aan toe. Daar kan LG niets aan doen. Dan heb je als klant een keus om het wel of niet te gebruiken via de Homey. Maar het feit dat je voor een apparaat daar claimt alles lokaal te doen, een cloud-account moet hebben, is gewoon raar. (En dan nog eens benoemd dat het ongedocumenteerd hard-coded de Google DNS-servers gebruikt(e))
Ik zeg ook niet dat LG daar iets aan kan doen, of Home Assistant for that matter. Wat ik wil aangeven is dat enorm veel 'smart' / IoT fabrikanten claimen het allemaal zo lekker makkelijk te maken, maar wel van je eisen dat je de eigen app gebruikt, een account aanmaakt en data upload.

Gelukkig is er nu EU2023/2854 zodat je in elk geval het recht hebt bij die data te kunnen.

Het wachten is op een soortgelijke directive die vereist dat slimme apparaten ook altijd lokaal en zonder Cloud connectie te gebruiken moeten zijn, en dan ook met dezelfde functionaliteit als de online variant.

Voordat we wederom een gevalletje krijgen zoals bij Van Moof waar de cloud connected slimme sloten niet meer open konden.
Belachelijk gewoon! En is dat wel legaal?
Alleen als de functies in kwestie of niet geadverteerd waren, in de winkel aangeprijsd werden, op de doos aangehaald werden als selling points, etc. ; of als bij al deze gevallen duidelijk vermeld werd dat deze functies enkel werken middels een koppeling met een smartphone app die een internetverbinding vereist.

Anders heb je wss. te maken met een misleidende omissie.
Zie mijn 1st line post. SInds EU2023/2854 is dat dus niet meer legaal.
Ze willen dan ook niets liever dan dat je gewoon betaald voor hun abonnement en bridge én tegelijk cripplen ze daarom opzettelijk alle andere mogelijkheden: directe API toegang tot de toestellen zelf, hun proprietary bridge is verplicht en die is dan weer beperkt qua lokale functionaliteit tov hun cloud. Driedubbele winst dus (toestel, bridge, abo) om gewoon je kraan/schakelaar/... aan te kunnen sturen.

Voor de twijfelaars: daarom wil je alles dus lokaal houden, zodanig dat ze achteraf de boel niet kunnen saboteren om je uit te melken.
Via de HomeKit integratie kun je niet:
  • Het schema terug zetten op de "auto" stand
  • Geen aanpassingsn voor een duur doen ("zet op X graden voor de komende Y minuten"
  • Is het niet mogelijk om de batterij status in te zien
  • Is het niet mogelijk om de "open raam gedetecteerd" status te zien (deze status heb je altijd, via het abonnement kun je instellen dat de verwarming automatisch uitschakeld).
  • Kun je niet warm water (/tapwater) aan/uit zetten (noch de status inzien).
  • Niet mogelijk om te zien of / hoe "hard" een zone verwarmd wordt (in de app zie je 3 "hitte golfjes" die oplichten afhankelijk van hoe ver de knop(pen) zijn open gedraaid zeg maar).
En dan zijn er vast nog wel meer zaken die ik niet weet/benoem.

[Reactie gewijzigd door RobertMe op 5 september 2025 17:25]

Is het niet mogelijk om de "open raam gedetecteerd" status te zien (deze status heb je altijd, via het abonnement kun je instellen dat de verwarming automatisch uitschakeld)
Even terzijde: dat wil je als je in betonbouw woont, zoals een apartementencomplex, nooit doen. Je wilt altijd de verwarming aanhouden als je lucht, anders creeër je namelijk een situatie waar de veelal vochtige klamme buitenlucht aan de binnenzijde in het beton penetreert en in de loop der tijd krijg je daarvan schimmelvlekken waar niet vanaf te komen is zonder kapwerk.
Hoe zeg je dat? Koude lucht kan minder vocht vasthouden dan warme lucht. Die "klamme lucht" is direct gortdroog qua relatieve luchtvochtigheid zodra het binnen ook maar een paar graden opwarmt. In het stookseizoen is de lucht eigenlijk altijd droger dan binnen, daarom moet je luchten, maar daar hoef je echt de kachel niet voor aan te houden als je de ramen even een uurtje open hebt.
Ik weet ook niet hoe de exacte thermodynamica ervan werkt.
Mijn VVE heeft destijds van de pandbeheerder wel waarschuwing gehad en doorgezet naar bewoners om bij ventileren vooral niet de verwarming lager of uit te zetten omdat je dan risico op vochtinwerking in de binnenzijde van de muren rondom de ramen krijgt, wat tot heel moeilijk te verwijderen schimmel kan leiden.

Kan me indenken dat het niet direct het vocht van de lucht van buiten is dat neerslaat, maar eerder het vocht van de lucht in huis die, als deze rondom de raam abrupt gekoeld wordt, als condens neer gaat slaan.

Eigenlijk hetzelfde effect als condens op de binnenkant v/d raam 's ochtends, alleen dan -- omdat de koude lucht verder de ruimte in trekt rondom het openstaande raam, en niet door bijverwarming gecompenseerd kan worden, trekt het effect door naar de muren.

[Reactie gewijzigd door R4gnax op 6 september 2025 17:56]

Gok dat je pandbeheerder uit zijn nekt lult en eerder moet kijken waarom er vochtdoorslag in je muren plaats kan vinden. Schimmels ontstaan alleen wanneer de relatieve luchtvochtigheid consequent te hoog is. Er is dus of niet voldoende ventilatie dmv een MV box oid, of circulerende afzuigkappen of slechte woongewoonten van bewoners. Of een constructief probleem zoals vochtdoorslag rondom kozijnen van buiten. Geen waterkering e.d.

Action e.d. verkopen wel van die leuke RV metertjes voor een euro. Elke kamer eentje neerzetten, dan kun je zien wat er gebeurt als je aan het luchten bent. Ideaal is het ergens tussen de 50 en 60%.
Wellicht omdat de implementatie via Google Home via de server loopt (ik weet het niet, heb dit spul zelf niet) maar kan me voorstellen dat Google Home dan de cloud API van Tado aanroept als je vraagt om de verwarming lager te zetten. Weet niet of dat via de directe API gaat.
Als je toch al Home Assistant gebruikt snap ik ook niet zo goed waarom je dan via de cloud zou gaan en niet gewoon lokaal.
De meeste mensen weten niet hoe ze het moeten opzetten om hun apparaten ook buitenshuis via hun smartphone te kunnen bedienen. VPN, VPS, netwerkpoorten. Die cloudoplossing maakt het mogelijk om heel eenvoudig voor iedereen om de apparaten overal te bedienen.
Als IKEA het kan met zijn Tradifi spullen moeten andere fabrikanten het toch ook kunnen.

Werkt het niet zonder internet dan moet je een product niet kopen.
IKEA kan het ook niet. Die app kun je alleen in huis gebruiken. Buitenshuis kun je je IKEA-spullen niet zonder cloud bedienen met de IKEA app. Dat kan alleen als je aan de slag gaat met Home Assistant of iets dergelijks.
Wat ik mee bedoel is, als IKEA een oplossing heeft welke zonder oud kan werken dan moet een ander het ook kunnen. Waarom moet alles vanaf een niet thuis locatie bediend kunnen worden.

Ik heb nog nooit een usecase in mijn leven gehad waar ik dacht. Wat fijn dat dat kan.

Ik heb wel heel veel momenten waarbij ik denk. Jee wat gaat dit makkelijk, zo eenvoudig dat iemand spullen in mijn huis kan bedienen. Waarom geen MFA, hoe zit het met beveiliging, ik zie geen SOC2, NIST, ISO op hun dienst, hoe veilig ben ik?
Omdat ik antwoord gaf op de vraag:
Als er lokale api's beschikbaar zijn, waarom zou je dan uberhaupt verbinding willen maken met de cloud api's?
Veel mensen kopen slimme apparatuur zodat het via een app te bedienen is, ongeacht waar ze zijn. Zeker nu zonnepanelen minde rendabel worden willen mensen juist apparatuur kunnen bedienen als ze van huis zijn.
Wat wil je dan uitschakelen? Je panelen of omvormer?

Ik heb nog nooit mijn panelen uit hoeven schakelen, en die paar dagen per jaar dat de prijs negatief is. Is al die heisa niet waard. En bovendien contra productief.

Ik heb een berekening gehad dat de prijzen negatief waren en dat was 20 dagen. Dat saldeerde gewoon weg met mijn dynamische prijzen. Nu heb ik wel thuis batterijen dus laad ik van net bij negatieve prijzen. Ik doe dat geheel geautomatiseerd.
Het is slechts een voorbeeld. Wasmachine aanzetten als de panelen flink terugleveren is een ander voorbeeld. Een alarm uitschakelen is een ander voorbeeld.
Dan stel je de timer toch in terwijl je de was er in doet. Zo doen wij dat, vrouw heeft was stopt die er in, afwas machine gaat ‘s avonds vol, ‘s morgens laatste er bij. Timers instellen en klaar.

Je moet het er toch in stoppen. Eigenlijk zeg je, voor domme mensen die vergeten dat hun machine een timer heeft.

Wanneer mijn spul kapot gaat komt er wel een machine voor in de plaats welke ik lokaal kan aansturen zodat ik de timer niet meer hoef te doen en automatiek ziet of er spul in zit.

[Reactie gewijzigd door WargamingPlayer op 6 september 2025 18:34]

Je kunt overal wel wat op verzinnen dat je die bediening niet nodig hebt. Veel mensen kopen nu eenmaal slimme apparatuur om die van buiten af te kunnen bedienen.

En daarnaast wist ik niet dat timers reageren op de zon. Zover ik weet gaat die op een bepaalde tijd aan en niet op het moment dat de omvormer veel energie teruglevert.
Dan zet je je wasmachine aan als de zon gaat schijnen en 30 minuten later uit omdat de zon weg is.

Je kan beter sturen op de energieprijs in plaats van zon of geen zon. Is stabieler.
Als niet alles beschikbaar is via een lokale API? (Dan kan je je gaan afvragen waarom dat is, we hebben het hier niet over super ingewikkelde berekeningen die je moet maken, de kleinste Pi kan dit al aan).
Bor Coördinator Frontpage Admins / FP Powermod 5 september 2025 17:14
En zo komt uiteindelijk veel 'slimme' techniek achter abonnementen te hangen. Jammer en indirect een beperking van de functionaliteit. Daarom koop ik waar mogelijk alleen zaken die ook 100% lokaal kunnen draaien.
Groot gelijk heb je. Ik was bij het lezen ook enorm blij dat ik destijds mijn bestelling geannuleerd had. Het lijkt er sindsdien niet beter op geworden. Voor mij is 100% lokaal draaien een absolute must, en als je ziet hoeveel er structureel misgaat bij dit bedrijf, dan bevestigt dat alleen maar dat ik die keuze niet betreur.

Daarnaast nog dit, een bedrijf dat na aankoop functies aanpast of van de gratis tier naar een betaalde verplaatst ga ik in ieder geval niet mee in zee en zou ook iedereen afraden dit te doen.
@tado Het is jammer dat de meerprijs niet gewoon duidelijker op de website staat. Door het lezen van dit topic kwam ik er hier pas achter dat er bij de v3+ een soort van abonnementsstructuur achter zit.

Op heel jullie informatiepagina en bestelpagina wordt nergens gerept over het "bijkopen" van auto-assist skill.
https://gathering.tweaker...message/57130507#57130507
Zodra je al in de shop zit van Tado, wordt er inderdaad NERGENS meer gerept over een abonnements structuur, als je van de VOLLEDIGE Tado functionaliteit gebruik wilt maken. Zelfs in de downloadbare informatie bruchure komt dit NIET terug. Of dat netjes is van Tado mag iedereen voor zichzelf bepalen, maar deze informatie voorziening mag beter...
En wie de wiki leest ziet nog meer structurele problemen:
https://consumerrights.wiki/Tado
https://consumerrights.wi...Tado_Smart_Thermostat_app
En de video's:
YouTube: Tado doubles down on a bad decision, falsely flags reviews as defama...
YouTube: Thermostat maker performs psychological experiments on customers: ne...

@KingFox Dat was puur een voorbeeld van eerder gedrag...

[Reactie gewijzigd door jdh009 op 5 september 2025 23:04]

Waar ergens op de Tado website staat die aanpassing van het abo? Heb zelf Tado zonder abo,werkt perfect.

https://www.tado.com/nl/app-services/auto-assist
en is dat vanuit de bedrijven gezien heel raar? Lijkt mij niet toch? Als het jou extra bandbreedte kost waar je niks voor terug krijgt. Een alternatief wat ze zouden kunnen doen is natuurlijk voor grote community projecten een andere regeling treffen. Zoiets als wat er voor studenten ook bestaat.


En natuurlijk dit: @jugger naut
Als er lokale api's beschikbaar zijn, waarom zou je dan uberhaupt verbinding willen maken met de cloud api's? Zijn er veel functionaliteiten die niet lokaal beschikbaar zijn?

[Reactie gewijzigd door Webgnome op 5 september 2025 17:18]

Bedrijfstechnisch zou het logisch zijn om de cloud betaald te maken en lokale toegang gratis. Servers die tien jaar moeten draaien zijn niet gratis, en onderhoud daarvan ook niet, daar zit gewoon mankracht achter die betaald moet worden. Voor een toeslag van honderd euro per smartphoneapparaat kun je die tien jaar wellicht vantevoren betalen, maar dat willen consumenten niet natuurlijk. Dan is zo'n abonnement heel logisch. Bijkomend voordeel: je betaalt ook niet voor je slimme lichtschakelaar als je die niet meer gebruikt.

Helaas "vergeten" bedrijven de tweede optie voor toegang, dus "moeten" ze ineens wel alles betaald maken. Daar raak je mijn sympathie kwijt als klant. Als jij er als fabrikant voor kiest om verplicht alles via jouw servers te laten lopen, regel je maar dat ik de volledige levensduur van het product van die servers gebruik kan maken. En zo'n levensduur is niet één tot twee jaar, zoals ze je willen laten denken, maar gewoon tien of twintig, net als the thermostaat die je tien jaar geleden in de winkel kon kopen. Wil je van je servers af, maak je maar een firmware-update die klanten hetzelfde laat doen zonder servers.

Hopelijk wordt het met Matter beter, maar als ik de reactie van @RobertMe lees, denk ik dat ik beter Tado maar kan vermijden als de pest.

[Reactie gewijzigd door GertMenkel op 5 september 2025 19:25]

Voor lokale toegang zou je ook geld in rekening kunnen brengen. De software moet worden ontwikkeld, moet worden onderhouden, er moet een helpdesk zijn. Zeker als er allemaal wettelijke verplichtingen komen om dat te blijven doen zal er op een gegeven moment toch iets tegenover moeten staan. Leuk? Nee. Maar als het van bedrijven komt onontkoombaar. Het enige alternatief is een grote open source community die het gratis wil doen.
Aan de ene kant wel, maar aan de andere kant zou ik zo'n abonnement verkopen als "toegang tot updates", zoals Microsoft volgende maand doet met Windows 10 en Adobe jarenlang ieder jaar gedaan heeft. Als je geen updates hoeft (omdat je je zaken zelf op orde kan brengen) vind ik niet dat ze voor lokale toegang geld moeten mogen kunnen vragen.

Dat gezegd hebbende zijn fabrikanten verplicht om hun spul te updaten met de CRA dus dat laatste zal wettelijk gezien wellicht geen optie zijn.

Bedrijfstechnisch snap ik het, en ik vind het het overwegen waard mits dit soort dingen maar voor aankoop duidelijk zijn, maar ik denk niet dat ik snel voor basale updates zou betalen met het uitermate slechte track record dat IoT-makers vandaag de dag hebben.
Als je gewoon een goed product levert dat je in de bouwmarkt kan kopen en makkelijk kan installeren zou je de kosten voor software e.d. prima in de kostprijs mee kunnen nemen.

Die dingen zijn niet in 1 jaar aan heel Nederland (als je zo klein denkt) verkocht. Met een goed product zou je gewoon jaarlijkse omzet kunnen blijven realiseren waarmee je ook je software team kan onderhouden.

Als je dat echt goed doet. Dan kan je misschien juist ook nog wel pro features op abonnementsbasis of ander model aanbieden en zo een goede zakcent extra verdienen. Maar als ik het hier allemaal lees is het al maar de vraag of je op den duur basisfeatures kan gebruiken bij Tado.
Voor een lokale deployment moet de software misschien (deels) worden ontwikkeld; totdat er standaardisaties zijn.
Maar dat mag in de eenmalige aanschafkosten meegenomen worden; als het gaat om apparaten die verder niet inherent onveilig zijn, is de hoeveelheid softwarematige maintenance al snel te verwaarlozen als het maar niet onnodig complex opgezet is.

M.a.w; de ontwerper en ontwikkelaar zijn van de grootste invloed op hoe veel maintenance benodigd is, de resultaten van zo'n strategische afweging behoren niet tot de klant tenzij die daar direct invloed op uit kan oefenen.

M.a.w.; lokale apis kunnen het best relatief statisch aangeboden worden, en voor cloud functies kunnen ze dan doen wat ze willen. willen mensen de extra/nieuwe/verbeterde snufjes, kunnen ze abboneren op de cloud. willen ze de functies minstens zoals vanaf dag 1; is dat gewoon zondermeer lokeel te regelen.
Zoals bijvoorbeeld instructies als "verwarm tot x" mogen basaal genoeg zijn dat je kan zeggen dat daar niet doorlopende softwareaanpassingen voor nodig moeten zijn.

[Reactie gewijzigd door Annihlator op 5 september 2025 18:48]

Bor Coördinator Frontpage Admins / FP Powermod @Webgnome5 september 2025 17:20
Vanuit een bedrijf is die gedachte niet heel raar maar de kans bestaat wel dat je vroeg of laat klanten weg jaagt. In dit geval is dit nieuws voor mij al reden om Tado over te slaan. Bijkomend probleem is vaak ook dat de abonnementskosten niet in relatie staan tot de kosten die men maakt voor het connected deel. Het is gewoon een product en melkkoe.
Ik weet niet of je klanten wegjaagt. De meesten gebruikers willen dat het gewoon werkt. Ik ben nu een tijdje terug begonnen met home automation en tot nu toe kost het alleen naar tijd. Vind ik niet erg, eerder leuk, maar veel mensen willen gewoon iets aansluiten en draaien.
Voor IKEA Tradifi heb je toch ook geen cloud nodig. En werkt gewoon. Zo zijn er zat producten die geen cloud nodig hebben.

Ja maar mensen willen alles wat thuis staat ook remote bedienen, want dat is handig.

Maar ik vraag mij af wat er gebeurd wanneer een fabrikant zegt:

Ons product kan je met een app bedienen en kost je € 80 per jaar wil je dat vanaf buiten de deur doen. Voor ieder extra devices komt er € 40 (korting) per jaar bij. Dan gaan mensen opeens rekenen.

Bovendien, wat is de toegevoegde waarde. Ik heb een aantal producten welke ook via de cloud te gebruiken zijn. Maar die functie nog nooit gebruikt. En dan disable je de communicatie van die dingen naar buiten, stoppen ze met werken. In dat geval is het gewoon koop ontbinden en ander product.
De meeste gebruikers hebben helemaal geen idee van API’s. Die hebben een apparaat en een app en die maken zich niet druk over hoe dat technisch in elkaar zit. Het zijn vooral de mensen die actief met home automation bezig zijn die specifiek zoeken naar lokale API’s.
En mensen welke op zoek zijn naar privacy :)
Ik heb al jaren een Tado, maar als ik nu een nieuwe thermostaat zou kopen, zou het geen Tado meer zijn, omwille van het verplichte cloud aspect, en zou ik ook een volledig lokale api willen.
Het probleem is om dat te vinden, want met zulke dingen adverteren de fabrikanten gewoonlijk toch niet
en is dat vanuit de bedrijven gezien heel raar? Lijkt mij niet toch? Als het jou extra bandbreedte kost waar je niks voor terug krijgt.
Het moet bij koop duidelijk zijn dat een abbo verplicht is/wordt. Anders ga je voor gebruikers halverwege het spel de regels veranderen met als gevolg/dreigement dat dure spullen e-Waste worden. Het is dus op zich niet vreemd dat een bedrijf per maand geld wil, maar het is ronduit dom dat ze dat niet bij voorbaat bedacht hebben en vanaf dag één de uitgavenstructuur en inkomstenvorm op elkaar matchen.

Nu was ik zelf bezig mijn radiatorkranen en ketel-aansturing te gaan vervangen, maar Tado gaat nu hoogstwaarschijnlijk van dat lijstje af. Dit soort grappen wil ik niet hebben in een Home Automation waar van leverancier wisselen gelijk honderden euros kost.

[Reactie gewijzigd door J_van_Ekris op 5 september 2025 17:29]

het is ronduit dom dat ze dat niet bij voorbaat bedacht hebben
Dan neemt niemand het, nu heeft iedereen dat apparaat en worden mensen min of meer gedwongen. Hoe kan dat nu dom zijn?
Misschien niet-dom, maar tegelijkertijd minstens slinks.

Je kan het van maar twee mogelijke kanten kijken; of ze zijn te incompetent om in te schatten dat de cloudstructuur zo veel operatiekosten met zich meebrengt, of ze gebruiken dat moedwillig als smoes in een poging de functionaliteit van jouw apparaten achteraf te gijzelen; beiden redenaties zijn iig niet netjes.

Ik zou zelf graag zien dat wetgeving gaat voorzien dat waar een fabrikant alles via de cloud enkel faciliteert (dus lokale api's danwel direct danwel indirect tegenwerkt of verbiedt) geen maandelijkse kosten mag verplichten voor verwacht regulier gebruik van hun apparaten.

in dit voorbeeld is 100 calls per dag te weinig; de apparatuur zou in een vrij normale werking al makkelijk over die grens (kunnen) gaan en de fabrikant bemiddelt dat eerder als het tegen te werken. Dat is natuurlijk een ongezonde vorm van self-reinforcement (motiveert ze indirect het platform moedwillig inefficient te laten) en ik zou vinden dat dat soort strategische of strategieloze keuzes hun financiele resultaten niet op de klanten afgeschoven mógen worden.

Addendum; en als er zon wetgeving komt mag er mede een bepaling komen dat als er nadelige dingen gebeuren binnen een product zijn natuurlijke gebruiksperiode (wss 3 5 of 10jr afhankelijk van t product), de koop *in zijn geheel* ontbonden DIENT te worden, niet mág, maar DIENT.

Dan worden eindelijk de bedrijven in kwestie eigenaar van de financiele risicos en gaan ze er misschien ook eindelijk wat verstandiger mee om. afschuiven is wel erg makkelijk.

[Reactie gewijzigd door Annihlator op 5 september 2025 18:50]

Dan neemt niemand het, nu heeft iedereen dat apparaat en worden mensen min of meer gedwongen. Hoe kan dat nu dom zijn?
Omdat, zoals anderen al terecht aangaven, het óf incompetentie óf bedrog is. Beide zaken waardoor ik een merk permanent van de lijst afvoer als leverancier voor dure apparatuur. Ik sta nu toevallig voor de beslissing tot aanschaf van toch aardig wat (mogelijk Tado) domotica spul en ik moet ze dus nu al niet vanwege het gedrag van het bedrijf, zonder me echt in de kwaliteit van het product verdiept te hebben.

Op korte termijn verdienen ze nu dan een paar stuivers, op lange termijn verliezen ze het. Klanten gijzelen is geen manier van zakendoen. Is me een paar keer nu met domoticaspul overkomen, en bij mij is het een doodsvonnis als leverancier. En ik heb de indruk dat meer mensen er zo over denken.

[Reactie gewijzigd door J_van_Ekris op 5 september 2025 19:32]

Dat boeit alleen mensen die er verstand van hebben. De huis tuin en keuken mensen die via mediamarkt een aanbieding krijgen zullen zon ding aanschaffen om er vervolgens later achter te komen dat ze voor bepaalde features moeten betalen. Dat is en blijft een verdien model. Dat zie je ook met Instagram, tiktok whatsapp,.wij tweakers weten wel wat voor bedrijf er achter schuilt, .aar het gros boeit het niet
Ik denk dat het volgens het consumentenrecht niet mag. Bij een online dienst die je gratis gebruikt mag men op een gegeven moment abonnement eisen als je het wil blijven gebruiken. Bij een fysiek product dat je hebt gekocht mag het volgens mij niet, dat je een abonnement moet aangaan om het te kunnen blijven gebruiken.
Je kunt het product gewoon gebruiken door de fysieke knoppen op de thermostaat omhoog of omlaag te zetten.
Ja, dat snap ik zo heb je het product niet gekocht. Dat diensten op een gegeven moment niet meer werken door technische vooruitgang of redelijkheid van de termijn voor ondersteuning (apps op smarttv's bijv.) blijkt onder het consumentenrecht toegestaan. In dit geval gaat het om het laten betalen van functionalteit die aanvankelijk bij het product geleverd was. Ik betwijfel of dat mag.
Staat het op de verpakking of in de product beschrijving? Nee, daar staat niks vermeld over api limieten.
Zo werkt het natuurlijk niet. Als er een limiet is moet men het erop zetten. In dit geval scherpt men de limiet aan en gaat men geld vragen voor aantallen die aanvankelijk in de prijs voor het product zaten. Dat kan niet.
Zo werkt het wel, als iets bij aankoop al niet duidelijk is, mag je het ook niet verwachten
Dat is natuurlijk onzin. Bij de aankoop worden alleen eigenschappen beschreven die tijdens die aankoop aanwezig zijn. Volgens jouw redenering kan een fabrikant vervolgens alles doen wat niet beschreven stond. Er is geen rechter die daar in mee zal gaan.

Dan ga ik stoelen verkopen en na twee jaar een abonnement invoeren zodat mensen moeten betalen om te mogen zitten. Ik had immers bij de verkoop niets over gemeld en volgens jouw redenering zou dat mogen.
Ik zie het als misleiding, en dat kan een reden zijn om een koop te ontbinden.
Ik zie eigenlijk nergens die verplichting, waar staat dit?

https://www.tado.com/nl/app-services/auto-assist
en is dat vanuit de bedrijven gezien heel raar? Lijkt mij niet toch? Als het jou extra bandbreedte kost waar je niks voor terug krijgt.
Als je het lokaal doet dan hebben ze ook geen bandbreedte kosten :)

Bovendien, je hebt als klant al voor het apparaat betaald. Als het je geld kost dan kan je dat gewoon in de prijs verdisconteren.

Het is meer dat bedrijven graag herhalende inkomsten willen waar ze nauwelijks iets voor hoeven te doen. Alleen wat servertjes in de lucht houden door wat goedkope Indiers. Maar wel van elke klant een tientje per maand trekken. Investeerders krijgen daar een natte broek van.

[Reactie gewijzigd door Llopigat op 5 september 2025 18:07]

Waarom in de prijs verdisconteren? Dan betalen anderen er aan mee. Het moet gewoon zo zijn:

Product heeft functies A,B,C en functie D is optioneel en heeft een abonnement en cloud koppeling nodig. Dan kan je producten vergelijken en daarmee je keuze maken.

Ik wordt ook gek van die producten die dan zeggen: geen internet nodig en dan een * er bij waar ergens staat in letter grootte 1pt dat 90% van de functies niet werkt zonder cloud.
Iemand een idee hoeveel API verzoeken de Tado Home Assistant integratie per dag ongeveer doet?

Ik heb een programma in de Tado App staan. HA haalt enkel de status op, hij stuurt niets aan. Dan verwacht ik dat het meevalt, zou je denken.
volgens mij ververst HA de Tado gegevens elke 5 minuten via de API. dus dan zit je al op 24*12=288 requests op een dag, en daarmee dus boven de limiet van 100 per dag. Echt waardeloos dit. Ik gebruik zelf HA om mijn vloerverwarmingspomp aan/uit te schakelen. Zal op zoek moeten naar een andere oplossing want ik ga hiervoor GEEN abonnement afsluiten.
Na wat ervaringen met apparatuur die (gedeeltelijk) afhankelijk zijn van de server van de fabrikant koop ik nu alleen nog maar apparatuur die volledig lokaal werken en b.v. Met Home Assistsnt volledig functioneel zijn. Je moet even zoeken en vergelijken maar het lukt bijna altijd. Soms ben je wel iets duurder uit. Maar op de lange termijn dan meestal wel weer voordeliger.

Enkele voorbeelden:
  • Verwarming: Tado -> Plugwise.
  • Camera’s: Arlo -> Reolink
De vraag is alleen, hoe lang. Met HA heb je geen SLA of ander soort contract. Je bent afhankelijk van de goodwill van de community. Zo stopte de officiële Volvo integratie van HA enkele maanden geleden ermee. De integratie moest worden aangepast op de nieuwe API van Volvo, maar de ontwikkelaar van die integratie had het HA project verlaten. Er is wel een ontwikkelaar van een custom integratie bereid gevonden om zijn Volvo integratie als officiële integratie aan te gaan bieden maar voor hetzelfde geld komt een integratie gewoon te vervallen als niemand het meer wil onderhouden.
Dat ben ik met je eens. Maar dat risico is veel kleiner dan wanneer een fabrikant stopt met ondersteuning.

Bij HA is de kans toch wel aanzienlijk aanwezig dat een ondersteuning door iemand anders over genomen wordt waardoor je het gewoon kan blijven gebruiken. Als het om een fabrikant afhankelijke ondersteuning gaat is het gewoon meteen en voor altijd afgelopen als die er mee stopt of er plotseling veel meer abonnementsgeld voor vraagt.
Dat weet ik nog zo net niet. HA is nu populair en actueel maar dat kan ook snel aflopen. Populaire integraties zullen misschien snel opgepakt worden door anderen maar integraties met een handjevol gebruikers niet.
Helaas heb ik vaker meegemaakt dat een fabrikant support er uit trok dan dat HA niet meer werkte. Sterker nog, ik ben ooit op HA overgestapt omdat een fabrikant stopte met ondersteuning (faillissement) en ik niks meer kon bedienen (Thermosmart).
Maar HA is nog betrekkelijk nieuw. De eerste jaren was het vooral iets voor hobbyisten en pas de laatste jaren is het ook toegankelijk voor mensen die minder kennis hebben. We weten niet hoe dat over tien jaar is. Dan is de nieuwigheid eraf en verplaatsen belangrijke ontwikkelaars zich misschien naar een nieuw project.
volgens mij ververst HA de Tado gegevens elke 5 minuten via de API. dus dan zit je al op 24*12=288 requests op een dag, en daarmee dus boven de limiet van 100 per dag. Echt waardeloos dit. Ik gebruik zelf HA om mijn vloerverwarmingspomp aan/uit te schakelen. Zal op zoek moeten naar een andere oplossing want ik ga hiervoor GEEN abonnement afsluiten.
Je kan nog proberen om de Tado (via de Tado bridge) in HA als Homekit device te zetten, is redelijk beperkt maar als je alleen wat simpele dingen wilt doen zoals aan/uit en temp. instellen en uitlezen is dat lokaal te doen zo vaak je maar wilt.

https://basontech.com/blog/tado-smart-thermostat-in-home-assistant-without-internet-or-cloud-app/

Ik heb dat zojuist gedaan en voor verdere integratie of automatisering scriptjes buiten HA kan je vervolgens weer je HA api aanspreken. Werkt op zich prima.
Als ik in Tado iets aanpas wordt het niet direct ververst in hass. Maar denk wel snel genoeg dat je er met 24 uur in een dag al snel meer hebt. Laat het eens per 5 minuten zijn, zit je er ook snel aan.

Denk dat er wel genoeg nerds, zonder en met hass, zijn die toch al abo hebben omdat dat nodig is voor geofencing.
Tado heeft al contact gehad met Home Assistant en de ontwikkelaars gevraagd om meer gebruik te maken van tado's lokale api's. Het quotum biedt volgens tado nog genoeg ruimte voor 'basisgebruiksscenario's' die niet beschikbaar zijn via tado's lokale api's.
Ik ben wel geïnteresseerd in een thermostaat als ik deze met een lokale api kan gebruiken. Is dit inderdaad mogelijk met Tado of is dit een wassen neus? 'basis scenario's niet beschikbaar via Tado's lokale api's' klinkt dan weer niet veelbelovend.
Voetnoot: dit heeft geen invloed op Tado X gebruikers, want die koppelen Home Assistant via Matter, waardoor home assistant niet eens weet heeft van de Tado cloud.
Met de Plugwise Adam kan alles gewoon lokaal draaien in HomeAssistant. Geen API of cloud abonnement nodig..... Just saying.....

(Paar jaar geleden in alle haast een Tado aangeschaft nadat we (natuurlijk in de winter) met een kapotte thermostaat zaten. Zodra het pakket op vrijdag binnenkwam geinstalleerd en vervolgens bleek dat het profiel van mijn ketel niet aangezet kon worden en ik daar Tado voor moest benaderen. Zij zouden dan het profiel op afstand activeren, maar ja, Tado support was pas op maandag weer beschikbaar (!). Na het hele weekend handmatig de draadjes verbonden te hebben om de ketel weer even te starten (en de kabeltjes weer los te halen als de verwarming weer even uit kon), was ik snel genezen van een cloudafhankleijke thermostaat. Nog voordat de Tado op maandag geactiveerd werd. Na een betere speurtocht werd het de lokaal werkende en toch slimme Plugwise.)
Interessant, naam klinkt bekend maar nooit naar gekeken. Hoe houden de thermostaatknoppen zich op batterijen?

Draaien ze ook op oplaadbare batterijen of geven die te weinig stroom om de knoppen te kunnen openen (zoals bij de Tado?)
Sorry, heb alleen de Plugwise Adam. Geen ervaring met de radiatorknoppen.
Op zich moeten 100 api aanroepen ruim voldoende zijn, maar als je de thermostaat als thermometer voor je systeem gebruikt en die elke vijf minuten gaat uitlezen, dan heb je een probleem. Je zal dan terug moeten naar twee tot vier keer per uur. Als je 's nachts één of twee keer per uur de temperatuur uitleest, dan houdt je voldoende over om overdag vier keer per uur de temperatuur op te vragen en nog voldoende calls over te houden om de instelling van de radiatoren bij te stellen.

Wanneer je je huis in afzonderlijke zones heb verdeeld (met aanwezigheidssensoren), dan kom je snel over de 100 calls per dag en is het beter om over te stappen op de lokale api.


Om te kunnen reageren moet je ingelogd zijn