{"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\/da\/blog\/news\/lytko-obedinyaet","title":{"rendered":"Lytko forener","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

For nogle tid siden pr\u00e6senterede vi for dig den smarte termostat<\/a><\/noindex>. Denne artikel var oprindeligt t\u00e6nkt som en demonstration af dens firmware og styringssystem. Men for at forklare logikken bag termostatens funktion og hvad vi har implementeret, er det n\u00f8dvendigt at skitsere hele konceptet som helhed.<\/p>\n

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

Om automatisering<\/h3>\n

\nGenerelt kan al automatisering opdeles i tre kategorier:
\nKategori 1<\/u> \u2014 enkeltst\u00e5ende \"smarte\" enheder. Du k\u00f8ber p\u00e6rer, kedler osv. fra forskellige producenter. Fordele: hver enhed udvider funktionerne og \u00f8ger komforten. Ulemper: for hver ny producent kr\u00e6ves der sin app. Protokoller for enheder fra forskellige producenter er ofte ikke kompatible med hinanden.<\/p>\n

Kategori 2<\/u> \u2014 installation af en enkelt board PC eller x86 kompatibel enhed. Dette fjerner begr\u00e6nsningerne for beregningskraft, og p\u00e5 denne maskine installeres MajorDoMo eller en anden serverdistribution til styring af det smarte hjem. P\u00e5 denne m\u00e5de forbindes enheder fra de fleste producenter i et samlet informationsrum. Dvs. der oprettes en egen Server for det smarte hjem. Fordele: kompatibilitet under et centralt system, hvilket giver udvidede muligheder for styring. Ulemper: ved serverfejl falder hele systemet tilbage til fase 1, dvs. det bliver fragmenteret eller bliver ubrugeligt.<\/p>\n

Kategori 3<\/u> \u2014 den mest hardcore mulighed. I renoveringsfasen l\u00e6gges alle kommunikationer, og alle systemer duplikeres. Fordele: alt bliver gjort til perfektion, og s\u00e5 bliver hjemmet virkelig smart. Ulemper: ekstremt h\u00f8j pris sammenlignet med kategorierne 1 og 2, behovet for at planl\u00e6gge alt p\u00e5 forh\u00e5nd og tage h\u00f8jde for hver lille detalje.<\/p>\n

De fleste brugere v\u00e6lger mulighed et og overgang til mulighed to. Og senere n\u00e5r de mest vedholdende op til mulighed tre. <\/p>\n

Men der findes en mulighed, som man kan kalde et distribueret system: hver enkelt enhed vil v\u00e6re b\u00e5de server og klient. I bund og grund er dette et fors\u00f8g p\u00e5 at kombinere mulighed 1 og mulighed 2. At tage alle deres fordele og udelukke ulemperne, finde den gyldne middelvej. <\/p>\n

Nogle vil m\u00e5ske sige, at en s\u00e5dan l\u00f8sning allerede findes. Men s\u00e5danne l\u00f8sninger er sn\u00e6vert fokuserede; for dem, der har programmeringskendskab. Vores m\u00e5l er at s\u00e6nke indgangen til s\u00e5danne distribuerede systemer b\u00e5de i form af slutbrugerenheder og ved at integrere eksisterende enheder i vores system. I tilf\u00e6lde af termostaten fjerner brugeren blot sin gamle termostat, installerer en smart enhed, og tilslutter sine eksisterende sensorer til den. Uden nogen yderligere handlinger.<\/p>\n

Lad os overveje integrationen i vores system ved hj\u00e6lp af et eksempel. <\/p>\n

Forestil dig, at vi har 8 Sonoff-moduler i vores netv\u00e6rk. Nogle brugere vil v\u00e6re tilfredse med at styre gennem Sonoff-cloud (kategori 1). Nogle vil begynde at bruge tredjepartsfirmware og gradvist skifte til kategori 2. De fleste tredjepartsfirmwares fungerer efter det samme princip: overf\u00f8rsel af data til en MQTT-server. OpenHub, Majordomo eller enhver anden server tjener et form\u00e5l \u2013 at samle disparate enheder i et samlet informationsrum, der er placeret enten p\u00e5 internettet eller i et lokalt netv\u00e6rk. Derfor er tilstedev\u00e6relsen af en Server n\u00f8dvendig. Her opst\u00e5r hovedproblemet \u2013 n\u00e5r Serveren svigter, stopper hele systemet med at fungere autonomt. For at forhindre dette bliver systemerne mere komplekse, og der tilf\u00f8jes manuelle kontrolmetoder, der duplicerer automatikken i tilf\u00e6lde af Serverfejl. <\/p>\n

Vi har dog valgt en anden vej, hvor hver enhed er selvforsynende. P\u00e5 denne m\u00e5de spiller Serveren ikke en afg\u00f8rende rolle, men udvider blot funktionaliteten.<\/p>\n

Lad os vende tilbage til tankeeksperimentet. Lad os igen tage de samme 8 Sonoff-moduler og installere Lytko-firmware i dem. I alle Lytko-firmwares er funktionen implementeret SSDP<\/a><\/noindex>. SSDP \u2013 en netv\u00e6rksprotokol, der er baseret p\u00e5 et s\u00e6t internetprotokoller, der bruges til at annoncere og opdage netv\u00e6rkstjenester. Svaret p\u00e5 foresp\u00f8rgslen kan v\u00e6re b\u00e5de standard og udvidet. Vi har lagt, at dette svar, ud over standardfunktioner, ogs\u00e5 indeholder en liste over enheder i netv\u00e6rket. P\u00e5 den m\u00e5de finder enhederne selv hinanden, og hver af dem vil have en s\u00e5dan liste. Eksempel p\u00e5 SSDP-liste:<\/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 fremg\u00e5r af eksemplet, inkluderer listen id'er for enheder, ip-adressen i netv\u00e6rket, enhedstypen (i vores tilf\u00e6lde en thermostat baseret p\u00e5 Sonoff). Denne liste opdateres hvert andet minut (denne tidsramme er tilstr\u00e6kkelig til at reagere p\u00e5 dynamiske \u00e6ndringer i antallet af enheder i netv\u00e6rket). P\u00e5 den m\u00e5de overv\u00e5ger vi tilf\u00f8jelsen, \u00e6ndringen og frakoblingen af enheder uden nogen handling fra brugerens side. Listen sendes til browseren eller mobilappen, og scriptet opretter automatisk en side med det angivne antal blokke. Hver blok svarer til en enhed\/sensor\/kontroller. Visuelt ser listen s\u00e5ledes ud:<\/p>\n
\"Lytko
\n
\nMen hvis andre radiosensorer er tilsluttet esp8266\/esp32 via cc2530 (ZigBee) eller nrf24 (MySensors)? <\/p>\n
Om projekterne<\/h3>\n
\nP\u00e5 markedet findes der forskellige distribuerede systemer. Vores system g\u00f8r det muligt at integrere med de mest popul\u00e6re. <\/p>\n
Nedenfor er projekter, der p\u00e5 en eller anden m\u00e5de fors\u00f8ger at \u00e6ndre situationen med inkompatibilitet mellem forskellige producenter. Det er for eksempel: SLS Gateway<\/a><\/noindex>, MySensors <\/a><\/noindex> eller ZESP32<\/a><\/noindex>. ZigBee2MQTT <\/a><\/noindex> er bundet til MQTT-serveren, s\u00e5 det passer ikke til eksemplet. <\/p>\n
En af m\u00e5derne at implementere MySensors p\u00e5 er en gateway baseret p\u00e5 ESP8266. De \u00f8vrige eksempler er p\u00e5 ESP32. Og i dem kan vi implementere vores arbejdsprincips metode til detektering og oprettelse af en liste over enheder. <\/p>\n
Lad os foretage endnu et tankeeksperiment. Vi har ZESP32, SLS Gateway eller MySensors. Hvordan kan vi samle dem i et samlet informationsrum? Til standardfunktionerne i disse gateways tilf\u00f8jer vi SSDP-protokolbiblioteket. N\u00e5r der anmodes om denne controller via SSDP, tilf\u00f8jer den en liste over de enheder, der er tilsluttet den, til det standardm\u00e6ssige svar. Baseret p\u00e5 disse oplysninger vil browseren oprette en side. Generelt vil det se s\u00e5dan ud:<\/p>\n
\"Lytko
\nWeb-interface<\/i><\/p>\n
\"Lytko
\nPWA-applikation<\/i><\/p>\n
\"ssdpList\": \n{\n   \"id\": 94967291, \/\/ unik identifikator for enheden\n   \"ip\": \"192.168.x.x\", \/\/ ip-adresse i netv\u00e6rket\n   \"type\": \"termostat\" \/\/ enhedstype\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\u00f8g\"\n},\n{  \n   \"id\": 57995113, \n   \"type\": \"kontakt_sensor\"\n},\n{  \n   \"id\": 74123668,\n   \"type\": \"temperatur_fugtighed_tryksensor\"\n},\n{\n    \"id\": 74621883, \n    \"type\": \"temperatur_fugtighed_sensor\"\n}\n<\/code><\/pre>\n
\nEksemplet viser, at enheder tilf\u00f8jes uafh\u00e6ngigt af hinanden. Der er tilsluttet 3 termostater med deres egne IP-adresser og 5 forskellige sensorer med unikke id'er. Hvis sensoren er tilsluttet et Wi-Fi-netv\u00e6rk, vil den have sin egen IP, og hvis den er tilsluttet en gateway, vil enhedens IP-adresse v\u00e6re gatewayens IP-adresse.<\/p>\n
Vi anvender WebSocket til kommunikation med enhederne. Dette minimerer ressourceomkostningerne i forhold til GET-anmodninger og muligg\u00f8r dynamisk modtagelse af information ved tilslutning eller \u00e6ndring. <\/p>\n
Dataene hentes direkte fra den enhed, som blokken tilh\u00f8rer, uden at g\u00e5 gennem serveren. Dermed forts\u00e6tter systemet med at fungere, selv hvis en enhed svigter. Den webbaserede gr\u00e6nseflade viser kun ikke det enhed, der er forsvundet fra listen. Men meddelelser om tab vil, hvis n\u00f8dvendigt, komme som en notifikation i brugerens applikation. <\/p>\n
Det f\u00f8rste fors\u00f8g p\u00e5 at implementere en s\u00e5dan tilgang var en PWA-applikation. Dette muligg\u00f8r opbevaring af databasen af blokke p\u00e5 brugerens enhed og kun anmode om n\u00f8dvendige data. Men p\u00e5 grund af strukturens s\u00e6regenheder er denne mulighed utilstr\u00e6kkelig. Den eneste l\u00f8sning er native apps til Android og IOS, som i \u00f8jeblikket er under aktiv udvikling. Som standard vil appen kun fungere i det interne netv\u00e6rk. Hvis n\u00f8dvendigt kan alt skiftes til ekstern kontrol. N\u00e5r brugeren forlader det lokale netv\u00e6rk, skifter appen automatisk til skyen. <\/p>\n
Den eksterne kontrol er en fuld duplication af siden. N\u00e5r siden aktiveres, kan brugeren logge ind p\u00e5 serveren og styre enhederne via sin personlige konto. Derved udvider serveren funktionaliteten, hvilket g\u00f8r det muligt at styre enhederne uden for hjemmet og ikke v\u00e6re bundet til port forwarding eller dedikeret IP.<\/p>\n
Dermed er den ovenfor beskrevne mulighed fri for serverens ulemper og har ogs\u00e5 en r\u00e6kke fordele i form af fleksibilitet i tilslutning af nye enheder.<\/p>\n
Om termostaten<\/h3>\n
\nLad os se p\u00e5 et eksempel p\u00e5 vores termostat.<\/p>\n
Beregnet til:<\/p>\n
    \n
  1. Regulering af temperaturen for hver termostat (vises som en separat blok);<\/li>\n
  2. Indstilling af tidsplan for termostatens drift (morgen, dag, aften, nat);<\/li>\n
  3. Valg af Wi-Fi-netv\u00e6rk og tilslutning af enheden dertil;<\/li>\n
  4. Opdatering af enheden \"over luften\";<\/li>\n
  5. Indstilling af MQTT;<\/li>\n
  6. Ops\u00e6tning af netv\u00e6rket, som enheden er tilsluttet.<\/li>\n<\/ol>\n
    \n\"Lytko
    \n
    \nUdover at styre via webgr\u00e6nsefladen er der ogs\u00e5 klassisk betjening \u2014 ved tryk p\u00e5 sk\u00e6rmen. Der er monteret en Nextion NX3224T024 2,4 tommer sk\u00e6rm. Valget faldt p\u00e5 den p\u00e5 grund af den enkle betjening af enheden. Derudover er der en egen monitor under udvikling baseret p\u00e5 STM32. Dens funktionalitet er ikke ringere end Nextion, men den vil v\u00e6re billigere, hvilket vil have en positiv indvirkning p\u00e5 den endelige pris for enheden.<\/p>\n
    \"Lytko
    \n
    \nSom enhver respektabel termostat-sk\u00e6rm kan vores Nextion:<\/p>\n