Back to topic, my initial query was when using an IP address for the computer name. If I use localhost I donât have this issue. I am not sure I understand the implications of using localhost though. We will have other computers in the network to do some live stuff with the data.
Can you share your docker-compose.yml and ttn-lw-stack.yml?
If it works on localhost, it sounds like either the network is blocking the database request to that IP or the IP is incorrect for the identity server?
So you want to use a larger part of the shared pie (airtime on limited frequencies)? Using a long range technology that will impact other users (many) miles away?
I am currently trying at home and there is nothing that blocks anything internally, especially not from my computer to itself (unless ubuntu/docker is doing something weird behind my back).
Not sure how best to share these, so here go:
docker-compose.yml:
version: '3.7'
services:
# If using CockroachDB:
cockroach:
# In production, replace 'latest' with tag from https://hub.docker.com/r/cockroachdb/cockroach/tags
image: cockroachdb/cockroach:latest
command: start-single-node --http-port 26256 --insecure
restart: unless-stopped
volumes:
- ${DEV_DATA_DIR:-.env/data}/cockroach:/cockroach/cockroach-data
ports:
- "127.0.0.1:26257:26257" # Cockroach
- "127.0.0.1:26256:26256" # WebUI
# If using PostgreSQL:
# postgres:
# image: postgres
# restart: unless-stopped
# environment:
# - POSTGRES_PASSWORD=root
# - POSTGRES_USER=root
# - POSTGRES_DB=ttn_lorawan
# volumes:
# - ${DEV_DATA_DIR:-.env/data}/postgres:/var/lib/postgresql/data
# ports:
# - "127.0.0.1:5432:5432"
redis:
# In production, replace 'latest' with tag from https://hub.docker.com/_/redis?tab=tags
image: redis:latest
command: redis-server --appendonly yes
restart: unless-stopped
volumes:
- ${DEV_DATA_DIR:-.env/data}/redis:/data
ports:
- "127.0.0.1:6379:6379"
stack:
# In production, replace 'latest' with tag from https://hub.docker.com/r/thethingsnetwork/lorawan-stack/tags
image: thethingsnetwork/lorawan-stack:latest
entrypoint: ttn-lw-stack -c /config/ttn-lw-stack-docker.yml
command: start
restart: unless-stopped
depends_on:
- redis
# If using CockroachDB:
- cockroach
# If using PostgreSQL:
# - postgres
volumes:
- ./blob:/srv/ttn-lorawan/public/blob
- ./config/stack:/config:ro
# If using Let's Encrypt:
- ./acme:/var/lib/acme
environment:
TTN_LW_BLOB_LOCAL_DIRECTORY: /srv/ttn-lorawan/public/blob
TTN_LW_REDIS_ADDRESS: redis:6379
# If using CockroachDB:
TTN_LW_IS_DATABASE_URI: postgres://root@cockroach:26257/ttn_lorawan?sslmode=disable
# # If using PostgreSQL:
# TTN_LW_IS_DATABASE_URI: postgres://root:root@postgres:5432/ttn_lorawan?sslmode=disable
ports:
# If deploying on a public server:
- "80:1885"
- "443:8885"
- "1881:1881"
- "8881:8881"
- "1882:1882"
- "8882:8882"
- "1883:1883"
- "8883:8883"
- "1884:1884"
- "8884:8884"
- "1885:1885"
- "8885:8885"
- "1887:1887"
- "8887:8887"
- "1700:1700/udp"
# If using custom certificates:
secrets:
- ca.pem
- cert.pem
- key.pem
# If using custom certificates:
secrets:
ca.pem:
file: ./ca.pem
cert.pem:
file: ./cert.pem
key.pem:
file: ./key.pem
ttn-lw-stack-docker.yml:
# Identity Server configuration
# Email configuration for "thethings.example.com"
is:
email:
sender-name: 'The Things Stack'
sender-address: 'noreply@thethings.example.com'
network:
name: 'The Things Stack'
console-url: 'https://192.168.1.133/console'
identity-server-url: 'https://192.168.1.133/oauth'
# If sending email with Sendgrid
# provider: sendgrid
# sendgrid:
# api-key: '...' # enter Sendgrid API key
# If sending email with SMTP
# provider: smtp
# smtp:
# address: '...' # enter SMTP server address
# username: '...' # enter SMTP server username
# password: '...' # enter SMTP server password
# Web UI configuration for "192.168.1.133":
oauth:
ui:
canonical-url: 'https://192.168.1.133/oauth'
is:
base-url: 'https://192.168.1.133/api/v3'
# HTTP server configuration
http:
cookie:
block-key: '' # generate 32 bytes (openssl rand -hex 32)
hash-key: '' # generate 64 bytes (openssl rand -hex 64)
metrics:
password: 'metrics' # choose a password
pprof:
password: 'pprof' # choose a password
# If using custom certificates:
tls:
source: file
root-ca: /run/secrets/ca.pem
certificate: /run/secrets/cert.pem
key: /run/secrets/key.pem
# Let's encrypt for "192.168.1.133"
#tls:
# source: 'acme'
# acme:
# dir: '/var/lib/acme'
# email: 'you@thethings.example.com'
# hosts: ['192.168.1.133']
# default-host: '192.168.1.133'
# If Gateway Server enabled, defaults for "192.168.1.133":
gs:
mqtt:
public-address: '192.168.1.133:1882'
public-tls-address: '192.168.1.133:8882'
mqtt-v2:
public-address: '192.168.1.133:1881'
public-tls-address: '192.168.1.133:8881'
# If Gateway Configuration Server enabled, defaults for "192.168.1.133":
gcs:
basic-station:
default:
lns-uri: 'wss://192.168.1.133:8887'
the-things-gateway:
default:
mqtt-server: 'mqtts://192.168.1.133:8881'
# Web UI configuration for "192.168.1.133":
console:
ui:
canonical-url: 'https://192.168.1.133/console'
is:
base-url: 'https://192.168.1.133/api/v3'
gs:
base-url: 'https://192.168.1.133/api/v3'
gcs:
base-url: 'https://192.168.1.133/api/v3'
ns:
base-url: 'https://192.168.1.133/api/v3'
as:
base-url: 'https://192.168.1.133/api/v3'
js:
base-url: 'https://192.168.1.133/api/v3'
qrg:
base-url: 'https://192.168.1.133/api/v3'
edtc:
base-url: 'https://192.168.1.133/api/v3'
oauth:
authorize-url: 'https://192.168.1.133/oauth/authorize'
token-url: 'https://192.168.1.133/oauth/token'
logout-url: 'https://192.168.1.133/oauth/logout'
client-id: 'console'
client-secret: 'console' # choose or generate a secret
# If Application Server enabled, defaults for "192.168.1.133":
as:
mqtt:
public-address: '192.168.1.133:1883'
public-tls-address: '192.168.1.133:8883'
webhooks:
downlink:
public-address: '192.168.1.133:1885/api/v3'
# If Device Claiming Server enabled, defaults for "192.168.1.133":
dcs:
oauth:
authorize-url: 'https://192.168.1.133/oauth/authorize'
token-url: 'https://192.168.1.133/oauth/token'
logout-url: 'https://192.168.1.133/oauth/logout'
client-id: 'device-claiming'
client-secret: 'device-claiming' # choose or generate a secret
ui:
canonical-url: 'https://192.168.1.133/claim'
as:
base-url: 'https://192.168.1.133/api/v3'
dcs:
base-url: 'https://192.168.1.133/api/v3'
is:
base-url: 'https://192.168.1.133/api/v3'
ns:
base-url: 'https://192.168.1.133/api/v3'
As I said, very close to the original example. And when comparing the IP version to the localhost version (which works), the only differences are to do with the IP vs the localhost.
I know! Itâs a battle Iâm going to have to have with my collaborators. I am currently reading up on this to see what the practical limits will be.
Do the legal limits given at https://www.thethingsnetwork.org/docs/lorawan/duty-cycle/#maximum-duty-cycle apply to reception as well (on the GW side)? This is not clear from this page.
We can help guide and educate your collaborators if needed 
Bottom line is that whilst FP only applies to TTN, legal limts still apply and key message is just because legal limits allow an âup toâ threshold that you âcanâ does not mean you âshouldâ! In the context of LoRaWAN remember it is a broadcast technology so all GWâs in range (however far away!) of your nodes will see your messages and on detecting a valid LoRa packet start will allocate their precious internal demod resources to decoding your nodes message and will blindly send on to their associated backend servers - TTN or not. Only at the NS will your âforeignâ packet/message be droppedâŚmeantime you have consumed both spectrum and (potentially hundreds!) of other GWâs resourses I often recommend that the FUP be applied for private use also as it is a âgood citizenâ behaviour model, though there are use cases for my own or clients/collaborators where I will step beyond on private deployments - even then I think very hard before allowing them to go more than 10% of legal and often ask them to rethink how they implementâŚ
Aber isnt too far for some of the UK folk to come and explore with you if needed - Iâm Thames Valley but roam around and Iâm sure Nick may even be up for trip to the seaside! There is also a lot of experience in Wales with the Gwynedd deployment and many others that you might reach out to (see the community map)
BTW will PM you laterâŚ
The duty cycle limits are only for transmission. You can receive as long as you want (or until your battery is empty). The transmission time is legally limited in EU eg to 36 seconds per hour, band and node (gateway) on most frequencies we use. But this is far beyond FUP.
Thanks for that. The âdownlink messages to 10 messages per day (24 hours) per nodeâ mentioned in the FUP is from GW to device (sensor), correct?
Yes, but the very very best thing you could do right now is tell us how big your uplink payloads are and how frequently the soil changes such that you want to send an uplink.
Because then you get âAlmost Instant Answerâ˘ď¸â on how this impacts the FUP.
Also, please consider that if your TTS OS instance goes awol during the data collection phase, the rental of a server or the 1 minute typing up the payload size / frequency of uplink may be cheaper than deployment with huge gaps due to no back end!
That is what I was working on right now (in between meetings). We will be using the raised version of the Tektelic agri sensors (for now anyway). By default they send 11 bytes (in fact 10 every 15 minutes and also battery voltage every day so an additional byte once a day). According to https://avbentem.github.io/airtime-calculator/ttn/eu868/11 this would limit us to using DR3, DR4 or DR5 if we want to use the default one message every 15 mins (we could go down to DR0 if only concerned about the legality aspect). I have yet to see how/if we select these on the devices. So far I have not seen much explanation on this DRx, but I am still reading.
A just received email from the person who will use the data says that one reading every 15mins is probably OK, for each of the 35 sensors.
From a device point of view that is right. From gateway point of view all transmission are subject to the legal limits just as any other transmitter. So 10 devices with 10 downlinks means 100 transmissions for a gateway.
More importantly âŚand the reason FUP says 10 max per day for downloads to a node(*) on the community network ⌠when a GW sends that downlink it stops listening to any uplinks - it goes deaf to potentially all other nodes in an area - for the duration.
(*) If on a private network on your own gateway that may not concern you as you will only loose your own messages, though there is still the social spectrum impact of your gw doing additional txs on shared channels if rx1 window, or contesting the standard channel for rx2 window⌠on TTN many encourage users to think more in terms of 10 DL per week, per fortnight or even per month+
These are all really interesting discussions. In our case, I donât think we will need to send data from the GW to the sensors, apart maybe at the setup period if we need to change from the default config. But I might well discover things as we progress!
1 Like
Seems you have your answer then - just use TTN.
No you canât - network operators are required to limit the use of devices on DR0 & 1.
Perhaps a focused read of this will help:
https://www.thethingsnetwork.org/docs/lorawan/
Everything you need to pass the TTI LoRaWAN Fundamentals certificate
I had read some of that, but not from the start so was missing a few things. I am not sure I understand your remark about DR0 & 1. I didnât see this mentioned anywhere and by default the sensors we are getting do ADR on DR0.
Anybody got any solution to my original problem? Hopefully Iâll get a GW this PM so would love to get a server running by then.
Hi, I have the same problem as [flabrosse]
1 Like
Hi, in docker-compose.yaml I changed :
image: thethingsnetwork/lorawan-stack:latest
with :
image: thethingsnetwork/lorawan-stack:3.18.0
and it worked
2 Likes
Yes it works! Thank you so much friend!
I just tried it, and it does indeed! How did you come up with this? Marking as solution.
Maybe this is a bug? Maybe the instructions need to be updated?