Same problem . Both solar logs are returning index out of range. Did you find a solution ? Thx
If you’re expecting help, post at least your logs and installation method.
Thank you for answer. I logged in via ssh and am trying to find them. It seems that HA sometimes starts, but then loses connection again. Updated using standard tools. Via WEB on 2024.10.0 → 2024.10.1
The log file is in the same directory as configuration.yaml.
Do you have alexa media players?
No, but there was integration with Dahua and some others. I deleted everything. And left only automation for solar power plant control. It seems to me that the system has stabilized.
Shows that there is an update. But it can’t be updated. Stuck on attempts. I have no idea why.
I try from console too and looks no access more to update.
Hallo everybody.
With the upgrade I have 2 issues. I cannot seem to pin point why I am having these issues. So if anyone has a clue that can be helpful would be much appreciated.
Thanks up front !
-
Daikin / Onecta. Response time is so slow. Example if I change temperature it takes 2 minutes before it changes in lovelace. It does change immediately in the unit itself.
I do not have this problem in 2024.10.9.4 -
SolarLog is not working “string index out of range”. Solarlog is out of service. As I use this app to control my energy consumption many off my automatisations are not working anymore. I do not have this problem in 2024.10.9.4.
I am back in 2024.10.9.4 without problems
Thank you
Bart
Tibber is working for me, and has since quite a long time.
Headings, nice way how to replate entities tile and get more at one place
Hi all,
I faced problems with switches in 2024.10.0&1.
In case I do external action with physical switch - this action appears in integration log (z2m, tasmota, esphome), but HA state does not change and also automation based on state was not triggered.
I switched back to 2024.9.3 for now…
- Core 2024.9.3
- Supervisor 2024.09.1
- Operating System 13.1
- Frontend 20240909.1
Updated to 2024.10.1 from 2024.9.3 and ran into issues with emoncms integration that we rely on. I understand change for making it easier with UI setup, but
a) why couldn’t the setup be migrated?
b) setting up new entities keep the sensors names or at least include the feed id
Now I have 48 entities named like sensor.emoncms_emoncms__temp_nn to sort through and rename
We had such a fantastic reaction when we released our [renewed badges]<<<<<
Everywhere in these blogs I have noticed there are more people opposing these changes than welcoming it so how does it make it a “fantastic reaction”.???
You are in a squeaky wheel echo chamber. This is not the only place feedback was received.
What other places are used for getting a feedback from new badges?
It would be useful then to post a short research here with evidence that this reaction was positive - otherwise based on Community posts an expression is quite opposite.
Usually there are only negative posts because the ones that like it dont express it.
I love the new badges.
New badges allow more customization for showing info, much less customization for styling and considered as small by some users. Myself never used both old and new ones, only posted tutorials about styling the old ones. More worried about a more general issue about interaction between devs and users.
This applies for both sides of the medal, has someone counted all reactions here in the forum as „research“?
I love the new badges a lot, so count me on the positive side
I used the old badges. I now use the new ones. They’re working out OK. In some ways better, in others not.
The problem I saw was the way they were “sprung” on users. It was a pretty dramatic change, and at first there were limited customization options. For example, no way to disable showing an icon. This made it impossible to consider them a direct replacement for the old style. That was, frankly, a bad design decision. If I display a temperature sensor, which shows a number, the “degrees” symbol and either C or F, I don’t need a little picture of a thermometer to be able to tell that’s a temperature. And, at first, there was no clear way to retain the old style badges while figuring out how to work the new style one into our design.
Those issues were eventually resolved. But the idea that a change like this could be forced on users who wanted to update, in an incomplete state and with little documentation, was the real problem.
Especially when there are hundreds of FRs on this forum, full of changes that users actually want.