I wonder why ASUSWRT cannot be managed via configuration.yaml anymore?
This is a very big inconvenience for me.
I prefer to manage settings via yaml…
I’m successfully running core-2021.3.2, attempted to upgrade to core-2021.3.3 but I got this error when adjusting the temp on my zwave go control thermostat.
I had to roll back to core-2021.3.2 from snapshot. Are there any issue trackers in for this?
For the same reasons all other integrations cannot be managed from there.
Did you try to read the error message yet? It’s expecting that you provide the value target_temp_high.
I’d believe the logs. Probably caching, or needing to reload. Try ctrl+shift+r.
1 Like
That must have been it, I just went to try installing it again and now it says the version is .3. Thanks everyone for the help!
This has been fixed in 2021.4dev
The change is here if you need to manually pull it in: Ensure startup can proceed when there is package metadata cruft by bdraco · Pull Request #47706 · home-assistant/core · GitHub
1 Like
has anyone else been noticing the new developer-tools/service page is way slower than before?
Thought switching it to yaml mode might help, but that is so deprecated compared to the previous style (no entity search dropdown), it is no longer of much use (or, I should probably say it is not as user friendly as before)
It would be nice if at least the entity picker could be restored own the yaml mode version?
A simple automation.trigger and then selecting an automation takes a long time on a larger system…
also, it needs the eyes to cross the whole screen from top left to bottom right to perform the action
1 Like
Also having issues i noticed yesterday. I havent checked yet what could be the issue.
the enitity picker is there in the yaml version, it just displays the name rather than the entity id
that’s the service picker…
ah my bad. although if you want to use the ui for most of it, pick the service and entity then click yaml mode
Unfortunately, if you have really problem, the meross add-on team doesn’t answer on github… 
Also noticed the addon isnt updated since 2020 december 
Think we might not be able to use it anymore unless we can fix the issue
as said, on a larger system, this is really slow. Not all UI progress is progress really. Sure, on my test systems it all is fluid, even on a Pi3. but using a production system, the eye candy all starts to lag significantly, and tbh, is not very intuitive in the first place (yet)
Since no one has the desire to answer a couple of simple questions…
Does anyone know how someone can use the previous version fan integration as a custom integration?
I’ve pulled the files from the prior code but unfortunately there are three (maybe more) files that could affect the fan domain operation - the main integration along with the mqtt fan and template fan - and I don’t know where to start to keep the functionality with three different but interrelated integrations.
What I also don’t know is if there is any special connection between the fan integration and the cloud integration that would still prevent the cloud devices from accepting a speed list as opposed to a percentage.
and I’m not sure how fans that are automatically set up using other integrations (zwave, zigbee, etc) are co-mingled with the main fan integration so would they be set up to only use percent speed either way.
Is it even feasible to try to split all of these away from the built-in fan integration?
2 Likes
Yep, same here. And if i try to reboot HA after i get the error message, i get the message that it can’t reboot because of an ungoing process. When that process finishes after some time, HA reboots and i have the new version. The logs do not have any error after the update. The only error i see is the line where i tried to reboot myself, which it denied. Strange…
(Supported HA Supervised on Debian10 here, on a Core2Quad CPU. )
Yeah I am seeing that I have gaps of hours in my speedtests (using the integration with 30 mins tests)
It has only just started doing this and it does it a few times a day. If I manually call the service it works again till it stops for no reason. Every time it stops I have to manually restart it. So I disabled the auto run in the integration and now switched to an automation.
2021-03-11 15:00:01 ERROR (MainThread) [homeassistant.components.speedtestdotnet] Unexpected error fetching speedtestdotnet data: Unable to connect to servers to test latency.
Traceback (most recent call last):
File "/usr/local/lib/python3.8/site-packages/speedtest.py", line 1489, in get_best_server
fastest = sorted(results.keys())[0]
IndexError: list index out of range
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 151, in async_refresh
self.data = await self._async_update_data()
File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 139, in _async_update_data
return await self.update_method()
File "/usr/src/homeassistant/homeassistant/components/speedtestdotnet/__init__.py", line 174, in async_update
return await self.hass.async_add_executor_job(self.update_data)
File "/usr/local/lib/python3.8/concurrent/futures/thread.py", line 57, in run
result = self.fn(*self.args, **self.kwargs)
File "/usr/src/homeassistant/homeassistant/components/speedtestdotnet/__init__.py", line 162, in update_data
self.api.get_best_server()
File "/usr/local/lib/python3.8/site-packages/speedtest.py", line 1491, in get_best_server
raise SpeedtestBestServerFailure('Unable to connect to servers to '
speedtest.SpeedtestBestServerFailure: Unable to connect to servers to test latency.
I wonder if this would be better if I switched to a fixed server in the integration?
1 Like
I see this behavior only with fixed servers.
*Auto Detect works fine.
It worked fine for me too till it didn’t in 2021.3.3