Wie is de baas van jouw smarthome?

Een paar jaar geleden stonden smarthome-producten aan het begin van hun ontwikkeling en probeerde iedereen een eigen ecosysteem te bouwen waarbij producten niet compatibel waren met elkaar. Lastig, maar de verwachting was dat dit uiteindelijk wel opgelost zou worden. Om slimme producten echt te laten doorbreken, moeten producten van verschillende partijen immers kunnen samenwerken. Op het eerste gezicht is dat eigenlijk ook prima gelukt. Op steeds meer verpakkingen prijken logo’s van Amazon, Google en Apple: een teken dat deze producten samenwerken met die ecosystemen. En veel producten ondersteunen meerdere van deze platformen. Kortom, missie geslaagd. Voor veel gebruikers is dat ook zo, want de producten zijn prima te bedienen met de bijbehorende app en werken bovendien samen met de gewenste slimme assistent. Maar geldt dat ook voor iedereen?

Wat is een standaard?

Wanneer je het over smarthome-producten hebt, dan heb je het al snel over standaarden. En die standaarden worden vaak op één hoop gegooid. Standaarden als Apple HomeKit, Google Home, Zigbee en Z-Wave worden in één adem als smarthome-standaarden genoemd. De ene standaard is echter de andere niet. Je moet onderscheid maken tussen enerzijds standaarden die een achterliggend ecosysteem beschrijven (zoals Google Home en Apple HomeKit, die ervoor zorgen dat producten op netwerkniveau met elkaar gekoppeld kunnen worden) en anderzijds standaarden die producten op een ander niveau met elkaar koppelen. Dat andere niveau betreft in het geval van producten die voor de doorsnee consument interessant zijn, draadloze standaarden in de vorm van Zigbee, Z-Wave en onbeveiligde 433MHz-protocollen zoals Klik-Aan-Klik-Uit (KAKU). Zo vormt Zigbee en dan specifiek het profiel Zigbee Light Link (ZLL) de draadloze basis van slimme lampen van onder andere Philips Hue, Ikea Trådfri, Osram Lightify en Innr. Z-Wave wordt dan weer veel gebruikt voor schakelaars en sensoren (zoals bewegingssensoren en rookmelders), terwijl je KAKU-producten in iedere bouwmarkt vindt. Daarnaast worden natuurlijk ook andere draadloze standaarden gebruikt variërend van wifi of bluetooth tot bedrijfseigen protocollen in het geval van verwarmingsproducten.

Meer dan draadloze standaard

Een draadloze standaard als Z-Wave of Zigbee is nog geen domoticasysteem. Je wilt je product immers kunnen bedienen met een computer of je smartphone. Zonder iets dat een koppeling maakt tussen de draadloze producten als een lamp en je smartphone is dat niet mogelijk. Vandaar dat veel kant-en-klare producten die gebruikmaken van een open standaard voorzien zijn van een bridge (of basisstation). Die bridge verzorgt uiteindelijk de koppeling met je thuisnetwerk. Die bridge is in het geval van verlichtingssystemen overigens doorgaans ook de oorzaak dat verlichtingssystemen niet compatibel zijn met lampen van een ander merk. In theorie voldoen al deze lampen aan de ZLL-specificaties en zijn ze hierdoor compatibel met elkaar. In de praktijk zul je soms toch problemen ondervinden, omdat de bridge de lamp herkent als lamp van een ander merk waardoor die uiteindelijk niet door de bridge aan de achterliggende app getoond wordt. En ook het updaten van de software is via de bridge van een andere fabrikant onmogelijk. Vandaar dat je ook bij systemen van een fabrikant die zogenaamd gebruikmaakt van ‘open standaarden’ vaak toch het beste de eigen spullen kunt gebruiken.

Focus op slimme assistenten

Voor een domoticasysteem is dus meer nodig dan het gebruik van een draadloze standaard en de meeste fabrikanten bieden daarom een eigen app waarmee een product te bedienen is, vaak gekoppeld aan een achterliggende clouddienst. Fabrikanten zien daarnaast in de platformen die door Google, Amazon en Apple worden aangeboden een eenvoudige manier om hun producten te integreren met die van andere fabrikanten. Daar is wel iets voor te zeggen, want voor een eindgebruiker werken deze platformen eenvoudig en je kunt je hele huis vervolgens bedienen met bijvoorbeeld je Google Home. Het probleem is alleen dat voor veel producten die ondersteuning voor één of meerdere van deze slimme platformen ook de enige mogelijk vorm van koppelen is. Wanneer je na enige tijd bijvoorbeeld zelf een domoticasysteem wilt bouwen met een eigen controller, al dan niet op basis van software als Domoticz of Home Assistant, dan heb je in het gunstigste geval een grote uitdaging en in een minder gunstig geval een probleem.

Tuya-platform

In eigen hand?

Wil je niet afhankelijk zijn van een slimme assistent, dan kan dat op drie manieren. De eerste is het gebruik van producten volgens open standaarden als Z-Wave en Zigbee. Lampen, sensoren, schakelaars enzovoort die voldoen aan de door jou gekozen open standaard kun je koppelen aan een geschikte radio in een eigen domoticacontroller. Hetzij een compleet product met eigen radio’s zoals de Athom Homey, of een zelfbouwoplossing op basis van bijvoorbeeld Domoticz of Home Assistant op iets van een Raspberry Pi die je voorziet van de juiste radio’s. Je kunt op die manier ook slimme lampen die gebruikmaken van Zigbee direct koppelen zonder de bijbehorende bridge.

De tweede manier is een lokale api die door een slim product op je thuisnetwerk wordt aangeboden. Een bekend voorbeeld van een product met een lokale api is Philips Hue. Niet alleen blijft een lokale api ook werken als de internetverbinding een storing heeft, het biedt ook voordelen als de fabrikant stopt met de ondersteuning. Signify (het voormalige Philips Lighting) is dit jaar bijvoorbeeld gestopt met de ondersteuning van de eerste variant van de bridge, waardoor deze niet meer volledig werkt in de eigen app. Dankzij de lokale api blijft een koppeling met een eigen domoticasysteem toch werken. Wel kan het zo zijn dat er Hue-producten op de markt komen die niet meer te koppelen zijn aan de oude bridge. Het volledig vasthouden aan open standaarden of een lokale api heeft ook nadelen. Vaak is het duurder, moet je veel uitzoeken en is het configureren van je systeem lastiger.

De derde manier is een api die door de fabrikant van je smarthomeproduct wordt aangeboden, maar die wel afhankelijk is van een clouddienst van een fabrikant. Dat kan prima werken, maar je bent dan natuurlijk nog wel steeds afhankelijk van een internetverbinding.

Wat als de ondersteuning stopt?

Maar ook als je er op let dat je slimme product een api heeft, dan is dat geen garantie dat het altijd blijft werken. Veel api’s maken gebruik van achterliggende clouddiensten en die moeten natuurlijk ondersteund worden. Dat ondersteuning stopt als een fabrikant failliet gaat of als een product al lange tijd niet meer te koop is, is nog enigszins te begrijpen. Maar een fabrikant kan natuurlijk altijd van strategie veranderen. Een bekend voorbeeld van een fabrikant die stopte met ondersteuning voor een api is Google. Voor de Nest-producten zoals de thermostaat bood Google in de vorm van ‘Works with Nest’ een api aan die behalve door ontwikkelaars ook gebruikt kon worden door eindgebruikers om hun slimme apparaten te integreren in een eigen domoticasysteem. Google besloot echter te stoppen met ‘Works with Nest’ en over te gaan naar ‘Werkt met de Google Assistent’.

Wanneer je enkel de apps van Google gebruikt niet zo’n groot probleem, voor gebruikers die hun thermostaat willen integreren in een eigen domoticasysteem een cruciaal verschil, want Googles nieuwe platform biedt niet langer een api. Gebruikers van domoticasystemen hebben inmiddels wel omwegen gevonden om de Nest-thermostaat weer te integreren, maar ideaal is deze situatie niet, want deze methodes worden sowieso niet ondersteund. Dit voorbeeld geeft aan dat ook als een fabrikant de mogelijkheid van een api biedt en het product goed verkocht wordt, het toch geen garantie is dat de koers van een fabrikant later niet verandert. In het geval van Google is de nieuwe koers duidelijk: er wordt gefocust op de Google Assistent als centrale spil van het slimme huis.

Een bijeffect van clouddiensten is natuurlijk ook dat het voor een fabrikant eenvoudig wordt om (eventueel later) een abonnementsmodel te hanteren. Iets om zeker rekening mee te houden.

Niet altijd keuze

Helaas is een api voor lokaal gebruik zonder cloud vrij zeldzaam. De meeste bekende en ‘gebruiksvriendelijke’ smarthome-producten hebben zo’n api niet. Soms kun je via een omweg als IFTTT nog toegang krijgen, maar ook dat gaat via een webdienst. Wil je een product dat bij je past, dan ontkom je meestal niet aan de afhankelijkheid van clouddiensten. Je zult zien dat die ene slimme thermostaat die alles doet wat jij wilt, volledig afhankelijk is van een achterliggende clouddienst. Zolang je je realiseert dat je afhankelijk bent van een clouddienst, kun je die afweging natuurlijk maken. In het gunstigste geval zorgt een verandering ervoor dat je een product niet meer aan een eigen systeem kunt koppelen, in een minder gunstig geval werkt je product helemaal niet meer en moet je het vervangen.

En andersom?

Conclusie

De verbindende factor tussen verschillende smarthome-producten lijkt steeds sterker te komen vanuit slimme assistenten als Google Assistant, Amazon Alexa en Apple Siri. Aan de ene kant is dit positief: de toenemende mate van integratie met deze platformen zorgt ervoor dat het voor de eindgebruiker eenvoudig is om producten van verschillende fabrikanten met elkaar te koppelen. En je hebt vaak ook nog eens de keuze uit meerdere platformen. Wil je echter meer, bijvoorbeeld een zelfgebouwd systeem, dan is de focus op de slimme assistentplatformen een beperking. Veel fabrikanten bieden naast ondersteuning voor deze platformen geen andere api aan. Wil je kortom een smarthome-systeem hebben dat je ook zonder tussenkomst van bijvoorbeeld Google kunt bedienen, dan heb je alleen echte zekerheid als je jouw systeem qua communicatie baseert op open standaarden als Z-Wave of Zigbee.