The issue there is the versioning conflict on aiohttp with Appdaemon and HASS on the same OS. Docker can avoid the issue by its nature, but obviously the best solution is to harmonize the version requirement in the long run.
SoooâŚ
If youâre running HA in a venv, this shouldnât be an issue then? Or is it still a problem?
Not an issue if you have one or the other or both in a vEnv or if you are using docker,
1 Like
However youâre doing it, if HASS and Appdaemon are on different OS instances (Dockers, VMs, physical machines, etc) then theyâre fine.
1 Like
Thank you both for the clarification.
1 Like
Hi There - yes, Beta 3 pretty much has the finished version of the new widget model. For better support I will add a custom_widget directory like I did with CSS, but if you want to start ahead of that, there is no reason not to as I expect the javascript components of the widget to be pretty stable now (that was the bulk of what I was changing).
1 Like
Good news, thanks! Will probably start with one specific to a device I have that i wrote a custom component for (no one else seems to have the system as I posted in the forum a while back).
1 Like
OK, cool. I would welcome your feedback on the widget API and let me know if you have nay questions.
Everyone sit tight on the aiohttp issue - I will hopefully be putting out a fix later today.
OK, I pushed a new version, I wonât start a new thread as it doesnât have too much in it, but it does support the same version of aiohttp that HASS does.
2.0.0beta3.5
- Label now accepts HTML for the value
- IFRAME widget now allows vimeo and youtube videos to go fullscreen when clicked
- IFRAME and Camera widgets now have optional title overlay
- Widgets that display icons can now pick up icons defined in HASS
- aiohttp version 2 support
Fixes
Breaking Changes
4 Likes
its just the fact that i can manipulate all over the place that makes appdaemon so powerfull.
for instance manipulate cronjob files based on certain sensor states, gives the option to take a picture with a webcam every minute, but if it is to dark it gives a picture that says there is not enough light. no need to keep the cronjob running for that time.
the background from the rpi, the volume from the rpi, actually any settings file from every program that is running on the pi can be manipulated based on certain circumstances. starting programs, stopping programs, etc. etc.
thats why i talk about files all over the RPI.
off course, if your apps only react to ha and only interact with HA then there is no problem, but then you lose a big part of the power of python in my eyes.
i guess the different viewpoint is that i see python as the overall program and ha and appdaemon just as small part from that big picture, where others see HA or appdaemon as seperate programs.
Nod, we just have a different style. I work a bit more distributed than that; eg, I really have nothing in my HASS Pi hardware wise, I push things out to other nodes on the network. Microcontrollers or other Pis or whatever, that handle a single function. So I do audio elsewhere, I do camera elsewhere, etc. In my case Appdaemon augments the shortcomings of HASS for automation, which is really hard to accomplish anything beyond the basics with (plus the constant restart/try/restart/try cycle gets old) â but yah I leverage HASS to do the state work, it is the center of that universe for me.
I think in the case of HADashboard, there will be a different class of people who are all about that dashboard and not the apps side at all (!) but theyâd also not be the folks who want to dig into much code anyhow. Just enough YAML to get through a dashboard and done. So thatâs certainly not integral.
EDIT: I think the fact that different pieces can be put together in different ways like this, that suits the people doing it, is pretty awesome though. You cant buy that in the store!
1 Like
Just updated and I get this error when trying to start.
Traceback (most recent call last):
File "/usr/lib/python3.4/runpy.py", line 170, in _run_module_as_main
"__main__", mod_spec)
File "/usr/lib/python3.4/runpy.py", line 85, in _run_code
exec(code, run_globals)
File "/home/hass/appdaemon/appdaemon/appdaemon/appdaemon.py", line 1671, in <module>
main()
File "/home/hass/appdaemon/appdaemon/appdaemon/appdaemon.py", line 1667, in main
run()
File "/home/hass/appdaemon/appdaemon/appdaemon/appdaemon.py", line 1180, in run
asyncio.ensure_future(appdaemon_loop())
AttributeError: 'module' object has no attribute 'ensure_future'Got it all working fairly quickly including installing docker - made a couple of small mistakes in my copy and pasting and had to add a sudo here and there. Thank you so much.
Excellent timing as I stupidly upgraded and broke HADashboard half an hour before I had to leave for work with guests coming to stay while Iâm out.
i started with hass on my windows pc 
my RPI is pretty dedicated to hass and appdaemon also, but i have little money and a webcamera that is laying around gave me cameraoptions
i want my hass to be able to speak, but a stereo isnt available at this moment, so i did put a cheap box on my RPI.
i just bought my second rpi only because i need backup and my first one was dying.
i love to be able to split things up, but that will cost more money
i know there are loads of other people doing other things in other ways, and that absolutely fine. if that wasnt the case i wouldnt be able to do the things i do, my way
so that said i also know that docker is something good for some people, but for others it can be a horror, and it also depends on developers knowing how to work with it the right way.
at least i am happy that i am able to install without the need for docker, VE or VM or anything like that
1 Like
Totally with you. Even though I generally prefer Docker, if something was available ONLY as a Docker?? I feel theyâre doing something really wrong.
1 Like
I couldnât get pass this error after beta 3.5, any idea? I am running rPi3 All-In-One installer. It was working with beta 3 earlier this morning.
Traceback (most recent call last):
File "/usr/lib/python3.4/runpy.py", line 170, in _run_module_as_main
"__main__", mod_spec)
File "/usr/lib/python3.4/runpy.py", line 85, in _run_code
exec(code, run_globals)
File "/home/appdaemon_dashboard/appdaemon/appdaemon/appdaemon.py", line 1671, in <module>
main()
File "/home/appdaemon_dashboard/appdaemon/appdaemon/appdaemon.py", line 1667, in main
run()
File "/home/appdaemon_dashboard/appdaemon/appdaemon/appdaemon.py", line 1180, in run
asyncio.ensure_future(appdaemon_loop())
AttributeError: 'module' object has no attribute 'ensure_future'
I have following components installed and NOT running virtual Python environment.
Command I have used to get the list is: pip3 list
aiohttp (2.0.6)
aiohttp-jinja2 (0.13.0)
astral (1.4)
async (0.6.2)
async-timeout (1.2.0)
asyncio (3.4.3)
chardet (2.3.0)
colorama (0.3.2)
configparser (3.5.0)
Cython (0.21.1)
daemonize (2.4.7)
docutils (0.12)
html5lib (0.999)
Jinja2 (2.9.5)
MarkupSafe (0.23)
multidict (2.1.4)
Pillow (2.6.1)
pip (9.0.1)
Pygments (2.0.1)
pyScss (1.3.5)
pytz (2017.2)
PyYAML (3.12)
requests (2.13.0)
roman (2.0.0)
setuptools (5.5.1)
six (1.8.0)
Sphinx (1.2.3)
sseclient (0.0.18)
urllib3 (1.9.1)
virtualenv (15.1.0)
voluptuous (0.9.3)
websocket-client (0.40.0)
wheel (0.24.0)
yarl (0.10.0)Try pulling again - I put a fix in for this.
1 Like
Wow! You are so much committed to this project. You did fix this in few hours and middle of the night!
May be next time I will have to think before posting any issue during night so you will not spoil your night trying to figuring out and fixing the issue :). Appreciate your dedication and valuable time.
I will try this fix tonight once I am at home.
Thanks you so much.
2 Likes
@aimc, @scadaguru has a point, although it may mean less features in the dashboard so quick. You gotta get a life man. LOL