Very new to LoRaWAN and thethingsnetwork. We have a project where we need to create a ocal, private network for 35 or so sensors. So I have been trying to install TTS on a computer that eventualy will be on a private network. I have followed the instructions, and so far so good. However, when trying to initialise the database of the Identity Server, I get:
~/TTN$ docker-compose run --rm stack is-db init
Starting ttn_redis_1 ... done
Starting ttn_cockroach_1 ... done
Creating ttn_stack_run ... done
INFO Connecting to Identity Server database...
pq: database "ttn_lorawan" does not exist
ERROR: 255
I have been searching a lot on that, found a post here that mentions a similar error but then progresses without without giving a solution to that specific problem. My config files are very similar to the instructions, where I have replaced the URL thethings.example.com with my IP address.
Nothing secret, I can assure you. But we will need to post more data than we can without paying extra (and the project doesnât have the money for that) when using the existing systems. And I use this as a learning experience for myself. Also, given where our sensors are, none of the GW put up by Ceredigion are accessibleâŚ
Not sure what you mean by this - can you give/share some details as we may be able helpâŚTTN is a free to use resource (if you follow & stick to the TTN Manifesto & FUP ). Hopefully you are not attempting to stream vision/video or virtualisation/classification of unidentified roads or streaming continuous robotic control messages over LoRa/LoRaWAN?!
A great reason in and of itself! Hopefully we will see the Uni set up a Comp Sci LoRaWAN & IoT course in the future as a result! Sure people like Nick, myself and others on the Forum willing to assist and provide pointers if you do (there is accumated experience in traiing and coaching others, inc students at various levels).
That is the whole point. When I mentioned FUP to colleagues, they said this might not be enough. We are still discussing this but we might want to send data every few minutes from about 35 sensors. I still have to look at regs to see what is possible though. No, nothing like video streams! Only soil data.
PS Itâs not fair, you clearly know who I am, I have no idea who you are
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.
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)
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.
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!
). Hopefully you are not attempting to stream vision/video or virtualisation/classification of unidentified roads or streaming continuous robotic control messages over LoRa/LoRaWAN?! 
Hopefully we will see the Uni set up a Comp Sci LoRaWAN & IoT course in the future as a result!