Is it just me but on the Maps dashboard it seems to have stopped showing the way points as I move along. It shows the current position(GPS Co=ordinates) but since upgrade doesnt show the tracks of how you got to a location (i.e. the blue dots and lines) . If I change the history from 48 hours to something like 120 hours the old tracks appear which tends to suggest the interim points arent being logged?/
lcsneil
Here are the logs.
I can execute the command manually in a terminal window and it works.
But after restart, after the Core 2024.7 install. these sensors in configuration.yaml fail to execute.
Logger: homeassistant.components.command_line.utils
Source: components/command_line/utils.py:56
integration: Command Line (documentation, issues)
First occurred: 7:39:42 AM (499 occurrences)
Last logged: 7:53:53 AM
Command failed (with return code 1): OPENSSL_CONF=/config/xcelcerts/myown/openssl.cnf /usr/bin/curl --ciphers ECDHE-ECDSA-AES128-CCM8 --insecure --url https://10.0.0.226:8081/upt/1/mr/3/r --cert /config/xcelcerts/myown/cert.pem --key /config/xcelcerts/myown/key.pem 2>&1 | grep -o '<value>.*</value>' | grep -Eo '[0-9]+'
Command failed (with return code 1): OPENSSL_CONF=/config/xcelcerts/myown/openssl.cnf /usr/bin/curl --ciphers ECDHE-ECDSA-AES128-CCM8 --insecure --url https://10.0.0.226:8081/upt/1/mr/1/r --cert /config/xcelcerts/myown/cert.pem --key /config/xcelcerts/myown/key.pem 2>&1 | grep -o '<value>.*</value>' | grep -Eo '([+-]?[0-9]+)'
Command failed (with return code 1): OPENSSL_CONF=/config/xcelcerts/myown/openssl.cnf /usr/bin/curl --ciphers ECDHE-ECDSA-AES128-CCM8 --insecure --url https://10.0.0.226:8081/upt/1/mr/2/r --cert /config/xcelcerts/myown/cert.pem --key /config/xcelcerts/myown/key.pem 2>&1 | grep -o '<value>.*</value>' | grep -Eo '[0-9]+'
I’m seeing the exact same issue with command_line and my xcel smart meter. Added info to a very similar sounding github issue that also started with 2024.7.1: Command line switch stopped to work after update (USB Relay) · Issue #119915 · home-assistant/core · GitHub
But that doesn’t make sense for other languages. For example, in Dutch you would never replace “ü” with (EDIT: “u”) “ue”. To me, it makes more sense to just replace special characters with their “base” form (ü → u; é → e; ñ → n; ç → c?) and consider the entity ID as a “computer-readable” ID that isn’t necessarily correct in the original language. Although even that is hard: what will you do with Chinese characters?
I’m not certain, but I think the map track/way-points not being logged, is connected to the ‘recorder’ issue discussed in other parts of this thread.
Not sure what you meant, but in German you would also never replace “ü” with “u”. That is what i wrote. And by the way, there are system settings with language settings. They could be used for translating.
I found this topic important, because “Küchen” translated from Home Assistant to “Kuchen” is in german something complete different. It means in englisch a cake and not the kitchen like before.
Just FYI, hitting an issue with the UniFi Protect platform on 2024.7.2:
7.1 broke the energy panel cant see history
7.2 the gui loads on the app but in the web gui it unusable slow loading
radio-browser seems to be broken. it was stuttering on release 2024.7.0, Then got worse with 7.1 and started throwing an error about quick_play. Now the log fires the quick_play error on every call. DNLA server works, but none of my radio-browser buttons work any longer. I tried to roll back to a 6.4, but lost too much history, so moving back to 7.1 as soon as the tables are rebuilt. I will post a sample log after.
Logger: homeassistant.components.websocket_api.http.connection
Source: components/websocket_api/commands.py:241
integration: Home Assistant WebSocket API (documentation, issues)
First occurred: 6:03:57 PM (2 occurrences)
Last logged: 6:04:00 PM
[547716138176] Unexpected exception
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/cast/media_player.py", line 100, in wrapper
return_value = func(self, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/cast/media_player.py", line 508, in _quick_play
quick_play(self._get_chromecast(), app_name, data)
File "/usr/local/lib/python3.12/site-packages/pychromecast/quick_play.py", line 97, in quick_play
controller.quick_play(**data, timeout=timeout)
File "/usr/local/lib/python3.12/site-packages/pychromecast/controllers/media.py", line 559, in quick_play
response_handler.wait_response()
File "/usr/local/lib/python3.12/site-packages/pychromecast/response_handler.py", line 54, in wait_response
raise RequestTimeout(self._request, self._timeout)
pychromecast.error.RequestTimeout: Execution of quick play http://playerservices.streamtheworld.com/api/livestream-redirect/KKJZFMAAC.aac timed out after 30.0 s.
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 241, in handle_call_service
response = await hass.services.async_call(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/core.py", line 2731, in async_call
response_data = await coro
^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/core.py", line 2774, in _execute_service
return await target(service_call)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 999, in entity_service_call
single_response = await _handle_entity_call(
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 1071, in _handle_entity_call
result = await task
^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/cast/media_player.py", line 777, in async_play_media
await self.hass.async_add_executor_job(
File "/usr/local/lib/python3.12/concurrent/futures/thread.py", line 58, in run
result = self.fn(*self.args, **self.kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/cast/media_player.py", line 102, in wrapper
raise HomeAssistantError(
homeassistant.exceptions.HomeAssistantError: CastMediaPlayerEntity._quick_play Failed: Execution of quick play http://playerservices.streamtheworld.com/api/livestream-redirect/KKJZFMAAC.aac timed out after 30.0 s.
Starting to look like it is something to do with radio-browser to the cast integration… I can listen to radio-browser from the media navigation item in the browser as soon as I change the cast to my AVR it errors and states “nothing playing.”
So happy to see home area in the UI.
It will be even better when we can draw a box for the boundaries. In the US, anyway, our properties are usually a rectangle or at least a polygon. In my case it is 4 times as long on two sides as it is on the other two. I enjoy walking around and …
Anyway - July is best update in a long while by my opinion. Great stuff
now apart from the issues I have with the recorder since 2024.7 I am also having issues with my Places integration since 2024.7.2
This is getting really dramatic if you ask me… I have never had big issues like this in years and now multiple things are breaking down with this latest release (including HA stuff itself like the recorder…)
Both those issues are related. If you’d read the rest of the thread, you would have known that places is one of three third party integrations which caused the recorder issue. Let me make it easy for you: this thread explains everything, including a post by frenck where he submitted a fix for places which is waiting to be released.
To be fair I do also share the opinion this release has been particularly problematic - qbitorrent has an issue opened (by me and now confirmed by another) as well for example. I’m trying each new version (I’m doing my part!) of course but I’m not yet willing to move to .7 so am reverting once I’ve tested to my satisfaction.
Glad to see the recorder issue has been moved up to this cycle and not just for .8.
It does seem that way. I have yet to try it as I’m very worried about trying it. HA is at the core of managing my home. I hope the developers are learning from this and are putting processes in place to avoid a repeat. It’s hard to imagine how this was tested sufficiently.
Did it work ok for you in beta?
In my old programming days, beta testing was done in house. We’d have various setups representing likely configurations. We never asked our clients to do beta testing for us. My HA system is very much a live system. If I were to do some beta testing on my live system, I could suffer from it, potentially costing me money and serious inconvenience. I’m afraid I’m not prepared to risk that.
Ok, sorry to suggest you might be inconvenienced by development, or by helping. Silly me.
Yadiyadiyadiya! Comments like yours are about as useful as an ashtray on a motorbike! I have made clear why being a beta tester is, in my opinion and for my situation, not appropriate. A bit of understanding of my situation, which I imagine is far from unique, might actually help to find a better way of testing releases.
Remember many of the developers are full time paid employees. The number of employees seems to have increased recently. Maybe having a dedicated test team would be a way forward.
If HA is not to be relied on as a production-level product, we should be told so we can go and find a more suitable alternative.