I suggest that the card “Start a Flow” be extended to so parameters can be sent to a flow, as tags.
Not only would this decrease the number of flows for most people, it would also elevate the Flow, programing paradigm to the exalted Turing complete language, eg it would be possible to write any flow ever written or going to be written in the Turing machine. Making Flows as powerful as Java, C/C++ or any other modern programming language. (abbreviated explanation, please read Turings Theory (Turing completeness - Wikipedia))
If you are lacking the resources to accomplish this I can recommend a company that can do this both efficiently and at the right price
/MS
2 Likes
What stops you from using tags and/or variables from flows started by “Start a flow”?
No, not c#, H.O.O.P. (Hope) - Homey Object Oriented Programming
You can create a Method Group (device) and have Methods with all kinds of parameters/arguments.
Also multiple triggers in one flow.
See the example Topics for examples: H.O.O.P. (Hope) - Examples
1 Like
I might have been unclear so let me further explain.
The card “Start a Flow” is when you from one flow call another flow. There are no way to pass any parameters in that card in the present firmware. I suggest an expansion or extension of that card and the possibility to use this with the already present tag system. I minor change, if Athom has done this the right way!
/MS
Well if we all learn JavaScript that might be a great way to go. I suspect that Athoms reason for introducing Flows, was for the common man/woman to be able to build complex automations of their home, without a university degree in computer science. But there are no reason for flows not be Turing complete. All flows will be the same, you just add. the possibility to have arguments/parameters.
/MS
1 Like
Well I have no trouble trying since I have a master in CS, but I do not only suggest this thing for my self. I wish the masses would have a Turing complete flow language. That would benefit not only a few but the majority of flow creators.
1 Like
Do you have any use cases where “the masses” would need this then, that they couldn’t implement with flows only? As @robertklep suggested, the use of variables will compensate for the lack of it, even though they are global. This would be a bad solution if you’d like to use recursion or trigger flows really fast after another, but both are ill advised in Homey and the latter is actively blocked (effectively blocking the first too).
ps. I doubt the language is Turing complete with these additions (too lazy to check), and I also doubt the masses would care. I haven’t run in to any serious deficiencies because of it, hence my question: what actual problems would it solve?
1 Like
I also doubt, like @Edwin_D, that the “flow language” will suddenly become be Turing Complete just by adding the feature to pass arguments to flows.
Indeed, there is no way with the Start a Flow and the A Flow is Started to pass along arguments.
Mainly because all arguments in a actioncard are always mandatory.
So, if Athom changes the Start a flow Action card; which arguments types and how many would the have to implement?
That is what i did with HOOP.
Did you take a look at H.O.O.P. (Hope) - Examples - Tutorials - Homey Community Forum (athom.com)
In particulair : Method flow | Homey
This flow can be called with 2 text arguments.
Gedeelde Flow | Homey
Or this one, it has 3 texts and 1 boolean arguments
And unless i am mistaken; this is precisly what you want: creating and calling flows while passing arguments, reducing the need for multiple flows and solving the asynchronized issues default flows have.
If this is not what you meen (flows able to pass arguments), please explain (again) what it is you want; maybe i can build it into H.O.O.P…
1 Like
I dont really understand this response: You don’t need to write javascript to use HOOP.
You just use flowcards of the right argument type.
These are the triggers available (and more):
Those can be triggered with condition/actioncards:
No need for JavaScript at all.
And you ofc can pass along tags.
Just to be clear: HOOP does not require you to really program; it turns flows (through the floweditor) into “programmable” objects. But you still only use the flow editor.
It just gives possibilities like:
- Start flows with parameters
- Start flows Synchronized
- Await (a started flow)
- Error handling (tag) and stacktrace (tag)
- If-THEN-ELSE within the conditional part, nested and as many as you would like; not just one if-or-or statement.
- Run any actioncard as conditioncard
The simplest use case is where you would like to effect a collection of devices with, for the sake of argument three parameters, let’s say hue, saturation and intensity.
As you argue the global parameter is an option, but an ill such. What if you have 10 different scenarios of said parameters with 2 groups of devices you like to control separately that would need 30 global variables.
There is an option to create 30 flows but that is also a bad solution. My tests indicate that the selections of which flows are to be executed are done by iterating over alla flows and would slow down the Homey considerably.
With the possibility of parameters just two flows are needed and that would. take care of even 1000.000 possible scenarios of hue, saturation and intensity.
I am not after recursion or fast execution, as this can be accomplished today by calling flows without parameters and using a global variable as a bailout.
PS As for the Turing completeness, it is easy as all functional languages are turing complete and functions with parameters would render flows equivalent with recursion. DS
I think that Athom created flows in the hopes of circumventing another of Turings theorems, the stop problem, and opted out of real functions in calling flows from flows. But the point of that theorem is that you can not opt out. You are stuck with the possibility that a program (flow) can execute forever and there is no way to predict or control if a program (flow) is done or not, and that is very bad for an event driven applications that should run for days or even months on ends.
/MS
As I said to @Edwin_D a language is considered turing complete if it allows for calling recursively with parameters, eq functions. That my friend should be common knowledge among CS scholars.
Yes I have. And I have used it extensively until it broke my whole set up and flows. Groups stopped working and devices left groups etc. It might be stable but that does not mean it is without bugs.
The support for recursion isn’t mandatory for a system to be Turing complete (but hey, I only have about 35 years of experience as a programmer, so what do I know…). FWIW, Homey will stop flows from being recursive, even if they would accept arguments.
But this entire discussion has a big XY smell to it anyway: you want easier flow construction and have focussed on Turing completeness (or lack thereof) instead of accepting that what you want is already present (just not in the way you want it).
You are right, a language does not have to be recursive to be turing complete, there are other options too. but you said you did not believe parameters/arguments to flow would render flows Turing complete. But I just have show one example for it to be true, not all.
I am trying to suggest a simple and better solution to a common problem and todays solution. There are plenty of idiotic examples of bad solutions to the same problem. I remember a academic language called Brain Fuck (BF). As the name applies it is totally impossible to program in but it isTuring complete. It even has a translator from C to BF. But that does not make it a good solution.
I am not trying to argue that there isn’t a solution to the problem already, just that the current solution is not as good as allowing parameters. It would not break any existing flows, it would still allow for sub par solutions but usher in a new paradigm in flow design.
Why are you so against an extension that is non disruptive and extends the utility of flows, just because there is a solution present today that is more error prone and takes more effort to achieve than my suggested solution?
And common knowledge among scholars is also that having feathers does not make you a bird. Your assumption that Homey is a functional language is therefore almost Turing complete is lacking.
Also, Turing completeness does not state accomplishing anything should be fun or easy or practically useable. You can make a Turing Complete language that is awful and you can make brillant languages that are not turing complete.
Homey is not a general purpose computing device, so it doesn’t need to be turing complete.
1 Like
I’m not, I’m against the proposition that adding that extension would suddenly make Homey’s flows TC.
It wouldn’t be too hard (especially for a master in CS like yourself) to create an app that would implement your idea.
Well I dare you to argue against a functional construct with parameters and recursion not being Turing complete but that is another thread in another forum.
I used Turing completeness as a selling point not a requirement, but rather a nice side effect of applying parameters and arguments to an already functioning paradigm.
As I said earlier I gave an example of a language that is Turing complete and unusable so there we agree.
I am not trying to make the flow paradigm of Homey into a general purpose computing device. Just make it easier to create elegant solutions.
