This page last changed on May 18, 2014 by tomas.morton.

Good evening,

I have recently started developing a new protocol to integrate with Open Remote. I went to create the Designer protocol XML file and could not find any options for specifying drop-down values. Is this feature available? If not, my team would not mind taking a look at implementing it. I am a strong believer in simplicity for users, and asking them to enter a value that is REGEX checked will very quickly frustrate my clients.

Edit:
Furthermore, are there any validation options available based on values entered in other boxes on the New Command screen?
For example, a snippet of an enum (modified for visibility):
DOOR_LOCK(), DOOR_UNLOCK(), DOOR_UNLOCK_LATCHED(),
AREA_DISARM_AREA(), AREA_DISARM_24HR(), AREA_DISARM_ALL(), AREA_ARM(), AREA_ARM_FORCE(), AREA_ARM_STAY(), AREA_ARM_INSTANT(),
OUTPUT_OFF(), OUTPUT_ON(), OUTPUT_TIMED(),
INPUT_BYPASS_REMOVE(), INPUT_BYPASS_TEMPORARY(), INPUT_BYPASS_PERMANENT(),
VARIABLE_SET(),
REQUEST_STATUS();

As you can see, there are a lot of options but only a few apply to each category.
It would not be reasonable to expect the user to remember each of these options; nor even to select from a list showing all of these values (though that would be an improvement).

Any thoughts or assistance would be much appreciated.

Regards,

Tomas.

A dropdown list is supported when specifying 'options' in the protocol definition, such as

<attr name="command" label="AMX Command" options="ON,OFF,PULSE,CHANNEL_STATUS,SEND_LEVEL,LEVEL_STATUS,SEND_COMMAND,COMMAND_READ,SEND_STRING,STRING_READ">
...

Dependency between fields is not yet supported but would indeed be something of value to simplify UI for end-users.

Posted by ebariaux at May 19, 2014 08:56

Thank you Eric, that's excellent.

Do you have any tips for where to go to look at implementing conditional fields? I haven't looked at the designer code very much at this stage so any assistance would be appreciated.

Posted by tomas.morton at May 19, 2014 09:12

I'll take a look at the source code and point you to where this is implemented.

In the meantime, I believe it would be interesting to discuss here already what you would like to implement to enhanced the command creation dialog and how that would translate in the protocol.xml definitions.
This can also be interesting for others to jump in at the purely functional level and indicate what, as end users, they would think would be useful in that dialog.

Posted by ebariaux at May 20, 2014 09:59

Sorry for the delayed reply - spending a lot of time getting everything running.

Without thinking about the technology currently implemented, I would imagine an optimal interface would allow a user to select an option from a box (such as Area, Door) and then have further fields become available to the user in a similar style to a JavaScript form. This is similar behaviour to the current Protocol selection when you are creating a command in the designer.

Another possibility, which is more complicated and will probably require a lot of new functionality, would be displaying a list view of all options at each screen. When an option is chosen, a typical hierarchy is displayed at the top of the screen (Door -> Unlock -> 3) and a list of options under that heading would be displayed. This means a smoother interface for the user to work with and not having to worry about what happens if a field value previously set is changed after.

Heres a couple of ideas for the XML:

<attr name="record-type" label="Record Type">
<option name="Door" id="recTypeDoor">
<option name="Area" id="recTypeArea">
<option name="Output" id="recTypeOutput">
<validations />
</attr>

<attr name="record-command" label="Record Command">
<!-- Door commands -->
<option name="Unlock" dependency="recTypeDoor">
<option name="Lock" dependency="recTypeDoor">
<option name="Latch" dependency="recTypeDoor">
<!-- Area commands -->
<option name="Arm" dependency="recTypeArea">
<option name="Disarm" dependency="recTypeArea">
<validations />
</attr>

You could possibly also group the options into a list, and assign them all the same dependency:

<options names="Unlock,Lock,Latch" dependency="recTypeDoor">

Edit: the dependency should probably link through the attribute name, makes it more robust but means more xml attributes.

Posted by tomas.morton at May 22, 2014 02:35
Document generated by Confluence on Jun 05, 2016 09:30