jul 202020
 

In de categorie: het is vakantie en dus eindelijk tijd voor….

Ik had al een tijdje een viertal Avatar AWP07L Power Monitoring Plugs liggen. Afkomstig van Amazon in Duitsland, zijn het stekkerplugs die je tussen een apparaat (of apparaten) en het stopcontact plugt. Er zit een handmatige knop op om de plug aan en uit te zetten, maar uiteraard kun je ze ook via het netwerk bedienen. De plugs maken verbinding met je Wifi netwerk en als je er Tasmota op zet dan kun je de verbruiksdata via o.a. Home Assistant (met dank aan MQTT) uitlezen en de schakelaars op die manier besturen.

Het flashen van de firmware is even wat puzzelen, maar je hoeft gelukkig de plug niet uit elkaar te halen, het lukte mij allemaal OTA (Over The Air) op basis van deze instructies.

De pluggen zijn een stuk duurder (€6,- per stuk ipv €3,50 per stuk) dan de “oude” pluggen die ik heb van de Action. Maar dat is ook logisch gezien de verschillen:

  • Compacter  (veel!)
  • Gebruik van WiFi in plaats van 433Mhz voor de aansturing
  • Meten en doorgeven van energieverbruik

Met name dat laatste maakt ze ook zinvol als je per apparaat of groep apparaten (pc + printer + beeldschermen, een wasmachine, vaatwasmachine, oven etc) een beeld wilt krijgen van het energieverbruik. In dat geval zul je waarschijnlijk de schakelfunctie niet zo heel vaak gebruiken. Op dit moment heb ik ze aan een paar Raspberry Pi’s hangen die heel af en toe nog wel eens om onverklaarbare reden willen gaan hangen.

mei 062020
 

Vroeger was machine learning iets wat je alleen op een stevige computer voor elkaar kreeg. Niet zo’n probleem want inmiddels is een gemiddelde laptop meer dan krachtig genoeg. Maar wat nou als je een sensor hebt die niet krachtig is? En die niet de beschikking heeft over een high-speed breedband internetverbinding om contact te maken met een systeem dat de herkenning kan doen?

Dan wil je het trainen van het model níet op je sensor doen, maar de herkenning wél op de sensor. Dan hoeft die sensor niet grote hoeveelheden observatiedata over de lijn te sturen, maar alleen een seintjes áls er iets te melden is.

Lees verder….

mrt 012020
 

Het kon al op specifieke apparaten zoals de Lopy of in custom builds of als je Circuit Python gebruikte op hardware die daar ondersteuning voor heeft. Maar op de ESP32 had je tot voor kort nog niet de mogelijkheid om BLE (Bluetooth Low Energy) te gebruiken binnen MicroPython als je gebruik maakte van een van de officiële firmware images. Met ingang van release 1.12 is dat eindelijk wél zo. Flashen van mijn ESP32 deed ik volgens de instructies die hier staan. Nieuw, wat mij betreft, was ook dat Thonny, de gratis open source IDE voor Python (en MicroPython) ook ondersteuning heeft voor het rechtstreeks werken op de ESP32.

Dat was tot voor kort nogal een gedoe. Anders dan bij de apparaten die Adafruit maakt, kon je de ESP32 niet als USB-drive zien na aansluiten op je laptop. Maar de Thonny “ziet” de ESP32 en je kunt dan bestanden openen die er op staan (ander dan bij Arduino vindt compilatie niet al vooraf plaats dus je kunt de programmacode ook achteraf nog lezen), nieuwe bestanden aanmaken én je hebt de REPL beschikbaar om interactief commando’s uit te voeren die dan op de ESP32 worden uitgevoerd.

Dat maakt het debuggen een stuk gemakkelijker. Mauro Riva  heeft op zijn blog niet alleen blogposts over het gebruik van MicroPython staan (zoals deze over het zelf compileren van de firmware met BLE support), maar ook een github repository. Daar kun je ook een aantal voorbeelden vinden.

Lees verder….

feb 242020
 

Ik weet het: echte ontwikkelaars maken voor hun versiebeheer geen gebruik van Onedrive. Dan moet het op zijn minst via Github. Prima, gebruik ik ook, af en toe. Als iets af is, om te delen.

Maar als ik gewoon wat aan het klooien ben,  als ik bv een TCRT5000 sensor op de watermeter in de meterkast geplakt heb om het ronddraaien van het tellerschijfje te registreren en dat dan weer via MQTT over Wifi vanaf een ESP8266 door te sturen naar een Mosquitto-server zodat ik die waarden in Home Assistant weer kan geven en in influxDB kan archiveren, dan ben ik meestal eerst even gewoon met code aan het stoeien.
Met een beetje mazzel (zoals deze keer) met Over The Air (OTA) updates zodat ik niet op een krukje op USB-kabel lengte afstand van de meterkast hoef te blijven zitten.

Tijdens zo’n traject kan het wel eens voorkomen dat ik denk “oei, nu heb ik een stuk code weggegooid of aangepast en dat had ik niet moeten doen”.

In dat geval kan het helpen om het .ino bestand op te slaan binnen een map die gesynchroniseerd wordt met Onedrive. Privé of zakelijk maakt niet uit. Ik gebruik in dit geval mijn privé Onedrive. Het mooie van Onedrive (en waarschijnlijk een aantal van de andere beschikbare diensten ook) is dat hij aan versiebeheer doet. Dus in dit geval, waarbij ik een stuk code had verwijderd dat ik toch nog wilde gebruiken, ging ik naar onedrive.com, zocht daar de map en het programma-code bestand op en selecteerde een oudere versie. Onedrive kan ze niet online weergeven zodat je even snel kunt knippen en plakken, het bestand wordt gedownload naar je computer. Ook goed. Als backup voor foutjes tijdens het klooien in de Arduino IDE in ieder geval iets wat mij al wat tijd bespaard heeft vandaag. 🙂

sep 152019
 

Afgelopen vrijdag had ik, voor de tweede keer in mijn leven, de mogelijkheid om een tocht in een luchtballon te maken. De eerste keer was samen met mijn partner, ruim 20 jaar geleden, dus nog voordat de kinderen geboren waren. Ik had tijdens de SURF Onderwijsdagen 2018 geheel onverwacht 2 tickets gewonnen voor een ballonvaart en dus besloten we 2 tickets bij te boeken en met z’n vieren te gaan.  Zoals gezegd: vrijdag 13 september was het zover.

We hadden het aantal devices wat beperkter gehouden dan maximaal mogelijk was. Geen 360-graden camera bv, maar wel de GoPro 7 Black (met de GPS-optie op aan), Olympus Tough TG-6 (die ook GPS aan boord heeft, die we tijdens het duiken nog niet gebruikt hebben), onze eigen telefoons (waarvan de Samsung Galaxy S7 en S9 prima foto’s maken) én natuurlijk de TTGO T-Beam om het bereik binnen het The Things Netwerk in kaart te brengen vanuit de ballon.

Wil je weten hoe de ballonvaart was? Dat kun je zien in foto’s hier op Twitter of als filmpje hier op YouTube

Lees verder….

jun 192019
 

Last Monday I took my TTN-mapper node with me in the car driving from home (Deurne) to Nijmegen, to Arnhem, to Veenendaal and back home again in the evening. The gateways found were not really surprising. None for most of the trip to Nijmegen, good coverage in Nijmegen and Arnhem (and in between) . But there was one gateway that surprised me. While driving through “De Rips” (population 1,179 in 2011) a total of 3 packages arrived at a gateway.

According to TTN Mapper and the metadata available at The Things Network, this gateway was located in Bilthoven at the, 75 km from the place where the package was sent. On Monday I could not figure out what could have gone wrong. The gateway was registered by the RIVM, the coordinates registered was as the RIVM in Bilthoven. But 75 km sounded as too good (far) to be true (possible).

I’ll skip to the conclusion: it was, the gateway was not located in Bilthoven, it was much closer.

Today, Derko from the RIVM (the National Institute for Public Health and the Environment) contacted me by e-mail because he had seen my tweet about their gateway. I pointed him to the post (in Dutch) that I wrote about it. In his mail he had already explained that the gateway was indeed a Lorank 8 (and not a single channel gateway as TTN Mapper assumed, but since then has corrected) and was located indoors. This made the 75 km even more unlikely.

About half an hour after my reply, Derko responded again. He felt sorry for me, but had bad news. Reading about the location from where I had been able to reach their gateway, he realized that only recently, they had installed a new gateway at one of their locations where they measure air quality. And you might have already guessed: that location was close to De Rips, it was at Vreedepeel, about 3.5 – 4 km and not 75 km from the location of my node. The location data for that gateway had not been updated when it was installed.

Derko since then changed the data for the gateway, so it now correctly shows its location:

TTNMapper hasn’t updated it on the map yet (I’m guessing that is a batch process), but the change in location is listed on this page: https://ttnmapper.org/gateway_moves.php (search for 1DEE0348A7BB4EC8) so it should be corrected in not to long.

Am I sad that it wasn’t 75 km? No, not at all. It was highly unlikely and I’m happy that the puzzle has been solved (thanks Derko!). The RIVM gateway is not the only gateway that has incorrect location information.

I took the TTN-mapper node with me today in the train to Deventer and back. And in Deventer a gateway was active that has its coordinates set to South Africa. It confuses TTNMapper because it by default zooms out to a view where all the gateways are visible.

But I prefer to focus on the plausible “cool results”, like the fact that apparently I could reach the “Grote Kerk” in Deventer and het Kadaster in Apeldoorn (see map in tweet above) at the same time. Both about 12 km or 18 km from where I was. Still impressive.

 

jun 182019
 

[UPDATE: zie dit bericht (in het Engels) over waar de gateway écht bleek te staan. Het was geen 75 km ver]

Vanochtend mocht de TTN-mapper node weer eens mee op pad. Ik moest met de auto naar Nijmegen – Arnhem – Veenendaal – Deurne. Helaas blijkt de TTN-mapper nog steeds heel accuraat voor het traject naar Nijmegen en dus kwam er heel weinig (bijna niets) aan van de pakketjes die verstuurd werden. Bijna niets, want net bij/voorbij de Rips of all places, zag ik op mijn telefoon dat er 2 pakketjes doorgekomen waren. Dat vond ik verrassend omdat ik niet wist dat er daar een gateway in de buurt stond.

Dat is ook niet zo, nakijken op TTN-mapper en in de Google sheet (die alle door de backend ontvangen data ook opslaat) leerde namelijk dat het een gateway is (zou moeten zijn) van het RIVM in Bilthoven. En dat was/is zo’n 75 km (!!) van de Rips vandaan.

Lees verder….

jun 172019
 

 

Nu even de tweet, meer uitleg over SDR komt een andere keer.

jun 062019
 

Ik wilde eigenlijk een blogpost maken over XOD, een interessante grafische omgeving voor het programmeren van Arduino. Hier kun je een uitlegfilmpje over XOD bekijken. Maar uiteindelijk blijkt dat alleen geschikt te zijn voor Arduino. En áls je op zoek bent naar iets anders dan de standaard Arduino IDE en je werkt ook met bv ESP32 of ESP8266 werkt, dan is PlatformIO een betere oplossing.

Andreas Spiess heeft er een mooi introductiefilmpje over gemaakt (zie hierboven) waarin hij laat zien hoe hij PlatformIO gebruik voor een Arduino UNO en daarna voor een ESP32. Hij demonstreert daarbij ook de mogelijkheid om per project de libraries die je gebruikt op te slaan of hoe een project met 26 libraries daar handig gebruik van kan maken.

Zelf heb ik er tot nu toe ook alleen gebruik van gemaakt in combinatie met code die geschreven was voor PlatformIO, nog niet vanaf scratch.

Je kunt bestaande Arduino projecten importeren, maar ook dan moet je het .INO bestand zelf nog even omzetten naar main.cpp en als je een project hebt met de nodige libraries zul je ook die verwijzingen eenmalig moeten opschonen.

In het geval van het project dat ik importeerde (de TTN-mapper die je hier kunt vinden) is een bonus dat de ook de Markup bestanden (de .md bestanden) rechtstreeks in de editor kunt bijwerken. De Readme.md van dat project heeft nu een lijstje van libraries die je nodig hebt, met links en in één geval de opmerking om vooral maar de laatste versie te gebruiken omdat de Arduino IDE anders in de war raakt. Dat probleem ben ik kwijt bij een overstap naar PlatformIO. Nadeel is dan weer dat de oorspronkelijke auteur van de code ‘gewoon’ de Arduino IDE gebruikt (ik gebruik een “fork” in Github). Het naar hem terug aanleveren van voorstellen voor wijzigingen in de code is een stuk ingewikkelder als ik overstap naar PlatformIO.

jun 022019
 

Deze moet nog even op het TODO lijstje, dit weekend veel gedaan, maar nog niet zelf kunnen bouwen. Maar de beschrijving van Andreas is (zoals altijd) meer dan duidelijk genoeg.

Het idee: maak een TTN-tracker waarmee je kijkt welke gateways je kunt bereiken en in plaatst van met de tracker te gaan lopen/rijden bevestiging je hem op een vaste plek in de hoop dat af en toe in verloop van tijd ook andere gateways bereikt worden (omdat het signaal toevallig op de juiste manier in de Troposfeer of Ionosfeer weerkaatst worden. Andreas beschrijft de configuratie van de node en de manier waarop je met Node-Red een systeem kunt bouwen dat je automatisch een bericht stuurt als er een gateway gevonden wordt die (bv) > 100km ver weg staat.

Leuk project, niet persé nuttig, maar wel leuk. 🙂