Smarta Hem 7.0 – Design

Vi börjar nu närma oss den slutgiltiga design som blir grunden för vårt Smarta hem 7.0. Det vi ansåg viktigt för vår trivsel och komfort i vardagen ingår i designen. Säkerligen kommer det ske uppdateringar i våra design även efter publicering, och då uppdaterar vi det här inlägget med den informationen, eftersom detta även är vår dokumentation.

Mål med designen

Den design vi beslutat oss för att gå vidare med uppfyller de mål och krav vi satt. Detta betyder inte att vi har rätt, men utifrån målen och det vi idag vet om smarta hem så är det ”good enough”. Vi har delat upp designen lager för lager, och kommer i varje del förklara varför det blev ett visst på ett visst sätt eller system.

Viktigt att nämna här är att ALLT vi skriver här är utifrån vår egna uppfattning, kunskap och summering av krav. Det behöver inte betyda att det stämmer för dig, och därför kanske du inte håller med om ett val vi gjort. Men utifrån de mål vi satt och den erfarenhet vi skaffat sedan vi började med smarta hem, kom vi helt enkelt fram till att detta var den optimala lösningen för oss (på papper än så länge). Får vi feedback eller tips om sätt att göra något bättre så är vi självklart tacksam för det. Vi tänkte nämligen inte bygga om vårt hem igen på en överskådlig tid, om den här designen fungerar som vi önskar.

Mål / Krav

  • Säkert
  • Stabilitet, funktionalitet & tillförlitligt
  • Flexibilitet
  • Låg komplexitet (här kommer vi tulla en del för att få funktionalitet & tillförlitlighet)

Utifrån dom fyra målen så blev det uppdelat på 3 hårdvaror. Vi har dessutom flera system på en hårdvara. Detaljer om respektive steg kommer i inlägget. Vi har många mindre system som inte syns på skisserna, dessa anser vi är sekundära i vår lösning just nu och blir ”add-ons” i kommande inlägg.

De system vi väljer att automatisera med är följande
De olika system vi kommer använda oss av är följande

I kommande inlägg (troligen Smarta Hem 7.0 – Installation) bygger vi upp enligt detta inlägget. Vi skulle verkligen uppskatta feedback på det här inlägget, eftersom nästa del kommer bestå i hur vi sätter upp del för del av det vi nämner i detta inlägget rent tekniskt. Troligen så kommer vi revidera detta inlägg en mängd med gånger innan vi känner oss nöjd (även om vi är nöjd just nu).

Planen är att inte skrämma dig som funderar på att designa ditt smarta hem, eller bara vill se hur vi valde att göra. Det är mycket information på både en övergripande och delvis på en mer teknisk nivå. Men tanken är att varje del ska vara nog förklarande och besvara ”varför” vi väljer att göra på ett visst sätt, du kanske hittar ett område du är intresserad av, kanske kan syna hur vi tänkte och se om det liknar dina krav.

Senast Uppdaterad: 2021-02-03

Meny

Bakgrund

Varför vi lägger så mycket tid med att bygga upp vårt hem på nytt? för att svara på det så rekommenderar vi att du läser igenom vårt första inlägg om Smarta hem 7.0 ( https://automatiserar.se/smarta-hem-7-0/ ). Men lång historia kort, vi har adderat och adderat funktionalitet sedan 2014 hemma, problemet blev dock att en lampa tändes helt random, och innan vi hittade orsaken så var alla i familjen tillräckligt road för att motivera en städning bland systemen. Och när vi väl gör det så tänkte vi även arbeta bort det vi idag anser som rena brister.

Av någon anledning så tänds 1 lampa 110% sporadiskt, vi hittade dock orsaken till sist

Utöver de fyra huvudmålen så hade vi en mängd mindre önskemål att uppfylla med. Så dessa mindre mål har varit en del vi haft i åtanke när vi till slut valde den lösning vi nu kommer bygga vidare på.

Vilket mål har vi med designen:

  • En lösning som är robust och inte stör vardagen om något strular (primär / sekundärbelysning )
  • Uppdelat så att familjen känner att det är enkelt och att gäster kan hantera belysning utan appar och kunskap om systemen.
  • Lösning som är robust och även skulle kunna användas som ett extra larm.
  • App som är enkel att hantera på telefoner även när man inte är hemma.
    • Notiser direkt om något uppkommer.
    • Möjlighet att svara tillbaka utifrån pushnotiser
  • Dokumentera hur allt hänger ihop och minska mängden system.
  • Jobba bort alla de bekymmer vi idag upplever.
  • Uppgradera säkerheten och begränsa åtkomsten till system & Internet.
  • Undvika Felaktiga inrapporteringar
  • Kalibrerade sensorer (eller möjlighet att kalibrera dom)
  • Sensorer med Prisvärda batterier.
  • Energimätande enheter på Z-Wave eller WIFI ( mer om orsak senare )
  • Dokumentation över placering och användningsområde.
  • Mäta in Temperatur & luftfuktighet i alla rum
  • Mäta in Ljus och rörelse i alla rum.
  • Mäta rörelser på gården, dvs på båda sidor om huset.

Vilka risker och avvägningar har vi tagit med i vår design

  • Vi håller inte på med hemautomation för att spara pengar, det hade i så fall varit billigare att bara vrida ner värmen och köpa en filt & lågenergilampor!
  • De primära funktionerna i huset ska gå att styra även om allt smart är nedstängt, vilket betyder att knappar till belysning finns kvar och att vi tar smällen om det blir strömavbrott, när strömmen kommer tillbaka kommer alla lampor att vara tända en stund.
  • Vi har för gammalt hus och inte någon budget för att göra något med KNX, vi skulle kunna tänka oss ett inbyggnadssystem. Men just nu händer det för mycket på marknaden för att vi skulle riskera det. Se bara på Nexa och 433Mhz enheter som byggdes in, idag är det nästan en säkerhetsrisk med 433Mhz sensorer utan kryptering för styrning av 230V utrustning.
  • Vi gör detta för att värna om miljön med tänket många bäckar små. Några smärre justeringar i ett hus kanske inte gör skillnad, men blir det några tusen hus så gör det stor skillnad. Där bland räknar Tado termostater och vår egna digitala termostat för Folding är några av de delar vi gör för att dra vårt strå till stacken.
  • Vi gör detta för att långsiktigt spara tid, öka bekvämligheten och tryggheten ( just den biten med att spara tid gäller nog inte oss eftersom vi dessutom skriver om allt, vilket även tar en mängd tid)
  • Att köpa något som är gratis idag kan betyda att det det slutar fungera inom något år, mycket på grund av att det då finns lite incitament att fortsätta utveckla. Det finns även en stor risk att strategin för produkten över tid är att börja ta betalt.
  • Att det ofta är villhöver faktorn som åsidosätter ett konkret behov. Vi har verkligen försökt att göra något vettigt med Psx clima fläkten som styrs via Bluetooth, men inser att en vanlig fuktstyrd fläkt hade fyllt behovet. Nu försöker vi se

Vad har vi insett när det gäller smarta hem

Vi kommer undvika att bygga kärnan i vårt hem med utrusning som förlitar sig helt på internetuppkoppling mot molntjänster. Detta på grund av att vi vill ha kontroll på när och hur utrustning ska bytas. Vi har tyvärr sett en trend att allt fler lösningar idag övergår till att erbjuda funktionalitet som extra tjänster för en kostnad, ofta dyker detta upp något/några år efter produkten lanseras.

Senaste i raden av molntjänster som börjar skruvat ner funktionalitet är IFTTT, vilket var en lösning vi nyttjade väldigt mycket fram tills IFTTT med en månads varsel införde en kostnad. När detta inträffade så insåg vi hur sårbart ett hem blir om allt baseras på något som förväntas vara gratis. Nu är det inte så att vi inte tycker att det ska kosta pengar att nyttja molntjänster, men när det kostar pengar så ska det inte införas på det mycket offensiva sättet som IFTTT valde att göra det på.

Nästa del vi vill göra är att just ha möjlighet att blanda mängder av olika system, tekniker och sedan koppla samman dessa. Här har vi under en lång tid kört Home Assitant eftersom den erbjuder just detta. Men även här har vi funderat om på grund av de säkerhetshändelserna. Nu ska vi säga att Home Assistant skötte detta mycket bra och gick ut i tid med att det var viktigt att uppdatera alla installationer för att undvika säkerhetshålet. Dessutom så stängde nabu casa (extern länk) ner åtkomsten från internet mot Home Assistants som ej var skyddade (om vi inte hört fel).

För vår egna Home Assitant installation som inte direkt är publicerad mot internet var det inte någon fara. Men hade vi tillåten den mot internet och kört några av dessa plugins så hade vår information i home assistant kunnat hamna på villovägar. Så därav väljer vi att enbart köra Home Assistant Internt och via Homey när vi vill nå vårt hem externt (Mer om hur i kommande inlägg).

Med den designen kan vi välja att avvakta lite med uppdaterar när vi känner att tiden inte räcker till eller att det är för stora ”Breaking Changes”. dvs ändringar som gör att integrationer eller funktionalitet behöver konfigureras om på nytt.

Val av hårdvara

När det gäller hårdvara så kommer vi installera det mesta på en Intel Nuc med Hass.io. Orsaken att vi väljer en NUC och inte att installera detta virtuell på en server, är på grund av att vi vill ha Home Assistant helt fristående och oberoende av annat som testas. Men vi kommer även använda oss av Homey och Philips Hue Hub. Att vi väljer tre hårdvaror och sedan säger att vi vill ha en enkel och stabil lösning pratar emot sig själv.

Vi kommer nytta en extern 2.5″ ssd för att få mer utrymme än vad den inbyggda disken hade möjlighet till.

Intel Nuc & HASS.IO
Den hårdvara vi kör Home Assitant och de andra mjukvarorna på är en Intel Nuc.

Vi insåg att den mängd sensorer vi vill använda, och de olika bristerna vi upplever i de olika lösningarna gör minst ont så här. Nu kan vi erkänna att vi kanske gillar att skapa grafer och samla på oss onödigt mycket data från sensorer. Men för att kunna fortsätta med det utan att resterande av familjen skulle uppleva de brister vi idag lider av så blev det så här till slut.

De system vi väljer att automatisera med är följande
De olika system vi kommer använda oss av är följande

Skydd för strömavbrott

I den design vi kommer bygga så har vi valt att skydda den primära utrustningen med UPS, vilket är en batteribackup som ger spänning till utrustningen ca 30 minuter. Detta gör att vårt internet och den utrustning som finns inkopplad där hinner larma om hushållet blir strömlöst. Samtidigt så skyddar detta utrustningen mot överspänning och åska sommartid. Så detta anser vi är en billig försäkring för att undvika onödiga larm. Vårt WIFI drivs dessutom av Power Over Ethernet (POE), vilket gör att vi kan tappa strömmen, men under en period fortfarande komma åt Homey och Home Assitant på vårt WIFI från mobiler.

Vi väljer en UPS från APC
Den UPS vi använder oss av är från APC.

Vi väljer att bygga upp den primära lösningen baserat på tre olika enheter. Homey och Home Assistant (även kallat HASS) för styrning av smarta hem produkter. Sedan väljer vi dessutom att nyttja Philips hue för den primära belysningen. Detta innebär att vi kommer ha flera Zigbee nätverk aktiva samtidigt.

Den utrustning vi väljer att skydda är Homey och Hass samt WIFI. Vi anser att Philips Hue inte gör någon nytta utan ström.

Design av nätverk för smarta hem

Som vi nämnde i början av inlägget så är säkerhet en del vi kommer arbeta mycket mer med nu i version 7.0 av vårt smarta hem. Orsaken till detta behöver vi nog inte gå in på i detalj, men vi kan säga så att alla system någon gång får en brist eller att en enhet tar med sig en oönskad programvara in i ditt hem. Får en tid sedan så uppdagades en sårbarhet i Home Assitant. Att det kommer sårbarheter är inte något nytt, men problemet är att dessa sårbarheter omgående behöver uppdateras. Men för att säkerställa att all utrustning hemma inte kommunicerar fritt med internet eller varandra utan vår vetskap så kommer vi segmentera upp vårt nätverk.

Vi kommer inte tillåta vår Home Assisant att vara åtkomlig från internet direkt. Blir det aktuellt så kommer det ske via VPN på telefoner. Den primära kommunikationen kommer ske från Homey när vi är utanför hemmet, mycket på grund av appen och enkelheten att hantera notiser mm. Nu kan detta kanske ändras över tid, men till en början blir det Homey eftersom familjen har den på telefonerna och upplever den som enkel.

Den synligaste segmenteringen blir på WIFI sidan, där kommer vi nu skapa upp 4 olika SSID:n för att enkelt kunna begränsa all wifi kopplad utrustning, samtidigt som vi begränsar vilka frekvenser och kanaler som får nyttjas. Detta gör vi för att inte krocka med Zigbee på 2,4 Ghz bandet.

Syfte med de begränsade nätverken är att helt enkelt kapsla in trafiken och styra så mycket som möjligt med regler i vår brandvägg och via Vlan. Nu är detta kanske överkurs, men vi väljer som sagt att göra vårt smarta hem 7.0 säkert och långsiktigt. Varje box begränsas och kan endast kommunicera ner mot brandväggen. Ett nätverk väljer vi dessutom helt att neka åtkomst till internt, det nätverket kommer innehålla våra ESPHome sensorer och kameror till en början.

Bilden förklarar hur vi väljer att skydda vårt IOT och smarta hem.
Designen är tänkt att skydda vårt smarta hem och förbereda det mot eventuella brister som kan uppstå

Val av WIFI

Vi har länge funderat på att köpa en till Ubiquiti för att få bättre täckning och redundans. Det slutade med att det gick helt överstyr och vi valde RUCKUS R550 med stöd för WIFI 6 (802.11 ax) och ”Embedded IoT”. Nu har vi möjlighet att göra de uppdelningar vi har behov av samtidigt som vi kommer få ut den prestanda vi efterfrågar för alla uppkopplade och strömmande enheter. Vill du veta mer om Ruckus R550? ( extern länk ). För som vi skrivit tidigare så är det mycket viktigt att planera WIFI så det inte krockar med Zigbee och dessutom ger den prestanda som behövs även om det strömmas filmer från Netflix mm. 2019 skrev vi ett inlägg om just WIFI och då slutade det med att vi valde Ubiquiti

Valet av wifi slutade med RUCKUS
De krav vi ställde på funktionalitet och kompabilitet gick lite överstyr och slutade med en RUCKUS R550

Design av sensor kommunikation

Vi kommer använda en hel del trådlös kommunikation, därav är designen och valen av frekvenser och kanaler på 2,4 Ghz WIFI mycket viktig. I vårt hem kommer det finnas två primära zigbee nätverk. Ett som hanteras av Philips Hue och ett som hanteras av Deconz via en usb sticka (Conbee zigbee).

Orsaken att vi inte väljer att använda oss av Homey:s zigbee är för att den idag inte stödjer alla Zigbee sensorer vi vill använda oss av. Dessutom har vi mycket länge väntat på en rewrite av zigbee som ska släppas när version 5.0 av Homey släpps. Detta gjorde att vi väljer en integration i Home Assitant med Deconz. Mer om integrationer kommer lite längre ner.

Vi väljer att använda oss av Philips Hue, Homey och Home Assitant för att styra/lyssna på de olika protokollen. Dessutom lägger vi nu till Deconz med en Conbee zigbee sticka.

Philips Hue och Zigbee

Vi väljer att använda Philips Hue för att bygga ett Zigbee nätverk för vår primära belysning hemma. Styrningen av belysningen kan vi sedan hantera via integrationer, mer om detta senare. Men skulle både Homey och Home Assitant gå i backen så kan vi fortfarande styra belysningen via en annan app på mobil eller vi knappar.

Vi har dessutom valt att konfigurera all belysning i Philips hue så att den tänds nästa gång dom startas om dom blir strömlös. Att konfigurera lamporna på det sättet gör att vanliga lampknappar fungerar om även vår Philips Hue väljer att stanna. Den enda nackdelen är om strömmen ofta går i det området vi bor. Men den nackdelen väger vi upp med att vi har en enkel fallback. Skulle en lampknapp vara stängd och därigenom göra lamporna onåbara från Philips Hue så kan vi larma om detta.

Vi vet hur ofta någon tänder eller släcker en lampa på knappen och därigenom stör den mesh som byggts upp, därav så isolerar vi belysning som ofta blir felaktigt hanterad till Philips Hue.

Vad gäller sensorerna i Philips Hue så kommer vi flytta Philips Hue motion för inomhusbruk till Deconz men behålla rörelsesensorn för utomhussensorn i Philips Hue. Orsaken är att vi vill tända belysning ute oavsett om Hass och Homey valt att stanna.

Philips Hue startkit
Med en Philips Hue gateway anser vi att den primära belysningen kan vara smart utan att riskera att gäster eller system hindrar belysningen.

Vilka nackdelar har det att bygga parallella Zigbee nät?

Med detta vägval att använda två Zigbee så tappar vi det mesh nätverk som byggs upp av lamporna till andra sensorer. Vilket gör att vi inte kommer kunna dra nytta av alla lampor som sköts av Philips Hue gateway för att få bättre räckvidd till sensorerna i Deconz.

Deconz och Conbee för Zigbee

Vi har tidigare inte skrivit så mycket om detta på bloggen, dvs Deconz och Conbee. Orsaken är att vi velat lite och tidigare använt Homey för vårt zigbee, men på senare tid så flyttade vi ut mer och mer från Homey till egna Gateways, bland annat IKEA trådfri fick tillbaka alla lampor ett tag. Detta på grund av de ibland skakiga Zigbee nätverk som vi haft med Homey.

När vi sedan valde att nyttja Home Assitsant mer så flyttade vi över belysningen från IKEA trådfri till Philips Hue. Det enda vi nyttjat IKEA Trådfri till nu är för att uppdatera firmware i lamporna. Men när det var gjort så hamnade den på hyllan.

Deconz (Extern länk till deras hemsida) kommer vi skriva mer om i kommande inlägg när vi börjar skriva om hur vi konfigurerar allt. Men vi kan säga att den klarar de flesta av de sensorer vi vill använda och dessutom har bra integrationer till både Homey och Home Assitant.

Vi kommer lägga till all sekundär belysning i Deconz, dessutom kommer vi lägga till en del utebelysning, faller det väl ut så kan det även bli aktuellt att flytta utomhusrörelsesensorn för Philips Hue till Deconz för att bygga ännu bättre mesh för sensornätverket. Att vi endast väljer att lägga sekundärbelysning i Conbee är för att det är minde risk att dessa hanteras manuellt. Vi tänker dessutom att den typen av belysning är det som oftare ska automatiseras och därigenom finns placerade runt om huset med.

Homey för 433Mhz och Z-Wave

Som vi nämnt har vi haft en del problem med Zigbee, och tyvärr även en del problem med Z-Wave tyvärr. Tidigare har vi skött all Z-wave via en Vera Secure och den har skött det mycekt bra, nu ska vi erkänna att vi sakta börjat lämna Z-Wave som protokoll, och därav inte köpt allt för mycket ny Z-Wave utrustning. Detta är nog en av orsakerna till att vi inte haft några problem med VeraSecrure. Tyvärr har Vera haft ett annat problem som gjorde att vi vilde Homey.

Vi ser inte att det händer så mycket utveckling när det gäller dessa Vera enheter, detta är synd eftersom det finns möjlighet för både Zigbee och 433Mhz där. Med det i ryggsäcken så väljer vi istället Homey även om den tyvärr inte varit lika driftsäker historiskt och dessutom saknar både batteribackup (det löser vi med UPS nu) och möjlighet att koppla upp till nätverk med kabel.

Styr nu belysningen i Trådfri med Fibaro Swipe
Styr nu belysningen i Trådfri med Fibaro Swipe

Vi upplever att det händer mycket med Homey och att det utvecklas och uppdateras löpande. Men vi har länge funderat vad som ska finansiera deras molnlösning och utvecklingen av deras ekosystem. Och för ett tag sedan fick vi svar på det, det kostar att ta backup och du kan ej ta backup lokalt. Men vi anser att vi nu kommer nyttja den primärt för att få en smidig app i telefonen. Skulle vi i framtiden inse att Z-Wave inte är stabil så kommer vi installera en Aeotech Z-Stick och RFXTRX till Home Assitant.

Design av integrationer mellan system

Vi kommer använda oss väldigt mycket av integrationer även om detta kan vara lite emot den design vi eftersträvar med enkelhet. Men för att uppnå en central styrning med möjlighet att använda alla typer av sensorer så var detta den enda lösning vi kunde tänka oss. Orsaken att vi inte går all in och låter Home Assitant sköta detta är för att vi då får en single point of failure, vilket innebär att stannar den vid en uppgradering eller strular efter en uppgradering så kan vi fortfarande hantera det mesta.

Vi väljer att låta Hass, Node-Red och Homey sköta automationer. Integrationen kommer ske via Rest & MQTT

Homey och Hass kommer vara gränssnitt för att ta emot och presentera, vi kommer primärt använda Homey utanför hemmet och Hass på surfplattor och som dashboards hemma. Där har det nyligen kommit ett alternativ till Homey med, men vi väljer att avvakta med det. Data och information som ska presenteras på en dashboard kommer skickas till en InfluxDB, vilket inte finns med på skisserna.

Placering av sensorer ( kommer snart / senare )

Den här punkten måste vi återkomma till så fort vi testat klart stabiliteten i det kommande Zigbee mesh nätet. Vi flyttar runt och mäter för att se vad som blir den mest optimala placeringen med. För varje sensortyp vi använder oss av har styrkor och brister, därav blir placeringen ännu viktigare då det avgör hur lång batteritid sensorn får, och hur bra och relevant data som skickas. Med hjälp av hållarna vi skapat (länk till våra hållare, sidan är till för att kunna stötta bloggen och ändå få något tillbaka för att lösa ett problem) kan flytta runt och hitta den optimala placeringen. Detta gör att vi sällan behöver vara oroliga att den första placeringen blir den sista för sensorn 😀

hållare monterad utomhus
Xiaomi aqara hållare monterad utomhus

En annan del att ha i åtanke när vi jobbarmed integrationer är fördröjningar mellan händelse till utförd automation.

Namnsättning av sensorer

Vi kommer dessutom påbörja en namnstandard av alla sensorer och sedan använda oss av alias, där det är möjligt dvs. Detta för att se samma id i alla system och sedan med presentation välja mer förklarande namn. Vi kommer även återkomma och uppdatera den här punkten när vi sätter igång med nästa inlägg.

Central styrning för Automationer

Att vi väljer att ha en central styrning av automationer är för att undvika att händelser i olika system hemma tar ut vara eller skapar oönskade effekter. Därav kommer vi så långt det går endast tillåta automationer från en plats. Vi kommer dessutom arbeta mycket med att hålla nere den maximalt tillåtna fördröjningen mellan händelse och åtgärd.

Node-Red kommer vi använda för att bygga automationer primärt, nyligen släppte Home Assitant Blueprints (extern länk) men vi väljer att avvakta där. För att sedan koppla samman alla system effektivt som möjligt så använder vi oss av Mosquitto MQTT, vi kommer skriva mer om den i kommande inlägg med om det finns plats.

Att vi väljer Node-Red beror till stor del på att vi under LÅNG tid byggt en mängd flöden till Node-Red och redan idag använder oss av MQTT för att integrera mellan olika lösningar. Därav så kapar vi bort en massa tid som vi annars skulle behöva lägga på att skapa logiken igen. Det kan vara så att vi sakta börjar övergå mot Blueprints om vi anser att den installation vi har av Home Assitsant är tillräckligt stabil.

Vi kommer primärt försöka använda oss av Node-Red för att hantera automationer, men vi kommer även placera några i HASS.

Presentation och dashboard

Som presentation hemma använder vi Grafana och Home Assitant. Vi kommer troligen länka in Iframes från Grafana i Home Assitant, detta för att få allt att hamna på samma ställe. Detta gör att vi kan använda oss av Home Assitant appen på surfplattor och på ett enkelt sätt göra en panel som även små barn kan förstå med bilder.

I dagsläget har vi byggt en panel med ”picture-glance” i home assistant och använt oss av bilder från olika delar av huset. Därav vill vi inte presentera den bilden i skrivande stund ( kommer en alternativ vy senare ). Men vi kan lova att den inte kommer få se ut som den vi skapade när vi skrev guiden för Home Assitant.

Home Assistant med trådfri, philips hue, vera secure
Home Assistant efter 10 minuter

Grafana och InfluxDB

Som du ser har vi inte i skisserna presenterat varken grafana eller InfluxDB. Orsaken till detta är att vi anser att det inte tillhör kärnfunktionerna i vårt hem, utan vi ser det som mer funktionalitet.

Grafana och InfluxDB är något som vi skrivit om tidigare på bloggen. Vi har dessutom nyttjat det i flera av våra projekt för att enkelt presentera data. Vi skulle dessutom kunna nyttja dashboarden i node-Red. Men här har vi inte fullt ut beslutat designen och vilka objekt som hamnar vart. har du några tips på hur vi borde göra? dela gärna med dig i så fall, sett en mängd riktigt snygga lösningar.

Vad händer nu då?!?

Har du läst och kommit hit då blir vi glad. Vi skulle bli ännu gladare om du kan tänka dig dela med dig av dina reflektioner, idéer som detta inlägg kanske har skapat. Skriv gärna en kommentar på vad som var bra och vad du tror kommer fungera mindre bra. Vi vill som sagt inte göra om vårt hem igen på LÄNGE. För nu när allt finns samlat till en plats så händer det MYCKET konstigheter i både Home Assistant och Homey, så dessa kommer få en ominstallation när vi kör igång med nästa guide.

När vi samlade in alla sensorer blev det kaos i automationerna
Kan inte mer än säga att varje gång jag går in i rummet där detta ligger så händer det saker i HELA huset…

Hjälpa Automatiserar.se?

Är du intresserad av att se vad som händer mellan våra inlägg så kan du följa oss på vårt Instagram (länk till vårt Instagram konto), där försöker vi dela vad som händer och är på gång. Är du intresserad av att diskutera eller få tips från andra så kan du gå med i vår Facebook grupp (länk till Facebook gruppen) som riktar sig till alla som tycker det är roligt med smarta hem och automation. Följ och gilla gärna vår sida på Facebook med (länk till automatiserar på Facebook).

Tycker du att du har nytta av denna blogg och alla inlägg som du läser helt utan reklam i mer än 7 år? Du kanske vill bjuda på en kopp kaffe medans vi skriver nästa inlägg? Vi tar gärna en Swish kopp kaffe0705470065 i så fall 🙂

Om du gillar sidan, ge gärna en swish för att visa din uppskattning.
Om du gillar sidan, ge gärna en swish för att visa din uppskattning.

Vi försöker tipsa hur du själv kommer igång och automatiserar. Vi kör sidan helt på fritiden och är helt oberoende och gör detta för att det är roligt, vill du hjälpa Automatisear.se, dela, gilla och följer sidan så får vi motivation att göra ännu mer 🙂

// Markus

2 reaktioner på ”Smarta Hem 7.0 – Design”

  1. Ser fram emot fortsättningen!
    Har ni undersökt den nya versionen (3)av OpenHab?
    Jag labbar just nu med både Hassio & OpenHab, och för en icke linuxanvändare eller programmerare så uppskattas OH dokumentation väldigt mycket jmf mot HAs vilda västern community där ett inlägg som endast är någon månad gammalt kan vara helt inaktuellt.
    HA verkar o andra sidan utvecklas snabbt och mycket tillägg och funktioner finns såklart, där OH verkar ha en avsevärt långsammare takt med mer fokus på stabilitet.

Lämna en kommentar

Din e-postadress kommer inte publiceras. Obligatoriska fält är märkta *