RTL-SDR RF vevő újratöltve

Már írtam korábban az USB-s RTLSDR vevő felhasználási lehetőségéről a rádiós eszközök adatainak begyűjtésével, a gyári Domoticz plugin használatával. Aminek annyi apró szépséghibája van/volt, hogy az egyszerű RF433 nyomógombokkal nem nagyon tudott mit kezdeni, inkább a rádiós hőmérőkre van kihegyezve.

 rtlsdr.jpg

A korábban használt rtl_433 alkalmazásra továbbra is szükségünk lesz, ha nincs még fent azon a gépen, amire az USB-s RTLSDR-t akarjuk csatlakoztatni, tegyük meg az eredeti cikkben leírtak szerint. (ez fizikailag lehet másik gépen is, vagy akár ugyanazon, amelyiken a Domoticz fut)

Az rtl_433 telepítését követően a /usr/local/etc/rtl_433/ mappában létrejött egy rtl_433.example.conf nevű beállításokat tartalmazó állomány, ezt nevezzük át rtl_433.conf-ra, az ebben tárolt beállítások a program minden indulásakor használatra kerülnek. Ez hasznos dolog, ha a FLEX dekóder segítségével akarunk jelsorozatokat felismertetni a programmal. A Flex dekóderről annyit kell tudni, hogy akkor van rá szükség, ha olyan RF433-as eszköz jelét akarjuk fogni, ami a programban szereplő körülbelül 130-féle eszközdefinícióban nem szerepel. Gyakorlatilag a legtöbb csengőkapcsoló, valamint az egyszerű mozgás és nyitásérzékelők 99%-a ebbe a kategóriába esik.
A conf fájl legnagyobb részét a használt protokollok listája teszi ki (protocol xx sorok), amiből úgy tudunk kizárni sorokat, hogy # jelet írunk elé, vagy egyszerűen töröljük azt. A végén pedig a "decoder n=..." sorok tartalmazzák a mintaként szereplő Flex dekóder számára értelmezhető sorokat, ezeket nyugodtan zárjuk ki, ha egyik eszközünket sem ismerik, minél kevesebb protocol és decoder sor van a konfigurációs állományban, annál gyorsabb a jelek értelmezése. (és a téves pozitívok száma is)
De hogyan tudjuk meg az eszközünk főbb paramétereit, ha nem vagyunk lelkes rádióamatőrök?

Az alábbi parancs indítását követően az rtl_433 megpróbálja analizálni a bejövő rádiójeleket:

rtl_433 -A

Ha valami ehhez hasonlót látunk:

Analyzing pulses...
Total count: 254, width: 363.08 ms (90770 S)
Pulse width distribution:
[ 0] count: 148, width: 912 us [896;936] ( 228 S)
[ 1] count: 14, width: 1204 us [1184;1216] ( 301 S)
[ 2] count: 92, width: 324 us [308;376] ( 81 S)
Gap width distribution:
[ 0] count: 148, width: 260 us [236;280] ( 65 S)
[ 1] count: 14, width: 4648 us [4636;4668] (1162 S)
[ 2] count: 91, width: 848 us [824;864] ( 212 S)
Pulse period distribution:
[ 0] count: 239, width: 1172 us [1164;1184] ( 293 S)
[ 1] count: 14, width: 5852 us [5852;5860] (1463 S)
Level estimates [high, low]: 15633, 2994
RSSI: -0.2 dB SNR: 7.2 dB Noise: -7.4 dB
Frequency offsets [F1, F2]: 10879, 0 (+41.5 kHz, +0.0 kHz)
Guessing modulation: Pulse Width Modulation with sync/delimiter
Attempting demodulation... short_width: 324, long_width: 912, reset_limit: 4672, sync_width: 1204
Use a flex decoder with -X 'n=name,m=OOK_PWM,s=324,l=912,r=4672,g=0,t=0,y=1204'
pulse_demod_pwm(): Analyzer Device

No akkor nyert ügyünk van, mert sikerült találnia egy olyan beállítást, amit ha bemásolunk a conf állomány végére, akkor mindig ugyanazt a számot társítja a bejövő jelhez utána, tehát tudjuk használni azonosításra.

A fenti példánál maradva a conf-ba az alábbi sort kell beilleszteni:

decoder n=EzATipusNeve,m=OOK_PWM,s=324,l=912,r=4672,g=0,t=0,y=1204

Ez után, ha futtatjuk az rtl_433 parancsot és az előző eszköz jelet ad, akkor azt jelenti majd, hogy "EzATipusNeve" modelltől kapott adatot. Több dekóder sor használata esetén természetesen egyre nagyobb a téves pozitív felismerések aránya, még az is lehet, hogy jobban járunk egy másik eszköz dekóder sorával, ami többet is felismer az eszközök közül, ez meglehetősen "próba és hiba" játék.

Ha ez a része megvan, akkor gondolkozhatunk a Domoticz felé történő adatközlésen. Az újonnan megjelent MQTT továbbítási módot használjuk, ami rugalmasabb, mint a Domoticz saját illesztője által használt "CSV kinyerése végtelen ciklusban" eljárás:

rtl_433 -F "mqtt://MQTTSZERVERIPCIME:1883,retain=0"

Ha az MQTT szerver ugyanazon a gépen van, akkor a fenti sorban egyszerűen az mqtt://localhost:1883 lesz a cím, egyébként az MQTT szerver IP címét kell behelyettesíteni a megfelelő helyre. Annyi a feladatunk, hogy a fenti parancsot valamilyen módon automatikusan indítsuk a rendszer indulásával, mivel e nélkül nem fognak érkezni az adatok...
Alapértelmezetten az "rtl_433/gépneve/events" MQTT témába küldi a jeleket, JSON formában.

Figyelem: mivel az rtl_433 programnak kizárólagos hozzáférésre van szüksége az USB tunerhez, egyidőben pontosan egy példány futhat belőle!

A Domoticz-ban ezúttal nem a gyárilag benne levő vevőt alkalmazzuk, hanem le kell tölteni egy külső Python plugint (ami fogadja a fentebb írt adatokat!), ám mielőtt használatba tudnánk venni egy - bármilyen - python plugint, érdemes az alábbi paranccsal feltelepíteni a függőségeket a Domoticz szervergépre:

sudo apt-get install python3 libpython3.6 python3-dev git

Ha ez megvan, lépjünk be a Domoticz alatti plugins könyvtárba és töltsük le a PyRTL433 plugint:

cd domoticz/plugins
git clone https://github.com/enesbcs/pyrtl433.git

Majd a Domoticz újraindítása után a hardverek között immár megtalálható a "PyRtl433 RTL-SDR MQTT receiver" eszköz: (Beállítás->Hardver)

screenshot_20190810_151205.jpg

Eszközt nem lehet és nem is kell felvenni bele, öntanuló módon felveszi azokat az eszközöket, amiket az rtl_433 lejelent erre az MQTT brókerre, megjelenik a Beállítás->Eszközök közé. (megj: ha minden szükséges eszközt megtanítottunk a pluginnek, érdemes az "Enable new device creation" opciót lekapcsolni, hagy az RF zajok ne készítsenek egy rakat felesleges eszközt)

rtl_domo_dev.jpg

Az eszköz neve a modell és flex szenzor esetén a küldött azonosító, amit átnevezhetünk a későbbiekben tetszés szerint, viszont alapértelmezetten nem engedélyezi az új eszközt, ezt kézzel kell elvégeznünk a zöld körben jobbra mutató nyílra kattintva a megfelelő soron.

Amennyiben mozgásérzékelő vagy csengőnyomógomb az eszköz, akkor a kapcsolók között, a Szerkesztés gombjára kattintva elérhetjük a beállításait:

rtl_domo_kapcs.jpg

És ezen beállítások között érdemes a "Késleltetett kikapcsolás" funkciót beállítani pl 2-3 másodpercre, mivel ezek az eszközök csak egyetlen jelet adnak: amikor aktiválják őket, ezen a módon tudjuk beállítani, hogy nyugalmi állapotba kerüljön az eszköz a jelzés vétele után, és készen álljon a következő vételére.

rtl_domo_kapcs2.jpg

Olyan nyitásérzékelő esetén, ami mindkét állapotát küldi, kicsit bonyolultabb a helyzet, bár annyiban jobb, hogy mindig tudható melyik állapotban van éppen. Ha ilyet akarunk készíteni, első lépésben vegyük fel a mind a két állapotát (Nyitott és Csukott) két külön kapcsolóként/nyomógombként késleltetett kikapcsolással, ahogy az előző példában.
Majd vegyünk fel egy Dummy hardware-t, ahogy a legelső Domoticz használatát bemutató cikkben írtam róla. (Virtuális érzékelők létrehozása)

rtl_domo_dummy.jpg

Majd a Beállítás->Több lehetőség->Felhasználói szkripteknél a + jelre kattintva hozzunk létre egy új LUA Device szkriptet az alábbi tartalommal:

commandArray = {}

for deviceName,deviceValue in pairs(devicechanged) do
    if (deviceName=='Door1-Opened') then
        if deviceValue == "On" then
            commandArray['Door1'] = "On"
        end
    end
    if (deviceName=='Door1-Closed') then
        if deviceValue == "On" then
            commandArray['Door1'] = "Off"
        end
    end
end
return commandArray

Ez annyit tesz, hogyha a Door1-Opened nevű rádiós eszköz aktiválódik, akkor a Door1 nevű virtuális eszközt Be állapotba, ha a Door1-Closed nevű aktiválódik, akkor pedig Ki állapotba kapcsolja, így a Door1 státuszában a nyitásérzékelő aktuális állapotát követhetjük, ezt az egy ikont kell felvinni a térképre az ajtó helyére.

Természetesen ugyanez a plugin tudja kezelni az RTL által ismert hőmérőket is:

rtl_domo_therm.jpg

Az eljárás még aránylag béta, erős tesztelése szükséges, illetve az RTL által közölt RSSI adatok Domoticz által elfogadható értékké konvertálása még várat magára...

A bejegyzés trackback címe:

https://bitekmindenhol.blog.hu/api/trackback/id/tr8115003902

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

HanG99 2020.01.29. 15:38:45

Sikerült-e valakinek a Sonoff RF Bridge-t ilyesmire használni?

Támogatók:
okosotthon.jpg
allterco.jpg

Utolsó kommentek

  • szenorb: Hello. Bekötöttem 12V-ra , a bemetére egy mozgás érzékelőt kötöttem. Szépen kapcsol a relé a késle... (2023.06.14. 06:48) Shelly okosrelé (Shelly1)
  • Melanoheliophobia: Üdv! Kb. 2 éve vásároltam két ugyanilyen okos izzót. Sajnos az egyik még garancia idő alatt eltávo... (2023.05.03. 16:50) Shelly Vintage okosizzó
  • eNeS: Lehetséges, bár az ESP8266-ot lassan ideje elfelejteni, ha nem helyi hálózatra akarsz vele forgalm... (2023.04.02. 08:43) Tasmota szkriptek
  • eNeS: @tomih: Thonnyban rebootot nyomva nekem se megy az NTP. De mikor lekapcsoltam a Thonnyt és rebooto... (2023.04.02. 08:40) Raspberry Pico és a LAN (W5100S-EVB-Pico)
  • krump_lee: Kedves eNeS! ESP8266 tasmota-val szenvedek, hiemq kapcsolat sehogy nem jön össze, sehol nem talál... (2023.04.02. 08:31) Tasmota szkriptek
  • Utolsó 20

Címkék

433mhz (12) alkatrész (22) alternatív kapcsoló (2) amg8833 (1) analóg (2) android (1) arduinoeasy (5) audio (1) automatizálás (3) bemenet (3) bk7231n (1) ble (1) blitzwolf (4) bluetooth (9) bridge (2) camhi (2) csináld magad (22) dimmer (1) diy (28) do-it-yourself (27) domoticz (11) ds18b20 (1) ebay (3) érintő (2) érintőkapcsoló (7) érzékelő (11) esp-01 (2) esp32 (11) esp8266 (21) espeasy (2) espurna (1) esp projekt (18) Eview7 (1) ewelink (1) feldolgozó (1) felhő (1) fényérzékelő (1) firmware (7) flame detector (1) fogyasztásmérő (5) ftdi (1) füstérzékelő (1) gázérzékelő (1) gpio (1) hang (4) hangjelző (1) hőmérséklet (22) https (1) ikea (1) impulzus relé (1) izzó (2) javascript (1) jelenlétérzékelő (3) kamera (18) keresztkapcsoló (1) kézmozdulat (1) kijelző (3) kimenet (21) konnektor (8) lan (9) lángérzékelő (2) led (3) linux (4) logic level converter (1) lua (1) lux (1) maple mini (2) mcu (3) micropython (1) mikrovezérlő (2) milkv (1) mobil (1) mosfet (1) mozgás (5) mpyeasy (4) mq-2 (2) mqtt (3) működtető rendszer (5) multiroom (1) nedvesség (1) neo (1) neopixel (1) Node-RED (1) nvr (4) nyitás (7) okosház (4) okosizzó (3) okosotthon (8) oled (1) onvif (8) openbeken (1) opencv (1) openwrt (4) orange pi (4) páratartalom (6) php (1) pico (1) pi pico (2) poe (1) programozás (9) projekt (25) proximity olvasó (1) python (2) raspberry (14) raspberry projekt (6) raspbian (1) reed (1) relé (27) rf (2) rgb (6) rock pi (1) rögzítő (2) rp2 (1) rpieasy (1) rtc (1) shelly (24) smartwise (1) solid state relay (1) sonoff (20) SonOTA (1) soros (1) ssl (1) ssr (1) stm32 (4) szenzor (11) szilárdtest relé (1) szintillesztő (2) sziréna (1) szkript (3) szünetmentesítés (4) t1 (1) tasmota (8) távirányító (3) Telegram (1) termékteszt (85) termosztát (2) touch (2) ups (5) usb (7) usb hub (1) valós idejű óra (1) vezérlések (20) vezérlő (5) világítás (5) villanykapcsoló (12) webkamera (1) wiegand (1) wifi (32) ws2812 (1) xiaomi (5) xm (4) xmeye (4) yoosee (1) zigbee (16) zwave (3) Címkefelhő
süti beállítások módosítása