Studio Code Server - upgrade to v5.16.0

So after upgrading Studio Code Server to 5.16 my YAML is now full of errors due to the change of terminology from service to action.

Everything still works okay, but eventually my OCD is gonna kick in and I’m going to have to change them all :laughing:.

How is everyone else feeling about that?

Hi Dave Forrester

The more people on the same page looking and working from the current Docs, the better.

Use replace…

Now I have 20 blueprints I’m sharing and 3 HA instances to fix…

1 Like

It would be nice, if this just updates automatically with some HA update.
I’m actually a bit tired of changing things manually every time, when someone decide to change things, which worked fine… :wink:

669 lines of code to check only in scripts.yaml, I so have no time for this…

I’ve just done a “find and replace” for every instance of service.

However, there were about half a dozen other errors such as this in a script:

  fields:
    light:
      name: "\U0001F4A1 Light"
      description: entity_id of the lamp.
      selector:
        entity:
          domain: light
      example: light.kitchen
      required: true

giving

String does not match the pattern of "DEPRECATED^".yaml-schema: http://schemas.home-assistant.io/integration-script

I still have 7 of these errors, this one in particular relates to the line

domain: light

The others are

domain:
- input_number
- input_select
- input_text
- sensor

and

domain:
- input_boolean
- binary_sensor

These are all in a script called Ashley’s Light Fader, which I don’t use anyway so will just ignore for now.

Is it safe to mass replace service with action ?

And i guess i will have to replace too platform: state to trigger: state because i am on the 2024.10 beta.

You’ll hve to be careful when mass replacing, especially for the beta. I did it, but I had to do some trickery to only replace the ones on top level.

1 Like

I believe you don’t have to change anything if you don’t want to. My understanding is that the legacy syntax will continue to work, and there are no plans to remove it.

Yes that’s my understanding too. I did check most of the replacements. I’ll deal with any issues if they arise.

Im in the process of migrating most of my packages into the UI. I just find it much easier to edit them there.

I like this new feature on my tablet. It freezes the top level indent so you can see where you are :+1:

No. Not yet.

Wait until you have updated to 2024.10.

Replace the word action: with actions: first. Then replace service: with action:

If you don’t do it in this order it becomes difficult to distinguish the changes required:

e.g easy:

- id: c6ff67b4-ea6a-4953-b3b5-d4a369f33f1c
  alias: 'Solar Forecasst Message'
  trigger:
  - platform: sun
    event: sunrise
  action: #### <- Change to "actions:" first #####
  - service: notify.telegram_general #### <- then change these to "action:"
    data:
      title: '☀️ <b>Solar Forecast</b>'
      message: >
        Today: {{ states('sensor.todays_solar_forecast') }} kWh

        Tomorrow: {{ states('sensor.solcast_forecast_tomorrow') }} kWh

difficult if you have already replaced “service:”:

- id: c6ff67b4-ea6a-4953-b3b5-d4a369f33f1c
  alias: 'Solar Forecasst Message'
  trigger:
  - platform: sun
    event: sunrise
  action: #### <- Change to "actions:" 
  - action: notify.telegram_general #### <- uh-oh don't change these ones to "actions:"
    data:
      title: '☀️ <b>Solar Forecast</b>'
      message: >
        Today: {{ states('sensor.todays_solar_forecast') }} kWh

        Tomorrow: {{ states('sensor.solcast_forecast_tomorrow') }} kWh

This can only be done after updating to the October release.

So in short do not change service: to action: just yet. Wait until you can change action: to actions: after updating to the October release. Only then it is safe (easy) to update service:.

5 Likes

Sound advice, thanks.

You should think about posting this message in a pinned place today after the release. It might help avoid some questions.

I plan to use this in a Video this week on my YT as well and will reference it directly.

I’m personally not changing anything. Everything is backward compatible. If it ain’t broke, don’t fix it. New automations will get these changes, that’s it.

But the VSCode warnings are going to get to people if they haven’t been removed. By the number of updates lately, they may have been though.

oh well, the vscode warnings are often wrong anyways. IIRC they only work well if you have a basic automation. Anything remotely advanced and it’s red squigglies everywhere.

My OCD won’t like them personally, and many will think it’s broken and be asking how to fix. That’s my point I guess.

When the word deprecation is used in the warning, people think it will soon break even though this is not supposed to.

As the originator of this thread, I absolutely get where @Sir_Goodenough is coming from, but am also mindful of what the moderators are saying.

I have some quite complex, “non-basic” automations and scripts etc and very seldom have red squigglies unless syntax or indentation is wrong. The “if it’s not broken don’t fix it” approach is generally the best but the OCDness of lots of “deprecation” messages will annoy quite a lot of people.

As a 2 year user of HA I bow to the greater knowledge and experience of long time users. After all, isn’t that one of the benefits of this community.

I looked yesterday, they edited the extension so that either syntax is accepted, and not listed as deprecated. I converted mine anyway, will have a YE video about it out Sunday morning my time.