search

xirixiz / dsmr-reader-docker

DSMR Reader in Docker.
https://hub.docker.com/r/xirixiz/dsmr-reader-docker
114 stars 33 forks source link

datalogger - sender not working anymore #164

Closed puijken closed 3 years ago

puijken commented 3 years ago

Hi everyone,

Have this issue since a couple of weeks but only now got the time to do some troubleshooting .. probably being stupid but after reading the documentation and trying a lot of stuf .. I cannot get it to work anymore.

Using a RaspberryPI as a datalogger sender to another docker container which is running in receiver mode. The receiver container is working fine and can access historical data. The sender docker used to provide the readings to the receiver docker via the API.

Now when starting the sender I'm getting the following error messages:

[ FAIL ] Could not connect to database server. Exiting..., [ INFO ] Verifying if the DSMR web credential variables have been set..., [ INFO ] Fixing /dev/ttyUSB security..., [ INFO ] Removing existing PID files..., [ INFO ] Creating log directory..., [ INFO ] Verifying Database connectivity..., Traceback (most recent call last):, File "/usr/local/lib/python3.9/site-packages/django/db/backends/base/base.py", line 219, in ensure_connection, self.connect(), File "/usr/local/lib/python3.9/site-packages/django/utils/asyncio.py", line 26, in inner, return func(args, kwargs), File "/usr/local/lib/python3.9/site-packages/django/db/backends/base/base.py", line 200, in connect, self.connection = self.get_new_connection(conn_params), File "/usr/local/lib/python3.9/site-packages/django/utils/asyncio.py", line 26, in inner, return func(*args, kwargs), File "/usr/local/lib/python3.9/site-packages/django/db/backends/postgresql/base.py", line 187, in get_new_connection, connection = Database.connect(conn_params), File "/usr/local/lib/python3.9/site-packages/psycopg2/init.py", line 127, in connect, conn = _connect(dsn, connection_factory=connection_factory, *kwasync), psycopg2.OperationalError: could not translate host name "dsmrdb" to address: Name does not resolve, , , The above exception was the direct cause of the following exception:, , Traceback (most recent call last):, File "/dsmr/manage.py", line 10, in , execute_from_command_line(sys.argv), File "/usr/local/lib/python3.9/site-packages/django/core/management/init.py", line 401, in execute_from_command_line, utility.execute(), File "/usr/local/lib/python3.9/site-packages/django/core/management/init.py", line 395, in execute, self.fetch_command(subcommand).run_from_argv(self.argv), File "/usr/local/lib/python3.9/site-packages/django/core/management/base.py", line 330, in run_from_argv, self.execute(args, cmd_options), File "/usr/local/lib/python3.9/site-packages/django/core/management/base.py", line 371, in execute, output = self.handle(*args, options), File "/usr/local/lib/python3.9/site-packages/django/core/management/commands/shell.py", line 87, in handle, exec(options['command']), File "", line 1, in , File "/usr/local/lib/python3.9/site-packages/django/utils/asyncio.py", line 26, in inner, return func(*args, *kwargs), File "/usr/local/lib/python3.9/site-packages/django/db/backends/base/base.py", line 219, in ensure_connection, self.connect(), File "/usr/local/lib/python3.9/site-packages/django/db/utils.py", line 90, in exit, raise dj_exc_value.with_traceback(traceback) from exc_value, File "/usr/local/lib/python3.9/site-packages/django/db/backends/base/base.py", line 219, in ensure_connection, self.connect(), File "/usr/local/lib/python3.9/site-packages/django/utils/asyncio.py", line 26, in inner, return func(args, kwargs), File "/usr/local/lib/python3.9/site-packages/django/db/backends/base/base.py", line 200, in connect, self.connection = self.get_new_connection(conn_params), File "/usr/local/lib/python3.9/site-packages/django/utils/asyncio.py", line 26, in inner, return func(*args, kwargs), File "/usr/local/lib/python3.9/site-packages/django/db/backends/postgresql/base.py", line 187, in get_new_connection, connection = Database.connect(conn_params), File "/usr/local/lib/python3.9/site-packages/psycopg2/init.py", line 127, in connect, conn = _connect(dsn, connection_factory=connection_factory, *kwasync), django.db.utils.OperationalError: could not translate host name "dsmrdb" to address: Name does not resolve, [ FAIL ] Could not connect to database server. Exiting..., [ INFO ] Verifying if the DSMR web credential variables have been set..., [ INFO ] Fixing /dev/ttyUSB security..., [ INFO ] Removing existing PID files..., [ INFO ] Creating log directory..., [ INFO ] Verifying Database connectivity...,

Running the following command for my sender docker: sudo docker run -d --name dsmr --restart always -e DJANGO-TIME_ZONE=Europe/Amsterdam -e DATALOGGER_MODE=sender -e DATALOGGER_API_HOSTS=https://hostname.domain.com -e DATALOGGER_API_KEYS=APIKEYREMOVEDPROBABLYDOESNTMATTER -e DATALOGGER_INPUT_METHOD=serial -e DATALOGGER_SERIAL_PORT=/dev/ttyUSB0 -e DATALOGGER_SERIAL_BAUDRATE=115200 --device /dev/ttyUSB0:/dev/ttyUSB0 xirixiz/dsmr-reader-docker

This just keeps looping... I would prefer not to give the sender docker access to the database as I think the idea of the API is to have it send to the receiver which in turn has access to the database. What am I doing wrong? :)

xirixiz commented 3 years ago

Hi, these are the kind of issues which are fun to solve :)

First things first:

puijken commented 3 years ago

Hi, sure let me provide you with some details about the setup.

compose file for dsmrreader

version: '3.6'

services: dsmrreader: image: xirixiz/dsmr-reader-docker:latest container_name: dsmrreader environment:

  • DSMRREADER_ADMIN_USER=snip # Webinterface user
  • DSMRREADER_ADMIN_PASSWORD=snip # Webinterface password
  • DJANGO_DATABASE_ENGINE=django.db.backends.postgresql
  • DJANGO_DATABASE_USER=dsmrreader_user
  • DJANGO_DATABASE_PASSWORD=snip
  • DJANGO_DATABASE_NAME=dsmrreader_db
  • DJANGO_DATABASE_HOST=dsmrpostgres.cont.domain.com
  • DJANGO_DATABASE_PORT=5432
  • DJANGO_SECRET_KEY=snip
  • DATALOGGER_MODE=receiver
  • DJANGO_TIME_ZONE=Europe/Amsterdam restart: always volumes:
  • data:/dsmr/backups labels: com.docker.compose.project: dsmrreader com.docker.compose.service: dsmrreader traefik.http.routers.dsmrreader-secure.entrypoints: websecure traefik.http.routers.dsmrreader-secure.rule: Host(dsmrreader.**snip**) traefik.http.routers.dsmrreader-secure.tls: true traefik.http.routers.dsmrreader-secure.tls.certresolver: wildcard-godaddy traefik.http.routers.dsmrreader-secure.tls.domains[0].main: "*.snip" traefik.http.services.dsmrreader-secure.loadbalancer.server.port: 80 traefik.enable: true networks: macvlan12: ipv4_address: 10.0.12.134 hostname: dsmrreader domainname: cont.domain.com volumes: data: networks: macvlan12: external: true

dsmrreader logs after fresh start

[ INFO ] Verifying if the DSMR web credential variables have been set..., [ INFO ] Fixing /dev/ttyUSB security..., [ INFO ] Removing existing PID files..., [ INFO ] Creating log directory..., [ INFO ] Verifying Database connectivity..., None, [ INFO ] Configuring DSMR in receiver datalogger mode...., [ INFO ] Running post configuration..., Operations to perform:, Apply all migrations: admin, auth, contenttypes, dsmr_api, dsmr_backend, dsmr_backup, dsmr_consumption, dsmr_datalogger, dsmr_frontend, dsmr_influxdb, dsmr_mindergas, dsmr_mqtt, dsmr_notification, dsmr_pvoutput, dsmr_stats, dsmr_weather, sessions, Running migrations:, No migrations to apply., 561 static files copied to '/var/www/dsmrreader/static'., Updating password of superuser "snip", [ INFO ] Checking for NGINX SSL configuration..., [ INFO ] ENABLE_NGINX_SSL is disabled, nothing to see here. Continuing..., [ INFO ] Checking for HTTP AUTHENTICATION configuration..., [ INFO ] ENABLE_HTTP_AUTH is disabled, nothing to see here. Continuing..., [ INFO ] Starting supervisord..., [ INFO ] Logfiles can be found at: /var/log/supervisor/.log and /tmp/supervisord.log, 2021-01-26 17:13:46,535 INFO Included extra file "/etc/supervisor.d/supervisord.ini" during parsing, 2021-01-26 17:13:46,535 INFO Set uid to user 0 succeeded, 2021-01-26 17:13:46,539 INFO RPC interface 'supervisor' initialized, 2021-01-26 17:13:46,540 CRIT Server 'unix_http_server' running without any HTTP authentication checking, 2021-01-26 17:13:46,540 INFO supervisord started with pid 16, 2021-01-26 17:13:47,544 INFO spawned: 'dsmr_backend' with pid 18, 2021-01-26 17:13:47,548 INFO spawned: 'dsmr_webinterface' with pid 19, 2021-01-26 17:13:47,550 INFO spawned: 'nginx' with pid 20, 2021-01-26 17:13:49,137 INFO success: dsmr_backend entered RUNNING state, process has stayed up for > than 1 seconds (startsecs), 2021-01-26 17:13:49,137 INFO success: nginx entered RUNNING state, process has stayed up for > than 1 seconds (startsecs), 2021-01-26 17:13:51,132 INFO success: dsmr_webinterface entered RUNNING state, process has stayed up for > than 3 seconds (startsecs),

compose file for postgres

version: "2.1" services: dsmr_postgres: image: postgres:13-alpine container_name: dsmr_postgres environment:

  • POSTGRES_USER=dsmrreader_user
  • POSTGRES_PASSWORD=snip
  • POSTGRES_DB=dsmrreader_db
  • TZ=Europe/Amsterdam
  • PID=1001
  • PGID=1001 volumes:
  • data:/var/lib/postgresql/data restart: always labels: networks: macvlan12: ipv4_address: 10.0.12.150 hostname: dsmr_postgres domainname: cont.snip volumes: data: networks: macvlan12: external: true

postgres logs after fresh start

PostgreSQL Database directory appears to contain a database; Skipping initialization, 2021-01-26 18:10:39.880 CET [1] LOG: starting PostgreSQL 13.1 on x86_64-pc-linux-musl, compiled by gcc (Alpine 10.2.1_pre1) 10.2.1 20201203, 64-bit, 2021-01-26 18:10:39.880 CET [1] LOG: listening on IPv4 address "0.0.0.0", port 5432, 2021-01-26 18:10:39.880 CET [1] LOG: listening on IPv6 address "::", port 5432, 2021-01-26 18:10:39.899 CET [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432", 2021-01-26 18:10:39.921 CET [21] LOG: database system was shut down at 2021-01-26 18:10:38 CET, 2021-01-26 18:10:39.935 CET [1] LOG: database system is ready to accept connections,

At this point when browsing to either the Traefik hostname or browsing to the DSMR container IP address shows me a fully functional DSMRReader with all my historical data visible and browseable. So far so good !!

As for the PI, it is is running in VLAN200 while the backend (DSMR and Postgres) are running in VLAN12 as is visible from the configuration. Usually the datalogger (sender) send its data via the Traefik proxy to the DMSR API via Traefik (https). For testing purposes I have already tried changing the sender configuration to directly send to DSMR API bypassing Traefik.

docker command when running directly to dsmr bypassing traefik

sudo docker run -d --name dsmr --restart always -e DJANGO-TIME_ZONE=Europe/Amsterdam -e DATALOGGER_MODE=sender -e DATALOGGER_API_HOSTS=http://10.0.12.134 -e DATALOGGER_API_KEYS=doesntreallymatterbuthey -e DATALOGGER_INPUT_METHOD=serial -e DATALOGGER_SERIAL_PORT=/dev/ttyUSB0 -e DATALOGGER_SERIAL_BAUDRATE=115200 --device /dev/ttyUSB0:/dev/ttyUSB0 xirixiz/dsmr-reader-docker

The following firewall rules are in place between the VLANS:

ALLOW 10.0.200.97 10.0.12.100 any protocol (normally https only) ALLOW 10.0.200.97 10.0.12.134 any protocol (normally this rule does not exist because API communication runs via Traefik).

IP-addresses: RASPBERRYPI 10.0.200.97 TRAEFIK_PROXY 10.0.12.100 DSMR (receiver) 10.0.12.134 POSTGRES 10.0.12.150

The error messages on the DSMR sender are exactly the same in both cases.

puijken commented 3 years ago

Ow yeah, should not really matter but with the cu command I see the output from the P1 port on the PI console.

puijken commented 3 years ago

What I find strange is after creating the sender container on the PI, the env variables seen below are automatically added. I think this happend in some update after which it stopped working but not quite sure.

A sender container should not need env variables such as djangodatabase* I think? As it only uses the API to send it's data to the receiver container. At least I'm never specifying them in my docker command so it makes no sense that they are created and used.

image

xirixiz commented 3 years ago

Thanks for sharing all the information. I have one more question though to understand it all a bit better. In the first post you weren't able to connect to dsmrdb at all, and now 5 days later dsmr and dsmrdb are running fine but you still receive some errors "The error messages on the DSMR sender are exactly the same in both cases.". Does this mean you get the errors from your initial post in you dsmr container, that is configured as a sender?

I verified the code at least, and indead, de db settings shouldn't be required for some types of containers, like for example the sender container. Ill update the code for this, thanks! However, I don't think this should impact your environment, but let's try out. Ill create a new "smarter" image so you can test with that image.

xirixiz commented 3 years ago

Je kan de Dcoker images met tag: docker pull xirixiz/dsmr-reader-docker:development-v4.11.0- gebruiken voor iedere Docker container om te testen

puijken commented 3 years ago

Thanks for sharing all the information. I have one more question though to understand it all a bit better. In the first post you weren't able to connect to dsmrdb at all, and now 5 days later dsmr and dsmrdb are running fine but you still receive some errors "The error messages on the DSMR sender are exactly the same in both cases.". Does this mean you get the errors from your initial post in you dsmr container, that is configured as a sender?

I verified the code at least, and indead, de db settings shouldn't be required for some types of containers, like for example the sender container. Ill update the code for this, thanks! However, I don't think this should impact your environment, but let's try out. Ill create a new "smarter" image so you can test with that image.

Correct, sorry if this was not clear from the initial post. The entire backend (dmsr receiver + database) part is working fine. The errors I'm getting are on the sender docker. That's why I was wondering why the database parameters were assigned when creating a "sender container".

I'll try the new images right now. Bedankt voor de aanpassing! Benieuwd !!

xirixiz commented 3 years ago

Most probably only using the latest development image for the sender will solve the issue you're currently facing. Leave the environment running, but just update the sender container first. If so, then verify the other containers as well using the updated Docker image. If everything is working, please let me know so I can push it to the master branch.

puijken commented 3 years ago

Goodmorning again,

Great news, after running exactly the same syntax as yesterday on the PI but with the new image, things started working again. Below you can find the logs of the now correctly running sender container. For now I only updated the container on the PI and as expected this was enough to get it up and running again.

[ INFO ] Removing existing PID files..., [ INFO ] Creating log directory..., [ INFO ] Fixing /dev/ttyUSB* security..., [ INFO ] Configuring DSMR in sender datalogger mode...., [ INFO ] Installing the DSMR remote datalogger client..., [ INFO ] Using a serial connection for the DSMR remote datalogger..., [ INFO ] Adding DATALOGGER_SERIAL_PORT and DATALOGGER_SERIAL_PORT to the DSMR remote datalogger configuration..., [ INFO ] Adding DATALOGGER_API_HOSTS, DATALOGGER_API_KEYS and DATALOGGER_INPUT_METHOD to the DSMR remote datalogger configuration...,

[ INFO ] Starting supervisord...,

[ INFO ] Logfiles can be found at: /var/log/supervisor/*.log and /tmp/supervisord.log, 2021-01-27 07:40:07,576 INFO Included extra file "/etc/supervisor.d/supervisord.ini" during parsing, 2021-01-27 07:40:07,576 INFO Set uid to user 0 succeeded, 2021-01-27 07:40:07,602 INFO RPC interface 'supervisor' initialized, 2021-01-27 07:40:07,603 CRIT Server 'unix_http_server' running without any HTTP authentication checking, 2021-01-27 07:40:07,605 INFO supervisord started with pid 13, 2021-01-27 07:40:08,615 INFO spawned: 'dsmr_remote_datalogger' with pid 15, 2021-01-27 07:40:10,552 INFO success: dsmr_remote_datalogger entered RUNNING state, process has stayed up for > than 1 seconds (startsecs),

Thanks a lot for the quick assistance!

puijken commented 3 years ago

Most probably only using the latest development image for the sender will solve the issue you're currently facing. Leave the environment running, but just update the sender container first. If so, then verify the other containers as well using the updated Docker image. If everything is working, please let me know so I can push it to the master branch.

I'll update the receiver container too to test that one. It's running on "amd64" but should really matter right?

xirixiz commented 3 years ago

The images are updated via an Azure pipeline, so the one for amd64 has been updated as well indeed.

Not much has changed, but it would be nice to verify so the rest of the world remains properly running after pushing the changes to the master branch :).

puijken commented 3 years ago

No issues on the receiver part after updating to the latest image:

[ INFO ] Removing existing PID files...,

[ INFO ] Creating log directory...,

[ INFO ] Verifying if the DSMR web credential variables have been set...,

[ INFO ] Verifying Database connectivity..., None,

[ INFO ] Running post configuration..., Operations to perform:, Apply all migrations: admin, auth, contenttypes, dsmr_api, dsmr_backend, dsmr_backup, dsmr_consumption, dsmr_datalogger, dsmr_frontend, dsmr_influxdb, dsmr_mindergas, dsmr_mqtt, dsmr_notification, dsmr_pvoutput, dsmr_stats, dsmr_weather, sessions, Running migrations:, No migrations to apply., , 561 static files copied to '/var/www/dsmrreader/static'., Updating password of superuser "snip",

[ INFO ] Checking for NGINX SSL configuration...,

[ INFO ] ENABLE_NGINX_SSL is disabled, nothing to see here. Continuing...,

[ INFO ] Checking for HTTP AUTHENTICATION configuration...,

[ INFO ] ENABLE_HTTP_AUTH is disabled, nothing to see here. Continuing...,

[ INFO ] Configuring DSMR in receiver datalogger mode....,

[ INFO ] Starting supervisord...,

[ INFO ] Logfiles can be found at: /var/log/supervisor/*.log and /tmp/supervisord.log, 2021-01-27 07:48:16,667 INFO Included extra file "/etc/supervisor.d/supervisord.ini" during parsing, 2021-01-27 07:48:16,667 INFO Set uid to user 0 succeeded, 2021-01-27 07:48:16,671 INFO RPC interface 'supervisor' initialized, 2021-01-27 07:48:16,671 CRIT Server 'unix_http_server' running without any HTTP authentication checking, 2021-01-27 07:48:16,671 INFO supervisord started with pid 15, 2021-01-27 07:48:17,675 INFO spawned: 'dsmr_backend' with pid 17, 2021-01-27 07:48:17,676 INFO spawned: 'dsmr_webinterface' with pid 18, 2021-01-27 07:48:17,677 INFO spawned: 'nginx' with pid 19, 2021-01-27 07:48:19,443 INFO success: dsmr_backend entered RUNNING state, process has stayed up for > than 1 seconds (startsecs), 2021-01-27 07:48:19,443 INFO success: nginx entered RUNNING state, process has stayed up for > than 1 seconds (startsecs), 2021-01-27 07:48:21,447 INFO success: dsmr_webinterface entered RUNNING state, process has stayed up for > than 3 seconds (startsecs),

xirixiz commented 3 years ago

Great! I`ll create a PR and merge the changes.

xirixiz commented 3 years ago

Done! All images have been updated and are now available in the Docker hub! You can switch back now to the images you were using!