okt 282018
 

De site/toepassing is niet nieuw, maar ik had simpelweg nog geen reden gehad om er eerder naar te kijken: MIT App Inventor.

Vandaag heb ik er voor het eerst mee geëxperimenteerd. De aanleiding is een wat groter project waarbij ik sensorwaarden die via een ESP32 worden verzameld direct op een mobiel apparaat wil kunnen ontvangen (dus niet via WiFi / MQTT etc). Het idee is om daar BLE (Bluetooth Low Energie) voor te gebruiken, de ESP32 heeft standaard WiFi en BLE ingebouwd. Maar de standaard apps die je voor BLE kunt downloaden hadden wat moeite met het verwerken en zeker met het netjes weergeven van de data die op deze manier binnen kwam. Zelf een app bouwen voor iOS of Android had ik in het verleden wel al eens geprobeerd, maar in beide gevallen was het installeren van de benodigde tools/software en het krijgen van een basisbegrip van hoe e.e.a. werkt al voldoende reden om daar niet teveel extra tijd in te steken.

Ik was dan ook een beetje sceptisch toen ik de verwijzing naar MIT APP Inventor tegenkwam. Maar, de eerste indruk na een paar uurtjes testen is heel positief. Goed, de eerste beperking voor nu is nog dat er nog geen ondersteuning is voor iOS. Dat was voor mij geen echt probleem, ik heb beide ter beschikking.
Heel prettig is wat mij betreft dat ik meteen in de online omgeving aan de slag kon. Ik kon met een Google account inloggen, naar keuze voor mij dan dus via @gmail.com of via @ixperium.nl omdat we Google Apps for Education gebruiken. Maar helemaal mooi werd het na het koppelen van mijn Android toestel via de MIT AI2 Companion App die ik via Google Play kon installeren. Na het scannen van een QR-code of het invoeren van een korte code werd mijn toestel gekoppeld aan het project waar ik mee bezig was. Dat betekende dat wijzigingen meteen werden doorgevoerd en te testen waren.

Het bouwen van een applicatie voelde heel vertrouwd, enerzijds heb je de ontwerpomgeving waar je knoppen, lijsten etc. op je scherm plaatst. Om er voor te zorgen dat die knoppen daadwerkelijk iets doen gebruik je de “Blocks” omgeving. Als je met Scratch kunt werken of met de Blocky achtige omgevingen zoals ook bij de Micro:bit gebruikt worden, dan kun je hiermee eenvoudig overweg.
En ook wijzigingen die je hier doorvoert worden meteen in de app op je smartphone doorgevoerd.

Heb je app helemaal klaar, dan kun je een .apk bestand downloaden op je smartphone. Dat is dus een “echte” app die gewoon zelfstandig werkt, los van de online omgeving. Nou staan de meeste smartphone tegenwoordig zo ingesteld dat ze niet zomaar apps installeren die niet in Google Play staan. Maar als het goed is, dan is dat één vinkje dat je moet aanzetten. Ik heb nog niet uitgezocht hoeveel werk de optie is om je app via Google Play te delen via App Inventor, want dat is voor mijn doel niet nodig.

Conclusie
Voorlopige conclusie is dat deze omgeving voldoende flexibiliteit biedt voor wat ik nodig heb.  De app is nog niet klaar dus nog geen filmpje etc. van het eindresultaat. Dat wordt nog vervolgd.

Deel dit bericht:
okt 062018
 

Sinds de Micro:bit beschikbaar kwam is er een groot aantal accessoires op de markt gekomen die het kleine, oorspronkelijk op het onderwijs gerichte, apparaatje eenvoudiger koppelen met andere hardware. Zie bijvoorbeeld deze pagina bij Kitronik. Soms kan ik me er heel wat bij voorstellen. Neem bijvoorbeeld dit boardje om als batterij een knoopcel te kunnen gebruiken (en een buzzer toe te voegen). Dan voeg je 5 GBP toe aan de kosten, maar heb je wel een heel compacte setup.

De GAME ZIP 64 is dan weer zo’n accessoire waar ik wat meer vraagtekens bij heb. Die kost bijna 40 GBP en dan krijg je “the ultimate retro handheld gaming platform for the micro:bit”. Niet alleen is die prijs enorm (ruim 2x meer dan je voor de Micro:bit betaald) maar het wordt natuurlijk nooit een echt ultiem retro handheld gaming platform.

Datzelfde heb ik bij de Kickstarter van PiSupply. Daar kun je onder andere een boardje ‘kopen’ (afhankelijk van of ze hun doelbedrag halen) waarmee je van je Micro:bit een node in het LoRaWAN netwerk van The Things Netwerk kunt maken. De Early Bird kosten van dat geheel, inclusief verzendkosten naar Nederland bedragen omgerekend 36 euro. Ook dat is een stevig bedrag, maar ook hier heb ik de vraag of LoRaWAN op een Micro:bit zinvol is. De reden dat je LoRaWAN gebruikt is als je weinig data hoeft te versturen, mogelijk niet binnen bereik van WiFi bent, 4G een (te) dure optie is én als je weinig vermogen wilt gebruiken. Dus als je apparaten wilt maken die zo lang mogelijk op een batterij meekunnen. En als ik iets geleerd heb van de talrijke video’s die Andreas Spiess gemaakt heeft over het onderwerp (zeer de moeite waard overigens) dan is het dat ook gewone ontwikkelborden, dus borden waar de LoRa chip en processor al geïntegreerd meestal niet zo geoptimaliseerd zijn als kan. Logisch, je ruilt eenvoud van gebruik in voor meer stroomverbruik.

Dan zie ik liever de constructies zoals Pauline Maas ze in Eindhoven bij de Maker Faire gebouwd had. Soms wat gelikter met onderdelen uit de 3D printer, andere keren gewoon met karton of met een 5 cent muntje als koppeling tussen meerdere kabels met krokodilbek. Niet iets wat je gebruikt voor een constructie die meerdere maanden/jaren zonder problemen moet werken. Maar voldoende voor een tijdelijk project of een prototype.

Laat ik positief afronden. Ik heb de Kickstarter gebackt voor 1 node. Nog even wachten tot maart 2019, áls ze hun deadline halen natuurlijk. Ik bestel hem, zal hem testen en laten horen hoe goed hij werkt. Als test, niet als ding dat ik permanent ergens ga installeren.

 

 

Deel dit bericht:
jan 132018
 

Time for part 2 of the post about getting the “cheap” Chinese ESP32 + SX1276 board connected to The Things Network.

The picture in this and the other post shows the board with a DHT11 temperature and humidity sensor already connected. I stopped using the small case that was on sale, because with the pinheaders soldered to the board and dupont cables connected to it, it no longer fitted.

Also, I am no longer using the small antenna that was provided with the board. I seem to have accidentally twisted the cable that you use to connect the SMA socket to the U.FL IPX connector on the board. The only suitable antenna I had available, was one that was provided as part of the LoPy kickstarter kits (which apparently is different from the antenna sets they sell now). The antenna I got in the kit is a RP-SMA antenna meaning the cable is also RP-SMA. Long story short: I can connect the LoPy cable + LoPy antenna to the board, but the the provided small antenna won’t fit on the LoPy cable. With the LoPy antenna combi I’ve been able to get about 500 meters range outdoors, combined with the single channel LoPy nanogateway. Which is absolutely not bad at all, also given that I’m fixed not to just one channel there but also to SPF7. I’ll do further comparisons once the replacement cable has arrived.

So, the DHT11 sensor. It helped that I managed to figure out that the provided pinout chart was incorrect. Once I know to which actual ports the DHT11 was connected, it was a matter of integrating the library and code into the existing code.  To keep the number of things that could go wrong manageable, I first tested jut the DHT11 code. I provided an example here. If that doesn’t work, don’t bother with the connection to TTN.

Lees verder….

Deel dit bericht:
jan 132018
 

The previous post about the LoRa board I bought via Aliexpress, I did in Dutch. I should have know that, like often happens with the more technical posts on my blog, the majority of people interested in it are not from the Netherlands.
So, this follow-up post about connecting a sensor to it, I’ll do in English again.

I will do the quick summary of the previous post first, so you’ll have an all-in-one topic:

This board was the first one I bought of Aliexpress. It was cheap, €13,9 incl. shipping for ESP32 + SX1276 + 0.96 inch OLED. ESP32 means WiFi (like you have with the ESP8266) *and* Bluetooth build in. If you compare that to a LoPy (about 50 euros) or a Marvin (about 85 euros), that is cheap. Problem though with Aliexpress is that you don’t always get a nice manual with the device.
Luckely there is a very active forum at The Things Network, and they have a topic specific for this combination of ESP32 and SX1276 chip. A number of people, much smarter than me, took the time there to figure out how to setup the board. All I had to do is go through their posts.

Lees verder….

Deel dit bericht:
jan 102018
 

Tot voor kort had ik 2 verschillende LoraWAN nodes in huis: een tweetal LoPy‘s, waarvan er eentje dienst doet als single channel gateway en een Marvin. Beide zijn niet bijzonder goedkoop, een LoPy met ontwikkelbordje en antenne kost zo’n 50 euro excl. verzendkosten. Een Marvin kost bijna 85 euro excl. verzendkosten. Niet echt sensoren dus die je ergens “kwijt” wilt raken. Terwijl een LoraWAN sensor toch juist vaak op een plek moet komen te hangen die iets verder van alles weg is (zoals sensoren langs een weg die fijnstof meten of zo).

Je kunt zelf een sensor bouwen door een chip te bestellen voor de communicatie, een ESP8266 te kopen, antenne etc en dan solderen. Maar dat kost tijd en extra werk.  De “868MHz/915MHz SX1276 ESP32 LoRa 0.96 Inch Blue OLED Display Bluetooth WIFI Lora Kit 32 Module IOT Development Board for Arduino” zoals de listing op AliExpress voluit luidt, is een voorbeeld van een tussenweg: voor €13,90 incl. verzendkosten heb je een ESP32 + SX1276 chip op een ontwikkelbord. Als je het LCD-scherm dat er dan op zit niet nodig hebt, kun je nog een paar euro besparen en €10,29 betalen incl. verzendkosten. Het is niet mijn eerste node op basis van een ESP32, ook de LoPy maakt daar gebruik van, maar het was wel de eerste die ik via AliExpress bestelde. En ik wist dat het daar bestellen een keerzijde heeft: documentatie is niet altijd voorhanden.

Gelukkig is er ook een heel actief forum bij The Things Network waar een heel topic specifiek voor deze combinatie van ESP32 en SX1276 chip (inclusief het OLED schermpje) ingericht is. En daar hadden sinds oktober 2017 al een paar slimme mensen alles uitgezocht wat ik nodig had om ook mijn exemplaar aan de praat te krijgen. En omdat het een proces is dat ik over een paar maanden zeker niet meer uit mijn hoofd weet te herhalen, documenteer ik het hier weer even.

Lees verder….

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:
jan 012018
 

Als je dit weblog regelmatig bezoekt, dan weet je dat we afgelopen week druk bezig zijn geweest met het last-minute deelnemen aan een experiment dat het RIVM, samen met anderen nu voor het tweede achtereenvolgende jaar uitgevoerd hebben: het meten van de hoeveelheden fijnstof tijdens de jaarwisseling.

Daarbij wordt gebruik gemaakt van relatief goedkope sensoren die door particulieren ook zelf opgehangen kunnen worden. Dat brengt uiteraard veel uitdagingen met zich mee, zo hebben wij zelf ook gemerkt toen we wilden deelnemen. Naar aanleiding van de aankondiging heb ik al een tweetal blogposts geschreven naar aanleiding van informatie die ik sindsdien gevonden had: blogpost #1 en blogpost #2. Zoals zo veel dingen lijkt het eenvoudig, maar komt er toch heel wat meer bij kijken als je het goed wilt doen.

Omdat het voor ons onmogelijk was om een Nova SDS011 sensor tijdig in huis te krijgen, zijn we aan de slag gegaan met een Shinyei PPD 42NJ samen met een BME280, een super kleine geïntegreerde sensor voor zowel luchtvochtigheid, temperatuur, luchtdruk en hoogte. Dat geheel werd in een PVC T-stuk bevestigd en achter het Frans balkon van ons huis opgehangen. De gebruikte code was een combinatie van de code van het RIVM van vorig jaar (voor de Shinyei) met de code van dit jaar (voor de SDS011 + BME280). Ik heb de code nog iets verder aangepast op basis van het script waar ik eerder over schreef zodat we ook zelf de ruwe waarden van de sensoren konden volgen. Dat was maar goed ook, want op de officiële site bleef de lijn van de meting bijna vlak:

 Sowieso worden voor de Shinyei sensoren alleen de ruwe PM2.5 metingen doorgegeven die dan op de server omgerekend zouden moeten worden naar µg/m3. Of dat hier helemaal goed gaat weet ik niet, maar omdat onze sensor pas 2 dagen voor de jaarwisseling online kwam ontbrak het aan de mogelijkheid hier nog echt contact over te hebben met het RIVM. Voor de duidelijkheid: vanuit het RIVM werd de afgelopen heel snel, vriendelijk en uitvoerig via de mail gecommuniceerd. Niets dan complimenten daarover!

De stevige piek die je in de afbeelding ziet was toen ik na registratie toch even het script met de omrekening gebruikt had (foei). Maakt niet uit, de grafiek die ik in Google Sheets liet maken (met dat stukje eruit geknipt) laat wél voldoende verschil tussen (ruwe) waarden zien om interessant te zijn.

Lees verder….

Deel dit bericht:
dec 302017
 

Een blogpost over een oplossing waarvan ik zelf inmiddels al geconstateerd heb dat hij tóch niet zo handig is? Moet kunnen. Want ik wil in ieder geval even documenteren hoe ik e.e.a. voor elkaar gekregen heb. Wie weet heeft iemand anders er toch nog wat aan.

Naast de fijnstofsensor voor het RIVM experiment heb ik er ook eentje gemaakt die ik in de woonkamer opgesteld heb. Gewoon om te zien hoe in huis eventueel het niveau fijnstof zou stijgen als we in de keuken aan het koken waren, of een paar uur wafels stonden te bakken.

Ik wilde de data snel kunnen verwerken zonder teveel gedoe met databases of zo, zou het niet handig en mogelijk zijn om de data op te slaan in een Google Sheet?

Ik weet inmiddels dat als ik het kan verzinnen, iemand anders dat ongetwijfeld ook al gedaan heeft. Zo ook nu. En lang geleden al.In 2011 schreef Martin Hawksey een script waarmee  je via een URL data door kunt geven aan  een Google Sheet. Je moet een Sheet aanmaken en dan in de Script editor het script inplakken. Eenmalig moet je dan de Setup() procedure uitvoeren en via Publish > Deploy as web app het script publiceren. Daarbij moet je er dan voor kiezen om het script ook voor “Anonymous” beschikbaar maken. Google zal dan moord en brand schreeuwen omdat het script niet door hen getest is etc.

De werking is dan eenvoudig. Op de eerste rij van de sheet zet je de namen van de waarden die je wilt doorgeven. Tip: noem de eerste kolom “Timestamp”, dan voegt het script automatisch datum en tijd in waarop de nieuwer data is ingevoerd.

Daarna kun je via GET of POST de data doorsturen naar de Google Sheet waarbij elke waarde gelijk moet zijn aan de titel van een kolom (hoofdlettergevoelig).

Ik gebruikte een NodeMCU ESP8266. Omdat Google een beveiligde verbinding gebruikt moet je gebruik maken van een andere bibliotheek dan normaal:

#include <WiFiClientSecure.h>
en
WiFiClientSecure client2;

Lees verder….

Deel dit bericht:
dec 282017
 

OK, één bericht nog dan voordat ik ga schrijven over onze eerste fijnstofmeter die (als alles volgens plan gaat) ook tijdens de jaarwisseling online te volgen is.

Naast de bestelde Shinyei PPD42 die vorig jaar door het RIVM gebruikt is, hebben we een tweetal DSM501 modules van Samyong in huis en blijkt er nog een Plantower PMS5003 onderweg te zijn die (vanwege een wat vaag leveringsprobleem) waarschijnlijk ingehaald wordt door de Novafitness SDS011 die het RIVM dit jaar gebruikt (en die ook door o.a. OK Lab Stuttgart gebruikt wordt).

Dus was ik verder op zoek gegaan naar info specifiek voor die sensoren.

In dit bericht over de DSM501 module wordt ook gesproken over de Air Quality Index (IAQ, IQA) en de bijbehorende verschillen tussen de  Europese Common Air Quality Index (CAQI) die in 5 stappen van 0 tot 100 loopt en de 6 niveaus van de AQI index die in de VS en China gebruikt worden en die van 0 tot 500 (of meer) loopt. En er blijken meer smaken te zijn. Het bericht legt uit hoe de verschillende indexen te berekenen.

Op het forum van The Things Network kun je een hele thread vinden over sensoren met de nodige verwijzingen. Hier is een beschrijving te vinden van (nog) een oplossing gebaseerd op LoraWAN

Het aansluiten van de PMS5003 gaat net weer wat anders dan van de andere sensoren, maar ook daar is informatie over te vinden online. Hij maakt gebruik van een seriële verbinding, net zoals (zo begrijp ik van het RIVM) de SDS011.

Dit bericht ten slotte is niet erg positief over de betrouwbaarheid van de PPDN402 en op dit blog deden ze een test in de keuken waarbij de conclusie was dat het aantal deeltjes dat daar de lucht in geslingerd wordt minstens zo erg is als buiten.

Lees verder….

Deel dit bericht:
dec 212017
 

In de categorie “zodra je je ergens in begint te verdiepen ontdek je hoe weinig je er over weet/wist” even een follow-up op mijn bericht van gisteren over het zelf meten van fijnstof. Joost Wesseling van het RIVM reageerde dezelfde avond (laat) nog op mijn vraag voor wat meer informatie over het initiatief om tijdens de jaarwisseling zelf mee fijnstof te meten. Uit zijn mail bleek dat ze bij het RIVM (uiteraard) ook weten van het Venlose initiatief en Teus Hagen. Ze zijn afgelopen jaar bij hem op bezoek geweest (filmpje).

Op de YouTube pagina van Samen milieu meten vond ik ook nog een paar andere filmpjes die antwoord geven op vragen die ik nog had. Bijvoorbeeld over de te kiezen behuizing voor het geheel. Er staan 3 low-tech voorbeelden online: PVC T-stuk (video door Joost), yoghurt-emmer, plastic fles. Ik wist dat ik zelf een 4e optie gezien had op een van oorsprong Duitse site, maar die ook info in het Nederlands aanbieden: PVC bochten. Die site van OK Lab Stuttgart is sowieso een plek waar je wel een uurtje zoet kunt zijn. Je kunt daar je sensor ook aanmelden zodat jouw metingen permanent, dus niet alleen tijdens oud en nieuw op een online kaart weergegeven worden. Ook hier met ondersteuning voor Nederland en er zijn nog genoeg plekken waar nog niet gemeten wordt.

Op instructables.com staat een beschrijving van het opzetten van een configuratie met de Shinyei PPD42 sensor waarbij ze een belangrijke hack toepassen: ze plakken de opening bij het detectiegebied af zodat er geen licht op valt, dat schijnt de hoeveelheid “ruis” bij de metingen te verminderen.

Ook heb ik inmiddels de beschrijving gevonden van het gebruik van de Shinyei sensor in combinatie met The Things Network (TTN). Het voordeel daarvan is dat je sensoren ook kunt ophangen in gebieden waar je geen toegang tot een draadloos netwerk hebt, al is dit wel een sensor waarvoor je een stopcontact in de buurt moet hebben want op een batterij gaat het vanwege de continue metingen niet werken.

Bij de beschrijving van de TTN-oplossing werd verwezen naar de behuizing die je hierboven bij het bericht afgebeeld ziet. Kost zo’n €20,- in aanschaf. Iets duurder, maar als je niet zo van het knutselen bent wat mij betreft ook wel een optie.
Lees verder….

Deel dit bericht: