Is there a “main” component (a “main” plugin in App) in DTH as well ?
Is it reasonable for the “main” of a Multiple-Component device to support scene binding?
Can it be removed ?
Recently I migrate a 4-button devices from DTH to EdgeDriver. 4 Button Devices
Now there are 5 plugins within a device card in App.
main
button1
button2
button3
button4
I consulted my colleague, and main plugin should represent the overall status of the device.
This means that no matter which button is pressed, ‘main’ should respond accordingly.
Moreover, I’ve looked at the default code implementation, and it indeed works this way. Default Implementation
local function added_handler(self, device)
local config = supported_values.get_device_parameters(device)
for _, component in pairs(device.profile.components) do
if config ~= nil then
local number_of_buttons = component.id == "main" and config.NUMBER_OF_BUTTONS or 1
device:emit_component_event(component,
capabilities.button.supportedButtonValues(config.SUPPORTED_BUTTON_VALUES, { visibility = { displayed = false } }))
device:emit_component_event(component,
capabilities.button.numberOfButtons({ value = number_of_buttons }, { visibility = { displayed = false } }))
else
device:emit_component_event(component,
capabilities.button.supportedButtonValues({ "pushed", "held" }, { visibility = { displayed = false } }))
device:emit_component_event(component,
capabilities.button.numberOfButtons({ value = 1 }, { visibility = { displayed = false } }))
end
end
device:emit_event(capabilities.button.button.pushed({state_change = false}))
end
But what confuses me is that “main” also supports scene binding,
and I’m not sure what the purpose of this support is. Is there a way to delete it ?
I’m not sure what you’re referring to on some points, for example when you say plugin, Are you referring to the components?
Can you give more context, please?
What is the current behavior? and What is the behavior that you want to achieve?
The code you shared is only assigning values to the supportedButtonValues attribute, which are the options available that will be shown to the user for other configurations automations and scenes.
By this, do you mean the main component is being bonded to a specific endpoint of the physical device?
I’m not sure what you’re referring to on some points, for example when you say plugin, Are you referring to the components?
Yes.
What is the current behavior?
Current Behaviour:
My device has only 3 buttons, but my App page has 4 components.
Main
Button1
Button2
Button3
All components support binding scene.
No matter which button I press on the device, the corresponding button on the App page,
as well as the main button, will respond with ‘Pressed’
and What is the behavior that you want to achieve?
I didn’t have any expected behavior, it’s just that some users are confused about the following matters.
I explained to them, but they hope to get some official answers.
Q1: Why there are 4 components on the App page instead of 3 components?
I explained to them that is because there must be a ‘main’ component in the profile, we use it to represent the overall status of the device. So there are 4 components.
Q2: Can main represents button1 instead of the entire device? Then there are only 3 components on App page.
I understand that it can be implemented at the code level.
We could only define main, button2, button3 in profile and send button1’s event to main component.
But I’m not sure if doing this conforms to the standard, and I personally think it’s not a good approach.
Moreover, if I do it this way, I’m not sure how I should name my profile (three-buttons or two-buttons?).
Q3: If the main component represents the entire device, is it necessary for the main component to support scene binding?
Users hope that the main component does not support scene binding and only displays the status; they shouldn’t be able to click on it to bind a scene.
By this, do you mean the main component is being bonded to a specific endpoint of the physical device?
Not to a specific endpoint, but no matter which button on the device is pressed, the main component will respond.
There is a bit of history here. If you consider something like a light switch with four switches, or an extension lead (as we call them in the UK) with four controlled sockets on it, it comes naturally to us to want to treat each switch/socket as a separate device. So they tended to be implemented as a parent device that handled the actual communication with the hardware, plus a child device for each switch/socket. Components, in the SmartThings sense, came along later and never really displaced this model in DTHs. Even in Edge drivers you will see that an EDGE_CHILD device was introduced so this approach could still be used instead of components.
Devices with multiple buttons are different. We don’t tend to think of each button as a separate device, we seem to think of a single device with multiple buttons. So they never really went down the child device path. Instead, to allow multiple buttons to be supported with just the one available button attribute, a button number was added to the event data. Legacy apps knew to look for this button number to identify which button had been pushed or held. Not only that but pushed and held were the only values in the button attribute at the time, so if there was a need to support double or triple presses etc, those were implemented as pushes on a different button number.
When the ‘new’ mobile apps came along, they didn’t understand the button number stuff, they only understood using components. So DTHs for multi-button devices were rewritten to use components so they worked better with the mobile apps, but still needed to work with the existing apps that didn’t understand components and so maintained the single attribute with the button number. That has lived on as the button attribute in the ‘main’ component of Edge drivers.
The above is not really necessary now the legacy apps have been phased out, but there is another reason to have a button attribute that reflects activity on all the buttons. The standard device tiles on the dashboard in the mobile apps can only display the status of a single attribute and what else would you put there?
So it is a convention, but a well established one.
Hi @liuyd96.
After discussing this behavior with the engineering team, they mentioned showing the events of any other button in the Main component was configured on purpose to allow users the possibility of creating an automation (Routine/Scene) of type “if any button is pressed” using the events in this component as a trigger.
