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

Er is weer een nieuwe afkorting bij om te kennen als het gaat om de apparaten die je thuis (en op andere plekken) aan het netwerk kunt /hebt hangen, denk aan de WiFi-router thuis, een camera die je via internet kunt bedienen, je mediabox die aan de TV hangt etc.

De media noemt ze overigens vaak “IoT devices” (Internet of Things apparaten) en dat is wellicht niet zo handig omdat veel mensen zullen denken “die heb ik niet”.

Ik schreef in januari al dat je zelfs je eigen thuisnetwerk niet zomaar als “veilig” zou moeten beschouwen. Dat was toen naar aanleiding van berichten dat hackers grote aantallen IoT devices gebruikt hadden om een DDoS (Distributed Denial of Service) aanval uit te voeren.

Nou zou je nog kunnen stellen “als het apparaat maar blijft werken, dan maak ik me er niet zo’n zorgen over”. Los van de vraag of je het prettig zou moeten vinden als een ander toegang tot je WiFi-router heeft, zijn er nu ook een tweetal bedreigingen die wél schade kunnen opleveren voor de werking van jouw eigen (onveilige) apparaat.

Het heet een PDoS, een “Permanent Denial-of-Service” en het woordje “Permanent” zegt het al: na zo’n aanval op jouw apparaat is het “stuk”. Weliswaar niet fysiek stuk, er komt geen rook uit je apparaat, maar softwarematig zo stuk dat jij er geen toegang meer toe hebt en de werking ervan ook stopt.

Zoals zo vaak maakt de tool die de aanval uitvoert (er zijn twee varianten: BrickerBot.1 en BrickerBot.2 die niet helemaal hetzelfde werken maar vergelijkbaar effect hebben)  gebruik van bekende kwetsbaarheden in software die in (blijkbaar) redelijk wat systemen aanwezig is. Het gaat om systemen die BusyBox en Dropbear gebruiken. Met name bij BusyBox is het lijstje van “andere software en hardware die gebruik maakt van BusyBox” lang. Hoeveel systemen daarmee gevaar lopen? Dat is wat moeilijker vast te stellen. Het is logisch dat een bedrijf dat ook consultancy verkoopt aan bedrijven om hun netwerk te beveiligen stevig aan de bel trekt. Dropbear heeft inmiddels al een patch uitgebracht, die worden echter maar zelden op dit soort apparaten geïnstalleerd (als het al kan). En voor alsnog geldt natuurlijk ook dat het systeem via internet bereikbaar moet zijn, dus die buitenste verdediging van je netwerk waar ik over schreef kan heel wat aanvallen tegen houden. Maar wees dus absoluut voorzichtig met het “zomaar” in je router openzetten van een poort zodat je je apparaten ook kunt bereiken als je op je werk of onderweg bent.   Het volledige bericht en de bijbehorende PDF is hier te vinden.

De vraag is in ieder geval hoe lang de situatie blijft bestaan waarbij hardware (ook je slimme TV) niet of nauwelijks van een update is te voorzien. Voorlopig lijken leveranciers zich er nog gemakkelijk vanaf te kunnen maken.

Wordt ongetwijfeld vervolgd.

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

I still wasn’t out of “what if…” scenario’s for the devices I had been playing with in relation to The Things Network / LoRaWAN. Because, although I had used the WiFi (and of course LoRA) capabilities of the LoPy a lot, I had not yet played with its BLE (Bluetooth Low Energy) capabilities. For that I needed something else that could use BLE to connect to it. My iPad Mini, the micro:bit, my desktop machine (thanks to the BLE USB adapter), they all could do that. But I wanted to use the Puck-js buttons that I had for that.

The use-case:  If I press the button on the Puck.js (I have two of them, I can press either of them), then the Puck.js connects over bluetooth to the LoPy. After the connection has been made, the Puck.js sends 1) its device-id 2) the measurement of the light sensor of the Puck.js 3) the measurement of the temperature sensor of the Puck.js and 4) the battery voltage of the Puck-js. Once the LoPy has received those 4 values (encoded as a single HEX-string), it sends it to The Things Network (TTN) via LoRaWAN.

Like with the Adafruit Circuit Playground, one of the challenges was that both devices (the LoPy and the Puck.js) use different programming languages and there were no existing examples that handles the cross platform connection.

I uploaded all code to github.com

Programming the Puck.js

To program the Puck.js, you need the Espruino IDE. I have had my fair share of problems connecting to the Puck.js from within that IDE. It is probably one of the challenges of using BLE as a connection to program. But in the end it got the job done. I wasted most time trying to understand how I can send data from the Puck.js to the LoPy after connecting to it. There was an example using 2 Puck.js to send data, but I could not figure out what the UUID of the PrimaryService and the UUID of the Characteristic for the LoPy that allowed me to write data to it where.

I tried to figure that out using code on the Puck.js, but that didn’t work. In the LoPy code that I found, the service and characteristic were defined like this:

srv1 = bluetooth.service(uuid=b'1234567890123456', isprimary=True)

chr1 = srv1.characteristic(uuid=b'ab34567890123456', value=5)

I finally discovered how these needed to be added in the Puck.js code by using nRF Connect, a free tool for iOS. After setting up the LoPy so that it broadcasts using BLE (see the code below), I connected to the LoPy using the nRF Connect app. It then shows you the correct UUID’s that are in the Send_BT_to_LoPy.js script:

return d.getPrimaryService("36353433-3231-3039-3837-363534333231");

return s.getCharacteristic("36353433-3231-3039-3837-363534336261");

Easy, once you know it.

Note #1:  The Puck.js connects to a device named “LoPy01” so if you change the name of the device in main.py for the LoPy, you also have to change it in the code for the Puck.js
Note #2:  I added the id for the Puck.js in the code, first line. You need to change that to the code for your Puck.js if you have more than 1 Puck.js and want to be able to keep the transmitted values apart afterwards.

Let’s continue with the LoPy.

Lees verder….

Deel dit bericht:
apr 072017
 

What happens if you take a LoRaWAN node with you in a train while you travel across the Netherlands for about 2,5 hours? I did not know and wanted to find out today because I had to be in Zwolle for a meeting.

So I charged a big external battery (with 2 USB ports), drilled a couple of holes in a plastic container to guide through the micro-USB connectors, and put in some bubble foil inside for safe transport. I drilled another hole to connect the external antenna for the LoPy node. Besides the LoPy, I put the Marvin in the box, with the temperature/humidity sensor on the outside of it. Not that it really mattered, today was going to be about finding gateways while I was on the road.

Things did not look good for the experiment though in the morning. The Things Network (TTN) backbone was acting up again. That was a bummer, because I still had to change the code on the LoPy. It had the code installed for the Circuit Playground and I wasn’t planning on bringing that also. So I changed the code to a simple “send a number every 30 seconds” but was not able to test it before leaving for the train.

To make matters more balanced: I decided to have the Marvin connect to the KPN network (still got 60 days left on my free trial), but the Hookbin.com server decided that today was a good day to refuse to work. And I needed a place to store the data sent by the Marvin. Luckily I found loggly.com another site that you can use as a destination for KPN nodes. I think it is better than Hookbin btw because it keeps more records and even the free plan should be enough for most people. Another nice thing was that Loggly also can act as an HTTP-integration for TTN, so I could collect both the data sent via KPN and the data sent via TTN in one single place. Quick tip: Loggly provides you with an http:// url for the endpoint, KPN doesn’t accept http:// but you can simply change the provided url to https:// and then it works.

OK, into the train. I wasn’t really sure what to expect. A train means lots of metal and a fast moving object (and nodes).

Lees verder….

Deel dit bericht:
apr 062017
 

Tegen de tijd dat ik het mailtje gisterenavond zag had ik ook al de follow-up mail met als titel “Let op: Phishing mail verzonden” in mijn mailbox met de waarschuwing om de mail gewoon te verwijderen. Maar het is/was een dusdanige phishing e-mail dat ik hem hier ook even wil plaatsen als waarschuwing en voorbeeld.

Normaal gesproken zijn phishing mails die ik ontvang namelijk gemakkelijk te herkennen: ze komen van een bank waar ik geen rekening heb, vragen informatie die ik nooit via de mail zou sturen, bevatten taal en spelfouten, etc.

De mail van gisteren was echter geschreven in foutloos Nederlands, bevatte in de “Beste” mijn volledige voornaam en achternaam én was verstuurd van een domeinnaam die leek op die van mijn werkgever: “han-hogeschool.nl” (i.p.v. han.nl)

De mail vroeg niet om mijn bankgegevens, maar had een link naar een pagina op (eveneens) han-hogeschool.nl die er exact zo uitziet als de schermpje waarmee ik normaal gesproken ook inlog:

 

De ene is de echte, de andere niet. Als je goed naar de adresbalk kijkt in de screenshots kun je zien welke wat is. Ik heb even niet getest wat er gebeurt als ik (onjuiste of juiste) inloggegevens in zou vullen, maar ik kan het de collega’s die hier wél voor gevallen zijn absoluut vergeven. Want hoe vaak vul je zo’n schermpje niet in? En in dit verband is het ook nog heel logisch, want je verwacht dat het nodig is om in te loggen om bij een interne pagina te komen waar je je keuze moet aangeven.

Overigens: via Internet Explorer, de standaard browser van de HAN, wordt de pagina netjes weergegeven. Met Chrome zie je wél snel dat er van alles mis is omdat ze de afbeeldingen en CSS bestanden gewoon heel brutaal bij de HAN rippen. En die gebruiken https:// terwijl de rest van de pagina via http:// uitgeleverd wordt. Chrome vindt dat niet fijn.

Goed, dit was een phishing aanval op HAN mailadressen. Ik neem aan, gezien de inhoud van de mail, alleen gericht op medewerkers. Maar als iemand zoveel moeite neemt om een aanval voor te bereiden, dan zou het me niet verbazen als ze zoiets ook op andere plekken gaan proberen. Het is een indrukwekkende combinatie van sociale manipulatie (je doet dingen die heel logisch lijken) en technische uitvoering. Dus let op!

p.s het domein is bij GoDaddy.com geregistreerd via domainsbyproxy.com, dus achterhalen wie hier achter zit zal wel nooit lukken denk ik.

Deel dit bericht:
apr 052017
 

One of the challenges left with regards to the LoPy was to find a way to actually connect sensors to the node. I had little luck with the DHT11 temperature/moisture sensor (one of the drawbacks of MicroPython over regular Arduino code is the lack of libraries) and didn’t have any I2C sensors lying around. But I did of course still had the Circuit Playground by Adafruit and I knew how to talk to that one from another device using the hardware serial RX/TX connection because I had already connected it to a micro:bit that way (the posts are here, but in Dutch).

So surely it should be possible to connect it to a LoPy and send the sensor data to The Things Network (TTN) that way? Is was. Not as easy and simple as I had hoped, but in the end it worked. Since it is rather a complex structure, I made a small graphic to explain how all the parts go together.

Let’s start with the easy parts: I have got a LoPy Nano Gateway up and running. That is not a full compliant LoRaWAN gateway, but it takes care of receiving messages send via LoRa / 868 Mhz and relaying them, via WiFi, via my WiFi Router, the internet, to the The Things Network (TTN) backend. That is the regular part.

On the right end lower corner, the action starts with the LoPy Node. It is connected via two cables to the Circuit Playground (CPG). One cable goes from the TX port of the LoPy Node to the RX port of the CPG. The other one goes from the TX port of the CPG to the RX port of the LoPy Node. The LoPy Node sends a signal (a digit ranging from 1 to 10) over the serial connection to the CPG. After the CPG receives the signal, it reads the three build in sensors for light, noise and temperature. It then converts the values to a 12 byte HEX string value and sends that back over the serial connection toe the LoPy Node. After sending the signal, the LoPy node waits a bit, giving the CPG time to return the value, then it reads the values and sends that via LoRa to the first available gateway, in this case the LoPy Nano Gateway on my desk.

After the gateway has delivered the messages to TTN, a Payload function translates the received value back into three individual values. It then send them, via the Integrations option, to the Swagger server where it the is available in JSON format. See, easy peasy. 🙂

I uploaded all the code to Github. You can find it here. The code in the LoPy-flash folder is (of course) intended for the LoPy Node, the code in the Circuit Playground folder needs to be uploaded to the CPG via the regular Arduino IDE. I made some changes to the LoPy node code provided by Pycom: I added the option to have the LoPy Node also connect to your local WiFi. Not necessary, but it makes it easier to debug/connect. If you leave that info blank, it will just ignore. Also, if you take the node outside of the range of you WiFi network, it will just ignore it. Another thing that I changed, is the use of config.py for the Node, so that you only need 1 place to change all the info. Finally I choose OTAA instead of ABP as the authentication for the node.

Lees verder….

Deel dit bericht:
apr 052017
 

Ik luister niet zo heel vaak naar podcasts, maar een tweet van Astrid Poot zorgde ervoor dat ik vandaag tijdens het werken tóch kennis maakte met “Lekker samen kletsen“. Aflevering 9, als heb ik 8 (waarvan Astrid dacht dat het 7 was) ook geluisterd want Soundcloud speelt gewoon door als je niet op stop klikt.

Waarom kwam ik bij de podcast? Nou, vanwege de vraag van Astrid in haar tweet “kun je praten over maken zonder te maken? kun je expert zijn zonder ervaring?” Het lijkt een open deur waar het antwoord dan op zou zijn “nee, natuurlijk niet!”. Maar het ligt wat mij betreft toch wat genuanceerder, en Peet Sneekes (de andere stem die je in de podcast hoort) probeert dat ook in de podcast wel voorzichtig aan te stippen.

En even voor de 100% duidelijkheid: dit is geen zure blogpost. Ik ben het niet 100% met Astrid eens en ga dat in tekst (getypte woorden) proberen onder woorden te brengen als onderdeel van het gesprek dat je over dingen kunt hebben waarbij je het niet 100% met elkaar eens bent. 🙂

Kijk, maakonderwijs, maken, maker education, is van nature een tastbaar ding. Dus logisch dat je dan zou zeggen “dat moet je dóen om te kunnen waarderen”. Maar het is wat mij betreft wat minder zwart/wit. Vroeger, toen ik nog naar Nederlands voetbal op de tv keek, kreeg ik van mijn kinderen wel eens commentaar als ik mijn beurt commentaar gaf op het spel van het Nederlands elftal. Ik kon het immers ook niet beter, sterker nog, mij laten voetballen levert waarschijnlijk meer kwetsuur op dan een paar buitenspeelbenen. Mag ik er dan geen mening over hebben? Of omgekeerd: als ik wél voetbal, ben ik dan automatisch beter in staat om er een mening over te hebben?

Terug naar maakonderwijs: ik heb van tijd tot tijd verschillende petten op: ik ben een geek die het leuk vind om dingen uit te proberen (vaker met software dan met “spullen” moet kunnen hoop ik), ik ben ouder van twee tieners (en ben het helemaal met Astrid eens als het gaat over de rol van ouders op dit gebied, los daarvan: het is gewoon leuk!) en ik ben onderzoeker bij een kenniscentrum. Mijn ervaringen op de ene plek, helpen mij op de andere plek.  Als onderzoeker wordt ik geacht ook “in de boeken” te duiken (er zijn best al veel boeken die relevant zijn voor maakonderwijs hoor!), tijd om zelf dingen te maken is er in die rol niet altijd. Geeft ook niet, want op zo’n moment wil ik vooral ook zien wat anderen doen, wat leerlingen doen, wat collega’s doen, niet altijd is het dan handig om “samen” te klooien. Dat doe ik dan wel weer op andere momenten, thuis, met de kinderen bijvoorbeeld.
Het er bij halen van theorie is daarnaast ook belangrijk. Want daaruit kun je namelijk leren wat anderen ook al verzonnen hebben en wat toen wel of juist niet werkte. Dan hoeven we niet steeds opnieuw het wiel uit te vinden.

Dus ik denk dat het gelukkig niet zo’n harde scheiding is. Een “expert” die heel stellig is in dingen op dit gebied mag van mij ook wel met stellige onderbouwing komen (ik zal niet zeggen “bewijzen”). De opmerkingen “ja, want ik ben docent” of “ja, want ik werk in de praktijk” is dan voor mij daarbij ook niet genoeg om me te overtuigen. Dus een “super praktische expert” zoals het in de podcast genoemd wordt is voor mij ook een verzinsel. Er wordt gesteld “Kun je denken over de realiteit, zonder in de realiteit te zijn” en anders dan Astrid en Peet denk ik dat dat wél kan. Ik zou mijn werk heel erg saai vinden als dat het enige was wat ik zou mogen doen (en niet alleen als het over maakonderwijs gaat), maar dat is wat anders. 🙂

Deel dit bericht:
 Reacties uitgeschakeld voor Moet je kunnen voetballen om een mening over voetbal te hebben?  Tags: ,
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?

Deel dit bericht:
 Reacties uitgeschakeld voor TTN: If the GUI fails, just go commandline  Tags: , ,
apr 032017
 

Laat ik beginnen met de breed gedragen constatering dat het werken met paper circuits toch nog best heel wat moeilijker is dan dat je zou denken als je de filmpjes die online staan ziet. Wat dat betreft is het ook maar goed dat ik 5 rollen van 30 meter besteld heb, want er zal nog wel wat tape “verbruikt” worden.

Maar…de opmerking dat ik natuurlijk na het weekend ook wel een paar voorbeelden wilde hebben om te laten zien, was voldoende stimulans om te volharden.

Ikzelf was er voor het debuggen, als mensen een voorbeeld zoeken van een debug-activiteit die niet met programmeren te maken heeft: laat leerlingen met paper circuits aan de slag gaan! 😉

Ik weet zeker dat ze dan ook leren om nauwkeurig te werken en planmatig te werk te gaan. Want als je niet nauwkeurig bent, dan is je stroomkring al bij de eerst bocht onderbroken en als je niet planmatig te werk gaat bestaat je project vooral uit frustratie om led lampjes die verkeerd om zitten of stroomkringen die niet sluiten.

Maar natuurlijk is het ook gewoon leuk. Waar Marit meteen aan het tekenen sloeg en begon met een mooie voorkant, dacht Niek na over parallelschakelingen van ledjes met aparte knopjes per led en combineerde Josine bestaande kaarten met ledjes en zorgde voor batterijhouders (van papier).

De kopertape die we hebben blijkt tweezijdig te geleiden, dat is handiger dan tape die alleen aan de bovenkant geleidt. Het vastplakken van leds met plakband blijkt niet zo handig, het contact is minder sterk dan nodig, beter is het om ook daar kopertape te gebruiken.

Lees verder….

Deel dit bericht: