I found another issue.
When I select the prepared question “What has changed since the previous scan?” and click Analyse Report, the request fails with an Internal Server Error (HTTP 500).
This looks like a backend exception rather than a routing issue, because the application returns a server error before producing any diagnostic result.
It might be worth checking the Flask/container logs for the stack trace.
I found the cause of the HTTP 500.
The prepared question “What has changed since the previous scan?” consistently crashes in the Report Comparison Layer.
The traceback shows:
AttributeError: 'dict' object has no attribute 'splitlines'
at
app/brain/layers/report_comparison.py
Specifically:
_count_lines(value)
where value is a dictionary instead of a string.
_count_lines() currently assumes every report section supports .splitlines(), but at least one section now returns structured data.
The comparison layer probably needs to handle dictionaries (or other structured types) before calling _count_lines().
Everything else is working fine. The crash only occurs when asking “What has changed since the previous scan?”, so this looks like a regression introduced by the new report comparison layer.
@isanto1306, thank you again. Both issues you identified have now been fixed.
“Are there any critical risks?” now routes to the Comprehensive System Health Layer. It separates verified critical risks, attention-level findings and informational observations. If no finding meets the critical threshold, it clearly reports that no critical risks were verified.
The prepared question “What has changed since the previous scan?” no longer produces an HTTP 500. The comparison code now safely handles structured report sections, and the question routes to the Health Timeline and Local Memory Layer for an evidence-based scan comparison.
During live testing, I also corrected several related report-quality issues:
I tested both questions directly on my ZimaCube. All focused regressions, the comprehensive health suite and the full 33-question regression passed, with no backend errors.
The updated image has been published under the existing tag:
gelbuilding/zimabrain-ce:1.6.0-beta
Thank you for finding these issues and including the traceback. That made the comparison failure much quicker to isolate and correct.
I also tested ZimaOS 1.7.0. It works, but I decided to roll back to 1.6.2 for now.
Personally, I think the beta phase for ZimaOS should last a little longer. In my opinion, it goes from Beta 1 and Beta 2 to a stable release too quickly. The community is still relatively small, so it’s difficult to catch all the issues in such a short testing period.
A slightly longer beta cycle would probably allow more real-world testing and help identify additional edge cases before the final release.
That’s just my personal opinion, but overall I’m very impressed with the progress of both ZimaBrain and ZimaOS.
Everything looks really good now. I’m genuinely impressed by how much ZimaBrain has improved.
I only have one small suggestion after looking at the latest dashboard.
In the Container / Service Alerts section, all intentionally or potentially intentionally stopped containers are still listed as “YELLOW: Container/service may need attention.”
Since ZimaBrain explicitly states that it cannot verify whether the container is intentionally stopped, I think the wording could be a little softer. Otherwise it looks like there are many problems even though they may simply be inactive by design.
Maybe something like:
Stopped container detected (intent not verified)
Container is exited; intention could not be verified
Review if this container is expected to be inactive
This would better reflect the evidence-first philosophy and reduce unnecessary alarm.
Apart from that, I’m really impressed with how far ZimaBrain has come.
One more thing: I’d also like to apologise for bringing up my experience with the ZimaOS 1.7.0 update here. The ZimaBrain thread probably isn’t the right place to discuss ZimaOS releases. I’ll keep any future feedback about ZimaOS in the appropriate forum instead.
I found another routing gap.
I asked:
“Why did my NAS restart?”
At the moment, ZimaBrain routes this to Containers and applications, but I think the user’s intent is clearly about the host system, not a container.
This is a very natural question after an unexpected reboot. Users want to know why the NAS itself restarted, for example:
Was there a power outage?
Was there an unexpected shutdown?
Was the reboot triggered by a ZimaOS/RAUC update?
Was there a kernel panic?
Was the reboot manually initiated?
Is there any evidence in the available logs?
If the available evidence cannot determine the cause, ZimaBrain should simply say so, for example:
“The NAS reboot was verified, but the available evidence cannot determine the exact cause. No evidence of a kernel panic, update-triggered reboot, or unexpected power loss was found.”
I think this would fit the evidence-first philosophy much better than routing the question to container diagnostics.
I have another idea that could make ZimaBrain much more useful for diagnosing system problems.
Right now, ZimaBrain analyses the current state of the system. The problem is that if the NAS becomes unresponsive and I have to reboot it, most of the important runtime information is already gone.
For example, I previously experienced a situation where the system suddenly became overloaded after I renamed or moved a file. CPU and RAM eventually reached 100%, the NAS became almost unusable, and I had to reboot it. After the reboot, there was no way to determine what had actually caused the overload.
I think ZimaBrain would benefit from a lightweight background monitoring/history feature. It doesn’t need to log everything every second, but it should keep a small rolling history of important system information, such as:
CPU usage
Memory usage
Disk I/O
Top CPU and memory-consuming processes
Running containers
OOM killer events
Important filesystem events
Then, if the system has to be rebooted, ZimaBrain could answer questions like:
Why did my NAS become unresponsive?
Why did CPU and RAM reach 100%?
What was running before the reboot?
Instead of only analysing the current state, it could explain what happened before the reboot.
I think this would be one of the most valuable troubleshooting features because many performance problems disappear as soon as the system is restarted. Without some historical data, it’s often impossible to determine the real cause afterwards.
I have now implemented both of your suggestions. Thank you for raising them.
“Why did my NAS restart?” is now routed to a dedicated Host Restart and Incident History layer instead of Containers and Applications.
ZimaBrain now checks for:
Host boot-ID changes
Kernel panic evidence
OOM events
ZimaOS/RAUC update reboot markers
Manual reboot markers
Clean shutdown evidence
Possible abrupt shutdown or power loss
It remains evidence-first. If the exact cause cannot be proven, it will clearly say that instead of guessing.
I also added a lightweight background monitor with a seven-day rolling history. It records CPU, memory, swap, disk I/O, top processes, container states, filesystem and mount changes, and important system events.
The new Incident History dashboard provides 24-hour, 3-day and 7-day views, including charts, top processes, container state, boot evidence and an event timeline.
ZimaBrain can now answer:
Why did my NAS become unresponsive?
Why did CPU and RAM reach 100%?
What was running before the reboot?
Monitoring starts after the feature is installed, so it cannot recover information that was already lost during an earlier reboot. However, it will now retain evidence for future incidents.
There are also two honest limitations:
A power outage cannot normally be proven without UPS or hardware evidence. ZimaBrain reports an abrupt shutdown as possible when no clean-shutdown marker exists.
It does not record every file rename or move because that would be noisy and privacy-heavy. However, it records the resulting CPU, memory, disk-I/O and process activity, together with filesystem errors and mount changes.
Previous-boot journal analysis also depends on ZimaOS retaining its journal across reboots. When that evidence is unavailable, ZimaBrain clearly says so rather than guessing.
I have attached a screenshot of the new dashboard. I believe this makes ZimaBrain much more useful for diagnosing problems that disappear after restarting the NAS.
The updated ZimaBrain image is now published and available from Docker Hub:
gelbuilding/zimabrain-ce:1.6.0-beta
If you already installed ZimaBrain using Docker Compose, open the directory containing your docker-compose.yml and run:
docker compose pull zimabrain-ce
Then recreate the container using the new image:
docker compose up -d --no-deps --force-recreate zimabrain-ce
Your existing ZimaBrain data and monitoring history will remain in the configured /DATA/AppData storage path.
You can confirm the container is running with:
docker compose ps
Then refresh the ZimaBrain page. The new Incident History panel should appear in the interface.
I had already uninstalled ZimaBrain CE from my system. I’ll reinstall it and test what you’ve implemented as soon as I get a chance.
Hi gelbuilding,
I reinstalled ZimaBrain CE and tested the three new Incident History questions:
“Why did my NAS restart?”
“Why did my NAS become unresponsive?”
“What was running before the reboot?”
The new Host Restart and Incident History layer is working. ZimaBrain correctly detected the host boot transition and checked for kernel panic, OOM events, update-triggered reboots, manual reboot markers and orderly shutdown evidence. It also correctly avoided guessing when the exact cause could not be verified.
As expected after a fresh installation, there are currently no rolling performance samples from before the previous reboot, so CPU, memory, disk I/O, processes and container states from that earlier boot cannot be recovered.
I’ll leave the background monitor running now. If another reboot or system issue occurs in the future, there should be enough recorded history to properly test the new incident analysis.
One small observation: all three questions currently return almost the same answer. This is understandable with no previous monitoring data available yet, so I think the more meaningful test will be after the monitor has collected data and a future reboot or incident occurs.
Thanks for implementing the suggestions.