Error: Command timeout

[vezinpi]

Hi,

I am just a regular user with good system understanding but I am not a software person by any means. Therefore, take the following with that in mind.

I feel myself trapped between HASS recommanded install for a Raspberry Pi, and MSR recommanded install. They are not compatible...

HASS recommanded install is using the Home Assistant Operating System, a controlled environment where the user do not have control over the OS. The good point, it is simple, very stable and protected against noice user like me. On the other hand it make it difficult to do anything else like installing MSR. Trough the Portainer Add-On, I manage to install the MSR container and to configure it to see my Vera and HASS devices. The problem is that the configuration is within the container and when we upgrade or remove the container, the configuration is lost.

The fact that the standard MSR container is running just fine (beside the config) means that the configuration is compatible with HASS OS. I understand your approach (not being system dependent like Reactor was with Vera) by providing either a generic container or tar ball but it implies having a device on which we have the control over the OS. Your actual container for Pi is so close from being an official add-on I wonder if it would not worth the effort. I even see a benefit for you when trouble shooting. The Hass OS environment being almost lock, it can become somewhat of a referece when chasing down an issue with MSR. How many problem are due to the user changing something it is not supposed to. The other thing is, how many users out there, like me, are using the Pi image or the Home Assistant BLUE platform.

I have been using (and contributed) Reactor and Virtual switches with my Vera and I definitely want to go that route with MSR and HASS. I will re-install HASS with an alternate method if I have to, but it is not my first choice if I can avoid it. Again, being just a regular user, simplicity is paramount and the HASS image was pretty good. If MSR could be an add-on, it would be fantastic.

For your consideration.

Thanks

[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.