[Reactor] Bug when sending MQTT boolean payloads

[toggledbits]

You are blazing new territory by running under the packaged, container HassOS. But it sounds like you're close.

Generically, docker containers allow you to "mount" a point in the OS' filesystem within the container; this is called a bind mount. This is the mechanism by which the configuration and log files are normally preserved outside the container on all other systems in which MSR docker containers run. In this way, replacement of the container and/or underlying image does not cause data loss (configuration, state, logs, etc.), because the data is no longer stored within the container.

What you need to figure out is how to get the /var/reactor directory inside the container mounted to an accessible, persistent location outside the container. For example, you may create a directory in your user home directory /home/username/reactor-data, and create a bind mount that mounts that directory over /var/reactor inside the container. Portainer generically allows you to create bind mounts to places in the filesystem, so I assume this is readily possible, but not being familiar with the specifics of how HassOS handles (and more importantly, restricts) its filesystem(s), I can't give you specific guidance.

[vezinpi]

Hi again,

Just thought I would provide an update on where I am at. I might also be helpfull to other people.

As you know, I am trying to get the MSR Container work on a Pi-4, configured with the standard HASS operating system (image via balena etcher). Well I finally found a solution to data persistance between reboot. Here is what I did:

• Installed samba add-on to get accesss to the standard Hass configuration folders

• Installed Portainer which will be used to install MSR

• From within Portainer, add an MSR container with the following configuration: image: toggledbits/reactor:latest-raspbian-armv7l, add a TZ variable with the proper region, restart policy define On failure, add a bind volume to map the reactor container /var/reactor to the host /mnt/data/supervisor/homeassistant/reactor. This (reactor) folder will be accessible via the samba addon under the config folder.

• Restarted the MSR container

The reactor.yaml configuration file is now accessible via samba under homeassistant/config/reactor/config or from a terminal sessison performed from portainer in the var/reactor/config folder.

All seems to work for now. Devices from vera and HASS are being seen by MSR. Configuration persist trough a reboot and I was also able to import (convert using the tool provided) my configuration from Reactor. I am now in the process of making the final adjustment.

Not sure what will the future hold but for now it is working fine.

Many thanks for your work and support.

[sender]

In hassos you can install an addon "portainer" and with the needed "settings" you can run your own dockers very easily besides the other containers (of which homeassistant is one).

[vezinpi]

Hi,

That's what I did.See post above. The challenge was to acheive data persistence between reboot, upgrade, etc... Hass OS is pretty tight when it comes to he host file system.

Thanks

[sender]

@vezinpi Have you ran the container and the portainer addon in privileged mode? I have had not trouble in data persistance...

[Fanan]

@vezinpi

1. How do I add a TZ-variable? And how do I know how my region (Sweden/Europe) is added?
2. My reactions seems to work, but I can't reach the Web UI. The adress in reactor.yaml doesn't work. I also tried the http://127.0.0.1:8111. Can someone point me in the right direction - what adress can it be to reach the Web UI?

Thanks!

[MikeReadington]

I don't want to give you bad info, but I believe when you edit a container in Portainer, it actually deletes and publishes the edited one in place.

Check here.

Edit or duplicate a container | Portainer Documentation

Here are some screen shot from Portainer on my Synology. These are the locations you need to edit for port and TZ.

[Fanan]

@mikereadington
Thanks!

Now it's working!!

[Fanan]

@mikereadington

• SOLVED*
  Solved by using Watchtower. Followed this guide:
  
  How to Update Docker Containers using Watchtower with Portainer

*OLD POST:
I've been able to update/pull the latest release of MSR a few times within Portainer (running in HA on a HA blue - odroid), but that's not possible anymore.
I only get this message:
I have stopped the MSR as I did before, but nothing seems to help anymore. I have reactor version 21228-05d7497 running, and can't upgrade.
My Portainer version is 2.6.2. Home Assistant is 2021.8.8.
Anyone else having this problem or knows why I can't pull and deploy the latest release?
/Fanan

[toggledbits]

Your initial problem may have been due to a build error on my part; the build was redone during the course of yesterday and repushed, so that may have had more to do with your success than using WatchTower. You might want to try it the "old" way and see what happens.

[vezinpi]

@Fanan If you are using the HASS.OS then this is a portainer issue in HAAS. See the following link:

Aug 23, 2021

Portainer v2.6.2 - unable to start containers

Not sure what the problem could be, but even since the portainer update to v2.6.2 ( integration v2.0.0 ) I’m unable to (re)start any of my previous working containers… The failure I get is : Starting container with non-empty request body was deprecated since API v1.22 and removed in v1.24 Anyone...

Until the problem is resolved in HAAS you will have to install the previous version of the Add-on.

[Fanan]

@vezinpi Thanks!
I installed alexbelgium repository and his version of Portainer. It was able to update MSR to the latest version (it took a few times with error messages, but then it worked). His version is also 2.6.3. - not 2.6.2. which is the latest available regarding the Portainer add-on i HA.

[vezinpi]

Thanks. I will keep that up my sleeve in case HASS fail to address the issue in a timely manner. But for now, the Portainer plugin version 1.5.2 is doing the trick.