0.101: Airly, Apprise, Sinch, Solar-Log, Microsoft Teams

[Mariusthvdb (Marius)]

@balloob

This release didn’t wipe authentication tokens. This is the first report I hear.

It did. Before the update my rest api sensor worked just fine, bearer token in the list and of course in my secrets file.
Since I got these ipbans, had to look what would be trying to authenticate on my 192.168.1.1, and deleting this rest sensor solved it. Then checked why that would be, I noticed the bearer token was gone from the list of long-lived acces tokens.
creating a new one immediately solved the issue.

I must also note that I wasn’t able to bypass the validation before, because when creating this sensor in the first place some HA versions ago, I wasn’t able to do so without a bearer token. It has always been needed for this particular rest sensor. Which seems to be according design, and is a good thing!

@balloob

because of your trusted network setting, which did stop working.

Not sure what you’re saying here I am afraid. Is my trusted network setting incorrect? Thought it be following the guidelines in the documentation:

  auth_providers:
   - type: homeassistant
   - type: trusted_networks
     trusted_networks:
       - 127.0.0.1
       - 192.168.1.0/24

[DavidFW1960 (David)]

Scene:

- name: Lounge Normal
  entities:
    script.loungenormal: on

Script

'loungenormal':
  alias: Lounge Normal
  sequence:
  - data:
      entity_id: light.lounge
      transition: 2
      brightness: 191   #brightness_pct: 75
      color_temp: 322   #kelvin: 3100
    service: light.turn_on

[Mariusthvdb (Marius)]

thanks David, I see what you’re doing. But, this isn’t using a scene anymore. As Balloob states:

@balloob

Scenes work by reproducing a given state.

The scene would be:

      name: Lounge normal
      entities:
        light.lounge
          state: on
          brightness: 191   #brightness_pct: 75
          color_temp: 322 

The way you use the scene now, you could just leave out the scene completely, and simply call the script couldn’t you?

This is not what Ballob says above,

@balloob

Hence, transition should be something that could be added as a parameter when activating the scene.

My hope would be on a parameter for transition to set in a script calling the scene.

[tom_l]

The way you use the scene now, you could just leave out the scene completely, and simply call the script couldn’t you?

Yes. I see no need to put the script in a scene other than for backwards compatibility.

[balloob (Paulus Schoutsen)]

Passing transition to activate scene service is not something that is currently implemented but is something that could be added.

[Mariusthvdb (Marius)]

if that could be done, all issues would be gone Do you need a separate feature request for this, or would this discussion suffice…

Would be really really appreciated!

added this to a feature request just to keep in on the radar

Passing transition to activate scene service

Continuing the discussion from 0.101: Airly, Apprise, Sinch, Solar-Log, Microsoft Teams:

[pergola.fabio]

What’s the purpose/advantage of a scene anyway, if everything can be done with a script?

[balloob (Paulus Schoutsen)]

Trusted networks only work while logging in. They do not allow those IP addresses to access the URLs because they came from that IP. This was a deprecated feature that was removed in this release.

[DavidFW1960 (David)]

@tom_l

Yes. I see no need to put the script in a scene other than for backwards compatibility

Main reason I did it. I’m not sure how Google Assistant treats scripts right now but it does handle scenes. (I think the answer is not well)

[tom_l]

You can just specify states rather than having to call services to set states. The scene integration translates the states into service calls for you.

[pergola.fabio]

Google treats scrips the same way as a scene… They are also invisible in the home app, but they are there…

[balloob (Paulus Schoutsen)]

In 102 we’re adding a scene.create service and a scene editor.

In your automations you’ll be able to create a snapshot of a couple of states by creating a scene of them, then do some magic like flashing lights etc, then restore the state by activating the just created scene.

Scene editor is also a lot easier to build than a script editor. The UI for it is just the UI to control the devices, then at the end we take a snapshot and store in your scene.

[sparkydave (🇦🇺 Dave)]

@DavidFW1960

how Google Assistant treats scripts

I have never used Scenes in HA, but do have Scripts. Google see Scripts as Scenes in the Google Home app - treats them as you would expect a Script. Where you will find the Scripts (called Scenes in GH app) is where you create / change Routines. If you ask a Google Home device to run a Script, it works well in my experience.

[Chronocento (Andrea)]

I just updated Hass.io to 0.101.2 (that’s the latest version that was shown, even if 0.101.3 is out), and apcupsd throws this error:

Unable to prepare setup for platform apcupsd.sensor: Unable to set up component.
14:15 setup.py (ERROR)
Setup failed for apcupsd: Integration failed to initialize.
14:14 setup.py (ERROR)
Failure while testing APCUPSd status retrieval.
14:14 components/apcupsd/__init__.py (ERROR)

From the changelog:

Move imports in apcupsd component ([@Bouni](https://github.com/Bouni) - [#27803](https://github.com/home-assistant/home-assistant/pull/27803))

Any clue?

[VDRainer]

No problems here with apcupsd since 0.101 beta.
EDIT: 3.7 venv on ubuntu

[123 (Taras)]

@Mariusthvdb

its just sometimes you like what you have, even though it might be against better knowledge

To provide perspective to the discussion about scenes, here is how they are handled in Premise. I’ve converted Premise’s terminology to Home Assistant’s (as best as a I can). There’s a lot of similarity with Home Assistant but with some important differences (like all of an entity’s options are available for use in a scene and a scene can have two behavior modes).

• A scene is a collection of entities whose state and options are set to a desired value when the scene is turned on.
• A scene can be turned on/off.
• Any entity can be added to a scene and all of it options are available for use in the scene.
• A scene’s behavior can be either set-restore or set.
  • If it is set-restore, when the scene is turned off, it restores everything to its previous value(s).
  • If it is set, when the scene is turned off, it leaves everything in its current state and does not restore to previous values.
• Starting and stopping a scene are events that can be used to trigger an automation.
• Scenes can be created in the UI by dragging entities from a palette, dropping them into a scene, then manually setting their state/options to the desired values.
• As an alternative to manually setting an entity’s desired state, you can choose ‘record’ and it will use the selected entity’s current state (and options).
• You can also choose ‘record’ for the entire scene (all entities listed in the scene will be set to their current state).

[Mariusthvdb (Marius)]

wow, that is a rich environment… Premise seems to be a great home automation system, every time you write about it, it seems to be very adequate in offering solutions for HA challenges.

And I am fuzzing about losing transition

[123 (Taras)]

It was a rich environment; it was discontinued many years ago and only a handful of people still use it. That’s why I have no qualms about describing its features, to inspire Home Assistant’s developers to freely copy them, because Premise is not a competing product (it’s more of a ‘historical artifact’ given that it was created almost 20 years ago).

[m0wlheld (Christoph Dahlen)]

Docker Image (or tag) for 0.101.3 still missing, is the build process broken?

[DavidFW1960 (David)]

it’s here for qemux86 https://hub.docker.com/r/homeassistant/qemux86-64-homeassistant/tags