Bring back home-assistant.log for supervised users

[Petro31]

Describe your core improvement

2025.11 removed home-assistant.log if you're a HAOS or Supervised user. I'd like the option to have them back as well as the past log.

Both of these items were necessary for debugging systems through restarts as well as simple configuration errors, like creating a template sensor or a rest sensor.

Current limitations

Debugging just got harder

1. We can't use our own tail software, which typically all use files stored to disk. (No text styling options, highlighting, columns, etc)
2. There is no previous log file to view after a restart or a reboot
3. When only samba share is working, you can't view logs
4. If we use a devorak keyboard, we can only use SSH because the console only supports qwerty.

Technical benefits

• Helps debugging

Additional context

No response

[tomlut]

Link to PR: home-assistant/core#146675

[Mariusthvdb]

for as long as I use HA now, about 9 years, the advise has been to move away from SDCards simply because they will fail. Might take a while, but they will.

considering that, it seems the wrong fix for the problem to take away the log. Especially in a time where more and more users will be installing HA in more robust machines, or in virtual ones, which dont have that issue either?

In the PR there has been a chat about the users choice of en/disabling that log write to disk, and decision was to not do that.
maybe that can still be reconsidered. In which case the whole PR needn't reverted, just amended

[edenhaus]

why introduce such a breaking change (it isnt even marked as a breaking change),

@Mariusthvdb That's not correct. It was marked as a breaking change. See the label, which are the ones that count in the end. The bot will set the correct labels from the PR, when opening the PR.

[Mariusthvdb]

Ok yes I see now

[ScottG489]

I think reducing disk usage and writes are both good ideas, regardless of what hardware you're on. The issue is that doing it this way breaks some users workflows, so we should try to find some ways of maintaining that functionality for those who need it.

[timmo001]

I'd like to suggest a symlink to the logs instead, the config directory is a good place to find everything, it can also be the easier place to diagnose a broken setup. If there are multiple logs avaliable, os, supervisor, network etc. potentially a directory could be used /config/logs/<symlinked to journal>?

---

This is the first I heard of this change, its a good one, but it needs ways of accessing the logs when your system is remote and the UI is down. Unrelated, but the supervisor test endpoint (I can't even remember the port number) observer at :4357 which shows whether the supervisor is up etc, could also give a view/download for the logs

[Mariusthvdb]

just stating it's a good one, is not really appreciative of the reasoning behind this discussion tbh...

the whole point is that OP feels it is Not a good one. as do a few other posters/users

[timmo001]

To clarify, it's not good that logs can't be accessed via /config anymore, which is why I suggested the symlink.

This removes the need to write to the filesystem twice, and gives access to more logs for those only with samba access for example

[ScottG489]

I don't believe the files in /config/logs/ are plaintext: https://www.freedesktop.org/wiki/Software/systemd/journal-files/

Another option might've been the logs from docker in /var/lib/docker/containers/. However, it doesn't look like they log here and instead integrate logging with journald, which is kinda a good thing anyways otherwise we'd have even more duplicate logs.

You're still able to download the log file from Settings > System > Logs > (Download icon in the top right). However, for filesystem operations such as watching the file for changes, it's not adequate. It also isn't a substitute for situations where you only have filesystem access or need the old log file.

[cogneato]

I also appreciate reducing disk writes, but the logs (UI) now mostly help the user looking at them and not the people who ask for them. The file was the last remaining piece that could easily be shared for support.

Could this be an optional file instead? Of course, when a system is already in trouble, you can’t enable what you can’t reach.
Symlink or some other option would be great

The observer (:4357) could be expanded to be more useful in general, but the reply to that has always been that it lacks authentication .

[Petro31]

I'd be good with anything that allows me to access the file. Even potentially an exposed port that offers a file:\\ url. Anything we can use to tail the file. (possibly as a HA supported & maintained addon)

[timmo001]

Just as a side note, I know its not the what is being requested, but you can tail with ha core logs --follow along with other options in the CLI

➜ ha core logs --help  

Allowing you to look at the log output generated by the Home Assistant Core
running on your Home Assistant system.

Usage:
  ha core logs [flags]

Aliases:
  logs, log, lg

Examples:

  ha core logs

Flags:
  -b, --boot string    Logs of particular boot ID
  -f, --follow         Continuously print new log entries
  -h, --help           help for logs
  -n, --lines uint32   Number of log entries to show
  -v, --verbose        Return logs in verbose format

Global Flags:
      --api-token string   Home Assistant Supervisor API token
      --config string      Optional config file (default is $HOME/.homeassistant.yaml)
      --endpoint string    Endpoint for Home Assistant Supervisor (default is 'supervisor')
      --log-level string   Log level (defaults to Warn)
      --no-progress        Disable the progress spinner
      --raw-json           Output raw JSON from the API

[Mariusthvdb]

tbh, I probably dont need the file size sensor on the log file.
It had its merits though as a sudden increase did set off alarms....

Logviewer however still requires that, so is broken now too? Is that already filed in that add-on, or fix in the making?
no issue yet so wrote it up there hassio-addons/addon-log-viewer#217

[dingedan]

Just as a side note, I know its not the what is being requested, but you can tail with ha core logs --follow along with other options in the CLI

Not for me, I'm running the latest version:

ha core logs --help 

Allowing you to look at the log output generated by the Home Assistant Core
running on your Home Assistant system.

Usage:
  ha core logs [flags]

Aliases:
  logs, log, lg

Examples:

  ha core logs

Flags:
  -h, --help   help for logs

Global Flags:
      --api-token string   Home Assistant Supervisor API token
      --config string      Optional config file (default is $HOME/.homeassistant.yaml)
      --endpoint string    Endpoint for Home Assistant Supervisor (default is 'supervisor')
      --log-level string   Log level (defaults to Warn)
      --no-progress        Disable the progress spinner
      --raw-json           Output raw JSON from the API

edit: nevermind. I did not realize that this feature is built into the ssh addon instead of core. Updating the ssh addon gave me this feature as well.

[Petro31]

while we wait https://github.com/Petro31/a-file-logger

[Petro31]

it rotates the log, it brings back the old behavior, the startup of the logging is delayed.

[tschmeltzer]

I ended up using https://github.com/cw-cdz/addon-log-viewer (a fork of the org log-viewer, that also makes the home-assistant.log)
Might look into breaking the log function out, and just have that alone running as an addon.
wasn't sure if a-file-logger rotated the logs, and thought it might not catch things before everything else was up and running.

Have to be honest i have never looked this deep into how HA works, so its a learning experience for me

[tschmeltzer]

Something is actively deleting the home-assistant.log file, and i cannot figure out why or when.

[Petro31]

The logs are removed when HA restarts. I suggest you just use the integration and be done with it.

[ekutner]

The integration is very helpful and very much appreciated but it misses the initial logging of integrations that load before it, which is very problematic for debugging integration, and probably some HA issues.

[CoMPaTech]

Adding to this - as also mentioned in the #beta channel - the 'enable debug logging' for integrations is broken as well. Regardless of which one you put in debug logging, as soon as the user turns it off and it would proceed to download the file - one get's a 404. This is most likely not the intended change for end-users willing to provide feedback

[CoMPaTech]

To add to this - the 'regular' log doesn't mention any of the potential debug either (expected as much though, but still not convenient)

[Petro31]

These should be written up as issues against the beta

[abmantis]

Yeah, this one seems to be a frontend bug. It seems that it is still using the older log API instead of supervisor's one.

[CoMPaTech]

home-assistant/frontend#27732

[abmantis]

Hey 👋 ! Thanks for the feedback @Petro31 .

So, when this was being developed there were discussions about whether or not to implement some way to keep the file around. In the end, the decision was to not have that because there wasn't a clear use-case that was worth the extra complexity of a new setting or something like that. Most of the use cases we thought of could still be handled without the home-assistant.log file.

But feedback is welcome, and if indeed there is a common use-case that now became impossible, we should consider it.

I think most use cases (other than downloading trough HA) would be covered by ha core logs or journalctl. Alternatively, and addon could be made to pipe from journald to a log file (an integration also works, but would miss the first HA startup logs).

But, as always, nothing is set on stone!

[bacco007]

A bit of an unusual use case for me - I was using the log file to monitor potential issues by tracking the number of WARNING/ERROR messages and the change in size of the file. If they exceeded a defined threshold, I'd get a notification that there might be something up with my setup.

Admittedly, there are probably easier ways to monitor and notify now.

[robharman]

Was there architectural discussion around the difficulty in only streaming logs of a certain level?

Defaulting to off, and burying a setting for log-level where people who rely on things like this would look seems like it would be a relatively straightforward fix given that the logging channels are already established and, I assume, relatively easy to hook into given they're sysloggy. 0

[borpin]

It should be a system option. Leave it to the user. having to 'download' the file is just such a pain. I just have the config folder mapped to my Windows device and I can open it when ever I want. Search, filter etc.

[tomlut]

We've also lost access to the home-assistant.log.1 file (easily accessible logs from before the last restart). This was a vital support resource to help people troubleshoot system instability.

[andrewjswan]

You can do ha core logs -n 99999 > /config/logs_logs_logs.log using the SSH addon

What if there are more messages in the log than 99999?

[CoMPaTech]

If it's down you couldn't SSH into it so having the logfile there or not is not helping you. Also numbering the logfile isn't. A there is your answer ... if you can't SSH (because the add-on fails) you can still see the logs in HA. If HA doesn't start at all you have console, where you still have ha core logs do disect? Don't get me wrong, I loved the logfile, but we shouldn't make it a bigger issue than it is. Especially throwing in things that aren't true - if you can access the system (either console or SSH) you still can ha core logs - or - if on console login and journalctl -n 1000 - and as such none of these are 'user' territory anyways right?

[andrewjswan]

If HA doesn't start at all you have console, where you still have ha core logs do disect?

SAMBA has always provided simple and convenient access to the log file, both locally and remotely. This access is no longer available.

[CoMPaTech]

Now that is something worth mentioning (though invalid for startup - if the box breaks, so does samba) - but not having it on SMB (of NFS) for that matter is something noteworthy 👍

[andrewjswan]

Now that is something worth mentioning (though invalid for startup - if the box breaks, so does samba) - but not having it on SMB (of NFS) for that matter is something noteworthy

This is if it breaks completely, SAMBA works even with a broken Supervisor or a broken Home Assistant, it has been tested repeatedly.

[bugbountyguy]

I've got syslog-ng installed on my system which sends over the logs to my monitoring server, which parses these into charts and grafana which allow me for sending alerts + have nice lifetime historical data. The system I've got setup allows me to dissect issues at the log level and send me alerts for anomalies to handle things immediately. As this log file will now no longer exist, I'm curious how I can manually re-enable it to continue my syslog-ng setup so that I don't lose access to a lot of the automation I have setup on my monitoring server.

Also, just my opinion, but something like this shouldn't be forced on the users. I can see the benefits to it as much as I can see the losses to it. Having something like this should have been an 'option' for people to select. Default it not write the log file if preferred, but give folks the option to enable it if they need or want those logs for any reason.

[CoMPaTech]

@bugbountyguy @hadavies for that specific case I'd reckon the request shouldn't be 'bring back the physical log file' but rather 'feature request configuring remote log receiver' to have journald send it directly instead of both journald writing and another process (syslog-ng) reading the same file :) But I have not yet taken a plunge at looking at how HAOS sets it up, but that could be the most beneficial way.

[hadavies]

I've got syslog-ng installed on my system which sends over the logs to my monitoring server, which parses these into charts and grafana which allow me for sending alerts + have nice lifetime historical data. The system I've got setup allows me to dissect issues at the log level and send me alerts for anomalies to handle things immediately. As this log file will now no longer exist, I'm curious how I can manually re-enable it to continue my syslog-ng setup so that I don't lose access to a lot of the automation I have setup on my monitoring server.

Also, just my opinion, but something like this shouldn't be forced on the users. I can see the benefits to it as much as I can see the losses to it. Having something like this should have been an 'option' for people to select. Default it not write the log file if preferred, but give folks the option to enable it if they need or want those logs for any reason.

Completely agree, this should be a choice, because the intention behind it is great but not all use cases have been understood.

What do you use for your log aggregation?

[bugbountyguy]

It's a personal python script/app I wrote years ago to handle all the various types of logs I get across the network. It's a bit dated and may be something I can finally replace these days, but it was at a time when some devices just didn't work with sending json payloads through syslog-ng and required some special parsing that I wanted... I think I should be able to convert that at the server side these days. Data's then all stored into a MySQL database which I run through Grafana for dashboards and metrics.

[LGO44]

A very nice tool, very easy to use, used by many people
Why has it been suppressed? In this flow we can try to find a work around.
It's an add-on , each one is responsible for its use...

[AndersRipa]

Please bring back the log files!
Log files should be readable/accessible without HA up and running!

[AndersRipa]

As of this release, we’ve stopped writing logs to the configuration folder. You can still view and download all logs from the Home Assistant settings page, just like before. We’ve adapted that page to read the logs from the OS directly instead.

Since the logs still are written to disk, how do I read them from a system that does not start?
E.g. from the file system.
What is the format?
What tools are needed?
What is the path to the logs?

Installing something before the crash defeats the purpose of having logs! So that's not really a valid option

[pergolafabio]

As of this release, we’ve stopped writing logs to the configuration folder. You can still view and download all logs from the Home Assistant settings page, just like before. We’ve adapted that page to read the logs from the OS directly instead.

Since the logs still are written to disk, how do I read them from a system that does not start? E.g. from the file system. What is the format? What tools are needed? What is the path to the logs?

Installing something before the crash defeats the purpose of having logs! So that's not really a valid option

Exactly, even the rotation log file is gone.
Please give us log back , or make it an user option at least!

[CoMPaTech]

It's still there ha core log from console :)

[andrewjswan]

It's still there ha core log from console :)

It can't provide a log file for the current Home Assistant startup; it only displays the last couple of lines or all the garbage it has...

[EDelsman]

I have no clue how to get logs from a HAOS that is down. And I guess that applies to 90% of all users.

SSH into it? Isn't that impossible without an addon? This feels like a car that can only open the hood if the engine is running.

Who from those who thought it wise to remove the functionality can we refer all users to to help them out? I won't be able to.

My HA is in a closet, I cannot get it to a monitor and keyboard without unplugging it, ethernet and three usb extension cords with z-wave, zigbee and thread adapters. All my monitors are attached to monitor arms, stuck to a desk. So whatever I can get straight from the console is not what caused HA to crash?

[CoMPaTech]

As replied above to a thread - 'users' wouldn't even know what to do either way - you'd have to tell 'm to "more" or "less" home-assistant.log - which they still can using ha core log. So the user isn't affected, the experienced user might be, but even those can still use that command (or go die-hard and console login to tinker with journald)

[robharman]

Telling a user that they wouldn't know what to do with the tool they're complaining you broke isn't a great approach. Likewise, telling they can do half of what they used to do with twice the effort is not a great way to sell the feature.

ha core log is useful for half of what viewing the log file was, but it's useless for troubleshooting across time, and (as multiple people (HA users) have noted above) for troubleshooting issues where you lack access to the console or the GUI. Such as headless installs in hard to reach places, VMs on headless systems, or for tools which rely on a log to help diagnose issues, which are basically the most primitive and fundamental tool there is for debugging.

Log files always do the same thing, they have repeatable behaviour across tools, they're easy to integrate, they're dead simple to understand. Removing them is the best way to make fixing problems harder. I can pull an SD card from a system and read the log files on a working computer, there's no way to do anything close to that with ha core log, or any of the other proposed workarounds to the removal of the log file .

Spammy log entries are a solved problem, because they're a user preference problem not a system problem. The log entries are already classified into info/debug/error, deciding that none of that should be written to disk is a decision that is going to make debugging everything harder in the long run.

[CoMPaTech]

Hi @robharman - let's clear the air first, I'm at loss as well as I depicted in earlier replies (and even commented on proper communication and handling in the PR). While we all would agree 'having it twice ain't nice' there is considerable impact. Back to the statements I made, some people feel 'how can I help the user' is a thing => that's why I replied on that kind of users. Non-domestic power-users (you, the responders above and me among them) have different needs. Do note that we could enable the 'I know what I'm doing' button on something like the SSH/Terminal add-on and log straight into HAOS and do whatever we want there.

You indicate that executing the log command doesn't work - but how would you even reach (besides the very valid https://github.com/orgs/home-assistant/discussions/1527#discussioncomment-14896239 use-case) said log without it? Also note that you can The SD card is one we can safely chalk up there with SMB and NFS, good point!

On your last comment, they are not 'not' written to disk - just not twice and unfortunately less easy to reach. As said, I also rather 'have it' but there is a lack of options (even with Petro's custom_component). I sincerely hope someone comes up with a clever 'expose' like properly exposing journald and/or remotely syslog-ging thereof but that will require changes to HAOS.

[pergolafabio]

still , i hope can consider you bring the log file back , i always opened it with notepad using smb addon, was extreme usefull when for instance HA itself wouldnt start a while ago
Or make it at least an configurable option to create .log files, let the user decide if they want it or not....

[andrewjswan]

which they still can using ha core log

How do I get the log for the current session? Like in home-assistant.log?
And how do I get the log for the previous session? Like in home-assistant.log.1?

[CoMPaTech]

Let's compile a list of things that the community wants a solution on, without focussing on what's lost or what can be achieved with ha core logs or Petro's custom_component (though some/most might be able with it):

• Filesharing (samba/nfs) @andrewjswan comment
• Inspecting the physical/virtual media @robharman comment
• Access previous/last session log in addition to only the current (i.e. .1 file) @andrewjswan comment
• Log viewer add-on @Mariusthvdb GH issue
• Log tail sensor? @Mariusthvdb comment
• Log period/rotation? Presumably journald cleans after itself where previously the whole 'since start' log was available @andrewjswan comment
• Rapid log growth indication (or similar situation) (i.e. like file size sensor but for other purposes) @MankiniChykan comment
• Ability to see 'since started' has also vanished @andrewjswan @CoMPaTech comment as you can't request beyond Uint number of lines - understandably with log rotation but still start issues could be relevant?

In his reply abmantis already indicated use-cases help get a other/proper route (https://github.com/orgs/home-assistant/discussions/1527#discussioncomment-14831724)

[andrewjswan]

access the current (with limitations) through the logs command

We currently have access to all log entries for the entire storage period, without breaking them down into current, previous, or previous week. Or, if there are a lot of errors, we don't have access to the full log for the current session (I understand there's a limit on the number of entries).

[MankiniChykan]

file size sensor

I second the file size sensor for the log file. It is a good indicator for when things are going astray. (Rapidly increasing there is a problem)

[MankiniChykan]

Thanks for adding so quickly @CoMPaTech

[MankiniChykan]

Does resetting HA now clear the log like it did previously?

[CoMPaTech]

Does resetting HA now clear the log like it did previously?

Tested on and with a couple of nines it still produces Oct 26 (even after restarting either core or the VM)

[pergolafabio]

if i do "ha core logs" , i get below, whats that for garbage? completely useless ??

[Mariusthvdb]

Tbh, that has been in de logs before opening the log from within the Ui

[frenck]

if i do "ha core logs" , i get below, whats that for garbage? completely useless ??

So... we collaborate in this environment. Just saying that the tone could be slightly different in your response there.

Anyway, this is a feature request, not an issue tracker. If you are experiencing an issue, I would recommend to raise on in the CLI issue tracker so it can be looked at.

Thanks! 👍

../Frenck

[hovant]

Luckily I haven't upgraded to 2025.11 version yet and I will skip it and wait for a version which has the logfile feature back there as it used to be. The logfile in the config folder is the most important debugging feature for custom integration developer. It is must to have.

[LupinIII]

This change just cost me an hour to first find out what happened to the logs and why they are missing. And I don't know how many more hours it will cost me, because the update to 2025.11 broke two of my scripts AND all of my usual workflow methods to fix them.

• I did access the log files via Samba
• I did tail the log file while debugging
• I did check older log files to see if a problem already existed in the past and I just missed it
• I did grep the log file for known strings
• I did check the date and/or size of the log file to see when the last entry happened or how fast it grows

Non of this is possible now (or at least needs a workaround that I have to find out first). Since when is the solution to too many log writes to remove the log file?
I've been setting up and administering systems for decades and simple (not just easy) log file access is essential.

[dabbler68]

Another voice to say removal of the logfile was a bad idea.

I have an automation that notifies me if the number of entries in the logfile are growing unexpectedly. If the numbers reach the next threshold it will wake me up. So rather than spend time sorting out a different solution I have restored back to 2025.10.

I also use the logfile when developing automations or until they are proven by writing debug information. Such a simple task and then browse through each time it has run. Traces function only does 5 executions.

My routine each day is a glance at the logfile pretty much first thing ... 'anything unexpected?'. Nicely colour coded information instantly viewable. Thanks to Petro31 for being so quick with a solution. I will be using that when the time comes to revisit a core update if it has not been restored by then.

[Kilmanagh]

This is the most frustrating change in a long time. I remember when Plex started out where users could tweak their servers to meet their needs and as it got popular, developers decided to dictate what is best for us without any choices.
The is huge step in that direction. If they keep alienating massive groups of users, a "Jellyfin" for HA is going to be on the horizon.

[8bitben]

Running a mix of native and HACS components, the log file (via Log Viewer) was my first stop to investigate any issues, and I saved many hours by having a quick reference.

I can understand the desire to make HA more reliable for some setups by removing this write-heavy option, but the cost of removing observability is significant, and maybe more than was contemplated when making this change.

I think leaving the log file as an option for advanced users (and/or adding other observability utilities) would be really beneficial for those of us that really need it.

[HelixX23]

yes, i totally agree. But how to help non advanced user who have crashed their system without logs turned on by default.
they will be lost and nobody in the community can help them!
I would recommend to turn off logs by default on a sd card driven system... this should increase the livetime of that sd card ...
(by the way, running HA on a sd card is also not having a long life even if turning logs off)

[pergolafabio]

I never download a log from from the UI, now we are forced todo it, but i see the log spammed with below example, i never saw it in the old log file, what is that? i also dont see it in the UI, only if i download the file, also tried Petro his custom, i dont see it in the log file then either?

what is that?

E0000 00:00:1764670538.303026      68 alts_credentials.cc:93] ALTS creds ignored. Not running on GCP and untrusted ALTS is not enabled.
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100  4675  100  4675    0     0   711k      0 --:--:-- --:--:-- --:--:--  913k
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100  4675  100  4675    0     0   764k      0 --:--:-- --:--:-- --:--:--  913k
E0000 00:00:1764670619.616669      68 alts_credentials.cc:93] ALTS creds ignored. Not running on GCP and untrusted ALTS is not enabled.
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100  4675  100  4675    0     0   815k      0 --:--:-- --:--:-- --:--:--  913k
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100  4675  100  4675    0     0   747k      0 --:--:-- --:--:-- --:--:--  913k
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100  4675  100  4675    0     0   794k      0 --:--:-- --:--:-- --:--:--  913k
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100  4675  100  4675    0     0   580k      0 --:--:-- --:--:-- --:--:--  652k
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100  4675  100  4675    0     0   680k      0 --:--:-- --:--:-- --:--:--  760k
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100  4675  100  4675    0     0   771k      0 --:--:-- --:--:-- --:--:--  913k

[CoMPaTech]

For people later to this longer thread; see the comment on the PR here https://github.com/orgs/home-assistant/discussions/1527#discussioncomment-14831724 or my suggested list of users chiming their alternatives https://github.com/orgs/home-assistant/discussions/1527#discussioncomment-14899460 Happy to add new ideas to the list if you have them (but I've not seen newer ideas, though one never knows if someone has another lightbulb moment).

For those impatient for (or if) any changes you can use Petro's workaround https://github.com/orgs/home-assistant/discussions/1527#discussioncomment-14829700

[pergolafabio]

For people later to this longer thread; see the comment on the PR here https://github.com/orgs/home-assistant/discussions/1527#discussioncomment-14831724 or my suggested list of users chiming their alternatives https://github.com/orgs/home-assistant/discussions/1527#discussioncomment-14899460 Happy to add new ideas to the list if you have them (but I've not seen newer ideas, though one never knows if someone has another lightbulb moment).

There is only 1 option, revert the change, there were no people complaining, we don't need add-ons or fancy commands or UI , we just need the file like it was

[CoMPaTech]

There are multiple, I've amended to add Petro's comment

[Petro31]

Can you please stop spamming this FR with AI crap?

The custom integration I wrote literally brings back the log to file functionality exactly the way it was before. The only difference is that it loads through the custom integration process, which means it loads some time later than it used to. There are no other differences.

[HelixX23]

the braking change was made here
home-assistant/core@07da0cf

[pergolafabio]

@Petro31 can you give me your 24/7 telephone number, so if there is a problem with my system not booting i can call you to fix it for me? i already have had so many headaches with HA in the past running forst on RPi SD Card, then on IntelNUC now on Proxmox. i dont want to be forced into a corner because someone removed my logfiles because of nothing.

Just stop with that AI shit and pointing to breaking changes links, we are aware of that

[CoMPaTech]

That is really uncalled for Helix, we get you are upset, you are not alone. Petro created a workaround (how nice of him to do that, right?).

[Petro31]

yes, how nice for him to do that in advance of the braking change. somehow he knew this will blow up quickly

the community made so many suggestions in doing it right. for example catching the sd card installations and turning log files off only on them... but now we are all affected

and yes, so "shit" that an AI can find the spot where it fails and quickly can produce patches for it

I made the integration because I was upset that the log file was removed. I found out during beta and made it because I knew how to get the log file back. I did not make the change that removed the log file, so don't direct your nastiness in my direction. Grow up.

[frenck]

Hey everyone 👋

First off, thank you to everyone who took the time to share their use cases and workflows. This kind of detailed feedback is genuinely valuable and helps us understand how people actually use Home Assistant in ways we might not have anticipated.

I want to let you know that we hear you, and we're actively exploring options. Nothing concrete to announce just yet, but the feedback in this thread (and the well-documented use cases) is being taken seriously.

That said, I do want to take a moment to talk about something else I noticed in this thread.
We're all here because we care about Home Assistant. The people who contributed the original change care. The people who are frustrated by it care. The maintainers responding care. We're all working toward the same goal: making Home Assistant better for everyone.

Open source thrives on collaboration, and that means we iterate together. Sometimes changes don't land perfectly the first time, or pan out to kill others use cases. That's okay. That's part of the process. What matters is that we can have constructive conversations about it and find solutions together.

What doesn't help is when frustration turns into dismissiveness, assumptions about intent, or responses that shut down dialogue rather than open it up. I've seen some of that in this thread, and I'd like to gently remind everyone that we can disagree, we can be frustrated, we can advocate strongly for our needs, all while still treating each other with respect.

We're a community. Let's act like one.

More updates to come as we work through the options. In the meantime, thanks for your patience and for continuing to help make Home Assistant what it is.

../Frenck

                       

Blogging my personal ramblings at frenck.dev

[tschmeltzer]

Does that mean it will be rolled back untill a better solution is found? or do we have to wait an arbitrary amount of time for a solution?

[frenck]

No, we are not rolling back, at least, that isn't directly the goal. We are looking for how we can provide the option for people like yourself to have their use cases restored. Nothing in my above response said anything about rolling back. Can I highlight the "assumptions about intent" once more? 😉

Anyway, repeating the above just to make sure it came across: we're actively exploring options.

../Frenck