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

For some time now, we have introduced you to a smart thermostat<\/a><\/noindex>. The current article was initially intended as a demonstration of its firmware and control system. However, to explain the logic of the thermostat's operation and what we have implemented, it is necessary to outline the entire concept as a whole.<\/p>\n

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

About automation<\/h3>\n

\nConditionally, all automation can be divided into three categories:
\nCategory 1<\/u> \u2014 individual \u201csmart\u201d devices. You purchase bulbs, kettles, etc., from different manufacturers. Pros: each device expands capabilities and increases comfort. Cons: each new manufacturer requires its own application. The protocols of devices from different manufacturers are often not compatible with each other.<\/p>\n

Category 2<\/u> \u2014 installing a single-board PC or x86 compatible one. This removes limitations on computing power, and a MajorDoMo or any other server distribution for smart home management is installed on this machine. Thus, devices from most manufacturers connect within a unified information space. That is, a Smart Home Server is created. Pros: compatibility under a single center, which provides expanded control capabilities. Cons: in case of server failure, the entire system reverts to stage 1, i.e., it becomes fragmented or turns useless.<\/p>\n

Category 3<\/u> \u2014 the most hardcore option. During the renovation stage, all communications are laid out and all systems are duplicated. Pros: everything is perfected, and then the home truly becomes smart. Cons: extremely high cost compared to categories 1 and 2, the necessity to plan everything ahead and take every little detail into account.<\/p>\n

Most users choose option one and then gradually transition to option two. Eventually, the most persistent reach option three. <\/p>\n

But there is an option that can be called a distributed system: each individual device will be both a server and a client. Essentially, this is an attempt to combine option 1 and option 2, to take all their advantages and eliminate the drawbacks, to find a golden mean. <\/p>\n

Kanskje noen vil si at en slik l\u00f8sning allerede er utviklet. Men slike l\u00f8sninger er spesialiserte; for folk med programmeringskunnskap. V\u00e5rt m\u00e5l er \u00e5 senke inngangsbarrieren for slike distribuerte systemer, b\u00e5de n\u00e5r det gjelder sluttbrukerenheter og n\u00e5r det gjelder integrasjonen av eksisterende enheter i systemet v\u00e5rt. N\u00e5r det gjelder termostaten, fjerner brukeren ganske enkelt sin gamle termostat, installerer den smarte, og kobler de eksisterende sensorene til den. Uten ytterligere tiltak.<\/p>\n

La oss se p\u00e5 integrasjon i systemet v\u00e5rt med et eksempel. <\/p>\n

La oss anta at vi har 8 Sonoff-moduler i nettverket. Noen brukere vil v\u00e6re forn\u00f8yd med styring via Sonoff-skyen (kategori 1). Andre vil bruke tredjeparts firmware og gradvis g\u00e5 over til kategori 2. Hoveddelen av tredjepartsfirmware fungerer etter samme prinsipp: dataoverf\u00f8ring til en MQTT-server. OpenHub, Majordomo eller enhver annen tjener ett m\u00e5l \u2013 \u00e5 samle forskjellige enheter i et enhetlig informasjonsrom, enten p\u00e5 Internett eller i lokalt nettverk. F\u00f8lgelig er tilstedev\u00e6relsen av en server obligatorisk. Her oppst\u00e5r det st\u00f8rste problemet \u2013 ved serverfeil slutter hele systemet \u00e5 fungere autonomt. For \u00e5 forhindre dette, kompliseres systemene, og manuelle kontrollmetoder som dupliserer automatikken legges til i tilfelle serverfeil. <\/p>\n

Vi valgte imidlertid en annen tiln\u00e6rming, der hver enhet er selvforsynt. Dermed spiller serveren ikke en avgj\u00f8rende rolle, men utvider bare funksjonaliteten.<\/p>\n

La oss g\u00e5 tilbake til tankeksperimentet. La oss igjen ta de samme 8 Sonoff-modulene og installere Lytko-firmware i dem. Alle Lytko-firmwarene har implementert funksjonen SSDP<\/a><\/noindex>. SSDP er en nettverksprotokoll basert p\u00e5 et sett med internettprotokoller, som brukes til \u00e5 kunngj\u00f8re og oppdage nettverkstjenester. Svaret p\u00e5 foresp\u00f8rselen kan v\u00e6re b\u00e5de standard og utvidet. Vi har inkludert i dette svaret, i tillegg til standardfunksjoner, opprettelsen av en liste over enheter i nettverket. Dermed finner enhetene hverandre selv, og hver av dem vil ha en slik 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 av eksemplet, inkluderer listen id-ene til enhetene, ip-adressen i nettverket, blokktypen (i v\u00e5rt tilfelle \u2013 en termostat basert p\u00e5 Sonoff). Denne listen oppdateres hver andre minutt (denne tidsrammen er tilstrekkelig for \u00e5 reagere p\u00e5 dynamiske endringer i antallet enheter i nettverket). Dermed kan vi spore tillegg, endringer og frakoblinger av enheter uten noen handling fra brukerens side. Denne listen sendes til nettleseren eller mobilappen, og skriptet lager selv siden med det angitte antallet blokkene. Hver blokk tilsvarer \u00e9n enhet\/sensor\/aktuator. Visuelt ser listen slik ut:<\/p>\n
\"Lytko
\n
\nMen hva hvis andre radiosensorer er koblet til esp8266\/esp32 via cc2530 (ZigBee) eller nrf24 (MySensors)? <\/p>\n
Om prosjekter<\/h3>\n
\nDet finnes ulike distribuerte systemer p\u00e5 markedet. V\u00e5rt system tillater integrasjon med de mest popul\u00e6re. <\/p>\n
Nedenfor er prosjekter som, p\u00e5 en eller annen m\u00e5te, pr\u00f8ver \u00e5 endre situasjonen med inkompatibilitet mellom ulike produsenter. Dette inkluderer for eksempel SLS Gateway<\/a><\/noindex>, MySensors <\/a><\/noindex> eller ZESP32<\/a><\/noindex>. ZigBee2MQTT <\/a><\/noindex> er knyttet til MQTT-serveren, s\u00e5 det passer ikke som eksempel. <\/p>\n
En av implementeringsalternativene for MySensors er en gateway basert p\u00e5 ESP8266. De andre eksemplene er basert p\u00e5 ESP32. I dem kan vi integrere v\u00e5r arbeidsmetode for oppdagelse og opprettelse av enhetslisten. <\/p>\n
Vi vil utf\u00f8re et tankeeksperiment til. Vi har en gateway ZESP32 eller SLS Gateway, eller MySensors. Hvordan kan vi kombinere dem i et enkelt informasjonssystem? Til de standardfunksjonene til disse gatewayene legger vi til SSDP-protokollbiblioteket. N\u00e5r vi henvender oss til denne kontrolleren via SSDP, vil den i sitt standardrespons legge til listen over enheter som er koblet til den. Basert p\u00e5 denne informasjonen vil nettleseren lage en side. I generell form vil dette se slik ut:<\/p>\n
\"Lytko
\nNettgrensesnitt<\/i><\/p>\n
\"Lytko
\nPWA-applikasjon<\/i><\/p>\n
"ssdpList": \n{\n   "id": 94967291, \/\/ unik identifikator av enheten\n   "ip": "192.168.x.x", \/\/ ip-adresse i nettverket\n   "type": "termostat" \/\/ typen av enhet\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": "bryter"  \n},\n{  \n   "id": 98412557, \n   "type": "r\u00f8yk"\n},\n{  \n   "id": 57995113, \n   "type": "kontakt_sensor"\n},\n{  \n   "id": 74123668,\n   "type": "temperatur_fuktighet_trykk_sensor"\n},\n{\n    "id": 74621883, \n    "type": "temperatur_fuktighet_sensor"\n}\n<\/code><\/pre>\n
\nFra eksempelet kan vi se at enhetene legges til uavhengig av hverandre. Tre termostater med egne IP-adresser og fem forskjellige sensorer med unike ID-er er koblet til. Hvis sensoren er tilkoblet et Wi-Fi-nettverk, vil den ha sin egen IP, og hvis den er tilkoblet en gateway, vil enhetens IP-adresse v\u00e6re IP-adressen til gatewayen.<\/p>\n
Vi bruker WebSocket for kommunikasjon med enhetene. Dette gj\u00f8r at vi kan minimere ressursbruken sammenlignet med GET-foresp\u00f8rslene og motta informasjon dynamisk ved tilkobling eller endring. <\/p>\n
Dataene hentes direkte fra den enheten som blokken tilh\u00f8rer, uten \u00e5 g\u00e5 om serveren. Dermed fortsetter systemet \u00e5 fungere selv om noen av enhetene feiler. P\u00e5 webgrensesnittet vil bare den tapte enheten ikke bli vist i listen. Men en varsling om tapet vil komme til brukeren i appen om n\u00f8dvendig. <\/p>\n
Den f\u00f8rste fors\u00f8ket p\u00e5 \u00e5 implementere en slik tiln\u00e6rming var en PWA-app. Dette gj\u00f8r at man kan lagre blokkdata p\u00e5 brukerens enhet og bare be om n\u00f8dvendige data. Men p\u00e5 grunn av strukturens s\u00e6rheter er denne varianten utilstrekkelig. L\u00f8sningen er native apper for Android og iOS, som n\u00e5 er under aktiv utvikling. Som standard vil appen bare fungere i det interne nettverket. Om n\u00f8dvendig kan alt overf\u00f8res til ekstern kontroll. Dermed, n\u00e5r brukeren forlater det lokale nettverket, vil appen automatisk bytte til skyen. <\/p>\n
Ekstern kontroll er en fullstendig duplisering av siden. N\u00e5r siden aktiveres, kan brukeren logge inn p\u00e5 serveren og styre enhetene gjennom sin brukerkonto. P\u00e5 denne m\u00e5ten utvider serveren funksjonaliteten, slik at man kan kontrollere enhetene fra utsiden av huset, uten \u00e5 v\u00e6re avhengig av portforwarding eller dedikert IP.<\/p>\n
Dermed er den ovenfor beskrevne varianten fri for servertiln\u00e6rmingens ulemper og har en rekke fordeler i form av fleksibilitet ved tilkobling av nye enheter.<\/p>\n
Om termostaten<\/h3>\n
\nLa oss se p\u00e5 kontrolleringssystemet ved hjelp av v\u00e5rt termostat-eksempel.<\/p>\n
Forutsatt:<\/p>\n
    \n
  1. Regulering av temperaturen for hver termostat (vist som en egen blokk);<\/li>\n
  2. Innstilling av timeplan for termostatens drift (morgen, dag, kveld, natt);<\/li>\n
  3. Valg av Wi-Fi-nettverk og tilkobling av enheten til det;<\/li>\n
  4. Oppdatering av enheten \"over luft\";<\/li>\n
  5. Innstilling av MQTT;<\/li>\n
  6. Innstilling av nettverket som enheten er koblet til.<\/li>\n<\/ol>\n
    \n\"Lytko
    \n
    \nI tillegg til styring via webgrensesnittet har vi ogs\u00e5 lagt til den klassiske metoden \u2013 ber\u00f8ringer p\u00e5 skjermen. Den har en Nextion NX3224T024 2,4 tommers skjerm om bord. Valget falt p\u00e5 den p\u00e5 grunn av enkelheten i \u00e5 bruke enheten. Men vi utvikler ogs\u00e5 en egen skjerm basert p\u00e5 STM32. Funksjonaliteten vil ikke v\u00e6re noe mindre enn Nextion, men den vil koste mindre, noe som vil ha en positiv innvirkning p\u00e5 den endelige prisen p\u00e5 enheten.<\/p>\n
    \"Lytko
    \n
    \nSom enhver respektabel termostat-skjerm, kan v\u00e5r Nextion:<\/p>\n