I tried changing mine, but still getting an error:
ERROR (Recorder) [homeassistant.components.recorder] Error during connection setup: No module named 'pymysql' (retrying in 3 seconds)
I tried changing mine, but still getting an error:
ERROR (Recorder) [homeassistant.components.recorder] Error during connection setup: No module named 'pymysql' (retrying in 3 seconds)
You need to install âpymysqlâ using pip in the venv.
Also stuck on the mariadb issue, having upgraded to Buster.
Changed the db url from mysql://
to mysql+pymysql://
(see below) and installed pymysql
(in the venv), but Iâm getting âConnection refusedâ -errors.
Current db string: mysql+pymysql://USER:PASS@HOST:PORT/homeassistant?charset=utf8
I can connect to the database, using mysql -u USER -h HOST --port PORT -p homeassistant
Any ideas?
EDIT: Solved. Seems I no longer should include port. So though the PORT was correct, as I could connect to it from the console, it nevertheless doesnât work if included in the db url -string. So, what seemed to have fixed for me was:
From: mysql://USER:PASS@HOST:PORT/homeassistant?charset=utf8
To: mysql+pymysql://USER:PASS@HOST/homeassistant?charset=utf8
Well I couldnât resist and tried docker on my current OSMC/raspbian Rpi3, with HA 0.96.5.
After the initial pain of the learning curve of using docker and resolving container-related breakage (two half-afternoons - I use a few scripts than canât be run inside the container and also needed some other state persistence), I have to say that the result is excellent.
Now the Rpi3 running my kodi music server and dockerized HA is running at half the utilization on idle that it had while I was running the python vEnv, and the system feels significantly more responsive. 5-min load average of 0.25 vs. ~ 0.60 that I used to see before.
Why this is so I have no idea. My fear with docker was a performance penalty and that the RPi3 would be too slow to handle it - and I was proved wrong.
Looks like I will be cancelling my plan to upgrade to RPi4 by the end of the year. And will be able to keep up with HA upgrades more easily than before - plus no need to upgrade to buster, which OSMC does not yet support - and I no longer care when it will
Hi, Iâm planning to update to Buster from my current Hassbian with option 1 but, regarding its step 1:
Steps
- Change
stretch
orjessie
tobuster
in these files:
/etc/apt/sources.list
/etc/apt/sources.list.d/raspi.list
/etc/apt/sources.list.d/hassbian.list
Iâm not familiar with doing changes to distributions. Where do I get the files:
sources.list, raspi.list and hassbian.list from the buster distribution
to put them in the aforementioned directories?? Maybe itâs a stupid question but any help willl be appreciated.
Just edit those files with a text editor, e.g. vi or vim and just change the word jessie to buster.
There are other more elegant ways to do it with sed, but its all the same same.
I updated last night. With modification to sql line (pymysql) everything seemed to run well. But after one extra restart (I didnât change anything in config) the stream component with foscam cameras stopped working (it worked initially after system update). Log shows no errors. Any idea why it worked after update and boot and after restarting home assistant it stopped working? I removed stream from config and now the cameras work fine (without streaming of course).
Edit. Iâm running hassbian in raspi 3.
Another look and error in logs:
Aug 07 07:22:18 hassbian hass[27324]: Exception in thread stream_worker:
Aug 07 07:22:18 hassbian hass[27324]: Traceback (most recent call last):
Aug 07 07:22:18 hassbian hass[27324]: File "/usr/local/lib/python3.7/threading.py", line 917, in _bootstrap_inner
Aug 07 07:22:18 hassbian hass[27324]: self.run()
Aug 07 07:22:18 hassbian hass[27324]: File "/usr/local/lib/python3.7/threading.py", line 865, in run
Aug 07 07:22:18 hassbian hass[27324]: self._target(*self._args, **self._kwargs)
Aug 07 07:22:18 hassbian hass[27324]: File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/components/stream/worker.py", line 48, in stream_worker
Aug 07 07:22:18 hassbian hass[27324]: import av
Aug 07 07:22:18 hassbian hass[27324]: File "/srv/homeassistant/lib/python3.7/site-packages/av/__init__.py", line 9, in <module>
Aug 07 07:22:18 hassbian hass[27324]: from av._core import time_base, pyav_version as __version__
Aug 07 07:22:18 hassbian hass[27324]: ImportError: libswscale.so.4: cannot open shared object file: No such file or directory
Will stretch eventually fix the issue? Is there a plan? This kind of big hack always put the system into risk.
How do you figure this? You either upgrade to the latest distro âBusterâ or compile your own packages.
Buster have updated libs vs stretch. ffmpeg -version shows every lib +1 conpared to stretch:
https://packages.debian.org/stretch/ffmpeg
vs buster
https://packages.debian.org/buster/ffmpeg
pi@hassbian:~ $ ffmpeg -version ffmpeg version 4.1.3-1+rpt1 Copyright (c) 2000-2019 the FFmpeg developers
built with gcc 8 (Raspbian 8.3.0-6+rpi1)
configuration: --prefix=/usr --extra-version=1+rpt1 --toolchain=hardened --libdir=/usr/lib/arm-linux-gnueabihf --incdir=/usr/include/arm-linux-gnueabihf --arch=arm --enable-gpl --disable-stripping --enable-avresample --disable-filter=resample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libcodec2 --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libjack --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librsvg --enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzmq --enable-libzvbi --enable-lv2 --enable-omx --enable-omx-rpi --enable-mmal --enable-openal --enable-opengl --enable-sdl2 --enable-libdc1394 --enable-libdrm --enable-libiec61883 --enable-chromaprint --enable-frei0r --enable-libx264 --arch=armhf --enable-shared
libavutil 56. 22.100 / 56. 22.100
libavcodec 58. 35.100 / 58. 35.100
libavformat 58. 20.100 / 58. 20.100
libavdevice 58. 5.100 / 58. 5.100
libavfilter 7. 40.101 / 7. 40.101
libavresample 4. 0. 0 / 4. 0. 0
libswscale 5. 3.100 / 5. 3.100
libswresample 3. 3.100 / 3. 3.100
libpostproc 55. 3.100 / 55. 3.100
So as my error shows, code is trying to find libswscale4, Buster has installed libswscale5 to my system.
Do I have to reinstall / update something or wait for something to be updated in home assistant (pyav for example)?
Edit. Re-installing pyav in venv solved the issue for me. So now buster upgrade is succesful, pihole works also in same rpi
Iâm running an old Hassbian on Jessie with Home Assistant 0.96.5 in a venv with python 3.6.3. I havenât had any problems with SSL, but I remember I saw a warning about cryptography/Open SSL when upgrading to 0.96.5.
Having no issues with 0.96, can I safely upgrade to 0.97? or do I need to upgrade to Buster before attempting this?
I updated my stretch to buster and also had the problem with certbot-auto. I first had to remove the old venv directory (/opt/eff.org
) created by the certbot-auto script under stretch and als âcommented outâ extra-index-url in /etc/pip.conf
for the first run of the certbot-auto, so it could rebuild a new venv. See also https://community.letsencrypt.org/t/certbot-auto-certificates-fails-while-installing-phyton-packages-with-these-packages-do-not-match-the-hashes/90363/10
You could use dehydrated instead of certbot-auto. https://github.com/SilvrrGIT/HomeAssistant/wiki/Letâs-Encrypt-Setup-(Hassbian,-Python-Virtual-Environment)