Микроконтролери и електроника
http://mcu-bg.com/mcu_site/

Mosquitto и... облаци
http://mcu-bg.com/mcu_site/viewtopic.php?f=16&t=15745
Страница 1 от 4

Автор:  TheWizard [ Съб Фев 10, 2018 1:42 pm ]
Заглавие:  Mosquitto и... облаци

Става въпрос за малки, приложения с около 200 устройства към брокер-сървър
Имам устройства, които логват данни с темп от минута до 10,
а проблема е че MQTT брокерите няма директна връзка с бази-данни и трябва някъв процес на сървъра да чете publish съобщенията и да ги записва в базата, а този процес не го искам !!!

Раз-компилирах москитото и добавих плъгин ( за сега DLL ) да "парсва" on PUBLISH съобщенията към DLL-a, а той директно сендва HTTP POST към апач-php-mysql
и мисля че стана... (screenshot http.jpg)
лагва около 10 мили секунди на съобщение към локал-хоста

Говорих с Roger Light, автора на москито - той каза, че в бъдеще щяло да има такива плъгини...
Въпроса е какво мислите за това или да мисля друга схема за логване на данните към базата

след известно време експерименти се изгаврих и вместо директно да ги сендва към HTTP ги пренасочих към node.js... лагва около 200 мили секунди на съобщение към локал-хоста
и си стана за сега :) node.js плъгин за москито
нода го имам инсталнат на компа, демек трябва да работи по същия начин и с phyton, php и подобни
с нода ми е възможно да пращам данните директно към mySQL/noSQL

Прикачени файлове:
node.jpg
node.jpg [ 189.61 KiB | Прегледано 6723 пъти ]
http.jpg
http.jpg [ 170.13 KiB | Прегледано 6723 пъти ]

Автор:  gicho [ Нед Фев 11, 2018 1:37 pm ]
Заглавие:  Re: Mosquitto и... облаци

TheWizard написа:
а проблема е че MQTT брокерите няма директна връзка с бази-данни и трябва някъв процес на сървъра да чете publish съобщенията и да ги записва в базата, а този процес не го искам !!!

Ако помислиш защо му викат "брокер", а не "сървър" ще разбереш защо концептуално е грешно да правиш плъгини - това е separation of concerns май идеологически. Това, което по всяка вероятност ти искаш се казва historian и се закача след брокера. Реално нещо като time-series база данни.
Като казвам "плъгин" имам предвид нещо добавено към брокера, в неговия процес, т.е. нещо статично или динамично линкнато към ядрото на брокера. Задълбавам да ти покажа основния принципен проблем на този подход - плъгина ти става специфичен за даденото ядро, т.е. москито или друго, и си зависим от някакво API. Според стандарта за mqtt такова апи не е описано, т.е. не е специфицирано и никой не е длъжен да го поддържа. Т.е. друг брокер, или нова версия могат да направят твоя плъгин неработещ.
Това в зависимост от гледната точка може да "бял кахър" и да не притеснява. Но си има причини и за да няма такова API - и едно от тях е че е ненужно тъй като вече има стандартен, специфициран, тестван, работещ механизъм за разширяване на функционалността на брокера - а това е MQTT протокола.
Ако ползваш него и реализираш идеята си като външен процес, който да е MQTT клиент, ще спазиш концепцията и ще имаш interoperability с произволен брокер, поддържащ дадената версия на протокола.
Помисли си как ще се случат нещата ако се наложи да се закачиш към деплойнат някъде брокер - може да е друг, може да е друга версия, може да се ъпдейтне след време към нова и т.н.
Единственото смислено разширение (според мен) което няма как да стане извън брокера (като отделен клиент) са разни екстри работещи с вътрешните данни на брокера - например начин да се абонираш за броя абонати на даден топик. Това ми е трябвало за да мога динамично да пускам и спирам разни мониторинг процеси (примерно polling на места където има "изход" към някакъв недорасъл протокол, който не поддържа publish subscribe). Това не съм измислил как да го направя отвън, т.е. без вътрешните списъци с абонираните клиенти.
Ако разгледаш ще видиш че дори стандартните bridge-ове между MQTT брокери се правят като отделни клиенти - т.е. процеси които има по един клиент за двата бриджнати брокера.
Реално подходът за да се случат нещата ти си го видял - обсъждат се в работни групи тия неща и влизат в стандарта. Но не мисля че някой би се навил да специфицира такива неща на ниво MQTT протокол. Евентуално определен разработчик може да се навие да напише и вгради твоето нещо в неговия брокер. Но аз лично не виждам достатъчно аргументи "за" които да преборят известните доста "против". Това всъшност е като 'apps' папката на lwip - става, може, който иска да прави и да предлага, но да се знае че няма да ги има ако бъде качено на облак или нещо такова (в смисъл не са част от tcpip стека и не се очаква всеки стек да ги има). След като има примерно BSD API за мрежа то апп-овете се правят с него за да може да се портира лесно. Ако е за ембедед се стига до "apps" на C за lwip.
Ако всеки почне да си добавя каквото му се иска ще стане голямо мазано - и точно това е довело до залеза на доста други протоколи.

Ако си стигнал до node.js мисля че имаш много по-директен път - виж това:
http://www.mosca.io/
То се закача с друг модул на същия италиянец:
https://github.com/mcollina/ascoltatori
Което прави връзка към Redis, MongoDB, ...
Но дори и да ползваш само брокера му лесно можеш да направиш произволно разширяване като изход към твоята база. То има нещо подобно, поне на име: https://www.npmjs.com/package/mqtt-db-sync
Имам съмнения обаче дали това ще е най-производителният вариант на това решение.
Всъщност има бази данни които поддържат pub-sub директно - например Redis: https://redis.io/topics/pubsub

Автор:  TheWizard [ Вто Фев 13, 2018 11:05 am ]
Заглавие:  Re: Mosquitto и... облаци

Това което обясняваш е така..
Става въпрос за частен брокер, сървър и базаданни
Брокера си работи нормално по стандарт, само си филтрирам моите неща за да избягам от други допълнителни процеси

Автор:  ДедоБоре [ Вто Фев 13, 2018 2:02 pm ]
Заглавие:  Re: Mosquitto и... облаци

а каква е въпющата нужда да не се пуска друг процес?

Автор:  gicho [ Вто Фев 13, 2018 2:23 pm ]
Заглавие:  Re: Mosquitto и... облаци

TheWizard написа:
Става въпрос за частен брокер, сървър и базаданни

В такъв случай няма причини да искаш да е точно mqtt брокер (и протокол). Най-малко ще са процесите ако пращаш заявките директно на базата. А да пращаш данни, от които да филтрираш нещо (т.е. да го губиш) и да пишеш част от нещата ме води до два извода - или имаш излишни данни които са там сигурно за "всеки случай", или ги ползваш и за друго (имаш друг, паралелен "консуматор" на данните който иска не-филтрираните).
Ако си сложил неща които някога може да потрябват би могъл да пишеш всичко - не се знае дали няма да искаш да достъпваш стари данни примерно.
Затова споменах Redis - като пример за база в която лесно можеш да "пълниш" без да минаваш дори през брокер. Така ще имаш само процеса на базата (фигуративно). Но това пак е стъпка в посоката обединяване на няколко отделни функционалности за удобство.
Обаче изглежда че ти искаш този "плъгин" не само за да препращаш към базата, а за анализ и филтриране на данните. Това вече е специфичен алгоритъм, които много вероятно ще е специфичен за твоята база (имам предвид за твоя модел на данните) и такова се съмнявам да мине като общоизползваемо. Имам предвид че си мислеш че искаш просто да прехвърляш payload-ите от някакви топици към таблици. Но ти споменаваш че преработваш данните - това съвсем не мисля че му е мястото в брокера (и в неговия процес, ако приемем че "плъгин" значи нещо вървящо в контекста на брокерските процеси).
Разбира се че ще го направиш както прецениш, просто споделям какво съм хванал от идеите на mqtt (и принципно брокерите) и защо има разлики между традиционните големи сървъри и microservices архитектурата, която пасва най-близо до брокерите и pub-sub.
Има и други интересни идеи, но са по-генерални и ако има интерес може да диплим.

Автор:  TheWizard [ Чет Фев 15, 2018 10:23 am ]
Заглавие:  Re: Mosquitto и... облаци

...друг процес...
стандартно: трябва да се конектна към брокера към съответните канали, да филтрирам топиците и да се разпределят данните към прилежащите им таблици в базата, а това си е допълнителна апликация/процес, а аз ползвам процеса на москитото, за сега синхронно, лага е 20 мили сек ( 200 мили за node.js ) за съобщение, което при мен е напълно задоволително да обработвам над 200 клиента спокойно без натоварване, По нататък ще пробвам асинхронно(да не бавя брокера) и най вече ако се ползва нода като "парсер"

разгледах Redis, пуб-суб е подобно/същото на това което правя с москитото... в бъдеще ще го тествам
То москитото си има плъгин(security) за before CONNECT, SUBSCRIBE, аз просто добавих after PUBLISH и onState(CONNECT, SUBSCRIBE, PUBLISH......)

Автор:  TheWizard [ Чет Фев 15, 2018 11:17 am ]
Заглавие:  Re: Mosquitto и... облаци

набързо пуснах съобщенията към node.js през thread....
лаг към брокера 0 мили сек,
самата нишка thread(node) = 350 мили

Автор:  gicho [ Чет Фев 15, 2018 9:27 pm ]
Заглавие:  Re: Mosquitto и... облаци

За какъв тред говориш, не схващам тия 350мс откъде са - между какво мериш. Тоя тред откъде е (щото няма да е от нода), значи имаш външен процес?
Или ти описваш варианта с плъгин в москитото и мериш до нода?

А относно наличието на плъгин(security) - това не е ли за тотално други цели? Не случайно е имало конект и субскрайб - те са местата където да се провери достъпа дали да бъде даден или не. Ама това с публиш ме хвърли в джаза - има API с което да поискаш да те известяват за публиш на точно определен топик, или си е генерално "на всеки публиш"? Ако е второто значи ще трябва да завъртиш пак цялата бюрокрация да видиш дали е от "твоите" топици". Което през "нормалния" протоколен интерфейс вече го имаш барабар с диези, плюсове и т.н.

Автор:  TheWizard [ Чет Фев 15, 2018 11:21 pm ]
Заглавие:  Re: Mosquitto и... облаци

плъгин(security) е за кой да, кой не (connect) и къде(topic) да се subscribe
по негово подобие се хванах след обработката на publish и търся съответната функция в моя плъгин(ако го има) и в зависимост от конфига на плъгина
вариант 1: ако топика(филтър) започва с ала_бала/.... http post message-то към localhost apache-php, там си парсвам кой къде как към базата
вариант 2: ако топика започва с ала_бала/.... старт еди кой си node.js, python или някъв там скрипт за към базата

в конфига на плъгина се определя как да се работи и какво да се филтрира, щото имам още по два топика за устройство за управление, те си преминават без обработка

node го виках със system(cmd) което си е синхронно и скрипта/нода ме бави около 350 мили секунди
сега го направих да го изпълнява thread... той(скрипта) кога свърши няма значение за брокера
москито state-machine(PUBLISH) -> DLL -> onPublush() - CreateThread - StartThread... минимална латенция към брокера, а нишката execute script, free и умира....

пробвах го и с python интересното е че е 2 пъти по бърз от нода

Автор:  gicho [ Нед Фев 18, 2018 9:52 am ]
Заглавие:  Re: Mosquitto и... облаци

Т.е. създаваш тред/процес при всяко публикуване??? Това няма как да стане приемливо бързо. Няма ли да е в порядък по-бързо прехвърляне към отделния процес - т.е. node да си стои и чака и през локалхост да получи събитието? Филтрирането за "ако е http post" го имаш готово в брокера - то и без това ще се изпълни преди/след колбека към твоя плъгин, така че не го спествяваш като сложиш твоето, а по-скоро минават и двете?
Бих се съгласил че може да има ефект ако имаше начин да кажеш на брокера като види определен топик да вика твой колбек и там да си направиш подготовката на заявката и да я изстреляш - с "екстрата" примерно да върнеш резултат на брокера и да му кажеш "аз се оправих с това събитие, работата е свършена, ти не се занимавай да търсиш абоната". Но си мисля че тука пак може да има греда - ти по всяка вероятно имах асинхронно API за пратиш към базата - т.е. даваш заявката на някого "извън теб" и забравяш, или чакаш за колбек от него че е станало или не? Ако е така (асинхронна) значи там имаш отделен процес за това I/O. Ако е синхронна значи напъваш процеса на брокера с цялата работа по пращането (а и чакането отговора).
Това е основната специфика (и сила на Node.js) - всичкото "I/O" ти е доставено като асинхронно, за да можеш ти да си свършиш работата в един единствен event loop, т.е. тред. Под "I/O" в случая се имат предвид мрежовите операции (сокета за връзка с брокера) и пращането към базата - по-всяка вероятност още един сокет.
Ако искаш да добавяш нови "I/O" трябва да се съобразиш с това че не трябва да блокираш основния тред на node-а - т.е. ако нямаш налично асинхронно API ще се наложи да ти да обърнеш на такова, добавяйки собствен тред.
Затова ти споменах за брокера на collina - той е вътре и нямаш нужда от превключвания на контексти (освен тези изисквани от TCP I/O-то на ноде-а).
Същото го има и за питон - https://github.com/beerfactory/hbmqtt - ползваш съм го за проби и също мога да го препоръчам. Имам предвид че имаш опит с питон и това би могло да ти е алтернативата - брокер, твоя обработка и изход към базата да ги направиш изцяло на питон.

Автор:  TheWizard [ Нед Фев 18, 2018 6:15 pm ]
Заглавие:  Re: Mosquitto и... облаци

правя thread за "всеки" изход(message) от брокера за да не му бавя state machine,
thread стартира за под една мили секунда, а самия тред се изпълнява да кажем за 350 мили зависи дали ще е питон, ноде, пхп... демек асинхронно, пращам без да чакам
ако чакам синхронно бавя стейта на брокера и се ограничава по брой закачени клиенти(точно в моя случай 100..200 клиента с темп на комуникация минута до 10 ми е без значение)
сега го правя с лист от топици, филтрирам само ако започват с еди какво си тогава "изход" натам
ако чакам отговор или калбак - може да "модифицирам" нящо, ама за сега гледам да не барам много по брокера, искам да си изясня какво точно ми трябва да го направя що годе универсално

пример за филтрация(редовете седят в кфг-то на плъгина)

FILTER(L/): node wiz_node/publish.js "%s" "%s" "%.*s"
FILTER(T/): http://localhost:80/lite/loger.php {"PROTO":"MQTT-LITE","CLIENT":"%s","TOPIC":"%s","MSG":"%s"}

за топици започващи с L/....... пращам към node wiz_node/publish.js с формат clinet, topic, message "%s" "%s" "%.*s"
а за топици Т/..... ги пращам с HTTP POST еди-къде си с формат онова в JSON-на, директно от плъгина, синхронно ми е около 20 мили към локалхоста

в нода(скрипта) за сега ми без значение как ще работи, той получава параметри CLIENT TOPIC MESSAGE, дали ще ги парсва и праща в базата.... няма значение за сега, отговор от него не ми трябва... за сега
ще го обмисля, да сглобя нящо да видя както точно става и къде може да има подводни камъни

Автор:  TheWizard [ Вто Фев 20, 2018 12:50 pm ]
Заглавие:  Re: Mosquitto и... облаци

тест на плъгина с един ESP mqtt клиент с датчик за частици и температура, темп 1 минута
москитото към плъгина към localhost http post към php, парсване, разпределяне и запис в монго

Прикачени файлове:
plugin.png
plugin.png [ 235.81 KiB | Прегледано 6344 пъти ]

Автор:  palavrov [ Сря Фев 21, 2018 10:37 am ]
Заглавие:  Re: Mosquitto и... облаци

В момента работя по нещо подобно като мащаб но с по голям обем на данните - синхронизирано снимане и събиране на снимки от 150 камери за възможно най кратко време ... всяка снимка е по 3-5мб и от камера се свалят по две. Т.е. обема на данните е между 500мб и 1гб - колегите са ме напънали да ги дръпваме за под 10с (това със запис в "база данни" и т.н.) - архитектурата ми е:
- "C" програма на камерата която чака UDP пакет с libuv, прави снимката и я записва в една папка която пък се вижда през httpd сървър
- node.js програма на сървъра която се грижи за всичко - от комуникация с камерите до react web user интерфаце

За момента камерите са RPi3, сървъра е EspressoBin (заради 3-те гигабитови етернет порта) но ще го сменяме, че се оказа скопен и въпреки, че има 3 гигабитови порта не може да се докара трафик повече от 1гб сумарно и сега ще минаваме на х86 с няколко PCI мрежови контролера, че да е сигурно, че ще може по всеки един да си върви по гигабит без да си пречи с останалите.

Нямам много време да опиша всичко в по големи детайли, но ако на някой му е интересно да пита - току виж си спести настъпването на мотиките които настъпах до момента :)

Автор:  miro_atc [ Сря Фев 21, 2018 11:21 am ]
Заглавие:  Re: Mosquitto и... облаци

palavrov написа:
всяка снимка е по 3-5мб


Няма ли комбо чип с DSP за сензора, компресия и някакъв link layer?
Навремето каубойците имаха такова с 1394 LLC, управляваше се супер елементарно (с 8051). Сега едва ли е акутално още, но ако имаш компресия кадъра ти пада на 0.5-1Mb. При 150 камери ще си на някакви си 100-150Mb. Даже по дъртото 1394 ще постигаш 2fps. Toва по един кабел... ако ги пръснеш на няколко кабела и някой малко "по-бързи" кабели не е невъзможно да постигнеш 15 или даже 30fps.
Стига да има нещо достатъчно бързо от другата страна на кабелите ;-)
Е на първо четене ми излиза RTS5825 сигурно има и други...

Автор:  palavrov [ Сря Фев 21, 2018 3:00 pm ]
Заглавие:  Re: Mosquitto и... облаци

Абе то има ама на нас ни трябва 8Мпиксела т.е. евентуално може да се ползва 4к камера и да се взимат само отделни кадри от видеото ако е кодирано с x265/hevc или дам някакъв друг яко мачкащ компресор запазващ читаво качество. Пък и бюджета като пари (пък и време) също има ограничения и не можем да се хвърлим на скъпи камери или пък дълга разработка. На мен като програмист най ми пасва да изнамерим евтина 4к охранителна камера с хардуерна х265 компресия на която да мога да пипам фирмуера за да я вкарам в режим на единични снимки а не да ми стриймва видео. На малинката успях да сваля големината от 5мб на 150кб със софтуерен x265 енкодер само, че това отнема по 20-30 секунди на снимка ... пък вградения хардуерен mpeg енкодер с който правя jpeg се справя за под секунда. Отделно да накачиш пайплайн в openmax за обработка на камерата скъсява живота с някоя друга година та за момента бързам да привърша останалата част от системата преди да започна да оптимизирам. Целта ми е да докарам до 30 или 60 кадъра в секунда синхронизирани през всички 150 камери - за да можем да снимаме движещи се неща - хора, животни и т.н. В момента снимаме само възрастни хора щото изпълняват като им кажеш да не мърдат за секунда две :D

Страница 1 от 4 Часовете са според зоната UTC + 1 час [ DST ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/