HA SwitchPlate HASPone: DIY In-Wall Touchscreen Home Assistant Controller

Hello,

can you help me for setup my cover with page 4?

i tried but i don’t work :frowning:

thanks for your help :slight_smile:

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.

1 Like

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.

2 Likes

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 :slight_smile:

1 Like

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:

  • Confirm that you have a working weather provider, and that under 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.
  • Rename all references in your HASP packages to point at this new provider. To help with this I wrote a script which you can execute like this:
    bash <(wget -qO- -o /dev/null https://raw.githubusercontent.com/aderusha/HASwitchPlate/dev/Home_Assistant/migrate-hasp-109.sh)
1 Like

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 :frowning:

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!

1 Like

Thanks so much Luma for the script!! Working well now!!

1 Like