Skip to content

generic_zigbee_sensor_improvement #2093

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 1 commit into
base: main
Choose a base branch
from

Conversation

pInksenberg
Copy link
Contributor

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

Refactoring zigbee-sensor driver, and adding support for tuya zigbee devices.

Summary of Completed Tests

Copy link

Duplicate profile check: Passed - no duplicate profiles detected.

Copy link

github-actions bot commented Apr 23, 2025

Test Results

   66 files    427 suites   0s ⏱️
2 188 tests 2 188 ✅ 0 💤 0 ❌
3 731 runs  3 731 ✅ 0 💤 0 ❌

Results for commit 9946a16.

♻️ This comment has been updated with latest results.

Copy link

github-actions bot commented Apr 23, 2025

File Coverage
All files 100%

Minimum allowed coverage is 90%

Generated by 🐒 cobertura-action against 9946a16

@pInksenberg pInksenberg force-pushed the generic_zigbee_sensor_improvement branch from 0f03911 to 21f22c9 Compare April 23, 2025 08:36
@pInksenberg pInksenberg force-pushed the generic_zigbee_sensor_improvement branch 5 times, most recently from 9267b81 to b81729b Compare April 24, 2025 09:44
Comment on lines 22 to 23
- 0xfe00 # EZVIZ private cluster
- 0xfe05 # EZVIZ private cluster
Copy link
Contributor

Choose a reason for hiding this comment

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

we usually capitalize the letters in our hex

Comment on lines 66 to 68
local generate_event_from_emergency = function(driver, device)
device:emit_event(capabilities.button.button.pushed({ state_change = true }))
end

local ias_ace_emergency_handler = function(driver, device)
generate_event_from_emergency(driver, device)
end
Copy link
Contributor

Choose a reason for hiding this comment

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

these functions can be consolidated

Comment on lines 26 to 47
local generate_event_from_zone_status = function(driver, device, zone_status, zb_rx)
local event
if zone_status:is_alarm1_set() or zone_status:is_alarm2_set() then
event = capabilities.contactSensor.contact.open()
else
event = capabilities.contactSensor.contact.closed()
end
if event ~= nil then
device:emit_event_for_endpoint(
zb_rx.address_header.src_endpoint.value,
event)
end
end


local ias_zone_status_attr_handler = function(driver, device, zone_status, zb_rx)
generate_event_from_zone_status(driver, device, zone_status, zb_rx)
end

local ias_zone_status_change_handler = function(driver, device, zb_rx)
generate_event_from_zone_status(driver, device, zb_rx.body.zcl_body.zone_status, zb_rx)
end
Copy link
Contributor

Choose a reason for hiding this comment

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

are we overwriting the defaults somewhere that makes it necessary to redefine them here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

you are right, we double check, and the redefine handler is not necessary and will be removed.

Copy link
Contributor

@greens greens left a comment

Choose a reason for hiding this comment

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

I'd appreciate if we could separate the zigbee generic sensor driver from the Tuya drivers.

@pInksenberg pInksenberg reopened this Apr 25, 2025
@pInksenberg
Copy link
Contributor Author

pInksenberg commented Apr 25, 2025

I'd appreciate if we could separate the zigbee generic sensor driver from the Tuya drivers.

Currently we have divided tuya and zigbee_generic_sensor into different directories, specifically located within "/drivers/generic_zigbee_sensor" and "/Unofficial/tuya" floder. Are you suggesting that we should further separate the Tuya-powered manufacturers, such as Eviz and Meian, into the "/Unofficial/tuya" folder?

@pInksenberg pInksenberg force-pushed the generic_zigbee_sensor_improvement branch 5 times, most recently from 6a5a0dd to 29fae3a Compare April 27, 2025 09:05
@greens
Copy link
Contributor

greens commented Apr 28, 2025

@pInksenberg I meant have them as two separate pull requests

@pInksenberg pInksenberg force-pushed the generic_zigbee_sensor_improvement branch from 29fae3a to 9946a16 Compare April 29, 2025 01:50
Copy link

@pInksenberg
Copy link
Contributor Author

@pInksenberg I meant have them as two separate pull requests

@greens , sure, I separated tuya devices support into another PR, please kindly check~
https://github.com/SmartThingsCommunity/SmartThingsEdgeDrivers/pull/2102/files

Comment on lines +17 to +24
- id: "generic-button-sensor"
deviceLabel: "Zigbee Generic Button"
clusters:
server:
- 0x0500
- 0xFE00 # EZVIZ private cluster
- 0xFE05 # EZVIZ private cluster
deviceProfileName: generic-remote-control
Copy link
Contributor

@greens greens Apr 29, 2025

Choose a reason for hiding this comment

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

if this device is a button it should be in the zigbee button driver

As far as I can tell it doesn't do any sensing, so it doesn't make much sense to put it here

Copy link
Contributor Author

Choose a reason for hiding this comment

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

After our team discussions, we have no better solution for this yet. Could you please share your suggestions? How about just put it to Unofficial/ezviz directory?

Copy link
Contributor

Choose a reason for hiding this comment

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

You could do that or you could put this exact same fingerprint in the zigbee-button driver.

Copy link
Contributor

@inasail inasail May 2, 2025

Choose a reason for hiding this comment

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

@greens
Actually, this device is non-WWST device, so we can't put exact fingerprint in zigbee-button driver for this device.
As you know, zigbee-sensor have only generic fingerprint for generic purpose and scalability. I think by adding like this, we can support more ezviz button if they use same private cluster in the future(or now) for their new button devices. and If we need to support more other different types of ezviz devices in the future, then let's move this device into Unofficial/ezviz. but now, Let's just keep this device into zigbee-sensor for a while. What do you think?

  • id: "generic-button-sensor"
    deviceLabel: "Zigbee Generic Button"
    clusters:
    server:
    - 0x0500
    - 0xFE00 # EZVIZ private cluster
    - 0xFE05 # EZVIZ private cluster
    deviceProfileName: generic-remote-control

CC: @kdbang @varzac

Copy link
Contributor

Choose a reason for hiding this comment

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

put this fingerprint:

  - id: "generic-button-sensor"
    deviceLabel: "Zigbee Generic Button"
    clusters:
      server:
        - 0x0500
        - 0xFE00 # EZVIZ private cluster
        - 0xFE05 # EZVIZ private cluster
    deviceProfileName: generic-remote-control

under a new zigbeeGeneric: section here: https://github.com/SmartThingsCommunity/SmartThingsEdgeDrivers/blob/main/drivers/SmartThings/zigbee-button/fingerprints.yml

Copy link
Contributor

Choose a reason for hiding this comment

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

buttons should use the button driver

},
can_handle = is_water_sensor
}
defaults.register_for_default_handlers(generic_water_sensor, generic_water_sensor.supported_capabilities)
Copy link
Contributor

Choose a reason for hiding this comment

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

@varzac Does only registering for defaults in a specific sub-driver work like this?

Comment on lines +107 to +108
require("meian"),
require("ezviz")
Copy link
Contributor

Choose a reason for hiding this comment

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

How about changing to 'meian-button' / 'ezviz-button' for the clarity? (including the folder name of each sub drivers)

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.

4 participants