Home » Archived » Eclipse SmartHome » Configuration 'actions'
| |
| Re: Configuration 'actions' [message #1694332 is a reply to message #1694315] |
Mon, 04 May 2015 13:57   |
 Chris Jackson
Messages: 256
Registered: December 2013 |
Senior Member |
|
|
Hi,
Thanks for your thoughts...
I'm not sure I understand how I can use the ItemRegistry here. I guess you're updating a things parameter in this instance (??), but what I want to be able to do is to send an action to a thing. So, I might want to be able to reset it, or something device specific - I don't think the current updated methods are ideal for this unless we can somehow separate out channels/parameter and actions as I think they are different. It might be possible to configure a channel to act as a reset, but as per my post, then the UI will treat it like other channels. Also, if I have a 'reset' channel, then how do I call it? If I update the value, then I'd need to call updated twice to trigger a change (I think?).
I also don't think there's anything defined to tell the UI what the actions are. Somehow, the UI needs to be told that there are actions for this thing so that it can present a dropdown, or set of buttons, or something, and then it needs to be able to tell ESH what the action, and it's option/value, is set to. The upcoming event framework might help in one direction (ie from the UI to the thing handler), but as I understand it, it won't define how the UI is to be configured.
In the config interface I had for HABmin in OH1 I had the ability to separately send actions - separate to items values and configuration parameters. These were hooked up to buttons in the UI - I'm looking for the same sort of thing here, but maybe there's a better (or just different) way to do the same thing with the existing framework?
Or... Maybe I've just misunderstand what you've implemented?  Can you provide a bit more information?
Cheers
Chris
|
|
| | | | |
| Re: Configuration 'actions' [message #1694455 is a reply to message #1694421] |
Tue, 05 May 2015 12:23 |
Chris Jackson
Messages: 256
Registered: December 2013 |
Senior Member |
|
|
Hi Kai,
the 'advanced channels' idea that you mention above would work (partly!) - but I agree - it doesn't quite feel right... It would however work from the definition perspective - ie an action could be defined in the same, or similar way to the config descriptions. However, where it doesn't work is the return direction. Currently, the configuration data is put into the thing, and sent to ESH - the problem is that unlike a parameter, which is simply set, an action is sent as the result of a user action... Maybe that doesn't make sense, so let me use an example. If I have a parameter called 'reset', and I set it to true, then I reset it. To send it again, I need to set it to false, and then back to true for there to be a change detection. Instead, what I might want is to send a single 'action' that results in a reset. If all the parameters are sent again, then the detection becomes complex for something that should be simple.
In my thinking, an action is like a button rather than an input, so needs some of the same attributes as a configParameter (options to support selection, label, description...) but doesn't require things like min/max...
In HABmin (OH1) I have a separate REST endpoint for actions - you send the action 'name' and 'value' and the binding has a handler to handle the function... I would be happy to implement something similar in ESH - maybe with a similar definition to the configParameter (reduced as above)....
Let me know what you think...
Cheers
Chris
|
|
| | |
| Re: Configuration 'actions' [message #1694691 is a reply to message #1694522] |
Thu, 07 May 2015 08:08 |
Kai Kreuzer
Messages: 673
Registered: December 2011 |
Senior Member |
|
|
I was actually not meaning "actions having parameters", but "actions have options like parameters", i.e. a list of possible values to send (like "reset", "backup", etc.). Having actions with parameters sounds as if it will easily become very complex - especially wrt how to render such things in a UI.
I think before we go into any implementation we have to think carefully about the requirements. We e.g. also talked about associating buttons to config parameters - e.g. sending the wifi settings to the device with the press of a button. If we introduce a "logic" interface for config descriptions with these actions, we might also want to consider the requirement of "dynamic options", e.g. providing possible options through code (like e.g. available SSIDs for the Wifi setting). Then again, I wonder if the solution is always embedded into a Thing, a rule module, a persistence service, etc. or if the config descriptions are offered independently with their own API. This decision will have a big impact on how the Java and REST API should look for this.
So you see, I still see many open questions... Maybe we should start sketching possible XML, REST and Java API and see how the different ideas could be fit in there.
|
|
|
| Re: Configuration 'actions' [message #1694759 is a reply to message #1694691] |
Thu, 07 May 2015 15:07 |
Chris Jackson
Messages: 256
Registered: December 2013 |
Senior Member |
|
|
Ok - sorry - when you said "we should keep in mind that config descriptions are not tied to Things, but are meant to be applicable to any kind of service" - I though that you meant that in the same way as we have a list of config descriptions for parameters, that we could have config descriptions for actions and you wanted to reuse the classes currently defined...
Possibly we're talking slightly cross terms, so I'll use examples...
For the definition, I see the following structure (defined as pseudo JSON) -:
actions [
{
name: "action1",
label: "Network function",
description: ""
context: ""
options: ["reset", "initialise", "reset alarm"]
},
{
name: "action2",
label: "Reset",
description: ""
context: ""
options: []
}
]
These would be provided in the thing-type descriptions along with the other configuration information...
This would then be sent back on the REST as -:
PUT 'action1' : 'initialise'
PUT 'action2' : ''
In a UI, action1 would be rendered as a list of options (since a list of options is supplied ) while in action2 this could be rendered as a button, or a menu option or something.
I've not thought about the Java API side, but would consider a similar service interface to the config descriptions, but with an additional 'doAction' type of method.
The above is effectively what I have in HABmin at the moment and it's used extensively for the ZWave binding. However, I can see someone coming along with a use case where instead of [options] they wanted to be able to set an action based on (say) a number (eg PUT 'action1': 23). If this use case comes up, then maybe the action definition could be the same as the parameter definition in the config descriptions. Again, I don't have that use case (yet:)) but someone else might so having a flexible interface and reusing the XML might be better (just a thought).
There are obviously a number of ways of doing this so I definitely welcome feedback, but I also think it might be useful to code something up for trial/test. I currently need something to initialise the zigbee interface so this might push me to do something soon as it's causing problems with some users...
Chris
|
|
|
Goto Forum:
Current Time: Thu Apr 25 13:07:54 GMT 2024
Powered by FUDForum. Page generated in 0.03851 seconds |
] 
Search
Help
Register
Login
Home
