Pokud se bude ještě testovat, poprosil bych jestli náhodou nemáte na zahradě studnu dát modul do ní. Mám klasickou kopanou studnu z betonových skruží zakrytou betonovým poklopem a zhruba 1/2m pod tím poklopem bude ESP měřit hladinu. Moduly s anténou na PCB už to nezvládaly, musel jsem pořídit verzi s externí anténou (i když jinak i základní ESP-01 s anténou na PCB fungovalo spolehlivě 50m od domu). Testoval jsem tak, že jsem modul spustil v igelitové tašce, důležité bylo mít přiklopený poklop, bez něj to docela fungovalo. Base nechte uprostřed domu jak byl. Pokud není studna, tak se pokusit najít podobně problematické místo, ještě třeba zarovnat cihlami atd. Nebo base umístit do rohu domu a remote venku na druhém konci zdi, aby signál musel jít v celé délce zdí. Prostě zkusit limity, jestli se povede komunikaci na 10-15m přerušit překážkou.
Předem díky 
Do studny neskočím, ale BigClown modul jsem tam hodil 
Dal jsem vysílací modul 0,5m od horního víka. Problémem přenosu nebyly skruže, ale to, že je studna prakticky v úrovni terénu. Kdyby se modul dal těsně pod víko, tak jsem přesvědčený že přenos bude 100% ať už přijímací část dám do domu kamkoliv. Ale to by o ničem nevypovídalo.
Viděl bych to tak, že přenos je spolehlivý, jen se zkrátka musí přemýšlet nad umístněním přijímacího modulu.
Děkuji moc, přesně takové testy jsem potřeboval. S umístěním přijímacího modulu toho člověk moc neudělá, když bude chtít mít USB dongle v Omnii a ta už je někde kam vedou UTP a kde dává smysl v rámci pokrytí domu wifi. Proto jsem to nyní chtěl proti base uprostřed domu. Leda snad až bude možnost routingu přes 1 hop jak psal Michal, tak to přeroutovat přes prvek lépe umístěný vzhledem k příjmu.
Pokud se podílíte i na dokumentaci, tak jeden z podnětů co bych měl, popis MQTT topiců: tady https://doc.bigclown.com/mqtt.html to vypadá jako nodes/bridge/0/thermometer/i2c0-48 což i dává smysl, všude jinde kde není bridge už není /0/ část (jak se tedy rozlišuje více base, remote, relay?) a u publikování to je vůbec divné, jednou nodes/base/led-strip/-/set pak nodes/base/led-strip/-/config/set, nikde ty popisy topiců nevidím, nevím co je ta pomlčka (znám wildcards + a #) atd. Předpokládal bych u každého modulu popis všech topiců, pokud modul něco sám odesílá tak co (topic/zpráva) a jak často. Přijde mi, že ty informace nejsou buď vůbec nebo se k nim dostává hrozně obtížně a přitom za tu zvýšenou cenu očekávám úsporu času proti vlastnímu bastlení z jednotlivých součástek - proto jsem psal, že chybí základy, tak abych dal konkrétní příklad.
Aktuálně je možné a účinné umístění base řešit možnostmi LAN (na UTP či Wifi pověsit např. RPi + base).
Identifikátor base není třeba v rozvržení MQTT topics podle MQTT Reference řešit (vůbec tam není), protože každý remote je identifikován unikátním id a v pub/sub komunikaci není třeba rozlišovat přes který base komunikace chodí (provozně se tak komunikační topologie může i měnit a na logiku ovládání pak případná změna topologie nemá vliv).
Např. více relé se pak rozlišuje id node (konkrétní MCU+security čip) a m:n (pozice na I2C sběrnici).
Bridge Module nemá MCU a security čip (ze kterého je id odvozeno), tedy nemá id, proto potřebuje dodatečné očíslování.
Pomlčka je použita jako náhrada I2C adresy u periferií, které mohou být v jednom stohu jen jednou (např. LED na Core Module nebo senzor CO2). Je použita proto, aby dobře fungovaly subscribe s použitím wildcards, tedy aby bylo možné si nechat posílat např. všechna měření z jednoho node.
Subtopic config je použit pro konfigurační nastavení vlastností konkrétní periferie např. jak často bude měřit, zatímco set bez config subtopicu je k nastavení stavu periferie typu aktuátor (např. relé).
MQTT topics jsou obecně vlastnostmi firmware a ne vlastnostmi HW modulů. Směřujeme ke generickému firmware node, ale SDK, struktura MQTT topics i payload nejsou zatím zcela usazeny. Pravděpodobně dojde ke změnám např. v souvislosti s podporou shadow devices (obdoba AWS IoT shadow devices).
Máte pravdu, že koncept MQTT topics si zaslouží zdokumentovat, doplníme do dokumentace.
Za pořizovací cenu BC komponent dostáváte hlavně kvalitní HW.
Celková cena BC HW komponent je většinou menší než celková cena “levné elektroniky” s obdobnými vlastnostmi (low power, možnost zabezpečení), ale je to zkušenost, která přichází až s roky provozu. Do celkové ceny je třeba počítat cenu pořízení a cenu provozu např. na 10 let. U “levné elektroniky” není výjimka výměna modulů po roce či dvou (např. z důvodu ztráty kapacity nekvalitních kondenzátorů v důsledku působení teplotních vlivů či vibrací, vypalování struktur čipů výboji - absence ESD ochran, snížení citlivosti rádia v důsledku malé kompenzace vnějších vlivů, změna elektrických parametrů PCB, či jen odpálení modulů prostým přepólováním baterií při absenci ochrany proti přepólování, …). Samozřejmě jsou výjimky, např. lidé jejichž hobby je věnovat se servisu a každý měsíc zjišťovat, který prvek přestal fungovat tentoktát budou znechuceni z HW, kde modul potřebuje jen jednou za dva roky vyměnit baterie - pro takové jsou BC komponenty bohužel velmi nevhodné.
Pravděpodobně tématu celkové ceny budu věnovat samostatný článek, protože zkušenosti s výhledem několik roků dopředu nám scházejí ve společnosti v mnoha oblastech (např. nastavení penzijního systému s výhledem volebního období nemůže být efektivní v porovnání s generační či dokonce vícegenerační parametrizací).
Díky za dotazy.
Umístění base na rPi jinam je možné ale ne ideální, mám Omnii na UPS a nechce se mi z principu starat o další nezálohované prvky, výpadek jednoho čidla se dá přežít, výpadek base je horší.
MQTT Reference: tady mé dotazy asi dost vychází z toho, že jsem do dokumentace chodil z Obchodu, kde se otevře anglická evidentně o kus chudší verze, kde toho není moc popsáno a odkaz na českou verzi dokumentace není, netušil jsem doteď, že existuje
S cenou je to těžké. První rPi mi běží 5 let, ESPčka asi 2,5 roku.Třeba to zítra klekne. Nevím, jestli úplně počítám to, jestli se mi to celkově vrátí za 10 let. Menší spotřeba je samozřejmě argument, protože nikdo nechce měnit každý měsíc baterky v nějakém remote členu. Ale kdoví co bude, pasivní wifi s 10000x menší spotřebou atd. Taky nemám rád vyhazování, ale kdybych si v roce 2007 koupil tu nejlepší Nokii, že mi jako vydrží 10 let a celkově ušetřím, asi by mi to nevyšlo Nebojte, chápu rozdíl mezi telefonem a prvky v domě a jejich jinou předpokládanou morální životnost, ale jako svým způsobem hračička (což tu bude většina lidí) celkem pochybuji, že na to 10 let nesáhnu a nebudu mít chuť to vylepšit nebo zařadit prvky, které nebudete mít v nabídce. BFU na tom bude jinak, otázka jestli návrh, instalaci a programování BC zvládne a nenechá si spíš nainstalovat něco hotového od firmy.
Base může být několik, RPi může dostávat napájení po PoE nebo může mít vlastní DC UPS nebo můžete zkusit experimentovat s USB over Ethernet nebo k Core Module v roli base připojit Ethernet nebo … možností je spousta. Nejjednodušší bude změnit parametrizaci ISM rádia (např. zmenšit modulační rychlost, protože o propustnost či latenci často u těchto přenosů nejde).
I pro případný ISM hop by bylo třeba řešit napájení, protože node v roli statického routeru ISM rádia už nebude moci většinu času “prospat”, takže bateriové napájení bude obtížnější.
Ad prolinkování a jazykové verze dokumentace - díky za upozornění, to nám uniklo, pořešíme v nové verzi, která je těsně před spuštěním.
S cenou mi to přijde naopak lehké:
- Dostatečně velká skupina zákazníků kvituje vlastnosti a nakupuje BC prvky (této variantě věříme a proto neoptimalizujeme na cenu, ale na kvalitu)
-
Přijde výrobce, který umí stejnou kvalitu a služby za nižší cenu (na tuto variantu se těšíme, rádi se učíme)
-
O BC komponenty nebude zájem (tento scénář nepovažujeme za pravděpodobný)
Samozřejmě i v sortimentu BC rozdělení na produkty částečně vychází z cenových očekávání zákazníků - např. jsme plánovali Battery Module, který obsahoval Battery Module a Sensor Module, který skončil nakonec jako dva moduly, protože cena modulu “jen pro napájení” přišla zákazníkům vysoká, byť byla menší než součet cen dnešních Battery Module a Sensor Module. Nicméně toto nejsou optimalizace na úkor kvality.
Při optimalizacích na nejnižší cenu se nedá vyhnout “kompromisům” s kvalitou, ať to je horší kvalita součástek, absence řízení kvality výrobního procesu nebo vypuštění ochran z designu HW - pak se stává, že pračka či myčka kondenzátory vytřese, že rádio nepřežije otevření mikrovlnky za chodu (on se ten magnetron nevypíná úplně hned při mezeře v kleci), že moduly odcházejí při letních bouřkách, že rádio přestane komunikovat nebo odejde v místnosti s 3F asynchronním motorem řízeným invertorem (např. vodárna), atd.
Když se vrátíme k původnímu tématu tohoto threadu, tedy produkt USB Dongle a multi Senzor, tak HW podle našeho názoru opravdu vydrží 10 let provozu ať už se technologie pohne kamkoliv. Tyto produkty nejsou z hlediska konstrukce HW určeny pro HW rozšiřování, potenciál růstu je v SW (např. doplnění zabezpečení, možná doplnění interpretu, atp.) a případném doplnění BC modulů.
U stavebnice BC lze samozřejmě udělat přestavby HW (změna funkcí, doplnění periferií, atd), tam jsou možnosti z hlediska HW otevřené. Stavíme hlavně na I2C, obecně máte všechna běžně používaná rozhraní (UART, SPI, GPIO, PWM, ADC/DAC, …).
Je fajn, že jsme v době, kdy low-power rádiová komunikace rozkvétá, varieta technologií se zvětšuje a je z čeho vybírat. Zejména v buňkových low-power sítích nás jistě čekají zajímavosti.
Když budeme chtít zůstat u otevřených technologií s dostupným rádiem (seznam co nám díky tomu vypadne je dlouhý), troufám si tvrdit že nás úzkopásmové ISM rádia jen tak neopustí, o čemž svědčí i to, jak dlouho už s námi jsou. Ano, rádia s dobrými parametry jsou levnější, snižuje se spotřeba (o řád už to půjde ztuha), zvyšuje se slektivita, atp.
Právě z důvodu variability přenosových technologií očekáváme integraci na úrovni MQTT a REST služeb. Když máte v oblibě “éčka”, doporučuji k pozornosti Mongoose OS, který na této integraci staví také.
Hotových produktů je a bude jistě také celá řada (např. i takové jako Smart Box), je na uživatelích co jim vyhovuje a jaké chtějí mít možnosti nahlédnout “do strojovny” či možnosti přizpůsobení/rozšíření.
Díky za náměty.
Je krásné, že prvky BC mají plánovanou životnost cca 10 let. Ale jaká je plánovaná životnost routeru Omnia? Můj Turris 1.x jede trvale s teplotou CPU okolo 90°C, což mu dlouhou životnost neslibuje.
Životnost prvků BC je podpořena ST Longevity Commitment na 10 let od ledna 2017 pro STM32L0 a toolchainem podporovaným přímo ARMem.
K plánované životnosti Turris routerů se vyjádří spíše kolegové z Turris teamu.
Turris 1.x jede na procesoru Freescale P2020, který má specifikovanou maximální junction teplotu 125°C, takže pokud mluvíte o teplotě čipu měřenou diodou na čipu, máte dost rezervy - trvalá teplota okolo 90°C slibuje dlouhou životnost. Konstantní (nebo málo se měnící) teplota je optimální provozní prostředí pro čipy (nejvíce jim “ubližuje” pnutí při teplotních změnách např. při zapínání/vypínání nebo jiné mechanické namáhání). Protože jsou použity i další kvalitní komponenty, je praktická životnost omezena spíše backportováním SW TO, dostupností záplat, podporou Linux kernelu (aktualizace, záplaty) a dostupnosti balíčků (nové verze, záplaty).
Martin @hubmartin publikoval zdrojové kódy firmware, které připravil pro vysílač a přijímač použité ve videích k testování dosahu. Můžete se na nich podívat, jak málo aplikačního kódu stačí při využití BC SDK k napsání smysluplné funkcionality.
Vysílač: https://github.com/hubmartin/bcf-rf-test-tx/blob/master/app/application.c
Přijímač: https://github.com/hubmartin/bcf-rf-test-rx/blob/master/app/application.c
Bohužel…jak sem se na BC těšil tak ceny to zatím zabíjí 
CO2 senzor chápu…ty jsou drahý,ale chtít za teplotu a vlhkost 2000 kč v době kdy to stejný od Xiaomi/Agara koupím po 8 dolarech v hezčím kabátku a easy to use? No nejdu do toho radši oželím tu proklamovanou bezpečnost a vystačím s miHome, Sonoff a gadgets
Tak už nějakou dobu plánuji, že nahradím domácí meteostanici nějakými moduly pověšenými na Turris. Cena USB dongle mi přijde OK, cena senzoru teploty a vlhkosti už méně. A ještě by se mi líbil nějaký eink displey, který bude zobrazovat hodnoty, grafy atd. Ideálně když to taky bude komunikovat přes ten dongle.
Ovšem vůbec netuším, jestli se k tomu někdy dostanu 
USB Dongle Vám bude komunikovat s Core Module na který lze nacvaknout LCD Module, je na něm Sharp Memory LCD. Je to technologie s nízkým odběrem i při častějších změnách obsahu (např. aktualizace 1x za sekundu) na rozdíl od eink.
Na kdy se toto řešení plánuje?
No, ona je nejspíš otázka, zda-li se to vůbec bude realizovat. Chápu tento (i ve stejném duchu anglický příspěvek) jako průzkum, zda-li o uvažované integrované řešení (Turris Omnia vs. Big Clown) bude mezi komunitou vůbec zájem … a podle výsledků průzkumu zatím moc zájem není. Nebo spíše, abych byl přesnější, je zájem spíše chabý.
Kdy/zda případně v jaké konfiguraci Senzoru po distribučním kanálu Turrisu záleží primárně na Turris Teamu a pak na velikosti série, v kusovém množství téměř obratem, stovky za 1/2 roku (lead time součástek). Stavebnice BigClown je dostupná nyní v obchodu BigClown.
Já osobně bych měl spíše zájem o hotové řešení bez nutnosti dalšího “doprogramování” (jak už jsem psal výše) - tedy dongle + hotové jednoduché akční členy (v podstatě relé řízená bezdrátově) a jednoduché snímače (0/1, napětí, případně čítač pulsů,…) - vše jednoduše spárovatelné (opět bez nutnosti připojovat k PC - podobně jako se páruje dongle + bezdrát klávesnice nebo myš). Řízení a vyhodnocování stavů potom provádět přes Domoticz (nebo podobnou aplikaci v Turrisu).
Rád bych se věnoval až vývoji konkrétní aplikace (zařízení) za akčními členy (resp. před snímači) - na ladění přenosové části nemám čas ani chuť (nicméně to samozřejmě ostatním neberu).
Tyto požadavky zatím zařízení od BC nesplňuje (i když je samozřejmě superuniverzální, nicméně čas věnovaný případnému ladění stavebnice bude chybět jinde). Samozřejmě by případný zájem závisel i na ceně tohoto řešení. Spíše bych oželel univerzalitu a dal přednost více jednoúčelovým jednodušším zařízením.
@Yearling Hotových firmware (bez nutnosti “doprogramování” MCU) udržujeme několik - viz seznam níže.
Tyto předpřipravené firmwares (včetně firmware pro USB Dongle či Senzor) lze flashnout na MCU s pomocí BigClown Firmware Flasher, ten nainstalujete např. s pomocí Python pip pip install bcf (potřebujete Python 2.7 nebo 3.6) nebo je také součástí BigClown Firmware Windows Toolchain.
Utilita bcf umí stáhnout aktuální firmware z Gitu a flashnout do MCU (Dongle, Senzor, Core, …).
Chování firmware je popsán ve vzorových projektech v BigClown dokumentaci.
Pro “hotové řešení” bez “doprogramování” MCU Vám pak stačí bcf (ať instalovaný přes Python pip nebo zabalený do binárky PyInstaller v Toolchainu), kterým si bcf update stáhnete seznam aktuálních firmware, bcf pull stáhnete příslušný firmware a bcf flash flashnete firmware do MCU.
V případě USB Dongle a Senzoru pak máte hotový HW včetně krabiček, v případě komponent stavebnice BigClown HW “skládačku” (navolíte si senzory/aktory dle potřeby) bez krabičky. V obou případech máte hotový přímo použitelný firmware MCU (nemusíte psát kód pro MCU) s textovým sériovým rozhraním typu MQTT topics a datový payload (obecně JSON payload).
Toto textové rozhraní můžete použít v rámci Vašeho aplikačního SW nebo můžete použít HUB SW BigClown (zakončení do MQTT, integrace nad tím). Můžete se tedy věnovat vývoji vlastní aplikace nad textovým sériovým rozhraním nebo nad MQTT rozhraním.
Proč prosím toto řešení nesplňuje Vaše představy ?
bigclownlabs/bcf-climate-station:firmware-142pixel.bin:v1.0.1
bigclownlabs/bcf-climate-station:firmware-144pixel.bin:v1.0.1
bigclownlabs/bcf-climate-station:firmware-72pixel.bin:v1.0.1
bigclownlabs/bcf-generic-node:firmware-battery-mini.bin:v1.3.0
bigclownlabs/bcf-generic-node:firmware-battery.bin:v1.3.0
bigclownlabs/bcf-generic-node:firmware-power-module-RGB-150.bin:v1.3.0
bigclownlabs/bcf-generic-node:firmware-power-module-RGB-300.bin:v1.3.0
bigclownlabs/bcf-generic-node:firmware-power-module-RGBW-144.bin:v1.3.0
bigclownlabs/bcf-generic-node:firmware-power-module-RGBW-72.bin:v1.3.0
bigclownlabs/bcf-lcd-thermostat:firmware.bin:v.1.0.0-beta
bigclownlabs/bcf-ping-pong-table:firmware.bin:v1.0.0
bigclownlabs/bcf-sigfox-climate-monitor:firmware.bin:v1.0.1
bigclownlabs/bcf-sigfox-co2-monitor:firmware.bin:v1.0.0
bigclownlabs/bcf-sigfox-motion-detector:firmware.bin:v1.0.1
bigclownlabs/bcf-sigfox-pulse-counter:firmware.bin:v1.1.0
bigclownlabs/bcf-skeleton-core-module:firmware.bin:v1.0.0
bigclownlabs/bcf-usb-dongle:firmware.bin:v0.0.0-test
bigclownlabs/bcf-usb-gateway:firmware.bin:v1.3.0
Díky za info. Až bude čas na hraní, tak na to mrknu.
Novinka: Senzor (včetně Cloony samozřejmě) obstál při zkoušce odolnosti na elektromagnetické pole v automotive třídě.
To znamená, že HW funguje spolehlivě i v relativně náročném prostředí
Looks good. But why is this not in the english part of the forum???