Topic: LoRaWAN
Hey,
have you ever thought about a LoRaWAN version for the scale?
Re: LoRaWAN
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
- +VBAT
- GND
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 2018-11-18 19:25:01 (edited by phisch92 2018-11-18 19:27:34)
Re: LoRaWAN
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. 
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
Philipp
4 2019-01-13 22:11:29 (edited by manuel 2019-01-13 23:37:01)
Re: LoRaWAN
Hi,
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!
Cheers from Norway
manuel
Re: LoRaWAN
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 :
https://www.microchip.com/forums/m945840.aspx
- 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 192.168.4.1 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.
Pierre
Re: LoRaWAN
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": "integrations.thethingsnetwork.org/ttn-eu/api/v2/down/meet-je-stad/http-test?key=ttn-account-v2.XF4Qs97ZiH07cWNhkvIUGCnTv_GhI4q4LbPWbhr6sIk"
}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?
Re: LoRaWAN
Hello,
I finally found the time to adapt the service endpoint to accept TTN.
It's not easy because I don't have a TTN coverage here to test.
I took your request body example, and just changed the payload_raw :
"payload_raw": "MDAwMA=="
(4 bytes, all equals to decimal 48 (== ascii '0'))
And posted as is :
curl -d "@bodyexample2.txt" -H "Content-Type: application/json" -A http-ttn/2.6.0 http://openhivescale.org/monitor/index.php?r=post-measure%2FindexI rely on user-agent to decide to process the request as a sigfox packet, or lora.
From the body, I just read hardware_serial and payload_raw.
I modified the admin page, http://openhivescale.org/monitor/index. … ve%2Findex and added a Lora DevEUI field.
I also did modifications on the firmware to make AppEUI/AppKey configurable. But not yet a smart 'join OTAA'.
To be continued...
8 2019-05-07 09:05:02 (edited by matthijs 2019-05-07 09:16:16)
Re: LoRaWAN
Cool!
I don't have a scale for testing myself (and I'm also a couple of hundred km away from Manual), but I'll see if I can document how to make this work for Manual and others to test. To set this up:
Create an account with TTN (I think through https://console.thethingsnetwork.org/)
In the TTN console, create an application (an application collects one or more similar devices, so if you have multiple scales it would make sense to put them in the same application)
"Application ID" is any string you like, to identify the application for your own reference. Same for "Description" (which can also be empty).
"Application EUI" will be generated by TTN (you can add secondary AppEUIs later if needed, but this is not the case for the scale).
Under "Handler registration" you can select the TTN handler server to use, typically based on your region.
In the TTN console, inside the application go to "Integrations" , click "add integration" and select "HTTP Integration".
"Process ID" is any string you like, to identify the integration for your own reference.
Under "Access key", you select the login used by the integration. The "default" key that should be listed there is fine.
The "URL" should be "http://openhivescale.org/monitor/index. … re%2Findex". This tells TTN to send all received data to openhivescale.org.
"Method" should be the default "POST"
All other values can be left empty.
In the TTN console, inside the application, create a device.
"Device ID" is any string you like, to identify the device for your own reference.
"Device EUI" is the id that is sent over the air to identify the node. It must match the value preconfigured in the Lora module (which can probably be found on a label on the actual module, or retrieved through the webinterface of the scale).
"App key" is the unique (per-device) security key will be autogenerated, you will have to copy this value into the scale later.
"App EUI" is the id to identify the application (group of devices) and has been autogenerated when you created the application. You will have to copy this value into the scale later.
You can look up all values after adding the device as well. All values can be changed later as well, except for the "Device ID".
Update the firmware running on the scale to a version that includes the changes that Pierre mentioned above. @Pierre, is there a precompiled version available somewhere already? Or perhaps you could post a one-off testing version? Do you have a reference to firmware update instructions somewhere as well? I could not find any just now.
Inside the webinterface of the scale, set the "AppEUI" and "AppKey" to the values shown in the TTN console for the device you added.
In the Openhivescale.org admin interface add a hive and configure the DevEUI to the Device EUI you also configured in the TTN console. @Pierre, is there anything else to be set up on the openhivescale.org side of things? I suppose the device should be linked to an account somehow?
Disclaimer: All of the above is untested, since I don't have a scale myself. If you try this, please followup with your results :-)
After that, data should be sent from your scale, through TTN to openhivescale.org and displayed there. If it does not work, you can also look in the TTN console (there is a "Data" tab for the application and the device) to see any data coming in to TTN for your application/device in realtime (so you can see whether the problem is in the scale -> TTN or TTN -> openhivescale.org part of the flow).