Dom mam postawiony na PLC i komunikuję się z HA poprzez Modbus. Chciałbym przyciskami z HA sterować wejściami/wyjściami sterownika - np. włączać światło i jednocześnie zmieniać kolor ikony (np. żarówki) gdy zmieni się stan bitu reprezentującego to światło. Aktualnie w Node-RED odczytuję po Modbusie rejestr, w którym przechowuję 16 bitów (WORD), stosuję funkcję rozbijającą WORDA na poszczególne bity i wysyłam poprzez MQTT Out, z wykorzystaniem MQTT Discovery broker tworzy encje. I tu mam pytanie - czy i jakie są Wasze doświadczenia jeżeli chodzi o takie podejście. Czy nie jest lepsze utworzenie binary sensor dla kazdego stanu i w ten sposób uzyskanie encji, która bezpośrednio będzie widoczna w HA? Czy może macie jeszcze lepszy pomysł na odczytywanie stanów i uzależnianie od nich np. kolorów ikon?
Aby powiązać sterowanie i rzeczywisty stan (feedback) w Mqtt używa się encji
switch
#mqtt:
# switch:
- unique_id: sprinkler_1
name: "Strefa 1"
state_topic: "/Sprinkler_1/zone1/State"
command_topic: "/Sprinkler_1/cmd/gpio/12"
payload_on: "1"
payload_off: "0"
state_on: "1"
state_off: "0"
availability_topic: "/Sprinkler_1/status"
payload_available: "Online"
payload_not_available: "Offline"
icon: mdi:sprinkler-variant
optimistic: false
qos: 0
retain: false
Do poprawnego działania należy wyłączyć optimistic a rzeczywisty stan pobierać ze state_topic.
Problem zaczyna się - tak jak u Ciebie - gdy statusy odbierane są grupowo jako jedna dana.
Musisz spróbować czy state_on: state_off: da się zapisać jako template wartości statusu z odpowiednia maską - tego nie wiem.
coś takiego?.. oczywiście nie bezpośredniego kopiowania:)
state_on: { value & maska);
lub robić to jak dotychczas, w NR tworząc w mgtt osobny status dla każdego switcha.
Dzięki za odpowiedź. Aktualnie mam kod funkcji który działa prawidłowo - przesyłam stany poszczególnych bitów przez MQTT i tworzę 16 encji przypisując im nazwy itd. Zastanawiam się czy to rozwiązanie optymalne i czy nie lepiej (stabilniej, szybciej) byłoby pominąć MQTT i korzystać po prostu z binary sensor czy current state dla kazdego bitu (po wyciągnieciu kazdego bitu z WORDA itd.).
Nie wiem czy dobrze rozumiem?.. ale teraz masz dwa osobne encje, jedna jako switch a druga jako status ( dla wyjść). Po co? skoro może to być tylko switch, którego kolorowy suwak może pokazywać stan.
Dla wejść to może być binary sensor z value_template: jako maska bitow np.
- binary_sensor:
- name: Entry Garage Door Sensor
state: "{{ is_state_attr('sensor.garage_entry_sensor_access_control_door_state', 'value', 23) }}"
- name: Front Door Sensor
state: "{{ is_state_attr('sensor.front_door_entry_sensor_access_control_door_state', 'value', 23) }}"
Szczegóły musisz doczytać sam bo w te klocki jestem zbyt słaby.
Dyskusja w temacie
Co lepsze to zależy co dalej będziesz z tym robił.
Raczej nie do końca się rozumiemy. Ja wyzwalam światła poprzez sterownik PLC. Przycisk w HA ma jedynie chwilowo wyzwolić bit w rejestrze, który poprzez Modbusa wysyłam do sterownika (o tym w ogóle nie piszę, bo nie w tym problem). Kolorowy suwak, czy inny wskaźnik rzeczywiście pokazuje stan, ale ten stan muszę właśnie pobrać ze sterownika, bo to on fizycznie wyzwala wyjście. Stan pobieram właśnie po modbusie - przesyłam rejestr, dekoduję go i poprzez MQTT wysyłam stany i przypisuję encje. Chodzi mi o to, czy nie lepiej byłoby pominąć MQTT i korzystać po prostu z binary sensor czy current state dla kazdego bitu (po wyciągnieciu kazdego bitu z WORDA itd.). Czy ktoś ma jakieś doświadczenia na tym polu?
Wydaje mi się, że raczej dobrze zrozumiałem 
Tak opisałeś, że wygląda to na robotę na około.
Może gdybyś dołączył więcej info jak to skonfigurowałeś byłoby łatwiej.
Lepie czy gorzej to jak zwykle zależy … 
Jeśli chcesz pominąć w ogóle mqtt i operować w HA tylko na modbus to dla encji można dopisać sekcję veryfy, jednak to generuje duży ruch ponieważ zwrotnie dla każdego zapisu wywoływany jest odczyt statusu.
# Example configuration.yaml entry
modbus:
- type: tcp
host: IP_ADDRESS
port: 502
lights:
- name: "light1"
address: 13
write_type: coil
- name: "light2"
slave: 2
address: 14
write_type: coil
verify:
- name: "Register1"
address: 11
command_on: 1
command_off: 0
verify:
input_type: holding
address: 127
state_on: 25
state_off: 1
Nie wiem dlaczego na około. Mógłbyś wyjaśnić?
W jakim celu podajesz konfigurację modbus? Ja nie mam problemu z modbusem, tylko szukam sposobu do optymalnego przesyłania stanów bitów z Node-RED do HA i tworzenie encji z tych bitów i kontroli ich stanów. Poza tym ja nie operuję na cewkach (coil) tylko całych rejestrach (holding registers) w modbusie.
Po tym stwierdzeniu już mi się odechciało i za język ciągnąć nie będę.
Przesyłam jak mam to zrobione. Chciałem skonsultować jedynie czy ktoś już robił coś podobnego i wie czy lepiej korzystać z MQTT czy funkcję WORD → send bits states via MQTT zamienić na taką, która wyrzuci bity, których stany można by kontolować za pomocą current state lub binary sensor i tworzyć encje bezpośrednio (bez brokera MQTT). Za nową funkcją wstawiłbym właśnie jeden (lub wiele - dla każdego bitu osobny) z tych dwóch bloczków. Mam nadzieję, że teraz jest to bardziej zrozumiałe.
Bardzej … to pokaż jeszcze jak jak masz zrobione wysyłanie.
Ponieważ są mechanizmy, które pozwalają utworzyć switcha wyświetlającego swój rzeczywisty stan w sposób spójny, jako jedna encja.
Tworzenie jakiś dodatkowych binary sensor to właśnie jest to “na około”.
Na co od początku usiłuje Cię naprowadzić.
Masz na myśli co jest zaszyte w funkcji WORD → send bits states via MQTT?
Dlatego jak widzisz nie zastosowałem binary sensor, tylko MQTT OUT
Jaki typ encji w HA uruchamia proces włączenia i co dzieje się dalej?
Dokładnie to?
Skoro używasz modbusa w NR, to jakoś to informacja o naciśnięciu przycisku musi się tam dostać.
Inny bit jest odpowiedzialny za reakcję na naciśnięcie, a inny reprezentuje stan wyjścia. Dzięki temu wyjście może być wywoływane z wielu miejsc.
Mqtt jest bezpieczniejsze, bo dba aby adresat otrzymał wiadomość nawet gdy w danym momencie nie ma z nim połączenia.
Gdy ustawisz retain, to gdy tylko się połączy otrzyma zaległy zasubskrybowany temat (jeśli tak sobie życzysz).
Osobiście tego swicha w HA zrobiłbym jako mqtt ( w sposób jak w pierwszym poście).
Do wysyłania w NR zasubskrybował bym temat command_topic: (zamiast ON1).
Obrobiony, odczytany w NR status przepisał do tematu state_topic:
W ten sposób nie używam w NR w ogóle nodów homeassistant.
Jest wtedy spójnie - w HA encja jest typu mqtt działająca i kompletna), a NR jest “most” modbus<>mqtt.
Drugi sposób to w HA utworzyć schitch modbusowy bez używania NR.
Ma to pewną wadę, ponieważ w HA modbus może być tylko jeden.
W Twoim odczycie statusu niepotrzebnie robisz okresowe odczyty - wystarczy połączyć zapis z odczytem i odczyt wywołać po nodzie ModusWrite
Planowałem docelowo tak to zrobić. Przycisk ON1 jest zrobiony na szybko, bo chciałem w ogóle sprawdzić czy będzie wyzwalał mi bit w sterowniku po modbusie.
Okresowo? Co masz na myśli? Bloczek inject (true) przed funkcją WORD 1?
Tak, będziesz miał oczekiwaną odpowiedź na do HA.
Klikasz przycisk i odwzorowanie stanu masz natychmiast.
Jeśli stan wyjścia może się samoistnie zmienić, to inject trzeba zostawić ale odpytywać rzadziej.
Tak by było, gdybym wyzwalał wyjście sterownika wyłącznie przyciskiem HA, a ja wyzwalam łącznikiem światła, wizualizacją sterownika i z innych miejsc.
W takim przypadku zostaw ten inject -reszta, jak napisałem wcześniej.
Jak dla mnie temat się wyczerpał.
Jak widzisz nikt w temacie się nie wypowiada, bo pytasz raczej o osobiste preferencje. Z technicznego puntu widzenia nie ma to większego znaczenia.