And yes, the raspbee uses GPIO to connect to the Pi, but that uses none of the GPIO integrations that are about to be removed. It simply uses the serial port on the GPIO-pins, and that stays supported.
3 Likes
@VarenDerpsAround has your OS updated. If you are using HAOS, the update to 7.3 five days ago did update the rpi kernel firmware https://github.com/home-assistant/operating-system/releases/tag/7.3
Got the same error… can’t be good. I’m going to hold off as well. ugh.
Your raspbee 2 is not affected, read the bottom part of the GPIO deprecation note
1 Like
Is this perhaps relevant to @VarenDerpsAround 's problem. Hard to say as he is happier ranting than providing relevant info.
1 Like
If he’s running the raspbee2 with ZHA, then yes probably
Not sure why you are still using a fan. I had to replace mine because of noise, and after the second failed, I bought this, and my temp hovers around 110°F. RPi 4, 4GB driving both a ZWave and Conbee USB controllers.
I’m clueless as to why so many HA users are putting fan’s on their RPi’s as well. The RPi comes without a fan because it doesn’t need one. Before I upgraded to a NUC I ran a RPi and it never had any heat issues without a fan…
don’t mistake your situation with the absolute truth… as always, ymmv.
Pi’s are effectively throttled when getting too hot, (which they do under circumstances) rendering a useless HA instance.
the thermal pads are not always sufficient. If they do anything at all.
As I have witnessed myself… Aluminum case helps, fan too. Havent seen halting system after having installed my ArgonOne, always between 34-40C, where it got near 80 before…
1 Like
Ha: ever tried a pi with an amp hat in a waterproof sealed box? (No it wasn’t running ha)
I’ve not ever had a need to waterproof a RPi… but I can imagine an amp hat would generate a fair bit of heat, however that’s certainly not anything like a HA server. I get that some people like to pile up a heap of services on the same device and in that case if an amp hat is included then a fan would be nice. Using it for HA and even with a raspbee or similar… no fan needed.
Energy dashboard partly not working anymore for custom energy entities coming from nodered but working for standard entities from 3rd party integration.
Strangely I see energy 0 but cost keep counting
Yeah it is the media player for my spa. There is a 5inch hdmi screen in there too.
Interesting on a hot morning to graph temp and connectivity. 80c and it is all over rover.
Anyway, off topic.
Well that could be used for existing binary sensors. But I was under the impression you were speaking about your current template binary_sensors and adding a field to that configuration. Which, in my opinion, is useless because you can just change your template to output a known state.
For example, you had this template that checks if a value is above 25:
template:
- binary_sernsor:
- unique_id: test
name: test binary sensor template
state: >
{% set value = states('sensor.xyz') | float(none) %}
{% if value %}
{{ value > 25 }}
{% endif %}
right now, that template will return unavailable. If you don’t want that, change the logic. This would default it off when unavailable:
template:
- binary_sernsor:
- unique_id: test
name: test binary sensor template
state: >
{% set value = states('sensor.xyz') | float(none) %}
{% if value %}
{{ value > 25 }}
{% else %}
false
{% endif %}
or you have this binary sensor that only triggers on state changes for sensor.xyz. On startup, it could be unknown if sensor.xyz doesn’t output a state.
template:
- trigger:
- platform: state
entity_id: sensor.xyz
binary_sensor:
- name: xyz
state: >
{% set value = trigger.to_state.state | float(none) %}
{% if value %}
{{ value > 25 }}
{% else %}
false
{% endif %}
This catches unavailable from sensor.xyz, but will be unknown on startup. So just add a startup trigger.
template:
- trigger:
- platform: state
entity_id: sensor.xyz
- platform: homeassistant
event: start
binary_sensor:
- name: xyz
state: >
{% set value = trigger.to_state.state | float(none) %}
{% if value %}
{{ value > 25 }}
{% else %}
false
{% endif %}
I am running HA Container in Docker, but not on a NAS.
I like not needing to worry about dependencies and I can upgrade when I want to. Since 2022,2 has been released I just upgraded to 2021.12.x, for instance. My current opinion is that it is likely the most stable current release. i follow threads like this to get a feel for what is coming whenever I upgrade again,.
4 Likes
I see 2 possible solutions.
- Community components for GPIO have been mentioned in this thread & others.
2, USB Zigbee sticks are very common and could be a solution.
You did not look very far for a solution so it does not appear important enough to you to trigger anger about an upcoming removal. Perhaps they should have removed it without warning to make you happier? 
1 Like
As indicated by Francis earlier:
- Nothing has been removed yet
- It has nothing to do with the raspee, anyway
- There is an explicit exception for anything using serial communication
1 Like
The take away here is that @VarenDerpsAround doesn’t understand that the GPIO integration deprecation doesn’t impact him, but he believes it does because he’s having a separate unrelated issue.
3 Likes
Has anyone identified the bug with Radarr integration?
Here is the topic but no devs have weighed in:
The radarr bug has been fixed (i opened an issue about it before the one you mention) i am running the fix as a custom component because its been stalled in review for a while. Sabnzbd is broken as well because of an upstream dependency and will stop working next release I think.