Skip to content

Feature/matter britzyhub #2189

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 13 commits into
base: main
Choose a base branch
from

Conversation

KyuminAhn
Copy link

Check all that apply

Type of Change

  • WWST Certification Request
    • If this is your first time contributing code:
      • I have reviewed the README.md file
      • I have reviewed the CODE_OF_CONDUCT.md file
      • I have signed the CLA
    • I plan on entering a WWST Certification Request or have entered a request through the WWST Certification console at developer.smartthings.com
  • Bug fix
  • New feature
  • Refactor

Checklist

  • I have performed a self-review of my code
  • I have commented my code in hard-to-understand areas
  • I have verified my changes by testing with a device or have communicated a plan for testing
  • I am adding new behavior, such as adding a sub-driver, and have added and run new unit tests to cover the new behavior

Description of Change

Initial Commit of matter-britzyhub edge driver

Summary of Completed Tests

Tested gas valve
Tested elevator
Tested dimming light

@DongHoon-Ryu
Copy link
Contributor

@KyuminAhn
Hello,
Basically, the EdgeDrivers of individual Bridged Devices under the Bridge do not have to be under the physical Bridge path. This is because the relationship between them is logically established during onboarding.

And, there was no difference between the existing EdgeDriver and the EdgeDriver related to the dimming-light, elevator, gas-valve, etc. you made. If a Bridged Device can operate with the existing Matter Generic EdgeDriver, no separate EdgeDriver code is required. That is, if it can be operated as a Matter Generic EdgeDriver, the EdgeDriver suitable for the Bridged Device is automatically downloaded when the Bridge Device is onboarded without further development.

If you have your own Bridged Device function that cannot be supported by Matter Generic EdgeDriver, you'd better implement the EdgeDriver for the separated directory at this time. However, even in this case, it would be better to implement the function under the directory such as matter-switch or matter-sensor, matter-thermostat, ... depending on the characteristics of the Bridged Device. This is because duplicate code can be minimized.

@hcarter-775 , @nickolas-deboom
Could you check this PR?

components:
- id: main
capabilities:
- id: valve
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please use safetyValve.

safetyValve capability has only close command.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@DongHoon-Ryu
we will change that, Thanks for your advice,

@@ -0,0 +1,530 @@
-- SinuxSoft (c) 2025
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be best to introduce a "is_air_conditioner" function in this subdriver (and similar for the other subdrivers) so that it is only loaded for AC devices. You can reference a similar function in the SmartThings Matter Appliance driver here for example. You could just check the device type and then return true if it matches AC.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've applied the source code based on your advice. Thank you.


local matter_driver = MatterDriver("britzyhub-matter", {
sub_drivers = {
require ("elevator"),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume that 'air-conditioner' and 'dimming-light' are not included here because there would be a conflict with the generic fingerprints for those device types already belonging in other drivers? (matter-thermostat and matter-switch, respectively)

},
capability_handlers = {
[valve_cap.ID] = {
--[valve_cap.commands.open.NAME] = function(driver, device, cmd)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This may be commented out accidentally

else
device:emit_event_for_endpoint(ib.endpoint_id, capabilities.airConditionerFanMode.fanMode("auto"))
end
elseif device:supports_capability_by_id(capabilities.airPurifierFanMode.ID) then
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The elseif and else clauses can be removed since airConditionerFanMode should be used here.

return false
end

local function match_profile(driver, device)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that all of the profiling logic should be removed from this sub-driver since the profile used by devices using this driver would be "air-conditioner.yml"

supported_capabilities = {
capabilities.switch,
capabilities.airPurifierFanMode,
-- capabilities.fanSpeedPercent,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think these may be inadvertently commented out


local function fan_mode_handler(_, device, ib, _)
local cap = capabilities.airPurifierFanMode
if device:supports_capability_by_id(cap.ID) then
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This check shouldn't be needed since this capability is present in the ventilator profile

local args = cmd.args.airPurifierFanMode
local mode_map = {
low = clusters.FanControl.attributes.FanMode.LOW,
sleep = clusters.FanControl.attributes.FanMode.LOW,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The enabled values in the profile are low, medium, high, auto, and off, so the other modes here aren't needed to be included

@lunDreame lunDreame mentioned this pull request Jul 13, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants