Pq: database "ttn_lorawan" does not exist


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.

What am I missing?


Paging @benolayinka, the TTI 4 minute install guru …

Curious to know what you are sensing that needs a private network - what will the GCHQ be thinking!

Despite having 12 GW’s in the area the Uni must be declaring UDI from the local Ceredigion Community! :rofl:

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 :wink: ). Hopefully you are not attempting to stream vision/video or virtualisation/classification of unidentified roads or streaming continuous robotic control messages over LoRa/LoRaWAN?! :wink:

A great reason in and of itself! :+1: :slight_smile: Hopefully we will see the Uni set up a Comp Sci LoRaWAN & IoT course in the future as a result! :wink: 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 :wink:

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:


version: '3.7'

  # If using CockroachDB:
    # 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
      - ${DEV_DATA_DIR:-.env/data}/cockroach:/cockroach/cockroach-data
      - "" # Cockroach
      - "" # 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:
  #     - ""

    # 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
      - ${DEV_DATA_DIR:-.env/data}/redis:/data
      - ""

    # 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
      - redis
      # If using CockroachDB:
      - cockroach
      # If using PostgreSQL:
      # - postgres
      - ./blob:/srv/ttn-lorawan/public/blob
      - ./config/stack:/config:ro
      # If using Let's Encrypt:
      - ./acme:/var/lib/acme
      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

      # 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:
      - ca.pem
      - cert.pem
      - key.pem

# If using custom certificates:
    file: ./ca.pem
    file: ./cert.pem
    file: ./key.pem


# Identity Server configuration
# Email configuration for "thethings.example.com"
    sender-name: 'The Things Stack'
    sender-address: 'noreply@thethings.example.com'
      name: 'The Things Stack'
      console-url: ''
      identity-server-url: ''

    # 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 "":
      canonical-url: ''
        base-url: ''

# HTTP server configuration
    block-key: ''                # generate 32 bytes (openssl rand -hex 32)
    hash-key: ''                 # generate 64 bytes (openssl rand -hex 64)
    password: 'metrics'               # choose a password
    password: 'pprof'                 # choose a password

# If using custom certificates:
  source: file
  root-ca: /run/secrets/ca.pem
  certificate: /run/secrets/cert.pem
  key: /run/secrets/key.pem

# Let's encrypt for ""
#  source: 'acme'
#  acme:
#    dir: '/var/lib/acme'
#    email: 'you@thethings.example.com'
#    hosts: ['']
#    default-host: ''

# If Gateway Server enabled, defaults for "":
    public-address: ''
    public-tls-address: ''
    public-address: ''
    public-tls-address: ''

# If Gateway Configuration Server enabled, defaults for "":
      lns-uri: 'wss://'
      mqtt-server: 'mqtts://'

# Web UI configuration for "":
    canonical-url: ''
      base-url: ''
      base-url: ''
      base-url: ''
      base-url: ''
      base-url: ''
      base-url: ''
      base-url: ''
      base-url: ''

    authorize-url: ''
    token-url: ''
    logout-url: ''
    client-id: 'console'
    client-secret: 'console'          # choose or generate a secret

# If Application Server enabled, defaults for "":
    public-address: ''
    public-tls-address: ''
      public-address: ''

# If Device Claiming Server enabled, defaults for "":
    authorize-url: ''
    token-url: ''
    logout-url: ''
    client-id: 'device-claiming'
    client-secret: 'device-claiming'          # choose or generate a secret
    canonical-url: ''
      base-url: ''
      base-url: ''
      base-url: ''
      base-url: ''

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 :wink: 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 :wink: 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! :wink: 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+ :wink:

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:


Everything you need to pass the TTI LoRaWAN Fundamentals certificate