Extending states with attributes

[cdjackson]

For OH3, I think we should take a serious look at how states / commands are defined. We've had the legacy system for 10 years now, and I personally think it's creaking at the seems and limiting the way we can run the system.

Currently, we have a single dimension in the state - e.g. ON/OFF, a single value, etc. This is fine for basic information that goes to a user or UI, however, in many cases further information is required (or at least, is provided from the device sending the state) to fully describe an event. While this information may not be of primary concern, and may not be used in a UI, it is useful for triggering rules/scenes and I feel it would be useful to think if this could be attached to the state event.

A few use cases -:

• A ZigBee light can provide a transition time - ie the amount of time required to move from ON to OFF. We want to be able to define this attribute, along with the state.
• Z-Wave scene controller can can send a scene 'command' - this usually has a number of attributes - the scene number, but also the keypress type (KEY-DOWN, KEY-UP, etc), and sometimes a time is also provided. This is currently handled by defining a number - (scene number).(type) - e.g. 6.3 might be used for scene 6, keydown - we ignore the time so the device can not be fully utilised.
• An alarm can have a type, and a state. Instead of implementing 25 channels for 25 different alarms, each with an on/off condition, it might be more convenient to provide a single Alarm channel with on/off state and alarm type attribute. The UI can show there's an alarm (i.e. showing the channel and it's state - as we now have) but a rule would be able to look at the attribute and decide exactly what alarm type this is and act with the appropriate response.
• A smoke alarm can go into alarm - we want to show this on the UI, however the notification rule that rings the fire brigade probably doesn't want to do this if it's a test - we could add the "Test=true" attribute so that the system can work around this.
• A door lock can have the state ON or OFF (LOCKED or UNLOCKED) but this can have attributes such as the reason it changed state (eg the user who opened the door).

Of course there are always ways around this with the current system - we can concatenate data together(e.g. alarm type number x 100 + alarm value), or we can use two channels, but then the rule has to resynchronise these two streams. Or we can use json strings to hold multiple bits of data which has been the recommendation so far.

I'd like to propose an extension to State updates to hold attributes - ie secondary data that provides context to the primary state.

Currently, we have -:

updateState(channelUID, state)

I believe (following an extremely quick look at the code!) that this could be extended with another parameter containing an object / attribute map. eg

updateState(channelUID, state, object)

eg in pseudo code.

updateState("channel.uid", OnOffState.ON, {"keypress":"down", "time":25})

Likewise in rules, we could have -:

Light.sendCommand(ON, {"duration", "10S"}),

A similar extension to rules would be required to read the attributes. The idea is not to impact the framework - all the generic information required to be system agnostic is still there, but it allows the framework to support the more advanced features that may be provided by systems like Z-Wave (and many more I'm sure).

I've also seen people talking about having things with 1500 channels - I've not looked at why this is, but I do wonder if the above suggest might in some cases allow better channel definition, and possibly reduction in channels (??).

This was originally proposed in ESH but not discussed - it seems to me that OH3.0 should take a good look at improving the command/state/items and I think something along these lines could significantly improve the system.

[kaikreuzer]

I actually think that this has been discussed many times already - and it seems that there are misconceptions in here.
You mix commands and states in your examples. For commands, there is the clear distinction that item commands must be without parameters as they otherwise do not make sense to link to generic UI elements. To have the same channel used with different parameters, this should be done by using channel parameters, which can be set differently for different channels of the same type. For anything where dynamic parameters are required, this only makes sense to be used in rules and for that the Thing actions have been specifically introduced last year.
For states the situation is similar: They exist on items and items are the abstraction layer that is meant to be as independent from concrete devices as possible. Adding arbitrary key-value-maps to them seems to virtually break a fundamental part of the architecture. If we feel that states require more metadata, this should be imho be defined by the framework and be the same for all bindings as its content should really be independent from a certain technology (like "the user who opened the door" - this is on a very functional level and requires a strong semantical link to other core concepts like "persons". It makes no sense to introduce this for 1 of 250 bindings only).
For anything that that is technology-specific, we already have the possibility of defining custom events in place - they are issued from a Thing and not linked to an item, so they live at the right place of the architecture.

I understand that architectural constraints sometimes feel to hinder new features. But at the same time, they keep creeping featurism under control and adding undefined key-value-maps anywhere in an API is honestly the worst choice one can do within a framework.

But back to your concrete use cases:

• Light with transition can and should be done as a thing action
• The scene controller device must have a trigger channel. It is free to define its own event type that includes all details on the button, type and time.
• 25 Alarms: There can be one alarm channel, signallling to the user that there is "some" alarm. Individual alarms can be defined as events of a trigger channel, which can be used from within rules.
• Test flag: There were similar discussions on how rules can be tested without triggering real actions anywhere. Can be a nice feature, but it should definitely be independent of any binding, but rather be implemented in general on a framework level.
• Reason for a change: As mentioned above, this is very functional information and thus should be defined on the abstract level. There were already similar ideas like providing information on "caused by rule xyz" or "caused by manual user interaction" - this definitely makes sense as a feature, but as it is not only about bindings, but also rules or any other source for events, it must be defined in the framework.

[cdjackson]

I actually think that this has been discussed many times already - and it seems that there are misconceptions in here.

Sorry, maybe I missed it, but this message was something i raised on the Eclipse forum a few years back (https://www.eclipse.org/forums/index.php/m/1759688/#msg_1759688) and it received no response from anyone.

You mix commands and states in your examples. For commands, there is the clear distinction that item commands must be without parameters as they otherwise do not make sense to link to generic UI elements.

Sorry if I did not describe this clearly - I don't mix them up, but wanted to present the same concept for both, so the examples do cover both states and commands. As I tried to say in the above suggestion, the main state is the same as it currently is, and therefore still links to the UI element - and the attributes are available for further processing (eg rules etc). The suggestion was for both commands and states to try and consolidate the concept rather then the (IMHO) messy situation we have now.

they keep creeping featurism under control

We are talking about evolving a framework that is now 10 years old - don't you think some "feature creep" is now warranted as we move toward OH3??? I don't really call it feature creep - I'm more trying to start some discussion about how OH3 can improve on the success of previous versions rather than remaining static.

Test flag: There were similar discussions on how rules can be tested without triggering real actions anywhere.

You misunderstood - the test flag comes from the device (if someone presses the test button) - the smoke sensor sends a SMOKE alarm, but tags it as a TEST button. Again, this is just really an example of device specific tags that people might want to make use of. It's very much device dependant though, but from the numerous discussions I've had about trying to support the 1000 ZWave devices we support, people do want this sort of thing to allow them to make bet use of the devices they have spent their money on.

Adding arbitrary key-value-maps to them seems to virtually break a fundamental part of the architecture.

What fundamental part of the architecture does it "seem to virtually break"?

If we feel that states require more metadata, this should be imho be defined by the framework and be the same for all bindings

I think this would be near impossible - trying to agree on the additional metadata to suite all users and all bindings would be nigh on impossible to agree. Maybe we can agree some common ones (such as transition time or obvious things like that) to try and keep things standard where possible, but it's not going to be easy to accommodate features of all fancy modern devices that companies are coming out with now. We would end up still having to use json strings, as you've previously recommended, to accommodate these states, and IMHO this is pretty messy.

content should really be independent from a certain technology

I might agree in an ideal world, but I would argue that we have this already at the highest level. Eg a door sensor in OH is the same for all bindings - but there needs to be a way to provide supporting information that does allow device/technology specific functions. Otherwise we will always be limiting the framework to work with the lowest form of technology.

I really feel that all the different states/actions/trigger channels are a lot worse and much more confusing. It's extremely difficult to shoehorn modern devices into the antiquated OH system and it would really be good to consolidate things moving forward - again - OH3 should be a step change, not just the same old thing (IMHO of course). I want to see OH3 succeed, and am happy to try and help where I can, but I think we need to think a bit more progressively.

There are other issues with the current system - there is no ability to define groups that are sent to bindings (I have a separate issue open on this for a while - #1035). IMHO, we really should have a rethink about these concepts to allow OH3 to run for another 10 years rather than floundering with OH1 concepts.

I guess that this won't go anywhere and you have made up your mind that we will stick with the old system, but I thought I'd try to suggest some improvements as we move toward OH3. If you want to close this then, please feel free if you think there's nothing useful in here.

[cdjackson]

An example of where I think we can improve -:

adding undefined key-value-maps anywhere in an API is honestly the worst choice one can do within a framework

Isn’t this what has been done with Thing Actions? This seems to have exactly this, and this is a good example of where we have multiple ways of doing the same (theoretically simple!) thing - just turning on a light. We have a nice standard OnOff channel - the user can interact with this channel via the Item, but they can’t set the transition time between On and Off. To do this, you recommended using a Thing Action so we can use the key/value parameters - so now the user has two ways to control their device - one through the Item, and the other that is the Thing Action (which can have an associated key/value map to allow us to set attributes).

Don’t you think this is strange? And confusing for users (let alone developers)? Don’t you think that there’s room for consolidation here - to simplify and enhance the system to the benefit of users and developers alike? OH3 seems like the perfect opportunity to do this.

[splatch]

I do believe there is a space and need for this improvement. Either by additional attributes or other more advanced way, whenever works.

For example BACnet supports prioritization of commands from 1 up to 16. First two are related to life safety, and last 7 are available slots for application specific needs. Operator might send command with priority 8 (manual operator) to override priority 9 (automated setting). This means that depending on a context, end device might be commanded with different level. As per specification rule can (and should) use default priority or priority above 8 and privileged user should be able to override it using priority 8. It is relevant as controller retains last received command priority.

I wouldn't mind to have a BACnet specific PrioririzedCommand as a wrapper for existing commands, however as pointed in https://community.openhab.org/t/flexibility-of-framework-supplied-types/ non-core command/state blows up core entirely. I doubt if any of existing mechanisms can mimic necessary logic and information which needs to be passed back to UI to binding and vice versa.

[J-N-K]

@splatch Command-Priority is indeed an interesting option for automation.

sACN (a DMX over Ethernet Protocol) also supports priority but with an extended range (1-200), where the highest is most important. I think that probably other protocols have something similar and we would need to have a way to map that. Maybe something openhab specific (with 5 to 10 different values) that bindings can then translate to the external needed values.

[bobadair]

I’m not really sure what the best solution is, but I have a similar problem with the Lutron binding. Nearly all of the Lutron integration protocol commands allow the specification of fade and delay times. The fade times, as you would expect, generally apply to lighting dimmers and specify the time for the device to fade from the current level to the new level. The delay times apply to many device types and specify a delay before the device starts to fade, switch, or move to the new level.

The current binding doesn’t do a good job of exposing this functionality. The dimmer thing allows the user to define fadeInTime and fadeOutTime parameters, which it passes along in certain cases. The drawback, obviously, is that this doesn’t allow the user to select different fade times on a per-command basis, which is what you would typically want. None of the supported things currently allow the user to specify delay times for commands, as these are only really useful on a per-command basis.

In the past I’ve tried modifying the binding to provide fade and delay channels for each device type that supports fade and delay command parameters, but that isn’t really a satisfactory solution either. For one thing, if multiple threads were to try to send commands with different fade and delay parameters to the same device at the same time, the outcome would be unpredictable.

Lately, I’ve been considering using ThingActions in order to pass commands with fade and delay parameters. However, it seems to me that if many bindings were to do this without some abstraction or standard way of implementing it, it would lead to the unfortunate situation where sending equivalent commands to similar devices handled by different bindings would have to be done in different ways.

[cdjackson]

@bobadair thanks for your comments. What you have presented is exactly the use case I have (well, one of them anyway) with both ZigBee and ZWave bindings. Currently it is quite messy to introduce these concepts - openHAB is simply not able to deal with modern technologies that support these sort of features (and while I say "modern" - these concepts are far from new).

Maybe there is some sort of middle ground to alleviate the dislike of key/value pairs by @kaikreuzer (even if the framework has many already) where we can define standard sets of attributes within the framework for features such as these where many bindings have such a need (much as we have system channels, but allow the binding to derive other custom channels). I am however concerned that trying to standardise this would be painful - you only need to look at other parts of the framework to see how difficult that has been and there must be an allowance for custom attributes.

Maybe in order to provide some error checking, and some level of up front definition, we could extend the channel definition to allow a binding to define what attributes a channel provides up front. This could allow the framework to check that attributes passed by the user are valid, and prevent the system being abused too much by requiring some level of up-front definition.

@kaikreuzer how do we proceed with this? It seems that from the discussion here there is reasonably widespread need - not just 1 in 250 bindings as you suggest. IMHO the framework needs to have a way to support additional information that can be used by users, in rules etc, but also working along side the standard types so that they are presented in a standard way in UIs. Can we add this into the feature list for OH3 (I'm not sure where this lives at the moment?) or define something similar to support this need.

[Hilbrand]

I see similar request for the TP-Link bulb and dimmers. They have the option to set among others the transition time.

I do see 2 different features here. The first is for adding properties to commands. Which is what is mostly discussed here. The current option it to implement it as a ThingAction. My analysis of ThingActions:
+ Can handle multiple channel state changes in one call
+ Can directly be used in rules
- Requires implementing it differently by the binding developer than just handling commands.
- As a ThingAction becomes part of the list of all actions, adding lots of ThingActions would create a large list of actions making it difficult to find a specific action if all you want to do is set an additional parameter for 1 channel.

So I would say there is room for adding new functionality. I think the challenge is to how this should be defined. Having only key-value pairs to be given as additional parameters makes it very hard to create a rule in the UI using this feature or possible have a UI element that can use this feature. I would say to make this possible this can be done by adding it to the thing XML. Currently we have the option to specific channel specific configuration. We could either use this and make it possible to override those values dynamically or introduce new properties or additional arguments to specify they can be dynamically overridden. Then these parameters can be automatically generated for setting in the UI and validated.

Additional to give the user access on a state element (not in rule configuration, but in the control UI, if we want this at all) to these properties so the user can dynamically set values, we could enhance the item configuration that if such a parameter is specified on the item the UI then can show a UI element with the property and the user can than set such a parameter to be send when the user changes the state in the UI. This requires some additional thought and there would be the question about if setting something would be persisted.

Regarding the second feature, the handling of state. I can think of multiple possible ideas, but have no clear idea about it. There are several other discussions about this. What I see here is the issue of having multiple channels being updated and because each channel update is a atomic action it's difficult to handle in rules, if the rule would depend on multiple channels. Maybe this is something to discuss in a new issue?

Also I would not put to much emphasis on what openHAB version it should be in. There is already a lot on the plate of OH3 and I think putting much effort in getting as much as possible OH1 bindings added already can take a lot of effort. Of course if we come up with something and it can be implemented it's fine.

[cdjackson]

@Hilbrand thanks for your thoughts.

Having only key-value pairs to be given as additional parameters makes it very hard to create a rule in the UI using this feature

I'm not sure why? My first post provided just one simple suggestion -:

Light.sendCommand(ON, {"duration", "10S"}),

Surely this can be improved and was just my initial thinking, but I don't think this is too hard?

If you are talking about rule generation in a graphical UI, then again I'm sure some UI wizkids can think of a way of attaching arguments to a command.

Currently we have the option to specific channel specific configuration.

Personally, I would prefer not to mix this up with configuration as configuration descriptions have been around a long time and are well used. I think trying to do this via configuration may break things.

I suggested earlier though that we could define "attributes" in the channel description, so I think fundamentally this is what you are saying - I am just suggesting a new construct to keep things clean. Using a new system also allows these sort of "attributes" to be defined as "core" attributes for as many common things as we can think of that may be used across multiple bindings to afford some level of standardisation to users.

I see here is the issue of having multiple channels being updated and because each channel update is a atomic action it's difficult to handle in rules, if the rule would depend on multiple channels.

I would personally suggest to avoid multiple channels - to me this is a bit of a mess. We've tried this in the past - we end up with a proliferation of channels and I'm not sure how we could synchronise them. To me it makes a lot more sense to have all data as a single entity rather than providing multiple channels with some way to synchronise them.

Maybe this is something to discuss in a new issue?

I'm happy to discuss it separately if we really think it's a different feature? My original thought was to try and keep a similar concept for both commands and states to make it easier for everyone (users and devs). If we were to take your idea of multiple channels for commanding with some way to synchronise them as a single event, we would have lots of channels for (eg transition duration) that are only used for state updates, but we then provide a transition duration in a command in a totally different construct. To me, this seems strange, and we would be better off trying to have a common mechanism for this.

Also I would not put to much emphasis on what openHAB version it should be in.

To me, we have an opportunity here to change things, which in my mind we should avoid as much as possible within major versions.

There is already a lot on the plate of OH3

Where is the list held? I've not really seen anything "functional" other than the UI changes. All other changes are "under the hood" - eg Java updates, refactoring namespaces etc. I don't disagree that there's a lot of work here, and it's not something that I personally am likely to get involved with as it's not my area of expertise. However, putting more things like this "on the plate" may allow them to be picked up by others (including myself).

putting much effort in getting as much as possible OH1 bindings added already can take a lot of effort.

Again, I think that this is likely to be a different set of people - I know it takes time from core maintainers, but if we are focussing our efforts for OH3 on migrating OH1 bindings and not on improving the architecture, then unfortunately I think we will be lost and there needs to be some core improvements for OH3 to keep the framework moving with the times, and not stuck in 2010 with OH1.

[cdjackson]

@Hilbrand I was just re-reading this and wanted to clarify your comment -:

Having only key-value pairs to be given as additional parameters makes it very hard to create a rule

Are you thinking about a graphical rule editor here, and is your concern that with key/value type information there is insufficient description to allow this to be presented in the UI?

If that's the concern, then I think my earlier idea should alleviate this.

Maybe in order to provide some error checking, and some level of up front definition, we could extend the channel definition to allow a binding to define what attributes a channel provides up front.

For example -:

    <channel-type id="door_state">
        <item-type>Switch</item-type>
        <label>Door Lock State</label>
        <description>Locks and unlocks the door and maintains the lock state</description>
        <category>Door</category>
        <state>
            <options>
                <option value="0">Open</option>
                <option value="1">Closed</option>
            <options>
            <attributes>
                <attribute id="unlockmethod" type="Number">
                    <name>Unlock Method</name>
                    <description>The way in which the lock was opened</description>
                    <option value="0">Manual</option>
                    <option value="1">RFID</option>
                    <option value="2">UserCode</option>
                </attribute>
                <attribute id="userid" type="String">
                    <name>User Id</name>
                    <description>The user who opened the lock. Not provided for manual unlocking.</description>
                </attribute>
            <attributes>
        </state>
    </channel-type>

or...

    <channel-type id="dimmer">
        <item-type>Dimmer</item-type>
        <label>Dimmer</label>
        <description>Sets the light level</description>
        <category>Light</category>
        <command>
            <attributes>
                <attribute id="transition" type="Number">
                    <name>Transition Duration</name>
                    <description>Sets the transition duration in milliseconds</description>
                    <maximum>5000</number>
                </attribute>
            <attributes>
        </command>
    </channel-type>

The id could be defined to allow system definitions that are defined for the whole framework (similar to system channels) = eg id="system.transition" to provide some standard definitions where there is a clear need across multiple bindings/systems.

If this is indeed your concern, then I think we can easily come up with a definition to alleviate that through appropriate definition of the allowable attributes in the channel definition. As I suggested earlier, this could also be used to enforce what bindings can provide in the state updates so it's not abused , and could also be used to automatically generate documentation to show the user what is expected (the ZWave binding does this now - generating docs from the channel definition).

[Hilbrand]

Are you thinking about a graphical rule editor here, and is your concern that with key/value type information there is insufficient description to allow this to be presented in the UI?

If that's the concern, then I think my earlier idea should alleviate this.

Yes that was what I was trying to express (English is not my native language, so that might be the problem too 😄). If I interpret how openHAB is intended than to make this possible or acceptable there should be support for a graphical I think. So I think we're on the same page here!

I was actually thinking about something similar what you described. Some thoughts I had related to the xml constructions:

• Instead of putting it on the channel-type I was thinking about adding it to the channel. That way the (current) channel types can be reused, including the system channels. This could be an addition to also be able to do it on channel types. Hhere as an example using your command structure:

<channel id="dimmer" typeId="system.brightness">
   <command>
            <attributes>
                <attribute id="transition" type="Number">
                    <name>Transition Duration</name>
                    <description>Sets the transition duration in milliseconds</description>
                    <maximum>5000</number>
                </attribute>
            <attributes>
        </command>
    </channel>

• Regarding the type of an attribute. Here I was thinking about using the same options as configuration parameters. (Maybe even use parameter) That way it would be possible to reuse existing functionality.

Regarding the state variant. What I meant with the synchronization problem is that these state attributes are now only possible as channels, but because each channel is updated individually it's not possible to deduct a relation between them and thus using channels makes it difficult, if not impossible, to use them effectively (If I interpret it correctly this was also what you meant as being the problem). So I understand your solution. But I also see some different issues to solve here. Like do these additional attributes need to be persisted? (With the command we could choose that those are not persisted and the value only is send with the command). When should something be an attribute and when a channel? Or are these kind of sub channels? Do these attributes need to be accessible to the user in the UI? Because I can easily see a case where it's an attribute and then the user want to see it in the user interface. So because of all these questions I think it requires some additional thoughts about what would be the best solution and hence my suggestion to make that a different issue. wdyt?

[cdjackson]

English is not my native language, so that might be the problem too

No - I don't think so. Your English is fine - the only "problem" is that every engineer will think and describe things a bit differently and I interpreted this a bit differently when I read it the second time :)

If I interpret how openHAB is intended than to make this possible or acceptable there should be support for a graphical I think. So I think we're on the same page here!

👍 100%

Instead of putting it on the channel-type I was thinking about adding it to the channel.

Yes, this is probably better. We could do "both" - many of the channel-type definitions can be over-ridden in the channel definition. However, you are right that most flexible is the channel definition.

Regarding the type of an attribute. Here I was thinking about using the same options as configuration parameters

This sounds fine to me I think. I'd need to look over the parameter definition, but from memory I think this should cover everything that is needed, and clearly re-using functionality is nice.

What I meant with the synchronization problem is that these state attributes are now only possible as channels, but because each channel is updated individually it's not possible to deduct a relation between them and thus using channels makes it difficult

I may need to retract my statement above about your English as I'm not sure I understand this statement :). Can you explain this?

I am wondering if you are thinking that the information is provided in separate entities in the binding? If so, that may happen in some bindings I guess, but for both ZigBee and ZWave, the "attribute" information is provided in the same entity (eg ZWave packet) as the state. So we might have for example a Door Lock state update - in one frame it provides all the information "The lock changed state to UNLOCKED, but RF CONTROL with ID User 123". I want to use a Switch to show the state of the lock, but then add the attributes to show the user who opened the lock, and how they unlocked it. There is no correlation etc required to take information from different packets/sources - it is just a "repackaging" exercise. (I'm not sure if that covers your point though, so please feel free to rephrase).

Like do these additional attributes need to be persisted?

Good question. I would say "Yes". These are potentially important bits of information - if we take the lock example above, I think it's useful/necessary to be able to recall who opened the door after the event. Basically, I would expect the full state to be persisted and the historical interfaces to restore the same state later.

When should something be an attribute and when a channel?

It's probably up to the binding in some respects, but for me there's probably normally a kind of "main state" that probably links largely to existing item types (Switch, Number etc...). I'm not sure there's a hard and fast rule, but by requiring bindings to define the channels and attributes in the XML there's a clear opportunity for review and critique (ie it stops/reduces channel abuse).

Or are these kind of sub channels?

We could no doubt call them different things. For me it's a way of consolidating information that relates to an atomic event together.

Do these attributes need to be accessible to the user in the UI?

My initial thinking is that they are primarily for rules, however there is probably nothing to stop them being exposed in the UI and this is probably a good idea. They are defined in the channel description, so it should not be too hard to display them in the UI if desired - the UI could treat them as separate channels linked together, or a tree type interface for selecting the item or attribute.

I think it requires some additional thoughts about what would be the best solution and hence my suggestion to make that a different issue. wdyt?

Maybe - I think for now we should keep them together while we discuss the solutions. In my mind at least, we should try to make the solutions for commands and states as similar as possible - at least at top level. Once we agree on the general approach, then maybe we close this and open 1, 2, or even 3 different issues (eg one for states, one for commands, and maybe there's some common code - I don't know). I think at this point there's potential to keep them similar, so I would suggest continuing the discussion in this, but if others think it helps move it forward then I don't mind too much.

[kaikreuzer]

For commands, I can only re-iterate that we have actions for exactly the purpose to pass arguments to a call. Everything about UIs in openHAB is designed in a way that arguments do not make sense there.

As a ThingAction becomes part of the list of all actions, adding lots of ThingActions would create a large list of actions making it difficult to find a specific action if all you want to do is set an additional parameter for 1 channel.

That's a valid concern, but the problem would be the same if you allow arbitrary key-value pairs or JSONs to be passed next to commands. But if we want to consolidate those actions (i.e. introduce some kind of common abstraction to it), we could simply define interfaces with methods that the actions are then implementing. So we could have LightTransitionAction interface that is implemented by different bindings and we could be sure that all are using the same signature.

[cdjackson]

For commands, I can only re-iterate that we have actions for exactly the purpose to pass arguments to a call.

I go back to my earlier point though - why do we have two ways to do the same thing (or nearly the same thing). Doesn't this feel wrong - confusing for both developers and users alike?

if you allow arbitrary key-value pairs

It is not "arbitrary" - we are trying to make this clearer by defining them up front so it is clear to the UI, the user and developer.

we could simply define interfaces with methods that the actions are then implementing.

Then we either end up with hundreds of interfaces, or only one or two interfaces that are somehow allowed to be added, which would not meet the need we are discussing here.