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:
dec 202017
 

Vandaag vindt in Amsterdam bij De Waag Society de workshop plaats ter voorbereiding van de meting van de luchtkwaliteit tijdens de jaarwisseling 2017-2018. Dit doen ze weer samen met het RIVM die een hele site heeft over het samen meten aan luchtkwaliteit. Ze zochten deelnemers in Amsterdam en daar woon ik niet, dus helaas. Op de site van het RIVM (b)lijkt het echter niet alleen om metingen in Amsterdam te gaan, logisch eigenlijk ook natuurlijk. Op die site staat ook dat ze dit jaar met The Things Network (TTN) en LoraWAN aan de slag gaan. Extra interessant natuurlijk.

Dichter bij huis, in Venlo, werken studenten van Fontys bij het Greentechlab aan een experiment voor (o.a.) tijdens de jaarwisseling. Omroep Venlo had er een reportage over (klik even door voor de video). Hier geen uitgebreide pagina, maar ik herken in het filmpje de Marvin van RDM Makerspace, dat betekent in ieder geval dat ze ook met LoraWAN aan de slag gaan. Niet duidelijk is of ze dan KPN gebruiken (en bv een demo-account) of “gewoon” TTN. De standaard bijgeleverd temperatuur en vochtigheidssensor zit er ook aan. Ik kan in het filmpje niet zien welke sensor ze gebruiken. Want daar zit nogal wat variatie in.

Het RIVM heeft er een hele pagina over online staan (en de website bevat nog veel en veel meer info). Het wordt dan al heel snel “technisch” met term en als PM 2.5 en PM 10. De getallen 10 en 2.5 verwijzen naar de afmetingen van deeltjes die gemeten kunnen worden in microns (micrometers). Dan heb je het over klein en nog kleiner. Het RIVM blijkt te meten met PM10, dus deeltjes van 10 micrometer en kleiner. Dat is een beetje balen want de sensoren die ik heb liggen (nog niet getest overigens) meten 2,5 micrometer en kleiner. Dat lijkt dan nauwkeuriger, maar als we het hebben over “fijnstof” dan telt alles van 10 micrometer en kleiner mee.  En dus is het handiger om in diezelfde maat te meten. Overigens, voor fijnstof geldt hoe kleiner de deeltjes hoe slechter en hoe minder van alles hoe beter. Er is geen veilige ondergrens.

Ik heb het RIVM om meer info gemaild. De sensor die zij gebruikten, de Shinyei PPD 42NJ  zou ik deze week nog in huis moeten kunnen hebben. De aansluiten op de Marvin moet relatief gemakkelijk zijn, dan zou het vooral gaan om de vraag hoe ik verbinding maak met de centrale backend van het RIVM om er voor te zorgen dat mijn data uit Deurne ook in hun overzicht/meting opgenomen wordt.  Wordt (hoop ik) vervolgd.

p.s. de kaarten met overzichten van de niveaus fijnstof zijn best verontrustend.

Deel dit bericht:
dec 022017
 

Google heeft weer een geinig nieuw experiment de wereld in gestuurd: Paper Signals. Het principe is heel simpel: je print een vouwmodel op papier, knipt het uit volgens de instructies. Je neemt een ESP8266, een servomoter en 3 kabels. Vouw het geheel samen. Maak een account aan bij Google zodat je via je smartphone en Google Assistent commando’s aan het “signal” door kunt geven. Zet de benodigde code op de ESP8266 (kwestie van wat variabelen in een bestandje aanpassen voor jouw wifi-netwerk, jouw code bij Google etc en dan uploaden). En klaar.

Het resultaat is dan bv een signal met een paraplu er op die open gaat wanneer het gaat regenen. Je geeft dan via de Google Assistent, met stemcommando’s, door dat die bepaalde signal het weer in jouw woonplaats bij moet houden.  Zo hebben ze al een voorbeeld voor een signal voor raketlanceringen, een countdown klok (leuk voor in de klas om af te tellen naar de Kerstvakantie), eentje voor het weer die aangeeft of het korte broeken weer is of niet (voor de meeste leraren is het nooit korte broeken weer in de klas!!). Maar je kunt ook zelf nieuwe sjablonen verzinnen.

Google gebruikt voor hun kit de Adafruit Feather HUZZAH en die is niet heel goedkoop. Maar als ik naar de bijgevoegde code kijk, dan zit daar op het eerste oog niets in dat niet op een willekeurig ESP8266 zou kunnen draaien. Ik heb het nog niet kunnen testen, maar dit zou ook op een Wemos D1 mini van 2 euro uit China moeten kunnen werken. Logisch ook omdat de ESP8266 niet veel hoeft te doen. Hij hoeft alleen via WiFi contact te maken met de Google dienst, te luisteren naar opdrachten die hem vertellen hoe de servo moet draaien en de servo op basis daarvan aansturen.

Let op! Ik ga er vanuit dat dit een experiment is van Google dat met name op de Google Assistant gericht is. Garantie dat de API en de dienst jaren in de lucht blijft heb je bij Google sowieso niet vaak. Maar ja, dan haal je de onderdelen toch weer uit elkaar en gebruik je ze voor wat anders?

 

 

Deel dit bericht:
nov 272017
 

Ondanks alles zijn kinderen nog lang niet zo’n nerd of geek als hun papa is. En hoewel ik natuurlijk sowieso helemaal niet over ze mag klagen, kreeg ik vandaag toch nog wel weer wat meer hoop. Vandaag kwam namelijk weer eens een pakje uit China binnen. Nu met zo’n “bekende” 37-in-1 sensorkit. Een zakje (ik had niet gekozen voor de duurdere versie met doosje) met daarin 27 verschillende sensoren voor aan de Arduino, de ESP8266 of de micro:bit.

Totale kosten zo’n 10 euro, geen geld dus. Ongetwijfeld niet de meest hoogstaande kwaliteit, maar elke sensor zit al op zijn eigen printplaatje met pinnen om meteen een dupont-kabeltje op aan te sluiten.

Wat me positief verraste was de belangstelling en de nieuwsgierigheid die het pakje met sensoren opwekte. Niet omdat ze iets moesten of wilden bouwen. Nee, gewoon nieuwsgierig naar waar al die 27 sensoren voor dienden, wat je er mee kon doen. Sommigen kenden ze al (relais, thermometer etc.) maar andere ook weer niet. Het bijbehorende kaartje bevat niet meer dan alleen een afbeelding van de sensoren en de bijbehorende naam. Ze kunnen er via YouTube dus heel eenvoudig achter komen.

Maar dat moet nog even wachten want komend weekend “moeten” we eerst nog een Sinterklaas surprise in elkaar knutselen op basis van een servo, een ATtiny85, LEDjes, hout, verf,…..
De week erna hebben we wél tijd. Ik ben eens benieuwd hoe ver we komen.

Dat kinderen alleen maar willen gamen en tv kijken is net zoveel onzin als dat hele digital natives verhaal van voorheen. 🙂

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:
apr 102017
 

Als het in het onderwijs in Nederland over “programmeren” gaat worden eenvoudige vragen al heel snel ingewikkeld. Dus een vraag als “Welke programmeertalen zouden onze leerlingen/studenten moeten kennen?” (bron) is niet helemaal zonder risico. Immers, je moet dan gaan nadenken over het doel dat je daarmee hebt. Wil je ze leren programmeren? Of juist coderen? Of software ontwikkelen? Ik ga niet eens proberen naar bronnen te linken die ze op één hoop of op juist heel verschillende hopen (en dan per bron ook verschillend) gooien.

Dus laat ik het maar even veilig houden in deze blogpost. Zo’n 9 jaar geleden vroeg ik me af welke programmeertalen ik allemaal zou moeten leren. Zoals ik toen beschreef:   Basic was mijn eerste kennismaking met programmeren, maar daar kon je (toen) zo weinig mee dat ik er niet veel interesse voor had. Op de universiteit leerde ik Turbo Pascal om daar vervolgens nooit meer wat mee te doen. Daarna kwam ik in de Windows omgeving en Visual Basic (binnen Office!) en Active Server Pages (ASP) terecht. Mijn eerste kennismaking met JavaScript was in de browser, ASP werd vervangen door PHP toen ik weblogtools ging gebruiken op basis van die taal. En daarna werd het een opeenvolging van “wat heb ik nodig”. Zo kwam er een beetje Python bij, een heel klein beetje .NET en eveneens een klein beetje Java. Dat was toen. Sindsdien zijn er dingen gewijzigd en gelijk gebleven.

Lees verder….

Deel dit bericht:
mrt 112017
 

Toen ik afgelopen week met de micro:bit en de Circuit Playground (CPG) aan de slag ging, lukte het me niet om via serial een verbinding tussen de CPG in de richting van de micro:bit op te zetten in combinatie met de CPG library. Zónder die library kon ik dataverkeer beide kanten op realiseren, zodra ik de library initialiseerde met CircuitPlayground.begin(); ging er geen verkeer meer de kant op van de micro:bit.

De oplossing bleek te liggen in het gebruik van de hardware serial aansluitingen van de CPG in plaats van software serial waarmee ik aan de slag was. Tot nu had ik alleen met de hardware serial gewerkt als het ging om communicatie via de USB-poort van een Arduino. Dat deed ik dan via bv via Serial.println("Setup complete"); waarbij ik dan in de Serial monitor op mijn computer de output kon zien, ideaal voor het debuggen. Als een Arduino board een hardwarematige seriële aansluiting heeft (soms hebben ze er meer dan 1), dan kun je de andere hardwarematige poorten ook gebruiken. Die heten dan achtereenvolgens Serial1, Serial2 etc.
De hardwarematige poorten werken prima samen met de CircuitPlayground code. Ik heb een nieuwe versie van het script op Bitbucket gezet. In CPG_Serial_Slave.ino staat de versie met de softwarematige seriële poort in CPG_Serial_hardware.ino staat het script beter werkt en dan de hardwarematige seriële poorten gebruikt. De code op de micro:bit is nog steeds dezelfde microbit-Serial-Count-Master_and_Slave.hex die je hier kunt vinden.

De werking is als volgt: nadat beide script op respectievelijk de micro:bit en de CPG geladen zijn wachten de boards op een start teken. Door op de B-knop van de micro:bit te klikken begint het script daar. De micro:bit laat een tekst zien op het display waarin aangegeven wordt dat eerst een 0 (nul) naar de CPG gestuurd wordt. De CPG wacht totdat er data via de seriële lijn binnen komt. Is dat het geval, dan wordt de string die ontvangen is omgezet in een getal. Er worden dan evenveel Neopixels aangezet als het getal hoog is. Dan wordt hetzelfde getal terug gestuurd. Dat lijkt zinloos, maar de micro:bit wacht op het terug ontvangen van een getal voordat hij verder gaat, zo blijven beide processen in sync. De micro:bit laat zien dat hij +1 bij het getal optelt voordat hij het terug stuurt. Dat gaat verder totdat het getal groter is dan 10. Er zijn maar 10 Neopixels, dus reset de micro:bit het getal dan naar 0 en stuurt de 0 door zodat ook op de CPG alle Neopixels uitgeschakeld worden.

Ook dit was een test om het communicatiemechanisme beter te begrijpen. Interessant wordt het als ik nu een telefoon via Bluetooth aan de micro:bit koppel en instellingen draadloos door kan geven, of een WeMos D1 ESP8266 chip (kost zo’n 3 euro) om er voor te zorgen dat de CPG alsnog over een Wifi-verbinding kan communiceren. Dat zou via Firmata moeten kunnen, want ook die kan zowel via USB als via de hardwarematige seriële poort aangestuurd worden. Wordt dus later vervolgd.

Deel dit bericht:
nov 292016
 

Nee, ik ben niet bang dat ik komende kerstperiode teveel Glühwein drink en dan van zottigheid tegen mijn kerstboom ga staan lopen kletsen. Het was echter een vraag die toch wel in me op kwam toen ik bovenstaand filmpje van Adafruit bekeek. Daarin koppelen ze een Alexa en een Echo aan een ESP8266. Het resultaat is dat ze met spraakcommando’s in staat zijn om bv een relais te schakelen of om LED’s aan te laten schakelen.

Vorig jaar heb ik voor het eerst de verlichting van onze kerstboom op afstand bestuurbaar gemaakt (de verlichting dan) met mijn smartphone. Sindsdien zijn er meer apparaten in huis op onze OpenHab server aangesloten, en komende kerstperiode zal dat dus in ieder geval geen uitdaging meer zijn. En je weet, dan is er dus ruimte voor nieuwe uitdagingen.

Om meteen maar even de conclusie te verklappen: nee, het zal dit jaar naar verwachting niet gebeuren.

Heel belangrijke praktische reden: de Alexa en Echo Dot zijn nog niet in Nederland te koop. Los daarvan is een apparaat van bijna 200 dollar ook wel heel erg veel geld om tegen mijn kerstboom te kunnen praten.

Maar als ik Amazon Alexa zeg, dan denk ik natuurlijk ook aan de Google Home. Is dat dan wellicht een alternatief?

Lees verder….

Deel dit bericht:
sep 142016
 


Het woord “Mesh-netwerken” in titel is eigenlijk helemaal fout, het zijn eigenlijk “Mesh networks” in het Engels over “Vermaasde netwerken” in goed Nederlands. Maar bij vermaasde netwerken zijn er nóg minder mensen die een idee hebben waar ik het over heb. Dus ook nu eerst even wat achtergrond: normaal gesproken als wij met onze laptop, iPad, smartphone of ander draadloos of zelfs bekabeld apparaat verbinding maken met het / een netwerk, dan is er een duidelijke rolverdeling. De laptop, iPad etc. is een node die verbinding maakt met een ander apparaat dat als belangrijkste taak heeft om toegang te verlenen tot het netwerk, tot internet, tot een server etc.
Dat kan een Wifi router zijn die het signaal van jouw apparaat ontvangt en dan doorgeeft via het bekabelde netwerk naar een ADSL router of een andere aansluiting met het internet etc.
Kenmerkend daarbij is dat er een infrastructuur beschikbaar is die daar specifiek voor aangelegd is. Maar wat nou als je sensoren hebt die op plekken moeten kunnen functioneren waar je geen vaste netwerkaansluiting hebt of waar nog geen WiFi-netwerk ligt of geen netwerk waar jij toegang toe hebt? In het bos of gewoon in een stad zelfs?

Dan kun je kiezen voor een netwerktechnologie die een heel groot bereik heeft, zoals bij een LoraWAN of je kunt betalen om toegang te krijgen tot een WiFi-netwerk van een ander of een mobiel netwerk (via GPRS of 3G/4G).
Maar wat nou als het helemaal niet zo noodzakelijk is dat je verbinding maakt met de buitenwereld. Wat als je eigenlijk vooral wilt kunnen communiceren met andere nodes die bij jou in de buurt zijn? Bijvoorbeeld met andere robots (zoals in dit voorbeeld), of wellicht straks zelfs andere zelfsturende auto’s.

Dan is een mesh-netwerk een oplossing. Daarbij is elke node gelijkwaardig aan elkaar en is er geen specifieke infrastructuur voor de onderlinge communicatie nodig. Vroeger, toen al die netwerken via kabels moesten worden aangelegd, was dat moeilijk schaalbaar (alles met alles verbinden via kabels wordt al snel een warboel), maar tegenwoordig met draadloze netwerken (via WiFi, Bluetooth of wellicht straks via Lora) is dat veel eenvoudiger.

De demo hierboven is leuk, het laat goed een sterke eigenschap zien: valt een node uit, dan werken de anderen gewoon verder, komt er eentje bij, dan wordt hij automatisch in het Mesh-netwerk opgenomen. Maar het gaat hier wel om een heel naïef netwerk waarbij elke node automatisch ook de informatie van de andere nodes vertrouwd. En dat zal niet altijd het geval zijn. Ook moeten de pakketten data die rondgestuurd worden niet té groot worden anders is elke node voornamelijk bezig met het afhandelen van de data van de andere nodes.

De code voor bovenstaand voorbeeld is hier op Github te vinden.

Deel dit bericht: