Domowe IoT w rozbudowie >> centralne ogrzewanie + Arduino + BLYNK

Ciepło na żądanie czyli BLYNK steruje kotłem CO

Okres wakacyjny i pięknej wrześniowej pogody przeleciał (za)szybko. Ale są i plusy - w deszczowy dzień można poświęcić więcej czasu na procesorowe dłubactwo.

Planowana wcześniej rozbudowa "inteligencji" domowej o możliwość zdalnego sterowania gazowym kotłem centralnego ogrzewania ma więc szansę na realizację. Bez tego mój system to raczej 1/2 inteligentnego domu a może i 1/4 ( taki trochę ćwierćinteligent).
Pierwszy problem - jak sterować - jest dość oczywisty. Obecnie temperatura w domu kontrolowana jest przez prosty ale niezawodny i co najważniejsze - bezprzewodowy - termostat DIGITIME-800.

Dane techniczne też napawają optymizmem - transmisja pomiędzy termostatem a gniazdem radiowym idzie na 433,92 MHz. Ciekawe czy standardowa biblioteka <RCSwitch.h>, która dekoduje sygnały z czujki ruchu poradzi sobie z odbiorem kodu termostatu. I zobaczymy jak działa monitor uruchomiony na terminalu BLYNK w programie BRAMA2.

No proszę - jak pięknie. Kod 5592332 załącza a 5592323 wyłącza piec CO. Należy tylko wysłać te kody do gniazda od pieca i po robocie!
Ale jak przerobić ten kod na coś takiego -  elroTransmitter.sendSignal(3, 'C', onoff); zrozumiałego dla biblioteki <RemoteTransmitter.h> ?

Wewnątrz biblioteki ukryte są takie funkcje
static void sendTelegram(unsigned long data, unsigned short pin);
static void sendCode(unsigned short pin, unsigned long code, unsigned int periodusec, unsigned short repeats);
Funkcja sendCode odpada - jak wół w opisie zaznaczono że transmituje ona jedynie pierwsze 20 bitów pozostałe zaś ignoruje. A rozwiniecie binarne liczby 5592323 to 10101010101010100000011 a więc co najmniej 23 bity. Pozostaje funkcja sendTelegram tylko co zrobić z nagłówkiem synchronizacyjnym 9 bitowym.  I jeszcze w to wszystko wcisnąć liczbę powtórzeń kodu. Uff zaczyna robić się ciężko.

Może łatwiej będzie z częścią nadawczą biblioteki <RCSwitch.h>. To biblioteka przeznaczona do nadawania i odbioru kodów w postaci liczb a nie zbiorów odzwierciedlających dipswitche i klawisze na pilocie.

Użycie biblioteki <RCSwitch.h> do nadawania kodu wydaje się banalnie proste
deklaracja pinu nadajnika    mySwitch.enableTransmit(3);  (nadajnik na porcie D3)
i wysyłamy kod w kosmos  mySwitch.send("0101010101010101000000111");  kod uzupełniłem o dodatkowe 0 na początku by zgadzała się liczba bitów - 24 szt.

Wstawiam do programu BRAMA2 - i ...... kicha. Program piękne wiesza się na procedurze transmisji kodu do pieca CO. Albo  kody obu bibliotek <RCSwitch.h> i <RemoteTransmitter.h> się gryzą albo ...... nie mam pojęcia co. Trzeciej biblioteki już nie mam.

Zaczynamy więc całą zabawę  od adrema.
Po pierwsze dobrze wiedzieć co naprawdę nadaje termostat. Do tego celu świetnie nadaje się przykład ReceiveDemo_Advanced z bibloteki <RCSwitch.h>.  Sprawdzę też jak wyglądają inne kody - te z pilotów i czujek PIR.

pilot - Decimal: 5522769 (24Bit) Binary: 010101000100010101010001 Tri-State: FFF0F0FFFF0F  PulseLength: 324 microseconds Protocol: 1

termostat - Decimal: 5592323 (24Bit) Binary: 010101010101010100000011 Tri-State: FFFFFFFF0001¨ PulseLength: 209 microseconds Protocol: 1
 
czujka ruchu - Decimal: 14013756 (24Bit) Binary: 110101011101010100111100 Tri-State: 1FFF1FFF0110 PulseLength: 408 microseconds Protocol: 1

Okazuje się że są to wszystko protokoły określane jako nr 1 ale różniące się miedzy sobą długością znaku!. Każdy z kodów ma inny PulseLengtth i to różniący się w takim stopniu, że praktycznie uniemożliwia bezpośrednią współpracę tych trzech urządzeń nawet jeśli udałoby się na każdym z nich ustawić te same kody nadawczo- odbiorcze. A więc wniosek pierwszy - nasz system IoT robi tu za swoisty ruter komunikacyjny łączący pomiędzy sobą urządzenia o różnych parametrach tego samego protokołu.

Drugi wniosek to ten że obie biblioteki powinny umożliwiać wysyłanie kodów każdego z trzech rodzajów urządzeń o ile tylko znajdę sposób by dobrać się do procedury tworzenia wynikowego kodu, który potem odbierany jest przez bibliotekę <RCSwitch.h>.

Zanim sprawdzę dlaczego transmisja kodu biblioteką <RCSwitch.h>  wiesza program spróbuję jednak uruchomić wysyłanie kodów biblioteką   <RemoteTransmitter.h> - wtedy nie będę musiał przerabiać całego programu BRAMA2 zamieniając kody pilotów na odpowiadające im liczby kododwe (z "3, 'C', onoff" na 5522769). Problemy widzę co najmniej dwa - jak wysłać kod w postaci liczby i czy zmiana PulseLengtth dla kodów termostatu nie wpłynie na pracę procedury elroTransmitter.sendSignal(3, 'C', onoff);

..............................
 ........ 2 h ..............
............................... 

Po dwóch godzinach analizy i pomocy od kolegi Rosjanina wychodzi mi, że z biblioteki  <RemoteTransmitter.h> bez jej głębokiej przeróbki  nie da się wykroić transmisji dowolnego kodu. W 32 bitowym kodzie zaszyte są bowiem na stałe parametry długości impulsu i liczby powtórzeń a trudno to zmienić przed procedurą transmisji. Biblioteka <RemoteTransmitter.h> wędruje więc do kosza.

Biblioteka <RCSwitch.h> jak pisałem jest prosta w użyciu. Dodatkowo bardzo łatwo można ustawić wszystkie istotne parametry transmisji. Kod obsługujący gniazda ELRO wygląda tak

    mySwitch.setPulseLength(320); 
    mySwitch.setProtocol(1);            
    mySwitch.setRepeatTransmit(4);

   mySwitch.send(5525844, 24);

Zaś sterujący piecem CO

    mySwitch.setPulseLength(210);
    mySwitch.setProtocol(1);
    mySwitch.setRepeatTransmit(4);
   
    mySwitch.send(5592332, 24);


I po kłopocie. Wszystko śmiga aż miło więc czeka mnie odczytanie wszystkich kodów pilotów w wersji liczbowej i przeróbka całego programu BRAMA2 pod bibliotekę <RCSwitch.h>. Ale to już całkiem inna historia.


Tak więc cd niewątpliwie nastąpi .......