CoRE and Piston Rules Engine, first design steps

Though similar enough in purpose that I think perhaps the Cube should be turned into a multi-Button Device Type. Just go all the way and make it emulate the first 6 buttons of the Minimote (4 pressed, 2 held), then it would be instantly usable with anything that supports the Minimote, such as Button Controller and Smart Lighting, Rule Machine, etc…

2 Likes

Now, that reminded me to see what happened to the “Cube” by the German studio Family of the Arts…

Looks like still a cool prototype :frowning:

2 Likes

Talking about buttons, I can see a rule that waits for a specific sequence of buttons pushed/held. Passwords/key combinations that trigger events. If only they made a keypad I could use outside for the gardener to enter a password so that the alarm doesn’t kick in while he’s mowing the lawn. Temporarily disable outside sensors… Kind of…

1 Like

Wow… Now you’ve got me wondering if the SmartThings accelerometer is sensitive enough to measure rotation around the Z-Axis (ie, kept flat… Just turned). That is the most common use case in the video. Great for dimmers and audio volume…

1 Like

I wrote a SmartApp for this… ButtonsAsPIN.

2 Likes

Cool, it could be integrated into the rule… with your permission, of course :slight_smile:

2 Likes

Depends on how you going to use it. If it’s just mood cube, where the face that’s up is what counts, then that’s six buttons.

But if it’s the way @ady624 initially described it, you have a lot more possibilities. Even if you limit it to 90° shifts, there are four rotational shifts for each of the six top face possibilities.

And of course if you allow for anything other than 90° shifts, It’s obviously a much higher number.

It’s sort of like the dimmer problem. Do you limit the choices to three presets (low, medium, high) or do you treat it as an adjustable scale? the UI is very different.

Most tilt sensors, for example, are essentially using using the preset concept, and that’s only rotation on one axis.

The mood cube, obviously, is another preset model, and even so, you can see how the number of “buttons” adds up fast. :sunglasses:

2 Likes

While working on the time selection for conditions, I came to the following dilemma: I know RM will assume “time between 9pm and 6am” means “past 9pm or before 6am”. And I feel the same way. I have been using the terms “inside range” and “outside of range” for numeric values. Since the numeric range is not repetitive like time is, if one says “is inside range 90 - 70” then I swiftly swap the two numbers while performing the evaluation. This is obviously the opposite of what the same would mean when dealing with time. Should the numeric comparison “is inside range” do the same, i.e. larger than the first or less than the second parameter in this case? Or is the word “inside” strong enough to imply that whatever way you enter the two numbers, the value has to be between them?

It’s only when dealing with time where the word “between” magically means anything but “inside range” and I believe the same meaning should be preserved (i.e. between 9pm and 6am means at night). I am most likely going to use the words “is between” or “is not between” rather than the range I’m using for numeric values. As for triggers, I believe time should only have one: “reaches”. Time can’t enter a range, can’t drop below, can’t raise above, can’t do a lot of things, right? :slight_smile:

1 Like

I think this is most expressive…

1 Like

Yeah, time is pretty much set. The question is about the numeric comparisons “is inside range” and “is outside range” when the first parameter is larger than the second parameter. The UI does not let me enter a minimum … wait a second… I may work something out.

1 Like

I would think sometimes using a maths expression might be easier?

Within range: smaller <= or greater >= or not != trying to express this with normal language might be difficult and less universal dont you think?

Why is plain English less universal? If my mom read “less than or equal to” she’d understand, but if she saw “<=”, being how she has no programming background, she’d freak out. Same goes for “==” and “!=”. I think we’ve already established that using words is user friendlier.

I agree, for programmers, it may be faster to locate “!=” than “is not equal to” in that list. But we’re not all programmers :frowning:

The mathematical symbols are ≠, ≤ and ≥
But then again, how many people won’t know them?

Well I bet less than people who dont speak english … Just saying … This would require that you need to translate every visible string, need to consider translated char lengths etc which could cause the ui to break for simple things like this

Unfortunately, ST does not offer key/value pairs in the input elements, which means the text itself makes it as a value into the settings map. This pretty much makes translation impossible (think Monday, Tuesday, etc.) If I am to suddenly change all texts to a different language, if I had the patience to translate it (would this be the first app in a language other than English?), then all the fixed name-representing strings would break. Just like that, puff. So I think translation is a bit out of reach with the current ST app model.

Any other supporters of <=, >=, !=, ==, etc. here?

Ha I didnt know that either - I assumed the ST app was multi-language but just changed to a different language and back to see it actually isn’t so that potentially eleminates my concern …

I think I prefer the symbols, but my wife would prefer the words. I do like how it appears as a nice sentence with the words as well.

It’s good to think forward though, they may bring multi-lang in the future. But for now, the lack of key/pair pretty much ruins it.

1 Like

You have to do words even though I want symbols.

2 Likes

How about “Less Than or Equal To <=” both only adds a few characters right?