Totally agree!
And i think not only ‘remove’ should be a Criteria, but change as well. By now for me HA feels like running after breaking Changes. Whenever i check/fix a broken Thing, the next Break is already around the Corner. Sometimes it feels like a breaking Change is not considered to be the last Option, but the first. This is sometimes quite frustrating.
Anyway. This isn’t meant to turn into a Rant.
There has been a significant improvement in communicating breaking Changes, and in making the Frontend more User-friendly. I hope it keeps that Path and keeps on getting better - Without removing Functions, and if there is no other, really no other Way to invent a breaking Changes, to make the Change as easy as possible on User Side. Maybe even without the User noticing.
Home Assistant should always assist the User, not get assisted.
That beeing said - i am really happy this Project so alive, continiously getting new Functions, while getting more and more professional - Communicationwise and Structural!
Edit: @Ildar_Gabdullin I think you were more thinking about a general Movement from yaml towards GUI If you can get the same results when doing it on GUI, would you consider that beeing a “removing” a functionality, or is it rather a “change”?
not so sure about that ‘beginners’ aspect, why would a beginner be helped with this. Id dare to say a beginner would be best instructed by creating yaml templates, as all of than manual labour tends to carve itself in our brains, and helps understanding the template concept.
But, now that we have these Helper templates, I do appreciate it (even though they will get lost in the UI and only have the state we can template)
its exactly the fact we only can use template on the state, that make these’ ideal’ Helpers.
No specifics required for the frontend, nothing full fledged, no, only a templated state of interest, that can Help in other scenarios like automations, frontend conditionals, or even inside other Helpers/templates, like the first I made:
Might seem ridiculous entity, but I need it inside Helper statistics Max, and since we can not simply use a value 0 inside those helpers, I needed a template entity for the entity picker
So, until any further progress is made (and no promises are made they ever will) I consider the Template Helper a true helper, and saves me a (tiny) bit of yaml.
EDIT
after some more exploring, I found another 56 templates I could move to the UI, and can edit now without having to open any editor other than the Cogwheel.
Same error here. Not sure if it’s the update, earlier today I had it also with 2023.8 version. Are you using zigbee2mqtt? In my system error log shows connection issues to its github page.
Looks like all github addon repos are causing it. If you restart HA, sometimes it works fine without errors. This also seems to block HA updates appearing.
I’m currently testing out the new enphase envoy integration, before i upgrade and switch to this default integration. Works OK for me, i don’t get the 3-phase sensors; is it due to not implemented or some other reason? Not that big of an issue; i have developed these myself in the past but i never look at the readings:-)
One thing i’m really miss compared to my current custom integration; overall battery charge / discharge. So with the current version i’m unable to use the battery information in the energy dashboard. Is this correct? and if so; is this functionality coming soon?
You should be able to copy and paste this as is (other than changing the IP) into your configuration.yaml and restart.
# RESTful platform
rest:
# Enphase Envoy
- resource: http://192.168.0.x/api/v1/production
scan_interval: 60
sensor:
- name: Enphase Envoy Current Power Production API
unique_id: E4C8227C-1ED7-4813-B3DA-2C76DCC1F88B
icon: mdi:solar-power
device_class: power
unit_of_measurement: W
state_class: measurement
value_template: "{{ value_json.wattsNow }}"
- name: Enphase Envoy Today's Energy Production API
unique_id: E438BC8F-A6D1-43D7-994E-3574209437B3
icon: mdi:solar-power-variant
device_class: energy
unit_of_measurement: Wh
state_class: total_increasing
value_template: "{{ value_json.wattHoursToday }}"
- name: Enphase Envoy Last Seven Days Energy Production API
unique_id: DF4A1A23-CC66-460E-BFC7-F4B27B3D3E01
icon: mdi:solar-power-variant-outline
device_class: energy
unit_of_measurement: Wh
state_class: total_increasing
value_template: "{{ value_json.wattHoursSevenDays }}"
- name: Enphase Envoy Lifetime Energy Production API
unique_id: B29C48E4-856B-443D-AEF4-84EE677683E0
icon: mdi:solar-power-variant-outline
device_class: energy
unit_of_measurement: Wh
state_class: total_increasing
value_template: "{{ value_json.wattHoursLifetime }}"
I actually used the RESTful integration to pull multiple sensors from the one resource, rather than creating separate ones using the RESTful Sensor integration, but the result is the same and you could do this either way, although doing it this way only requires one call to the API, rather than four that would be required otherwise.
You can can load and check these are working before upgrading.
Unfortunately, as these are new sensors, they will not have the history or long-term statistics from the old sensors provided by the integration. Someone may be able to correct me, but I don’t believe there is any way to migrate that across.
As others have stated you could potentially also load the old integration as a custom component, which may possibly have the benefit of keeping the history and long-term statistics (I am not sure about this though), but as it will no longer be supported there is a risk it could break at some point in the future. My personal preference is to lose the history and statistics now and know that this should carry on working for the foreseeable future.
It’s not just one addon, at least two different repos give errors like this and cause SuperVisor errors. I haven’t noticed this before today and it happened also with 2023.8.
stderr: 'fatal: unable to access 'https://github.com/hassio-addons/repository/': Failed to connect to github.com port 443 after 132051 ms: Couldn't connect to server'
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/src/supervisor/supervisor/store/repository.py", line 108, in update
await self.git.pull()
File "/usr/src/supervisor/supervisor/jobs/decorator.py", line 266, in wrapper
raise err
File "/usr/src/supervisor/supervisor/jobs/decorator.py", line 264, in wrapper
return await self._method(obj, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/supervisor/supervisor/store/git.py", line 178, in pull
raise StoreGitError() from err
supervisor.exceptions.StoreGitError
Ah thank you so much for this. Works like a charm. And I agree, using the old version may work for now, but you’ll never know for how long.
I have this now running on the 2023.8.4 version of HA and it seems to work fine. Too bad about losing history indeed. But maybe it’s possible to leave the old sensors in the energy dashboard for historical purposes. The data shouldn’t be lost after the update right?
I’ll do the update (takes a while) and see if that will at least let me keep the history in the energy dashboard.
I imagine the sensors will be removed if you remove the integration. However, the Devs have confirmed that 3.17.3 should be supported, so maybe there’s a bug or it’s been caused by another issue?
That’s why I was planning to keep the integration and use your sensors for the future. But as the Devs have confirmed that 3.17.3 should be supported, I’ll wait and see if they come up with a fix. If not, I have your work-around at least. So thank you very much for that.
Traceback (most recent call last):
File "/usr/src/supervisor/supervisor/store/git.py", line 136, in pull
await self.sys_run_in_executor(
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/site-packages/git/remote.py", line 1015, in fetch
res = self._get_fetch_info_from_stderr(proc, progress, kill_after_timeout=kill_after_timeout)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/git/remote.py", line 854, in _get_fetch_info_from_stderr
proc.wait(stderr=stderr_text)
File "/usr/local/lib/python3.11/site-packages/git/cmd.py", line 604, in wait
raise GitCommandError(remove_password_if_present(self.args), status, errstr)
git.exc.GitCommandError: Cmd('git') failed due to: exit code(128)
cmdline: git fetch -v --update-shallow --depth=1 -- origin
stderr: 'fatal: unable to access 'https://github.com/home-assistant/addons/': Failed to connect to github.com port 443 after 130329 ms: Couldn't connect to server'
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/src/supervisor/supervisor/store/repository.py", line 108, in update
await self.git.pull()
File "/usr/src/supervisor/supervisor/jobs/decorator.py", line 266, in wrapper
raise err
File "/usr/src/supervisor/supervisor/jobs/decorator.py", line 264, in wrapper
return await self._method(obj, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/supervisor/supervisor/store/git.py", line 178, in pull
raise StoreGitError() from err
supervisor.exceptions.StoreGitError
If you can get the same results when doing it on GUI, would you consider that beeing a “removing” a functionality, or is it rather a “change”?
