Lytko միախմբում է

Մեկ ժամանակ մեզ ներկայացրել եք մտածող ջեռուցիչ. Այս հոդվածը սկզբում նախատեսված էր որպես նրա ծրագրFirmware-ի և կառավարման համակարգի ցուցադրություն: Բայց ջեռուցիչի աշխատանքի տրամաբանությունը բացատրելու համար անհրաժեշտ է նկարագրել ամբողջ կոնցեպցիան ընդհանուր առմամբ:

Օպտիմիզացման մասին

Լայնորեն, ամբողջ օպտիմիզումը կարելի է բաժանել երեք կատեգորիայի՝
Կատեգորիա 1 — առանձին «խելացի» սարքեր: Դուք գնում եք տարբեր արտադրողներից լույսեր, ջ kettle և այլն: Վերստին: յուրաքանչյուր սարք ընդլայնում է հնարավորությունները և բարձրացնում է հարմարավետությունը: Պահանջներ: յուրաքանչյուր նոր արտադրողի համար անհրաժեշտ է իր սեփական ծրագիր: Տարբեր արտադրողների սարքերի протոկոլները հաճախ չեն համատեղելի:

Կատեգորիա 2 — մեկական մեքենայի հետ միասին կամ X86 համատեղ: Սա թողնում է հաշվարկային հնարավորություների սահմանափակումները, և այս մեքենայի վրա տեղադրվում է MajorDoMo կամ ցանկացած այլ սերվերային դիստրիբյուտիվ՝ «խելացի» տան կառավարման համար: Այսպիսով, շատ արտադրողների սարքերը միանում են միասնական տեղեկատվական տարածքում: Դ。例如, հայտնվում է «խելացի» տան սեփական Սերվեր: +θύρες: համատեղելիություն միասնական կենտրոնում, որը տալիս է ընդլայնված հնարավորություններ управления: -նրկառի: սերվերի խափանումի ժամանակ ամբողջ համակարգը վերադառնում է 1-ին փուլ, այսինքն` դառնում է անշարժ կամ անօգուտ:

Կատեգորիա 3 — ամենածանրակշիռ տարբերակը: Վերանորոգման փուլում մշակվում են բոլոր կապերը և կրկնակի են դրվում բոլոր համակարգերը: +խնդիրներ: ամեն ինչ հասցված է իդեալի և այդ ժամանակ տունը իսկապես դառնում է խելացի: -արդյունավետության չափազանց բարձրություն համեմատ առաջին ու երկրորդ կատեգորիաների , անհրաժեշտություն առաջգային մտադրությունների ու յուրաքանչյուր մանրուքների հաշվի:

Համենայն դեպս, օգտագործողների մեծամասնությունը ընտրում է առաջին տարբերակը, ապա աստիճանաբար անցնում երկրորդ տարբերակին: Իսկ հետո առավել տոկունները անցնում են երրորդ տարբերակը:

Բայց կա ընտրանք, որը կարելի է կոչել բաշխված համակարգ. յուրաքանչյուր առանձին սարք կլինի և՛ սերվեր, և՛ հաճախորդ: Իրոք, սա մի փորձ է վերցնել և միավորել առաջին ու երկրորդ տարբերակները: Վերցնել նրանց բոլոր առավելությունները և բացառել նվազագույները, որսալ ոսկե միջինը:

Հնարավոր է, որ ինչ-որ մեկին կասի, որ նման տարբերակը արդեն մշակված է: Բայց այդպիսի լուծումները` ոլորտային; մարդկանց համար, ովքեր լավ են հասկանում ծրագրավորմանը: Մեր նպատակն է նվազեցնել մտքի շեմը դեպի նման բաշխված համակարգեր, ինչպես վերջնական սարքերի տեսքով, այնպես էլ մեր համակարգին գոյություն ունեցող սարքերի ինտեգրմամբ: Ջեռուցչի դեպքում, օգտագործողը պարզապես վերցնում է իր հին ջեռուցիչը, տեղադրում խելացի, և միացնում նրանց մոտեցող զգուշավորությունները: Ոչ ոք լրացուցիչ գործողություններ չի պահանջվում:

Առաջարկենք ինտեգրման մեր համակարգում օրինակով:

Եկեք պատկերացնենք, որ մեր ցանցում կա 8 Sonoff մոդուլ: Որոշ օգտատերերի համար բավարար կլինի կառավարումը Sonoff ամպի միջոցով (կատեգորիա 1): Ոմանք սկսում են օգտագործել երրորդ կողմի փրոշFirmware և հանգիստ անցնում կատեգորիա 2: Երրորդ կողմի փրոշFirmware-ների մեծ մասը աշխատում է նույն սկզբունքով. տվյալների փոխանցում MQTT-ի սերվեր: OpenHub-ը, Majordomo-ն կամ որևէ այլ ծառայություն ծառայում է մեկ նպատակին՝ մեկուսացված սարքերը միացնել մեկ միասնական տեղեկատվական տարածքում, որը գտնվում է թե՛ ինտերնետում, թե՛ տեղական ցանցում: Այսպիսով, սերվերի առկայությունը պարտադիր է: Առաջանում է կարևոր խնդիր՝ սերվերի անհաջողության դեպքում ամբողջ համակարգն ավելի ոչ ինքնավար է աշխատում: Այս դժվարությունը կանխելու համար համակարգերը բարդանում են, ավելացվում են ձեռքով կառավարման եղանակներ, որոնք կրկնում են ավտոմատությունը սերվերի անհաջողության դեպքում:

Մենք գնացել ենք այլ ճանապարհով, որտեղ յուրաքանչյուր սարք ինքնաք suficiente: Այսպիսով, սերվերը առանցքային դեր չի խաղում, իսկ միայն ընդլայնում է ֆունկցիան:

Վերադառնանք մտքի փորձին: Կրկին վերցնենք նույն 8 Sonoff մոդուլները և տեղադրենք մեջը Lytko փրոշFirmware: Lytko բոլոր փրոշFirmware-ներում իրականացված է ֆունկցիա SSDP. SSDP՝ ցանցային պրոտոկոլ, որը հիմնված է ինտերնետի պրոտոկոլների հավաքածուի վրա և ծառայում է ցանցային ծառայությունների հայտարարելու և հայտնաբերելու համար: Ուղարկված հարցման պատասխանն կարող է լինել և՛ ստանդարտ, և՛ ընդլայնված: Մենք այդ պատասխանին ավելացրել ենք իմաստի ստանդարտ ֆունկցիաներին, ստեղծելով սարքերի ցուցակը ցանցում: Այսպիսով, սարքերը ինքնուրույն գտնում են միմյանց, և նրանցից յուրաքանչյուրն այդ ցուցակը կունենա: SSDP ցուցակի օրինակ՝

"ssdpList": 
	{
		"id": 94967291,  
		"ip": "192.168.x.x",
                "type": "thermostat"
	}, 
	{
		"id": 94967282,
		"ip": "192.168.x.x",
                "type": "thermostat"
	}

Ինչպես видно են օրինակից, ցուցակը ներառում է սարքերի id-ները, ip-հասցեն ցանցում, բլոկի տեսակը (մեր դեպքում՝ Sonoff բազան վրա պարունակվող տերմոստատ): Այս ցուցակը թարմացվում է երկու րոպեն մեկ (այս ժամանակահատվածը բավարար է ցանցում սարքերի քանակի դինամիկ փոփոխություններին արձագանքելու համար): Այսպիսով, մենք հետևում ենք սարքերի ավելացման, փոփոխության և անջատմանն առանց օգտատերի կողմից որևէ գործողությունների: Այդ ցուցակը ուղարկվում է զննարկիչ կամ շարժական ծրագրին, և սկրիպտը ինքնուրույն ստեղծում է էջը որակյալ բլոկների բովանդակությամբ: Յուրաքանչյուր բլոկ համապատասխանում է մեկ սարքին/սենսոր/կառավարիչի: Վիզուալ ցուցակը տեսնում է ինչպես հետևյալը:

Բայց եթե esp8266/esp32-ին միացված են այլ ռադիո-սենսորներ cc2530 (ZigBee) կամ nrf24 (MySensors) միջոցով:

Պրոյեկտների մասին

Ցանցի վրա առկա են տարբեր բաշխված համակարգեր: մեր համակարգը թույլ է տալիս ինտեգրվել ամենատարածվածների հետ:

Արձանագրված են այն պրոյեկտները, որոնք այս կամ այն կերպ բարձրացնում են տարբեր արտադրողների միջև անհամաձայնությունը: Դրանք են՝ SLS Gateway, MySensors կամ ZESP32. ZigBee2MQTT կապված MQTT-s серверի վրա, այնպես որ չի հարմար մեր օրինակին:

MySensors-ի реализации տարբերակներից մեկը ESP8266 հիմնված шлюզն է։ Մնացած օրինակները՝ ESP32-ի վրա։ Եվ այստեղ կարելի է կիրառել մեր սարքի հայտնաբերման և սարքերի ցանկի պատրաստման սկզբունքը։

Կատարենք մեկ այլ մտավոր փորձ experiment. Ունենք ZESP32 шлюզ կամ SLS Gateway, կամ MySensors։ Ինչպես կարող ենք դրանց միացնել միասնական տեղեկատվական տարածքում։ Այս шлюզերի ստանդարտ ֆունկցիաներին ավելացնենք SSDP պրոտոկոլի գրադարանը։ Երբ դիմում եք այս կառավարչին SSDP-ի միջոցով, նա ստանդարտ պատասխանին կավելացնի սարքերի ցանկը, որոնք կապված են նրան։ Այս տեղեկատվության հիման վրա բրաուզերն ստեղծելու է էջ։ Ընդհանուր տեսքը այսպես կլինի։

Web-интерфейс

PWA-արգասիք

"ssdpList": 
{
   "id": 94967291, 
   "ip": "192.168.x.x", 
   "type": "thermostat"
},
{
   "id": 94967292,
   "ip": "192.168.x.x",
   "type": "thermostat"
},
{
   "id": 94967293,
   "ip": "192.168.x.x",
   "type": "thermostat"
},
{  
   "id": 13587532, 
   "type": "switch"  
},
{  
   "id": 98412557, 
   "type": "smoke"
},
{  
   "id": 57995113, 
   "type": "contact_sensor"
},
{  
   "id": 74123668,
   "type": "temperature_humidity_pressure_sensor"
},
{
    "id": 74621883, 
    "type": "temperature_humidity_sensor"
}

Օրինակից երևում է, որ սարքերը ավելանում են մի համակարգի մեջ անկախ միմյանցից։ Կապված են 3 թերմոստատներ սեփական IP-հասցեներով և 5 տարբեր սենսորներ յուրահատուկ ID-ներով։ Եթե սենսորը միացած է Wi-Fi ցանցին, ապա կունենա իր IP հասցե, եթե միացած է шлюզին, ապա սարքի IP հասցեն կլինի шлюզի IP հասցեն։

Սարքերի հետ կապի համար օգտագործում ենք WebSocket։ Սա թույլ է տալիս նվազեցնել ռեսուրսների ծախսերը համեմատ GET-հետաքրքրություններ հետ և ստանալ տեղեկատվություն դինամիկ ձևով միացման կամ փոփոխության ժամանակ։

Տվյալները վերցվում են անմիջապես այն սարքից, որի բլոկն է, շրջանցելով սերվերը։ Ասել է թե, եթե որևէ սարքը ձախողվի, համակարգը շարունակում է աշխատել։ Վեբ-հարթակում միայն անհայտ դարձած սարքը չի ցուցադրվում։ Բայց անհրաժեշտության դեպքում, կորուստի ազդանշանը կգա որպես ծանուցում օգտվողի բաղակների։

Այս փորձի առաջին իրականացումը եղել է PWA-արգասիք։ Սա թույլ է տալիս պահել բլոկների տվյալները օգտվողի սարքում և հարցնել միայն անհրաժեշտ տեղեկությունները։ Բայց կառուցվածքի առանձնահատկությունների պատճառով, այս տարբերակը անբավարար է։ Եվ մեկ ելք կա՝ մոբիլ փոխադրանքը Android և IOS համար, որը այժմ ակտիվ զարգացման փուլում է։ Ծածկած, ծրագիրը միայն կաշխատի ներքին ցանցում։ Եթե անհրաժեշտ է, ամեն ինչ կարելի է փոխարկել արտաքին կառավարմանը։ Այսպիսով, երբ օգտվողը լքում է տեղական ցանցը, ծրագիրը ավտոմատ կերպով switches to cloud.

Երրորդ կողմի կառավարումը՝ ծառայության լրիվ կրկնօրինակումը։ Տվյալ էջը ակտիվացնելուց հետո օգտագործողը կարող է մտնել սերվեր և կառավարել սարքերը անձնական հաշվեհամարով։ Այս ձևով, սերվերը ընդլայնում է գործառույթները, թույլ տալով կառավարել սարքերը, գտնվելով տունը դուրս և կախյալ չլինելով նավահանգիստների փոխանցումից կամ հատուկ IP-ից։

Այսպիսով, վերոնշյալ տարբերակը ազատ է սերվերային մոտեցման թերություններից և ունի մի շարք առավելություններ, ինչպիսիք են նոր սարքերի կապի ճկունությունը։

Թերմոստատի մասին

Կանխատեսենք կառավարման համակարգը մեր թերմոստատի օրինակով։

Նախատեսված է՝

1. Յուրաքանչյուր թերմոստատի ջերմաստիճանի կարգավորում (ցուցադրվում է առանձին բլոկով);
2. Թերմոստատի աշխատանքի գրաֆիկի կարգավորում (ուգסה, օր, երեկո, գիշեր);
3. Wi-Fi ցանցի ընտրություն և սարքի միացում;
4. Հրաժարում սարքի 'օդային' թարմացումը;
5. MQTT կարգավորում;
6. Ցանցի կարգավորում, որի միջոցով կապակցված է սարքը։

Բացի web-հրաձգությունից, նախատեսված է դասական — էկրանին ճեղքումով։ Առկա է Nextion NX3224T024 2.4 դյույմանոց մոնիտոր։ Ընտրությունը հանուն սարքի աշխատանքը հեշտ դարձնելու համար։ Սակայն մշակվում է սեփական մոնիտոր על հիմնված STM32։ Նրա գործառույթները ոչ մի կերպ չեն զիջում Nextion-ի ծախսերի հաշվի առմամբ, սակայն ավելի ագրեսիվ գին կունենա, ինչը դրական կերպով կազդի սարքի վերջնական գնի վրա։

Ինչպես և ամեն հարգված թերմոստատի էկրան, մեր Nextion-ը կարող է՝

• փոխել անհրաժեշտ ջերմաստիճանը (սեղմելով աջ կողմի կոճակները);
• ըմբռնում և անջատել գրաֆիկի միջոցով աշխատանքը (N կոճակը);
• ցուցաբերել ռելեի աշխատանքը (ձախ կողմի նշան);
• ունել երեխաների պաշտպանության համակարգ (ֆիզիկական սեղմումները արգելափակվում են, մինչև բանալին հանվի);
• ցուցադրել WiFi-ի ազդանշանի մակարդակը։

Բացի այդ, մոնիտորի միջոցով կարելի է՝

• ընտրել օգտագործողի ներթափանցած տվիչի տեսակ;
• կառավարել երեխաների պաշտպանության գործառույթը;
• թարմացնել firmware-ը։

WiFi բարի վրա սեղմելուց հետո օգտագործողը կսովորի միացված ցանցի մասին տեղեկատվությունը։ QR կոդը օգտագործվում է HomeKit-ի firmware-ին սարքը կապակցելու համար։

Դիսպլեյի հետ աշխատանքի դեմո՝

Մենք մշակել ենք դեմո-էջ երեք կապակցված թերմոստատներով։

Դուք հարցնում եք՝ "Ինչպես առանձնահատուկ է ձեր թերմոստատը?" Հիմա շուկայում բազմաթիվ թերմոստատներ կան Wi-Fi գործառույթով, աշխատում են գրաֆիկ էդե, հարմար էեկրանային կառավարման։ Իսկ էնտուզիաստները գրել են մոդուլներ առավելապես սիրված խելացի տուն համակարգերի հետ (Majordomo, HomeAssistant և այլն)։

Մեր թերմոստատը հարմար է այսպիսի համակարգերի համար և ունի վերոնշված բոլոր հատկանիշները: Բայց առանձնահատուկ հատկանիշն այն է, որ թերմոստատը մշտապես բարելավվում է համակարգի ճկունության շնորհիվ: Ամեն մեկ թարմացման հետ ունենք նոր գործառույթներ: Ստանդարտ համակարգի կառավարման մեթոդի (ժամանակացույցով) միացումից բացի, մենք կավելացնենք ադապտիվը: Տևականորեն կընդունենք օգտագործողի գեոլոկացիան: Հենց դրա շնորհիվ, համակարգը դինամիկ կերպով կհարմարեցնի աշխատանքային ռեժիմները նրա գտնվելու վայրի վրա հիմնված: Իսկ եղանակի մոդուլը թույլ կտա հարմարեցնել եղանակային պայմաններին:

Ունենք նաև ընդլայնման հնարավորություններ: Յուրաքանչյուր ոք կարող է փոխարինել իրեն ապրած սովորական թերմոստատը մերով: Պետք է ընդամենը մի քիչ ջանքեր գործադրել: Մենք ընտրել ենք 5 ամենատարածված սենսորները, որոնք ներկայումս մատչելի են շուկայում, և ավելացրել ենք դրանց աջակցությունը: Բայց նույնիսկ բացառիկ հատկանիշների դեպքում, օգտատերը կարող է միացնել այդ սենսորը մեր թերմոստատին: Համար անհրաժեշտ կլինի թերմոստատի կալիբրումը կոնկրետ սենսորի համար: Մենք տրամադրելու ենք հրահանգներ:

Թերմոստատը կամ ցանկացած այլ սարք միացնելիս, այն ամենուրեք բարձրանում է: և վեբ-ֆրանցիայում, և PWA հավելվածում: Դիակն ավտոմատ կերպով ավելացնում եմ: Պարզապես պետք է միացնել այն Wi-Fi ցանցին:

Մեր համակարգը չի պահանջում Սերվեր, և Սերվերի ձախողման դեպքում դա չի վերածվում լրագրերի: Խմբավորումներից մեկի ձախողման դեպքում համակարգը չի սկսում աշխատել ճգնաժամային սցենարով: Կոնտրոլեր, սենսորներ, սարքեր. յուրաքանչյուր բաղադրիչ և Սերվեր, և հաճախորդ, այնպես որ լիովին ինքնավար է:

Հետաքրքրվողների համար՝ մեր սոցիալական ցանցեր: Telegram, Ինստագրամ, Telegram News, VK, Facebook.

Շփվել մեզ հետ՝ shop@lytko.com

P. S. ոչ թե Սերվերից հրաժարվելու կոչ ենք անում. Մեր մոտ նաև կա MQTT-server-ի աջակցություն և ունենք սեփական ամպ: Մեր նպատակն է համակարգի կայունությունն ու հուսալիությունը բարձրացնել որակապես նոր մակարդակի: Որպեսզի Սերվերը չլինի թույլ կողմ ու լրացնի գործառույթները, ինչը կդարձնի համակարգը հարմարավետ:

Ընտանիք: habr.com