Sterownik pieca Elektro-Miz cobra i komunikacja modbus

Witam.
Poszukuję specyfikacji komunikacji pomiędzy modułem Cobra i modułami zewnętrznymi w celu integracji sterownika z systemem inteligentnego domu.
Sterownik działa jako modbus master, współpracuje z modułami slave o adresach 1-32 (z czego 1-6 mają swoje reprezentacje w postaci ikon na wyświetlaczu sterownika), potrafię zmusić go do wysyłania obecnych parametrów i większość z nich potrafię odszyfrować.
Sterownik odpytuje cyklicznie slave'y o zawartości holding registers i input registers. Przypuszczam że chodzi o wersję modułu (holding registers) oraz o dane do zmiany nastawów pieca (input registers). Nie wiem tylko jak ma wyglądać odpowiedź.
Może znajdzie się ktoś posiadający przykłady odpowiedzi na przykład z modułu Spider albo Buran ?

Witam,
również poszukuję specyfikacji lub chociaż jakiejkolwiek informacji dotyczącej komunikacji sterownika/regulatora COBRA. Jak na razie nie udało mi się nic na ten temat znaleźć. Wygląda na to, iż jest to tajemnica pilnie strzeżona. W związku z tym chętnie przyłączę się do prac nad "odszyfrowaniem" protokołu którym posługuje się COBRA. Obecnie nie mam jeszcze nic czym mógłbym się podzielić ale myślę, że przykłady odpowiedzi mógłbym dostarczyć. Czy sterownik komunikuje się w formacie Modbus/RTU?

Tak. To jest protokół RTU. Cobra działa jako master, wszelkie moduły są slave'ami, dla tego sterownik może współpracować z sześcioma jednocześnie (teoretycznie z 32 ale tylko działanie 6 jest pokazywane na wyświetlaczu).
Na razie mam zrobiony odczyt bieżących parametrów. Wygląda to tak:
1. Cobra wysyła co sekundę zapytanie typu 4 (odczyt rejestru wejściowego) po kolei od aresu 1 do 32, na przykład:
003 004 000 000 000 001 048 040 (dla adresu 3)
Jeśli uzyska odpowiedź (ja wysyłam ją dwa razy - przy pojedynczym wysłaniu często nie ma reakcji. Być może chodzi o konieczną przerwę w transmisji) w której będzie:
003 004 002 054 146 086 253 - istotne są dwa bajty 054 i 146 - informuje sterownik że ma nadawać zestaw z bieżącymi parametrami. Odpowiedź 054 147 daje inny zestaw danych wyjściowych (może dla modułu Aligator?), nie znalazłem innych kombinacji.
Odpowiedzi z adresów 1 i 2, 3 i 4 oraz 5 i 6 są interpretowane jako moduły Aligator, Buran i Spider oraz powoduje wyświetlenie ikony odpowiedniego modułu na sterowniku.
2 Cobra przechodzi do nadawania statusu w postaci 20 rejestrów:
003 016 000 000 000 020 040 017 008 022 023 041 000 001 037 002 094 000 199 000 207 000 000 023 001 000 000 000 000 000 039 000 070 000 070 000 089 000 065 000 100 000 003 000 000 000 000 164 166
3. Co jakiś czas zapytuje też o 10 rejestrów i 10 rejestrów wejściowych w transmisjach:
003 003 000 000 000 010 196 078
003 004 000 001 000 010 032 047
Wtedy prawdopodobnie potrzebuje odpowiedniego zestawu danych przy użyciu których zmienia nastawy.
Ponadto brak zrozumiałej odpowiedzi powoduje po jakimś czasie miganie ikony modułu na sterowniku. Żadnych innych objawów nie zauważyłem.
Dodano po 15 [minuty]:
Rozczytałem też większość statusu 016:
003 adres urządzenia
016 rozkaz zapisu
000 000 adres 00 do zapisu w module slave
000 020 zapis 20 rejestrów
040 zapis 40 bajtów
017 rok
008 miesiąc
022 dzień
023 godzina
041 minuta
000 sekunda
001 037 temperatura CO (29,3) dla wszystkich temperatur temperaturę obliczamy jako (pierwszy bajt*256+drugi bajt)/10
002 094 temperatura CWU (60,6)
000 199 temperatura podajnika (19,9)
000 207 temperatura powrotu (20,7)
000 000 ??
023 001 ?? liczba zmienia się przy zmianie różnych ustawień. Nie rozpracowałem jeszcze tego.
000 000 aktualna moc wentylatora (na dugim bajcie)
000 000 praca sterownika (na drugim bajcie: 000 = OFF, 008 = ON)
000 039 nastawa CO (039=OFF, inna liczba to nastawa w stopniach)
000 070 nastawa CWU (039=OFF, inna liczba to nastawa w stopniach)
000 070 chyba jest to temperatura do jakiej dąży w danej chwili sterownik
000 089 tryb pracy automatyki (89=PID, 105=ADC, 73=OFF)
000 065 czas przerwy podajnika
000 100 maksymalna moc wentylatora
000 003 minimalna moc pieca
000 000 ??
000 000 ??
164 166 suma kontrolna


Teraz trzeba by było dowiedzieć się jak konstruować odpowiedzi na zapytania 03 i 04. Prawdopodobnie nie są to te same dane które nadawane są przy użyciu komendy 16. Wydaje mi się że jedna z odpowiedzi powinna zawierać wersję oprogramowania modułu. Nadawanie losowych danych nie zadziałało. Mógłbym sekwencyjnie wysłać po kolei wszystkie kombinacje, ale trwałoby to za długo i zanim bym się zorientował że komenda odniosła skutek, nie wiedziałbym która z nich zadziałała. Fajnie by było mieć zapis podsłuchu Modbusa z komunikacji sterownika z modułem. Ja nie mam dostępu do żadnego modułu więc nie mam jak tego dokonać.

Jeśli będziesz potrzebować kodu dla Arduino do zaimplementowania protokołu, mam już gotowy program więc mogę wyłuskać z niego odpowiednie fragmenty. Przypuszczam że całość z obsługą wyświetlacza Nextion nie będzie przydatna.

Wykonałeś kawał bardzo dobrej roboty! Z pewnością wielu ułatwi to życie, a na pewno mnie. Bardzo dziękuję.

Jak znalazłeś te "istotne dwa bajty 054 i 146" dla odpowiedzi spod adresu 003?

Z pewnością zapis monitoringu komunikacji z modułami rozszerzeń pozwoli łatwiej i szybciej pogłębić znajomość języka COBRY. Niestety z tego co rozumiem, moduł Buran nigdy nie wyszedł na rynek. Od wielu lat próbuję go kupić. Komunikacja z nim dałaby wiele cennej informacji. Obecnie dostępne na rynku są tylko Aligator i Spider GSM.

W chwili obecnej nie mam fizycznego dostępu do mojej COBRY. Wyślę prywatną wiadomość z propozycją jak mógłbym pomóc. Za kod dla Arduino na razie bardzo dziękuję. Myślę, że podepnę się z PC przez konwerter USB-RS485 i wykorzystam dostępne skanery, parsery itp.

To akurat było proste. Cobra pytała o jeden rejestr więc puściłem w pętli odpowiedź na każde zapytanie ze strony Cobry, za każdym razem zwiększając odsyłaną wartość o 1. Było 65536 możliwych kombinacji, ich nadanie trwałoby niecałą dobę. po kilku godzinach zobaczyłem że Cobra zaczęła odsyłać dane, dość szybko ustaliłem który kod powoduje reakcję. Potem poszło już z górki.

Też kiedyś szukałem Burana, ale w sumie nie jest on konieczny. Przydałby się Spider. Oczywiście zawsze mogę wprowadzić w programie cykliczne wysyłanie odpowiedzi na zapytania Cobry podobne do tego które wykonałem na początku. Tym razem Cobra prosi o 20 bajtów danych więc potrwa to kilka miesięcy, ale nie wiem jaki będzie efekt tych działań. Nie chcę żeby się okazało że podczas pracy piec dostanie dziwne parametry i zgłupieje. Na razie się na to nie zdecydowałem i tylko korzystam z pobierania danych z pieca i wyświetlania ich na wyświetlaczu w pokoju.

W przypadku gdyby denerwowało Cię miganie ikonki modułu na wyświetlaczu, wystarczy żeby podłączyć się jako slave o adresie powyżej 6. Nie będzie żadnej ikony.

KonJarek napisał:

W przypadku gdyby denerwowało Cię miganie ikonki modułu na wyświetlaczu, wystarczy żeby podłączyć się jako slave o adresie powyżej 6. Nie będzie żadnej ikony.

Czy te "istotne dwa bajty 054 i 146" sprawdzają się przy odpowiedzi od każdego slavea?

Ten inny zestaw danych wyjściowych COBRY otrzymywany w odpowiedzi na 054 147 też rozszyfrowałeś?

Komunikat dla drugiego zestawu wygląda tak:

001 adres slave'a
016 rodzaj komunikatu
000 000 adres pierwszego rejestru
000 040 ilość rejestrów
080 ilość bajtów
000
000
001 215 T CO (47,4)
001 105 T CWU (36,1)
000 194 T podajnika (19,4)
001 153 T powrotu (40,9)
000 002
000 039 T CO=OFF
000 070 T CWU = 79
000 000
000 001 ??
043 052 ??
056 000 ??
000 000
000 000
000 000
000 000
000 000
000 000
043 052 ??
000 000
043 052 ??
056 000 ??
000 000
000 000
000 000
000 000
000 000
000 000
043 052 ??
000 000
043 052 ??
056 000 ??
000 000
000 000
000 000
000 000
000 000
000 000
047 000 ??
000 000
9F 99 CRC


Nie mam pojęcia co oznaczają te parametry, ale może służą do sterowania zarowem

Jednak myliłem się. Ten drugi zestaw parametrów nie służy do komunikacji z zaworem tylko z modułem Spider.

Moduły pracują w Modbus RTU, z prędkością 9600.
Komunikacja wygląda tak:

1. Cobra wysyła zapytanie o rejestr z adresu 0:
005 004 000 000 000 001 048 078
Spider odpowiada podając kod 054 147:
005 004 002 054 147 031 061

2. Cobra odpytuje o wersję i status modemu (adresy 1-9):
005 004 000 001 000 008 161 136
Spider odpowiada:
005 004 016 000 212 000 000 000 000 000 000 000 000 000 002 000 015 000 000 057 128
gdzie:
005-adres modułu
004 - typ komunikatu Modbus
016 - ilość zwracanych bajtów
000 212 - wersja 2.12
000 000 Zmiana nastawy CO
000 000 Zmiana nastawy CWU
000 000 1=start
000 000 1=stop
000 002 - status modemu (001 - inicjalizacja, 002-błąd SIM, 003-błąd PIN, 004-logowanie, 005-zalogowany, 006-błąd SMS)
000 015 - poziom sygnału GSM
000 000 - ?
057 128 - CRC

Zwrot tego komunikatu ze zmienioną temperaturą nastawy CO, CWU lub zmiana start/stop powoduje zmianę ustawień Cobry.

3. Cobra zapisuje parametry do modułu
005 016 000 000 000 040 080 000 000 002 172 002 158 000 255 001 003 000 002 000 039 000 080 000 000 000 001 043 052 056 XXX XXX XXX XXX XXX XXX XXX XXX XXX 000 000 000 000 043 052 000 000 043 052 056 049 049 049 049 049 049 049 049 049 048 000 000 000 043 052 000 000 043 052 056 057 057 057 057 057 057 057 057 057 057 000 000 000 068 000 000 000 112 134
gdzie:
005-adres modułu
016 - typ komunikatu Modbus
000 000 - adres pierwszego rejestru
040 080 - 40 rejestrów, 80 bajtów
000 000 - Kody błędów (opis na dole)
002 172 - temperatura CO
002 158 - temperatura CWU
000 255 - temperatura podajnika
001 003 - remperatura powrotu
000 002 - status termostatu pokojowego (0 - wyłączony, 1 - włączony, 2 - nie działa)
000 039 - ustawiona temperatura CO
000 080 - ustawiona temperatura CWU
000 000 - czy sterownik jest włączony (000 001 - włączony)
000 001 - czy sterownik jest wyłączony (działa na zmianę z poprzednim rejestrem - tylko jeden z nich jest ustawiony na "1")
043 052 056 XXX XXX XXX XXX XXX XXX XXX XXX XXX 000 - numer pierwszego telefonu zapisany w ASCII
000 000 000 043 052 000 000 - ??
043 052 056 049 049 049 049 049 049 049 049 049 048 000 - numer drugiego telefonu zapisany w ASCII (tutaj +481111111110)
000 000 043 052 000 000 - ??
043 052 056 057 057 057 057 057 057 057 057 057 057 000 - numer trzeciego telefonu zapisany w ASCII (tutaj +489999999999)
000 000 - ??
068 - temperatura pieca w stopniach (bez części ułamkowej)
000 000 000 - ??
112 134 - CRC

Kody błędów są w postaci flag. W pierwszym bajcie może być ustawionych 5 młodszych bitów, w drugim bajcie wszystkie 8. Ustawienie kilku bitów spowoduje wysłanie w tekście wszystkich ustawionych alarmów.
pierwszy bajt:
bit 1 (1) - Duży prąd podajnika
bit 2 (2) - Dużu prąd pompy CWU
bit 3 (4) - Duży prąd pompy CO
bit 4 (8) - Duży prąd zapalarki
bit 5 (16) - Duży prąd dmuchawy

drugi bajt:
bit 1 (1) - Wysoka temp. kotła
bit 2 (2) - Pożar kosza
bit 3 (4) - Alarm STB
bit 4 (8) - Blokada podajnika
bit 5 (16) - Brak opału
bit 6 (32) - Otwarty kosz
bit 7 (64) - Odpopielanie
bit 8 (128) - Awaria czujnika temperatury

Spider potwierdza zapisanie danych:
005 016 000 000 000 040 193 147

4. Cobra odpytuje o 40 rejestrów (pierwszy adres 0):
005 003 000 000 000 040 068 172
Spider odpowiada:
005 003 080 000 000 002 166 002 157 000 244 001 132 000 002 000 039 000 080 000 000 000 001 043 052 056 XXX XXX XXX XXX XXX XXX XXX XXX XXX 000 000 000 000 043 052 000 000 043 052 056 049 049 049 049 049 049 049 049 049 048 000 000 000 043 052 000 000 043 052 056 057 057 057 057 057 057 057 057 057 057 000 000 000 067 000 000 000 242 018
gdzie:
005 - adres modułu
003 - typ komunikatu modbus
080 - ilość zwracanych bajtów
000 000 - ??
002 166 - temperatura CO
002 157 - temperatura CWU
000 244 - temeratura podajnika
001 132 - temperatura powrotu
000 002 - status termostatu pokojowego
000 039 - ustawiona temperatura CO
000 080 - ustawiona temperatura CWU
000 000 - czy sterownik jest włączony (000 001 - włączony)
000 001 - czy sterownik jest wyłączony (działa na zmianę z poprzednim rejestrem - tylko jeden z nich jest ustawiony na "1")
043 052 056 XXX XXX XXX XXX XXX XXX XXX XXX XXX 000 - pierwszy telefon
000 000 000 043 052 000 000 - ??
043 052 056 049 049 049 049 049 049 049 049 049 048 000 - drugi telefon
000 000 043 052 000 000 - ???
043 052 056 057 057 057 057 057 057 057 057 057 057 000 - trzeci telefon
000 - ???
000 067 - temperatura CO w pełnych stopniach
000 000 000 - ??
242 018 - CRC

W przypadku braku komunikacji dłużej niż przez minutę, moduł wysyła komunikaty ostatnich błędów oraz alarm "brak komunikacji ze sterownikiem"

To chyba wszystko co da się wyciągnąć z tego urządzenia

Przy komunikacji z Cobrą bardzo istotne są czasy odpowiedzi. Opóźnienie rzędu 100ms może spowodować odrzucenie wysyłanego komunikatu. Po nadaniu trzeba też dodać trochę czasu zanim przełączymy się na odbiór. Przy komunikacji z Arduino ustawiam 10ms opóźnienia przed nadawaniem i 100ms na końcu, zanim przełączę moduł na odbiór.

Niesamowite ile udało Ci się zrobić w tak krótkim czasie. BARDZO dziękuję!

KonJarek napisał:

...
3. Cobra zapisuje parametry do modułu
...
002 172 - temperatura CO
002 158 - temperatura CWU
000 255 - temperatura podajnika
001 003 - temperatura powrotu
...


Spider potwierdza zapisanie danych:
005 016 000 000 000 040 193 147


4. Cobra odpytuje o 40 rejestrów (pierwszy adres 0):
005 003 000 000 000 040 068 172
Spider odpowiada:
...
002 166 - temperatura CO
002 157 - temperatura CWU
000 244 - temperatura podajnika
001 132 - temperatura powrotu
...

Jest różnica między danymi, które Cobra wysłała do zapisu w module Spider a danymi, po potwierdzeniu zapisu przez Spidera, które on wysyła w odpowiedzi na odpytanie Cobry. Czy dane zwracane przez moduł po zapisie nie powinny być identyczne z tymi które były podane do zapisu?

Czy różnica ta jest tylko w przykładzie czy występuje również w rzeczywistości?

Dodano po 17 [minuty]:

KonJarek napisał:

Po nadaniu trzeba też dodać trochę czasu zanim przełączymy się na odbiór. Przy krótkich komunikatach ustawiam 10ms opóźnienia przed nadawaniem i 100ms na końcu, zanim przełączę moduł na odbiór.

Zakładam, że piszesz o przełączaniu się na odbiór przez moduł, np. Spider. Nie bardzo rozumiem dlaczego zbyt wczesne przełączenie się na odbiór, nawet natychmiastowe, po nadaniu odpowiedzi do Cobry, czyli mastera, mogłoby coś popsuć w komunikacji. Dla tego przykładu nie rozumiem dlaczego musisz czekać 100ms na końcu, czyli po nadaniu komunikatu do mastera.

Ustawiasz 10ms opóźnienia przed nadawaniem (czyli po odebraniu komunikatu z mastera) przy krótkich komunikatach. Czy chodzi o krótkie komunikaty otrzymane z mastera, czy krótkie wysyłane do mastera?

Przy dłuższych komunikatach używasz innego opóźnienia?

Przedstawione sekwencje nie stanowią zwięzłej całości. Należy traktować je osobno, jako przykładowe.

Pisałem o przełączeniu się na odbiór nie przez Spidera tylko przez moduł łączący komputer z magistralą RS485. W moim przypadku był to coś takiego: http://yourduino.com/sunshop//index.php?l=product_detail&p=323
Większość modułów używanych do komunikacji komputera z RS485 wymaga jakiegoś opóźnienia pomiędzy przełączeniem trybu pracy a transmisją. W moim przypadku na 100% konieczne było dodanie opóźnienia pomiędzy nadawaniem a przełączeniem się na odbiór (po przesłaniu danych do bufora modułu potrzebny był czas na przekazanie transmisji przez RS485 a przełączenie modułu na odbiór przerywa nadawanie). Nie stwierdziłem na 100% czy konieczne jest dodanie opóźnienia pomiędzy przełączeniem na nadawanie a wysłaniem transmisji, ale bez tego opóźnienia Cobra rzadziej odczytywała transmisję (dłużej trwało prawidłowe przesłanie danych). Na pewno przy tak ustawionych opóźnieniach transmisja przebiega prawidłowo pomimo tego że mam czasem problem z zakłóceniami spowodowanymi długim, łączonym kablem.

To z krótkimi komunikatami było pomyłką (chodziło o nadawane komunikaty z Arduino do Spidera lub Cobry). Ustawienie 10ms pomiędzy przełączeniem na nadawanie a transmisją i 100ms pomiędzy końcem nadawania a przełączeniem na odbiór stosuję przy wszystkich nadawanych komunikatach. Poprawiłem opis w poprzednim poście żeby nie powodował już nieścisłości.

No i wszystko jasne dlaczego niezbędne okazały się opóźnienia. Dzięki za wyjaśnienia.
Komunikacja została starannie opisana pod kątem wykonania programu, z wykorzystaniem MAX485, a ja próbowałem zrozumieć ją z punktu zachowania się sygnałów na szynie Modbus .

Pod kątem szyny Modbus można to opisać w prosty sposób:

Master - Cobra lub Puma
Slave - Spider (adres 5)
baudrate 9600

1. Nawiązanie komunikacji
M - Zapytanie slave'ów od numeru 1 do 32 o 1 rejestr wejściowy z adresu 0 (funkcja 4)
S - Odpowiedź zwracająca wartość 054 147
2. Zapytanie o status GSM i zmiany parametrów pieca
M - Zapytanie o 8 rejestrów wejściowych zaczynając od adresu 1 (funkcja 4)
S - Odpowiedź (na przykład 005 004 016 000 212 000 000 000 000 000 000 000 000 000 002 000 015 000 000 057 128)
3. Wysłanie parametrów pieca i ustawień telefonów do Spidera
M - wysłanie 40 rejestrów zaczynając od adresu 0 (funkcja 16)
S - potwierdzenie zapisania 40 rejestrów
4. Odebranie aktualnie zapisanych w Spiderze parametrów pieca
M - zapytanie o 40 rejestrów zaczynając od adresu 0 (funkcja 3)
S - Odpowiedź zwracająca 80 bajtów



Do podtrzymania połączenia pomiędzy urządzeniami konieczna jest cykliczna transmisja z punktu 2. Bez niej moduły stwierdzają brak połączenia.

Do sterowania piecem potrzebne są komunikaty z punktu 2 (nadawanie nastaw do pieca) i 3 (odbieranie aktualnych nastaw i temperatur z pieca)

Zastanawiałem się czy nie prościej byłoby, w module łączącym Arduino z magistralą RS485, na stałe włączyć odbiór, tzn. podać aktywny sygnał na Receiver Enable (RE), i tylko przy nadawaniu aktywować Driver Enable (DE). W tym przypadku co prawda Arduino odbiera wszystko co jest na szynie Modbus, czyli także echo tego co sam nadaje, ale mogłoby to być nawet korzystne. Arduino w tym przypadku nigdy nie zgubi żadnego komunikatu na szynie, a słuchając swojego echa wie dokładnie kiedy fizycznie skończył nadawać. Z opóźnień pozostałoby tylko to wymagane przez specyfikacje Modbus, tzn. po odbiorze komunikatu adresowanego do niego, Arduino musiałoby odczekać min. 3,5 znaki Modbus. Jeśli byłoby wygodniej, to zamiast timera, można byłoby w tym celu wysłać 4 bajty dowolnych danych bez aktywacji drivera (DE). Własne echo jeśli nie potrzebne łatwo odrzucić.

Nie wiem jak ten moduł jest podłączony do Arduino, ale przypuszczam, że powinno być to możliwe.

Dodano po 8 [minuty]:

KonJarek napisał:

Do sterowania piecem potrzebne są komunikaty z punktu 2 (nadawanie nastaw do pieca) i 3 (odbieranie aktualnych nastaw i temperatur z pieca)

Czy w tym przypadku master (Cobra) nie wykonuje jeszcze zawsze punktu 4, tzn. czy nie odpytuje "aktualnie zapisanych w Spiderze parametrów pieca" i czy nie powinny one być dokładnie takie jak te z punktu 3?

Panowie, strasznie czarujecie.
To że w sterowniku miga ikona jest to skutkiem błędnej komunikacji aplikacja<-->sterownik.
Sterownik po ustalonym czasie stwierdza brak komunikacji co skutkuje miganiem (ostrzeganiem) usera o możliwej awarii modułu.

Aby uzyskać stablilną komunikację, i tutaj nie mam dla Was dobrych wieści, trzeba popchać odpowiedni "kod" na odpowiednich rejestrach.
Jakiś czas temu miałem zestawioną komunikację PC<->Cobra z moim softem. Działało to jakieś 2 lata. Projekt został zrealizowany prawie w 95%.
Działało chyba poza nastawami dla 3D/4D wszystko.
Niesty szczegółów komunikacji zdradzić nie mogę ale mogę nakierować/pomóc w tym temacie

Akurat używając takiego protokołu komunikacji jak opisałem powyżej, Cobra nie podnosi alarmu o braku komunikacji. Wystarczy że otrzymuje odpowiednie odpowiedzi na wysyłane komunikaty.
Nie musisz podawać szczegółów skoro są takie tajne. Wszystkie potrzebne dane są już podane w obecnym wątku bo nie widzę powodu do robienia z tego takiej tajemnicy. Zapewniam że wszystko pięknie działa. Używam tego na zrobionym samodzielnie panelu.

Janiszew: nie zauważyłem wcześniej Twoich pytań, dla tego dopiero teraz odpowiem:
komunikacja dwustronna jest konieczna po to żeby Cobra widziała podłączony prawidłowo moduł, nie mówiąc już o wysyłaniu nastaw. Od biedy jeśli komuś wystarczą informacje z Cobry na przykład do wyświetlania na panelu obecnej temperatury pieca, można przymknąć oko na migający alarm i odbierać komplet danych z transmisji przeznaczonej dla modułu Buran (054 146). Zanim nie użyczyłeś mi swojego modułu Spider, używałem tego do wyświetlania temperatur na panelu pokojowym.

Co do drugiego pytania, to odpowiedź z takimi samymi parametrami jest podczas normalnej pracy pieca. Dopiero zmiana nastaw powoduje różnicę w tych punktach, co jest oznaką że piec jeszcze nie zakończył zmiany nastaw. Gdy informacje z punktu 3 i 4 są znów zbieżne, Spider ustawia ponownie zera w odpowiedzi z punktu 2 i w ten sposób następuje zakończenie procedury zmiany nastaw.

Damian_lisu napisał:

Panowie, strasznie czarujecie.
To że w sterowniku miga ikona jest to skutkiem błędnej komunikacji aplikacja<-->sterownik.
Sterownik po ustalonym czasie stwierdza brak komunikacji co skutkuje miganiem (ostrzeganiem) usera o możliwej awarii modułu.

Aby uzyskać stablilną komunikację, i tutaj nie mam dla Was dobrych wieści, trzeba popchać odpowiedni "kod" na odpowiednich rejestrach.
Jakiś czas temu miałem zestawioną komunikację PC<->Cobra z moim softem. Działało to jakieś 2 lata. Projekt został zrealizowany prawie w 95%.
Działało chyba poza nastawami dla 3D/4D wszystko.
Niesty szczegółów komunikacji zdradzić nie mogę ale mogę nakierować/pomóc w tym temacie

Mimo szczerych chęci, niestety nie udało mi się znaleźć żadnej wartości dodanej w tym poście, a szkoda .
Jeśli faktycznie możesz w czymś pomóc lub choćby nakierować, to nie krępuj się i po prostu to zrób dla społeczności elektroda.pl.
Wszystko co się udało do tej pory "wyczarować" jest wyłączną zasługą KonJarek. Jestem głęboko przekonany, że jest to jedyny zasób wiedzy w tym temacie udostępniony bezinteresownie dla innych. Bardzo chciałbym się mylić.

KonJarek napisał:

Jednak myliłem się. Ten drugi zestaw parametrów nie służy do komunikacji z zaworem tylko z modułem Spider.

Moduły pracują w Modbus RTU, z prędkością 9600.
Komunikacja wygląda tak:

1. Cobra wysyła zapytanie o rejestr z adresu 0:
005 004 000 000 000 001 048 078
Spider odpowiada podając kod 054 147:
005 004 002 054 147 031 061

2. Cobra odpytuje o wersję i status modemu (adresy 1-9):
005 004 000 001 000 008 161 136
Spider odpowiada:
005 004 016 000 212 000 000 000 000 000 000 000 000 000 002 000 015 000 000 057 128
gdzie:
005-adres modułu
004 - typ komunikatu Modbus
016 - ilość zwracanych bajtów
000 212 - wersja 2.12
000 000 Zmiana nastawy CO
000 000 Zmiana nastawy CWU
000 000 1=start
000 000 1=stop
000 002 - status modemu (001 - inicjalizacja, 002-błąd SIM, 003-błąd PIN, 004-logowanie, 005-zalogowany, 006-błąd SMS)
000 015 - poziom sygnału GSM
000 000 - ?
057 128 - CRC

Zwrot tego komunikatu ze zmienioną temperaturą nastawy CO, CWU lub zmiana start/stop powoduje zmianę ustawień Cobry.

3. Cobra zapisuje parametry do modułu
005 016 000 000 000 040 080 000 000 002 172 002 158 000 255 001 003 000 002 000 039 000 080 000 000 000 001 043 052 056 XXX XXX XXX XXX XXX XXX XXX XXX XXX 000 000 000 000 043 052 000 000 043 052 056 049 049 049 049 049 049 049 049 049 048 000 000 000 043 052 000 000 043 052 056 057 057 057 057 057 057 057 057 057 057 000 000 000 068 000 000 000 112 134
gdzie:
005-adres modułu
016 - typ komunikatu Modbus
000 000 - adres pierwszego rejestru
040 080 - 40 rejestrów, 80 bajtów
000 000 - Kody błędów (opis na dole)
002 172 - temperatura CO
002 158 - temperatura CWU
000 255 - temperatura podajnika
001 003 - remperatura powrotu
000 002 - status termostatu pokojowego (0 - wyłączony, 1 - włączony, 2 - nie działa)
000 039 - ustawiona temperatura CO
000 080 - ustawiona temperatura CWU
000 000 - czy sterownik jest włączony (000 001 - włączony)
000 001 - czy sterownik jest wyłączony (działa na zmianę z poprzednim rejestrem - tylko jeden z nich jest ustawiony na "1")
043 052 056 XXX XXX XXX XXX XXX XXX XXX XXX XXX 000 - numer pierwszego telefonu zapisany w ASCII
000 000 000 043 052 000 000 - ??
043 052 056 049 049 049 049 049 049 049 049 049 048 000 - numer drugiego telefonu zapisany w ASCII (tutaj +481111111110)
000 000 043 052 000 000 - ??
043 052 056 057 057 057 057 057 057 057 057 057 057 000 - numer trzeciego telefonu zapisany w ASCII (tutaj +489999999999)
000 000 - ??
068 - temperatura pieca w stopniach (bez części ułamkowej)
000 000 000 - ??
112 134 - CRC

Kody błędów są w postaci flag. W pierwszym bajcie może być ustawionych 5 młodszych bitów, w drugim bajcie wszystkie 8. Ustawienie kilku bitów spowoduje wysłanie w tekście wszystkich ustawionych alarmów.
pierwszy bajt:
bit 1 (1) - Duży prąd podajnika
bit 2 (2) - Dużu prąd pompy CWU
bit 3 (4) - Duży prąd pompy CO
bit 4 (8) - Duży prąd zapalarki
bit 5 (16) - Duży prąd dmuchawy

drugi bajt:
bit 1 (1) - Wysoka temp. kotła
bit 2 (2) - Pożar kosza
bit 3 (4) - Alarm STB
bit 4 (8) - Blokada podajnika
bit 5 (16) - Brak opału
bit 6 (32) - Otwarty kosz
bit 7 (64) - Odpopielanie
bit 8 (128) - Awaria czujnika temperatury

Spider potwierdza zapisanie danych:
005 016 000 000 000 040 193 147

4. Cobra odpytuje o 40 rejestrów (pierwszy adres 0):
005 003 000 000 000 040 068 172
Spider odpowiada:
005 003 080 000 000 002 166 002 157 000 244 001 132 000 002 000 039 000 080 000 000 000 001 043 052 056 XXX XXX XXX XXX XXX XXX XXX XXX XXX 000 000 000 000 043 052 000 000 043 052 056 049 049 049 049 049 049 049 049 049 048 000 000 000 043 052 000 000 043 052 056 057 057 057 057 057 057 057 057 057 057 000 000 000 067 000 000 000 242 018
gdzie:
005 - adres modułu
003 - typ komunikatu modbus
080 - ilość zwracanych bajtów
000 000 - ??
002 166 - temperatura CO
002 157 - temperatura CWU
000 244 - temeratura podajnika
001 132 - temperatura powrotu
000 002 - status termostatu pokojowego
000 039 - ustawiona temperatura CO
000 080 - ustawiona temperatura CWU
000 000 - czy sterownik jest włączony (000 001 - włączony)
000 001 - czy sterownik jest wyłączony (działa na zmianę z poprzednim rejestrem - tylko jeden z nich jest ustawiony na "1")
043 052 056 XXX XXX XXX XXX XXX XXX XXX XXX XXX 000 - pierwszy telefon
000 000 000 043 052 000 000 - ??
043 052 056 049 049 049 049 049 049 049 049 049 048 000 - drugi telefon
000 000 043 052 000 000 - ???
043 052 056 057 057 057 057 057 057 057 057 057 057 000 - trzeci telefon
000 - ???
000 067 - temperatura CO w pełnych stopniach
000 000 000 - ??
242 018 - CRC

W przypadku braku komunikacji dłużej niż przez minutę, moduł wysyła komunikaty ostatnich błędów oraz alarm "brak komunikacji ze sterownikiem"

To chyba wszystko co da się wyciągnąć z tego urządzenia

Przy komunikacji z Cobrą bardzo istotne są czasy odpowiedzi. Opóźnienie rzędu 100ms może spowodować odrzucenie wysyłanego komunikatu. Po nadaniu trzeba też dodać trochę czasu zanim przełączymy się na odbiór. Przy komunikacji z Arduino ustawiam 10ms opóźnienia przed nadawaniem i 100ms na końcu, zanim przełączę moduł na odbiór.

Witam. Czy za pomocą arduino udało się sterować piecem? Jeżeli tak to w jaki sposób? Za pomocą przycisków? Jakieś aplikacji czy z komputera? Zastanawiałem się czy nie dało by rady podłączyć go pod suplę i sterowac, lub przynajmniej podglądać temperaturę.

Udało się w takim zakresie w jakim można sterować przy użyciu modułu Spider - ustawianie temperatur, włączenie/wyłączenie kotła. Podgląd parametrów jest w znacznie szerszym zakresie - da się odczytać wszystko to co opisałem w sentencji 016. Do komunikacji potrzebny jest moduł RS-485. Wystarczy napisać program który będzie potwierdzać odebranie komunikatów typu 003 i 004, odbierze i potwierdzi komunikat typu 016, sprawdzi sumę kontrolną i po jej potwierdzeniu wybierze z komunikatu potrzebne dane i przekaże je na wyświetlacz albo do komputera. Można też napisać program na komputer a moduł RS-485 podłączyć przez konwerter USB-TTL bez pośrednictwa Arduino. Ja używam Arduino bo chcę żeby wszystko wyświetlało się na czymś w rodzaju sterownika pokojowego.

Czy próbowałeś wystawić to na stronę www i kontrolować temperaturę + sterować nastawami zdalnie? Jest szansa żebyś wstawił program wgrany do arduino? Bym był baaardzo wdzięczny

Na stronę nie próbowałem ale raczej jest to wykonalne. Już umieszczam na WUnderground dane pogodowe z Arduino i ściągam do niego prognozę pogody z Weather.com. Najwygodniej jest to robić przez WIFI modułem ESP8266 albo zamiast Arduino użyć zintegrowanego z WIFI komputerka ESP031.
Cały program którym testowałem połączenie z Cobrą na nic Ci się nie zda, bo bez wyświetlacza Nextion nie będzie działać. Spróbuję wyłuskać najważniejsze elementy które sobie wmontujesz we własny program. Ogólnie nie jest to żadna technika rakietowa - wszystko polega na komunikacji po porcie szeregowym.

Super.
Zamówiłem ESP8266 NodeMcu V3. Jak wyłuskasz co trzeba to zobaczymy czy sobie z tym poradzę

Tak mniej więcej wyglądał mój program testowy. Nie jestem pewien czy nie ma w nim teraz błędów bo wycinałem z niego obsługę panelu HMI. Nie mam teraz czasu żeby go przetestować. Używa dwóch portów szeregowych więc przydatne jest arduino większe niż UNO / pro mini. Ja używałem Mega 2560.




bool cobrareceived=false;
const byte nrsterownika=5;
unsigned long t;
byte buforspider[80];
byte cobra[100];
byte bufor[100];
byte bufor2[100];byte cobralength=0;
byte zmienna1=0x36;
byte zmienna2=0x92;//0x93 - parametry dla modułu Spider, 0x92 - rozszerzone parametry pieca
uint16_t crc;
void setup() {
Serial.begin(115200);//PC
Serial2.begin(9600);//RS485
pinMode(3,OUTPUT);//RS485 R W
digitalWrite(3,LOW);
};

void loop() {
while(Serial2.available()){
t=millis();
receive=true;
newsign=true;
bufor[bufpos]=Serial2.read();
bufpos++;
if(bufpos>6){
switch (bufor[1]){
case 3:
cobralength=8;
break;
case 4:
cobralength=8;
break;
case 16:
cobralength=9+bufor[6];
break;
default:
break;
}
if(bufpos==cobralength){
crc=CRC16(bufor,bufpos-2);
if((bufor[bufpos-2]==(crc&0xFF))&&(bufor[bufpos-1]==(crc>>8))){
if(bufor[0]==nrsterownika){
for(byte i=0;i<cobralength;i++){
if(bufor[i]<100){
Serial.print("0");
}
if(bufor[i]<10){
Serial.print("0");
}
Serial.print(bufor[i]);
Serial.print(" ");
}
Serial.print(" CRC OK");
cobrareceived=true;
}
if(bufor[1]==16){
for (byte i=0;i<80;i++){
buforspider[i]=bufor[7+i];
}
Serial.println("\n\rbufor wypelniony");
mamdane=true;
}
}else{
for(byte i=0;i<cobralength;i++){
if(bufor[i]<100){
Serial.print("0");
}
if(bufor[i]<10){
Serial.print("0");
}
Serial.print(bufor[i]);
Serial.print(" ");
}
Serial.print(" CRC BAD, should be ");
cobrareceived=true;
Serial.print(crc&0xFF);
Serial.print(":");
Serial.print(crc>>8);
}
if(bufpos>0){
bufpos=0;
cobralength=0;
Serial.println();
}
}
}
}
if(cobrareceived){
switch(bufor[1]){
case 3:
if(mamdane){
digitalWrite(3,HIGH);
delay(10);
bufor2[0]=bufor[0];
bufor2[1]=0x03;
bufor2[2]=80;
for(byte i=0;i<80;i++){
bufor2[3+i]=buforspider[i];
}
bufor2[83]=(CRC16(bufor2,83)&0xFF);
bufor2[84]=(CRC16(bufor2,83)>>8);
Serial.print("\r\nsend: ");
for( byte i=0;i<85;i++){
if(bufor2[i]<100){
Serial.print("0");
}
if(bufor2[i]<10){
Serial.print("0");
}
Serial.print(bufor2[i]);
Serial2.write(bufor2[i]);
Serial.print(" ");
}
Serial.println();
delay(100);
digitalWrite(3,LOW);
}
break;
case 4:
if(bufor[3]==0){
digitalWrite(3,HIGH);
delay(10);
bufor2[0]=bufor[0];
bufor2[1]=(0x04);
bufor2[2]=(0x02);
bufor2[3]=(zmienna1);
bufor2[4]=(zmienna2);
bufor2[5]=(CRC16(bufor2,5)&0xFF);
bufor2[6]=(CRC16(bufor2,5)>>8);
delay(100);
Serial.print("\r\nsend: ");
for( byte i=0;i<7;i++){
if(bufor2[i]<100){
Serial.print("0");
}
if(bufor2[i]<10){
Serial.print("0");
}
Serial.print(bufor2[i]);
Serial2.write(bufor2[i]);
Serial.print(" ");
}

Serial.println();
delay(100);
digitalWrite(3,LOW);
}
if(bufor[3]==1){
digitalWrite(3,HIGH);
delay(10);
bufor2[0]=bufor[0];
bufor2[1]=0x04;
bufor2[2]=16;
bufor2[3]=0;
bufor2[4]=101;
bufor2[5]=0;
bufor2[6]=0;
bufor2[7]=0;
if(mamdane&&buforspider[15]==65){
bufor2[8]=80;
}else{
bufor2[8]=0;
}
bufor2[9]=0;
bufor2[10]=0;
bufor2[11]=0;
bufor2[12]=0;
bufor2[13]=0;
bufor2[14]=5;
bufor2[15]=0;
bufor2[16]=25;
bufor2[17]=0;
bufor2[18]=0;
bufor2[19]=(CRC16(bufor2,19)&0xFF);
bufor2[20]=(CRC16(bufor2,19)>>8);
Serial.print("\r\nsend: ");
for( byte i=0;i<21;i++){
Serial.print(bufor2[i]);
Serial2.write(bufor2[i]);
Serial.print(" ");
}
delay(100);
digitalWrite(3,LOW);
Serial.println();
}

break;
case 10:
break;
case 16:
// z=bufor[6];
for(byte j=0;j<bufor[6];j++){
cobra[j]=bufor[j+7];
}
wypisz();
digitalWrite(3,HIGH);
delay(100);
bufor2[0]=bufor[0];
bufor2[1]=(0x10);
bufor2[2]=(0x00);
bufor2[3]=(0x00);
bufor2[4]=(0x00);
bufor2[5]=bufor[5];
bufor2[6]=(CRC16(bufor2,6)&0xFF);
bufor2[7]=(CRC16(bufor2,6)>>8);
Serial.print("\r\nsend: ");
for( byte i=0;i<8;i++){
Serial.print(bufor2[i]);
Serial2.write(bufor2[i]);
Serial.print(" ");
}
Serial.println();
delay(6);
digitalWrite(3,LOW);
break;
}
cobrareceived=false;
}


if(((millis()-t)>600)&&(receive)){
// Serial.println("<<timeout>>");
receive=false;
bufpos=0;
cobralength=0;
}
}

uint16_t CRC16(byte buf[], int len)
{
uint16_t crc = 0xFFFF;

for (int pos = 0; pos < len; pos++)
{
crc ^= (uint16_t)buf[pos]; // XOR byte into least sig. byte of crc

for (int i = 8; i != 0; i--) { // Loop over each bit
if ((crc & 0x0001) != 0) { // If the LSB is set
crc >>= 1; // Shift right and XOR 0xA001
crc ^= 0xA001;
}
else // Else LSB is not set
crc >>= 1; // Just shift right
}
}
// Note, this number has low and high bytes swapped, so use it accordingly (or swap bytes)
return crc;
}
void wypisz(){
float pomoc;
Serial.print("parametry sterownika :");
Serial.print("\n\rData: ");Serial.print(cobra[0]);Serial.print("/");Serial.print(cobra[1]);Serial.print("/");Serial.print(cobra[2]);Serial.print(" ");
Serial.print("\n\rCzas ");Serial.print(cobra[3]);Serial.print(":");Serial.print(cobra[4]);Serial.print(":");Serial.print(cobra[5]);Serial.print(" ");
pomoc=cobra[6]*256+cobra[7];
Serial.print("\n\rTemp. CO ");Serial.print(pomoc/10);
pomoc=cobra[8]*256+cobra[9];
Serial.print("\n\rTemp. CWU ");Serial.print(pomoc/10);
pomoc=cobra[10]*256+cobra[11];
Serial.print("\n\rTemp. pod. ");Serial.print(pomoc/10);
pomoc=cobra[12]*256+cobra[13];
Serial.print("\n\rTemp. powr. ");Serial.print(pomoc/10);
Serial.print("\n\r???? ");Serial.print(cobra[14]);
Serial.print("\n\r???? ");Serial.print(cobra[15]);
Serial.print("\n\r???? ");Serial.print(cobra[16]);
Serial.print("\n\r???? ");Serial.print(cobra[17]);
Serial.print("\n\r???? ");Serial.print(cobra[18]);
Serial.print("\n\rnadmuch ");Serial.print(cobra[19]);
Serial.print("\n\r???? ");Serial.print(cobra[20]);
if((cobra[21]&0b1000)==0b1000){
Serial.print("\n\rSterownik ON");
}else{
Serial.print("\n\rSterownik OFF");
}
if((cobra[21]!=0)&&(cobra[21]!=8)){
Serial.print(" wartosc nieznana :");
Serial.print(cobra[21]);
}
Serial.print("\n\r???? ");Serial.print(cobra[22]);
if(cobra[23]>39){
Serial.print("\n\rTemp. CO ");Serial.print(cobra[23]);
}else{
Serial.print("\n\rCO OFF");
}
Serial.print("\n\r???? ");Serial.print(cobra[24]);
if(cobra[25]>39){
Serial.print("\n\rTemp. CWU ");Serial.print(cobra[25]);
}else{
Serial.print("\n\rCWU OFF");
}
Serial.print("\n\r???? ");Serial.print(cobra[26]);
Serial.print("\n\r???? ");Serial.print(cobra[27]);
Serial.print("\n\r???? ");Serial.print(cobra[28]);
Serial.print("\n\rtryb PID ");
if((cobra[29]&0b01110000)==0b01000000){
Serial.print("OFF ");
}
if((cobra[29]&0b01110000)==0b01010000){
Serial.print("PID ");
}
if((cobra[29]&0b01110000)==0b01100000){
Serial.print("ADC ");
}
if((cobra[29]!=105)&&(cobra[29]!=89)&&(cobra[29]!=73)){
Serial.print(" wartosc nieznana :");
Serial.print(cobra[29]);
}
Serial.print("\n\r???? ");Serial.print(cobra[30]);
Serial.print("\n\rprzerwa podajnika ");Serial.print(cobra[31]);
Serial.print("\n\r???? ");Serial.print(cobra[32]);
Serial.print("\n\rmax. pred. went. ");Serial.print(cobra[33]);
Serial.print("\n\r???? ");Serial.print(cobra[34]);
Serial.print("\n\rmin. moc pieca ");Serial.print(cobra[35]);
Serial.print("\n\r???? ");Serial.print(cobra[36]);
Serial.print("\n\r???? ");Serial.print(cobra[37]);
Serial.print("\n\r???? ");Serial.print(cobra[38]);
Serial.print("\n\r???? ");Serial.print(cobra[39]);
}

Dodano po 16 [minuty]:

Co do ESP 8266 to trzeba zastosować następujące kody AT:

"AT" - sprawdzenie czy jest połączenie z modułem. Powinien odpowiedzieć "OK"
"AT+CIPMUX=0" - ustawnienie trybu pojedynczego połączenia. Powinien odpowiedzieć "OK". Na razie nie próbowałem jeszcze pracować w trybie multi, ale biorąc pod uwagę że mój komputerek odczytuje czas z NTP, wysyła dane pogodowe i odbiera prognozy, może kiedyś skorzystam z multi.
"AT+CWMODE=1" - ustawienie trybu klienta. Powinien odpowiedzieć "OK". Jeśli odpowie "link is builded", oznacza że już jest połączony.
"AT+CWJAP=\"" SSID "\",\"" hasło "\"" - połączenie z routerem. Powinien odpowiedzieć "OK"
"AT+CIPSTART=\"TCP\",\"wxdata.weather.com\",80" - połączenie, w moim przypadku z Weather.com. Powinien odpowiedzieć "OK"
"AT+CIPSEND=110" - podanie długości danych do transmisji. Powinien odpowiedzieć ">"
"GET /wxdata/weather/local/PLXX6385?cc=%2A&unit=m&dayf=2&locale=pl HTTP/1.1\r\nHost: wxdata.weather.com\r\n\r\n" - zapytanie o dane ze strony. Po przesłaniu czekamy na odpowiedź zaczynającą się od "+IPD"

Wystarczy przesłać odpowiednie komendy i czekać na odpowiedzi albo na informacje o błędach. W ESP mogą być różne firmware'y więc komendy i odpowiedzi mogą się trochę różnić.

Wielkie dzięki. Może coś uda mi się z tego zrobić. Arduino Mega idzie już z Chin.

witam,

przepraszam za mój zły polski, ale mieszkam w Niemczech i używam tłumacza google.
Kupiłem grzejnik na pelety z PUMA PID i jestem z tego bardzo zadowolony. Niestety w Niemczech obowiązkowe jest posiadanie zbiornika buforowego o pojemności co najmniej 1000 litrów podczas ogrzewania za pomocą pelletu. Ale teraz jest tak, że PUMA PID zawsze utrzymuje odpowiednią temperaturę czajnika i nie chcę tego. Szukam sposobu na wyłączenie PUMA PID bez wyciągania wtyczki.

Powyższy protokół wygląda jednak inaczej niż mój. Dostępna jest pamięć USB z MAX485, Arduinos i Raspberry PI. Byłbym zainteresowany rozwiązaniem w Pythonie tutaj.


Dziękuję za poświęcony czas

Pozdrawiam Michał