Topic: LoRaWAN


have you ever thought about a LoRaWAN version for the scale?


Currently, the board we prototyped is a single board with sigfox modem.
But as I started to think about having a GSM version, it appeared clear that the strategy will be to have on one side  a main board, (with esp8266 (main mcu+wifi), Power regulator, rtc, motor driver, and optical endstop entry), and "daughter" board plugged in. Kind of the idea of arduino and shields, but simplified. 

The interface between both would be simple : 
- tx/rx serial uart
- +3V3 regulated when board wake up

Doing this way, it'll easy to make variants. We can produce the main board by hundreds, and make à single prototype with engraver to test this or that modem, including lorawan of course.

3 (edited by phisch92 2018-11-18 19:27:34)


In order to share my experience with the LoRa-OpenHiveScale here are my lessons learned:

1)    Integration in TTN:
Once in config-mode you should be able to get the DEVICE EUI from the LoRa module.
To adjust the NETWORK SESSION KEY you will need to recompile the firmware and update it with for example Arduino IDE. For version openhivescale_v4.8 you can do the necessary changes in the file modem.ino in line 180 (appeui) and 182 (appkey). After compiling and uploading the .bin-file to the scale you should be able to receive messages via LoRa.

2)    Payload decoder:
In order to decode the payload I used the following payload decoder:

function Decoder(bytes, port) {

var steps = (bytes[0] << 32 ) + (bytes[1] << 16)  + (bytes[2] << 8)  + bytes[3];

var factor = 303.4; // steps per kg as a conversion factor
var offset = -12.2; // setps of offset

var mass = (steps-offset) / factor; //calculating the actual mass based on the amount of steps
mass = mass.toFixed(3); // rounded to 3 decimal places
mass = parseFloat(mass); //changing the format from string to float
return {
  scale: steps,
  mass: mass

I am happy for ideas to improve. This is a very basic decoder.

3)    The scale will perform an OTAA to communicate with TTN (or any other LoRaWAN). So each time the scale sends something it will first perform a activation and doesn’t store the credentials form TTN yet. This causes the capacity of the battery to decrease faster. I will try to suggest some code to improve the energy consumption in the near future.

4)    It is very helpful to add a manual switch to the casing to turn on and off config-mode from the outside of the box. This way you can change parameters and update firmware even with a load on the scale. Because it is hard to get the box out of the scale unscrew it and put the little jumper on the pins when there are 50 kg on it. Plus I am actually not a bee keeper so I was a little bit nervous doing this the first couple of times with bees next to my head.

5)    It would be great to adjust the sending interval of the scale via LoRa downlink. This way one could increase measurements during day, turn them off when its raining, etc… I will play around with the code and share it once it works. smile

6)    I recommend everyone to do a simple calibration of the scale. Due to modifications, different materials of the scales and different assembling methods the conversion factor (263 steps / kg) might be different to each scale. Mine got a little offset as well.

Best regards

4 (edited by manuel 2019-01-13 23:37:01)



i got my scale successfully working via wifi and now i would like to have it send the data via the LoRa chip. The university has set up a LoRa network in town and is using it to get in data from DIY weather stations. They are happy about alternative uses so I wanted to use their network to get my scale-data in.The next gateway is in line of sight about 800m away.
Therefore I was wondering if all the steps described above by phisch92 are necessary to get the data in via LoRa? I am no programmer, come from the beekeeping side of things and therefore have no knowledge about the network/programming details. The scale shows the deveui when requested in config mode. I assumed it will automatically connect and send in the data once in range of the lora network and display it in the graph on the monitoring page (as it does for wifi connection). Or are there additional steps necessary to make it work?

Thanks a lot for the help! smile
Cheers from Norway



Hello Manuel,

No you won't need to do the firmware modifications and recompilation like phisch92 did. I did make some modifications in the firmware in the meantime, and if needed additional I'll do it. Eventually you'll need to upgrade the firmware, but this is easy.

Could you go on the debug link in config mode, and look in the very first lines, the compilation time, it's the actual version of the firmware (I have to make a simpler versioning)?

About LoRa : It's a bit more complex scenario than sigfox where everything is configured on their backend with just the modem id, or GSM where once you have a SIM and its PIN code, network gives you access to internet.
For now I didn't manage personally the network configuration part for other users, but I ran some test with Orange and Bouygues national LoRaWan networks. It worked, but some stuffs are not perfectly clear to me.

You can read this :

- I don't understand in which scenario hwid and deveui should be different? One is readonly, the other is configurable.
- appeui / appkey : who must define it? The board developer? Or the network manager? Is just a random string, or is there rules?
- join otaa : should it be ran each time board wakes up? or only once for lifetime?

For you information :
Once connected to the wifi board in config mode, you have access to the modem through telnet. Get a telnet client (putty under windows is nice), connect to default telnet port, and play the commands you want. Starting by 'sys get ver' to check it works.

Could you ask to the people who give you access to the LoRa network how you/they will configure the modem? Will they give you an appeui/appkey or do you have to define it yourself? What is the process to pair the hwid/deveui with the network, and the callback URL?

For the callback URL, do you want to use our website? Or do the university have something that you can use?

Once you get some information about the lora network you'll use (access to some sort of configuration backend website), I can assist you, ideally with a laptop (for wifi) connected to internet through cable. So that we can share the screen, and in the same time wifi connected to the scale to run tests.



Hi Pierre,

Manuel asked me to help him out with his LoRaWAN connection, as I have some more experience with that.

Manuel is planning to connect his scale to The Things Network (TTN), just like phish92 did. When you register a node on TTN:
- TTN will generate an AppEUI (from their own block), but you can also add arbitrary secondary AppEUIs
- You provide the DevEUI yourself. This can be any number, it does not have to be an actual globally  unique EUI (as long as it is unique within the application).
- The appkey is randomly generated by default, but can be manually set to an arbitrary value as well.

Looking at the openhivescale firmware, that seems to hardcode the AppEUI and AppKey, and use the DevEUI stored inside the microchip modem. I think we can make this work with TTN, but it would actually be better if the AppEUI and certainly the AppKey could be modified (the current approach of hardcoding a public AppKey seems to be a security problem, I think). Perhaps you could consider to modify the firmware so you can set the AppEUI and AppKey through the webinterface? Perhaps also the DevEUI (not needed for TTN, but maybe for other networks).

As for OTAA joining: I would suggest only doing an OTAA join on initial powerup, rather than on every message. TTN can do both, but IIRC for every join a new unique nonce must be generated, and reusing one poses a security problem (TTN protects against this by storing a history of used nonces, but they can't store an infinite amount). I'm not quite familiar with the Microchip module, but I think it should support persistently storing the OTAA results. One thing is to decide when to redo OTAA (in case you need to switch networks, or your session is otherwise broken). If adr (automatic data rate) is enabled, the modem should be able to detect a connectivity problem and redo activation. Alternatively, an explicit "redo OTAA" button in the webinterface would make sense.

As for the HTTP callback: TTN allows adding an HTTP integration to an application, which makes it send all messages to an arbitrary HTTP endpoint. I think this could be configured to send data into your platform, though you might need to make some changes on your end to support the particular format TTN is uing. To help with that, I've captured one such HTTP request (not from an openhivescale, so the payload is different, but the rest of the structure should be the same).

Here's the headers used:

Of these headers, the value of the Authorization header can be set to
any arbitrary string, and it is probably a good idea to check this
header on your end to prevent spoofed HTTP requests. TTN also allows
adding an arbitrary additional header if that helps for you, or use an
arbitrary HTTP method.

Here's the request body:

  "app_id": "meet-je-stad",
  "dev_id": "meetstation-288",
  "hardware_serial": "0000000000000120",
  "port": 12,
  "counter": 1155,
  "payload_raw": "AhoVsQKySgYGvusQ/g==",
  "payload_fields": {
    "firmware_version": 2,
    "humidity": 107.875,
    "latitude": 52.169464111328125,
    "longitude": 5.39288330078125,
    "lux": 4331,
    "supply": 3.54,
    "temperature": 6
  "metadata": {
    "time": "2019-01-27T10:08:41.143947354Z",
    "frequency": 867.9,
    "modulation": "LORA",
    "data_rate": "SF9BW125",
    "coding_rate": "4/5",
    "gateways": [
        "gtw_id": "mjs-gateway-4",
        "gtw_trusted": true,
        "timestamp": 4159638420,
        "time": "2019-01-27T10:08:41Z",
        "channel": 7,
        "rssi": -90,
        "snr": 12.25,
        "rf_chain": 0,
        "latitude": 52.168682,
        "longitude": 5.391306,
        "location_source": "registry"
  "downlink_url": ""

Here, the hardware_serial is the DevEUI, the app_id and dev_id are
arbitrary identifiers that are set in the TTN portal (but not used in
the radio protocol). The "payload_fields" element contains the result of
a decoder (a bit of custom javascript configured in the TTN portal) that
can decode the binary payload (but for the openhivescale case, this
should probably not be needed, you can use the payload_raw (base64
version of the binary payload) directly. The metadata field contains
data on the radio transmission and receiving gateways, but probably
isn't relevant here either.

Note that I intentionally broke the "downlink_url", since my post was refused then saying "too more links in message. Allowed 2 links." even when I only have two links in my post...

Would that be enough info, or do you need additional details?