Vad är OpenMQTTGateway, en ny 433Mhz Gateway?

Nu kanske OpenMQTTGateway inte är en nyhet för många. Men vi hade helt missat projektet! Efter att ha läst om projektet så beställde i hårdvara för att bygga en egen gateway, vi hade ganska höga förhoppningar om projektet och vad den kan lösa. Vi ville ersätta vår befintliga 433Mhz lösning med RFXtrx som idag sitter kopplad till Home Assistant.

Inlägget senast uppdaterat: 2023-05-18 – Uppgradera till större antenn.

Veckan efter vi publicerade den här bloggposten så annonserade Telldus (2023-04-07) att dom kommer börja ta betalt för både API och schema läggning. Nu ska vi vara tydlig med att det även går att uppgradera till en premium plan hos Telldus och fortsätta som idag med. Men söker du ett enklare alternativ för att ersätta Telldus och slippa månadskostnaden, samtidigt som du kan behålla 433Mhz enheter, då kan den här lösningen med OpenMQTTGateway var något för dig.

Den RFXtrx vi använder är uteslutande för att hämtat data från en väderstationen via 433Mhz frekvensen. Sedan har vi haft presentation av det datat i Home Assistant under lång tid. Vi har tyvärr en del problem med räckvidden på 433Mhz, något som det här projektet kan lösa.

Nu tyckte vi att en lösning som totalt kostade oss ~250kr inte är allt för farligt, speciellt om vi får in 433Mhz enheter helt fristående, det var svårt att motstå. Att vi dessutom löser räckviddsproblemet och kan avveckla RFXtrx blev en bonus.

Detta var möjligt genom att OpenMQTTGateway blir en brygga för 433Mhz, den i sin tur nyttja WIFI för att skicka data till Home Assistant . Vilket gör att vi kan placera den vart som helst med WIFI täckning, något som ej varit möjligt med RFXtrx eftersom den sitter inkopplad via USB.

Meny

• OpenMQTTGateway för 433Mhz enheter
• Kom igång med Openmqttgateway och Home Assistant
• OpenMQTTGateway i Home Assistant
• OpenMQTTGateway och hårdvara
• Felsöka enheter i OpenMQTTGateway
• Skal till LILYGO och OpenMQTTGateway
• RFXtrx vs openMQTTGateway
• Så kan du kan minska bruset på MQTT
• Byta antenn på LILYGO
• Rekommenderad läsning
• Loggbok
• Stort tack

OpenMQTTGateway för 433Mhz enheter

Är du intresserad av att kunna bygga den här lösningen från start till mål med Home Assistant? Då kan du följa vår guide Guide för nybörjare med fokus på Home Assistant och Homey – Där hittar du steg för steg hur du sätter upp alla delar som behövs i Home Assistant. Efter det kan du fortsätta med det här inlägget.

Vi beställde en LILYGO esp32 från AliExpress för någon månad sedan med ett Lora chip (länk längre ner i inlägget), vilket krävs för det här projektet. För dom som följer oss på Instagram (extern länk) så delade vi för en tid sedan att vi köpte 2st pycom lora moduler, vilket ej går att nyttja till den här lösningen. Nu är tanken med dessa ett annat Lora projekt, dom har dessutom ”rätt” Lora frekvens på 868Mhz.

Bakgrunden till varför vi blev så intresserade av lösningen var att det nu räcker med en enda ESP32 för att både ta emot och tolka signalen, något som tidigare krävde RFXtrx eller prestandan av en Raspberry PI med SDR (software defined radio), i praktiken en tv mottagare på USB. Lösningen med Raspberry PI var både dyr och gav dessutom inte de resultat vi önskade, så den är redan avvecklad.

Med just den ESP32 från LILYGO så har Lora chippet vi köpte den Asiatiska frekvensen på 433Mhz. Men lång historia kort så kan ett esp32 chip med den här Lora frekvensen och chippet ”dekoda” och helt avlasta tolkningen av 433mhz från processorn i ESP32:an. Vilket gör att esp32:an klarar att agera gateway och tolk samtidigt! Vi kan med den både skicka och ta emot dessutom. Nu har vi hört många som har haft bekymmer med Telldus och sökt alternativ för 433Mhz, och här kanske vi har en vettig lösning med.

Gillar du den här typen av teknik så glöm inte att prenumerera på inlägg från bloggen nedan och följa oss på våra sociala medier 🙂

Kom igång med Openmqttgateway och Home Assistant

Att komma igång med OpenMQTTGateway var nästan för enkelt, utifrån erfarenheter från tidigare projekt så har hade vi räknat med att behöva hantera en hel del konfiguration och kod. Nu har vi i skrivande stund inte testat Bluetooth Low Energy, GSM/ GPRS och Infrared. Men en Infraröd gateway kanske kan ersätta Ambi Climate och Sensibo Air för att styra luftvärmepumpen i framtiden!

Men här var allt vi behövde göra att koppla in LILYGO esp32:an via USB i en dator. Sedan surfade vi in på webbplatsen OpenMQTTGateway v1.5.0 (Extern länk), och lästa på lite om olika möjligheter.

När du sedan har läst en om projektet så går du vidare till (Option 1) Upload from the web | OpenMQTTGateway v1.5.0 ( extern länk ). Sök sedan fram lilygo-rtl_433 i listan, och väljer att ladda upp din kod. I samband med det så dyker längst upp en ruta till vänster på skärmen där du får välja vilken serieport du vill flasha (var noga med att ta rätt enhet!). När du sedan valt det så kommer det troligen att se ut något som på bilden nedan.

Efter några minuter så är esp32:an uppdaterad, och på displayen står det nu någon likande information.

Nu tog vi en telefon och ansluter den till esp32:ans WIFI eftersom den aggerar accesspunkt. Där uppdaterad vi med vilket WIFI esp32:an ska koppla in sig på. När du kopplat upp din OpenMQTTGateway så kommer du mötas av en liknande bild som nedan med namnet ”OpenMQTTGateway_lilygo_rtl_433_ESP”. Nu är det inte många steg kvar!

Nu väljer du ”Configure WiFi” och där letar du fram ditt 2.4Ghz WiFi som du vill att din gateway ska koppla upp på. Sedan är det bara att fortsätta med MQTT inställningarna.

Vi valde att skapat en ny användare i Home Assistant, en som bara tillåts logga in lokalt i Home Assistant. Den användaren skriver vi nu in som mqtt användare i esp32:an. Vi skriver även in IP-adressen till vår Mosquitto Mqtt i vår Home Assistant.

Vår användare fick det kreativa namnet ”espmqtt”, under mqtt server anger du ip adressen till din Home Assistant. Det kanske går att ange dns namnet med, men vi valde att hårt sätta ip adressen eftersom den är reserverad till vår Home Assistant och byts därav inte.

Vi ändrar dessutom topic:en från ”Home” till en egen ”openmqttgateway”, vilket i efterhand såg lite fult ut eftersom OpenMQTTGatewayen publicerar sitt namn som börjar på precis samma namn med lilygo_rtl_433_ESP en nivå ner. Så vårt path i MQTT blev: ”OpenMqttGateway/OpenMQTTGateway_lilygo_rtl_433_ESP/RTL_433toMQTT/”sensor”.

Så på topic kanske du ska låta ”Home” vara kvar eller sätta en annan än det vi valde. Eller så döper du om din enhet, men detta är mer en smaksak än att det påverkar något praktiskt.

När allt detta är klart så sparar vi inställningarna och efter någon minut så ser vi via vårt Node-red. Vi har där ett flöde som lyssnar på topic:en openmqttgateway/# vilket gör att vi kan följa allt som kommer in via vår openmqttgateway.

Så när vi får in vår data på vår MosquittoMQTT så kan vi i realtid se det och logga.

När vi väl får in ett meddelande från vår OpenMQTTGateway till MosquittoMQTT så ser det ut som nedan när det tolkats korrekt. Informationen är från debug flödet i Node-Red

Nu kan vi lyssna på meddelanden i Node-RED och sedan avgöra om det är något vi vill tillåta komma in på MQTT i framtiden. Vi kunde via den här se att det fanns mycket mer 433Mhz enheter i luften än vad vår RFXtrx lyckats detektera. Vi kunde även se att väderstationen vi har dyker upp! men endast temperatursensorn blir en korrekt enhet på MosquittoMQTT… Så vi kommer behöva göra ett flöde i Node-Red som översätter det stora JSON svar vi får och skapar en sensor i Home Assistant.

Vi gick in och kollade vår Grafana rapport för MQTT nedan, den bygger på data kommer från Node-Red flöden som vi visade ovan. Allt detta körs på vår Home Assistant och via en fråga mot INFLUXB så ser vi att det är mycket händelser/data som går igenom vår MosquittoMQTT. Merparten av meddelandena under de senaste 7 dagarna är det Zigbee systemet Zigbee2MQTT som genererat. Och det beror på att vi i skrivande stund har mer än 120+ Zigbee enheter som snurrar utan problem där 🙂

OpenMQTTGateway i Home Assistant

Inne i Home Assistant får vi nu upp en ny enhet som är just vår OpenMQTTGateway om vi kollar under enheter i MosquittoMQTT. Integrationen och den detekterade enheten i MQTT tillåter oss att styra OpenMQTTGatewayen fullt ut från gränssnittet i Home Assistant. VI kan ändra så displayen på LILYGO chippet får en annan ljusstyrka, samt ändra vissa funktioner i gatewayen härifrån.

Menyn nedan ger dig möjlighet att korrigera och ställa olika egenskaper i den OpenMQTTGateway, vilket underlättar när du precis har kommit igång. Bland annat så valde vi att släcka ner displayen när vi inte ska lägga till nya enheter. För dom där små skärmarna har en förmåga att få få inbränning över tid historiskt. Så ett tips där är att släcka dom när du inte har behov av att se loggan eller vilka enheter den detekterat.

Utöver att nu få in statistik så kan vi via en knapp i Home Assistant gränssnittet aktivera så att det detekteras och inkluderas 433Mhz enheter. Du hittar den inställningen under ”SYS: Auto discovery”, MEN tänk på att bor du i områden där det kan finnas många grannar så är risken stor att du får en mängder med enheter. Så ett tips är att bara aktivera den här funktionen när du vill få in en av DINA enheter.

OpenMQTTGateway och hårdvara

När det kommer till hårdvara så fanns det en mängd enheter som openMQTTGateway stödjer. Nu har vi specifikt snöat in på just 433Mhz för det här projektet. Men vi har planer att testa en vanlig esp32 i framtiden med deras Bluetooth Gateway, Vi hoppas få att vår pax fläkt att lämna Python scriptet med pyclima, mycket på grund av att det nu låser upp en separat Raspberry pi.

Den hårdvara vi själva beställde var den nedan, och det är den modell som finns som rekommendation i hårdvarulistan hos OpenMQTTGateway projektet. Du kan hitta hela listan här: Boards | OpenMQTTGateway v1.5.0 ( extern länk ), tänk då på att hålla koll så du hittar en med LORA på 433Mhz om du vill återskapa vårt projekt.

Men för att kunna följa det här inlägget så är det viktigt att du får tag på en esp32 med just ”Lora chip”, detta för att kunna få in signalerna från 433mhz enheter. Det som är viktigt med är att du inte köper en med frekvensen 868Mhz som är standard i Europa, utan att du väljer 433Mhz varianten som är för Asien.

Att vi tog LILYGO innebar att vi dessutom fick en liten display till vårt kort, något som var rätt smidigt i början när vi testade olika 433Mhz enheter. För gatewayen växlar nämligen information på displayen när den lyckats dekoda ett 433Mhz paket. Något som gjorde att vi direkt kunde se att vår väderstation tolkades.

Att den lyckades med väderstationen innebär att vi nu kan ersätta rfxtrx (trodde vi!). Eftersom detta var de sista riktiga 433mhz enheterna vi använde. Nu visade det sig att vi inte kunde tolka den helt korrekt, men vi tror att det ska gå att lösa med hjälp av Node-Red flöden.

Nu gav vi inte upp bara för att de enheter vi hoppats på inte fungerade, utan vi letade fram en låda med en mängd gamla enheter, och där hittade vi en bortglömd stektermometer, nu står det ingen information alls om hur den kommunicerar, men när vi köpte den så gissade vi på att det var 433Mhz. Men vi lyckades aldrig få in den i RFXtrx enheten då…

Så nu packade vi upp den och testade om OpenMQTTGateway skulle hittade den. Vilket skulle vara ett roligt projekt att addera till sommarens alla projekt i trädgården.

Och när vi ställde in OpenMQTTGateway på att inkludera enheter så dök stektermomeneter upp! Vi kunde se att den började skicka data! När vi kört den några minuter så uppmärksammade vi att probe nummer 2 alltid skickade helt felande värde…. Så nu är det perfekt att ha Node-Red för att debuga och se om det kommer in korrekt data på MosquittoMQTT eller om det felar redan från OpenMQTTGatewayen

Nu kunde vi dock se att OpenMQTTGateway hade problem att översätta probe nummer 2, ofta drog den iväg till 300 grader. Men vi kan se att datat tolkats och att det är det resultat vi får från OpenMQTTGatewayen.. Så här kommer vi inte kunna göra någon korrigering tyvärr, men vi vet att vi kommer kunna använda probe 1 och automatisera utifrån den.

Felsöka enheter i OpenMQTTGateway

Nu var planen med OpenMQTTGateway att ta in vår väderstation, men som vi nämnde så lyckades vi inte direkt med det… När vi detekterade Oregon-WGR800 i OpenMQTTGateway och fått den att skicka till MosquittoMQTT så ser vi att den bara registrerade batteri. Så här blev vi mindre glad eftersom det var problemet vi ville lösa!

Men vi gav inte upp, nu vet vi att den tolkar enheten..

Vi började felsöka genom att kolla debug i node-red för det här objektet. Där får vi all information i JSON, så ser vi att det finns mer information än det som registrerats i MosquittoMQTT. Nu började vi fundera om detta beror på att det är helt vindstilla, och därav kommer det inte upp några fler egenskaper. Kollar vi meddelandet så ser vi att Wind_dir_deg här värdet 337.5, så det verkar tolka data från vindsensorn, men det registreras inte..

Vi kollar hur vår RFXtrx har registrerat vindsensorn och den skrivit in data (bilden nedan), där ser vi att det är vindstilla och att den vinden pekar mot 202 grader. Så vi måste tyvärr avvakta och vänta på att det börjar blåsa här för att avgöra om OpenMQTTGateway får några värden… Skulle den få det så kan vi i Node-Red skapa ett flow som översätter data från JSON formatet till en sensor i Home Assistant.

Skal till LILYGO och OpenMQTTGateway

För att få en snyggare paketering som vi kan skruva upp på en vägg så passade vi på att skriva ut ett skal med hjälp av en 3D skrivare. Något som som börjar bli så pass stabilt så det nästan bör vara ett tillbehör i ett smart hem 🙂

Det ”chassi” vi har skrivit ut med hjälp av 3D Skrivare finns att ladda ner här: TTGO Lora ESP32 V2.1 1.6 – Robust case by JesAde – Thingiverse (extern länk). Vi har inte designat chassit utan tackar JesAde på Thingiverse som designat och delat med sig av sin design 🙂

Nu ska vi säga att de flesta av våra designer även finns att ladda hem på Thingiverse med, så vi försöker dela med oss av det vi designar med. Du hittar bland annat den regnsensorn vi designade för en mängd år sedan där, den finns att ladda ner här – https://www.thingiverse.com/thing:3039882 (extern länk). Vill du stötta bloggen och hjälpa oss driva den vidare så säljer vi våra egna designer här.

RFXtrx vs openMQTTGateway

Nu efter att ha testat openMQTTGateway under snart en veckas tid då har vi kommit till insikten att RFXTRX klarar fler 433mhz enheter än vad openMQTTGateway gjorde. Men vi kommer behålla båda lösningar över en tid. För nu får vi in 433Mhz enheter på vår MQTT, vilket innebär att vi får samma hantering för dessa enheter som vi har för Zigbee2MQTT via vår SONOFF zigbee usb 3.0 sticka.

Värt att tänka på är dock att RFXTRX har funnits sedan tiden då vi körde Vera lite runt 2015. Där finns det en stabil integration med Home Assistant och dessutom möjlighet att lyssna på olika ”mönster” på 433mhz kommunikation. Enheterna på bilden nedan är just via RFXCOM RFXtrx, så när vi jagade igång en mängd 433Mhz enheter så tillät vi även RFXtrx att detektera och inkludera enheter automatiskt.

Inne i integrationen för RFXtrx så går det enkelt att aktivera fler mönster i 433Mhz, vilket skulle detektera fler 433Mhz enheter. Nu har vi valt att aktivera följande för vår enhet (bilden nedan). Motsvarande skulle kräva att vi laddar in en uppdaterad firmware i OpenMQTTGateway tyvärr.

När det gäller OpenMQTTGateway så är det mycket nyligt som det blev känt att en Esp32 med en ”felande” Lora frekvens på för Europa går att använda för att läsa av meddelanden.

Nu hoppas vi att intresset för det här projektet blir stort och att fler hjälper till att skapa dekoders för olika 433Mhz tillverkares protokoll. Vi har testat en handfull olika 433Mhz enheter. Och vårt resultat är att rfxtrx klarar merparten av de äldre 433Mhz enheterna vi testade, medan openmqttgateway var begränsad på äldre enheter. Vill du se listan på alla enheter OpenMQTTGateway klarar så kan du läsa den här:

Devices | OpenMQTTGateway v1.5.0 (extern länk) – Här hittar du även en lista på en mängd Bluetooth enheter.

Så kan du kan minska bruset på MQTT

Som nämns nere i kommentaren så kan det tyvärr vara en hel del brus på MQTT, något som gör att du får mer information och enheter än du kanske önskar från OpenMQTTGateway. Nu är det kanske inte ett problem om du väljer att offra den Topic där den här informationen kommer in. Men skulle du som oss glömma att stänga av ”SYS: Auto discovery” så är risken stor att du hittar liknande enheter på din Home Assistants Mosquitto MQTT.

Skulle du däremot vilja få ut någon enhet som Home Assistant inte klarar att översätta till en enhet, då kan det vara aktuellt att testa med Node-Red för att fiska information från den MQTT Topic som OpenMQTT gateway skickar till. För att få fram alla förutsättningar och veta hur du sätter upp Node-Red så spana in Guide: Kom igång med Node-Red på Home Assistant, där visar vi hur vi både installerar node-Red och konfigurerar allt med koder och exempel för MQTT.

Byta antenn på LILYGO

Eftersom vi nu använder 433Mhz så finns det inte någon fin funktion för att enheterna ska kunna hoppa mellan varandra (mesha). Därför testar vi att maximera förutsättningarna att vår OpenMQTTGateway når våra 433Mhz enheter. Och som bilden ovan visar så gick vi från den lilla antennen till en större variant för ~50kr med +5dbi för 433Mhz.

Så vad vi kunde så i loggar så upplevde OpenMQTTGateway mycket bättre förutsättningar i sin egen RSSI. Kollar vi däremot en väderstation på gården så upplever vi inte så stor skillnad i signal enligt grafen nedan. Men vi ska låta det gå några dagar innan vi drar förhastade slutsatser här.

Så vår slutas om att det kan vara värt att byta antenn är precis samma här som det var på RFXTRX och Vera Lite långt tillbaka i tiden. Vi ska troligen testa en annan extern antenn inom kort med. Men först vill vi samla på oss loggar från det här bytet.

Har du testat att byta till en annan antenn? Vilken valde du och vilket resultat fick du?

Rekommenderad läsning

Vi har en mängd innehåll på bloggen, så vill du fördjupa dig i andra liknande tekniker. Spana då in några av de populäraste inläggen på bloggen just nu.