{"id":55356,"date":"2020-01-18T00:00:00","date_gmt":"2020-01-17T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/lytko-obedinyaet"},"modified":"2020-02-18T14:03:28","modified_gmt":"2020-02-18T11:03:28","slug":"lytko-obedinyaet","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sv\/blog\/news\/lytko-obedinyaet","title":{"rendered":"Lytko f\u00f6renar","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

F\u00f6r en tid sedan presenterade vi f\u00f6r er den smarta termostaten<\/a><\/noindex>. Denna artikel var ursprungligen avsedd som en demonstration av dess firmware och styrsystem. Men f\u00f6r att f\u00f6rklara logiken bakom termostatens arbete och vad vi har implementerat, \u00e4r det n\u00f6dv\u00e4ndigt att skissera hela konceptet som helhet.<\/p>\n

\"Lytko
\n<\/a><\/noindex><\/p>\n

Om automation<\/h3>\n

\nI stort kan all automation delas in i tre kategorier:
\nKategori 1<\/u> \u2014 separata \u201csmarta\u201d enheter. Du k\u00f6per lampor, vattenkokare etc. fr\u00e5n olika tillverkare. F\u00f6rdelar: varje enhet ut\u00f6kar m\u00f6jligheterna och \u00f6kar komforten. Nackdelar: f\u00f6r varje ny tillverkare beh\u00f6vs en egen app. Protokollen f\u00f6r enheter fr\u00e5n olika tillverkare \u00e4r ofta inte kompatibla med varandra.<\/p>\n

Kategori 2<\/u> \u2014 installation av en enkorts-PC eller x86-kompatibel. Detta tar bort begr\u00e4nsningarna f\u00f6r ber\u00e4kningskraft, och p\u00e5 denna maskin installeras MajorDoMo eller n\u00e5gon annan serverdistribution f\u00f6r att hantera det smarta hemmet. D\u00e4rigenom kopplas enheter fr\u00e5n de flesta tillverkare samman i ett enhetligt informationsutrymme. D.v.s. en egen server f\u00f6r det smarta hemmet skapas. F\u00f6rdelar: kompatibilitet under en gemensam central, vilket ger ut\u00f6kade m\u00f6jligheter f\u00f6r styrning. Nackdelar: vid serverfel \u00e5terg\u00e5r hela systemet till fas 1, d.v.s. blir splittrat eller obrukbart.<\/p>\n

Kategori 3<\/u> \u2014 den mest hardcore varianten. Vid renovering l\u00e4ggs alla kommunikationer och alla system dubbelas. F\u00f6rdelar: allt \u00e4r perfekt och d\u00e5 blir huset verkligen smart. Nackdelar: extremt h\u00f6g kostnad j\u00e4mf\u00f6rt med kategorierna 1 och 2, behovet av att planera allt i f\u00f6rv\u00e4g och ta h\u00e4nsyn till varje detalj.<\/p>\n

De flesta anv\u00e4ndare v\u00e4ljer alternativ ett, f\u00f6r att sedan gradvis \u00f6verg\u00e5 till alternativ tv\u00e5. Och s\u00e5 sm\u00e5ningom n\u00e5r de mest ih\u00e4rdiga alternativ tre. <\/p>\n

Men det finns ett alternativ som kan kallas ett distribuerat system: varje enskild enhet kommer att vara b\u00e5de server och klient. I grunden \u00e4r det ett f\u00f6rs\u00f6k att kombinera alternativ 1 och alternativ 2. Att ta alla deras f\u00f6rdelar och utesluta nackdelarna, f\u00e5nga den gyllene medelv\u00e4gen. <\/p>\n

Det finns kanske de som s\u00e4ger att en s\u00e5dan l\u00f6sning redan \u00e4r utvecklad. Men s\u00e5dana l\u00f6sningar \u00e4r sn\u00e4va och riktar sig mot personer med programmeringskunskaper. V\u00e5rt m\u00e5l \u00e4r att s\u00e4nka intr\u00e4desbarri\u00e4ren f\u00f6r s\u00e5dana distribuerade system, b\u00e5de n\u00e4r det g\u00e4ller slutprodukter och integrering av befintliga enheter i v\u00e5rt system. N\u00e4r det g\u00e4ller termostaten, tar anv\u00e4ndaren helt enkelt bort sin gamla termostat, installerar den smarta och kopplar de sensorer han redan har till den. Utan n\u00e5gra ytterligare \u00e5tg\u00e4rder.<\/p>\n

L\u00e5t oss \u00f6verv\u00e4ga integrationen i v\u00e5rt system med ett exempel. <\/p>\n

L\u00e5t oss anta att vi har 8 Sonoff-moduler i n\u00e4tverket. Vissa anv\u00e4ndare kommer att n\u00f6ja sig med att styra via Sonoff-molnet (kategori 1). Andra kommer att anv\u00e4nda tredje parts firmware och smidigt g\u00e5 \u00f6ver till kategori 2. De flesta tredje parts firmware fungerar enligt samma princip: \u00f6verf\u00f6ring av data till en MQTT-server. OpenHub, Majordomo eller vilken annan tj\u00e4nst som helst tj\u00e4nar ett enda syfte \u2013 att f\u00f6rena spridda enheter i ett enhetligt informationsutrymme, antingen p\u00e5 Internet eller i det lokala n\u00e4tverket. D\u00e4rf\u00f6r \u00e4r n\u00e4rvaron av en server obligatorisk. H\u00e4r uppst\u00e5r huvudproblemet \u2013 n\u00e4r servern g\u00e5r ner slutar hela systemet att fungera autonomt. F\u00f6r att f\u00f6rhindra detta kompliceras systemen, och manuella styrmetoder l\u00e4ggs till som duplicerar automatik vid servermisslyckande. <\/p>\n

Vi har dock valt en annan v\u00e4g d\u00e4r varje enhet \u00e4r sj\u00e4lvf\u00f6rs\u00f6rjande. P\u00e5 s\u00e5 s\u00e4tt spelar servern ingen avg\u00f6rande roll, utan ut\u00f6kar bara funktionaliteten.<\/p>\n

L\u00e5t oss \u00e5terv\u00e4nda till v\u00e5rt tankeexperiment. L\u00e5t oss ta samma 8 Sonoff-moduler och installera Lytko-firmware i dem. I alla Lytko-firmwares finns funktionen SSDP<\/a><\/noindex>. SSDP \u2013 ett n\u00e4tverksprotokoll baserat p\u00e5 en upps\u00e4ttning Internetprotokoll som anv\u00e4nds f\u00f6r att annonserar och uppt\u00e4cka n\u00e4tverkstj\u00e4nster. Svaret p\u00e5 en f\u00f6rfr\u00e5gan kan vara b\u00e5de standard och ut\u00f6kat. Vi har lagt till att skapa en lista \u00f6ver enheter i n\u00e4tverket, f\u00f6rutom standardfunktionerna. P\u00e5 s\u00e5 s\u00e4tt hittar enheterna varandra sj\u00e4lva, och var och en av dem kommer att ha en s\u00e5dan lista. Exempel p\u00e5 en SSDP-lista:<\/p>\n

"ssdpList": \n\t{\n\t\t"id": 94967291,  \n\t\t"ip": "192.168.x.x",\n                "type": "termostat"\n\t}, \n\t{\n\t\t"id": 94967282,\n\t\t"ip": "192.168.x.x",\n                "type": "termostat"\n\t}<\/code><\/pre>\n
\nSom det framg\u00e5r av exemplet inkluderar listan enheter, IP-adresser i n\u00e4tverket, typ av modul (i v\u00e5rt fall en termostat baserad p\u00e5 Sonoff). Denna lista uppdateras varannan minut (den h\u00e4r tidsperioden \u00e4r tillr\u00e4cklig f\u00f6r att reagera p\u00e5 dynamiska f\u00f6r\u00e4ndringar i antal enheter i n\u00e4tverket). P\u00e5 s\u00e5 s\u00e4tt sp\u00e5rar vi till\u00e4gg, \u00e4ndringar och bortkoppling av enheter utan n\u00e5got krav p\u00e5 anv\u00e4ndarens \u00e5tg\u00e4rd. Denna lista skickas till webbl\u00e4saren eller mobilappen, och skriptet genererar automatiskt en sida med angivet antal moduler. Varje modul motsvarar en enhet\/sensor\/styrenhet. Visuellt ser listan ut s\u00e5 h\u00e4r:<\/p>\n
\"Lytko
\n
\nMen vad h\u00e4nder om andra radiosensorer \u00e4r anslutna till esp8266\/esp32 via cc2530 (ZigBee) eller nrf24 (MySensors)? <\/p>\n
Om projekt<\/h3>\n
\nDet finns olika distribuerade system p\u00e5 marknaden. V\u00e5rt system m\u00f6jligg\u00f6r integration med de mest popul\u00e4ra. <\/p>\n
Nedan f\u00f6ljer projekt som p\u00e5 olika s\u00e4tt f\u00f6rs\u00f6ker f\u00f6r\u00e4ndra situationen med inkompatibilitet mellan olika tillverkare. Det \u00e4r till exempel SLS Gateway<\/a><\/noindex>, MySensors <\/a><\/noindex> eller ZESP32<\/a><\/noindex>. ZigBee2MQTT <\/a><\/noindex> som \u00e4r kopplad till MQTT-servern, s\u00e5 den passar inte som exempel. <\/p>\n
En av de m\u00f6jliga implementationerna av MySensors \u00e4r en gateway baserad p\u00e5 ESP8266. \u00d6vriga exempel \u00e4r baserade p\u00e5 ESP32. I dem kan vi implementera v\u00e5r arbetsprincip f\u00f6r att uppt\u00e4cka och skapa en enhetslista. <\/p>\n
L\u00e5t oss g\u00f6ra ytterligare ett tankexperiment. Vi har ZESP32 eller SLS Gateway, eller MySensors. Hur kan vi sammanf\u00f6ra dem i ett gemensamt informationsutrymme? Till de standardfunktionerna f\u00f6r dessa gateways l\u00e4gger vi till SSDP-protokollet. N\u00e4r vi kontaktar denna kontroller via SSDP, l\u00e4gger den till en lista \u00f6ver enheter som \u00e4r anslutna till den i sitt standard-svar. Baserat p\u00e5 denna information kommer webbl\u00e4saren att generera en sida. I allm\u00e4nhet kommer det att se ut s\u00e5 h\u00e4r:<\/p>\n
\"Lytko
\nWebbgr\u00e4nssnitt<\/i><\/p>\n
\"Lytko
\nPWA-applikation<\/i><\/p>\n
"ssdpList": \n{\n   "id": 94967291, // unik identifier f\u00f6r enheten\n   "ip": "192.168.x.x", // ip-adress i n\u00e4tverket\n   "type": "termostat" // enhetstyp\n},\n{\n   "id": 94967292,\n   "ip": "192.168.x.x",\n   "type": "termostat"\n},\n{\n   "id": 94967293,\n   "ip": "192.168.x.x",\n   "type": "termostat"\n},\n{  \n   "id": 13587532, \n   "type": "switch"  \n},\n{  \n   "id": 98412557, \n   "type": "r\u00f6kdetektor"\n},\n{  \n   "id": 57995113, \n   "type": "kontakt_sensor"\n},\n{  \n   "id": 74123668,\n   "type": "temperatur_fuktighet_tryck_sensor"\n},\n{\n    "id": 74621883, \n    "type": "temperatur_fuktighet_sensor"\n}\n<\/code><\/pre>\n
\nExemplet visar att enheter l\u00e4ggs till oberoende av varandra. Tre termostater med egna IP-adresser och fem olika sensorer med unika ID \u00e4r anslutna. Om sensorn \u00e4r ansluten till Wi-Fi-n\u00e4tverket kommer den att ha sin egen IP, om den \u00e4r ansluten till en gateway kommer enhetens IP-adress att vara gatewayens IP-adress.<\/p>\n
F\u00f6r kommunikation med enheterna anv\u00e4nder vi WebSocket. Detta minimerar resursf\u00f6rbrukningen j\u00e4mf\u00f6rt med GET-f\u00f6rfr\u00e5gningar och g\u00f6r att vi kan f\u00e5 information dynamiskt vid anslutning eller f\u00f6r\u00e4ndring. <\/p>\n
Data h\u00e4mtas direkt fr\u00e5n den enhet som blocket tillh\u00f6r, utan att g\u00e5 via servern. S\u00e5ledes forts\u00e4tter systemet att fungera vid fel p\u00e5 n\u00e5gon av enheterna. I webgr\u00e4nssnittet kommer endast den borttagna enheten inte att visas i listan. Men signalen om bortfallet kommer, om n\u00f6dv\u00e4ndigt, att skickas i form av en avisering i anv\u00e4ndarens app. <\/p>\n
Det f\u00f6rsta f\u00f6rs\u00f6ket att implementera ett s\u00e5dant tillv\u00e4gag\u00e5ngss\u00e4tt var en PWA-app. Detta m\u00f6jligg\u00f6r lagring av datablock p\u00e5 anv\u00e4ndarens enhet och beg\u00e4r endast n\u00f6dv\u00e4ndiga data. Men p\u00e5 grund av strukturens egenskaper \u00e4r denna variant ofullst\u00e4ndig. L\u00f6sningen \u00e4r en native-app f\u00f6r Android och iOS, vilket f\u00f6r n\u00e4rvarande \u00e4r under aktiv utveckling. Som standard kommer appen att fungera endast i det interna n\u00e4tverket. Om det beh\u00f6vs kan allt \u00f6verg\u00e5 till extern kontroll. N\u00e4r anv\u00e4ndaren l\u00e4mnar det lokala n\u00e4tverket v\u00e4xlar appen automatiskt till molnet. <\/p>\n
Extern kontroll\u2014 en fullst\u00e4ndig duplikat av sidan. N\u00e4r sidan aktiveras kan anv\u00e4ndaren logga in p\u00e5 servern och styra enheterna via sitt personliga konto. S\u00e5ledes ut\u00f6kar servern funktionaliteten och m\u00f6jligg\u00f6r styrning av enheterna utanf\u00f6r hemmet utan att vara bunden till port forwarding eller dedikerad IP.<\/p>\n
P\u00e5 s\u00e5 s\u00e4tt saknar den ovan beskrivna varianten serveranslutningens nackdelar och har flera f\u00f6rdelar i form av flexibilitet i anslutning av nya enheter.<\/p>\n
Om termostaten<\/h3>\n
\nL\u00e5t oss \u00f6verv\u00e4ga styrsystemet med v\u00e5rt termostat som exempel.<\/p>\n
F\u00f6ljande funktioner finns:<\/p>\n
    \n
  1. Justering av temperaturen f\u00f6r varje termostat (visas som en separat block);<\/li>\n
  2. Inst\u00e4llning av termostatens arbetsschema (morgon, dag, kv\u00e4ll, natt);<\/li>\n
  3. Val av Wi-Fi-n\u00e4tverk och anslutning av enheten till det;<\/li>\n
  4. Uppdatering av enheten \"over the air\";<\/li>\n
  5. Inst\u00e4llning av MQTT;<\/li>\n
  6. Inst\u00e4llning av n\u00e4tverket som enheten \u00e4r ansluten till.<\/li>\n<\/ol>\n
    \n\"Lytko
    \n
    \nF\u00f6rutom att styra via webgr\u00e4nssnittet, finns \u00e4ven klassisk kontroll med knapptryckningar p\u00e5 sk\u00e4rmen. Ombord finns en Nextion NX3224T024 2,4-tums sk\u00e4rm. Vi valde den p\u00e5 grund av enkelheten att arbeta med enheten. Men en egen monitor baserad p\u00e5 STM32 \u00e4r under utveckling. Dess funktionalitet \u00e4r lika bra som Nextions, men den kommer att kosta mindre, vilket positivt p\u00e5verkar slutpriset f\u00f6r enheten.<\/p>\n
    \"Lytko
    \n
    \nPrecis som alla respektabla termostat-sk\u00e4rmar kan v\u00e5r Nextion:<\/p>\n