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

Blog
163

Ok, thanks for explaining, I do get the logic… its just sometimes you like what you have, even though it might be against better knowledge. Let’s bite the bullet :wink:

Let me please ask the community here how then to rewrite a scene call into a script with given simple example below. Where to put the transition in the script?:

current script:

lighting_slapen:
  alias: Lighting Slapen
  sequence:
    - service: input_select.select_option
      data:
        entity_id: input_select.activity_lighting
        option: Slapen
    - service: scene.turn_on
      entity_id: scene.slapen

and scene_slapen:

- name: Slapen
  entities:
    light.bedside_table:
      state: off
      transition: 20 #<---- where do I enter this, now transition is no longer supported in scenes?
    group.kantoor_lights: off

Since I cant find that option in the scene.turn_on service,

42

can I simply change to:

    - service: scene.turn_on
      entity_id: scene.slapen
      transition: 20

?

164

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!

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
165

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
166

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

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,

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

1 Like
167

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.

168

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

3 Likes
169

if that could be done, all issues would be gone :wink: 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 :wink:

170

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

1 Like
171

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.

172

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)

1 Like
173

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.

174

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

175

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.

1 Like
176

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.

1 Like
177

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?

178

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

179

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).
1 Like
180

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

181

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).

182

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

1 Like