That’s probably related to a known blip in the rules templates system. I thought I had fixed it previously. Sorry about that. I have now applied a fix. If you delete the rule template and reinstall it you’ll get the updated version and shouldn’t have this problem when you create new activation rules.
Hmmm, sorry about that. There really isn’t that much naming involved here: You need to create one string proxy item. If you name it Rule_SceneModify then you don’t have to set item parameter for the widget. If you want to name this item something else, then you just have to make sure that you set the widget parameter to whatever name you gave this proxy item.
I’m quite open to suggestions if you think there something I can do to make that more clear.
This is doable. I didn’t do it on this widget for reasons that I’m sure made sense to me at the time…
If you look at the widget and rule code for my Bayesian sensors, you’ll see that there’s a mechanism for creating the items. Implementing something similar would fit this system as well. I’ll try to find some time to work on this.
I’ve spent quite a bit of time thinking about this (probably more than I should have). This is actually a lot harder than it sounds using the widgets. As you point out determining what to use for which item produces a ton of extra baggage in the widget. There’s no way to dynamically define what a component is. So, in this case, for every device listed in every scene every possible input widget would have to be included and depending on what the type of this one item actually is all the inputs that aren’t appropriate would be hidden…
On top of all of this, the widget actually doesn’t even get information about the type of each of the devices, just the name of the device and scene setting for the device from the scene metadata. The entire metadata system would have to be reworked to add that type information.
The devices are listed by passing the array returned from the metadata into an oh-repeater. At present, there is no way built-in way to sort the output of the oh-repeater.
I did, however, have the kernel of an idea the other day while working on a different widget. I haven’t tested anything yet, so no promises, but I may have a workaround that could achieve this. Stay tuned…
See the comment about about the widget not knowing the item types. It might be possible to build a giant, nested conditional that runs enough different checks on the actual state value to work out basic type info, but it would be pretty absurd and probably not able to capture all the different built-in types.
Manually setting DateTime objects is somewhat unusual, especially as part of a scene, so I didn’t bother to include it originally. That said, there is nothing about how the rules work that should exclude DateTime items (I’m 95% certain); it’s just that the item selector dialog doesn’t have a button for isolating those item types. You should still be able to type the name of the DateTime item into the search box and select it.
The same is true for any other item types (ok, image types probably don’t work at all since the rules don’t manipulate the raw states, but why would be be using a scene to set and image item?).
Again, this is mostly limited by what one can do within the widgets. Here is the “simple” filter logic as it currently stands:
filter: "((!!vars.filterSwitch && loop.ohItem.type=='Switch') || (!!vars.filterPlayer && loop.ohItem.type=='Player') || (!!vars.filterDimmer && loop.ohItem.type=='Dimmer') || (!!vars.filterRoller && loop.ohItem.type=='Rollershutter') || (!!vars.filterColor && loop.ohItem.type=='Color') || (!!vars.filterNumber && loop.ohItem.type.substring(0,6)=='Number') || (!!vars.filterText && loop.ohItem.name.includes(vars.filterText))) ? true : false"
Including other factors further complicates that at a nearly exponential rate, if the desired complexity is even available with the limited widget expression parser.
This might be doable; that information is easily accessible in the data returned by the API.
There’s no reason reason to try and implement this (even if it were possible which I doubt). This is much more elegantly achieved via proxy items. Just set your rules to run when a proxy item receives a particular command and have that proxy item be one of the scene devices.
I’m not sure I completely follow what you’re describing here, but it sounds like you don’t have to really modify this system at all for this. Just add the state of your VACANT item as a condition to any of the scene activation rules that you would like to be dependent on occupancy.