DesignSpark Electrical Logolinkedin
Menu Search
Ask a Question

Experimenting with All Things Talk and The Things Node

An update on the LoRaWAN sensor project to measure the outdoor temperature.

The Things Node (135-9784) has worked well, keeping me updated on the plummeting temperatures during our recent second run-in with the “Beast from the East”. I can confirm that The Things Node is water and snow proof.

Two issues are now clamouring for attention – the batteries keep running out and my partner keeps asking if she can have the weather on her ‘phone too.

Optimising for low power usage


The first thing to deal with is the power consumption. The Node was sending quite a lot of data that I wasn’t interested in, as well as turning its LEDs on and off. I reckoned if I could stop it doing this, it should prolong the battery life.

As I mentioned in my previous blog I’m new to Arduino sketch writing so I thought the best plan was to start with a sketch that I knew worked OK and adapt it to my requirements. I had a quick search on The Things Node forum and found a useful thread started by John Hallard on getting the Node to work for a reasonable time on one set of batteries - “The Things Node: new low power library development” 

That helped me track down a power saving sketch for the The Things Node on GitHub

Even given that this was a power saving sketch I reckoned a could squeeze some extra life out of the batteries by stopping it doing the things I didn’t need – movement sensor, luminescence sensor and turning the LEDs on and off.

I started taking the bits out that I didn’t want and then testing to see if I’d broken it …

… after a fair amount of trial and error I’ve ended up with a lean, mean sketch that should result in a reasonably long battery life.

Although the sketch seemed to work well, when I checked the temperature in the morning it was reading over 21ᵒ. I know it’s Spring but it certainly was not that warm. It seems the temperature sensor had got stuck when it was recording indoors, before I put the Node out in the wild.

I re-uploaded the sketch and that seemed to set it back to an accurate reading, although the Node was inside again now so I didn’t know if it was having some kind of problem with low temperatures. Then I had a brainwave – I’ll put it in the ‘fridge and see what reading I get.

This in turn, gave me another thought: we have a ‘fridge at work that, every now and then, goes in to over-drive and freezes all the contents. We also have a spare Things Node at work. Why not put it in the ‘fridge and set up an alert to text or email if the temperature drops below 1 degree? Having worked in a cafe where one of my jobs was to check the ‘fridge and freezer temperatures spread around 3 buildings, I could see how the IoT could be really useful in a catering environment.

AllThingsTalk Maker

I had decided to try AllThingsTalk (ATT) as a way of sharing the data, so
I signed up for an AllThingsTalk Maker account and added the integration to my Things Network application.

I needed a simple Sketch to start with, so I applied the same principles of getting rid of the bits I didn’t need in the Basic Sketch provided as part of the Things Node Examples.

I then added my Node as a device on All Things Talk by simply copying and pasting the required details from TheThingsNode device page into the form on ATT …


Once the Device is added I clicked on “Settings” and then “Payload formats”, I ticked the “Use ABCL ...” box and pasted this code that again I had found on the Things Node forum into the box and saved it.

{
  "name": "temperature",
  "sense": [
    {
      "asset": "temperature",
      "value": {
        "byte": 4,
        "bytelength": 2,
        "type": "integer",
        "calculation": "val/100"
      }
    }
  ]
}


(Thanks to a post by Mark Stanley on the The Things Network forum)

I could see that data was coming through to AllThingsTalk by clicking on the DEBUG link on the Devices page, but it was not updating the reading on the Asset. After a fair amount of trial and error I found that putting this in the Profile under the Advanced tab fixed this.

{
    "type": "integer",
    "asset": "temperature",
    "value": {},
    "unit": "C"
}

 

Once I had installed the ATT App on my ‘phone ....

 ... I could see the temperature read out from my Node nice and clearly.

 

OTAA vs. ABP

All was well until I realised that, if my node lost its connection to the network, the AllThingsTalk integration stopped working. After a bit of digging about, I realised that
ATT use ABP (Activation By Personalization) rather than OTAA (Over-The-Air-Activation) as its Join Mode. I found this page that explains the difference between the two.

As someone who has experience of computer networks, I understand it as being similar to the difference between a fixed IP address or using DHCP. Using OTAA, the Dev Address, Network Session Key and App Session Key that ATT uses to set up its connection to my Node, are generated anew if the device reconnects to the Things Network. Using APB they would stay constant.

The upshot is that I either need to change the connectivity settings of my Node on AllThingsTalk if/when it loses its connection to The Things Network and rejoins, or I need to re-write the Node’s Sketch to use APB instead of OTAA. Having experimented with a mash-up of my minimal Sketch and the ABP one in The Things Node examples, without a great deal of success, I decided that I would live with the former for the time being. If it gets to be too much of a pain I’ll come back to it and have another go at a minimal ABP Sketch for the Node.

This has been a pretty steep learning curve for me and frustrating at times, but patience and perseverance have paid off. I’ve learned a lot and I‘m already planning future forays into the world of the IoT.

I look after production at AB Open. In my spare time I do a bit of DJing. I like tinkering and making things.

3 Apr 2018, 13:14

Comments

April 17, 2018 08:21

Nice , i wonder is it a python hackable device ?

0 Votes