Announcing staging environment of TTN Back-end 1.0

[johan (Johan Stokking)]

That is the gateway, not the AppEUI.

[JimK (Jim Kirkby)]

in the wiki could we add, it might make it a bit more clear for idiots like mw who need spoon feeding every command.

Application Management

Now create a new application with ttnctl applications create. In this example we will create an application named Hello World App. The

❯ ttnctl applications create ‘Hello World App’
INFO Application created successfully
If you work in a group, you can authorize your colleagues to manage the application with the ttnctl applications authorize command:

*Now type this to provide all the running details for you’re application. *
*> ttnctl applications *
EUI Name Owner Access Keys Valid
xxxxxxxxxxx xxx test1 test1@txxxx.xyz xxxxxxxxxxxxxxxxxxxxxxxxxxxxx= true

❯ ttnctl applications authorize 0807060504030201 john@doe.org
INFO User authorised successfully

Thats the bit I clearly missed

[htdvisser (Hylke Visser)]

@laura

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

Still have to make that work

See issue #127

[ndarkness]

@johan

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.

I guess that once it id comletely develop you would provide some guide in order to know how to interface with a private account server too right?

@johan

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.

Then that means too that for now if I want to use the TTN backed for a private network, I have to register my nodes into the TTN devices server otherwise I won’t see any traffic from my nodes since if they are not register, the broker wouldn’t allow them have access to the network, am I right?

@johan

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.

I did it once, and now I don get the starting error in the broker, , thanks @johan

[johan (Johan Stokking)]

@ndarkness

I guess that once it id comletely develop you would provide some guide in order to know how to interface with a private account server too right?

Yes. It’s basically OAuth 2.0.

@ndarkness

Then that means too that for now if I want to use the TTN backed for a private network, I have to register my nodes into the TTN devices server otherwise I won’t see any traffic from my nodes since if they are not register, the broker wouldn’t allow them have access to the network, am I right?

The account server tracks user information and applications only. The devices and their security keys are registered in the handler. You can easily use TTN’s account server for private networks. Only in offline scenarios you would need a local account server.

[laura]

Hi all,

Concerning downlink and mqtt…

How is managed the downlink? Only the last request is kept (it seems the case; the node reveives only the downlink data from the last request)? The requests are queued in a fifo?

Thanks to the community and the core development team!

[johan (Johan Stokking)]

It is indeed a queue of size 1. We’re considering fifo and make the queue size configurable. We decided not to build it this way to keep it simple, both the handling of messages and configuration options. If you need this feature, please raise an issue on GitHub cause it’s not there yet.

[laura]

Concerning downlink and mqtt…

Is it correct to use the following value to tun the ttl? :

• “e.g. for a ttl == 1 hour (ok is coming from the wiki)”
  {“payload”:“SGVsbG8gd29ybGQK”,“port”:1,“ttl”:“1h”}

• “e.g. for a ttl == 1 minute”
  {“payload”:“SGVsbG8gd29ybGQK”,“port”:1,“ttl”:“1m”}

• “e.g. for a ttl == 1 second”
  {“payload”:“SGVsbG8gd29ybGQK”,“port”:1,“ttl”:“1s”}

Tks!

[laura]

something else!

After the initialization of my node and it joined (otaa) the network… if a use: ttnctl devices info my_device
I get for FCn:
FCntUp: 0
FCntDn: 0

That seems normal.

If my node send data (e.g. with a rn2483: “mac tx cnf 1 3939390A”) I get
(after tapping again: ttnctl devices info my_device)
FCntUp: 0
FCntDn: 1

After that, if my node sends again data, I get
FCntUp: 1
FCntDn: 2

[johan (Johan Stokking)]

Yes that’s correct.

Can you raise an issue for the second remark?

[Arjan]

Regarding the downlink: how can you tell the message for a node has been removed from the queue (in other words: can I check wether the queue for node x is still waiting?) and how do I know the message has been successfully delivered to/received by the node?

[johan (Johan Stokking)]

That is currently not possible. For this, we need to introduce a new topic, e.g. <AppEUI>/devices/<DevEUI>/down-tx. You can submit an issue for this on GitHub.

[Arjan]

Ok!

Issue: Tx-queue MQTT topic

[wienkegiezeman]

This topic is no longer a banner. It will no longer appear at the top of every page.