Du må være registrert og logget inn for å kunne legge ut innlegg på freak.no
X
LOGG INN
... eller du kan registrere deg nå
Dette nettstedet er avhengig av annonseinntekter for å holde driften og videre utvikling igang. Vi liker ikke reklame heller, men alternativene er ikke mange. Vær snill å vurder å slå av annonseblokkering, eller å abonnere på en reklamefri utgave av nettstedet.
  4 3918
Jeg leker litt med tanken, eller rettere sagt jeg leker med 3D modeller og kretskorttegninger av RGB-LED «dekorasjonslys» som jeg har lyst til å montere rundt huset til høsten. Lysene vil bli styrt av en ATMega kontroller med ethernet interface, jeg ser for meg å tildele egen IP adresse til hvert lys. Men nå er det ikke lysene som er selve problemet, men det er protokollen som skal benyttes til å styre disse, for hadde det bare handlet om et enkelt tilfelle så kunne man brukt hvilken som helst protokoll, eller designet sin egen.

Men jeg ser jo for meg å utvide etterhvert som jeg for tid til å lage andre kule gadgets til hjemmet, og da bør man jo gjøre en grundig research før man beslutter hvilken protokoll man skal benytte seg av. Og det eksisterer jo et hav der ute av protokoller som er laget for automatisjon, finnes det noen standarder innen feltet? Eller er det slik at det er opp til hver enkelt produsent og utvikle sin egen?

Eneste kravet mitt er at protokollen må fungere på IP protokollen over (U/F/S/SF)TP kabel, og eventuelt over WiFi hvis det blir aktuelt i framtiden. Og hvis det ikke finnes standarder på dette, hva er den mest lovenede/mest brukte protokollen i så tilfelle?

Jeg vet at det er flere medlemmer her som har stor interesse i hjemme automatisering, så jeg setter pris på et hvert råd og tips fra dere.
Det meste av eksisterende teknologi benytter kombinasjoner av teknlogier, f.eks. WiFi og ZigBee (Bygd på IEEE 802.15.4). Avhengig av antall enheter og topologien deres, så er en mesh-basert teknologi det som er mest smertefritt når det kommer til å få full dekning. Philips Hue benytter blant annet dette, hvor de har en bro-enhet som oversetter mellom IP og ZigBee. I tillegg har du Z-Wave, som også oversetter mellom IP og en proprietær protokoll.

Du nevner ikke noen annen mikrokontroller enn ATMega, så det begrenser veldig hva du får utført. Du kan kikke på UDP-baserte protokoller som "xPL" eller "xAP". Disse bygger på at det er en "HUB" som kjenner til alle enheter, og som videresender beskjeder til alle enhetene på rekke og rad. Hver enhet sender en heartbeat, og støtter det å melde seg ut og inn av HUB-enheten. Meldingssystemet er rimelig rudimentært, men kan enkelt utvides.

Hvis du vil legge til en mikrokontroller med RF, så øker mulighetene for mer dynamiske løsninger. Det skorter virkelig ikke på alternative teknologier, men de har både fordeler og ulemper. Spørsmålene du bør stille deg er:
- Hvilken topologi er mest gunstig for deg? Har du kablet nett til absolutt alle enheter? Er det en stjerneformasjon, en seriekobling, eller en kombinasjon av disse? Endres dette over tid?
- Hvor responsiv må protokollen være? Skal du gjøre komplekse styringer i sanntid over IP, eller skal hver kontroller motta enkle kommandoer som "av", "på" og "sekvens N"? Likeledes, hvor robust skal protokollen være mot feil?
- Hvor høyt strømforbruk er akseptabelt? Skal kontrolleren ha nettspenning, eller går dette på batteri som må byttes årlig/månedlig?
- Hva er kravet ditt til brukervennlighet? Skal dette settes opp én gang og permanent, eller vil du kunne legge til og fjerne enheter på en enkel måte?

Da kan du undersøke protokoller som 6LoWPAN, OpenMesh-implementasjoner, Bluetooth Low Energy (som ryktes å komme med en offisiell Mesh-standard snart) eller Thread. De førstnevnte støtter IPV6-adressering av enheter på lokalnettet, så bruker du en bro fra f.eks. Bluetooth eller WiFi til IP. Dette gjør det mulig å bytte bro-teknologien i fremtiden, uten å måtte endre noe på enhetene. F.eks. vil 6LoWPAN gi deg muligheten til å snakke med enhetene som om de var på samme nettverk som deg, hvor hver dings har sin egen IP, men den faktiske kommunikasjonen går over en annen protokoll.
Sist endret av Dyret; 10. juli 2017 kl. 02:08.
På makerspacet der jeg "henger", så valgte vi MQTT som protokoll, fordi det hele blir mest fleksibelt slik. Da trenger man ikke å tenke ut på forhånd hva en sensor eller kontroll skal brukes til; man kobler den til, og så kan man koble i hop sensorer og kontroller via MQTT etterhvert som man finner ut hvordan man ønsker og koble sammen ting.
Se https://bitraf.no/wiki/IoT for noe info (ikke sikkert at alle lenkene funker utenfor Bitraf sitt nett).
Overskuddsmateriell
Kjører mer og mer over på MQTT hjemme nå jeg. Meget fornøyd med fleksibiliteten og skalerbarheten. Er også en protokoll som allerede finnes mye bra støtte til på ESP8266 chip'er som jeg er blitt forelska i fremfor Atmel sine. Hovedsaklig fordi de har innebygget wifi og kan bruke veldig lite strøm i deep sleep modus.

Til å knytte sammen automasjonen bruker jeg NodeRed. Får ett fint grafisk interface for programmering og ett kurant UI. MQTT broker og NodeRed kan fint kjøres på en rPi.
NOOOOOOOOOOOOOOOOOO-
robhol's Avatar
Bruker en kombinasjon av Domoticz, MQTT og egenmekket til å styre ting hjemme. Domoticz støtter de individuelle enhetene og kommuniserer med dem via en 433MHz transceiver, og publiserer også events til alt mulig på MQTT. Så har jeg en egen applikasjon på samme MQTT-broker, basert på "microservice"-aktig tankegang. Én service for å oversette til og fra Domoticz-events (som er en tanke hårete), én service for å koble sammen forskjellige brytere med lamper, dimmere osv., og én service som fungerer som termostat.

Hele greia fungerer tålelig bra.