Może ktoś pomoże.
Potrzebuje zrobić Stan dostępności dla wentylatora MQTT zależny od załączenia do niego zasilania przez włącznik ścienny
encja: light.wentylator
…taki zapis działa i nie jest ważne skąd pobiera stan dostępności
W twoim zapisie też pewnie by działał, jakbyś odwoływał się do stanu przełącznika a nie do stanu tego samego wentylatora?
Zwykły, niezwykły… chciałem zasugerować, że w Twoim zapisie dostępność wenylatora próbujesz ustawić na postawie stanu wentylatora (czyli samego siebie) - zamiast stanu wyłączka.
Tak rozumiem ten zapis.
No nie.
Prąd do samego modułu wentylatora (RF 433MHz) sufitowego jest załączany przez włącznik ścienny - jest prąd do wentylatora jest wyłączony to moduł nie jest zasilany więc teoretycznie jest offline, a że jest to tylko moduł RF odbiorczy to nie znamy jego stanu, więc chce stan jego dostępności ustawić za pomocą włącznika ściennego.
Ok… pogubiłem się co jest co.
light.wentylator to fizycznie które urządzenie?
Konstrukcja availability_template: >… którego dotycz?
Sposób osiągnięcia efektu jest dla mnie zrozumiał i poprawny.
light.wentylator - włącznik ścienny załączający zasilanie do modułu wentylatora FAN RF
availability_template - dotyczy urządzenia FAN RF przez MQTT
Chciałbym ustawić availibility urządzeniu FAN RF korzystając ze stanu urządzenia light.wentylator:
jeśli state jest ON to FAN RF jest offline
jeśli state jest OFF to FAN RF jest offline
Obstaje przy swoim, już tak robiłem tylko pobierałem avaliliblity z tematu mqtt stanu innego urządzenia.
Nigdy nie pobierałem bezpośrednio z HA i nie wiem czy taka metoda zadziała?
W twoim przypadku powinno działać coś takiego
availability:
- topic: "nie byle co tylko temat stanu włacznika ściennego"
payload_available: "on"
payload_not_available: "off"
niestety to za mało bo włącznik ścienny na danym temacie MQTT nie wyrzuca samego stanu tylko JSONa, dlatego potrzebny jest jeszcze template do wyciągnięcia w tym przypadku stanu POWER2
Zacznijmy od początku.
Wpadłeś w pułapkę zasady działania MQTT i własnych wyobrażeń.
W MQTT, to nie czujnik odczytuje zawartość tematu tylko broker publikuje dane i to on jest inicjatorem.
Z tego powodu ta część kodu nigdy się nie wykona
ponieważ temat “byle/co” nie istnieje i nigdy nie będzie istniał.
Od początku sugeruje aby
jednak próba odczytu stanu
value_template: “{{ states(‘light.wentylator’) }}”
może być hazardowa, ponieważ na ten sam temat wyłącznik ścienny mógł jeszcze nie zareagować i otrzymasz stan poprzedni.
Więc bardziej poprawnym byłoby
ponieważ otrzymasz dane z pierwszej ręki, a nie pośrednika.
Dokładnie tak samo jak zdefiniowałeś w odczycie stanu przełącznika ściennego.
Drugim sposobem jest zmiana dostępności wentylatora w kodzie samego wyłącznika np. przez automatyzację.
Nie cierpię składni HA i do końca jej nie czuję, więc ta co jest w wąsach { } może być nie do końca właściwe.
Ten twój pierwszy sposób też już wcześniej próbowałem i teraz ponownie - sprawdzacz nie zgłasza błędów, ale niestety stan się nie zmienia i wentylator FAN RF jest teraz ciągle offline
(bez parametrów availibility wszystko działa w FAN RF)
Sprawdziłem w szablonach że poprawnie jest wyciągana wartość “POWER2”.
Odnośnie sposobu drugiego, to wiem że mógłbym sobie dodać rolę publikującą nowy stan dla konkretnego gang’u, ale próbuje to rozwiązać w HA także dla kolejnych urządzeń RF, a nie ustawiać coś w poszczególnych urządzeniach załączających zasilanie do nich.
Wiodącym jest “Napowietrzacz” i jego stan aktualizuje stan dostępności “Fake”
Problem jest tak, że wybrałeś niewłaściwy topic: “tele/Salon_2_D2DFCE/STATE” publikowany jest okresowo z czasem Telemetry period (300)
Więc zmień topic albo czekaj 5min na aktualizację.
Do czasu jak nie pokażesz całej konfiguracji męcz się sam.
Skoro masz tasmotę to na pewno masz takie tematy, jeśli nie ma - to wykonaj przełączenie i się pojawią
Czyli tele, cmnd i stat
Operowanie na temacie tele to nie jest dobry pomysł. Pojawia się on jak pisałem wcześniej, okresowo zgodnie z
Więc rzeczywisty stan przekaźnika otrzymujesz co telemery period.
Pracujesz w trybie optimistic więc wydaje ci się, że przekaźnik się przełączył - a wcale tak być nie musi i o faktyczny stanie się dowiesz dopiero np. po 3 min.
Nie chce mi się dużo rozpisywać więc sprawdź to co wrzucę i wtedy ewentualnie pytaj.
Wydaję mi się, że po poprawnym sformatowaniu teksu powinno zaskoczyć od razu.
- platform: mqtt
name: Wentylator
state_topic: stat/Salon_2_D2DFCE/POWER2
command_topic: cmnd/Salon_2_D2DFCE/POWER2
availability_topic: tele/Salon_2_D2DFCE/LWT
payload_on: "ON"
payload_off: "OFF"
state_on: "ON"
state_off: "OFF"
payload_available: Online
payload_not_available: Offline
optimistic: false #stan swicha na panelu na podstawie info zwrotnego o rzeczywistm stanie przekaźnika
qos: 1
retain: false
- platform: mqtt
name: "Wentylator sufitowy"
#state_topic: 'tele/RF_Bridge/RESULT'
command_topic: 'cmnd/RF_Bridge/RfCode'
availability_topic: "stat/Salon_2_D2DFCE/POWER2"
payload_available: "ON"
payload_not_available: "OFF"
optimistic: true #stan optymistyczny, bez kanału zwrotnego
percentage_command_topic: 'cmnd/RF_Bridge/RfCode'
percentage_command_template: >
{% if value < 5 %}
#EE254E#
{% elif value < 34 %}
#E8204B#
{% elif value < 67 %}
#EC274D#
{% else %}
#D11E7A#
{% endif %}
qos: 1
payload_on: "#E8204B#"
payload_off: "#EE254E#"
preset_mode_command_topic: "cmnd/RF_Bridge/RfCode"
preset_mode_command_template: >
{% if value == "1h" %}
#EE254E#
{% elif value == "4h" %}
#E8204B#
{% elif value == "8h" %}
#EC274D#
{% endif %}
preset_modes:
- "1h"
- "4h"
- "8h"
akurat stan Teleperiod jest do przesyłania statutu sensorów a nie stanów Relay i Light.
Rzeczywiście zapomniałem o tym drzewie “stat” - używając go oczywiście ruszyło ,bo dane wejściowe nie musiały być specjalnie wyciągane - DZIĘKI.
Pozostaje kwestia dlaczego parametr “value_template” dla urzadzeń MQTT nie obrabia/wyciąga danych wejściowych z topicu
