Add easier solution for loops in automations/scripts

Well… I don’t have three examples, but here’s two (and if python_scripts are the way to go here, happy to pointed in the right direction (again!)).

I want to use a rest_command to POST some data to an external API/URL (solcast.com) every 5 minutes (all day, every day—though from just before sunrise to just after sunset would probably be just as suitable). I can manually trigger it, but I need a lot more data uploaded to calibrate.

I also want to use a rest_command to GET data from solcast.com every 40 minutes (between sunrise and sunset) to conserve my 20 free API calls (:slight_smile: POST API calls don’t count). I’m currently using a RESTful sensor for this, but as that runs all night (as well as during the day) I only get about 10 useful API calls (i.e. daytime ones).

Sounds like what the Time Pattern Trigger was designed to do.

Time Pattern Trigger with a sunrise/sunset condition.

1 Like

Taras, you’re a legend. I’ll give it a try.

Well that seems to be working great for great for my POST of data to solcast.com—thanks very much Taras!

Any suggestions on what/where to read up on using GET in rest_command to set the value of a sensor (so I can control it in the same way as the POST—versus the “always running” RESTful sensor I’m currently using)?

(and apologies to the OP is this is off-topic)

It’s my understanding that GET is the default for rest_command.

Regarding your existing RESTful sensor, the default polling interval (for most platforms that perform polling) is 30 seconds. If that’s too frequent for your sensor’s purpose, you can adjust it using scan_interval. For example, if you want it to poll every 15 minutes, set it to 15 x 60 = 900 seconds.

Yep… GET is default. And I’m aware of the polling interval settings for RESTful sensor (I currently have it set to 4500 seconds).

What I’m hoping to do is either:

  • Some way to stop the RESTful sensor from polling during the night (to conserve my API calls), or

  • Use the rest_command to get the same information at fixed intervals, and only during daytime, (as is now working successfully (thanks!) in POSTing data) and use the data to “set” a sensor (if there is some way to do this)

Hmmm. Here’s an (untested) idea, create an automation that runs periodically, but only during daylight hours, and updates your RESTful sensor via a service call to homeassistant.update_entity.

  • Use your existing RESTful sensor.
  • Set its scan_interval to 86400 seconds so it fires just once a day.
  • Create an automation with a time_pattern trigger (set the interval to whatever you prefer).
  • Set the automation’s condition to run exclusively during daylight hours.
  • Set the automation’s action to run the update_entity service for your RESTful sensor.
1 Like

Initial testing seems to be working—so… awesome! I’m gonna have a play with extreme scan intervals (like… a year (31536000)—apparently others have done this with no issues as yet).

Thanks again!

I don’t like the idea of having to write a Python script to perform a loop in HA. If HA is going to be something for common folks, that will never do.

One other example of a loop that I need right now is following:

  • Burglar Alarm is triggered - > use tts.google_say to repeat message “intruder alert”. Maybe with a delay in between. This should be done until state of alarm is disarmed.

Do you mean that you cannot currently implement it without python_script?

yes, correct!

You don’t need a python script for this. Take a look at the alert integration, it should do exactly what you want.

The thing is, most of the time when someone asked for a loop here in the forum it was either solvable through the alert integration or no loop was needed for achieving their end goal. And people that really needed a loop and the alert integration was not enough, were capable of writing python scripts.

That’s an aspirational goal. Much work remains to make the Automation Editor support all existing automation abilities, let alone adding a looping ability. Currently, Home Assistant’s installation process alone puts it out of reach of ‘common folks’ (i.e. the average consumer).

As I’ve stated in previous posts, looping is an edge-case requirement. Many of the use-cases cited, to justify its need, can already be achieved through other means.

Feel free to vote for this Feature Request but know that thousands of people are using this 6+ years-old software project without an explicit ‘automation looping’ ability.

though agreeing with you here @123, I do wish we had a media_player.loop_media service… that would make life so much easier, the ways we have to go to make an automation play a file, calulate its length and restart that file again…

just curious - why do you need to do so many things?

I remember that conversation. Yes, a specific service for media_player, that understands the media’s duration, would be useful.

According to this post it seemed that TTS.google_say was not a valid notifier, and they went with node-red instead. But I will look into it! Thanks for your feedback.

Sure, I understand that it maybe isn’t highest priority. Still I think it’s a valid request.

Of course it is possible to do without a built in loop feature. But so is everything:)

Personally I would gladly learn python to be able to contribute, but not right there yet. But I will maybe try the code you supplied above as a start :slight_smile:

1 Like

Ou okay didn’t know that, thought you wanted a notification on the phone.

No, the message should be broadcasted on all my google home minis around the house. So it does not seem the solution works for this case. So either this pull request are more valid, or support for tts.google_say could/should maybe be added to the alert integration instead.