Din varukorg är för närvarande tom!
Vi hjälper dig skapa ett smartare och tryggare hem.
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: 2024-03-21 – OpenMQTTGateway med den senaste firmwaren startar om, upptäckte det i loggarna.
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.
| Info om det vi beställde: | Länkar |
| LILYGO® TTGO ESP32-Paxcounter LoRa32 V2.1 1.6.1 Version 433/868/915MHZ LoRa ESP-32 OLED 0.96 Inch SD Card Bluetooth WIFI Module – Pris ~250kr när vi beställde | https://a.aliexpress.com/_mLL31Sm (extern länk) |
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.
Popular Posts
Guide: Home Assistant på svenska 2017-01-19 I mer än 6 år har vi på Automatiserar.se byggt och uppdaterat just den här guiden om Home Assistant på svenska. Vi har ständigt delat med oss av erfarenheter och nyheter om Home Assistant här. Och mer än 100.000 läsare har här fått hittat tips om just Home assistant. 2024-03-30 – Vi har nu uppdaterat till en Raspberry Pi 5 med NVME disk för Home Assistant. Guiderna är på gång att uppdateras. Vi kommer nu uppdatera guiden för att även fungera med Rapsberry Pi 5 och NVME disk istället för en extern SSD via USB. Du kan nu steg för steg bygga din installation från grunden upp, så har du redan börjat så hoppla längre fram i Guiden för nybörjare…
Test: Så bra är Xiaomi Aqara temperatursensor 2019-02-20 Till att börja med är sensorn den minsta jag skrivit om på bloggen sedan jag började 2014! Temperatursensorn med luftfuktighet & lufttryck är endast 36mm i kvadrat och under en cm tjock! Vilket är en stor skillnad mot många andra temperatursensorer vi tidigare testat. Den är mycket lätt att dölja i inredningen till skillnad från andra sensorer. Senast uppdaterad: 2021-03-23
IKEA Trådfri: Vanliga fel och så kan du förlänga räckvidden 2019-08-05 Vi har läst om många som har haft problem att gatewayen Trådfri. De vanligaste problemen är dock lätta att åtgärda. Räckvidden och väntande uppdateringar verkar vara det vanligaste problemen. Men en del problemen kan tyvärr vara lite mer komplex att fixa (vanans makt). Här kommer du läsa om alla de tips och fel vi identifierat, med dessa tips kanske även din Trådfri gateway även bli helt felfri.
Guide till Home Assistant med Tips och Trix 2019-11-02 Vi har skrivet en helt ny Guide till Home Assistant med Tips och Trix. Vi har tidigare skrivit en populär guide om Home assistant, men guiden är nästan 4 år gammal och mycket har ändrats i Home Assistant. Vilket gör det lika bra att börja en helt ny serie om Home Assistant / Hass. Senast uppdaterad 2023-02-04 – Del 2 – Installera Mosquitto Broker Och Zigbee2mqtt På Home Assistant Vill du få hjälp att optimera och maximera ditt Zigbee nät? då är det här inlägget något för dig! vi kör i skrivande stund 120 enheter med dom inställningarna. Uppdaterad 2023-01-22 – Del 1 – Installera Home Assistant På Raspberry PI 4 – Nu med Youtube filmer med. uppdaterad 2023-01-15 -…
Guide – Raspberry Pi 2016-12-08 Kom igång med Raspberry pi för hemautomation. Har börjat komma igång med Raspberry pi för hemautomation. För att minska startsträckan för fler, och kanske få några tips tänkte jag göra en serie ”från start till mål med Raspberry Pi”. 2017-02-25 – Uppdaterar stegen för Grafana till V4.1.2, mer info om hur graferna ska ordnas. Guiden är nu testad och verifierad med Asus tinker board (förutom del 1 RPI installationen). 2017-02-04 – Lägger till info att tänka på när det gäller minneskort under ”Hårdvara”. 2017-01-22 – Rättad rutin för Home Assistant, uppdaterad förklaring på Grafana 2017-01-19 – Lägger till guide för installation av Telldus Duo. Hela guiden uppdaterades 2017-01-14 för att fungera med version ”PIXEL” som nu finns Guiden håller nu…
Test: Hur bra fungerar IKEAS gateway TRÅDFRI? 2017-04-01 I dagsläget är det enbart via mobilen det är möjligt att hantera kontrollern. Det är möjligt via Iphone och Android telefoner, allt som behövs är appen ”Trådfri”. För tillfället går det inte att hantera den på annat sätt än via Ikeas app. Antagligen är det bara en tidsfråga innan andra system lyckats integrera sig mot kontrollern.
Loggbok
2023-07-14 – OpenMQTTGateway är en mycket stabil lösning. Kört den fram tills nu helt utan problem.
2023-05-18 – Uppdaterade med information om hur en ny antenn påverkade RSSI (signal styrkan) för OpenMQTTGateway.
2023-04-30 – Vi skapade idag loggboken och svarade på lite frågor om OpenMQTTGateway, dessutom adderade vi en del för att beskriva hur du eventuellt kan jobba runt bruset som du får på MQTT Topic:en
Stort tack
Har du läst hit så vill vi tacka för att du tog dig tid att läsa, var det här inlägget bra? Uppskattade du innehållet? Dela det gärna med fler och kommentera med mer saker som borde finnas i det här inlägget.
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 gärna på våra sociala medier om du vill stötta oss med liknande innehåll.
Mvh Markus
Skribent:
Markus Jakobsson har i mer än 10 år delat med sig av erfarenhet inom smarta hem på bloggen. Han har testa det mesta och lärt sig massor på vägen, något han delat med dig här på bloggen.
Du kanske uppskattade och fick nytta av det här inlägget och vill hjälpa sidan Automatiserar.se?
Om du vill så Swisha gärna några kronor för att stötta bloggen på tel: 0705470065
Du kan även stötta bloggen genom att köpa någon av våra smarta hållare.
Alla bidrag vi får går till att täcka driftkostnaderna hos webbhotellet och köpa sensorer till bloggen.
Stort tack för att du tog dig tid att läsa vårt inlägg.
Med vänliga hälsningar Markus Jakobsson
Allt går att automatisera!
Gör som 2 257 andra, prenumerera du med.
Taggar:
Kommentarer
56 svar till ”Vad är OpenMQTTGateway, en ny 433Mhz Gateway?”
Sitter och labbar lite med Node-Red efter det att jag fått igång ovanstående lösning.
Det kommer in en massa ”skit” som jag inte vill ha men kan för mitt liv inte komma på hur jag ska kunna filtrera bort ”skiten”. Jo, själva filtret får jag till (allt ser bra ut i debug) men hur ska jag kunna hooka in i MQTT-flödet. Om jag levererar in det jag filtrerat ut så kommer det ju tillbaks i flödet igen och igen och igen och igen. Ska jag försöka ändra topic kanske? Hur har du löst det? Ser en function i din lösning. Jag har bara en switch.Just brus kan beror på vilken dekoder du kör till OpenMQTTGatewayen. Bruset är nog något som tolkas fel troligen), hade själv tur att den defaulta decodern översatte det jag ville, sen dök det ändå in lite brus på mqtt topic:en.
Nu kollar jag väldigt lite på just openmqttgateways topic, istället så låter jag vissa enheter skickas vidare från den topic:en till en annan topic som jag har automationer mot. Så inte löst problemet med brus, men fångar det jag är intresserad av.
// Markus
Man ska inte fråga utan fortsätta fundera. Och det funkade. Jag la in en change efter switchen och bytte MQTT-topic på de devices jag vill få in.
Alltså en MQTT-in, en switch, en change och sen en MQTT-ut.
Hur enkelt som helst bara man letar lite bland de olika funktionerna.
Och Markus, tack för snabbt svar!!!
Jag försöker avveckla mina tellstick net…
Nu är jag inte jättebevandrad i MQTT, z2m döljer ju allt så elegant.
Jag har satt upp en lilygo-433, alla temperatursensorer och några till dyker så vacker upp.
Men när via Telldus Live skickar en knapptryckning så dyker den upp med endast RSSI.
Jag måste då sätta upp den manuellt, men hur då? Jag är helt nöjd om den enbart ska skicka.
Om den kan ta emot så är det bonus, för nu, jag har ju redan de sensorer som jag vill.
Det finns inget exempel direkt, inte som jag kan förstå iaf.
Så här ser det ut med off-tryckning:
2023-08-15 08:57:04.436 DEBUG (MainThread) [homeassistant.components.mqtt.client] Received message on home/omg_lilygo_1/RTL_433toMQTT/Nexa-Security/3/38428816 (qos=0): b'{”model”:”Nexa-Security”,”id”:38428816,”channel”:3,”state”:”OFF”,”unit”:3,”group”:0,”protocol”:”Nexa”,”rssi”:-99,”duration”:242576}’
Det jag försökt med är bla
mqtt:
switch:
– name: Plug1
state_topic: ”home/omg_lilygo_1/RTL_433toMQTT/Nexa-Security/3/38428816”
command_topic: ”home/omg_lilygo_1/commands/MQTTtoRTL_433”
payload_on: ’{”model”:”Nexa-Security”,”id”:38428816,”channel”:3,”state”:”ON”,”unit”:3,”group”:0,”protocol”:”Nexa”,”rssi”:0,”duration”:242576}’
payload_off: ’{”model”:”Nexa-Security”,”id”:38428816,”channel”:3,”state”:”OFF”,”unit”:3,”group”:0,”protocol”:”Nexa”,”rssi”:0,”duration”:242576}’
qos: ”0”
retain: false
Men jag blir inte riktigt klok på detta, och gott om tid är det ont om!Hej,
Jag har samma ”problem” sensorer verka fungera OK, men nexa uttag fungerar ”dåligt”Gissningsvis är det något jag inte förstått…
Exempel sida för OMG lämnar lite att önska, inte mycket men just ”DET DÄR”!
Det här har jag fått att fungera:
mqtt:
– binary_sensor:
name: ”Plug1”
state_topic: ”home/omg_lilygo_1/RTL_433toMQTT/Nexa-Security/3/38428816”
value_template: ”{{ value_json.state }}”
payload_on: ”ON”
payload_off: ”OFF”
Men det är en binary_sensor.
Jag har testat
– switch:
name: ”Plug1”
state_topic: ”home/omg_lilygo_1/RTL_433toMQTT/Nexa-Security/3/38428816”
# command_topic: “home/omg_lilygo_1/commands/MQTTtoRTL_433”
command_topic: “home/omg_lilygo_1/RTL_433toMQTT/Nexa-Security/3/38428816/set {{ value_json.state }}”
value_template: ”{{ value_json.state }}”
payload_on: ”ON”
payload_off: ”OFF”
state_on: ”ON”
state_off: ”OFF”
Sensor delen fungerar, men inte att skicka.Som jag ser det så är det kanske command_topic: “home/omg_lilygo_1/commands/MQTTtoRTL_433”
som ska användas. Det är bara frågan hur man får med parametrarna unit channel etc.Jag tror (misstänker) att OMG inte kan avkoda nexa pluggar på ett korrekt sätt med avseende på channel knapp osv…
Om OMG kunde avkoda på korrekt sätt så borde det ”uppstå” enheter med mer percisa namn där channel/ unit (typ A 5 ) dit då kan skicka on/off till.Man kanske måste skriva en egen avkodare och kompilera om koden och installera de.
Gunnar
Nja, den kan avkoda, trycker du på en ”nexa-knapp” med loggning för mqtt, så dyker den upp i loggen. Men det är bara RSSI-topic som dyker upp som enhet.
Man måste än så länge ha koll i loggen och lägga upp den manuellt.Med rätt command_topic och parametrar så bör det gå, det är bara frågan om vad de är…
Jag skull vilja få tag på en plugg som fungera och se hur det set ut i loggen och vilka kommand som ska skicka via mqtt.
Om man skulle kunna se den ”råa” bit strängen skulle man antagligen oxå kunna använda den, typ som exemplet i manualen (den bristfälliga).LilyGo kan bara ta emot, inte skicka.
Blev upplyst om detta igår.
Nu försöker jag att förstå hur det hela fungerar på github.
Så får vi se om jag kan implementera någon form av commands för RTL_433.
Det är det där med tid oxå…Så måste vi bara hitta en billig CC1101 och koppla ihop den med en esp32…
Kul att det finns en del (nån i alla fall) som håller på som Jag.
Jag vill oxå bli av med mitt beroende av en Telldus kontroller för 433.
Skulle vara kul att prats vid nån gång….Jag har bråkat en del med hemautomatisering i många år. Inte superaktivt, men då och då.
Det började med Telldus TellStick usb-dongle. Denna körde jag mot en NSLU2 med en programsnutt som hette tellstickd. Den tände och släckte lampor oftast som den skulle.
Det var skrivet i pearl, och det blev väl några smårättningar då det blev stolligt när tex solnedgången var efter det att lampan skulle släckas. Så började NSLU2:n bli plågsamt långsam och disken hade varit med i många år. Så jag skaffade första versionen av Tellstick Net. Tellstickd moddades och jag byggde en gateway i Java som anslöt sig mot tellstick net.
Det hela fungerade väl som förut. Samtidigt sneglade jag på lite ”mer”, bla Free Domotic, vars layout är intressant. Men det föll på Home Assistant. Därifrån har det utvecklat.
Jag har ett system hemma och ett i stugan. Och jag har en TS net på var ställe, samt en i min salig mors hus. Att det krävs premium hos Telldus för att få tillgång till api blev spiken i kistan! Openmqttgateway på en lilygo verkade vara en perfekt lösning, att den har wifi, gör den dessutom lättplacerad.
Som jag förstått det så kan lillygo skicka 433MHz, men ingen har implementerat det, fast jag kan ju ha fattat fel… .
Det är ju det där med tid, som det alltid finns för lite av.
Iofs, så skulle jag kunna skrota alla 433 MHz pluggarna, men jag har måånga.
De flesta är till små belysningar som ljusstakar, smålampor och julbelysning. I övrigt är det Zigbee som gäller, jag tror att jag har tre ZWave enheter, men de är inte aktiva.
Ja, ja vi får se hur det blir, det är mycket nu!
Jag började med tidur, blev trött på dem och började leta efter en automatisk och programerbar lösning.
Hittade Tellstick och nexa switchar som Jag körde med en webserevr på en rasberry 2B, gick över till telldus duo.
Började leta efter en bättre platform, provade en del men fastnade för HomeAssistant på en Raspberry 3.
Jag lagt till en hel del under åren, en dell hemmagjorda styrningar m.h.a esp8266 och relän bland annat för att starta och stopp cirulationspumpen och sätta tempratur till hög/låg samtidigt bled det massor med automationer för lampor och liknande.
Nu har Jag oxå end del Ikea prylar och z-wave intergrationer Alea och google osv….
Jag blev oxå irriterad på att man numera måste prenumera hos Telldus för få tillgång till integraionen.
Gunnar
Någon som lyckats hitta lösning på att kunna köra om/off av enheter?
Skulle gärna vilja få till det också men lite för dålig kunskap själv att gå vidare med det..
Fråga – behöver man skaffa till ett SD-kort om man skaffar hårdvaran ni länkat till?
Du behöver inget minneskort, allt lagras i chippet på kortet.
// Markus
Notera att denna gateay bara är HALV, den kan bara ta emot 433, INTE SKICKA!
Vet du om det är en begränsning i hårdvaran eller mjukvaran..? Har du något tips på vad det finns för alternativ om man vill ersätta en Tellstick med något som är helt lokalt?
Har själv inte haft tid att djupdyka mer i den här lora enheten. Men själva chipet ska ha stöd för att både ta emot och skicka, sen har jag själv inte gått in på djupet för att se hur den skickar. Men kanske är som många skriver att det inte går, och då borde de vara i mjukvaran begränsningen sitter.
Du kan använda tex rfxtrx för att ersätta Telldus i så fall. Sen sitter via usb och kan både skicka och ta emot 433mhz signaler, nu visar den här delen hur den används med Vera. Men principen är densamma för Home Assistant.
https://automatiserar.se/test-av-rfxtrx-433e-till-vera/
En ESP8266 och en liten 433MHz sändare löser det problemet.
Jag har grejerna, men har inte haft tid att plocka ihop dom. Hinner inte ens med att pilla ihop dom med tre kablar.
Det är synd att den inte klarar både och.
Jag är inte helt klar om det är mjukvara elle hårdvaran som egentligen är problemet
Kan passa på att tipsa om denna på Amazon som verkar vara likvärdig (om inte exakt samma?) som ni länkat till på AliExpress:
https://www.amazon.se/dp/B07RXSKPBX
Står ”DollaTek” på listningen men LILYGO på enheten jag fick hem. Kostar några kronor mer men fick också hem det på bara några dagar 😀
Att få igång det var ju precis som nämnt i artikeln hur lätt som helst, tack för tips och bra artikel! Kommer sannolikt ersätta en Tellstick Net v1 med denna för mina temp- och rörelsesensorer och sedan byta ut Nexa-uttagen jag har till WiFi- eller Zigbee-motsvarigheter och sedan koppla samman allt i Home Assistant 🙂
Med lilygo:n kan du ju alltid använda sensorer och knappar.
Jag har tänkt mig att använda de gamla 433-pluggarna till tex julbelysning och annat småkrafs. Men där det verkligen behöver fungera, så blir det zigbee.
Med wifi-enheter så tar det ju rätt många adresser på nätverket.
Det räcker med de ESPHOME-grejorna som jag har och kommer att ha.
Men med tex en 433MHz sändare och en ESP8266, så finns det en gateway att ladda på den. Det enda är att det blir två fysiska enheter. Å’ andra sidan så kan man ha flera för att få bra täckning.
Det är alldeles för mycket nu för att jag ska hinna med att testa att sända. Det är iofs bara tre sladdar, men det tar säkerligen en massa tid att komma underfund med hur det fungerar. Och börjar man konfigurera i ordning, så blir det många timmar. Jag har hyvlat bort de flesta ”fasta” 433:or, men det är några kvar. Det har blivit zigbee i stället. Hemma tror jag att jag är uppe i 97 zigbee-enheter, lampor, knappar och infällda. Môe blir det!
I stugan är det väl bara 60 enheter…
Hej,
Har startat upp en Lilygo för två veckor sedan. Fick in en massa enheter. Mitt problem är att Home Assistant tappar anslutningen till Lora32 eller tvärtom. För att få igång mottagaren igen måste jag rycka ur usb-kablen för omstart. Finns det något annat sätt att schemalägga en restart?
Hej
Låter skumt att den tappar kontakten, har kört min helt stabilt i 1.682.000 sekunder nu utan en enda omstart mot HA. Min HA har startas om några ggr för uppdateringar så den kopplat upp igen.Har du mesh wifi eller sitter den långt från din wifi accesspunkt? Samt har du 5ghz wifi på samma eller har du dedikerat ett 2.4 GHz wifi till den typen av sensor?
Annars har jag nog svårt att ge tips på lösningar. Iofs om du vill köra en omstart på den så kör en Zigbee strömbrytare på usb strömmen till den. Men det kanske inte är det snällaste mot esp:n
// Markus
Det finns väl i mqtt.
Titta där den dyker upp i listan.
Sedan en automation som startar om.
Har Asus wifi mesh 2,4 och 5 GHz. Esp32:an sitter nära (40 cm) den ena routern. Inkopplad till Pi via en (kort) usb. Hur dedikerar man 2,4GHz till esp:n?
Ulf: Vad ska jag leta efter i MQTT mer precis?
Hittade i MQTT. SYS: Restart gateway som är otillgänglig!
ESP32 Sys: Restart var otillgänglig eftersom den var satt till dold, nu ändrad till synlig. Har skrivit en automation för restart kl. 02:00. Får se om detta löser problemet.
Jag hade samma problem. Vilken firmware version kör du? 1.50 var stabil, men då fick jag inte in alla Oregon sensorerna trots samma modell. Med 1.60 löstes problemet med sensorerna, men den blev otillgänglig stup i kvarten så jag var tvungen att rycka usb sladden. La även till ett script som skulle resetta enheten om minnesmängden blev för låg. Inget löste problemet, mer än att backa till 1.50 igen, men då blev det ju problem med sensorerna. Moment 22. Jag behövde förändringarna i radiomodulen som var integrerad i 1.60, men stabiliteten hos 1.50, så det slutade med att jag kompilerade ihop en egen custom firmware efter mycket trial and error. Tog radiomodulen från 1.60 och och la till den i 1.50, sen var det bara att traggla sig igenom alla kompileringsfel som uppstod och åtgärda dem ett i taget tills kompileringen gick igenom. Nu har jag en stabil firmware som just nuhar en uptime på över 2,1miljoner sekunder. Webbgränssnittet från 1.60 fick jag offra, men inget jag behövde. Ser att det nu finns en ver 1.70. vet inte om den kan åtgärda eventuella problem. Har inte vågat testa då jag inte vill sabba det som just nu fungerar perfekt.
Kan även varit så att jag tog senaste koden för radiodelen från utvecklaren av rtl_433, minns inte riktigt hur det blev.
Hej,
Jag har firmware ver. 1.60.
Har problem med att alla inställningar för Lilygo är otillgängliga i HA. Vad göra? Installera om den? Lustigt, firmware var det enda som gick att läsa.Fick ordning på det, konfigurerade om den.
Var hittar jag firmware 1.7.0?Hoppa över 1.7.0!! Det är problem med den, krashar och bootar om. Stanna på 1.6 tills det har löst sej.
https://github.com/1technophile/OpenMQTTGateway/issues/1836
/ALäste meddelandet om firmware 1.7.0 försent!
Men jag tycker nog det har blivit bättre efter uppdateringen till 1.7.0. Visst ser jag att den startar om ibland men inget som stör mina sensorer. Endast en manuell reset på två veckor.
Det står LILYGO® Paxcounter i texten men länken går till en LILYGO® TTGO Disaster-Radio.
Vilken är det jag ska beställa?
Dom verkar ha ändrat innehållet på sin sida, ska se om jag hittar rätt version sen. Men annars kolla på OpenMQTTgateway:s sida, där fanns det några andra alternativ med så länge.
// Markus
Provade att byta antenn på min LilyGo OMG 433 och fick mycket lustigt resultat. Har två Oregon temp och fukt-sensorer, en på husvinden nära Lilygo. Och en på garagevinden, en bit längre bort övre gården. Med nya antennen fick jag sämre signal från den närmsta sensorn och bättre signal från den längre bort. Mysko.
Kolla rssi grafer här: https://drive.google.com/file/d/17pGpxKnVO4uIpvaHBGRWXiPdB7i9Ns1I/view?usp=sharing
Nya antennen kommer från Electrokit art nr 41015461. Var finns antennen i artikeln att köpa?
Jag har fått in c:a 15 enheter (grannarnas…) under MQTT-fliken.
Jag har följande termometrar:
1 st ESIC (Classe:s gamla)
3 st Viking AB art: 02038 (Nyare varianten, den som Loh säljer).
Jag får inte in någon av dessa? Vad gör jag för fel?
Jag har inte installerat node-red iom att jag började få in sensorer.
Något tips? Är det så illa att ingen av dessa Termometrar fungerar mot Lilygo:n?
Tack!
//Niklas
Hej Markus! Har nu väntat några veckor på att min LilyGo skall dyka upp, och dessvärre stöter jag på problem direkt. Kopplar in den i USB, den bootar och visar firmwareversion och tom IP-adress. Dock dyker den inte upp i datorn, varken på min mac eller pc. Har provat tre olika kablar utan skillnad. Har du stött på detta eller fungerade allt direkt?
Den är köpt från Ali med exakt samma artikelnummer som din.
//Per
Hmm, låter som att du kunnat flasha den till openmqttgateway med andra ord, men att den inte kopplar upp på ditt wifi? Om jag inte missförstått det.
I så fall kanske det är så att du kör 5Ghz wifi och att den misslyckas att koppla upp på det. Testa ett dedikerat 2.4 GHz wifi och se om de gör någon skillnad.
Annars så behöver jag nog mer detaljer om hur långt du kommit med själva flashningen.
// Markus
Hej, tack för snabbt svar. Nej, den hittas alltså inte alls av datorn. Ingen flashning gjord ännu. Jag tror att den är förflashad med någon disaster.radio firmware. Det finns ett wifi som går att ansluta till men det säger inte så mycket.
Eftersom jag provat tre olika kablar så borde det inte vara något fel där.
//Per
Men OJ, fjärde kabeln jag provade gjorde att den dök upp. Nu kan jag gå vidare med flashningen. Återkommer om det skiter sig igen.
//Per
Ok, håller du in flasha knappen när du kopplar in den i datorn? Har för mig att den ska dyka upp ändå, men testa om de gör någon skillnad.
På Windows dyker den alls upp i enhetshanteraren eller reagerar datorn inte alls på att något kopplas in på usb?
// Markus
Aha, nu läste jag att du kom vidare. Hör gärna av dig med resultatet sen så jag får höra hur det gick.
// Markus
Lyckades flasha den enligt instruktionerna, eller i varje fall så säger https://docs.openmqttgateway.com/upload/web-install.html att flashningen gick bra. Men den verkar inte boota upp korrekt, inget syns på displayen och efter en stund börjar den lilla röda LED:En blinka som galen. Väntade fem minuter men inget hände. Kopplade ur kabeln och tillbaka igen, men samma igen.
Då är det nog som du är inne på att något inte gick hela vägen, valde du rätt modell i webbgränssnittet? Har för mig att det annars en hel del att välja på.
Testa att flasha den igen, för den bör starta displayen om allt gick ok. Så det verkar vara något som felar tidigt.
// Markus
Efter andra omflashningen gick den igång, och jag fick konfat wifi´t men än så länge dyker det inte upp någon enhet i MQTT-integrationen. Den bootade dessutom om av sig själv nyss. Jag flyttade den till en egen USB-matning och kör inte längre via datorn, men det borde väl inte bli sämre för det. Har inte tid att felsöka mer ikväll men nu är projektet i varje fall påbörjat. Tack för snabba svar. Om jag skulle behöva göra om wifi-konfigureringen, är det full omflashning som gäller då?
Roligt att höra att den hoppade igång, ja tyvärr är det en flashning som behövs för att ändra wifi om jag inte mins helt fel.
// Markus
Hej, ville bara meddela att efter en hel del pill med kablar och omflashningar så är jag igång och det ramlar in enheter till HA. Kul! Jag kan även tillägga att det går att logga in på enheten via WebGUIt på den ip-adress som enheten får via dhcp och där konfa om alla inställningar utan att flasha om. Tack för kommentarerna, jag hade nästan gett upp innan jag börjat 🙂 Tänk att det skall vara så känsligt med vilken USB-kabel man använder!
//Per
Roligt att höra att det löste sig. Jo när den väl är uppe på ditt wifi så kan du komma åt och justera lite inställningar. Men innan dess så är det kört och kräver omflashning.
USB kablar är något som det fuskas mycket med tyvärr. Jag har slutat köpa billiga usb kablar från Kina pga det.
// Markus
Vet inte om det är följdfel för mig, men min device bootar om väldigt ofta. Den körs nu separat strömmatad, alltså inte via datorn, jag har den precis bredvid jobbdatorn så jag ser att den då och då bootar om, ibland kommer det upp på displayen att den skickar data, ibland kan jag logga in på webbinterfacet men det data den skickar till HA MQTT brokern är väldigt sporadiskt. Jag har inte NodeRed (pga RPi 3b) så jag kan inte se rådatat om jag inte monitorerar loggen på själva LORA:n. Som ju fungerar ibland.
Tror det finns lite kommentarer om detta en bit upp, vissa har haft problem med absolut senaste versionen av mjukvaran. Testa att flasha in en äldre version och se om de gör någon skillnad.
Kör själv den absolut senaste, såg dock nu när jag kollade att den startar om vid 17.00 idag. Men innan dess hade den en uptime på runt 1 740 000 sekunder.
Hej igen!
Av någon anledning slutade enheten att boota om och har gått stabilt några dagar. Jag fick dessutom ett snyggt skal utprintat av en kollega så nu är den skyddad och kan placeras där jag vill ha den också. Dock, det stora problemet är det du skriver om tidigare i inlägget, att den hittar en ohemul mängd enheter. Jag bor inte på något sätt i stan, vi har kanske tio fastigheter på hundra meters avstånd så det borde inte vara möjligt att den har hittat 316 enheter och över 770 entities. OBS, jag hade inte Auto-discovery påslaget från början, och den är fortfarande avslagen men det ramlar in nya hela tiden. Måste man toggla ”switchen” för att den skall ta kommandot? Jag har pga gammal host (rpi3b+) inte kraft för att köra Node-Red och kan således inte analysera paket där innan jag godkänner dem.
Som sagts innan så är det ett känt problem att ver 1.7 kraschar och bootar om emellanåt.
https://github.com/1technophile/OpenMQTTGateway/issues/1836
Jag har backat till tidigare version 1.6, funkar stabilt.
/A
Lämna ett svar