Hello,
can you help me for setup my cover with page 4?
i tried but i don’t work
thanks for your help
Hello,
can you help me for setup my cover with page 4?
i tried but i don’t work
thanks for your help
show us what you have done and we point down the right track
I have NWS installed and getting data but no temp data on displays.
Was working prior to latest HASSIO upgrade.
Here is my hasp_demo.yaml weather config.
weather:
You mean you didn’t read the novel of breaking changes for this release? (please read with as much sarcasm and friendliness as possible). NWS can only be configured through the UI now, it can no longer be done in a yaml file. Once you’ve done that, you can rename the daynight weather entity to nws
, again in the UI. This should bring you back to your prior state.
I do not want to commit myself to maintaining a custom component for something I do not use. It will eventually break, because the upstream library version will update in the official integration but not the custom component. There is no easy way to ‘future proof’ it to safeguard against changes in the official integration unless someone is maintaining it in close sync with the official integration unfortunately. So after thinking about this some more, my original suggestion was probably doomed from the start.
so i tried to setup my cover on first step:
# when the user moves the slider, change the light in Hass
- alias: hasp_chambre1_p4_Dimmer7UpdateHass
trigger:
- platform: mqtt
topic: "hasp/chambre1/state/p[4].b[7].val"
action:
- service: cover.set_cover_position
data_template:
entity_id: cover.fibaro_volet_principale_level
brightness: "{{ trigger.payload }}"
On service i tried also cover.toggle with no result, don’t move (up or down)
my second step: is with slider, i change the code to have good positioning of slider but not work at 100% because for light brightness is 255 and cover is max 100 when i setup slider, slider never go to max (=255) but below half (=100)
# When the light is changed in Hass, update HASP to move the dimmer
- alias: hasp_chambre1_p4_Dimmer7UpdateHASP
trigger:
- platform: state
entity_id: "binary_sensor.chambre1_connected"
to: "on"
- platform: homeassistant
event: start
- platform: state
entity_id: cover.fibaro_volet_principale_level
action:
- service: mqtt.publish
data_template:
topic: "hasp/chambre1/command/p[4].b[7].val"
payload_template: "{{states.cover.fibaro_volet_principale_level.attributes.current_position|default(0)|int}}"
i need multiply by 2.55 my current_position but i don’t know make this
Yeah I was a bit cheeky suggesting it
Pretty annoying that we’re once again dealing with more breaking changes but I suppose we should all be used to it by now.
This time, it has been decided that weather providers are no longer going to be allowed to be configured through YAML. By default, weather providers will now be created new installations will have a weather provider created with name weather.home
. The good news is that this happens automatically, bad news it’s only for new installations.
So, here’s what we’ll need to do with existing installations:
Developer Tools
> States
you have a device called weather.home
. If not, add the NWS provider to your configuration through the UI and rename the entity to weather.home
.bash <(wget -qO- -o /dev/null https://raw.githubusercontent.com/aderusha/HASwitchPlate/dev/Home_Assistant/migrate-hasp-109.sh)
Where did the decision come to make the weather provider default to weather.home
and what provider/integration creates this weather.home
? I have many weather providers (Ecobee, NWS, Dark Sky) and each has a unique name and none of them are “Home”. NWS now creates two entities after adding the integration that are weather.<station>_daynight
and weather.<station>_hourly
. Ecobee creates entities based on the name of the thermostat (I have an upstairs
and a main_floor
). and Dark Sky… well we won’t talk about Dark Sky.
If you do a default Hass installation from scratch on 109+, a met_no
weather integration will be automatically created as weather.home
. So, figured that was a good a target as any.
Right up until someone decides to change that in some later breaking change of course.
ok, so in my case I can just substitute weather.home
with the name of whatever sensor I want to use as the provider to HASP.
EDIT: that is as long as what HASP is looking for is a valid attribute of that integration/entity…
The properties of the weather providers should all be standard-ish according to the docs. I do know I can switch between NWS and Met.no without changing the automations.
As another poster pointed out, I don’t think this is true. It is up to each integration to name entities.
Met weather names it’s entities home and has done this for a long time.
Totally correct, my bad
Still, weather.home
is the closest thing I have to default at this point and I can no longer configure this directly for the user (thanks hass devs) so… seems like the lowest-friction approach.
Oh by the way, met no has problems now for anyone at higher elevations using imperial units.
See https://github.com/home-assistant/core/issues/34781 for issue describing the problem with met weather
Doesn’t NWS only provide US weather? It appears so from their website.
Correct. NWS is US only.
I am a new user, and have been searching for an answer to the question of how I get my new HASwitchPlate to display the temperature and weather. This answered my question. Thank you!
Thanks so much Luma for the script!! Working well now!!