Im not sure if this is the correct place to post, if not, apologies.
I am unsure as to whether I should switch to hass.io?
I am currently running home assistant on a Rpi3.
On this same Pi I am also running Kodi.
I have a few (probably dumbass, basic) questions…
If I switch to hass.io, can I still install kodi on the same Pi?
My Home Assistant setup is pretty basic, compared to some I have seen, and my home automation consists of lights, a few RF switches, some ESP2866 modules running temp sensors. Pretty simple stuff.
But I do plan on expanding and building my home automation system in the future.
Will I really see any benefit switching to hass.io?
Will my existing configuration ‘port’ across easy enough?
Will it run on a Pi2…I almost see it as a bit of a ‘waste’ of the resources running has on a Pi3??
Sorry if these are ignorant questions, but ive hunted and cant really find anything to help?
It depends on how much effort you can spend. Hass.io has a very powerful mechanism of addons for extra features. Potential example of such addon could be KODI - but I don’t know whether such solution already exists or you should write such addon yourself (it’s not as hard as it sounds, and it’s nicely documented). But if you do, you can share it so whole community will benefit (-:
I’ve bought rpi especially for home assistant, but I wanted to install there also some other stuff, for start DHCP and DNS. And it was a nice surprise that in hass.io there are already components for them. So instead of manually configuring them in raspian, I could much easier have it up and running via hass.io.
TL;DR: go for hass.io, it may need more effort now but it will pay off later.
Well, the main point of hass.io is virtualization via addons - each addon receives its own OS and is free to do there whatever it likes, without much risk of messing up other addons. So of course you can use pip, but inside addon.
thanks i didnt know that.
can you also tell me how people should go from one addon to another to use pip?
because i only have seen people mentioning that pip is giving an error.
couldnt it be that most addons have pip not installed/activated?
isnt the OS for an addon only what is needed?
Addons are defined by Dockerfile, which is a “recipe” for prepering virtual machine. Here is an example fragment of Dockerfile of my addon, which is hosting django-powered website (this particular one is in python2, in python3 it’s slightly different, as pip is already included in python3):
RUN apk add --no-cache python
RUN apk add --no-cache py-django
RUN apk add --no-cache py2-pip
RUN apk add --no-cache python2-dev
RUN apk add --no-cache zlib-dev
RUN apk add --no-cache libjpeg-turbo-dev
RUN apk add --no-cache alpine-sdk
RUN pip install pytz
RUN pip install Pillow
RUN apk add --no-cache python
RUN apk add --no-cache py-django
RUN apk add --no-cache py2-pip
RUN apk add --no-cache python2-dev
RUN apk add --no-cache zlib-dev
RUN apk add --no-cache libjpeg-turbo-dev
RUN apk add --no-cache alpine-sdk
RUN pip install pytz
RUN pip install Pillow
Of course it’s just an example, not all those apks are just for pip (-:
The rule of thumb in hass.o is one responsibility - one addon - one virtual machine. It is a little different approach then good old “let’s install everything we can on one machine and make it work there”. When you split functionalities between virtual machines, the chances of one functionality braking another are smaller. And such machines can be easily reused by other users.
nice thought.
to bad that interaction between programms is the big bottleneck. (probably because programs are mostly not setup to function that way, and rewriting them to a good addon is not common and/or easy)
As long as applications have network API, it’s not that hard, as they can communicate via (virtual) network connections. And network APIs are not that uncommon. Oh, and of course they can share some filesystem parts. It all depends on tightness of a bound between two programs/components. If bound is very strong, maybe it’s a good idea to put them in one addon. If bound is weak, maybe it can be easily split to separate addons.
Let’s take for example kodi. IMHO it should not be part of home automation - home automation and kodi should be able to control themselves to some excent, but since their main responsibilities are different, they should be separated (e.g. one should be easily to restart/upgrade without need to restart another).
I know that my answers are highly philosophical, but hey, your question also had some philosophical taste (-:
To sum up: hass.io is a different approach. It needs some learning and getting used to. It is also relatively young when it comes to hass ecosystem. If you can afford to spend time / energy on learning new stuff and potentially doing some work, try hass.io.
but i dont think its the users that decide if 2 things are in 1 addon or not.
i know that its all nice when its working like it should. but for instance i see for several weeks now problems coming by from people who want to use Appdaemon.
Appdaemon works with the HASS api en without trouble in 2 seperate venvs
but getting an problemfree addon up and running seems to be difficult.
its a programm that is frequently updated. if the programmer isnt able to, or isnt willing to, update the addon at the same speed as the original you get also problems.
i tried to let people upgrade the way i am familiar with (pip) but thats not working. (or at least i havent seen someone succeeding and i have a lack of knowledge how to)
After trying HASIO I came to the conclussion that I want to revert to the old home assistant AIO. Although I like the idea about an simpler install with an image, less fuzz with missing packages and so on, much faster, it lacks things I like to do but to name a few!
First big issue I can’t get a connection using SSH, well you can but you get into a subshell with no options what so ever.
You need to build a SSH key put it there and here and you should do that… way to difficult.
My database refuses to work so no History, but I can’t correct it via SSH
My timezone is 4 hours off, no way I can go to raspi-config and fix it, it is not there in the new OS
I like to debug Mosquitto, no way to do that in a shell.
Passwords is another big omission, howto change them is beyond me.
Password for Samba.
Changing the RPI’s name in the system.
and there are a few lesser pains.
O YES SUDO, missing that big time
I know I am a poor programmer but for me… I need the old options back.
Maybe the right input will push the HASSIO image in the right direction, but for now not yet for me.
