apr 202017
 

De Amazon Dash knoppen zijn heerlijk controversieel. Het idee: je hebt een knop (gewoon, een knop met niet verwisselbare batterij en wifi ingebouwd). Als je daar op drukt, dan wordt er automatisch dat ene product waarvan je ook het logo/merk op de knop ziet (ok, dat kun je dan wel zelf instellen vooraf) in je mandje bij Amazon gelegd. Gemakkelijk: plak er eentje in het kastje op de badkamer en als iemand de laatste wc-rol pakt, drukt die gewoon even op de Dash knop om hem bij te bestellen.

Ja ja, super ernstig, fout, verspillend, gemakzuchtig. Geloof me, ik zou er nooit eentje gebruiken. Tenminste niet voor het doel waar ze voor verkocht worden. Want zo’n Dash knop kost maar 5 euro. Helaas, wel in Duitsland te koop, nog niet in Nederland.

Want zo’n knop is natuurlijk een heel hackbaar ding. Nou ja, wil je het allemaal veilig maken en zo, dan kost het wat meer werk, maar voor 5 euro kan ik niet zo’n compacte knop maken die een signaal via mijn wifi netwerk verstuurd. Een ESP8266 kost zo’n 2-3 euro, hier zit een mooie compacte behuizing omheen, een kleine drukknop, het enige nadeel vind ik wel (ook een beetje principieel) dat de batterij niet te vervangen is. Dus als die leeg is (na zo’n 1.000 keer gebruik), dan moet je de knop weg gooien (en niet gewoon in de grijze kliko vanwege die ingelaste batterij).

Dat is één van de redenen waarom deze hack van de knoppen eigenlijk niet zo “goed” is, al is het idee natuurlijk super: een ouder heeft een viertal Dash knoppen aangepast zodat dochterlief van 4 zelf de muziek via het Sonos systeem aan en uit kon zetten. Een Raspberry Pi met daarop o.a. de scapy library vangt de signalen op die de Dash knop verstuurt als deze verbinding wil maken met Amazon. De truc is om de setup van de knop niet helemaal af te ronden zodat deze wél verbinding met je wifi netwerk kan maken, maar niet met Amazon.

Dat principe is natuurlijk ook op andere dingen toe te passen, bijvoorbeeld om apparaten op afstand aan en uit te schakelen. In dit bericht kun je lezen dat dat niet zo heel veilig is aangezien anderen dan zo’n zelfde script zouden kunnen gebruiken om je lampen, apparaten etc. aan te sturen.
Nou klopt dat inderdaad, maar dat is net zo waar voor de meeste “KlikAanKlikUit”-achtige systemen die veel in gebruik zijn.

Hoe dan ook, leuk voorbeeld, en scapy is de moeite waard om wat dieper in te duiken. YouTube heeft er zo te zien voldoende filmpjes over.

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

If there is a thing that is dislike most, than it is giving up on a technical problem before it is solved. So, although this weekend a late cold finally managed to make me sleep more than usual, I did manage to spend some time with The Things Network, the LoPy Nano Gateway and the Marvin Node.

So, one thing that really can kill your debugging efforts is the fact that the backbone for The Things Network is rock solid stable. I don’t know whether that just is the case during the weekend, but like last week, this weekend there were some outages. There is no single status page that you can check, so that makes it a bit hard. But I’m starting to learn that if the console page act oddly, like failure to show the gateways that I defined, or if suddenly everything is displayed is disconnected, it might just be that they are having problems on their end.
Who am I to complain about a free service? I know, still, an automated page that tells me if I need to just wait and do other stuff, would be nice.

But during the uptime, I was able to get some more stuff working.

First of all: the code that Alex used in the video does work, just make sure you select “Packet forwarder”.

Another thing to know is that the default abp_node.py script has this code:

for i in range (200):
s.send(b'PKT #' + bytes([i]))
time.sleep(4)
rx = s.recv(256)
if rx:
print(rx)
time.sleep(6)

Basically it just sends 200 packages within a short time and then stops. So if you don’t know that, you’ll think the node stopped working. It does, but on purpose. Now if you reset the LoPy, it will start again, but the TTN backbone will ignore that data because the LoPy will start again with package #0, and the backbone will already have a package #0. The quick solution during testing is to reset the frames counter for the device.

Also, the test script is nice for testing, but LoRaWAN was not build for a rapid stream of data, so make sure you read the post about the TTN Fair Access Policy, even with small messages at close range, the 500 messages (of 10 bytes each) per day at SF7 means max. 1 message per (about) 3 minutes, the script sends one every 10 seconds. Granted, it stops after 200 messages, but if you repeat that 2-3 times during testing, you go above that.
For me, testing it on my own Nano Gateway, the chances that I “steal” airtime from other nodes is small, but if you’re using someone else’s gateway, you could be causing problems for other nodes being unable to get their messages through.

But like I said in the title, the weekend showed there is still some love left. I managed to get a few more things working with my two nodes.

Lees verder….

Deel dit bericht:
mrt 312017
 

If your are used to learning stuff without there being a clear manual available, without a teacher that gives you a step by step breakdown of what to do, like when you like to experiment and play with electronics or ict, then you know how frustrating the process of trial and error can be to get something to work. And how rewording it is when it does work in the end.

There are limits however. And LoRaWan in combination with The Things Network (TTN) is really testing my limits with this regard. Because it turns out it is really tough to get it to sort of work, even though it looked easy at first, and I am not sure anymore whether this is good and a way to learn all the ins and outs of LoRaWAN and TTN or whether it just is not worth it (yet).

So, what is the current situation?

  1. On Monday I wrote about connecting the Marvin node to KPN, that worked surprisingly good and was easy to do. Connecting the LoPy as a node to KPN was just as easy. But since KPN is a paid solution and I don’t have a use-case that warrants that amount of money, I kept on looking.
  2. On Tuesday I wrote about setting up a single channel gateway for TTN. That worked also, but only for half a day. At the moment, I understand it sort of was surprising that it worked at all, though online information isn’t always very clear whether failure is by design or by accident, in particular because that info was from before I got the gateway online. Currently, that gateway shows as connected in the TTN console, but no data has been transferred by it since it disconnected Tuesday evening.
  3. Yesterday, there was a live broadcast by Alex from Pycom where he was going to explain how you can use the LoPy as a “Nano Gateway” for TTN. If you watch it, you’ll see that even for Alex, getting the LoPy acting as a gateway is not easy and not something that he could totally do from start to finish during a livestream. I tried to follow the steps that Alex outlines, wasted a couple of hours last night and by the looks of it by accident, the gateway started to accept broadcasts by both the second LoPy and the Marvin node. However…
  4. The LoPy Nano Gateway still is online, data from both of the nodes is being displayed in the console page for the gateway (see image), but not always and none of that data (except for the first few hours) is displayed at the data page for the nodes. So basically I now have a functioning gateway and still no data from the nodes.

Give up or go on?

Personally I don’t have any use-case for nodes that need to be in a location where there is no WiFi. Yes, WiFi uses a lot of battery power, but for the more battery sensitive stuff, 433Mhz transmission also works, and I have got plenty of those lying around.
Yes, I know that Single Channel Gateways or Nano Gateways are not LoRaWAN compliant. So, I cannot blame TTN if they don’t (fully) support them. And nobody is forcing me to use their free infrastructure.
But I am someone that would be willing to spend the couple of hundred euros needed to put a gateway on my house, either by building one for 200 euros or buying one for 400 euros, but with this little succes (and love) in a test setup, that is not going to happen. Because I really don’t know if spending that money would fix all the current problems.

So for now, my home village will have to do without TTN capabilities. I did post a question on the Pycom forum, maybe Alex can shed some light on the problems, maybe he has suggestions, other than that, I don’t know what to test for now.
If someone has a spare gateway lying around that he wants to borrow or donate to get Deurne (NL) on the TTN map, let me know!

Deel dit bericht: