Configurable scenarios

[rlkoshak (Rich Koshak)]

@villaRob

what needs to be possible to change in scenario setting by UI ? Eg: - Such as lights switch off / on - Dim level of dimmable lights or color of rgb lights - Any delay between commands - Voice confirmation to the execution order (for example scenarios that perform actions that are not readily or easily verifiable) - ??

So here is the problem. This is a universal problem in Home Automation and other areas where:

1. We want automation that is flexible to do almost anything we can think of
2. We want the automation to be configurable
3. We want the automation to be configurable by non-technical people

Unfortunately many people do not realize that 1 and 3 are incompatible with each other. Flexible automation means coding (sure there may be cool GUIs and such but at the end of the day its coding) and coding is not friendly to non-technical people. So in order to get to 3, you have to limit the flexibility in 1.

There are lots of ways to do that and you are presenting one option (your option 2 doesn’t really say anything about what you would implement or how you would do it differently in jython verses the Rules DSL). The biggest challenge though will be defining a set of configuration parameters and presenting them in such a way that they do not overwhelm the non-technical user on the UI.

For scene activation, I’ve actually implemented something similar with my lighting, only on a much simpler scale. I don’t have dimmers, everything is triggered based on time of day, and I don’t have configuration parameters. The full example with code is here:

Automation/Orchestration Design Patterns

I’ve debated whether to continue this thread or to start a new one and decided to add to this thread. Ultimately this will probably be added to the wiki and/or included in the OH 2 user’s guide. So, it has been several months since I posted my design patterns above and as I’ve refactored things I’ve come up with some improvements which I will post here. Time of Day Design Pattern In the original above I use Switches to represent the current time of day state. This made sense at the time becaus…

The tl;dr of it is I define a set number of “times of day” which represent my scenes. I then create an ON and OFF group for each time of day and add which lights I want to turn ON or OFF to the appropriate groups. In my rule I grab the appropriate group based on the value of my TimeOfDay and PreviousTimeOfDay Items and loop through them turning ON or OFF the lights as appropriate.

To start to approach what you are looking for I would add:

• First the TimeOfDay rule needs to be updated so it no longer assumes that everything is a Switch. The instanceof command will be useful here.

    if(item instanceof SwitchItem) // do switch stuff
    else if(item instanceof DimmerItem) // do dimmer stuff
    ...

• Next you need to create Items to store the configurations. Follow the same pattern illustrated above: create a Group to store the config Items and name the configuration Items so you can grab an Item’s config through its name. For example, if you are in Scene1 you can construct that Item’s configuation Item with something like:

val configItemName = item.name+"_"+ScenarioNum.state+"_Config"

Then you can grab that config Item out of the configuration group using:

val configItem = gConfigItems.filter[cnf | cnf.name == configItemName].head

Depending on the type of the Item you can then cast configItem to a NumberItem or SwitchItem or StringItem depending on what sort of Item you need to config the device.

• Then just send the configed value to the Item.

• To control which Items are a member of which group you can have a special config Item for each device that lists the groups Scenes its a member of. In the rule just check to see if the Item is a member of the Scene and proceed accordingly.

This can all be made completely generic so you need only the one rule. But Grouping and parsable consistent naming of Items is going to be key. You need to put Items in a Group so you can pull them out by name and you need to name Items such that you can construct the name of its associated Items (e.g. config Items) programmatically.

So the “server side” of what you want to do is pretty well handled. It will require a good deal of careful coding and tedious Items file configuration but very doable.

One gotcha you will face is you will need a way to bootstrap the values of the Config Items. I handle this by setting up persistence on the Config Items (a good idea as you don’t want all your configs to go away on an OH reboot) and temporarily writing a System started rule to initialize the Items with their first values. After reloading the rules file I remove the System started rule.

The big problem, as I stated above, is presenting all of these configuration parameters to the user in a way that is intuitive and not overwhelming. You need to think long and hard on this part of the problem because this is where the real challenge is. Remember the more options you provide to the user the more complicated your UI will become and the less friendly it will be to non-technical users. You will have to balance between what options you allow to be configured and the complexity of the UI.

Personally I would probably go the PHP route as you will have more flexibility in how you present the options. I would use the OH REST API to get current configs and to set new ones when they are updated. If you stick with the OH UI, I would probably greatly reduce the number of options that are configurable so you don’t have pages and pages of options. You will probably want to limit how many scenes are permitted in any case as each scene will grow the size and complexity of your config UI greatly.