Yeah, saw it, and used it.
1 Like
First, great app.
But I want to report an issue.
I have a spline with a maximum value of 1,00.
I have a flow that captures the query value and writes it to a logic # value.
Then when the value should rise to the maximum value, the actual value written to the logic is higher then the maximum value. I have noticed this with both Homey Logic and Better Logic, although the Homey Logic is slightly less going over the max value, currently 1.09 where I have seen 1.45 at Better Logic. As this value represents a percentage, the flow using the logic can’t handle that value.
What should I change?
Or do you have another suggestion?
@MadMonkey
What happens with the spline curve when you increase the maximum y-value to 5?
I think that the spline is a nice smooth curve.
I just checked again, the value of the logic has now increased to 1.52.
Which would translate to 152% while the flow that actualy uses that value expects a maximum value of 100%.
For now I have changed the flow, so at least light turns on.
Enhancement request.
The possibility to define step size.
When Y is from 0 to 360, but does not allow anything else then whole numbers, it would be nice to be able to set a stepsize of 1 for the Y value.
The same goes for a Y value from 0 to 1 with a stepsize of 0.05 (which would most likely by 5% intervals).
many regards
Splines are smooth lines/functions, perhaps that even though in your example the graph gets capped at 1.0, the calculated value doesn’t. You could try to create a spline that has no “flat line” at the top, to see if that is the actual problem. I guess that eventually the calculated value must be capped off at max-Y.
@MadMonkey @robertklep
I have capped the maximum value in the spline values itself to 0,95 (95%) But it still goes over the max set value, and it increases a little with every query.
So this appears to be a real issue.
Trying the following now, so if that changes behaviour.
In stead of having a straight line with same values for several hours, I will create squiggly line varying between 0.90 and 0.95.
Let’s see what that brings.
The graph is still showing a flat line at the top. What I think may be happening is that the spline is interpreted like this:
That is quite an interesting theory, I will see if the value decreases after 14:00 today.
If not i will add some data points and set a different value between 9:00 and 17:00 for every hour. So tomorrow I shouls see something from that.
@Twan_Veugelers, I can reproduce the issue.
What I don’t understand is why you get a different value with Better Logic than with the Build-In logic?
The suggestion made by @robertklep is absolutely correct, I see a decrease of the values after the top of invisible arc has passed. So the app continues to calculate the arc, although it show cap it at the max value.
Great idea to actually log the queried value, I can do that as well.
Forget this remark, as it probably was just a value at another moment. And I have never written the queried value to both at the same time.
I suspect so too, but is it wanted that way?
Or is it a mistake @MadMonkey?
Because the app is really great! 
I would personally think that the line shown in the graph is what determines the output values.
But then it becomes almost incalculable and causes errors. A dimming level above 1 will cause an error, probably.
One possible solution could be:
– Set query interval to 15 minutes, for example.
– Set an X/Y value every 15 minutes
But is this wanted?
I can confirm, if the dim level goes above 1 the whole flow fails, with ‘out of range’ error.
1 Like
This should be fixed now. I’ve tested it with the Splines app. Thanks for reporting this issue.
Hi @Jero
What is fixed? In the thread for this app, 2 issues have been reported, one with the app itself, one with finding the value to be used as tag not being in the HWA while it is available in the phone app.
Seeing that no new version of Splines has been released, I guess that it is related to the HWA issue.
Yes related to tokens in the web app. Should have clarified that 
Just checked it, and can verify that the tag can be selected now.
Thanks for reporting the fix.
