Zoekresultaten : mqtt

apr 152017
 

Now that Alex explained everyone how to use MQTT in combination with the LoPy, I thought it was time to show some more advanced uses of MQTT in case you still had no idea why you would bother learning to understand it.
The nice thing about MQTT (MQ Telemetry Transport or Message Queue Telemetry Transport) as a protocol, is that it is not tied to the LoPy or WiPy that Alex used in his example. You can use it in combination with many different devices, tools and applications. For example, in our house, I use a Mosquitto MQTT broker as the central backbone for the home automation. For those that can understand Dutch, see this blogpost I did in 2014, or the one about the lights in my Christmas tree.

MQTT is also supported by The Things Network (TTN) meaning that you can retrieve all the data that your nodes send to TTN using MQTT. This also means you can use MQTT as a way to create a local backup of the data that your nodes send this way.
You can also use it in combination with the KPN LoRaWAN network, but the setup is slightly different. So in this post I am going to focus on TTN, although like before I will be using both the Marvin board and the LoPy board (in combination with Puck.js although that is completely optional of course).

I will be using Node-RED installed on one of my Raspberry Pi devices and I will be using MySQL as the database backend. I will be posting about MySQL versus MongoDB versus InfluxDB one of these days, but on a Raspberry Pi for now this was the quickest and easiest solution.

Let’s dive in:

Lees verder….

Deel dit bericht:
dec 202015
 

php_MQTTDit is even een blogpost die 99% van de lezers niet zal zeggen, maar die ik voor mezelf hier maak zodat ik hem de volgende keer weer terug kan vinden, zonder het bijbehorende uitzoekwerk.

Wat wilde ik?
Ik heb op een Raspberry Pi een Mosquitto MQTT server draaien en op die server draait ook een Apache webserver met PHP5 ondersteuning. Nu wilde ik vanuit PHP data naar de Mosquitto server kunnen sturen en lezen. Dat kan, via deze uitbreiding. Maar daar moest ik een paar zaken voor doen. De commando’s zijn:

> sudo apt-get install php-pear
> sudo apt-get install php5-dev
> sudo apt-get install libmosquitto-dev
> sudo pecl install Mosquitto-alpha
> sudo nano /etc/php5/apache2/php.ini
voeg
extension=mosquitto.so
toe aan het bestand en sluit af
> sudo nano /etc/php5/cli/php.ini
voeg
extension=mosquitto.so
toe aan het bestand en sluit af
> sudo /etc/init.d/apache2 restart

Belangrijk is dat ik extension=mosquitto.so aan /etc/php5/cli/php.ini toe bleek te moeten voegen om het ook vanaf de commando prompt te kunnen gebruiken.

Deel dit bericht:
 Reacties uitgeschakeld voor Quick notes: MQTT ondersteuning in PHP op Raspberry Pi  Tags: , ,
jul 052014
 

Schema netwerk Vandaag weer wat (lees: eigenlijk teveel) tijd gehad om verder te werken aan mijn sensornetwerk op basis van MQTT. Ik had een vorige keer al beschreven dat ik op dit moment helaas alleen digitale vochtmeters voor in de grond huis heb (de analoge exemplaren zijn nog onderweg vanuit China). Maar ik had, naast de drie digitale vochtmeters voor in de grond, ook nog een gecombineerde temperatuur/luchtvochtigheid meter (een DHT11) en een lichtgevoelige weerstand beschikbaar, dus in totaal 6 meeteenheden.

Mosquitto
Op de Raspberry Pi had ik Mosquitto draaien, een open source MQTT “broker”, een plek waar de Arduino de gegevens naar toe kan sturen en waar anderen kunnen aangeven dat ze die info dan ook willen hebben. Het betrouwbaar aan de praat krijgen van de koppeling tussen de Arduino en de Raspberry Pi was niet gemakkelijk. Eigenlijk een bekend probleem: ik wilde het te mooi/ingewikkeld doen en was met JSON aan de slag gegaan om in plaats van via 6 MQTT calls, het geheel in één JSON via MQTT call te doen. Om een lang verhaal kort te maken: slecht idee.
Op een gegeven moment liep de Arduino bij het opstarten meteen vast en wel op een manier dat de seriële poort ook niet meer werkte en ik er dus geen gewijzigde scripts op kon zetten.
De oplossing bleek het goed getimed uploaden van het “blink” script waarbij ik de Arduino net op het juiste moment moest aansluiten zodat het uploaden plaats zou vinden voordat het bestaande script de Arduino weer zou doen vastlopen.
Lees verder….

Deel dit bericht:
jun 022014
 

MQTTTijdens het schrijven van de post over de robots gisteren, kwam ik een term tegen die ik nog niet kende, maar die wél al heel lang blijkt te bestaan: MQTT of: MQ Telemetry Transport, in 1999 bedacht door Dr Andy Stanford-Clark van IBM en Arlen Nipper van Arcom (tegenwoordig Eurotech).

Het is een lichtgewicht protocol voor berichten tussen apparaten. De werking is heel simpel: je hebt minimaal drie partijen (apparaten/programma’s) nodig: een sender, een ontvanger en daar tussenin een ‘broker’. Dit is een plek waar de zender de informatie aflevert en de ontvanger de informatie op haalt. En natuurlijk kan een broker meer dan één zender aan en kunnen meerdere ontvangers dezelfde informatie ophalen. En het kan ook zijn dat één ontvanger de informatie van meerdere ontvangers verzameld/combineert.

Daarbij hoeven zender en ontvanger niets van elkaar te weten. Het kunnen verschillende hardwareplatformen zijn en verschillende programmeertalen. Zo beschrijft dit voorbeeld de communicatie tussen een BeagleBone Black die Python gebruikt en een Raspberry Pi waar Java op draait. Beide apparaten hoeven niet van elkaars bestaan te weten, ze hoeven niet in hetzelfde netwerk te zitten, als de ene er even niet is, dan heeft de andere er niet direct last van. Zolang de broker maar in de lucht is.
Lees verder….

Deel dit bericht:
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.

Deel dit bericht:
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.

 

Deel dit bericht:
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….

Deel dit bericht:
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….

Deel dit bericht:
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.

 

Deel dit bericht:

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….

Deel dit bericht: