2023.1: Happy New Year of the voice!

Can you post your logs when you perform a restart? You can access them via SSH or Samba Share

Can access via samba share… Where are stored the log ? on hassio ?

homeassistant.log, you should have 5, one for each of your last few restarts. The most recent will not have a number. Increasing numbers on the logs are older log files.

Wow, where to start.

  1. You have many deprecated options still in configuration.yaml. These deprecations happened almost 2 years ago. entity_id was removed from template sensors.
  2. Darksky is rejecting your API key.
  3. You’re having issues with your USB port. HA is not seeing any device connected to /dev/ttyACM1.
  4. You can’t connect to PVOutput
  5. You have a number of incorrectly configured MQTT entities.
  6. You’re missing a unit of measurement on a mobile app sensor. If you didn’t remove it, then this is a bug with the mobile app you’re using
  7. You can’t connect to any of your ESPHome devices
  8. You have compatibility issues with Music Assistant. I don’t use that so I can’t really explain why it needs 2022.11, but that’s what it’s claiming.
  9. You can’t connect to any of your cameras
  10. Lastly recorder is cancelling it’s startup. Is your database on another device? This is what’s ultimately killing HA.

Most of these issues seem like you have a network issue. Something is going bad on the hardware you’re running on your your router is acting up.

3 Likes

actually, you were the first of us both who respond.
Initially, I asked someone else (who I suppose has a better chance to know rationale than you) but you had to jump into that writing piece of advice but not answered my original question. It really doesn’t help.

Knowing rationale helps understand decisions. Asking for the rationale isn’t a bad thing. Answering them is a matter of good culture.

He’s getting his information by reading the release notes and github PRs… Same thing I do. Someone like that isn’t going to know the rational. As always, the rational for things like that are located in the same place they always are. The discussions section on github, the ADRs, or PRs.

EDIT: There’s nothing in discussions or the ADRs. So the reasoning is most likely buried in a PR. I’ve located a few PRs about the update_entity service call, but they do not lead to a reasoning.

Why yaml cannot use similar settings for polling?

You can still schedule updates with homeassistant.update_entity using an automation for yaml entities. scan_interval only accepts an integer, so you can’t turn it off. Typically people set the value to a large frequency like 9 million seconds to “turn it off”.

That is what I do - manual update and huge scan_interval.
But anyway it updates on HA start up.
My question was in general - why settings for polling cannot be set by yaml, what is a reason of this limitation?
Is it related to compatibility?

1 Like

I guess I don’t understand your question. If the sensor or integration can be added via yaml, scan_interval is available for the configuration. If the sensor/integration can only be added via the UI, you can’t adjust the scan interval (polling rate) via yaml because it doesn’t have a yaml configuration.

Yes coz some network connections problems linked with multiple reboot. But my main concerns now, my RFXtTrx is no more detected in any serial port :frowning: … coz also some other problem with serial (sky connect, leonardo)

I had a similar issue after the update with it taking forever to finish starting up and then the bootstrap message saying it never completed so moving on.

If this helps anyone, check your log and see what is giving you the most errors and disable those integrations, reboot make sure everything is happy then reenable them one at a time and reboot till the problem comes back.

Mine was the formulaoneapi causing my problem so looking to see if there is any open issues etc and go from there.

99% of the time for me, it has always been a random integration I have added at some point that causes these problems.

Serial devices on USB are autonamed in linux and the name depends on the device.

many popular devices used in HA are named ttyACM0, ttyACM1, ttyACM2 etc. First one detected is 0.

If you have a config with /dev/ttyACM1 then you must have had a /dev/ttyACM0.

You cannot know which one becomes 0 and which one becomes 1. It may happen that the two are always assigned the same in 99% of the time. And then the 1% you will think it is something else that is broken.

There is a reason why people prefer to use the predictable /dev/serial/by-id/xxxxxx links instead as they are predictable and point to the right place (updated each time you boot)

There was an issue with Deconz addon using by-id links. I do not know if that was ever fixed. I moved my Deconz to a different machine. But in general you want to use the by-id device path instead.

2 Likes

Just installed 2023.1.1, and went looking for a backup for an addon and noticed that all my backups are missing on the backups page. Has anyone come across this?

Also made a backup which took longer than normal, and it’s not there either. Does anyone know where the backups are saved? I’d like to have a look and see if they are infact gone, of if there is some bug in showing them to me.

Yes. Devices and services. Application credentials

I have a docker installation and the backups are in config/backups. I can see all the backups with 2023.1.1.

I did find out the NodeRed addon was causing this. There are a lot off problems at the moment with the NodeRed addon. For me greyed out inject and debug nodes and start/stop of Nodered addon all the time
I switched to nodered as sperate docker. All is fine now, including CPU speed

1 Like

Took me a bit of time to get used to the changes through the updates but the addon still works well for me.

The problem I had with one of my integrations not starting properly after the 2023.1.1 meant nodered didn’t start until everything else had finished so it started out looking like a nodered issue but wasn’t in the end.

Was fixed in 2023.01.01 :grinning:

1 Like