I'm not certain if there is a design intent or this is just how it has evolved, but my understanding is as follows:
An Input type plugin can be an IO type or an X10 type. IO types deal in DeviceValues and X10 types deal in ON/OFF/DIM/... commands/status.
An X10 device uses the X10Event callback which will set the DeviceStatus and not geneate a SETIO, but can generate a ReceiveX10 event callback(&H1) as well as a State Change event callback (&H4).
An X10 device, as an output, responds to the ExecX10 command. This generates a SETIO which the plugin used to output the command. TransmitX10 (&H16) and perhaps a State Change event callback (&H4) will be produced. Note that the TransmitX10 event and the SETIO calls are not generated when a SetDeviceStatus are used, hence no output is produced on a SetDeviceStatus.
An IO device informs HS of an input change with the ValueChange callback. This will let HS change the deviceValue without producing a SETIO call back to the plugins. I forget if the State Change (&H4) event may be geneated.
An IO devcice, as an output, responds to a SetDeviceValue command. This will generate a SETIO call to which the plugin will service by output of the value. Same memory lapse on the State Change (&H4) event.
Since the SETIO call is made for both X10 and IO device output commands to a plugin, it is up to the plugin to decipher if it is going to respond to the command (ON/OFF etc) or to the value/brightness parameters. I'm fuzzy on a good decode strategy for the general case since I've seen a variety of combinations occur.
From a GUI control perspective, if there are only two states it is best viewed as a device that can respond to ON and OFF commands. If it has more than two states then it needs to be controlled as enumerated values which shows up 2 levels lower in the GUI control interface. Just a human-factor difference. From the web view all buttons are at the same level. Only the labeling changes.
With all this being said, I think what is desired is button inputs to look like ON/OFF commands for which the state is maintained as DeviceStatus. For joystick inputs these are analog and maintained as DeviceValue.
The button state should be able to be communicated to HS via the X10Event. This will change the status, generate a Callback for the button press (&H1), and a callback for the state change (&H4).
The joystick update should be done via the ValueChange callback.
Now that I have gone through this description I can see that the ExecX10 for a button input will work, but conveys the wrong information since it will produce an X10Tansmit event (&H10). The use of the X10Event is most closely aligned with event notification associated with the change of an external input. Don't be confused with the "X10" part of these commands since they apply to any signal that behaves according to ON/OFF type status criteria.
Of course the above is my view of how the system should function in a predictable manner. There are various combination of commands and callbacks that can be used to achieve any pluign-specific control action. With a variety of plugin authors I'm certain a hodgepodge of techniques are being used.
An Input type plugin can be an IO type or an X10 type. IO types deal in DeviceValues and X10 types deal in ON/OFF/DIM/... commands/status.
An X10 device uses the X10Event callback which will set the DeviceStatus and not geneate a SETIO, but can generate a ReceiveX10 event callback(&H1) as well as a State Change event callback (&H4).
An X10 device, as an output, responds to the ExecX10 command. This generates a SETIO which the plugin used to output the command. TransmitX10 (&H16) and perhaps a State Change event callback (&H4) will be produced. Note that the TransmitX10 event and the SETIO calls are not generated when a SetDeviceStatus are used, hence no output is produced on a SetDeviceStatus.
An IO device informs HS of an input change with the ValueChange callback. This will let HS change the deviceValue without producing a SETIO call back to the plugins. I forget if the State Change (&H4) event may be geneated.
An IO devcice, as an output, responds to a SetDeviceValue command. This will generate a SETIO call to which the plugin will service by output of the value. Same memory lapse on the State Change (&H4) event.
Since the SETIO call is made for both X10 and IO device output commands to a plugin, it is up to the plugin to decipher if it is going to respond to the command (ON/OFF etc) or to the value/brightness parameters. I'm fuzzy on a good decode strategy for the general case since I've seen a variety of combinations occur.
From a GUI control perspective, if there are only two states it is best viewed as a device that can respond to ON and OFF commands. If it has more than two states then it needs to be controlled as enumerated values which shows up 2 levels lower in the GUI control interface. Just a human-factor difference. From the web view all buttons are at the same level. Only the labeling changes.
With all this being said, I think what is desired is button inputs to look like ON/OFF commands for which the state is maintained as DeviceStatus. For joystick inputs these are analog and maintained as DeviceValue.
The button state should be able to be communicated to HS via the X10Event. This will change the status, generate a Callback for the button press (&H1), and a callback for the state change (&H4).
The joystick update should be done via the ValueChange callback.
Now that I have gone through this description I can see that the ExecX10 for a button input will work, but conveys the wrong information since it will produce an X10Tansmit event (&H10). The use of the X10Event is most closely aligned with event notification associated with the change of an external input. Don't be confused with the "X10" part of these commands since they apply to any signal that behaves according to ON/OFF type status criteria.
Of course the above is my view of how the system should function in a predictable manner. There are various combination of commands and callbacks that can be used to achieve any pluign-specific control action. With a variety of plugin authors I'm certain a hodgepodge of techniques are being used.
Comment