2021.9.0: More energy, USB discovery, template ❤️

A config check against the new version would not have helped here, unfortunately. This wasn’t an issue with configuration and the new version. It’s looking like broken sqlite-tools for aarch64 in alpine 3.14

In regard to backups, you should make use of other add-ons or automations which will copy off your backups to another location aside from the device itself. I use the Google Drive add-on which has been mentioned here and there are other options. https://www.home-assistant.io/common-tasks/os#copying-your-backups-to-another-location

In regard to the restarting, you can connect keyboard and monitor to your device and force HA into safe mode. Once it is no longer restarting you should be able to downgrade using ha core update --version=2021.8.8 in the ssh add-on terminal. Also, @Ildar_Gabdullin

This is from an esphome node config - ive repurposed the Glow electricity sensor using a reed switch

  - platform: template
    id: gas_glow_total_gas_m3
    name: '${friendly_name} - Total Used m³'
    accuracy_decimals: 3
    unit_of_measurement: 'm³'
    state_class: measurement
    device_class: gas
    last_reset_type: auto
    icon: 'mdi:circle-slice-3'

I have a similar config (also without showing up in the dropdown for gas):

sensor gas_delivered:
  platform: mqtt
  name: "Gas Gebruik"
  state_topic: "DSMR-API/gas_delivered"
  state_class: total_increasing
  unit_of_measurement:'m³'
  value_template: '{{ value_json.gas_delivered[0].value | round(3) }}'

the last_reset attribute does also not make it visible…also interested what is missing.

Yes, I am also confused about the long term stats. The blog says basically all sensors can use this feature now, but I see no configuration options anywhere.

1 Like

I get it out. Put into your config:
device_class: gas

Finally got my gas working :grinning:

image

Had to do it in 2 places - MQTT sensor and then add last_reset: ‘1970-01-01T00:00:00.000000+00:00’ via customize.yaml. Unit of measurement has to be m³ and not m3 -

- platform: mqtt
  name: "Gas M3"
  state_topic: "SMART/HILD/XXXXXXX"
  unit_of_measurement: 'm³'
  value_template: "{{ value_json['gasMtr']['0702']['00']['00']|int(base=16) * value_json['gasMtr']['0702']['03']['01']|int(base=16) / value_json['gasMtr']['0702']['03']['02']|int(base=16) }}"
  icon: 'mdi:fire'
  state_class: measurement
  device_class: gas
    sensor.gas_m3:
      last_reset: ‘1970-01-01T00:00:00.000000+00:00’

Thanks to all that helped.

1 Like

Check what I did here

@BertrumUK yes, the key here is m³ and not m3.

Lost 2 days (How adapt a custom mqtt reading gas sensor to use with new dashboard), I would try to update the docs, in case.

1 Like

Seems you were going to say something but the post is cut.
Regarding my case - there is nothing critical. The RPi HA setup is basically used for testing purpose, I can wait for the next update, there is no need for me to downgrade.

I’m so glad for the Homekit Device Automations! Finally a way to send button events to Homekit without awkardly mimicing a switch that goes on and off…

Is it possible to use though, if configured in YAML? According to documentation it’s something you add in the integration, but if you do it the YAML way there’s no option for it…

I am still not seeing this update in supervisor on either of my two instances.

1 Like

Its been pulled for now

image

1 Like

hello @all

same problem, i have any notification info for HA Core 2021.9.0 in supervisor and the strange thing is when i check the log i can see :

INFO (MainThread) [supervisor.updater] Fetching update data from https://version.home-assistant.io/stable.json

so i check https://version.home-assistant.io/stable.json

and the result is logic :

channel	"stable"
supervisor	"2021.08.1"
homeassistant	
default	"2021.8.8"
qemux86	"2021.8.8"
qemux86-64	"2021.8.8"
qemuarm	"2021.8.8"
qemuarm-64	"2021.8.8"
generic-x86-64	"2021.8.8"
intel-nuc	"2021.8.8"
khadas-vim3	"2021.8.8"
raspberrypi	"2021.8.8"
raspberrypi2	"2021.8.8"
raspberrypi3	"2021.8.8"
raspberrypi3-64	"2021.8.8"
raspberrypi4	"2021.8.8"
raspberrypi4-64	"2021.8.8"
tinker	"2021.8.8"
odroid-c2	"2021.8.8"
odroid-c4	"2021.8.8"
odroid-n2	"2021.8.8"
odroid-xu	"2021.8.8"
hassos	
ova	"6.2"
rpi	"6.2"
rpi0-w	"6.2"
rpi2	"6.2"
rpi3	"6.2"
rpi3-64	"6.2"
rpi4	"6.2"
rpi4-64	"6.2"
tinker	"6.2"
odroid-c2	"6.2"
odroid-c4	"6.2"
odroid-n2	"6.2"
odroid-xu4	"6.2"
generic-x86-64	"6.2"
intel-nuc	"6.2"
ota	"https://github.com/home-assistant/operating-system/releases/download/{version}/{os_name}_{board}-{version}.raucb"
cli	"2021.08.1"
dns	"2021.06.0"
audio	"2021.07.0"
multicast	"2021.04.0"
observer	"2021.06.0"
image	
core	"homeassistant/{machine}-homeassistant"
supervisor	"homeassistant/{arch}-hassio-supervisor"
cli	"homeassistant/{arch}-hassio-cli"
audio	"homeassistant/{arch}-hassio-audio"
dns	"homeassistant/{arch}-hassio-dns"
observer	"homeassistant/{arch}-hassio-observer"
multicast	"homeassistant/{arch}-hassio-multicast"
images	
core	"ghcr.io/home-assistant/{machine}-homeassistant"
supervisor	"ghcr.io/home-assistant/{arch}-hassio-supervisor"
cli	"ghcr.io/home-assistant/{arch}-hassio-cli"
audio	"ghcr.io/home-assistant/{arch}-hassio-audio"
dns	"ghcr.io/home-assistant/{arch}-hassio-dns"
observer	"ghcr.io/home-assistant/{arch}-hassio-observer"
multicast	"ghcr.io/home-assistant/{arch}-hassio-multicast"

I am under HassOs 6.2, core 2021.8.8, supervisor 2021.08.1

Is someone can explain what append to a few of us please?

@applesauce are you under HassOS too?

Thanks

Search this forum for “Pi3” and you will see why. Seems there is a memory issue related to the new USB addition.

1 Like

Operating System

Home Assistant OS 6.2

We are only 2 guys who that happens lol ?

I am glad they pulled it if there are bugs that need to be resolved.

2 Likes

Yes you’r right!

i wait for 2021.9.1…

for those cant wait, a ha core update --version 2021.9.0 will work :wink:

For those of you using (rooted) Toon slimme meter…

Adapted to new energy dashboard code
Added gas sensors for energy dashboard Optimized sensor code

@cyberjunky cyberjunky committed 4 hours ago

Looks like the GitHub issue was locked so responding here.

I sympathize with the HA devs as a developer myself. Bugs happen, it’s just a fact. My argument is that certain scenarios should probably be tested a little more thoroughly. This isn’t some obscure scenario AFAIK, it affects anyone running HA OS (or whatever it’s called now) with a Pi 3b+.

I do have an issue about the tone many are taking regarding this issue. Seems like some devs and mods are taking a very hostile stance here and I’m not quite sure why. As far as I can see, that vast majority of affected users are just trying to report what they’re seeing and getting responses like “you’re not describing the problem correctly” (boot loop vs core crashing, because the average user differenciates the two of course), or “maybe you should be a beta tester”. It’s not really constructive.

Regarding becoming a beta tester, I actually wouldn’t mind doing that if it helped the community. I know most people saying this are just using it as a device to victim-blame, but I’ll take you all up on that. Is there a guide somewhere where I can do that? I understand the mechanics of opting in, but how would one run their production (stable) instance in parallel with the test instance? In my case I have a z-wave stick in my Pi 3b+, but beyond that nothing too crazy. And not just running in parallel but also how to properly stage and mirror changes between the instances. I’m genuinely interested in helping out here if given some reasonable direction.

7 Likes