Krótko błyska jak wysyłam czyli kiedy nadaje
Dodam jeszcze ,że wciskałem przyciski w ciepłomierzu (choć prostowali ,że zawsze działa) , podkładałem papierek (jeden gość tak zrobił-niby za silny sygnał ....), próbowałem różnych ustawień, rozstaw diod wydaje się podobny...
Pisali na tym forum domoticza ,że musi być właściwa komenda ,żeby ciepłomierz odpowiedział...
Koledzy -dokopałem się jeszcze do takiego opisu komunikacji IR w tym ciepłomierzu :
Szybkie tłumaczenie :
"12Transmisja danych 12.1 Protokół danych MULTICAL® 402 Wewnętrzna komunikacja danych w MULTICAL® 402 jest oparta na protokole Kamstrup Meter Protocol (KMP), który zapewnia szybką i elastyczną strukturę odczytu, a także spełnia przyszłe wymagania dotyczące niezawodności danych. Protokół KMP jest używany we wszystkich licznikach zużycia Kamstrup wprowadzonych na rynek od 2006 roku. Protokół jest używany dla oka optycznego i przez wtyki wtykowe dla obszaru modułu. Tym samym moduły z m.in. Interfejs M-bus używa protokołu KMP wewnętrznie i protokołu M-bus zewnętrznie. Protokół KMP został zaprojektowany do obsługi komunikacji punkt-punkt w systemie master/slave (np. system magistrali) i służy do odczytu danych z liczników energii Kamstrup. Ochrona oprogramowania i parametrów Oprogramowanie miernika zostało zaimplementowane w technologii Flash i nie może być zmienione ani celowo, ani przez pomyłkę. Zmiana parametrów prawnych poprzez transmisję danych nie jest możliwa bez zerwania pieczęci prawnej i zwarcia „całkowitej blokady programistycznej”. Zgodność oprogramowania Suma kontrolna oprogramowania, oparta na CRC16, jest dostępna poprzez transmisję danych i na wyświetlaczu. Integralność i autentyczność danych Wszystkie parametry danych obejmują typ, jednostkę miary, współczynnik skalowania i sumę kontrolną CRC16. Każdy wyprodukowany licznik posiada unikalny numer identyfikacyjny. W komunikacji między urządzeniem nadrzędnym i podrzędnym używane są dwa różne formaty. Format ramki danych lub format potwierdzenia aplikacji. • Żądanie od urządzenia nadrzędnego do podrzędnego jest zawsze wysyłane w ramce danych • Odpowiedź od urządzenia podrzędnego może być wysłana w ramce danych lub jako potwierdzenie aplikacji Ramka danych jest oparta na modelu OSI z wykorzystaniem warstwy fizycznej, łącza danych warstwę i warstwę aplikacyjną. Liczba bajtów w każdym polu 1 1 1 0-? 2 1 Oznaczenie pola Bajt początkowy Adres docelowy CID Dane CRC Bajt stopu Warstwa aplikacji Warstwa łącza danych Warstwa łącza danych OSI – warstwa Warstwa fizyczna Protokół oparty jest na szeregowej komunikacji synchronicznej half duplex z ustawieniami: 8 bitów danych, brak parzystości i 2 bity stopu. Szybkość transmisji danych wynosi 1200 lub 2400 bodów. CRC16 jest używany zarówno w żądaniu, jak i odpowiedzi. Dane są przesyłane bajt po bajcie w formacie danych binarnych, gdzie 8 bitów danych reprezentuje jeden bajt danych. Byte Stuffing służy do rozszerzania zakresu wartości."
Tylko nie wszystko , a właściwie nie za dużo kumajet...
Ustawienia portu ok , ale jak rozumieć resztę warunków do komunikacji ?
Protokół CRC16 może tu być kluczem, czytam...
CRC to jest suma kontrolna , załóżmy ,że ten skypt wie jak ją liczyć 🙂
Mnie zastanawia to baud 1200 lub 2400 , czyli na obu zadziała?
Spróbuj wyedytować ten skrpt , i w linii 128 masz baudrate = 1200, zamien na 2400 i probuj.
A najlepiej to byś zdobył ten tool Kampsrupa ( czy jak to się pisze) i zobaczył, czy z tym Twoim ciepłomierzem wogóle da się połączyć przez IR.
ew , spróbuj też tego skryptu co przekazuje dane do mqtt ... Masz brokera mqtt ?
Migu-ten tool to chodzi Ci o skrypt pythona ? Jeśli tak , to poproszę o szybki instruktaż jak to wklejać w konsoli-nie mogę tego znaleźć jakoś...
A jeśli chodzi Ci o program na windowsa , to nie mam dostępu
Mam broker mqtt-ale tak sobie myślę jak mi nie gada po kablu , to czemu by miało zagadać po wifi ?
Cholera-grubsza sprawa...nie mam odpowiedniej wiedzy "informatycznej" ,a w tym o pythonie.
Nie wiem czy z motyką na Księżyc się nie wybrałem...
Domoticza jestem w stanie ogarnąć chyba tylko na zasadzie gotowych rozwiązań (konfiguracja , wtyczki, funkcje , itp) lub ich modyfikacji (raczej na małpę-jak ktoś pokaże )
Jeszcze rozkminiam ten zapis :
1 1 * * * /home/pi/domoticz/scripts/pyKamstrup_single.py /dev/ttyUSB1 60 21
u mnie też jest teraz usb1 , rejestr 60 jest obsługiwany , a 21 to idx-i tu jest kwach...nie dodaje mi się sprzęt kamstrupa więc nie mam np idx109 (bo ostatni jest 108).
Koło się zamyka...
kolejna kwestia gdzie wrzucać ten zapis ? po tym :
pi@smarticz:~ $
Spróbowałem zlogować co ten skrypt wysyła po wykonaniu tej komendy , no i idzie takie coś:
80 3F 10 01 00 3C B2 5F 0D
80 3F 10 01 00 50 1F 75 0D
80 3F 10 01 00 56 7F B3 0D
80 3F 10 01 00 57 6F 92 0D
80 3F 10 01 00 59 8E 5C 0D
80 3F 10 01 00 4A AC 0E 0D
80 3F 10 01 00 44 4D C0 0D
80 3F 10 01 00 8D 05 A5 0D
80 3F 10 01 00 8B 65 63 0D
80 3F 10 01 00 8C 15 84 0D
80 3F 10 01 00 8A 75 42 0D
80 3F 10 01 00 91 D6 18 0D
80 3F 10 01 00 8F 25 E7 0D
80 3F 10 01 00 95 96 9C 0D
80 3F 10 01 00 96 A6 FF 0D
80 3F 10 01 00 90 C6 39 0D
80 3F 10 01 00 8E 35 C6 0D
80 3F 10 01 00 7E DA D9 0D
80 3F 10 01 00 7C FA 9B 0D
80 3F 10 01 00 7D EA BA 0D
80 3F 10 01 00 7B 8A 7C 0D
80 3F 10 01 00 82 F4 4A 0D
80 3F 10 01 00 1B 7F D4 08 0D
80 3F 10 01 00 92 E6 7B 0D
80 3F 10 01 00 93 F6 5A 0D
80 3F 10 01 00 81 C4 29 0D
80 3F 10 01 00 7F CA F8 0D
80 3F 10 01 00 61 39 07 0D
80 3F 10 01 00 6E C8 E8 0D
80 3F 10 01 00 71 2B 36 0D
80 3F 10 01 03 EC 2C 71 0D
Więc pierwszy bajt 0x80 to jest bajt startu , 0x0D bajt stopu, i na przykładzie ostatniej komendy:
0x3F 0x10 0x01 0x03 0xEC to jest komenda ,gdzie 0x03EC to na dziesiętne jest 1004 , czyli CommandNr 1004: HourCounter , a 0x2C71 to jest CRC-16/XMODEM (można sprawdzić np na tej stronie ,że dorze policzona 🙂 https://crccalc.com/ )
Pytanie tylko , czy destination adress 0x3F i CID 0x1001 jest poprawny dla Twojego ciepłomierza. Może masz te parametry gdzieś na nim , albo na wyświetlaczu możesz sprawdzić gdzieś w opcjach , albo pojawiają się np na chwilę podczas podania napięcia do ciepłomierza ?
EDIT: Przy okazji widać , że dla tej dłuższej komendy CRC się nie zgadza (coś musiało pójść nie tak) , i ciepłomierz na taką komendęby nie odpowiedział 🙂
Jeszcze rozkminiam ten zapis :
1 1 * * * /home/pi/domoticz/scripts/pyKamstrup_single.py /dev/ttyUSB1 60 21
u mnie też jest teraz usb1 , rejestr 60 jest obsługiwany , a 21 to idx-i tu jest kwach...nie dodaje mi się sprzęt kamstrupa więc nie mam np idx109 (bo ostatni jest 108).
Koło się zamyka...
kolejna kwestia gdzie wrzucać ten zapis ? po tym :
pi@smarticz:~ $
Zostaw narazie domoticza , ciepłomierz musi odpowiedzieć jakimiś liczbami podczas tego testu , a nie same None. Jak coś odpowie , to będziemy w domu.
Migu -nie ma w ciepłomierzu żadnych parametrów do regulacji , jedynie daty i wskazania wartości
Może jest gdzieś na nim napisane , albo jak się jak się coś naciśnie ( np dłużej ) to się to wyświetli ?
Generalnie widać ,że ten skrypt jest zgodny z tym co wcześniej wiedzieliśmy ( ustawia port com na baud 1200 8N2 , wysyła m.n komendę 80 3f 10 01 00 3c b2 5f 0d , czyli tą co na samym początku prosiłem ,żebyś wysłał realtermem).
Próbowałeś przestawić skrypt na 2400 ?
Ten ciepłomierz na pewno ma IR ? Czy może jest wykastrowany o to ?
Jeśli ten destination adress 0x3F i CID 0x1001 jest poprawny dla Twojego ciepłomierza , to już niewiele można zrobić , tylko ustawić dobrze głowicę
Jak dłużej wciśniemy jeden przycisk to wchodzimy w call (chyba calibrACJA) , nie można niczego zmienić oprócz daty (wg opisu).
Port IR -diody fizycznie są , w opisach jest info ,że zawsze jest po 2006 roku (mój jest po)
Na 2400 jest to samo.
A co chodzi z tym :
destination adress 0x3F i CID 0x1001
No to zmień w tym skrypcie linię 128 na 2400 , może tą głowicę obróć o 180 stopni...
Wyłącz go z baterii czy tam z sieci , nacisnij przycisk przed testem ... Próbuj , musi coś na te komendy co skrypt wysyła odpowiedzieć.( może nie na wszystkie ,ale przynajmniej na część).
W protokole modbus jest takie coś , i to jest jakby identyfikator urządzenia. Jeśli kilka urządzeń jest w "sieci" to odpowie tylko to urządzenie , które ma taki identyfikator , stąd dobrze byłoby wiedzieć czy jest poprawne. Narazie zakładamy ,ż każdy Kampstrup ma je identyczne i niezmienialne/programowlne.
Jak wypnę go od baterii , to mogę stracić wszystkie dane-wolałbym tego nie robić.
Po co mam odwracać o 180 st jak nadajnik musi być skierowany do odbiornika (czyli dioda jasna do ciemnej) ?
Nie edytuję (nie wiem jak) skryptów-a zmieniam prędkość transmisji tylko w tym programiku realterm