Bastlením se zabývám a tento článek mi opravdu udělal radost. Myslím, že jsem na něco podobného už narazil při bloumání internetem, samozřejmě v angličtině.
Ale myslím si, že by to chtělo začít opačným postupem, který považuji za jednodušší. Koupit si hotové zařízení, třeba zigbee žárovku + jednoduchou bránu, třeba HOME ASSISTANT SKYCONNECT, a pokusit se napsat jednoduchý komunikační program pro ovládání zařízení a čtení jeho stavu (můj případ).
Tím se získá praxe a znalosti komunikačního protokolu a jednotlivých entit, které do žárovky implementoval profesionál - výrobce. Teprve s těmito znalostmi bych začal bastlit svoje koncové zařízení.
Ale je to "jen získávání obecných znalostí". S Home Assistant to přímo nemá nic společného. Takže takovýchto článků jsem na netu moc nenašel. I když samozřejmě vím o knihovnách zigpy a navazující bellows. Jen můj názor.
Abych jen neteoretizoval, momentálně zkouším tohle:
https://github.com/MalteGruber/zigpy_standalone
Velmi dobry clanok, hoci ma HA dobre popisane vsetky rozsirenia, takyto komplexny clanok dokaze edukovat ovela lepsie.
Mohli by ste sa v niektorom pokracovani dotknut temy dlhodobej archivacie vybranych senzorov? Potreboval by som dlhodobu statistiku spotreby plynu/elektriny a po viacerych zmenach v HA som to uz vzdal. Ako toto riesit v HA?
Dobrý den,
ohledně dlouhodobé archivace sensorů. Nestačilo by vám data těchto sensorů ukládat do influxdb a následně vizualizovat v Grafana? Psal jsem o tom v jednom z předchozích dílů. Sám toto přesně kvůli dlouhodobé spotřeby elektřiny, plynu a vody mám. Každopádně nějaký základní pohled, včetně historie, je v HA v energy dashboardu stále dostupný i napříč verzemi. Toto téma bych rád zpracoval do dalšího pokračování.
VS
Dik za nakopnutie, teraz som aktualizoval HA a neverim vlastnym ociam - od verzie 2023.12 bola pridana zalozka History, kde je presne to co potrebujem.
V některém z minulých článků seriálu to Václav popisoval... klíčová slova jsou InfluxDB + Grafana :)
HA má Energy dashboard, ve kterém se vytváří dlouhodobá statistika automaticky. Pak je možné posílat data do Promethea nebo InfluxDB a HA ta data umí teď nově i číst a jako bonus k tomu jde připojit Grafana jak tu píší ostatní.
BME280 ve spojeni s ESP jsem vzal a hyhodil do kose. Po nekolika dnech se zasekla i2c komunikace a pomohl jen restart. A to se jak je pravidlem stava ve chvili, kdyz jste na dovolene. Nahradil jsem to za cinske wifi tuya cidla, ktere jsem prefleshoval by delali to co maji. Cidlo z API za 50kc v plastove krabice vs. BME chip za skoro stovku + ESP + jako bonus musite resit krabicku. To se nevyplati.
Vysledne pouceni. HW se nevyplati stavet. Ten je lepsi vzdy koupit
Zajímavé. Mám mnoho BME modulů za desítky korun (žádné stovky) zapnuté 356 dní v roce a ani jednou jsem nezaznamenal zaseknutí i2c. Připojeno k esp8266 i esp32. V esp flashnuty NodeMCU takže sw psán v lua. Všechno se posílá po mqtt do influxu.
No na kodu neni nic sloziteho, stravil jsem s tim spoustu bezesnych noci https://github.com/karotka/smart.home/blob/main/temp.sensor/src/temp.sensor.ino deska je taky profi vyrobena problem jsme nenasel
No, já tam vidím problémů dost...
1) Průměrujete 10x tu stejnou hodnotu (čtení ze senzoru probíhá pouze jednou při volání getEvent!) [0][1]
2) Žádné timeouty nikde.. pracujete s hardware, rádiem a sítí! Musíte počítat s tím, že ke ztrátě packetu, nedostupnosti sítě, wifi nebo externímu rušení může dojít. [2][3]
3) Žádný watchdog, aby se to resetovalo na hardwarové úrovni, když už software skončí ve smyčce.
[0] https://github.com/karotka/smart.home/blob/main/temp.sensor/src/temp.sensor.ino#L79
[1] https://github.com/adafruit/Adafruit_BME280_Library/blob/master/Adafruit_BME280.cpp#L564
[2] https://github.com/karotka/smart.home/blob/main/temp.sensor/src/temp.sensor.ino#L40
[3] https://github.com/karotka/smart.home/blob/main/temp.sensor/src/temp.sensor.ino#L104
Pěkné. S ESPHome si template vytvoříš do 5 minut a pak už program beze změny flashuješ do libovolného počtu zařízení. Vše funguje spolehlivě a v noci mohou klidně spát...
Hele vzal jsem BME280, nějakej ESP32 board, přidrátoval to bez pájení, zapojil do nabíječky na telefon, vmáčknul to mezi roury u vířivky a měří to už skoro rok bez jedinýho problému. To bude něčím jiným.
Za stovku máš těch BME280 minimálně deset.
Jako nevim cim to je, proste to v celem baraku postupne umiralo. Deset asi tezko :) je rozdil BME a BMP. BME je drazsi. 3x se mi stalo, ze mi misto BME poslali BMP
BMP280 považuji za nejspolehlivější čidlo ve své kategorii. Teplotu a tlak s ním měřím už 10 let. Napřed bylo připojené k RPi, teď už několik let k ESP32 - senzor je vlastního návrhu. Zasekávání I2C jsem taky zažil. Ano. A taky jsem měl chuť to hodit do koše. Ale pak jsem si přečetl datasheet a kód napsal tak, aby splňoval to, co si žádá datasheet. Hlavně pauzy mezi požadavkem a čtením odpovědi. S BME280 je to to samé. Od té doby se mi nezaseklo ani jedno čidlo.
BME280 jsem používal taky, ale není úplně schopné dlouhodobě pracovat ve venkovních podmínkách - odcházely mi. Proto na vlhkost používám SHTněco.
A jsi spokojený s přesností? SHT10 bylo spíš hádač vlhkosti než měřák (dokázalo mi tvrdit, že vlhkost je 110% a podobně). Použij raději SHT3x.
Každopádně to nic nemění na tom, že ty BM**80 čidla jsem používal a používám a pokud jsem dodržel časování, tak byla/jsou spolehlivá.
18. 1. 2024, 18:58 editováno autorem komentáře
Na mereni teploty doma v kazdem pokoji to jde. Obcss je treba pricist neco, nebe odecist, ale kdyz se to skalibruje, tak to funguje dobre.
Jo, zasekávání I2C jsem taky viděl. Rádiové vysílání blízkého rádia (ESP má Wifi, že ano..) umí někdy naindukovat dost, aby to zmátlo připojenou periferii.
Proto je potřeba bitbang způsobem umět odblokovat sběrnici (poslat data až do NACKu, STOP a zajistit IDLE).
https://www.analog.com/media/en/technical-documentation/application-notes/54305147357414AN686_0.pdf
Ad vlastní VLAN: Mikrotik dovoluje i v rámci jedné SSID podle MAC nastavit separátní heslo (PSK) a VLAN, Výhoda je, že s tím není takový overhead na beacons.
Snížit zátěž beaconů se dá snížit taky tak, že se zvýší rychlost na které se vysílají. Většina AP je vysílá na 1 Mb/s pro maximální dosah a to pak trvá věčnost. V OpenWrt je default 6 Mb/s a dá se to dále zvýšit, nejjednodušeji přes cell_density. Takže i když budete mít třeba 10 SSID, tak pořád rušíte okolí míň než jedno bežné AP. Ale zkuste to vysvětlit sousedům.
Zajímavé. Myslel jsem si, že se beacony vysílají na stejném kanále, kde ta síť funguje, pak by rušení se sousedy bylo jedno, pokud si všichni nastaví jiný kanál…
Jo, to jo, ale na 2.4GHz se kanály překrývají a je jich tak málo, že těžko se najde nějaký volný. Navíc běžná AP ještě k tomu si je náhodně mění v čase.
Soused si stěžuje na pomalou wifi, přitom má jen jedno "nabušené" AP nastavené na maximální výkon, aby mu to jakože pokrylo celý byt. Když vidí, že mám 7 SSID (všechny na jednom kanále), tak se mu to nezdá. Líp by udělal kdyby si místo toho koupil více levných AP, roztahal je po bytě a nastavil výkon na minimum.
ESPhome je moc fajn. Hodilo by se zmínit, že nijak nezávisí na Home Assistantovi, je to jen jeden z komunikačních protokolů který umí.
Na jednoduché věci se hodí MQTT, třeba shellový skript na pár řadků používající příkazy mosquitto_sub a mosquitto_pub. Nebo naopak složitější věci, které by se v Home Assistantovi dělaly už moc těžkopádně, a kde je už lepší sáhnout po skutečném programovacím jazyce.
ESPHome je jistě výkonný systém, ale pro začátečníka může být možná trochu náročnější na rozjezd.
Doporučuji kouknou na projekt ESPeasy.
Do čipu to také můžete nahrát přímo z prohlížeče, ale po připojení na wifi se připojíte na jeho webové rozhraní a hezky naklikáte jaký senzor máte na jaké piny připojený, co se má dít s naměřenými hodnotami a můžete napsat jednoduché skripty pro další práci s naměřenými údaji nebo přijatými daty z nadřízeného systému.
Konfiguraci můžete samozřejmě zálohovat a použít pro další čidla atd.
Už 6 let s tím, nahraným v Sonoff Basic, řídím el. podlahovku v každé místnosti bez jediného problému.