Page 5 of 9

Re: Node-red vs Hapcan

Posted: 11 Nov 2018, 19:33
by Bartek
Gdyby ktoś chciał się nieco wgryźć w Node-Red i nody do Hapcana to właśnie skrobnąłem wpis na moim blogu (gdzie również opisuję cały mój system od A-Z). Można sobie poczytać po Polsku, w samym Node-Redzie help jest w języku angielskim.

https://onixarts.pl/blog/2018/11/node-r ... ib-hapcan/

pzdr;

Re: Node-red vs Hapcan

Posted: 12 Nov 2018, 22:02
by Bartek
Dobry wieczór :)

Wersja 1.2 do pobrania a w niej:
- Nowy bloczek Infrared input odczytujący dane z pilota
- Dodana możliwość wyłączenia logowania wiadomości Hapcan do konsoli

Smacznego.

Re: Node-red vs Hapcan

Posted: 10 Jan 2019, 23:01
by Bartek
Wersja 1.3 dostępna, a w niej dodana funkcja przywracania połączenia po jego utracie.
Zwłokę pomiędzy kolejnymi próbami można ustawić w parametrach połączenia.

Akurat tak się dzisiaj stało, że rano światła włączyć nie mogłem - się okazało, że połączenie z modułem Ethernet wysiadło i żaden kawałek kodu nie postarał się aby je przywrócić ;).

W Node-redzie będzie pewnie za kilka godzin.
Pozdrawiam.

Re: Node-red vs Hapcan

Posted: 12 Apr 2019, 20:16
by m.n
14 Button: ustawić temperatury termostatu to chyba jeszcze się nie da? Czy źle szukam?

Re: Node-red vs Hapcan

Posted: 12 Apr 2019, 20:27
by Bartek
Nie ma takiej funkcji, bo nie używam termostatu. W planach jest uniwersalny node umożliwiający wysłanie dowolnej ramki - to powinno rozwiązać takie braki.

Re: Node-red vs Hapcan

Posted: 10 Aug 2019, 15:44
by Bartek
Dobre wieści przynoszę, powstały nody uniwersalne do Node-reda!

W wersji 1.5, która przed chwilą została opublikowana dodaje dwa nowe klocki, Custom input i Custom output.
Za pomocą Custom output można wysyłać statyczne ramki Hapcana zdefiniowane w konfiguracji jak i dynamicznie je modyfikować za pomocą payloadu wiadomości wejściowej.
Żeby było łatwo i przyjemnie, każdemu bajtowi danych można przypisać nazwę, poprzez którą można potem wstrzykiwać odpowiednie wartości do magistrali Hapcana w odpowiednim miejscu. Do tego, wartości domyślne/statyczne z możliwością wpisania jako hex i dec, automatycznie przeliczane.
W oknie znajduje się również podgląd wysyłanej ramki.

W konfiguracji należy podać typ ramki (0x302, 0x303), która będzie wysłana. Jeśli przez przypadek wklepiecie jakiś numer ramki Hapcana, to obok pojawi się jej nazwa. Zakładam, że najlepiej posługiwać się zdefiniowanymi przez Jacka ramkami jeśli mają takie same dane i znaczenie, jak chociażby 302 - button status. Jeśli wymyślacie swoje ramki to też lepiej trzymały się "standardu" i jeśli to jest status to niech ma tą 3 z przodu, czyli np 0x350 ;).
Do sterowania urządzeniami oczywiście służy ramka sterująca 0x10A, którą również node rozpoznaje (podobnie jak ramki systemowe).

Dodatkowo, obok okienka z typem ramki jest rozwijana lista presetów, zawierająca wiele typów ramek. Po ich wybraniu w pola z nazwami pól wpiszą się odpowiednie nazwy z dokumentacji konkretnej ramki. Myślę, że jest to cool ;)
custom-node-configuration.png
Pamiętać należy, że bloczek nie przetwarza danych w ramkach, więc pomimo tego, że są one zwracane w polach o odpowiednich nazwach to maja wartości wzięte prosto z ramki Hapcana. Bloczki dedykowane robią odpowiednie konwersje, tutaj musicie o tym pamiętać aby jednak zerknąć do dokumentacji jakie wartości można wysłać i jakie są odbierane.

Na podobnej zasadzie działa też Custom input, który po wskazaniu urządzenia poprzez (node, group) oraz określeniu ewentualnego filtra typu ramki będzie wrzucał odpowiednie dane z pola, którym przypisaliście nazwy. Tutaj też jest okno z presetami.

Myślę, że teraz możliwości integracji Node-reda z Hapcanem weszły na nowy poziom nieograniczoności :D.

Smacznego, mogę iść wreszcie odpocząć :)

P.S. Trochę szkoda Jacku, że są ramki, które mają kilka znaczeń, bo tego niestety nie da się przeskoczyć robiąc uniwersalny moduł i np taki termometr, moim zdaniem, powinien zwracać osobne typy ramek dla temperatury, termostatu, regulatora temperatury i błędu, a tak każda ma 0x304 i po samym typie nie wiadomo jak intepretować dane w ramce, dopóki się ich nie sprawdzi. Może przydała by się "mała" zmiana w protokole :) włączana jakimś pstryczkiem w konfiguracji modułów, aby moduł mógł generować różne typy ramek. Można by je wtedy ładnie usystematyzować, opisać w jednym dokumencie, wszak do dyspozycji jest ponad 4000 typów :) a urządzenia wykorzystują ledwie 10.

Re: Node-red vs Hapcan

Posted: 10 Aug 2019, 20:37
by Jacek
Dzięki Bartku,
kawał dobrej roboty.
Ramki były projektowane pod niskopoziomowe programowanie, rzeczywiście na "wyższym szczeblu" mogą sprawiać trochę kłopotów...

Re: Node-red vs Hapcan

Posted: 11 Aug 2019, 15:58
by Bartek
P.S. mała popraweczka 1.5.1 - gdyby komuś nie działały nody wejściowe :oops:

Re: Node-red vs Hapcan

Posted: 09 Nov 2019, 22:07
by Bartek
Wersja 2.0!

A w niej wreszcie wyszukiwanie urządzeń na magistrali, dzięki czemu nie trzeba już pamiętać node i group. Urządzenia można wybrać w okienku konfiguracji danego bloczka i są od razu filtrowane. Tak więc wybierając bloczek obsługujący np moduł RGB na liście będą tylko znalezione urządzenia RGB.

Image

Poprawiona również obsługa uszkodzonych oraz krótszych ramek (wysyłanych przez Hapcan programmer), które powodowały zawieszenie się modułów.

Jako, że mam niewiele modułów i u mnie wykrywanie ich działa dobrze, to prosiłbym o informację, czy w przypadku większej liczby modułów działa to również poprawnie.

Re: Node-red vs Hapcan

Posted: 30 Dec 2019, 00:00
by Bartek
Wersja 2.1 powinna niebawem pojawić się w paletce Node-reda.

Główne zmiany, to dostosowanie do wymogów Node-red 1.x.x, m.in. możliwość przechwytywania zakończenia działania bloczka typu output za pomocą nowego bloczka Complete (z node-reda), poprawki działania okienek konfiguracji bloczka custom-input i custom-output.

Dodany także nowy bloczek button-output umożliwiający sterowanie diodami LED w module 14 przycisków.
node-red-hapcan-button-output.png
node-red-hapcan-button-output.png (9.59 KiB) Viewed 17221 times
Można w nim nazwać diody po imieniu i sterować nimi poprzez payload podając jsona, np:

Code: Select all

{
   "action":"toggle",
   "leds": [1, 2, "blue", "power led"]
}
Wersja 2.1 wymaga Node-red w wersji minimum 1.0. Na starszych wersjach (0.20.x) nie będzie działać.

Re: Node-red vs Hapcan

Posted: 11 Jan 2020, 23:51
by optyk
Bartek wrote:Jako, że mam niewiele modułów i u mnie wykrywanie ich działa dobrze, to prosiłbym o informację, czy w przypadku większej liczby modułów działa to również poprawnie.
Cześć,
nie wiem na ile aktualne jest pytanie, w każdym razie 34 moduły wykryło bez problemu.

optyk

Re: Node-red vs Hapcan

Posted: 19 Jan 2020, 17:55
by Bartek
Dzięki za informację :)

Re: Node-red vs Hapcan

Posted: 26 Nov 2020, 13:34
by kompio
Bartku
Czy możliwe że klocki np temp input i custom zwracają złą wartość w frame (wszędzie FF)? kiedyś mi to działało :)

Re: Node-red vs Hapcan

Posted: 26 Nov 2020, 19:49
by Bartek
Próbowałeś restartu Node-Reda?

Re: Node-red vs Hapcan

Posted: 27 Nov 2020, 07:44
by kompio
Używam node-red jest w kontenerze (docker)
wersja node-red 1.2.5, node-red-contrib-hapcan 2.2.0 (nie działa)

Uruchomiłem starą wersje na normalnym środowisku
wersja node-red 1.0.3, node-red-contrib-hapcan 1.2.0 (działa)

Uruchomiłem też tą wersje w kontenerze (docker)
wersja node-red 1.0.3-4, node-red-contrib-hapcan 1.2.0 (nie działa) :((

Dziwne że tylko ramek nie widać ...

(Pi4 Rasbian)