Announcing staging environment of TTN Back-end 1.0

TTN Network and Services
21

@w4e’s example works for static (ABP) devices. For dynamic (OTAA) devices, you can use the following:

❯ ttnctl devices register 0102030405060708
  INFO Generating random AppKey...
  INFO Registered device                        AppKey=45316EFBEFA00AE3CB10A323E9BD24E2 DevEUI=0102030405060708
22

Hi all, first of all congrats for the new backend!! :smiley:

I was wondering that in case I would like to run a private network setup with this new TTN Backend, according to the wiki and this overview, I only have to create a Docker-compse file that includes the configuration there shown?

Thanks in advance,

Regards,

EDIT: I have tried that but I got errors in the broker that cannot connect to the account server, is that needed for private networks?

broker_1 | FATAL Broker has fallen… error=Invalid operation: Failed to refresh token key: Get https://account.thethingsnetwork.org/key: dial tcp: lookup account.thethingsnetwork.org on 127.0.0.11:53: read udp 127.0.0.1:46121->127.0.0.11:53: i/o timeout

23

@htdvisser @w4e thanks! I can now join via ABP and receive messages with ttnctl subscribe.

However, if I try to use OTAA it fails to join. I’ve configured the Multitech MDOT with:

AT+PN (public network) - tried both 1 and 0. Not sure which it should be now?
AT+NK (network key/AppKey in Loramac) - set with AppKey
AT+NI (network ID/App EUI in Loramac) - set with AppEUI

I’ve registered the device with ttnctl using the full EUI (008000000000ADB3).

Also, how do you use ttnctl to de-register/delete a device?

And do you need to do anything else (on the gateway or via ttnctl) to enable acknowledged uplink?

24

Very good job! Thanks!

Just one question… how can we delete a user created with “ttnctrl user create”?

tks!

25

You do need access to an account server. You can use TTN’s account server on https://account.thethingsnetwork.org. We’re still doing quite some development on this, but as soon as the API is stable, we’ll define a specification for this account server so that you can implement your own.

This could be caused by a number of things. For example if you have a single-channel gateway closeby (#140), if you’re not in Europe (#119 and #120) or some other unknown issue. Talk to me on Slack tomorrow (CEST) and I can try to help you.

That’s not possible yet, but it’s on our todo list.

Only use confirmed uplink if you really need it. It eats downlink capacity.

That’s not possible yet, but it’s on our todo list.

1 Like
26

This could be caused by a number of things. For example if you have a single-channel gateway closeby (#140), if you’re not in Europe (#119 and #120) or some other unknown issue. Talk to me on Slack tomorrow (CEST) and I can try to help you.

Thanks, @htdvisser. I’m in the UK and fairly sure there are not any other gateways nearby. I’m out of the office today, but will be back with the gateway tomorrow afternoon around 14:00 UTC.

Regarding confirmed uplink, I have a survey app from Multitech that uses this to measure downlink RSSI, which is then stored along with the GPS coordinates and timestamp. However, it just occurred to me that I should probably have been using the experimental branches from the Lora-net GitHub repos in order for the gateway to support ACKs.

27

Thanks @htdvisser , I understand it.So in that case if my private network cannot reach the internet, I cannot use the new backend from TTN till its API is stable right? I have noticed that the broker crashes if it cannot reach that server, so I commented it but still it was crashing.

28

Hi,

After the update our gateway has disappeared from ttnstatus and ttnmap. Are these tools linked to the new backend or not?

29

Yes, all traffic is forwarded to the existing croft prototype, so they should end up on ttnstatus.org and thethingsnetwork.org/map, as before.

30

In a private offline network (see wiki), you can implement your own authentication mechanism. It is still token-based, but you can issue your own tokens and disable authentication on MQTT, for example.

31

The same frequency of Australia will be used in Brazil

32

Yep… And the US frequencies in South America (except Brazil) and Canada. And there are a lot more exceptions, so we’ll probably build a list where you can find the correct frequency for each country.

33

Ah, that was the last missing puzzle piece in my application - that the DevEUI in the mqtt topic is the DevAddr (like 02E00202) with 8 pre-pended zeros. Actually discovered it by subscribing with wildcards ( +/devices/+/up ) in nodejs, and then printing out the topic when a message came in! Working great now…

34

Hi @johan, could you explain me a bit more how to disable authentication on mosquitto and the token based mechanism?

I create my server using Docker with this configuration file, where I commented out these two lines

  - TTN_HANDLER_MQTT_USERNAME=yourusername        # You don't need this if you use 
  - TTN_HANDLER_MQTT_PASSWORD=yourpassword        #   the default mosquitto server

  - TTN_BROKER_ACCOUNT_SERVER=https://account.thethingsnetwork.org

However running the backend mosquitto does not fail but the broker does with this error

broker_1 | FATAL Broker has fallen… error=Invalid operation: Failed to refresh token key: Get https://account.thethingsnetwork.org/key2: dial tcp: lookup account.thethingsnetwork.org on 127.0.0.11:53: read udp 127.0.0.1:46121->127.0.0.11:53: i/o timeout

Thank you very much in advance,

35

I tried ttn on a private server (Docker-based deployment). It looks pretty good.
Thanks again to all involved!

Some remarks:

  • For downlink and mqtt, use (for example):
    {“payload”:“SGVsbG8gd29ybGQK”,“port”:1,“ttl”:“1h”}

    If I use (from the wiki):
    { payload: ‘SGVsbG8gd29ybGQK’, port: 1, ttl: ‘1h’ }
    it doesn’t work.

  • If I “downlink” in using (for example) port 15 (or an other) my node (RN2483 based)
    always received on the port 1.

BR

36

Thanks @laura, I’ll update the wiki. The only difference is the JSON formatting, right?

37

We’re using tokens to authenticate and authorize users and applications. The tokens are issued by the account server. You can issue your own tokens if you implement your own account server too. We did not publish specifications for that yet because it is still in development. Tokens are signed with a private key and can be validated with a public key. This public key is required in the Broker to check if the token from the client (e.g. ttnctl) is valid.

It looks like you try to get the wrong key; the Broker tries to get the public key for validating the token from https://account.thethingsnetwork.org/key. The Broker tries this on start-up. If it fails, because there’s no internet, then the cached key is used. So make sure that your start the Broker at least once with an internet connection.

1 Like
38

I’m really struggling to get a device registered.

I use the standard command and I’m getting the following error message. I’ve managed to get the re-configured etc.
Setup up new account and password
Setup and Application
Associate the application

./ttnctl devices register personalized 02D1DD03
INFO Generating random NwkSKey and AppSKey…
FATAL Could not register device error=rpc error: code = 2 desc = Invalid operation: rpc error: code = 2 desc = Invalid operation: Unauthorized

I’m clearly missing something obvious here!

39

Did you use the ttnctl applications use <AppEUI> command to activate your newly created application? See the AppEUI in the overview you get with ttnctl applications.

40

Yes did that. And got an affirmative result

ttnctl applications use 008000000000xxxx
INFO You are now using application 008000000000xxxx.