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.
Marvin node updates
I made a couple of changes to the Marvin script in combination with TTN. You can find the code here. First of all, I removed the wait() between the messages and replaced it with millis(). This is just better coding practice in Adruino.
Also, I replaced the use of a delimiter while sending temperature and humidity with the conversion of the decimal values to hex like this:
send_LoRa_data(set_port, String(temp, HEX) + String(hum, HEX));
This enables me to use a decoder function on the TTN backend for the application that the Marvin node was part of, that automatically translates the HEX values into a json object:
The result is that for every message that is received, the conversion takes place automatically, which makes it much more readable:
It also means, that adding the “Data Storage” integration to the Application, also stores the resulting JSON object:
This means that it is possible to retrieve the data stored on the TTN backend using either MQTT or simply JSON. For example, this is what you receive using MQTT:
Doesn’t look pretty yet, I should be able to connect my own Mosquitto server to the one at the TTN backend, but the first attempt for that didn’t work out yet. With that, I would be able to easily link the data to my OpenHab server which does have a pretty display for temperature and humidity based on my home transmitters (that use 433Mhz instead of LoRaWAN).
Using Freeboard is another option (see image at the top), you can use the online environment to create a dashboard, or run your server. In that case however, the data itself is still only stored on TTN servers.
So overall, quite happy with the Marvin. There is room for more sensors, they are not the cheapest, but relatively plug and play: light sensor, sound sensor, UV radiation, distance, movement.
LoPy node updates
So the LoPy works, but getting it to do something useful turns out to be a bit more of a challenge. Connecting a good old DHT11 temperature and humidity sensor didn’t work out as good as I had liked, and judging from the forums, I am not the only one. There is a great expansion board available, that provides a number of sensors:
- Ambient light sensor
- Barometric pressure sensor
- Humidity sensor
- 3 axis 12-bit accelerometer
- Temperature sensor
but for €38.34 incl. VAT and shipping, it is a bit more than I want to spend on it. Another option I’ll be looking at is using the Circuit Playground as an external sensor bank for the LoPy. Since I already own one of those and it also has light, pressure, temperature sensors (and accelerometer). And I also might end up doing some online shopping for some more I2C sensors.
In general, I notice that I am much more used to the way “regular” Arduino board works, compared to MicroPython. A lot is easy to learn, the lack of libraries for
Downlink back to the nodes
Neither of the example scripts for the LoPy or Marvin really take into account that you also can send back data from the TTN backend, via the TTN gateways to the node. The LoPy Nano Gateway does have the functionality for it, so scheduling a downlink message, will eventually get it to both the Marvin and the LoPy.
It is getting the node to do something when it has been received (like blink the light or something) that turns out to be a bit of a challenge. Being able to do that reliably would greatly enhance the ability to check the connectivity of a node. Or to make the node do something, like switch a relay.
Still something to look at.
Conclusion
I am still glad that I don’t have any critical systems that depend on LoRaWAN + The Things Network. I am glad that at least now I can say that I got the basics working, both with TTN and KPN, with two different brand/type of nodes. So, not to bad for a beginner.
Thx for your helpful post https://t.co/e8sIfVZqg1 ideas how #Marvin in sleepmode ? @thethingsntwrk what to do the g… https://t.co/PbbMyOsSs4