Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rules sentences can be cryptic #1862

Open
flatsiedatsie opened this issue May 7, 2019 · 2 comments
Open

Rules sentences can be cryptic #1862

flatsiedatsie opened this issue May 7, 2019 · 2 comments

Comments

@flatsiedatsie
Copy link
Contributor

flatsiedatsie commented May 7, 2019

I really like the attempt to turn rules into human-readable sentences.

However, these are some of the rules I'm ending up with in practise:

IF Smart lock is Door 2, set Signal Hub Replay 1 to false

Ideally that would be something like:

If on Smart lock -> Door 2 is locked, then on Signal Hub set Replay 1 to off.

The improvements that would help might be:

  • Add a 'then' separator too?
    then

  • Perhaps this is already implemented, but: allow binary devices to set a unit, and use this to name the states. So Door 2 as the 'true' state could become `Door 2 is locked'.

  • Move the 'set' to in between the device and the property for actuators? So set Signal Hub Replay 1 might become ,[ then ] on Signal Hub set Replay 1 [ to on ]

  • Create some way to visually show that Smart lock is Door 2 is a device and a property mashed together. Something like `Smart lock -> Door 2', except that using characters like that might confuse people to read 'bigger than'. Similarly for just using a dash, that might make people read 'minus'. So I don't know the solution. Perhaps just making the device name bold.

Another example if this is with my device called "Temperature and more", which measures a few things, temperature being the 'main' thing.

If Temperature and more Temperature is greater than 24, notify with message "Hot in here"

Here it's mostly the rough concatenation of names that is a little jarring. See also the issue of the name-property concatenation in logs.
#1815

@hobinjk
Copy link
Contributor

hobinjk commented May 7, 2019

The "Door 2 is locked" part is adding support for new @type values. There's already partial support for @type OnOffProperty so it's just a matter of covering the rest (e.g. type OpenProperty for making the boolean open/closed).

I agree that visually distinguishing thing name from property name is a good idea. I don't really like using arrows because it doesn't echo the lines of the thing detail screen but on the other hand an em dash just suggests an Emily-Dickinson-style aside.

One alternative to direct concatenation is to just add an apostrophe s to the end of the thing type and hope that it's not dramatically incorrect. For example, "Temperature and more's Temperature." To invert it, this could also be "Temperature of Temperature and more." I'll add the possessive to test it out because upon more thought people are probably lenient enough about grammar that the "thing's property" successes will outweigh the "plural names's property" failures

@flatsiedatsie
Copy link
Contributor Author

Cool. I also think that adding the 'then' to the sentence would be a good idea. A lot of people are getting familiar with the "if-then" concept from things like IFTT and programming courses.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants