Zigbee? Homeassistant? kérdés

Fórumok

Leírom a megoldandó problémát:

Van egy rendszerem: homeassistant, mqtt, zigbee2mqtt, zigbee (lámpa) a főbb komponensek.

A lámpát néha lekapcsolják (fizikai kapcsolóval teljesen áramtalanítódik ilyenkor). Értelemszerűen ekkor hiába küld neki bármilyen automatizálás bármit.

Azt szeretném elérni, hogy a kívánt állapot (kapcsolás, fényerő) tárolódjon el valahol és amikor a lámpa ismét elérhető akkor legyen beállítva jól.

Nem muszáj azonnal, ha cronjobból 5 percenként történik az is teljesen oké megoldás.

Hozzászólások

Szerintem egyreszt ez nem teljesen igaz, masreszt az OP pont a masik oldalrol kozeliti meg a problemat, ami valoszinuleg mukodhet is (sorry, azt nem tudom, hogy hogy kell megcsinalni).

 

Kerdes az is, hogy mit ertesz "aram alatt" alatt. A Zigbee tamogat sleepy end device-okat, amik ugyan kapnak tapot de az ido jelentos reszeben alszanak, hogy energiat takaritsanak meg (jellemzoen elemes taplalasnal) - ergo ezek nem forwardolnak csomagokat, tekintve, hogy alvas kozben nem tudnak kommunikalni (amikor felebrednek lekerdezik a parent device-t, hogy var-e szamukra uzenet (poll / data request)). Persze teljesen el is lehet venni az eszkozoktol a tapot, altalaban a network parametereket lementik NVM-be a csatlakozaskor, amikor megkapjak ujra tapot vagy innen beolvassak vagy ujra join process van. Az is igaz, hogy egy villanykapcsolot alapbol lehet, hogy nem sleepy end device-nak terveznek, mert feltetelezik, hogy ott mindig van tapellatas - de ez igazabol csak firmware kerdese.

De a kerdezo felvetese arrol szol, hogy a Home Assistantban szeretne eltarolni az allapotot (ugy emlekszek ilyet lehet csinalni) majd szertene kuldeni egy (MQTT) uzenetet idonkent, ami a kapcsolonak atkuldi ezt az eltarolt allapotot (szerintem ilyet is lehet (MQTT uzenetet kuldeni nyilvan lehet, mar en is csinaltam)).

/sza2

Digital? Every idiot can count to one - Bob Widlar

Zigbeenel 3 fele eszkoz letezik. Coordinator, router es end device. Amirol Te beszelsz az end device. Amirol en beszelek az router. Az izzok jellemzoen routerkent mukodnek es ezert aram alatt “kell” lenniuk. Azert idezojel mert nem kotelezo de mivel reszt vesznek a halozat megalkotasaban a hozzajuk fizikailag kozelebb levo eszkozok ezeken keresztul kommunikalnak a tobbi eszkozzel. 

Ha allandoan aram alatt vannak azzal elkerulheto a halozat allando ujraszervezese es kulon repeaterek(routerek) hasznalata hiszen mar egy eleve hasznalt eszkoz elvegzi ezt a feladatot.

Vannak sleepy deviceok is valoban de azok nem is mukodnek routerkent csak end devicekent.

Bar valoszinuleg meg lehet oldani a felvazolt MQTT bohockodassal ennek ellenere en nem mennek eziranyba a fentiek miatt, de pontosan ezzel is kezdtem a fenti kommentemet

En most pl pont azzal szivok hogy az uj adaptive lighting komponens pont erzekeny arra hogyha direktbe MQTT-rol van rangatva az izzo HA call service-ek helyett..

Erre van az MQTT last will testament, illetve retained message, ha támogatja valamennyire is az eszköz, viszont ezzel a probléma az lesz, hogy amikor felkapcsolod fizikailag, akkor jelentős és érzékelhető idő eltelik, mire megkapja ezt az üzenetet... ha megkapja, mert a legtöbb MQTT implementáció nem perzisztens.

Ennek a mellékhatása az lesz, hogy ha logikailag le volt kapcsolva utoljára, a default state on, akkor felkapcsolódik, majd az MQTT kapcsolat felépítésével lekapcsolódik. Vagy fordítva, ha default off és utoljára fel volt kapcsolva, akkor felkapcsolod, semmi, és egyszercsak lesz fény.

Nekem alapvetően ezért nem jöttek be ezek a központ miatt okos dolgok, mert a központ miatt nem tárolnak state-et és hülye dolgokat képesek csinálni, ha leszakadnak az agyukról.

Szerkesztve: 2021. 06. 15., k – 18:55

lehet hulye kerdes, de miert nem a masik oldalrol kozelited meg a dolgot es veded ki magat a problemat pl azzal, hogy raksz a kapcsolo moge egy shelly1 et? (vagy 1L-t, ha nincs nulla.) feltetelezem, itt egy okosizzorol van szo igaz?

Vagy ha szeretsz hackelni, akkor meg egyszerubb, ha veszel egy xiaomi nyomogombot, raforrasztasz ket kis vezeteket amit beteszel a kapcsolo moge es kesz :) (max 1-2 evente kell szetszedni, elemcsere miatt)

 

https://thinkl33t.co.uk/zigbee-button/

 

Ha jol valasztasz kapcsolot (nem tudom milyen gyartmany az izzod) akkor meg bindelni is tudod, tehat akkor is mukodni fog, ha a szervered valamiert nem megy.

Igen és nem. A kapcsolóval nem a lámpa áramkörét kapcsolod, hanem a Shelly kapcsoló bementét, a Shelly 1L pedig annyit tud, hogy az izzószálon vagy egyéb esetben a külön értékesített söntön keresztül kap annyi parazita áramot, hogy folyamatosan hálózaton tud lenni külön odavezetett N nélkül is.

Szia! Bár elektroműszerésznek tanultam időszámításunk előtt, de nem tudom, hogyan kéne kiszámítani. Ha mutatnál egy irányt az jó lenne mert van néhány Shelly-m és Sonoff Mini-m is.
Egy ilyet találtam korábban, de nem próbáltam még ki (alkatrész hiányában).
https://support.itead.cc/support/discussions/topics/11000016944/page/2?url_locale=

Szép napot!
Kárász Attila

Nem tudom, mert nem tudom, hogy hogyan kell kiszámolni. Én leragadtam az Ohm törvénynél. A nyagy lányom fizika dolgozatát is csak hármasra sikerült megírni amikor homeoffice-ból nyomtuk mind a ketten.  :-) Kerestem képleteket a Net-en de nehéz megfogalmazni a keresőnek, hogy mi keresek.

Most esett le, hogy kikapcsolva is van fogyasztása és lehet h az úgy átfolyó áram már elég a shellynek is. :)

Érdemes kipróbálni, hogy hátha.

Ez a bypass dolog alapból nem tetszik, felesleges plusz fogyasztás, nem is olyan kevés.

Nem több, mint amennyit a Shelly fogyasztana rendes tápellátással, hiszen sorba vannak kötve és sönt-kondenzátor nem igazán fogyaszt önmagában, nem melegszik.

A ZigBee2MQTT-t nem ismerem (ZHA-t használok), de az nem járható út, hogy azok az automatizálások, amik a lámpa állapotát módosítják, azok egy input_boolean-t is állítgatnak? (ami így megmondja, hogy milyen állapotban kéne lennie a lámpának)
Egy másik automatizálás pedig a lámpa "nem elérhető" -> "elérhető" átmenetére triggerelődne, és beállítaná a lámpát arra az állapotra, amiben az input_boolean szerint lennie kéne.
 

Keveritek itt a dolgokat rendesen. Ez egy OTA FW update az izzokra. a kontrollernek ehhez annyi koze van, hogy o tolti le az Ikea szerverekrol es telepiti over-the-air az izzokra.

A zigbee2mqtt szinten tud OTA frissitest, gyakorlatban nem tudom megmondani mennyire mukodik, mert miota atalltam nem voltak FW frissitesek.

https://www.zigbee2mqtt.io/information/ota_updates.html

A szepseghibaja, h a Tradfri izzok is kulonbozo szeriakbol valok es nem mindegyikre adta ki az Ikea a power-on behaviour FW upgrade-t. Nekem van egy szines izzom, amihez mar nem jon frissites, mert kivezettek a gyartasbol es pont nem is fogja tudni ezt. Szoval meg kell nezni a pontos tipusat az izzonak h megtudd, fogja-e tudni vagy sem.

Egyebkent ha szukseg van a power-on FW upgrade-re es a zigbee2mqtt megsem tudna a gyakorlatban az OTA upgrade-t, akkor workarondkent vissza lehet parositani a gyari gw-re majd vissza. Nyilvan macera de csak egyszer kell eljatszani (izzonkent).

ZHA is tud OTA update-t, de sosem hasznaltam, az is lehet akar jarhato ut:

https://www.home-assistant.io/integrations/zha/#ota-firmware-updates

Tudom mirol beszelsz, az Ikea Gatewaynek hivja, de nincs szukseg ra a power-on behaviourhoz. Maximum ahhoz hogy az izzo megkapja a megfelelo frissitest. Ahogy fentebb irtam

Ami kell a power-onhoz:

  • megfelelo szeriaju Tradfri izzu
  • a friss firmware (van ami a gyarbol azzal jon ki, van amit frissiteni kell)

Az izzo onnantol maga jegyzi meg, mi legyen ha elmegy es visszajon az aram, beallitani meg egy MQTT parancs:

https://www.zigbee2mqtt.io/devices/LED1545G12.html#power_on_behavior-en…