Omnia is architecture arm7l (seven “little L”; not one).
Home Assistant in MOX?
1 Like
And MOX is aarch64, indeed.
Thanks. Then…I don’t know why I can’t install the HA 
Here are the error messages
Collecting homeassistant
Downloading homeassistant-0.96.5-py3-none-any.whl (5.0 MB)
|████████████████████████████████| 5.0 MB 4.8 MB/s
Requirement already satisfied, skipping upgrade: pip>=8.0.3 in /srv/homeassistant/lib/python3.5/site-packages (from homeassistant) (20.0.2)
Collecting bcrypt==3.1.7
Downloading bcrypt-3.1.7.tar.gz (42 kB)
|████████████████████████████████| 42 kB 417 kB/s
Installing build dependencies … error
ERROR: Command errored out with exit status 1:
command: /srv/homeassistant/bin/python3 /srv/homeassistant/lib/python3.5/site-packages/pip install --ignore-installed --no-user --prefix /tmp/pip-build-env-yn0oq0ih/overlay --no-warn-script-location --no-binary :none: --only-binary :none: -i https://pypi.org/simple – ‘setuptools>=40.8.0’ wheel ‘cffi>=1.1; python_implementation != ‘"’"‘PyPy’"’"’’
cwd: None
Complete output (105 lines):
Collecting setuptools>=40.8.0
Using cached setuptools-45.1.0-py3-none-any.whl (583 kB)
Collecting wheel
Using cached wheel-0.34.2-py2.py3-none-any.whl (26 kB)
Collecting cffi>=1.1
Downloading cffi-1.13.2.tar.gz (460 kB)
Collecting pycparser
Downloading pycparser-2.19.tar.gz (158 kB)
Building wheels for collected packages: cffi, pycparser
Building wheel for cffi (setup.py): started
Building wheel for cffi (setup.py): finished with status ‘error’
ERROR: Command errored out with exit status 1:
command: /srv/homeassistant/bin/python3 -u -c ‘import sys, setuptools, tokenize; sys.argv[0] = ‘"’"’/tmp/pip-install-6vchzwco/cffi/setup.py’"’"’; file=’"’"’/tmp/pip-install-6vchzwco/cffi/setup.py’"’"’;f=getattr(tokenize, ‘"’"‘open’"’"’, open)(file);code=f.read().replace(’"’"’\r\n’"’"’, ‘"’"’\n’"’"’);f.close();exec(compile(code, file, ‘"’"‘exec’"’"’))’ bdist_wheel -d /tmp/pip-wheel-kpobrnwb
cwd: /tmp/pip-install-6vchzwco/cffi/
Complete output (36 lines):
running bdist_wheel
running build
running build_py
creating build
creating build/lib.linux-aarch64-3.5
creating build/lib.linux-aarch64-3.5/cffi
copying cffi/vengine_cpy.py -> build/lib.linux-aarch64-3.5/cffi
copying cffi/model.py -> build/lib.linux-aarch64-3.5/cffi
copying cffi/commontypes.py -> build/lib.linux-aarch64-3.5/cffi
copying cffi/error.py -> build/lib.linux-aarch64-3.5/cffi
copying cffi/backend_ctypes.py -> build/lib.linux-aarch64-3.5/cffi
copying cffi/cparser.py -> build/lib.linux-aarch64-3.5/cffi
copying cffi/ffiplatform.py -> build/lib.linux-aarch64-3.5/cffi
copying cffi/pkgconfig.py -> build/lib.linux-aarch64-3.5/cffi
copying cffi/vengine_gen.py -> build/lib.linux-aarch64-3.5/cffi
copying cffi/api.py -> build/lib.linux-aarch64-3.5/cffi
copying cffi/lock.py -> build/lib.linux-aarch64-3.5/cffi
copying cffi/init.py -> build/lib.linux-aarch64-3.5/cffi
copying cffi/setuptools_ext.py -> build/lib.linux-aarch64-3.5/cffi
copying cffi/cffi_opcode.py -> build/lib.linux-aarch64-3.5/cffi
copying cffi/verifier.py -> build/lib.linux-aarch64-3.5/cffi
copying cffi/recompiler.py -> build/lib.linux-aarch64-3.5/cffi
copying cffi/_cffi_include.h -> build/lib.linux-aarch64-3.5/cffi
copying cffi/parse_c_type.h -> build/lib.linux-aarch64-3.5/cffi
copying cffi/_embedding.h -> build/lib.linux-aarch64-3.5/cffi
copying cffi/_cffi_errors.h -> build/lib.linux-aarch64-3.5/cffi
running build_ext
building ‘_cffi_backend’ extension
creating build/temp.linux-aarch64-3.5
creating build/temp.linux-aarch64-3.5/c
aarch64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -g -fdebug-prefix-map=/build/python3.5-qsALw2/python3.5-3.5.3=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -DUSE__THREAD -DHAVE_SYNC_SYNCHRONIZE -I/usr/include/ffi -I/usr/include/libffi -I/usr/include/python3.5m -I/srv/homeassistant/include/python3.5m -c c/_cffi_backend.c -o build/temp.linux-aarch64-3.5/c/_cffi_backend.o
c/_cffi_backend.c:15:17: fatal error: ffi.h: No such file or directory
#include <ffi.h>
^
compilation terminated.
error: command ‘aarch64-linux-gnu-gcc’ failed with exit status 1
----------------------------------------
I had installed Home assistant on my MOX, but then MOX was unstable (it is still unstable evene if I uninstalled Home A.)
Turris team suggested me to uninstall it becasuse my MOX have only 1GB of RAM and that is not enough for running Home A.
Installation problem solved including the following command to ensure that the required dependencies on cryptography are installed
apt-get install build-essential libssl-dev libffi-dev python-dev
Thank you … but my RPi has only 1GB and HA works fine 
Silly question:
HA is running now … but where? IP:8123? Which is the IP address of a LXC?
yeap, on RPi works fine for me too
check DHCP in Luci what IP address your LXC got …
Sorry but I can’t find in Luci the LXC IP. probably because the MOX has not activated the DHCP service 
But without any problem using:
#lxc-info homeassistant
Name: homeassistant
State: RUNNING
PID: 28937
IP: 192.168.1.34
CPU use: 2436.27 seconds
Memory use: 284.26 MiB
KMem use: 36.40 MiB
Link: vethLMO2RF
TX bytes: 3.24 MiB
RX bytes: 195.86 MiB
Total bytes: 199.10 MiB
Unfortunately … not connect using:
192.168.1.34:8123
Why?
Now, it’s working FINE in my MOX!
I fogort these sentences
Let’s configure systemd to automatically start the application. Create the file /etc/systemd/system/home-assistant@homeassistant.service:
root@homeassistant:~# cat <> /etc/systemd/system/home-assistant@homeassistant.service [Unit] Description=Home Assistant After=network.target [Service] Type=simple User=homeassistant ExecStart=/srv/homeassistant/bin/hass -c “/home/homeassistant/.homeassistant” [Install] WantedBy=multi-user.target EOF
Enable and launch Home Assistant:
*root@homeassistant:~# systemctl --system daemon-reload root@homeassistant:~# systemctl enable home-assistant@homeassistant Created symlink from /etc/systemd/system/multi-user.target.wants/home-assistant@homeassistant.service to /etc/systemd/system/home-assistant@homeassistant.service. root@homeassistant:~# systemctl start home-assistant@homeassistant
We just have to make sure the container starts automatically when we reboot the router. Set the following in /etc/config/lxc-auto:
root@turris:~# cat /etc/config/lxc-auto
config container
option name homeassistant
option timeout 60*
Now, I’ll to include the HA configuration of my RPi 
FIrst “problem”: Python 3.5 won’t be compatible with the new versions of HA since next August
To upgrade to Python 3.7
Step 1. Before we install any software, it’s important to make sure your system is up to date by running these following apt-get commands in the terminal:
apt-get update
apt-get upgrade
Step 2. Installing Python 3.7 on Debian 9.
Download Python using following command from python official site:
cd /usr/src
wget https://www.python.org/ftp/python/3.7.3/Python-3.7.3.tar.xz
tar xf Python-3.7.3.tar.xz
Next, compile python source code on your system:
cd ./Python-3.7.3
./configure --enable-optimizations
make
make install
Once the process is complete, check version of Python 3:
python3 -V
After compile the new version of python from source, we can now configure Debian to make it our default version of python3.
update-alternatives --install /usr/bin/python python /usr/local/bin/python3.7 10
Debian BUSTER has the latest Python 3.7.3
just one point…I used HA on Omnia earlier with lxc container, debian and python virtualenv…it was fine for testing, but many things must be done manually and if you want influxdb, grafana, have many devices/entities and automations, camera, etc… it’s better to spend few bucks for raspberry 4b and get benefits from hass.io image - for example supervisor for installing plugins, upgrading HA or OS from lovelace and more
1 Like
What’s the problem using Turris? Unstability of the router? Dificulty to manage installation packages?
It’s not problem at all. But hass.io image for rpi or nuc gives you supervisor for easy installing plugins and updating OS / HA. Supervisor is not included in virtualenv version. And other thing is performance. Router is fine for testing with few devices / sensors, but after you automatize more things or want some advanced plugins, you may be limited by hardware performance
For me, the main problem is not to have DOCKER in the Turris
Don’t you agree?
1 Like
I have started to automate Home Assistant deployment in a LXC container based on Alpine with Ansible. I will let you know when it is in good shape.
Turris team recommended to me that I shouldnt run Home Assistant on MOX (because of lack of memory even if I have 1GB RAM) as same as not run suricata … so technically they recommended to me to use MOX only as a dummy wifi router.
It was me, who responded to your issues, so I’d like to correct some things, which now seems a little bit confusing. In the first place, I don’t think it is a good idea at all to run Home Assistant, Suricata, and LXC among basic features that router does on the same device (in this case Turris MOX) in the same time, which has just 1 GB RAM (in your case) as it will go wrong.
We have never ever advertised support of Home Assistant for Turris MOX. Based on the diagnostics sent to technical support as the MOX, I have suggested to uninstall it, because with fulfilled RAM and because of Out of Memory Killer it went to the non-responding state and watchdog rebooted the device.
More details in the Czech thread:
While I was playing around with Home Assistant on Turris routers, I read the documentation for Installation of Home Assistant and clearly, their devs recommend to have minimum 1 GB RAM. This depends on sensors, plugins being used. Before I know that for short a period of time, I had been using it on 512 MB, but no other services were running. MOX in my case was configured only as a server. I don’t recommend it to anyone run Hass on 512 MB nor 1 GB, but only sharing my experience as on 512 MB it was good till there was a new update and there wasn’t enough RAM to proceed it successfully and OOM killer was triggered and killed Hass.
Running Suricata and LXC on the MOX with 1 GB can be in some cases a problematic one, but this depends on the network’s traffic. When the Turris routers startup, there is a RAM being used for Foris, /var (tmpfs) and other services as well and not sure, but you should have something about 512 MB RAM free/available for you when you have 1 GB RAM. As you were experiencing the same issue with the non-responding state and rebooting the router, I suggested as I want to know if the culprit is the same - not enough RAM - before sending the router to us as you wanted from us to take a look at it.
I would say that you can compare it with a smartphone. You can buy it with just 1 GB RAM, but we know how mobile operating systems can be hungry and apps are sluggish or you can not run them at all as they are crashing almost each time. For what would you use that phone? For their basic function - calling, writing SMS, maybe using some apps for messaging to each other.