Thanks for checking CChris . I think it is indeed the round corners that made it more visible.
I was expecting margins/padding like on the energy dashboard. I think I can use the cardmod custom card as mentioned earlier in the thread to get those added.
EDIT:
So I ended up with this cardmod CSS code
card_mod:
style: |
ha-card {
border-radius: 0;
padding: 8px;
}
Which gives me a similar looking padding as on the energy dashboard and I like how this looks
Full view
I recently updated but now I get a dict error on my restful configuration which worked perfectly fine before. I didnāt find anything related at first glance to the restful configuration in the breaking section.
configuration.yaml
homeassistant:
packages: !include_dir_named packages
packages/rest.yaml
rest:
- resource: https://www.meteo.be/services/wow/ajax/getLatestObservation.php?id=eb83b402-87d8-e911-b3b9-0003ff59a783
scan_interval: 60
sensor:
- name: "vlinder_data_temperature"
value_template: '{{ value_json["primary"]["dt"] }}'
unit_of_measurement: 'Ā°C'
- name: "vlinder_data_wind_speed"
value_template: '{{ value_json["primary"]["dws"] }}'
unit_of_measurement: 'km/h'
- name: "vlinder_data_wind_direction"
value_template: '{{ value_json["primary"]["dwd"] }}'
- name: "vlinder_data_humidity"
value_template: '{{ value_json["primary"]["dh"] }}'
unit_of_measurement: '%'
- name: "vlinder_data_pressure"
value_template: '{{ value_json["primary"]["dm"] }}'
unit_of_measurement: 'hPa'
- name: "vlinder_data_rainfall"
value_template: '{{ value_json["primary"]["drr"] }}'
unit_of_measurement: 'mm/h'
Error
homeassistant.exceptions.HomeAssistantError: The system cannot restart because the configuration is not valid: Package rest setup failed. Component rest cannot be merged. Expected a dict.
As stated, worked on 2022.10.5 as expected. Stopped working after upgrading to 2022.11.2 upgrade this morning. Not sure (never encountered an issue) if I can safely put the 2022.10.5 release back? Or would like to know whatās suddenly wrong with the setup restful integration?
Search a few posts upā¦
Also, always check the integrations listed issues. Itās raised
No one take the bait please. Thanks.
@frenck wrote in the release note that we now can use config_entry_id() in templates.
That of course only works for UI configured integrations, not for the yaml ones.
Is there a workaround / other way to achieve the reloading of a yaml configured integration?
uhmā¦
Logger: homeassistant.components.history
Source: components/history/__init__.py:85
Integration: History (documentation, issues)
First occurred: 11:35:57 (5 occurrences)
Last logged: 12:15:08
WS API 'history/statistics_during_period' is deprecated and will be removed in Home Assistant Core 2022.12. Use 'recorder/statistics_during_period' instead
why would core integration History throw a warning of deprecationā¦?
They are refactoring the statistics getter endpoint in the websockets API. Itās a renaming of the endpoint. To make things ālook more logicalā on their side. It will completely break all components using LTS, including core and custom cards. They will all have to be changed and updated to the new endpoint, otherwise they will break in 2022.12. For a completely unnecessary rename that gives zero functionality or stability advantages. And supporting the old endpoint for backwards compatibility would have taken less than 10 lines of code.
Sigh.
The cavalier attitude towards breaking changes in this project really blows my mind. A breaking change should be an absolute last resort thing, not something you do casually just because you feel like it.
Its an internal api that isnāt meant for outside use. It just so happens that custom āitemsā, have access to this api. This is what you signed up for when you make custom things for HA. Add your stuff to core and itāll get fixed for you without it being a breaking change.
HA has stated many many times that they will do whatever they want with their api. At least they notify custom āitemsā now, they never did in the past.
Every project Iāve ever worked on in 20 years of development does this with their internal apiās. This shouldnāt be anything new for you.
Now breaking changes for the usersā¦ yes, itās a bit overboard at times.
Why donāt you gauge interest for a fork? The current developers have no interest in creating production value.
Please donāt engage lights_on, this is one of his many accounts (that isnāt suspended). By all means, he is a troll. Just ignore him. Thanks.
I am not a troll; I also said you guys did something right this release.
Wow. How motivating.
Itās these kind of responses that make me wonder why I even bother with this project anymore.
And how are we supposed to know what part of the WS API is āofficialā and what part is āinternalā ? Where is this documented ? Are the only āofficialā WS parts the ones in this outdated doc here ? In every serious commercial API I have ever worked with, internal API calls where always clearly marked as such. Not in HA apparently.
Everything is internal when making custom integrations or frontend items. This is a trade off of going custom. The management is 100% in your hands when the API changes. Bringing things into core has an added benefit that tests break when the API changes and itās up to the breaking change maker to fix everything. The downside is now you have to follow the HA standards.
You have to be kidding meā¦
It isnāt that simple though. Leaving an old endpoint is not just 10 lines of code, it is supporting that endpoint for some amount of time, if the new endpoint changes in behavior or gains new functionality / new defaults then there is a discrepancy in behavior which can cause confusion. Thereās also the fact that with this change other internals may be changing which would break the old API usage anyway.
As a custom integration developer (like myself) it is my job to keep the integrations up to date with the internal APIs that the integration uses.
Same here, including professionally working with large companies even. On one hand I do understand the frustrating aspect of it but at least being notified of the issue is happening now which helps a lot. Either way, Iād really much prefer things to continue moving at a good pace then at a snails pace.
External apis are documented. If itās not documented its internal. If you get confirmation that itās actually external and undocumented then thatās a doc bug.
Is that really so different from any other project? Changes to undocumented internal apis happen all the time.
@lights_on, youāve been privately asked multiple times to not insult people. Thatās it. Donāt insult people. Itās a simple concept. The development team are people. Other forum members are people. I am a person. Other mods are people. Admins are people.
Donāt insult anyone in that list, which is everyone. Thatās it. A simple rule which you are unable to follow.
Iāve asked you privately, now Iām asking you publicly. Stop insulting people. Name calling in any form is an insult. Stop.
It was entirely unclear, to me at least, what is considered internal and what is not with HA. HA documentation in general is very poor, so not finding a call in the docs is not something I associated with āoh, itās internalā, but rather with āoh, they didnāt update the docsā. But thanks for clarifying. It certainly makes developing custom components a lot less attractive.
I mean very poor seems like a stretch but thatās a topic for a different thread. Too technical seems like an assessment that would be hard to argue with.
Fortunately too technical isnāt aproblem for developer docs. The rest API for example is actually thoroughly documented. Which suggests to me the websockets API is too.
Fwiw you might be right though, HA certainly isnāt immune to bugs. If you find an undocumented internal API that you want to be external then submit a #feature-requests asking for it to be one. If it turns out to already be one but missing doc then itāll become a bug and then you know itās safe to use.
Ok, good to know.
Not really. The REST API is actually much better documented than the WS API, which is basically just a list of convoluted examples without any clear reference to available actions, valid parameters in the json, etc.