1 Reply by matthijs

(7 replies, posted in Technical)

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).

Go to forum: Technical

2 Reply by matthijs

(7 replies, posted in Technical)

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:

https://i.postimg.cc/F9GZNmcX/Selection-003.png?dl=1

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?

Go to forum: Technical