i have 2 problems with the new Network Storage Feature.
HA can not read the files.
I add my fritz.nas as samba share two times, as type media and different folder as backup type.
On Backup: the system make the backup and store it on my nas. but the name isn’t the name i give them (insert test as backup name on UI, but filename is a225607f.tar) but bigger problem is, that i can’t see this backup on the HA.
Same on the media source. I test it using the HA media browser UI to upload a image. It is correctly saved, i can open it on my nas ui, but when i try to open it on HA media browser, the picture is not shown. It shows only the filename with a “brocken image”-Symbol. Same for lovlace gallery card, shows me only the filenames.
It seems that there is a problem with reading the files in ha for both type of connections: backup and media.
Any Ideas?
No matter how you name it, that is the filename, always been, always will be.
As for your other problem, that really sounds like permission issues.
Check your configuration / user on that share server.
Just to give you an idea of what is exposed so far. There are apparently other commands available via service calls but they are undocumented. No map yet but you can do a service call to start cleaning certain rooms as shown in the docs. Tested and working.
Has anyone come across a
InsecureRequestWarning: Unverified HTTPS request is being made to host 'xxx.xx.....
in the logs?
Its intergrations to Unifi and Proxmox that are throwing these. These are both local and don’t have certificates but to date hasn’t been an issue. The full detail is:
2023-06-08 12:02:44.211 WARNING (SyncWorker_7) [py.warnings] /usr/local/lib/python3.11/site-packages/urllib3/connectionpool.py:1056: InsecureRequestWarning: Unverified HTTPS request is being made to host '192.168.0.20'. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.io/en/1.26.x/advanced-usage.html#ssl-warnings warnings.warn(
Technically correct that these are unverified HTTPS requests (I think - not too techie) but to date wasn’t an issue and now is. It’s slowly filling my logs up which I work hard to keep clean and correct. Any pointers or suggests would be gratefully received before I dig too deep into a rabbit hole!
Other than that another exciting release - thank you!
Wow!!! What a help!
You can write it under almost any bug report!
Integration works perfect in 2023.5 and i have to report it here. I works perfect after I restore 2023.5 backup also.
I post it here because it will probably effect most of custom integrations
We have to know which change is causing this! It is like an import error on the HA start
I noticed this Installing Home Assistant OS using Proxmox 7 - #997 by Routout (although it relates to a custom component)
OK, so the “check configuration” tool for me is taking an age, and never seems to complete
I have to restart via CLI to get it to restart, there are no errors recorded when it comes back up. anyone else ?
It only affects custom integrations that have ignored deprecation warnings for many (many) years.
https://docs.python.org/3.8/library/asyncio-task.html#asyncio.coroutine
I am seeing this too, but it does eventually (after about 10 minutes) complete, telling me:
Platform error device_tracker.bluetooth_tracker - Requirements for bluetooth_tracker not found: ['pybluez==0.22'].
Do you have the Bluetooth Tracker platform enabled in your configuration.yaml? When I remove this from my configuration.yaml, it completes almost instantly (as before upgrading).
Does anyone know if there is there a breaking change for the Bluetooth Tracker platform that has not been listed?
If someone is expecting this to work on a supervised installation because of this comment: Nope, this feature currently seems to be available for HASSOS only.
And yes, on a core / supervised install there are other ways to achieve the same result (a bit less comfortable), thus this feature isn’t really missed.
TBH, you don’t need it for supervised on Debian. You can just do a normal mount, that’s what I do.
wow, yes you’re correct. I get the same error. Disabling my device trackers config allows the checker to run properly
Noted here
Since 2023.6 i see a processor usage that climbing slightly to the 100%.
From 8-9% after de update this morning now 58%.
Will this happen because of all kind of background actions of the new version?
EDIT: After a full reboot of the system itself it seems to be ok now. CPU now use 9%
Has anyone got Command Line working at all ? Everything I try throws an error
#command_line:
sensor:
- name: CPU Temperature
command: "cat /sys/class/thermal/thermal_zone0/temp"
unit_of_measurement: "°C"
value_template: '{{ value | multiply(0.001) | round(1) }}'
- name: CPU Speed
command: "cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq"
unit_of_measurement: " Mhz"
value_template: '{{ value | multiply(0.001) | round(0) }}'
scan_interval: 10
I have a related question. Right now, I have a template sensor and automation to a) count the number of persistent notifications at any given time and b) forward them as push notifications to my phone. If I understand this change correctly, it sounds like I will be losing both of those abilities, so I’m also interested in any possible workarounds.
- sensor:
name: CPU Temperature
command: "cat /sys/class/thermal/thermal_zone0/temp"
unit_of_measurement: "°C"
value_template: '{{ value | multiply(0.001) | round(1) }}'
- sensor:
name: CPU Speed
command: "cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq"
unit_of_measurement: " Mhz"
value_template: '{{ value | multiply(0.001) | round(0) }}'
scan_interval: 10
had same issue this how it will work
No it is available for supervised too. Install the latest supervised deb file (and possibly you need the latest os-agent too.
the user settings are ok. if i login on my nas with this user, i can read all the files. And there is only a read/write setting for the user on my nas. HA can read the filenames, but maybe not the content.
This is the error log:
2023-06-08 14:37:26.491 ERROR (MainThread) [aiohttp.server] Unhandled exception
Traceback (most recent call last):
File "/usr/local/lib/python3.11/site-packages/aiohttp/web_protocol.py", line 512, in start
resp, reset = await task
^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/aiohttp/web_protocol.py", line 458, in _handle_request
reset = await self.finish_response(request, resp, start_time)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/aiohttp/web_protocol.py", line 611, in finish_response
await prepare_meth(request)
File "/usr/local/lib/python3.11/site-packages/aiohttp/web_fileresponse.py", line 279, in prepare
fobj = await loop.run_in_executor(None, filepath.open, "rb")
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/concurrent/futures/thread.py", line 58, in run
result = self.fn(*self.args, **self.kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/pathlib.py", line 1044, in open
return io.open(self, mode, buffering, encoding, errors, newline)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
OSError: [Errno 116] Stale file handle: '/media/fritz_medien/IMG-20230508-WA0006.jpg'
Thanks all - a very smooth release for me. Just one broken integration, but as I am the maintainer and had probably made the screw-up in the first place, I guess I’ll need to create an angry post ranting about how inept I am 
(In fact, it was fixed last week when another beta tester made me aware of it so no big dramas.)
Loving the new features. Congratulations to the team 