Flows scripting

Does anybody have an example how to create flows programmatically?
It would be nice to have something like:

  1. Create flow with a trigger from an App (so I can specify the trigger and an App to use trigger from)
  2. Add conditions (like states from other Apps / devices).
  3. Add actions (change device state / set state for an App / execute an action for a chosen App).

So the goal is to script everything that flow editor allows you to do.

1 Like

Did you try HomeyScript? With this app.
Examples can be found here.

1 Like

I’ve seen HomeyScript, but I’m not sure if it provides a way to create flows with triggers etc without using the standard flow editor.
Is that possible? I don’t see any examples like that.

I dont know if that is the purpose, Homey script is to run scripts not trigger scripts.

If you don’t want to use the flow editor to trigger a script, then you could create a SDK app which uses the webAPI to piggy back upon a device capability event observers. Be warned that if you go that route your likely to have a Alice falling down the rabbit hole moment.

I’d like to find any examples how to create flows with API only.

I can’t think of any :frowning: The documentation is woefully incomplete: https://developer.athom.com/docs/api/HomeyAPI.ManagerFlow.html#createFlow

Hi,

Not sure if remotely helpful but:

@Erik - Who is behind the ‘flow viewer’ also created a flow editor in the past for his private use use. (I think he suggests there, that he’s going to look into making a working public version of it? - If not then, I misunderstood)

At any rate. Maybe he can give you some pointed on how to address your question?

The question I have is … Why?

Only reason I can think of is making a flow editor?

1 Like

Or make flows on the commandline when you are working in a linux shell? :wink:

Or make the promised Community Desktop App to replace the old one. Without proper documentation…

1 Like

Now who did that?

  $.ajax({
    url: `${setup.protocol}://${setup.ip}/api/manager/flow/flow/${flowId}`,
    type: 'POST',
    data: JSON.stringify(flowObject),
    success: function(data) {
      console.log('Hoera')
    }
  })

Where flowObject is comparable to what you GET with the getFlow commands.

I don’t like visual interfaces to build any sort of logic and mobile UI doesn’t add any value to that.
The goal is to create and maintain all the flows/logic using scripting only. Also this allows to use VCS to keep a history of changes.

I don’t see the point of creating flows then, it sounds like you want to use events to detect changes to device state and act on those. Or use the MQTT Gateway/Hub app to do the heavy lifting, and implement your logic based on MQTT events.

1 Like

That was my original intention.
Homey provides other features using Apps, so it’s possible to use non-device events, actions and data using regular flows. It would be great to have an opportunity to use that. Also it’s still useful to have flows because they are a part of the whole system.
Do you know how to use Apps without flow cards in a convenient way? Well, nothing is convenient btw, but I’d like to use Apps from my scripts.

You have to be more specific: can you name an app and how you would want to use it?

Examples:

  1. Play music using Spotify.
  2. Check if it’s raining outside using a weather app.
  3. Check if it’s time to collect a trash using Trashcan Reminder.

Well, it’s still possible to create flows manually and run them through MQTT. Or I can send MQTT events if something happens using a few flows.
Not sure if it makes sense to use MQTT in this case, it looks like it would be better to build my own app that does all these things.

I really fail to see why in the cases you mentioned you would need anything other then the normal flow editor. It sounds to me like over engineering

This was/is exactly my thought for the MQTT Hub. I also want(ed) to integrate app triggers, conditions & actions into the hub, to fully control your Homey over mqtt. No need to create flows. Even had a long discussion about this a while ago on slack; the conclusion (from Emile): it’s simply not possible.