NAM 0.4 LoRaWAN enabled sensor – part 2

Posted on by

When you have soldered and built NAM 0.4 sensor you need to configure it. To do it you need access sensor via WiFi. The same like with regular NAM 0.3 sensor. Help how to configure 0.3.x sensor is described on Nettigo docs site. You can config WiFi in NAM – when you place it in final destination, where is no WiFi it will start with AP and send data via LoRaWAN. After you config NAM – LoRaWAN in NAMF is seen as just another API.

One important thing – in Advanced tab there is field for how long AP should be running if no client is connected. After that time it will shutdown and you have to restart device to get this config WiFi again. If you set this value as 0 config AP will be enabled all time. Remember that config WiFi has default password – change it, especially if you want to keep AP up all the time. This is done in WiFi Sensor section of Advanced tab.

ESP32 can not recognize what was reset reason, so there is no factory reset procedure (NAM 0.3 on ESP8266 does have one). If you change default password store it in secure place.

I wrote short series posts how to use different Heltec module to send data to The Things Network. In case TTN is new topic for you read at least part 1. You have to create account in TTN and create so called application to collect data from NAM sensors. So this is not covered here, as result you need AppEUI, DeviceEUI and App key.

Go to config page of NAM 0.4 and in API section enable LoRaWAN and provide config data. I have redacted keys here since they are from sensor in use.

Those who track posts here maybe now know that experiments with LoRaWAN and persisting data done here were preparation to get NAM 0.4 running. But, as I wrote I’m not LoRaWAN expert, so it turned out that to get all things running we need to persist more data than I thought. And problem is that SX126x-Arduino library does not expose all needed data. So, with current NAMF release (47rc4) I decided to change LoRaWAN flow.

Device won’t persist any session data, so it will need to do join procedure after restart. To avoid flooding TTN network with join request on start when you will connect/disconnect device or something will make device restart, join request will be sent later, after device is up and running. To be exact – at 4th measurement taken.

Data to LoRaWAN network will be sent every 5th measurement. So, OTAA join request will be sent one measurement before sending first data.

State of LoRaWAN network is shown on /status page:

Join status can be also: Ready to join, Join failed and config error. First will be after proper initialization and before 4th measurement. After successful OTAA it is Joined (as on picture). If OTAA request will fail (not in range or you have mixed something with device config) it will be Join failed. Error states means that NAMF can not parse App EUI/Device EUI/App key entered in config.

Last air time and average air time (from10 values) are times spent on radio activity (as reported by library) can get you some information if you are in compliance with Fair Use Policy for TTN. In short – 30s of air time per 24h. Don’t be mislead by just 47 ms on image above. My device is few meters away from gateway, so it uses fastest settings offered by gateway. Firmware NAMF used adaptive data rate, so it will try to adjust LoRa radio data rate to distance from gateway. When gateway is in further distance you will get much higher radio time. And this is time as seen by end device, TTN network seems to see it bigger – you can always check it in application console, when inspecting incoming message search for consumed_airtime field. For example here device sees 47 ms while TTN reports 66 ms.

To get sending data interval multiply device measurement interval by 5 and divide 86400 (number of seconds in a day) by result. That will how many times per day sensor will send data. Multiply by average air time and compare result with 30 seconds from TTN FUP.

This sensor has default measurement time (145 seconds), so: 5 * 145 = 725 seconds. 86400/725 ~= 120 (rounded up). With average radio time 47 ms we get 5.52 seconds. Far from limit, but as I said this node is only few meters away from TTN gateway – connection is good and fast (as for LoRaWAN). When device is further away from gateway this time will increase significantly – you may need to adjust measurement time to get less messages per day.

As for now current software does not support selecting what data is being sent to the TTN. NAM sends PM10 & PM2.5 (from SDS011) and temperature & humidity (from BME280). In future versions should be possible to select what values will be sent.

But what I can do with data in TTN

If you considered LoRaWAN earlier as possible solution for collecting data, you should already now, that sending data to TTN is only part of solution. Now you need to get data out off network you need some integration (application) which will receive data from TTN when messages are received.

With NAM we suggest you can use AQI.eco website to collect data. If You do then AQI.eco have you covered – they provided integration for TTN, you need only configure it in two simple steps.

First login to your account on AQI.eco and go to Settings tab. There you find section TTN Token

You will use given webhook in TTN config. Here it is https://api.aqi.eco/update-ttn/163c1f16a88561bdcd337e27c504c2c6. Now split it two parts: host and path: https://api.aqi.eco/ and /update-ttn/163c1f16a88561bdcd337e27c504c2c6

Go to your application console in TTN. Select Integrations in menu on left and then Webhooks. Click Add webhook button. Then select tile with Custom webhook. Provide webhook ID (for example aqi-eco) and as base URL paste first part (host) from webhook taken from AQI (https://api.aqi.eco/). Scroll down a bit and find Uplink message in Enabled event types section. Mark checkbox next to Uplink message and enter webhook path (/update-ttn/163c1f16a88561bdcd337e27c504c2c6) in field which have opened when checkbox was enabled.

Now click Add webhook button on page bottom and we are ready.

So, rules are as follow: one account in AQI.eco – one application in TTN. When device name in TTN (to be correct: End device ID) in TTN application is exactly the same like name set in AQI.eco, then no additional config is needed. AQI will know which uplink message is from which device. What is has to be different? No problem, just set device id used in TTN in device config on AQI.eco. Here is example: device id in TTN is nam-esp32-3and in AQI.eco is nam-esp32-2. Just provide correct ID:

And that’s all folks! Your device is online!

What next?

As I wrote NAM 0.4 is still in beta stage, both in terms of hardware and software. If you need to place a device where is no WiFi coverage, but in LoRaWAN range you can do it now. Your can help that way in device and software development and what is important – already get PM readings from that node.