no ja teraz impulsy generuje na sterowniku funkcją PT.
Chodzi o TP? On nie generuje impulsów, a raczej stabilizuje to co ma na wejściu. Więc tak czy inaczej trzeba mu zdefiniować źródło impulsów, którym u mnie jest z-OR-owane wejście fizyczne z wyłącznika oraz zmienna %MX, która ma przypisany adres MODBUS-owy. Zmieniając stan tej zmiennej z wizualizacji steruję działaniem bloczka TP. Problem jaki powstaje przy tym sposobie sterowania to właśnie omawiana konieczność wysyłania przy każdej akcji dwóch poleceń - najpierw ustawienia rejestru na 1 a później powrót na 0.
Ogólnie nie widzę tego, aby powierzyć Rapsberry większą logikę domu.
Nie ma mowy o powierzeniu innemu urządzeniu obsługi logiki - tą zajmuje się wyłącznie Wago. Jeśli jednak chcesz wizualizację i wygodny interfejs to musisz go postawić na zewnętrznym serwerze i tutaj takie wynalazki jak miniPC sprawdzą się doskonale.
Aż się wierzyć nie chce, że na takim openhabie nie ma prostej obsługi na zasadzie "impulsów", a w zasadzie to chodzi o to, aby item mogło jednocześnie zapisywać i odczytywać modbusa, tak aby można było mieć informację o stanie światła przy wykorzystaniu włącznika na ścianie. Czy z tym problemem także sobie radziłeś w node red?
Tak, chociaż cykliczne zapytania niezbędne do prawidłowego wyświetlania aktualnych statusów bardzo zmulają komputery o mniejszej wydajności, jak np. starsze RPi czy mojego BeagleBone'a, z którego byłem zmuszony zrezygnować.
Sam sposób implementacji widać na załączonym zrzucie:
1. Odczyt dziesięciu rejestrów Modbus poczynając od 512 (tyle mam kart wyjściowych)
2. Podgląd wartości poszczególnych rejestrów w formie tablicy WORDów (wartości od 0 do 65535 czyli 16 bitów bo tyle jest wyjść na każdej karcie)
3. Funkcja wyłuskująca interesujący bit (wyjście)
4. Bloki ustawiające na wyjściu właściwości takie jak kolor czy tekst w zależności od stanu wejścia
5. Przycisk
6. Zapis rejestru odpowiadającego zmiennej sterującej dany obwód
7. Bloczek delay
8. Funkcja wymuszająca zmianę stanu rejestru na 0 po upływie czasu "delay"