Commands, states and comparators in experimental rules engine

Hello everyone,

I am having some trouble with generating rules with Paper UI and have some questions about how this currently works. Lets start with an example first:

Lets say I want my Lights to turn blue, if Temperature drops below 18°C, but only if it is later than 6 pm. (Just imagine it is something worth doing :laughing:)

Now when I create a trigger it looks like this:

Regardless which Item I choose, I can check on the states ON/OFF, OPEN/CLOSED, UP/DOWN.

When adding an action, I get the same types to send as commands to my light bulb:

And at last, when I add a Condition, I can compare it using <,>,<=,>=,= with the same 6 states as above.

My issues with how it currently works are the following:

  • Concerning the trigger, I am slightly confused, that i have to set a state at all, since I would expect, that any evaluation of the actual temperature would take place in the conditions part of the rule. Even more confusing is that none of the given states make sense for a state of a temperature.

  • When adding the action, I would expect that the available commands depend on the given item. So if I select my light bulb, I can send something like hue = 200, saturation = 20, brightness = 254. Or just ON/OFF which is already available. I would not expect the types OPEN/CLOSED, UP/DOWN.

  • Now at last when adding the condition, I would expect a different operator depending on the item I chose. For Date and Time I would rather expect operators like BEFORE/AFTER/EQUALS. And instead of the 6 given states, I would expect an item that lets me chose a time.

Now my questions are:

  1. Do I understand this correctly, that the triggers have been designed that way, so they dont trigger the rules as often as they would without any evaluation of the state of the item?
  2. Would it be possible to add a feature, that the UI gives you better command options for the actions?
    So for example I click on the command SET_STATE when I selected my bulb and then I can set the parameters for the bulb as RGB or HSI values?
  3. Would it be possible to have dynamic operators for different item types for better comparison?
  4. Would it be possible to dynamically change the type of the compared state? So when i want to compare a date_time value, i get to enter another date_time value in the compared state using a time picker like in the “it is a fixed time of day”-trigger option.
  5. I found a lot of types in the org.eclipse.smarthome.core.library.types package. Are those the ones used for the default options?
  6. Where could I change which options are given by default?

Now if you made it this far reading this, you are my hero and I would really apreciate your help :slight_smile:

I’ll start with the caution that “Experimental” is in the name for a reason. It is not complete and only available for experimental use and testing. There is no documentation and it is not feature complete.

You don’t have to provide the State. Just leave it blank.

You can type in the state for String and Number states. So if you did want to trigger when the temp gets to a specific number just type in that Number.

The UI needs some work.

For a Color you can use 200,20,254 as the command.

As for the rest, the UI needs some work.

Time operations and I’d venture to say DateTime Items are not yet fully supported.

They are not designed that way. The state is optional in the triggers so you can reproduce Rule triggers like one uses in the Rules DSL along the lines of Item MyItem received command ON. Leave it blank and the Rule will trigger for all commands, not just the one defined.

Probably. It’s still a work in progress, experimental. I don’t know what is planned for or what needs to be requested. It wouldn’t hurt to create an Issue over at Eclipse Smarthome.

ibid

ibid

Probably

Don’t know if you can.

Beyond what I’ve mentioned above all I can offer is that the documentation for the Experimental Next-Gen Rules Engine was essentially started two days ago. I don’t think anyone on this forum really knows how this all works yet and it is very important to realize that it is not done being developed.

Sure, my post was not meant to be criticism, I’m just trying to understand how things currently work and to avoid missing any functionality by accident.

Ah yeah, that makes sense. So in case I wanted to check if it is at a certain temperature i’d type in that Number. If I wanted to check if it is below a certain Number I’d leave it blank and do a separate check in the conditions section.

Actually I tried that, but I seem to have run into the bug you mentioned:

Pointing this out really helped me a lot, thank you! I made sure now, that this is the case for every Rule I’m testing with.

Alright I will do so! Also when looking for the origin of these default values I found that in /rest/module-types the same values appear.

Thanks a lot, this is really useful to me! :slight_smile:

Correct.

As you learn to make this work, if you have anything you can add to the posting I started it would be greatly appreciated. I made the post a wiki so you can just go ahead and edit it.

Sure, as soon as I understand more about it I will! :slight_smile:

Right now I found out where the default values come from. The rules consist of Modules. These have a ModuleType, which provides information about the module. Paper UI accesses these Types through the Rest API, where they can be accessed through /rest/module-types.

The currently available module-types are defined as .json files in the package org.eclipse.smarthome.automation.module.core in the ESH-INF/automation/moduletypes folder. It is possible to add new module types through OSGi Bundles as can be seen in the ESH Documentation. So adding module types with .json files seems to be the way to go.