Organizing/ structuring rule sets and rules

[d868]

I'm just starting to look at ways to migrate away from Vera and just started working on a Home Assistant setup so I'd also love to have a go at testing this out in Docker on a QNAP but I don't really want to have to SSH into the NAS to do the docker compose, etc. I have only ever used the docker hub to add docker images but it looks like it's possible to use the QNAP container station to create a docker image locally but the steps you posted a few days ago in the thread don't seem to be in the format that the GUI needs, or I'm doing something wrong. If there aren't any QNAP gurus around I'll wait for something to come up.

[PerH]

The code above is for dockerfile. That is for making images, while docker-compose sets up containers based on images you make, or is found on docker hub.
No idea how QNAP works, you say it has input for dockerfile code? if so, the code above should work (the dockerfile code, not the compose!), its very standardized.. But unless you make the image yourself i guess you'll have to wait with MSR in docker until there is an official MSR image.

[parkerc]

Hi @d868, other than creating our own image, we’ll have to wait until one’s approved and then published on Docker Hub.
If it helps you I’m planning to do the same thing with MSR as I did with Home Assistant, and create a Container Station API build guide.

Jan 23, 2021

QNAP - Installation via Container Station’s API

Rather than use the UI to build your Home Assistant Docker container, you can do it all via the command line using its API. https://qnap-dev.github.io/container-station-api/ Here’s how I did it… On any device, access it via the command line, In this situation, I’m doing it on the QNAP itself...

[d868]

@parkerc thanks. I'm trying to avoid doing anything by command line if I can, but if you do end up creating a guide I'll see how I go with it. In the meantime I'll have a bit of a play around with Container station to see if I can get the syntax right for creating it myself via the GUI.

[PerH]

Just updated the first post.
I just noticed that Reactor time wasn't correct, and its probably because of daylight savings time here in Norway.
I put a Bind mount for /etc/localtime in the docker-compose, and noW it will follow the host machines time.

[Buxton]

Hi Patrick,

Do you have a compose file that you're happy with. I'd like to try this on my HA machine which has several other containers, and runs on an Intel Atom with 4gb ram.

[Buxton]

To those dreading ssh into their machine, try using WinSCP and setting the file editor to Notepad ++. Makes editing linux files a breeze and you can set up your folder structures and permissions with the winscp gui.

[toggledbits]

@buxton said in MSR in Alpine Docker:

Do you have a compose file that you're happy with.

Here's what I last used:

version: '3'

services:
  web:
    container_name: reactor
    environment:
      REACTOR_DATA_PREFIX: /var/reactor

    image: toggledbits/reactor:latest
    restart: always
    network_mode: "bridge"
    expose:
      - 8111
    ports:
      - 8111:8111
    volumes:
      - .data:/var/reactor
    tmpfs: /tmp

To those dreading ssh into their machine, try using WinSCP and setting the file editor to Notepad ++. Makes editing linux files a breeze and you can set up your folder structures and permissions with the winscp gui.

If you're on an RPi (or really anything, but RPi was a breeze), setting up Samba and being able to open the files directly on the host via the share is a great time saver, too. Choices.

[toggledbits]

@perh said in MSR in Alpine Docker:

and not it will follow the host machines time.

@PerH I'm re-reading this... the bind mount fixes it, right? You meant "now"?

[PerH]

Yes.
My MSR Container clock was one hour off, and the bind fixed it.

[Buxton]

Ok got the following error:

Pulling MSR (toggledbits/reactor:latest)...

ERROR: pull access denied for toggledbits/reactor, repository does not exist or may require 'docker login': denied: requested access to the resource is denied

[toggledbits]

It's not a published image. The only image I make available is for Synology NAS x86. You'll need to build your own image using the generic package download (which you can get from the download button in the MantisBT bug tracker).

Have you built docker images before?

[Buxton]

Yes, I've built some simple ones. I'll need a Mantis login though. Let me know what kind of info you need to set up my credentials.

[toggledbits]

OK. Just PM me your full name and email address.

[PerH]

I'm happy to see an official docker image for MSR!

Just thought i'd share my docker-compose.yaml, which is only different in that i use docker volume instead of bind to host folder

Not sure if it's better, but i've done this to all dockers in my system.

This came up working well immediately, next is to stop the container and add my storage and config data.

version: "3.9"

services: 
  MSR:
    container_name: MSReactor 
    restart: always 
    image: toggledbits/reactor:latest-generic-amd64 
    ports:
      - "8111:8111" 
    networks:                            # Optional for use of static IP inside the docker network. 
      HAnett:                            # You could replace this and the subsequent lines with " network_mode: "bridge" "
        ipv4_address: 192.168.0.8 
    volumes:
      - type: volume 
        source: MSR 
        target: /var/reactor
      - "/etc/localtime:/etc/localtime:ro" 
    environment:
      - TZ=Europe/Oslo
      - REACTOR_DATA_PREFIX=/var/reactor
    tmpfs: /tmp
    logging:
        driver: "json-file"
        options: 
          max-file: "5" 
          max-size: 2m
networks:    #Optional
    HAnett: 
        name: HAnett
        driver: bridge
        ipam: 
            config:
                - subnet: 192.168.0.0/16 
                  gateway: 192.168.0.254 
volumes: 
  MSR: 
    name: MSR

[LibraSun]

Nice work there! I'm going to save a copy even though I routinely use the Docker GUI (perhaps not available to all Synology NAS users) to set up MSR.

I, too, have been mulling the difference between bind and volume and Googling a while back did not seem to settle it for me. Surely it must make some difference?!

Also, I gotta ask: Do you have any Sunrise/Sunset-based Rules? Only asking b/c for me, in 21117, my only Sunset/offset routine somehow failed to launch itself last night, but I'm uncertain whether that constitutes a 'bug' or just a misfire of some other kind.

[PerH]

I think the main advantage of volumes is that location is controlled by docker, and these locations aren't as easy to screw up if you mess around with the folder structure.. It also puts all volumes in a common folder (var/lib/docker/volumes) that can be copied to a tar or backup folder using one line, but thats just as easy if you organize bind folders the same way.. Let me know if you find other advatages.

I have no sunrise/sunset rules, i use light sensors for i.e. outside lighting.. I think about 90% of my "MSR bugs" have been PEBCAC, so check your logic.