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.
- You have many deprecated options still in configuration.yaml. These deprecations happened almost 2 years ago. entity_id was removed from template sensors.
- Darksky is rejecting your API key.
- Youâre having issues with your USB port. HA is not seeing any device connected to /dev/ttyACM1.
- You canât connect to PVOutput
- You have a number of incorrectly configured MQTT entities.
- 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
- You canât connect to any of your ESPHome devices
- 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.
- You canât connect to any of your cameras
- 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.
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?
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 ⌠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.
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
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