Refer to "Upcoming Events" on this page:
1 Like
I have the same issue on a QNAP NAS running a .qpkg package (apps). It came to a sudden halt on auto-update, so I downgraded to v2021.11.5 (last packaged app). None of my hue lights worked and within a day the core tried to upgrade again to 2022.02.03 saying that 2022.02.02 was installed (it wasn’t but i presume all of the site-packages had been upgraded).
Starting Home Assistant
usage: hass [-h] [--version] [-c path_to_config_dir] [--safe-mode] [--debug] [--open-ui]
[--skip-pip] [-v] [--log-rotate-days LOG_ROTATE_DAYS] [--log-file LOG_FILE]
[--log-no-color] [--script ...] [--ignore-os-check]
hass: error: unrecognized arguments: --pid-file /var/run/homeassistant81.pid --daemon
Now I’m stuck until the package maintainer builds one for 2022.02. Unless there is something I can amend on the startup script.
#!/bin/sh
CONF=/etc/config/qpkg.conf
QPKG_NAME="HASS81"
QPKG_ROOT=`/sbin/getcfg $QPKG_NAME Install_Path -f ${CONF}`
APACHE_ROOT=`/sbin/getcfg SHARE_DEF defWeb -d Qweb -f /etc/config/def_share.info`
export QNAP_QPKG=$QPKG_NAME
export QPKG_ROOT
export QPKG_NAME
export PATH=/opt/Apache81/bin:$QPKG_ROOT/bin:$PATH
#export PYTHON=/opt/Apache81/bin/python3
#export PIP=/opt/Apache81/bin/pip3
export DESC=$QPKG_NAME
export CONFIG=$QPKG_ROOT/CONFIG_DIR
export SHELL=/bin/sh
export LC_ALL=en_US.UTF-8
export USER=admin
export LANG=en_US.UTF-8
export LC_CTYPE=en_US.UTF-8
export HOME=$QPKG_ROOT
export TMPDIR=$QPKG_ROOT/TMPDIR
#export PYTHONPATH=$QPKG_ROOT:$PYTHONPATH
export TZ=$(/sbin/getcfg System 'Time Zone' -f /etc/config/uLinux.conf)
export PIDF=/var/run/homeassistant81.pid
case "$1" in
start)
ENABLED=$(/sbin/getcfg $QPKG_NAME Enable -u -d FALSE -f $CONF)
if [ "$ENABLED" != "TRUE" ]; then
echo "$QPKG_NAME is disabled."
exit 1
fi
/bin/ln -sf $QPKG_ROOT /opt/$QPKG_NAME
cd $QPKG_ROOT/bin
#######
# activate venv
source activate
####### check update first
echo "Checking if there is any Home Assistant Update"
./pip3 install --upgrade homeassistant
#######
echo " Starting Home Assistant"
./hass -v --config $QPKG_ROOT/CONFIG_DIR --pid-file $PIDF --daemon
sleep 10
;;
stop)
echo " stopping Home Assistant"
ID=$(more /var/run/homeassistant81.pid)
if [ -e $PIDF ]; then
kill -9 $ID
rm -f $PIDF
fi
killall -9 hass
rm -rf $TMPDIR/*
rm -rf /opt/$QPKG_NAME
;;
restart)
$0 stop
$0 start
;;
*)
echo "Usage: $0 {start|stop|restart}"
exit 1
esac
exit 0
Considering docker but I’m imagining all manner of config errors re-using my existing CoreOS config folder.
Any help greatly accepted.
Does anyone else see this:
localtuya does not appear in the Integrations list.
??
Thinking about restoring an earlier version back up and then trying again with 2022.2. Options?
I’m on 2022.2.3
What version of local tuya are you on? Maybe you need to update the custom integration?
I use a raspbee2, the gpio thing ruined my most used automations and assets in my home. The raspbee 2 is pretty much the same as the conbee but way more stable, and doesn’t require an additional usb which I need. Hoping for a reversal here on this one. I’m talking 30+ activations of this automation a day now I have to find another way to do it. I really appreciate the foresight into removing a functional and honestly useful (whether you see it or not)(The raspbee 2 is way, way more stable then the conbee I had. Fix your USB shit, then remove GPIO. I should have a toggle for each port is this is the case for usb 2/3 capability because lord knows it doesn’t figure it out on it’s own) Zigbee Home Assistant is a corner stone of My home assisstant and you literally just stomped on it. WTF. Does your data not see anyone using zigbee ha on gpio for 20+ zigbee devices? What is going on here. I’ve used my raspbee flawlessly for 3 years now. I JUST HAD A FIRMWARE UPDATE TO IT 2 MONTHS AGO.
For reference, I’m talking about Zigbee Home Automation.
@frenck ](frenck (Franck Nijhof) · GitHub) - #63883 )
As of this release, all integrations interfacing with GPIO directly, have been deprecated.
There are multiple reasons for this, which includes a general low usage of these integrations. For most Home Assistant installations, GPIO isn’t easily usable and more often the integrations are unmaintained.
1 Like
Nothing is removed yet AFAIK. And you are in the wrong thread.
Has raspbee even been deprecated? Hard to tell.
I updated, it locked up entirely wouldn’t boot. I rolled back and reinstalled completely. Restored snapshot from a while back, updated, and now I can’t connect my raspbee 2 because it’s gpio and that’s gone now…It’s literally made for the raspberry pi, which is the staple.
No. It. Is. Not.
You pointed to a PR removing python 3.8 removal and are blaming woes with ZHA on that?
1 Like
Are you talking about something like this?
template:
- binary_sernsor:
- unique_id: test
name: test binary sensor template
state: "{{ true if states('binary_sensor.another_sensor') in ['unavailable', 'unknown'] else states('binary_sensor.another_sensor') }}"
No, I’m saying he removed the ability for addons to communicate with gpio, a functional part of the raspberry pi. why the hell do I even have this little crap thing now then if I can’t use basic functions like wifi and gpio? The Raspebee is made for the raspberry pi, it’s maintained, completely falsifying the whole:
There are multiple reasons for this, which includes a general low usage of these integrations. For most Home Assistant installations, GPIO isn’t easily usable and more often the integrations are unmaintained.
Might as well turn it into a pi-hole and just connect my lifx with alexa and be done with it. Is no-one else tired of needless changes like these every few months?
Buy me a conbee, today and I’ll stop bitching. I just spent money on other important stuff and I don’t have it right now, and this update pure and simple broke my home assistant (seeing as it locked up entirely and wouldn’t even boot once I updated) If It wasn’t for that, my shit would probably still work idk. I honestly think you have no idea what zigbee is, or how many people use it. GPIO is a functional part of many, many integrations, why they would remove it for “low usage” is absurd beyond belief.
This is supposed to be about the perfect smart home, why the gatekeeping?
removing python 3.8 removal
Use words, explain like an adult why anyone would remove this functionality. 
2 Likes
Thanks all for the replies.
I had to download the repo again and then do a re-start. The Integration came available again and I could proceed to add the devices back.
A bit strange how it appeared to have lost the integration with the update.
What an angry man.
If your lockup/failure to boot is the fault of 2022.2 it is not as a result of GPIO removal, because nothing has been removed yet.
If it is a result of python 3.8 removal, you are not explaining very well, perhaps your low mood is getting in the way of a decent explanation.
Just what I needed! Thanks! I guess I need to start spending more time there. 
You’re right, my mood is sour because I have to find out a way to connect 20+ zigbee devices without my raspbee 2
This is what I’d replace it with, and I’d have to re-pair all the devices and the motions sensors and stuff. soo yea…fun. sonoff conbee 2 Also We’re fairly broke, hence using an openish source platform for home security and automation. Woulda been nice not having to deal with this but I’ll move on I suppose. As long as this sonoff zigbee bridge works. PIMA tho.
Try explaining exactly why your boot failure is due to changes in 2022.2? Maybe someone can help.
Or revert to 2021.12 at least until your problem is fixed.
1 Like
This media filtering has broken some stuff for me. I have a bunch of video files and mp3s and my Google cast devices (Nest Minis, Hub, and Google Home Minis) used to be able to play them all. I could cast an mp4 to an audio only device and it would play the audio. Now I can’t even see the mp4s in the browser. Does anyone know of a way to remove the filtering? I’ve looked at the Media docs but they don’t mention any control over what content shows in the media browser.
Do you honestly think I know that? I logged in, I read the MOTHER OF ALL RELEASE NOTES for about 2 minutes said eh fuck it, clicked updated because eventually I have no choice as it’s functionally going to shit out and will become insecure, then magically It just didn’t come back online. At all, I tried local control, I tried cloud, I tried to ping it from console, nothing, It was just stuck. So I pulled the power cord and rebooted…10 minutes still nothing, so I pulled the power cord and the sd card, reformatted it, loaded a new copy of hass, and then loaded the snapshot right from the login page. I was in, My home assistant addons all dated back to december but I was in, I clicked update, and zigbee home assistant no longer can see the raspbee 2 connected to the gpio pins on the raspberry p 4b.
Better?
1 Like
No you don’t. GPIO has not yet been removed, that won’t happen for 4 months. In those 4 months you have plenty of time to switch to the custom component which brings back that core functionality. (EDIT: as per Francis’ comment below, this shouldn’t even be needed)
Also, if you want to keep complaining about something that has already been resolved, please do it here.
Also, since you are frustrated and this will help…
Is actually Zigbee Home Automation 
None of that appears to be related to the update to 2022.2 as GPIO has not yet been removed.