Mikrokontroler EFM8 komunikuje się z ESP8285 dość prostym protokołem ładnie opisanym w dokumentacji modułu.. Nie ma tego dużo. Opis zawiera kilka komend umożliwiających nadawanie i odczyt kodów transmisji 433 MHz oraz ich zapamiętanie w pamięci mikrokontrolera. Dla celów testowania będę potrzebował jedynie dwu poleceń :
- komenda z informacją o odebranym przez EFM8 kodzie 433 MHz
- komenda żądania wysłania kodu 433 MHz o określonych parametrach
Obie komendy mają identyczną postać - różnią się jedynie wartością pola Action i oczywiście kierunkiem przesyłania
Odbiór kodów 433 MHz
Odebranie i prawidłowe zdekodowanie kodu przez EFM8 powoduje wysłanie następującej komendy do ESP8285
0xAA 0xA4 Tsync Tlow Thigh 24bit data 0x55
i sygnalizowane jest użytkownikowi króciutkim mignięciem czerwonego LEDa.
ESP powinien odpowiedzieć komendą potwierdzającą przyjęcie informacji
0xAA 0xA0 0x55
Nadawnie kodów 433 MHz
0xAA 0xA5 Tsync Tlow Thigh 24bit data 0x55
EFM8 powinien potwierdzić odebranie i wykonanie komendy
0xAA 0xA0 0x55
Dzisiejsze zadanie wydaje się banalnie proste. Potrzebuje niewielkiego programiku dla ESP, który potrafi odebrać i nadać ciąg kilku, kilkunastu bajtów. Jednak wgrywanie i testowanie oprogramowania przy wykorzystaniu oryginalnego procesora zaszytego w SONOFFie jest nieco kłopotliwie. Dużo wygodniejsze jest podmienić go czymś bardziej przyjaznym, na przykład modułem D1 MINI. Bez problemu da się połączyć EFM8 z D1 MINI trzema kabelkami (GND, Tx i Rx). Należy tylko pamiętać by przełącznik rozdzielający porty szeregowe był w pozycji OFF.
SONOFF zasiliłem z PowerBanku a D1 MINI połączony jest standardowo z komputerem. Czemu z PowerBanku? Dla bezpieczeństwa. Kiepskie zasilacza nie dają pełnej separacji napięć i może się zdarzyć, iż połączenie dwóch układów zasilanych z różnych źródeł sieci kończy się tragicznie zwłaszcza dla komputera.
Dzięki zamianie ESP8285 na D1 MINI uzyskałem pełną kontrolę nad ESP i błyskawicznie mogę podmieniać tworzone oprogramowanie.
Na początek nauczyłem się słuchać. To spora umiejętność szczególnie dla faceta.
Wysyłane przez EFM8 komendy trafiają na port Rx D1 MINI. Podgląd odbieranych komend zrobiłem dwutorowo. Odebrane dane wysyłam jednocześnie na port Tx (dzięki temu wyświetla się ona na monitorze ARDUINO IDE ) oraz na terminal BLYNKa i mam jej podgląd w telefonie. Kawałek kodu odpowiedzialny za tę operację wygląda tak
void myserialEvent() { // string z Serial
if (Serial.available()) {
int inputznak = Serial.read();
Serial.print(" ");
Serial.print(inputznak, HEX);
Serial.print(" ");
terminal.print(" ");
terminal.print(inputznak, HEX);
terminal.print(" ");
}
}
A tak wyglądają kody wysyłane przez pilota ELRO wyświetlane na monitorze Arduino IDE i terminalu BLYNKa.
Dla tego samego klawisza pilota kody różnią między sobą na pozycji 4 i 8. To oczywiste - jest to młodszy bajt wartości czasu odebranych impulsów Tsyn i Thigh i jego pomierzona przez program wartość jest różna dla kolejnych odczytów. Generalnie dla wszystkich trzech czasów zawartych w komendzie wartość na pozycji młodszego bajtu (bajt nr 4, 6, i 8) dla tego samego kodu będą się nieznacznie różnić.
Rozszyfrujmy odebrany kod
AA - bajt startu komendy
A4 - znacznik, że jest to kod odbierany
27 1A (27 24) - długość czasu trwania impulsu synchronizacji (10 010 DEC)
01 40 - długość czasu trwania impulsu 0 ( 320 DEC)
03 C0 (03 CA) - długość czasu trwania impulsu 1 ( 960 DEC)
54 55 5F - kod wysyłany przez pilota ELRO (24 bity) w HEX (5526879 DEC)
55 - bajt końca komendy
Tak na oko wszystko wygląda OK.
Porównajmy to z wartościami odczytywanymi przez bibliotekę rc-switch.h a konkretnie przez program ProtocolAnalyzeDemo.ino.
Porównajmy to z wartościami odczytywanymi przez bibliotekę rc-switch.h a konkretnie przez program ProtocolAnalyzeDemo.ino.
Dla tego samego klawisza na pilocie odczytane dane mają wartość:
Received 5526879 / 24bit Protocol: 0
data bits of pulse train duration: 31064
proposed protocol: { 324, { 1, 31 }, { 1, 3 }, { 3, 1 }, false }
====
first level down
10029
309 981 956 345 298 989 949 349 298 993 947 348 297 998 299 992
298 1000 939 350 298 995 945 353 292 998 944 349 297 999 941 354
291 1002 939 358 293 1001 937 360 934 359 931 366 933 358 938 364
283
==== czyli =====
Received 5526879 / 24bit Protocol: 0
data bits of pulse train duration: 31064
proposed protocol: { 324, { 1, 31 }, { 1, 3 }, { 3, 1 }, false }
====
first level down
10029
309 981 956 345 298 989 949 349 298 993 947 348 297 998 299 992
298 1000 939 350 298 995 945 353 292 998 944 349 297 999 941 354
291 1002 939 358 293 1001 937 360 934 359 931 366 933 358 938 364
283
==== czyli =====
impuls 0 - ok 310
impuls 1 - ok 930
impuls synchro - ok 10 000
kod 5526879
No proszę wszystko pasuje jak w zegarku. Jeśli dobrze kombinuję to wystarczy odczytać parametry kodu w rc-switch zamienić na format HEX i wysłać je komendą do EFM8. No to jedziemy
Przykład praktyczny : Przyciski w pilocie ELRO generują takie kody
A-ON >5522769<DEC >54 45 51<HEX
A-OFF >5522772<DEC >54 45 54<HEX
Program w ESP wysyła do EFM8 naprzemiennie co 3 sek komendę relON[] i relOFF[]
byte relON[] = {0xAA, 0xA5, 0x27, 0x2E, 0x01, 0x36, 0x03, 0xD4, 0x54, 0x45, 0x54, 0x55} ;
byte relOFF[] = {0xAA, 0xA5, 0x27, 0x2E, 0x01, 0x36, 0x03, 0xD4, 0x54, 0x45, 0x51, 0x55} ;
byte sw = 0;
void sendhex() {
sw = !sw;
if (sw) Serial.write(relON, sizeof(relON)); else Serial.write(relOFF, sizeof(relOFF));
}
A efekt .... co 3 sek żarówka zapala się i gaśnie ... zapala się i gaśnie ...... (zepsuła się :0).
Miało być porównanie SONOFF RF BRIDGE z biblioteką rc-switch.h ale naprawdę nie ma co porównywać. SONOFF bardzo ładnie czyta i wysyła wszystkie kody .... o ile są to kody 24 bitowe. Innych ani rusz. Drugim poważnym mankamentem jest przesyłanie do ESP ostatniego poprawnie zdekodowanego kodu z całego odebranego ciągu kodów. Kody nadawane są grupami (kod w grupie powtarzany jest n razy od 2 do 20 razy). Niektóre nadajniki kodów np. piloty ELRO pierwszy i ostatni kod w grupie fałszują z różnych przyczyn. Ale kilka kodów wewnątrz grupy jest jak najbardziej prawidłowych i one bez problemu uruchamiają bezprzewodowe gniazdo. Jeśli za prawidłowy kod uzna się pierwszy lub ostatni zdekodowany ciąg dość często jako wynik uzyskuje się całkowicie przypadkową wartość. Problem ten wystąpił z całą ostrością przy budowie mojego Routera 433 gdy tak zniekształcone grupy kodów powodowały błędne działanie urządzenia. Problem jest łatwo rozwiązywalny o ile się go dostrzeże przy tworzeniu programu. Chińscy programiści jeszcze o tym nie wiedzą?! Możliwe.
Podsumowując
SONOFF RF BRIDGE to bardzo fajne urządzenie również dla miłośników BLYNKa i to przy praktycznie bezstresowej implementacji naszego kodu do ESP8285. A że nie wszystko da się tym sterować .... to i bardzo dobrze. Inaczej domowi elektronicy musieliby szukać sobie innego hobby.
A tak jest szansa że ciąg dalszy jednak nastąpi....
127
https://github.com/Portisch/RF-Bridge-EFM8BB1
OdpowiedzUsuńDrobna uwaga odnośnie rysunku, rx z sonoffa powinien być podłącozny do tx esp, a tx do rx, a nie rx do rx i tx do tx.
OdpowiedzUsuń:0 słusznie prawisz!
OdpowiedzUsuń