Virtualenv Portability

[ngardiner]

Virtualenv Portability

[bikeymouse]

I would also love it if there where Docker images for TWC, that would be even more portable!

[bikeymouse]

Update:

I now have made the RS-485 connection to the TWC. Everything works fine (except for the OCPPControl error)!

Another thing is that I noticed that the timestamps in the log where 2 hours behind. Also scheduled times where not adhered to. So I have added this bind mount in the docker-compose.yaml so it can read the time from the host.

    volumes:
      - /etc/localtime:/etc/localtime:ro

Concluding: just some minor things, but overall you made a great step by providing this application as a Docker image to make this more portable and maintainable/upgradable for everybody.

Perhaps this is also an approach to decouple the additional modules from the core and and put these in containers as well (and communicate via e.g. MQTT). That is e.g. how Home Assistant is doing this.

Anyway, thanks so much for the work!

[ngardiner]

Great feedback, thanks @bikeymouse

The OCPP error is a known issue - it's related to a module that hasn't been included in the development tree yet - the problem is that rather than publishing the latest version of TWCManager to Docker Hub, we're currently publishing the latest GitHub build. I'll need to do some proper release management to provide versioned docker images, for the moment you're getting the latest and greatest (and most experimental) code.

I'll get localtime added to the docker-compose.yml file as I think this is the best approach. Also, you're 100% right about git clone being overkill here, I'll replace it with an appropriate wget/curl of the file from github instead.

Really appreciate your feedback, it helps a lot to improve the Docker installation experience.

[ngardiner]

I like the idea @nean-and-i, thanks for raising this. For some the benefit of having an effectively isolated python environment for this project would be an advantage.

Given the steps above are nicely documented, would it make sense to add this as a Makefile target, eg make virtualenv? That way people could choose on a per-installation basis whether to install it systemwide or via virtualenv?

[bikeymouse]

Any change a docker-image will become a available any time soon?

[ngardiner]

Any change a docker-image will become a available any time soon?

Yes, this is something that we could get up and running quickly. Would you be running this inside Docker on an RPi? I'd need to find the right base image to work from (I know Raspberry Pi OS has a stretch image but not a buster image for arm, but stretch has Python 3.5 bundled so I might need something more modern), perhaps there's an appropriate alpine arm image to start from. I'd also have to work out exactly what we'd need to do to mount the serial interface within the container. Give me a few days to work on the early stages of a docker image and I'll report back.

[bikeymouse]

Hi, that sounds great!

I would start to use this on Docker on my RPI 3B with Buster.
If that all works fine, eventually I think I would migrate it to my "production" Intel NuC system that has ProxMox where I also try to run everything as much as possible on VM's with Docker-containers.

Docker makes installing/updating and maintaining everything so much easier.

I use Docker-compose so all the configuration/start-up options, like mapping USB-ports into the container, are also consistently configured in the docker-compose.yaml files. If you would provide these as well, that probably would save a lot of installation-related questions on the forum ;-)

You may want to look at ESPHome, that is also a python 3.6 application and runs well in docker on a RPI and other platforms. They build their own base-images, based on a Debian Buster image, see their docker file here

[ngardiner]

Hi @bikeymouse,

I've added and performed limited testing on a Docker container for TWCManager. Unfortunately my install doesn't fully support doing this so I can't do full end to end testing.

I've added some documentation around how it works to:

https://github.com/ngardiner/TWCManager/blob/main/docs/README.md

Would be happy to get your feedback once you have a chance to try it out, thanks!

[bikeymouse]

Hi, I've done some quick testing:

First of all, thanks for your great effort! I was waiting with installation for the Docker support, so really great to have that now.

So now I plugged in my RS-484 USB-stick and gave it a go. It is not wired to the TWC yet (hopefully be doing that this weekend), but I already could test if it starts and if the web-interface get's up. And it does!, yeah!

So really easy this way, good work!

Only some minor feedback:

• At start-up I do get this error message:

ImportError: No module named 'lib.TWCManager.Control.OCPPControl', when importing Control.OCPPControl, not using Control.OCPPControl

Which is strange because in the config.json it is configured as disabled:

      "OCPP": {
          "enabled": false,
          "serverPort": 9000
      }

About the installation manual:

• The Docker-installation suggests to do a complete git clone but all you really need is the docker-compose.yaml
• As the config.json is by default created in /etc/twcmanager on the host, you can edit this without the need to start the container in interactive mode, as the installation suggest.
• I myself like not use /etc/twcmanager on the host to store data from Docker-containers, but rather do this in a ./data subdirectory or use a volume instead of a bind mount.
  To be really platform independent, perhaps best is to use a volume (in which case the previous remark should be ignored).

[ngardiner]

Closing this off as I've (finally) updated the Docker documentation to just pull down the docker-compose.yml file, and localtime has been added some time back