Thanks for the info, card-mod seems the tool to use, with the examples I could make the margins/corners go away.
Now I just need to brush up on my CSS knowledge to do more advanced stuff as I don’t really mind the round corners, it is more the (IMHO) inconsistent margins/paddings.
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.