Add ability to reload sensor config while running

[raetha]

To allow for easier renaming of sensors without having to restart the service or docker container, add a topic and subscription that will reload the sensor config while the service is running.

[onedr0p]

Hello again :) it would be nice if the docker image didn't require logging, sensor and config yamls present when starting up the first time.

also, logging.yaml can just be built into the main script and you can toggle loglevel with an environment variable, do people really need logging to be that configurable?

[raetha]

Hi @onedr0p.

I'll take a look at if we can do anything with docker. But without a web UI to configure things, there is nothing to start in docker without the config.yaml file in place. the sensors one will just build itself, but the config file tells it how to connect to MQTT, and without that nothing would really happen. So what would you want to docker container to do if that file isn't present? Just loop looking for it until one is put in place?

On the logging front, I was mostly just experimenting with Python logging. I learned Python for this project, and so wanted to dig in more than one might when trying to do something quick. Since I got the dynamic logging using dicts working, I figured there was no reason to remove it, but also defaulted that so that no one needed to modify it if they didn't want to.

[onedr0p]

I was actually thinking a web UI would be great, even if it was a white page with a few inputs and textboxes to configure devices. Maybe a project in the future if I can ever get to it... haha.

I didn't know their was a default for logging, I thought I had to include it in my volume mount.

What about a single config file for everything? Something like config.yaml:

mqtt:
  host: <host>
  port: 1883
sensors:
  - name: Front Door
    mac: 'XXXXXX'
    location: Foyer
  - name: Patio Door
    mac: 'XXXXXX'
    location: Patio

That would make configuration much easier, I'll open up a separate issue if you think that's good :)

As for logging I can open an issue for adding an environment variable to change the log level.

Edit: It maybe worth checking out a Python CLI library, I've used Click, it's pretty nice. Here's a project I used it with.

https://github.com/onedr0p/sonarr-episode-prune/blob/master/sonarr-episode-prune.py

It allows you to have argument, environment and file based configs together without writing much code. Very helpful for writing CLI apps.

Good work so far, your python looks great!

[raetha]

@onedr0p Definitely some good ideas in here. I've already got an issue logged for a web GUI, though I don't have the skills for that, but am asking some developer friends for any framework recommendations or anything else they could help with there.

On the config files, for the moment I'd like to keep them separate. The sensors config is especially what I'd like to see editable in a web UI, but it is also dynamically built with defaults by the script. If I merge it, everything has to be ready and able to write out the complete configuration or risk breaking stuff. Right now if the sensors file blows up, things should get rebuilt (without customizations), but things will still work. If the MQTT settings get broken though, then everything grinds to a halt.

I did just add issue #28 (and the code) to automatically copy a default config.yaml and logging.yaml if they don't exist. So Docker runs will now put them in the config folder waiting to be modified as needed.

As for Docker ENVs, I'll happily take new issues for that. I want to get 1.1 released before digging into the Docker stuff more, but could look at it for 1.2. I'm thinking ENVs for the MQTT host, port, username, and password would be good, as then you could get away without ever having to touch config files for Docker. And an eventual UI to edit things after the fact would take care of the rest. And I think that's ultimately what you're looking for. I'd love you to log this one though, as having more folks involved in this has helped keep my interest going and know I'm not just tweaking things for myself. :)

I'll also definitely take a look at click. If nothing else I think that would be great for the cli tool to interact with the bridge, but to your points above might also help with some of the configuration.

Thanks again for all the feedback.