Zoekresultaten : mqtt

apr 082018
 

Ik realiseer me dat de titel van dit bericht weer eens absoluut geen click-bait is. Als je toch verder leest: leuk! ūüôā

Voor wie denkt: waar heeft hij het nou weer over, eerst even kort wat uitleg. Zoals je wellicht weet zijn er naast Arduino en Micro:bit tal van andere interessante oplossingen op het gebied van microprocessoren, kleine uitbreidingskaartjes met een chip er op die net als Arduino en Micro:bit gebruikt kunnen worden om sensoren te lezen, randapparaten aan te sturen, maar die vaak een fractie van het geld kosten. Bekendste op dit gebied was ongetwijfeld de ESP8266, als je de link volgt kom je bij een aantal berichten op dit blog daarover. De ESP8266 heeft inmiddels een opvolger, de ESP32. Het heeft even geduurd voordat ook de firmware en ondersteuning voor de chip op orde was, maar inmiddels zijn ontwikkelbordjes met de ESP32 goed en goedkoop te krijgen (zeker via online shops zoals AliExpress). Ook over de ESP32 heb je hier al meer kunnen lezen, de LoPy van Pycom was de eerste ESP32 die ik hier in huis haalde naar aanleiding van de Kickstarter in augustus 2016 alweer. Dat was ook mijn eerste kennismaking met MicroPython. Een programmeertaal die voor mij helemaal niet zo vanzelfsprekend was omdat ik (toen) nog niet eerder met Python geprogrammeerd had.

Sindsdien gebruikte ik MicroPython uitsluitend op de LoPy’s. Want pogingen om het op een ESP8266 handig aan het werken te krijgen waren op niets uitgelopen. Het was simpelweg teveel gedoe om de code te wijzigen.

Bij toeval kwam ik echter op YouTube deze serie instructiefilmpjes tegen:

Ik bekeek hem en was onder de indruk van het gemak waarmee, met dank aan rshell het nu mogelijk was om bestanden te uploaden en wijzigen op de ESP32. Overschakelen naar de REPL, weer terug naar de shell, het ging allemaal heel soepel. En ik had toevallig nog een ESP32 liggen die niks lag te doen.
Ik had hem aangeschaft al node voor LoRaWAN / TTN, maar helaas had ik bij het bestellen niet goed opgelet en een versie op 433Mhz besteld in plaats van op 868Mhz. Je kunt hem hier vinden (even opletten dus!). Je hebt helemaal gelijk als je zegt “maar voor 16 euro kan ik ook een Micro:bit kopen”. Klopt. Maar dat komt door de LoRa-module en het kleine LCD-schermpje. Wil je een gewone ESP32 zonder LoRa-module en zonder LCD, dan kun je er hier al eentje voor minder van 4 euro (incl. verzenden) vinden. En dan heb je dus een microprocessor m√©t WiFi en BLE en batterij-aansluiting.

Goed, ik ging het proberen. Maar ik wilde het niet op een Raspberry Pi doen, maar in het Linux Subsystem dat ik op Windows 10 heb draaien. Waarom? Omdat ik wilde weten of het nu eindelijk een volwaardig alternatief geworden is. Spoiler: ja, dat is het, maar je moet er wel even wat voor doen.

Lees verder….

jan 212018
 

Ik heb vandaag de Sonoff Pow voor het eerst echt getest. En de resultaten zijn heel interessant wat mij betreft. Onze wasmachine draait heel wat was per week en het blijken dan ook ideale momenten om de vermogensmeter uit te proberen. Hierboven zie je de resultaten van vandaag (tot nu toe). De grafiek komt uit Grafana, die de data ophaalt uit InfluxDB waar de data terecht komt via OpenHab en MQTT. De gele lijnen heb ik later toegevoegd.

Van links naar rechts zie je achtereenvolgens een bonte was programma op 30 graden, gekenmerkt door een snelle stijging van het gebruikte vermogen naar zo’n 2kW en daarna geleidelijke daling met 3 kleine verhogingen bij het centrifugeren.
De tweede trommel was beddengoed op 60 graden. Daar zie je dat het vermogen veel langer op die 2kW blijft en ook hier kleine verhogingen voor het centrifugeren.
Het beddengoed ging de droger in, het verbruik daarvan kent niet zo’n grote piek (zie blokje 3) maar blijft heel lang op zo’n 400W.
Het vierde blok moet je nu al kunnen herkennen: een tweede trommel op 60 graden (beddengoed van de kinderen), daarna heb ik de droger weer van de meter afgehaald en de T-shirts van het hockeyteam van de jongste gewassen. Een kort programma (30 minuten) op 40 graden, te zien in het vijfde blokje.
En op het moment loopt een laatste bonte was voor vandaag bijna ten einde.

Inmiddels heb ik tellers toegevoegd die respectievelijk de gebruikte energie tijdens een geselecteerde tijdsduur, daarvan afgeleid het aantal kWh (delen door 36.000) en de kosten (vermenigvuldigen met 18 eurocent per kWh) laat zien. Daaraan kan ik zien dat een trommel witte was met 18 eurocent zo’n 2,5x zo duur is als een trommel bonte was (7 eurocent) en de T-shirts van het hockeyteam verbruiken, ondanks het kortere programma, door de hogere temperatuur bijna net zoveel stroom als een gewoon bonte was programma. Geen manier om geld te besparen dus. Ook de droger is niet heel goedkoop in gebruik, net zo duur als een trommel witte was. De waslijn waar het kan blijft dus het devies.

p.s. ik vind zulke metingen, de data, de info die het oplevert super interessant. Betekent niet dat ik voortaan geen apparaat meer aan durf te zetten uit angst voor het bijbehorend verbruik. Verspilling tegen gaan is prima, maar het moet wel leefbaar blijven.

jan 202018
 

Vandaag ben ik lang bezig geweest met het aan de praat krijgen van een Sonoff Pow switch met WiFi-aansluiting. Het is een schakelaar die verbinding maakt met je draadloos netwerk, die je op afstand kunt aan/uit schakelen én die het verbruik bijhoudt. Dat is een eigenschap die mijn andere schakelaar niet hebben.

Nou dacht ik te hebben begrepen dat de schakelaar via MQTT eenvoudig aan OpenHab (het domotica systeem dat ik gebruik), maar dat bleek even tegen te vallen.
Sowieso bleek het koppelen van de schakelaar aan de standaard applicatie nogal ingewikkeld (tip: zet je telefoon in vliegtuigstand en maak dan via WiFi verbinding met de schakelaar).

Maar MQTT zit niet in de standaard firmware, daarvoor moet je die bijwerken. Om de firmware te kunnen bijwerken met je een 4-pinnige headers op het board solderen. Daarvoor moet je de behuizing openen. Tot slot heb je een USB-TTL converter nodig die je op die 4 pinnen kunt aansluiten zodat je via UART de nieuwe firmware op de in de schakelaar opgenomen ESP8266 kunt zetten.

Gelukkig had ik alle benodigdheden in huis. 

Alleen bleek het aan de praat krijgen van een alternatieve firmware iets ingewikkelder dan gedacht. Ik ben van start gegaan met ESPEasy. Maar zowel de 1.2 als de 2.0 versie daarvan leverden geen schakelaar op die een netwerk liet zien waar ik mee kon verbinden.

Ook de ESPurna firmware leek in eerste instantie helemaal niets te doen. Er verscheen geen Wifi-netwerk waarmee ik kon verbinden om de Sonoff aan mijn eigen thuisnetwerk te verbinden.

Uiteindelijk heb ik op de laptop waarop ik zat te werken Python ge√Įnstalleerd (stond daar nog niet op) en ESPtools¬†ge√Įnstalleerd om het op die manier te installeren. Tot dat moment had ik gebruik gemaakt van een voor Windows gecompileerde executable.

Ook daar gaf het uploaden van de firmware in eerste instantie een foutmelding (zie afbeelding hierboven), maar hoera, ondanks dat zag ik het netwerk SONOFF netwerk (wachtwoord “fibonacci”) verschijnen. Daarna was het een kwestie van daarmee verbinden, naar http://192.168.4.1/ toe gaan en daar de instellingen aanpassen (Wachtwoord aanpassen, WiFi-netwerkverbinding aanmaken, MQTT verbinding tot stand brengen).

De schakelaar stuurt zelf een heleboel data door naar MQTT, zoals het voltage, de stroomsterkte, vermogen etc. En je kunt de schakelaar ook weer via MQTT aan en uitschakelen.

Ik heb er voor nu één. Belangrijke eerste vraag was namelijk of ik het geheel in mijn infrastructuur opgenomen zou krijgen. Dat lukt in ieder geval. Ik moet me nog wat verder inlezen op het gebied van active power, reactive power and apparent power.

Mooi lijkt me in ieder geval als ik dit soort toepassingen ook zelf kan bouwen. Wordt dus vast nog vervolgd.

 

jan 082018
 

Toen ik een week geleden schreef over het automatisch opslaan van sensordata in Google Sheets gaf ik al aan dat dat zeker niet een optimale oplossing was. Inmiddels wordt dat ook meer dan duidelijk omdat de spreadsheet zich blijft vullen en het opbouwen van de grafieken duidelijk meer tijd kost.

In dat bericht verwees ik al naar InfluxDB, een database die specifiek ontwikkeld is voor het opslaan van tijdreeksen, data dus die gekoppeld is aan een datum/tijd. Het is dan ook niet zo vreemd dat InfluxDB populair is als database om de data die vanuit de verschillende sensoren die je aan OpenHAB koppelt op te slaan. OpenHAB is een gratis tool/omgeving waarmee je zelf je huis kunt automatiseren. Je kunt er lampen of schakelaars mee aansluiten, de data van sensoren zoals thermometers verzamelen en weergeven, je kunt acties koppelen aan die sensoren (bv zet de ventilator op de badkamer automatisch aan als de luchtvochtigheid boven de 50% komt) etc.

Ik gebruik OpenHAB al een tijd en hoewel er ook hier discussies zijn over wat de beste omgeving is (er zijn meer gratis alternatieven op dit gebied), werkt het voor mij en heb ik geen reden om over te stappen. Wat ik echter wel wil doen is overstappen van mijn huidige 1.8 versie naar de recente 2.2 versie. Dat is op papier een eenvoudige upgrade, ik had vooral al begrepen dat het in praktijk niet helemaal zo zou zijn. Daarom wilde ik dat voorzichtig aanpakken. Het voordeel van het gebruik van OpenHAB op een Raspberry Pi is dat het niet veel geld kost om er een tweede Raspberry Pi naast te zetten met de nieuwe versie (zeker als je er al een paar in huis hebt).

Een tweede ontwerpkeuze waar ik veel voordeel van gehad heb is dat ik MQTT gebruik voor zo ongeveer alles wat met sensordata te maken heeft en ook voor het aansturen van schakelaren in huis. De Mosquitto-server (een gratis server voor MQTT) die ik daarvoor gebruik staat op dezelfde server als OpenHAB. Dat zou een probleem kunnen zijn, alle sensoren sturen namelijk hun data naar dat IP-adres, maar het is gelukkig heel eenvoudig om de Mosquitto-server te vertellen dat alle ontvangen data ook doorgestuurd moet worden naar de Mosquitto-server die op de “nieuwe” (test-)server met OpenHAB 2.2 staat. Zo kon ik de bestaande productieserver helemaal met rust laten (op het toevoegen van die ene doorverwijzing in het mosquitto.conf bestand (zie ook de schermafdruk hiernaast voor de benodigde aanpassing, voor het IP-adres gebruik je het eigen IP-adres van de nieuwe server, de naam van de connection is vrij te kiezen). Daarna moest ik de Mosquitto-server even herstarten met systemctl status mosquitto.service -l

Goed, terug naar de tijdseriedata en InfluxDB. Er zijn tutorials beschikbaar voor het installeren van InfluxDB op de Raspberry Pi (bv hier). Maar omdat het mij om de combinatie InfluxDB, Mosquitto, OpenHAB én Grafana ging, heb ik gekozen voor openHABian. Daar heb je namelijk al die tools (inclusief o.a. Node-RED, ook heel handig in combinatie met sensoren) ter beschikking in één download. Er is wat discussie over de vraag of je dat wel allemaal op één Raspberry Pi moet willen installeren. Dat zal waarschijnlijk een beetje afhangen van het gebruik. Ik heb het geheel nu draaien op 1 Raspberry Pi 2 en het werkt voor nu voldoende snel. Ik moet wel nog even uitzoeken hoe snel de database groeit, maar met een 16GB micro-SD kaartje is er nog wel wat ruimte over voor groei.
Lees verder….

dec 182017
 

Zal ik beginnen met de opmerking dat je prima kunt leven z√≥nder de oplossing waar ik nu over ga schrijven? Goed, dan weet je dat in ieder geval. Los daarvan heb ik best een speciale relatie met onze kerstboom. Die gaat verder terug dan 2015, maar voor deze blogpost hou ik het daar even bij. In dat jaar sloot ik de lampjes van de boom namelijk aan op een ELRO KlikAanKlikUit kloon. Dat is zo’n stopcontact dat je met een afstandsbediening aan/uit kunt schakelen. Maar als je zo’n zender aansluit op een Raspberry Pi, dan kan dat ook vanuit je smartphone. Het resultaat kun je hier zien/lezen.

Vorig jaar besloot ik nog dat het te vroeg was om gebruik te maken van stembesturing, de benodigde hardware was nog niet te koop in Nederland en veel te duur (200 dollar). Dit jaar was dat al heel anders, de hardware kostte minder dan de helft: ‚ā¨39,- voor een Raspberry Pi 3b, een paar euro voor een micro-SD kaartje en goede voeding en ‚ā¨33,- voor de Google AIY Voice Kit. Die laatste was niet heel gemakkelijk te vinden, na de initi√ęle verspreiding via MagPi duurde het een paar maanden voordat er een nieuwe batch gemaakt was voor gewone verkoop. Maar ik had er eentje.

Het in elkaar zetten van de hardware is niet heel moeilijk, een kwestie van het volgen van de stappen op de website (of in het boekje op papier dat er bij zit), je moet bij Google een account hebben, een project aanmaken en een bestand downloaden naar de Raspberry Pi. Gemakkelijk genoeg allemaal.

Lees verder….

sep 042017
 

Ik heb nog geen tijd gehad om zelf te spelen met Chatfuel, maar ik vond het voorbeeld dat¬†My Electronics Lab¬†gerealiseerd had met Chatfuel interessant genoeg voor een blogpost. Chatfuel is een (gratis) online dienst waarmee je zo te zien relatief eenvoudig een Facebook chatbot kunt bouwen. Die chatbot herkent de teksten die een gebruik intypt en reageert daar dan op. Dat hoeft niet alleen met tekst. In het voorbeeld hierboven verstuurd de chatbot GET-commando’s naar een (andere gratis) online MQTT-server. Een ESP8266 die een verbinding met die server heeft reageert daar dan weer op en schakelt een LED-lampje aan of weer uit. Die LED kan dan ook van alles anders zijn. Omgekeerd kun je je ook voorstellen dat je op deze manier informatie van sensoren opvraagt.

 

LoRaWAN with LoPy and KPN + Loggly

 Gepubliceerd door om 15:49  Hardware, LoRaWAN
mei 202017
 

In the Netherlands, KPN¬†was the first to offer nationwide coverage of a IoT network based on LoRaWAN. You can read about my first tests using their Network in combination with the Marvin node in this post. Unlike with the IoT network that for example is currently being rolled out by T-Mobile, which uses¬†NB-IoT and different hardware than The Things Network (TTN), switching a device from the TTN network to the KPN network is simple: just change the¬†DEV_ADDR, NWK_SWKEY, APP_SWKEY values in the config.py of you Pycom LoPy to the values that are provided in the management environment of KPN (see image left). No changes in the microPython code needed. You could even have a device connect to both networks and switch between them (although you probably don’t want to do that when you’ve got a battery powered node).

KPN offers a free test period where you can test your nodes on their infrastructure without having to pay. It is what I used for my train trip last month where I used both the Marvin node (connected to KPN) and the LoPy (connected to TTN) as a way to get a feel for coverage while moving in the Netherlands.

Besides the fact that KPN offers a commercial solution, the free test version (don’t know about the paid version) has a number of differences: unlike TTN where they provide a number of integration options (Cayenne, Data Storage provided by TTN, HTTP integration, IFTTT Maker), KPN only offers HTTP integration. This means you have to provide a destination URL for an HTTPS endpoint where the data is stored. In the Marvin workshop they use¬†Hookbin.com as a free and easy to setup endpoint. But endpoints created there only store data for a limited time. That is why I now use the free version of Loggly.com¬†to collect the data. But of course, the data is only useful if I manage to get it from Loggly to my own local system.

A second difference is a bit of a mystery. If I used the Marvin to send data over the KPN network, the data gets encrypted by the Marvin, but automatically is being decrypted again on the KPN server. But if I use the LoPy to send data over the KPN network, the data shown in the debug console at KPN and the data received by Loggly is still encrypted.

I managed to get both challenges resolved and in this post I’ll do a write-up not of the (lengthy) process of getting to the working code, but of the end result. All code is available on Github.

Lees verder….

apr 042017
 

At the moment, the console page of The Things Network has some problems getting the Gateway page. It has been reported on the forums, it appears to be a front-end thing, the gateways themselves appear to be working just fine.

So unless you want to get info about your gateway, add a new one, remove or change one, there should be no problem. If you have to do one of these things, you can also use the commandline interface (CLI) using the tool provided here.

It allows you to login using your account, get information about your gateways, add new ones, remove them etc.
The Rx / Tx info shows you the amount of trafic on the gateway (uplink and downlink).
It also offers a MQTT interface if you want to have a look at the data coming in from your devices without having to go to the website.

Besides giving answers, in my case it also raised some new questions:

If you click on the screenshot to enlarge it, you’ll see 2 gateways listed. One (“eui-b827ebffff2e837b”) ¬†is the LoPy Nano Gateway which has been heaving nicely since it actually got connected with an increasing count for Rx because it still is forwarding messages from my nodes here at my desk.

The other one¬†(“eui-b827ebffff2e837b”) ¬†is the single channel Raspberry Pi +¬†Dragino Lora Shield¬†that I at first managed to get online last week, but then at the end of the day stopped working (see here). Now at first, looking at it via the CLI did indeed show that it hadn’t been seen for a while. After removing the gateway and adding it again via the CLI, it did show up as recently seen. And apparently it still sees it.

I noticed that the gateway is working again because my nodes now sometimes list both of the gateways as receiving and transporting their messages:

  

Great. So, it works? Yes, but what I don’t understand yet is why the¬†LoPy Nano Gateway is connected to a “bridge” that is called the “PacketForwarder Backend” while the Raspberry Pi is connected to “staging”. Why the difference?¬†Also, how come that the Rx for the Raspberry Pi seems to be resetting all the time?

There is one thing that could explain the difference: because I am using NAT, I have setup port forwarding for UDP on port 1700 to the LoPy Nano Gateway. I cannot do that for both (I got only 1 externally visible IP address), so I am guessing that the TTN backend can reach the LoPy Nano Gateway, but cannot reach the Raspbery Pi. But does that explain the difference in bridge assignment?

 Reacties uitgeschakeld voor TTN: If the GUI fails, just go commandline  Tags: , ,
apr 022017
 

If there is a thing that is dislike most, than it is giving up on a technical problem before it is solved. So, although this weekend a late cold finally managed to make me sleep more than usual, I did manage to spend some time with The Things Network, the LoPy Nano Gateway and the Marvin Node.

So, one thing that really can kill your debugging efforts is the fact that the backbone for The Things Network is rock solid stable. I don’t know whether that just is the case during the weekend, but like last week, this weekend there were some outages. There is no single status page that you can check, so that makes it a bit hard. But I’m starting to learn that if the console page act oddly, like failure to show the gateways that I defined, or if suddenly everything is displayed is disconnected, it might just be that they are having problems on their end.
Who am I to complain about a free service? I know, still, an automated page that tells me if I need to just wait and do other stuff, would be nice.

But during the uptime, I was able to get some more stuff working.

First of all: the code that Alex used in the video¬†does work, just make sure you select “Packet forwarder”.

Another thing to know is that the default abp_node.py script has this code:

for i in range (200):
s.send(b'PKT #' + bytes([i]))
time.sleep(4)
rx = s.recv(256)
if rx:
print(rx)
time.sleep(6)

Basically it just sends 200 packages within a short time and then stops. So if you don’t know that, you’ll think the node stopped working. It does, but on purpose. Now if you reset the LoPy, it will start again, but the TTN backbone will ignore that data because the LoPy will start again with package #0, and the backbone will already have a package #0. The quick solution during testing is to reset the frames counter for the device.

Also, the test script is nice for testing, but LoRaWAN was not build for a rapid stream of data, so make sure you read the post about the TTN Fair Access Policy, even with small messages at close range, the 500 messages (of 10 bytes each) per day at SF7 means max. 1 message per (about) 3 minutes, the script sends one every 10 seconds. Granted, it stops after 200 messages, but if you repeat that 2-3 times during testing, you go above that.
For me, testing it on my own Nano Gateway, the chances that I “steal” airtime from other nodes is small, but if you’re using someone else’s gateway, you could be causing problems for other nodes being unable to get their messages through.

But like I said in the title, the weekend showed there is still some love left. I managed to get a few more things working with my two nodes.

Lees verder….

jan 172017
 

Infrarood ontvangerEen van de (hier nog niet gedocumenteerde) projectjes waar ik afgelopen kerstvakantie aan gewerkt heb, bestond uit het koppelen van een Wemos D1 mini en een infrarood-ontvanger. Daarmee kan ik de signalen van mijn Logitech Harmony 650 opvangen en doorsturen naar mijn MQTT-server die de informatie daarmee weer beschikbaar maakt voor OpenHab.

Daardoor kan ik bv de lampen ook met de Logitech afstandsbediening uitschakelen. Omdat het me handig leek een paar ontvangers achter de hand te hebben, ik had de enige/laatste die ik had opgebruikt, bestelde ik er 5 bij via AliExpress. Ik dacht dat ze ‚ā¨0,67 per stuk moesten kosten. Maar ik had niet helemaal goed gelezen. Die 67 eurocent waren namelijk niet per stuk, maar per 10 stuks. En ik had er dus geen 5 besteld, maar 50 stuks.

Dus….als je nog leuke maak-idee√ęn hebt voor projecten waarbij ik een infraroodontvanger kan inzetten, dan hou ik me aanbevolen! ūüôā