MQTT, openHab, Mozilla IoT atd.

[TechnikTom]

U MQTT mi trochu vadí ta přebujelost.
Když si představím, že všechny sensory se mi přihlásí třeba k odběru venkovní teploty nebo synchronizaci času, tak broker musí postupně obeslat všechny pěkně jednoho po druhém.
A při tom by stačil jeden broadcast označený jako venkovní teplota nebo čas.
Kdo to potřebuje, tak si to přijme a uloží
Něco jako u CAN.
A pak pozor u rychlých dějů.
RPi2 dokáže při qos=2 publikovat je 8 až 9 zpráv za sekundu.

[Reklama]

[HoLi]

A při tom by stačil jeden broadcast označený jako venkovní teplota nebo čas.

Osobne bych za toto byl take radsi. Ono by to pak cele mohlo fungovat zcela bez Brokeru. Stacil by jedinecny identifikator nebo treba certifikat, kterym by se komunikace podepsala a pak by kazde zarizeni mohlo rozeslat pres broadcast treba sve aktualni hodnoty a zarizeni co je chce by si je vzalo. Ale i tak se mi to libi a vzhledem k rozsahu, ktery chci mit je to zbytecne.

RPi2 dokáže při qos=2 publikovat je 8 až 9 zpráv za sekundu.

Mam RPi 3B+ a jak jsem rikal. Je to jen docasne reseni, aktualne spise na experimentovani nez na finalni implementaci do doby nez najdu misto pro Rack a splasim nejakej server.

[Mirek Prýmek]

U MQTT mi trochu vadí ta přebujelost.

MQTT je naopak velice úsporně navržený protokol. A slušně navržený - broker s většinou funkcionality se dá napsat za víkend. Ještě minimalističtější pak je MQTT-SN.

Když si představím, že všechny sensory se mi přihlásí třeba k odběru venkovní teploty nebo synchronizaci času, tak broker musí postupně obeslat všechny pěkně jednoho po druhém.

Což není absolutně žádný problém. Jsou to malé objemy dat a ten tok, který to způsobí, je pořád o několik řádů nižší než třeba blbý internetový rádio.

A při tom by stačil jeden broadcast označený jako venkovní teplota nebo čas.
Kdo to potřebuje, tak si to přijme a uloží
Něco jako u CAN.

To by ale museli být všichni klienti na jednom broadcast segmentu. Což je velký omezení.

A pak pozor u rychlých dějů.
RPi2 dokáže při qos=2 publikovat je 8 až 9 zpráv za sekundu.

Tomuhle nerozumím. Zpráv publikuje tolik, kolik mu řeknu, aby publikoval. QOS=2 pak jenom znamená, že na jednu "datovou zprávu" se použijí minimálně další 2 "servisní" zprávy.

Jinak, 8 až 9 zpráv za sekundu je absolutní nic. Provozuju na OrangePi audio server, CPU to žere minimum a těch zpráv tam běží několikařádově víc.

Řešíš neexistující problémy a hledáš optimalizace kde absolutně nejsou potřeba.

[TechnikTom]

To znamená, že pokud budete chtít rozeslat ( publikovat ) zprávu 40 senzorům s garancí doručení, bude to dle testů co jsem viděl trvat mosquitu na Rpi2 přes 4 sekundy.
A samozřejmě, publikovat jich můžete kolik chcete, jen víc než těch 9 za sekundu prostě neprotlačíte.

[Mirek Prýmek]

To znamená, že pokud budete chtít rozeslat ( publikovat ) zprávu 40 senzorům s garancí doručení, bude to dle testů co jsem viděl trvat mosquitu na Rpi2 přes 4 sekundy.
A samozřejmě, publikovat jich můžete kolik chcete, jen víc než těch 9 za sekundu prostě neprotlačíte.

Nevím, kdo to jak zkoušel, ale zjevně dělal něco špatně.

Za prvé je potřeba vědět, že QoS=2 by se mělo používat jenom tam, kde je opravdu nutné (tj. v domácích podmínkách nikde). Jelikož provoz běží po TCP, které má samo o sobě slušnou garanci doručení, není QoS>0 prakticky nikdy potřeba (ani na vypínače apod.).

Za druhé, pokud už použiju QoS=2, musím si dát hodně pozor na to, jak mám nastavenou diskovou persistenci. Pokud si tam nastavím, že se ukládá každá zpráva a zároveň to provozuju na RasPI, které mi to zapisuje na pomalou SD kartu, tak nemůžu čekat, že mi tam bude lítat tisíc zpráv za sekundu. A SD karta taky nemusí přežít do příštího měsíce.

Jinak, pokud člověk tyhle chyby neudělá, tisíce klientů a throughput v řádu tisíců i desetitisíců zpráv za sekundu není problém (http://www.scalagent.com/IMG/pdf/Benchmark_MQTT_servers-v1-1.pdf)

[Reklama]