Skrivet den 21 oktober 2018 kl 12:39 av Krönika9 kommentarer2663

Z-Wave – En systemarkitekts synvinkel
Jag är inte imponerad

Lite sent in i matchen kan man tycka men jag har börjat titta på smartahemlösningar den senaste tiden. Det finns ju inte så mycket att välja på; Zigbee, Plejd och Z-Wave – och några till. Jag valde Z-Wave mest för att Fibaro verkar populärt och det var mest snack om dem på nätet, med andra ord kanske enklast få support?

Hur som helst, jag har lekt de senaste dagarna med Z-Wave och det blir ju naturligt att titta på deras system ur ett perspektiv som mjukvaruarkitekt. Och för att uttrycka det milt, jag är inte imponerad.

Deras lösning på kommunikation mellan enheter är något de kallar associationsgrupper, ett gäng kommandon att skicka kan man förenklat säga. Som ett exempel, en Fibaro-knappsats (Fibaro Switch 2) kan skicka Grupp 3 (Dimmerkommandon på kanal S1) till samma grupp på tex en Fibaro Dimmer och på så sett fjärrstyra en dimmer via en knapp på väggen. På grund av den bristfälliga abstraktionen kan du enbart vara säker på att du kan prata mellan enheter om du håller dig till Fibaro – och det är inte ens säkert att saker och ting kommer fungera då.

Abstraktion kanske inte är ett ord folk utanför IT-svängen känner till men Wikipedia beskriver det bra:

”Inom datavetenskap innebär abstraktion att man döljer de tekniska detaljerna bakom ett lager av kod som erbjuder ett enklare gränssnitt mot omvärlden.”.

Enklare sagt, Enhet A producerar något som B kan använda, men varken A eller B har någon insikt i vad den andra gör.

Z-Wave har NOLL abstraktion! Noll! Som en systemarkitekt kommer detta som lite av en chock. Det är till och med ett skolexempel på hur man INTE ska designa sin arkitektur, varför ska en knappsats ha kännedom om hur en dimmer fungerar? En knappsats är binär, varken mer eller mindre. Men här har Fibaro-knappsatsen implementerat hela logiken för hur en dimmer fungerar och skickar dimmerkommandon till mottagardimmern som sedan dimrar istället för att knappsatsen skickar ett binärkommando och låter dimmern avgöra hur den ska tolka kommandot. Vi pratar arkitektur för dummies här, alla vet att detta är dålig design. Vad de borde ha gjort istället är att ha definierade enkla kommandon, tex BinaryCommand, NormalizedCommand (Värde mellan 0-1) etc, och låta dimmern avgöra hur dessa ska tolkas.

Vad som gör det ännu värre är att det inte finns något robust sätt för Knapp 1 (Vi kan kalla den för Kanal 0) att skicka sina kommandon på Kanal 0 eller Kanal 1 på dimmersidan, den är hårdkodad för Kanal 0. Grupp 3 är hårdkodad på knappsatsen för att skicka dimmerkommandon på Grupp 3 på mottagaren och Grupp 5 är hårdkodad för att skicka dimmerkommandon till Grupp 5 på mottagaren och det finns alltså inget enkelt sätt att styra om detta. Du kan lösa det genom att skicka alla kommandon genom din kontrollenhet och styra om kommandona till önskad grupp. Men detta medför grova fördröjningar vilket gör det omöjlig att dimra då du kommer dimra för mycket eller för lite på grund av fördröjningen.

Jag skulle istället byggt upp systemet såhär, varje enhet kan skicka en uppsättning inställningar till kontrollenheten som beskriver vad den kan hantera. Ett exempel på en knappsats som enbart har utdata och ingen indata skulle vara:

{
   out: [
      {
         channel: 0,
         commands: [BinaryCommand]
      },
      {
         channel: 1,
         commands: [BinaryCommand]
      }
   ],
   in: []
}

Vi säger åt kontrollenheten att vi kan producera binära kommandon på två kanaler. Kontrollenheten kan då låta dig skicka dessa kommandon på valfri kanal på mottagarsidan, tex en dimmer.

En till rolig iakttagelse jag gjort är att det finns ingen knappsats utan relä. Så om jag bara vill ha en knappsats som skickar data till andra enheter är detta omöjligt. Jag får köpa en enhet med relä som är både dyrare och onödigt stor, åter igen en indikation på att något inte tänkt.

Z-Wave – A system architects view