Nazywam się Łukasz i chciałbym odświeżyć temat openHAB (OH) jak i samych bibliotek programistycznych dla hapcan. Piszę, ponieważ udało mi się uporządkować kilka rzeczy związanych z obsługą magistrali CAN. Biblioteka Apache PLC4X, w której rozwijam obsługę CAN dla Javy pozwoli wkrótce na oddzielną implementację protokołu i transportu CAN. Na chwilę obecną zmiany oczekują na wejście do projektu (https://github.com/apache/plc4x/compare ... ck-tunning) no i oczywiście dokumentację.
Kluczowe tutaj jest to, że komunikacja do CAN będzie mogła iść przez ETHERNET/USB/RS232 a protokół aplikacyjny tj. mapowanie identyfikatora, flagi rtr (jeśli wykorzystywana) oraz sekcji danych będzie od tego niezależny. Myślę że zaoszczędzi to sporo pracy przy obsłudze różnych metod łączenia do magistrali, które na chwilę obecną obsługuje hapcan. Sam do swoich celów wykorzystuję prosty adapter CAN 2.0a/USB z bootlanda, który jest obsługiwany pod linuxem przez socketcan.
Piszę o tym wszystkim, ponieważ w ramach swoich własnych prac rozwojowych i weryfikacji zmian architektonicznych biblioteki planowałem zaimplementować obsługę protokołu slcan/serial line can. Jest to protokół ASCII używany/rozpropagowany przez firmę Lewicell min. w ich adapterze can232. Opis samego protokołu jest dostępny online: www.can232.com/docs/can232_v3.pdf. Moją główną intencją było/jest odblokowanie użycia biblioteki i obsługi protokołu CANopen (tj. protokół warstwy aplikacji oparty o CANbus) pod Windows, w tym także odpalenie openHABa z obsługą CAN pod Windows. Nie wiem czy na tym forum jest wiele osób które korzystają z openHAB i Windowsa. Jeśli ktoś tu jest to ręka do góry.
Kilka słów na temat samej biblioteki PLC4X. Jest ona pisana głównie w Javie, aczkolwiek pozwala na wygenerowanie z opisu protokołu źródeł w c oraz go. Jest to spore uproszczenie przy utrzymaniu zgodności np. serwera w C i klienta w Javie. W ten sposób, tak długo jak są budowane z jednego deskryptora, powinny być ze sobą zgodne. Wiem, że spora część firmware jest w asemblerze a oprogramowanie narzędziowe w Delphi(?)/C#. Niestety tutaj raczej rzeczona biblioteka nie pomoże, chyba że ktoś zainwestuje swój cenny czas w napisanie szablonu do generatora. Oprócz samego generatora projekt oferuje również API dla klienta tj. aplikacji która chce skorzystać z protokołu jak i SPI dla programisty który takowy chce zaimplementować.
W linku do PR na githubie oprócz samych zmian w obsłudze transportów jest "generyczny driver can". Pozwala on na mapowanie sekcji danych ramki do pól, które klient później może odczytywać. Obsługiwana "rozdzielczość" pola to 1 bit, czyli można spokojnie obsłużyć 8 kanałowy przekaźnik, który koduje się jako sekwencja 8 bitów (a nie np. int). Driver ten planuję w nadchodzących miesiącach spiąć z openHABem do obsługi najprostszych integracji. Sprawdzi się on tam, gdzie jest stały identyfikator oraz struktura ramki (np. raportowanie napięcia z BMS/battery management system). Nie jest to coś, co w znaczny sposób uprości integrację z hapcanem, ale przynajmniej pozwoli na bezpośrednią komunikację OH oraz CAN.
Teraz, aby ogarnąć od początku hapcan pod OH, wydaje mi się że potrzebnych jest kilka rzeczy:
1) Opis protokołu zdatny do generowania kodu - wiem, że ramki nie zmieniają się bardzo często, ale przepisywanie tego do każdego języka i biblioteki nastręcza trudności.
2) Implementacja logiki protokołu (np. operacji typu żądanie/odpowiedź jeśli występują) oraz zmapowanie na struktury logiczne tj. moduł, wejścia/wyjścia itp.
3) Implementacja transportu do adaptera/adapterów hapcan.
4) Implementacja bindingu w oparciu o powyższą bibliotekę/protokół.
Trudność powyższych rzeczy jest zależna tak na prawdę od złożoności protokołu. Im więcej operacji i wariacji tym więcej pracy. Przyznam, że nie wczytywałem się jeszcze w protokół hapcana, także nie jestem w stanie ocenić potrzebnych nakładów. Sprawdzałem jakiś czas temu binding, który był opublikowany pod OH 2.4 i jest on w porządku, aczkolwiek wymaga znacznego odświeżenia aby móc działać z OH 2.5 nie wspominając o 3.0 i 3.1. Każda z tych wersji jest niezgodna ze sobą z różnych powodów. Wersja 2.4 i 2.5 była pod zamierzchłą wersję frameworku z pakietami org.eclipse.smarthome, który nie jest już rozwijany. 3.0 korzysta z pakietów org.openhab.core a wersja 3.1 zmienia obsługę jednostek miar i wag z pakietu javax.measure (jest to dość znacząca zależność). W rezultacie dodatek hapcana trzeba skompilować od nowa.
Jako, że zajmuję się "wdrażaniem" openhaba, pisaniem i publikowaniem dodatków do OH w swojej działalności gospodarczej to nie mam problemów z tym aby zrobić to samodzielnie. Ze względu na chroniczny brak czasu mogę a nawet wolę wesprzeć kompetencyjnie kogoś, kto chciałby się tego podejąć. Większość kodu, który piszę publikuję na licencji Apache 2.0, która jest bardziej liberalna niż GPL na którym jest publikowany hapcan. Nadmienię, że nie posiadam instalacji hapcana, w sumie to chyba nie planuję jej mieć. Chciałbym jednak żeby obsługa CAN w OH przestała być pasmem niekończących się nieszczęść a wasz projekt w końcu dorobił się należytej integracji!
Pytania zasadnicze do społeczności:
Jak integrujecie się z hapcanem, z czym macie najwięcej zachodu. Jak wygląda utrzymanie Waszego rozwiązania i czy zapatrujecie się na zmiany lub ulepszenia. Być może rozwiązanie, które zbudowaliście jest po prostu satysfakcjonujące.
Jak dużą instalację chcecie obsłużyć i jak wiele rzeczy chcecie zautomatyzować (np. wykrywanie adaptera hapcan/usb, hapcan/ethernet, wykrywanie węzłów, wykrywanie kanałów).
Pozdrawiam serdecznie,
Łukasz