Piwheel issues with older versions of Raspbian

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 :x:

To: mysql+pymysql://USER:PASS@HOST/homeassistant?charset=utf8 :white_check_mark:

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 :slight_smile:

2 Likes

Hi, I’m planning to update to Buster from my current Hassbian with option 1 but, regarding its step 1:

Steps

  1. Change stretch or jessie to buster 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.

1 Like

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

1 Like

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 :slight_smile:

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)