jimtng

> > The "core." part of "core.ItemStateChangeTrigger" is meaningless to the end users and the "Trigger" part is redundant. > > +1000 OK, having thought about it again and re-read...

> create a "short code" for the most commonly used typeUIDs is one. We could also for example define that if it is "unqualified" (lacking e.g. the `code.` prefix), it...

I'm not sure if it's easy to implement it, so this is just an idea: Given a list of keys, first try to match them against "module parameters" then apply...

About the structure, which do we want? ``` triggers: - ItemStateChanged: item: My_Item state: ON previousState: OFF ``` In @rkoshak's example, he puts the `item`, `state`, etc under the same...

> I feel that it would be safest to allow IDs to optionally be specified, so that the rule is "an exact copy" of the source. I agree. So perhaps...

> The problem with this is that the parser has no idea what are valid "parameter names"/keys for either. The parser doesn't have any information about the class that implements...

Yup, I didn't incorporate the split back to a separate configuration section. So this is the one I think, which is basically the same as it is now, except the...

oops wrong, rule name is not the uid... it is indeed the label, sorry!

I am unfamiliar with the whole marketplace rules / templates. How does this connect with the marketplace stuff, or is this a separate thing?

JRuby helper library currently already offers a `toggle` method for `SwitchItem`. If the item's state is not ON (which includes OFF, NULL, and UNDEF), send an ON command. Otherwise, send...