DIY Dry box — Part 6

Now the MQTT server is set up and running, next step is to visualize the data (yes, the data that is not collected yet… more on that in the next post).

A good idea might be to integrate humidity and temperature in a home automation system. Of course, an open source one, running locally.

There are plenty of them like FHEM, Home Assistant, openHAB, Jeedom… but I went for Gladys Assistant. I didn’t do much research to find which one is the best one, I chose Gladys because it’s a French project with a small and dynamic community. If I go further in the home automation later on, I might select another environment if Gladys is not adapted to what I want to do.

Install Gladys Assistant

Anyway, Gladys comes as a docker image. So it can be easily added to the docker file already created:

  gladys:
    image: gladysassistant/gladys:v4
    depends_on:
      - mqtt
      - proxy
    privileged: true
    environment:
      - NODE_ENV=production
      - SERVER_PORT=8080
      - TZ=Europe/Paris
      - SQLITE_FILE_PATH=/var/lib/gladysassistant/gladys-production.db
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /dev:/dev
      - /run/udev:/run/udev:ro
      - /path/to/gladysassistant:/var/lib/gladysassistant
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.gladys.rule=Host(`gladys.example.com`)"
      - "traefik.http.routers.gladys.tls=true"
      - "traefik.http.routers.gladys.tls.certresolver=le"
      - "traefik.http.routers.gladys.entrypoints=websecure"
      - "traefik.http.services.gladys.loadbalancer.server.port=8080"

So the routing, TLS and certificate generation is handled by Traefik Proxy again.

But I’m not too happy with this. One advantage of Docker is that you can kind of sandbox software running on the server but Gladys Assistant requires “privileged” mode and write access to sensitive parts of the system and runs as root anyway. So basically Gladys is root on the system. I can understand that it’s required to integrate with some hardware, but it would be nice if the documentation included information on what can be tuned down depending on the needs.

For instance, this docker-compose file is not enough, I got issues with the MQTT server because I didn’t pass the --cgroupns=host option to docker… since it’s not yet supported in docker compose. See issue 8167 on docker compose and issue 148 on compose spec. A workaround is suggested here, but it applies to the whole docker daemon and not only the container. So anyway, the file /etc/docker/daemon.json needs to be created with the following content:

{
    "default-cgroupns-mode": "host"
}

Note: this should not be necessary with newer versions of docker-compose as the issues seem to have been closed since.

Connect Gladys to the MQTT server

Gladys Assistant can start its own Docker instance of Mosquitto since it has full access to Docker. But given that I already installed Mosquitto, it just needs to be configured. This is quite straightforward:

  • go to Integration
  • click on MQTT
  • then Setup
  • fill the URL: mqtts://mqtt.example.com
  • then the credentials
  • and save the configuration

That’s all.

Add MQTT devices

Since I’m about to develop a software that will send messages to MQTT, and MQTT is quite free form on the topic structure, it might be interesting to see what Gladys is expecting.

Unfortunately Gladys doesn’t seem to have support for homie. Homie is a structured convention on how to name and fill MQTT topics for an IoT device, so it can be auto-discovered by other systems. For instance, Valetudo can publish its events on MQTT following the homie convention, so it could be easier for Gladys to integrate my Dreame Z10 Pro vacuum… but no.

So instead let’s see what convention is used by Gladys. It’s in fact well described in the MQTT integration documentation.

I find strange that the “external ID” must start with mqtt: and even stranger that the “external ID” of a feature must be unique across the whole system. I guess there are some reasons for that, but not sure that they are justified.

After playing a bit, I think the best way will be in fact for the controller to show up as 4 devices: one for each dry box connected to it. The reason for that is that the graph view was showing the same label for the different humidity sensors in the graph view.

OK, here is one dry box configuration:

Make four of them:

Add a dashboard:

Here is the result I’m aiming for:

To get that result I manually sent values to the appropriate MQTT topics. So now I know that the topics I have to publish to are:

  • gladys/master/device/mqtt:dryboxX/feature/mqtt:dryboxXhumidity/state
  • gladys/master/device/mqtt:dryboxX/feature/mqtt:dryboxXtemperature/state

(with X needing to be replaced by 1 to 4, the number of each dry box).

Comments Add one by sending me an email.