Page 1 of 1

Better Conditions?

PostPosted: Sun Jun 11, 2017 9:52 pm
by jltnol
Seems to me I accidentally ran into a plugin or some better/fancier way to evaluate conditions... kind of like if this is the case, do this, but if THIS is the case, do that.

Am I dreaming, or is this a plugin/adition I can't find?

Re: Better Conditions?

PostPosted: Mon Jun 12, 2017 12:24 am
by CliveS

Re: Better Conditions?

PostPosted: Mon Jun 12, 2017 4:57 pm
by jltnol
YES!


Thanks!

Re: Better Conditions?

PostPosted: Tue Sep 19, 2017 12:06 am
by agame
Having just completed my first few (successful!!) attempts at manipulating Indigo variables in scripts, for the purposes of establishing a more sophisticated condition on a trigger, I can only say this seems way more obtuse than it ought to be. Especially given the need to manipulate values from strings to integers and back, and so forth.

I've seen at least one plugin that allows simple math to be performed (e.g. adding several variable values) through a configuration dialogue.

Even Vera provides a relatively straightforward (non-programatical) approach (e.g. in PLEG) [sorry for the comparison].

Has anyone written a condition generation dialogue that allows basic math? For instance adding a value to variable or calculating the difference between two variables. Must be a common requirement?

Obviously all achievable fairly easily once the python barrier is broken through...

Re: Better Conditions?

PostPosted: Tue Sep 19, 2017 9:13 am
by jay (support)
To be clear: your issue is that the condition editor is limited in what functionality it enables, correct? Your use of "obtuse" is a bit confusing as it could also imply that the condition editor itself is difficult to use to configure it's current functionality.

Can you provide some specific use-cases rather than just generalizations? When we once again revisit the condition editor it would be nice to have some firm examples. No time estimates when we'll be doing that, but providing concrete examples along with a feature request is usually a good idea.

Re: Better Conditions?

PostPosted: Tue Sep 19, 2017 4:19 pm
by agame
okay, here's an example. I'll use the bathroom fan since its fresh in mind.

Say I want to switch a fan off when humidity level has stabilised at within 5% of the value at which it switched on (that value saved as a variable).

at the moment I can't (I don't think? or am I missing something?) test a condition 'less than variable + (value x)'so instead I have to create a new variable (old humidity + value x) for the comparison. not hard but requires manipulation of variables in python which must be a barrier for many.

obviously the whole equation could ideally be constructed in a point and click dialogue... e.g. ' true if (old_humidity +5) - current_humidity >= 0'

thats basically what the aforementioned PLEG supports. the IndogoPLOTd plugin goes a long way toward a similar outcome but only for charts.

Re: Better Conditions?

PostPosted: Tue Sep 19, 2017 4:42 pm
by jay (support)
Thoughts: first, you're actually describing a triggering event (you want it to fire when humidity level becomes less than a calculation based on a variable value). This isn't a condition but rather an event. Further, if you know the value at which the fan kicked on (because you coded the value into the the triggering event) then you can just use that as the basis for the calculation, and then use a normal device state changed trigger to turn the fan off.

Second, you're saving off the humidity value to a variable when you trigger - instead, it seems like you'd save off the calculated target value into a variable rather than the start value. This would be an action rather than a condition (and there may be a plugin that does that but I don't recall what it is).

So, based on this use-case, I don't think you're looking for calculations in conditions, but rather calculations as part of events and/or calculations as part of actions. Is that a fair assessment?

Re: Better Conditions?

PostPosted: Tue Sep 19, 2017 5:22 pm
by agame
Um, no it isn't, because my trigger for doing the evaluation is a change in current humidity level. The action is to switch off the fan if certain conditions are met (I described only one). Your logic could achieve the same outcome, of course.

I can't just use the 'trigger-level' humidity value as a threshold - because my fan will never switch off if there's been a movement in the ambient humidity level in the house that prevents the bathroom humidity returning to the former level...I need to allow a few percent or there will be situations where the fan runs for a couple of days. So a bit of simple maths is required somewhere.

(I'm quite happy with the implementation I have working here..it works flawlessly so far...my comment wasn't a query about the logic, but an observation / sanity check on whether achieving (IMHO) fairly basic conditional scene functionality where calculating a value is required should really require tackling python. I'm personally not phased by simple scripting but I think this jars with the otherwise simple and intuitive interface you've created...).

So... underlying point you make is a good one...your alternate approach illustrates that calculations on variables are likely to be a pretty routine requirement across more than just conditions...for which a simple UI could remove a scripting requirement in many simple cases...(?) am I making sense?


Sent from my iPhone using Tapatalk