Hello
i have also problems with getting an background image to work.
I used the code
background_image: /www/community/lovelace-windrose-card/bg.png
resut is the Background showing a “default” picture
Can anyone help please?
Cheers, Jörg
I have setup my card background picture and paddings by the card-mod.
card_mod:
style:
.: |
.card-content {
padding-bottom: 0px;
padding-top: 10px;
padding-left: 20px;
padding-right: 5px;
margin: 0px 0px 0px 0px;
background: url('/local/images/hv_1_dark.png');
background-size: 100% 100%;
border-radius: 5px;
}
1 Like
Example:
background_image: /hacsfiles/lovelace-windrose-card/bg.png
This should work
Or with cardmod.
1 Like
I do not have the folder /hacsfiles/
my lovelace-windrose-card can be found under /www/community/lovelace-windrose-card/
The file is in the correct location but is hosted under hacsfiles
1 Like
ok, thanks, now it is working. I thought, the link should be to the folder i copied the *.png file. with your shortcut to /hacsfiles/lovelace-windrose-card/ it actually worked!
Thank you !!!
1 Like
Where do I get that Apex chart?
I got a question today on GitHub in an issue.
The person is asking me to bundle changes and not release that often.
What do you think about this?
Should I bundle new features and bug fixes and release once a month for example.
Or should I release as soon as I think it’s ready to be shared?
Personally frequent updates don’t bother me, especially if they are for issue fixes.
If you do end up bundling update you could use the pre-release feature for minor updates for people who want updates more often.
2 Likes
I vote for releasing as soon as you think it’s ready to be shared. Frequent updates are welcome.
2 Likes
I would prefer more often as I look forward to all these updates. However, I see other HACS streams particularly with high dependencies and with potential breaking changes, use beta releases to incrementally move forward. I don’t see Windrose as high dependency; there are no automations dependent on it. Keep up the good work!
2 Likes
Released version 1.18.1
Fix:
- In corner info, when converting degrees to cardinal direction letters, some direction where not converted correctly. Thanks deanfourie1. Fixes #137
And thanks for your responses about the release cycle.
I’ll keep releasing new features when ready and fixes as soon as possible.
5 Likes
Hi,
New HA release, I read something in the noteworthy changes.
We now have a device class for wind direction sensors! Thanks @edenhaus
I’m curious what this will do for statistics data for wind direction sensor.
Sorry, why do you think that the new device_class may impact LTS?
I had a conversation some time ago about this, here: A few questions about matching_strategy · Issue #96 · aukedejong/lovelace-windrose-card · GitHub
It contains a link to: Ecowitt integration - the sensor ********_wind_direction does not have a 'state_class' attribute · Issue #129260 · home-assistant/core · GitHub
My wind direction entities don’t have LTS.
Do we have users with direction entities witch support LTS?
Gismeteo integration provides a “wind bearing” sensor with “state_class: measurement”. Although the integration gives data not in a reliable way (could be caused by a source though), but it’s another issue.
Is there something wrong here or am I not understanding something?
If I show the last 4 hours I see the strong wind speeds, though they are not all in the correct bin of speeds:
However if I show the last 8 hours the strong winds disappear:
They should be still there for at least 50% of the time.
Likewise for 24 hours (the span of the chart above):
type: custom:windrose-card
title: Casey Wind Rose
data_period:
log_measurement_counts: false
period_selector:
active_color: white
active_bg_color: var(--secondary-text-color)
location: bottom
buttons:
- hours: 4
title: 4 hr
- hours: 8
title: 8 hr
- hours: 24
title: 24 hr
active: true
- hours: 168
title: 7 days
max_width: 400
refresh_interval: 300
windspeed_bar_location: bottom
windspeed_bar_full: true
wind_direction_entity:
entity: sensor.casey_wind_direction
direction_unit: letters
use_statistics: false
direction_compensation: 0
windspeed_entities:
- entity: sensor.casey_wind_speed
name: " "
speed_unit: auto
use_statistics: false
output_speed_unit: knots
speed_range_beaufort: false
speed_ranges:
- from_value: 0
color: "#93abca"
- from_value: 5
color: "#039BE5"
- from_value: 10
color: "#63e686"
- from_value: 15
color: "#0da035"
- from_value: 25
color: "#e0b400"
- from_value: 35
color: "#ff8000"
- from_value: 45
color: "#e45e65"
- from_value: 60
color: "#ff4754"
- from_value: 80
color: "#b200ff"
background_image: /local/background/casey.png
windrose_draw_north_offset: 0
cardinal_direction_letters: NESW
matching_strategy: direction-first
current_direction:
show_arrow: true
arrow_size: 40
center_calm_percentage: true
The LTS for the new wind direction class is still under development and will be available (if no blocker is found) with the next release
1 Like
Hi Tom,
That looks strange.
Your input speed unit is ‘auto’. What unit is your entity using? Also knots?
Your configuration uses some deprecated properties. I think it’s good to fix this first.
The properties output_speed_unit, speed_range_beaufort en speed_ranges can be moved to the windspeed_entities level. Please check the readme for the deprecated ones, there are more.
Have you tried other matching strategies? See the readme for the differences between the strategies.
An option that could help explain this, set log_measurement_counts to true and have a look add the numbers logged in the browsers console (F12)
If we still cannot explain this, please submit an issue in GitHub.
https://github.com/aukedejong/lovelace-windrose-card/issues/new
Maybe a bug. 