И кат' висне дограмата, радиатора нажежен до червено...

То хубаво искаш да си го направиш сам, и аз за много неща така правя, ма глей за почти без пари кво се продава.
https://www.itead.cc/sonoff-th.html

Тия китайски Sonoff, не правят нищо по-различно от мене с една много тънка разлика:
- Ако си сглобя частите сам, ми излиза наполовината, като цена
- Тия пращат към клауд някакъв данните или всички устройства работят като AP и трябва да се връзваш към тях.
Аз сензорът го имам и DH11 и DS1820 и на Microchip MCP9808 имам. ESP8266 имам поне 3-4 платки различни конфигурации. Въпросът е, че искам да си го направя по мой вкус, без да ползвам чужди облаци.

Ако си сметнеш и времето по каквато и да е разценка сметката никак няма да ти се върже. Не искам да те отказвам, напротив - просто икономията не трябва да е мотив в случая. Виж предизвикателството, научаването на нещо ново, притеснението от облака помоему са много по удачен мотив.

И най-вече последното. Гадничко е когато фирмата на "бай-хой" изчезне, облака спре, и всички устройства ползвали тая услуга да станат безполезни кутийки...

Терзанието ми беше, има ли някакъв подход, нещо, което някой го е правил преди, за генериране на Schedule tasks от WEB api, като самото апи или сървърът, който стои зад него да задействат събития, когато дойде времето. Или си оставам с cron jobs.

Зависи каква ти е архитектурата, концепцията. Аз бих направил на сървъра един сървис който да се стартира автоматично, да се рестартира ако умре и т.н. и в него бих сложил таймери кога да проверява сензорите. По този начин можеш да направиш някаква по лесна конфигурация през апп или веб интерфейс и няма да трябва да редактираш cron jobs и прочее системни файлове. А дали сензорите ще са в slave режим и ще чакат някой да им обърне внимание или сами ще пращат данни през определен интервал от време е друга бира. Хубаво е да имаш в предвид и за някаква опашка където да се трупат данни ако някоя част от системата не работи да не се появяват празни дупки в данните през този период. Можеш да направиш опашка в сензора докато сървъра не му каже да трие след като е записал всичко и т.н. варианти много - зависи колко ти се занимава.

Архитектурата се оформя да бъде - един сървър и едно или повече EndPoint устройства. Сървърът ще може изпраща команди към устройствата, а устройствата ще рапортуват данните си през определен момент от време. Комуникацията между сървъра и устройствата ще бъде посредством HTTP в локална мрежа (т.е сървърът и устройството/ата ще са в една и съща мрежа).
Терморегулаторът през определен период от време изпраща HTTP POST заявка към сървъра с моментната температура на помещението и евентуално, други параметри, които да могат да бъдат зададени от бутоните на устройството или отдалечено.
Сървърът ще съхрани температурата/данните в БД, като по-късно събранните данни, могат да бъдат визуализирани като графика/тренд на потребителя. От своя страна сървърът ще може да казва на регулатора да включи/изключи радиатора. Т.е тук нямаме Master-slave комуникация.
Друга съществена роля на сървърът е да представлява посредник между комуникацията на потребителят с устройството, т.е да му предоставя API за управление на устройството/ата, да визуализира данните, да синхронизира устройствата.

Идеята е регулаторът, както и евентуални бъдещи устройства, които биха могли да бъдат добавени към вече съществуващата разработка, да бъдат прости устройства, които да приемат точно дефинирани заявки и да изпращат точно дефинирани зададени заявки. Освен това, всяко устройство ще има бутон за "reset", с който да се вкарва в режим, който да позволи да се зададат настройките на устройството (ssid, password, api_key ). Целта на този подход е, да бъде цялата система насочена една идея повече към plug&play. Така например, взимам една платка с ESP, програмирам я и когато я вкарам в регулатора, мога да му сетна настройките ръчно и после да си го оставя да работи, без да хардкодвам всеки път за всяка платка някакви настройки.

От гледна точка на сигурността. Връзката между сървъра и потребителя е енкрипната + Log-in система, за предпазване от нежелан достъп. Връзката между Esp и сървъра е некриптирана, но пък всяка платка ще си има уникален api key, с цел да е сигурно, че няма поради една или друга причина една платка да пише данни в таблицата пригодена за друга или да се опитва да манипулира сървъра или устройството. API ключът за сега си го мисля сам и го хардкодвам в сървъра и устройството, но в бъдеще, когато измисля и други устройства, може сървърът да го генерира и пази в друга таблица, съответно да го дава на потребителя да го вкара ръчно в конфиг менюто на устройството или автоматично при откриване на ново устройство да му сетва ключа и устройството да си го помни в еепрома.

Да, целта е наполовина учебна, но е и наполовина приложна. Т.е наистина целя да управлявам някои устройства вкъщи, разчитайки, че правейки го аз, макар и супер нескопосано и по възможно най-тъпия начин, няма някой китаец или "хакер" - ентусиаст да тръгне да се бъзика с устройствата вкъщи, само щото в youtube са излезнали 1000 клипчета, как да се бъзикаме със smarthome-а на съседа.

Хубаво е да помислиш за някакви защити които да сработват в случай, че тоя сървър запцне - примерно някакъв предварително зададена горна температура която ако се достигне устройството което управлява отоплението да изключва автоматично а не да чака команда. Същото при падане под минимална температура и т.н. Т.е. колкото и да искаш тези устройства да са възможно най прости е добре ако все пак могат да бъдат и донякъде автономни и да не зависят от постоянна връзка с кораба майка т.е. да няма single point of failure както за цялата система, така и за всеки един елемент сам по себе си.

Server е пасивен елемент...
Слуша и Отговаря ... понякога и записва
Той не управлява
Управлява човек или "робот"(демон, сервиз. .. )

Потребителят ще задава температура + време за работа или само температура, за минимална няма смисъл, ако ме няма 1 седмица вкъщи, няма смисъл да се пуска радиатора въобще, ако ще и -20 градуса да е в стаята, винаги мога да видя каква е температурата и да преценя кога да включа радиатора. Под сървър имам предвид РС-то, което ще ползвам като сървър, не сървърното приложение (apache/mosquitto).
Значи за сега виждам по следния начин варианта:
Потребителят създава задачи посредством WEB Базирано приложение; въпросното приложение създава cron job; създава запис в БД с параметрите на задачата и някакъв идентификатор на cron job-а. После при поискване приложението визуализира списъка с актуалните задачи. При желание на потребителят да изтрие дадена задача, приложението намира съответния cron job и го премахва, посредством идентификатора, записан в БД. Като го няма записан, cron job-ът не се изпълнява. При желание на потребителят да промени или активира/деактивира задачата, задачата ще се трие или променя от списъка с cron job, а ще се актуализира нейното състояние и параметри в БД.

първо трябва да измислиш "НОДА" и default програмата(например JSON) по която ще цъка радиатора ако няма сървър
след това ако има сървър на горната база как ще я приема и update, тряяя измислиш мониторинга за текущи параметри - online, темпетатура ...
после как ще комуникираш в локалната и глобалната мрежа(secure) - интерфейс, протокол ... един "тъп" радиатор си е "забавление"


най-лесния начин ( така работи IoT Google, Amazon, Azure, Alibaba .... сичкото облак дето си помислиш )
пускаш една linux машина с хард диск Apache, PHP, mySQL, nodeJS, python, mosquito
връзваш всички нодове по MQTT (узер и парола) локално да си пингват москитото, да мониторват във PUB nod_id/monitor -> {текущи данни на QoS 0 кой ги чуе чуе}
SUB(слуша) nod_id/command и PUB nod_id/command_answer

пишеш "демон/и" на C, node, python да слуша всичко от брокера и да мажеш в базата данни, пишеш "демон" да "управлява"
Апача праща "където и да е" текущите данни от ДБ и през апача имаш ремоте достъп до локалното MQTT

и тн .... няколко метра код

Всички NODEs рапортуват през определен период от време данните си на апача, а апачът ги записва в БД. Температурата ми в момента е в таблица: room_temp със следните колони:
id, temp, reading_date. За всяко измерване имаш нов запис в БД. Така мога да си направя статистика за определен период от време и да я визуализирам тази статистика във формата на тренд. Към момента имам тренд, който визуализира данните за последното денонощие.

От гледна точка на сигурността, всички нодове са в домашна WiFi мрежа свързани с WPA2 енкрипция. Апачето е свързано с lan cable към същия рутер. На апачето имам Let's encrypted, като всеки, който е извън мрежата минава задълже през HTTPS, а локалните нодове могат да си говорят с апачето без криптиране.

За да бараш каквото и да е трябва да се логнеш в "системата", т.е да въведеш username & password.



Ако няма да се ползва сървъра, т.е ако минеш в ръчно управление, имаш два бутона за нагласяне на температурата, монтирани на самото устройство. Натискаш единият - увеличаваш зададената температура. Натискаш другия - намаляш заданието.



Това съм го направил преди да пусна темата.



Г/д такава ми беше първоначалната идея, ама с появата на BD се обезсмисля MQTT-то. Вместо това директно си комуникират с HTTP заявки на локално ниво. NODE-овете изпращат post заявки към linux машината, linux машината изпраща POST заявки към NODE-овете.


Еми, в момента, когато потребителят се аутентифицира в апача, апачът му визуализира данните. Освет това може да каже на апача, да изпрати заявка за включване/изключване на релето или промяна на някакъв параметър.

и си направил нода HTTP мулти мастър и клиен и сървър...
играй си - апетита идва с яденото

Да, всеки ноуд е клиент+сървър, ама то това е принципа на HTTP комуникацията. Много малко, струва ми се, са сайтовете или приложенията, в които да имаш класически client-server модел. Обикновено когато посетиш един сайт или изпратиш заявка до сървър, този сайт/сървър изпраща заявки до други сървъри/сайтове.