add support for generic zigbee sensor #1921

pInksenberg · 2025-02-11T09:00:04Z

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

Add support for generic Zigbee sensor base on IASZone type

Summary of Completed Tests

github-actions · 2025-02-11T09:00:48Z

Duplicate profile check: Passed - no duplicate profiles detected.

github-actions · 2025-02-11T09:01:33Z

Invitation URL:
https://bestow-regional.api.smartthings.com/invite/wvjJwbDPnqMk

github-actions · 2025-02-11T09:03:53Z

Test Results

65 files 411 suites 0s ⏱️
2 088 tests 2 082 ✅ 0 💤 6 ❌
3 573 runs 3 567 ✅ 0 💤 6 ❌

For more details on these failures, see this check.

Results for commit 1dd4216.

♻️ This comment has been updated with latest results.

github-actions · 2025-02-11T09:03:55Z

File	Coverage
All files	`97%`	✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/zigbee-sensor/src/init.lua	`97%`	✅

Minimum allowed coverage is 90%

Generated by 🐒 cobertura-action against 1dd4216

inasail · 2025-02-11T11:16:12Z

drivers/SmartThings/zigbee-sensor/fingerprints.yml

@@ -0,0 +1,8 @@
+zigbeeGeneric:
+  - id: "ias-generic-sensor"
+    deviceLabel: "IAS Zigbee Generic Sensor"


The label is a little bit difficult to understand. How about the 'Zigbee Safety Sensor"
@greens @varzac Do you have any good idea?

inasail · 2025-02-11T11:16:39Z

drivers/SmartThings/zigbee-sensor/profiles/ias-generic-button-profile.yml

@@ -0,0 +1,12 @@
+name: ias-generic-button-profile


If this profile is unnecessary, please remove.

inasail · 2025-02-11T11:18:14Z

drivers/SmartThings/zigbee-sensor/src/init.lua

+
+local ZIGBEE_GENERIC_SENSOR_PROFILE = "ias-generic-sensor"
+local ZIGBEE_GENERIC_CONTACT_SENSOR_PROFILE = "ias-generic-contact-sensor"
+local ZIGBEE_GENERIC_EMERGENCY_BUTTON_PROFILE = "ias-generic-emergency-button"


You can remove this because there is no any implementation about button functionality in this code.

inasail · 2025-02-11T11:18:44Z

drivers/SmartThings/zigbee-sensor/src/init.lua

+  local profile = ZIGBEE_GENERIC_SENSOR_PROFILE
+  if zone_type == Contact_Switch then
+    profile = ZIGBEE_GENERIC_CONTACT_SENSOR_PROFILE
+  elseif zone_type == Remote_Control or zone_type == Key_Fob or zone_type == Keypad then


You can remove this because there is no any implementation about button functionality in this code.

inasail · 2025-02-11T11:23:25Z

drivers/SmartThings/zigbee-sensor/src/init.lua

+    state_change = true
+  }
+
+  log.info("---zone_status: "..zone_status.value)


You can remove log.info() after you have finished the test.

inasail · 2025-02-11T11:40:10Z

drivers/SmartThings/zigbee-sensor/src/init.lua

+local ZONETYPE = "ZoneType"
+local log = require "log"
+
+local Contact_Switch = 21 -- 0x0015


You can use 0x0015 directly and use a capital letter when you define.
local CONTACT_SWITCH = 0x0015
local REMOTE_CONTROL = 0x010F

inasail · 2025-02-11T11:51:38Z

drivers/SmartThings/zigbee-sensor/profiles/ias-generic-contact-sensor.yml

+name: ias-generic-contact-sensor
+components:
+- id: main
+  capabilities:


Would you test the battery capability for Group2 devices?
and check the configureReport set for the powerConfiguration cluster. (don't forget to add capabilities.battery in supported_capabilities of init.lua.)
Sensor should report its battery state periodically.

varzac · 2025-02-11T13:38:35Z

drivers/SmartThings/zigbee-sensor/src/init.lua

+local ZIGBEE_GENERIC_MOTION_SENSOR_PROFILE = "ias-generic-motion-sensor"
+local ZIGBEE_GENERIC_WATERLEAK_SENSOR_PROFILE = "ias-generic-waterleak-sensor"
+
+-----add by dzd 20250124 start-----


these comments can be removed

varzac · 2025-02-11T13:52:45Z

drivers/SmartThings/zigbee-sensor/src/init.lua

+end
+
+-- since we don't have button devices using IASZone, the driver here is remaining to be updated
+local generate_event_from_zone_status = function(driver, device, zone_status, zb_rx)


Instead of having a single function here that that branches, the standard way to handle this in drivers is with subdrivers. So if you had a subdriver that looked like:

local capabilities = require "st.capabilities" local clusters = require "st.zigbee.zcl.clusters" local IASZone = clusters.IASZone local subdriver_template local generate_event_from_zone_status = function(driver, device, zone_status, zb_rx) if zone_status:is_alarm1_set() then device:emit_event(capabilities.contactSensor.contact.open()) else device:emit_event(capabilities.contactSensor.contact.closed()) end end local function subdriver_canhandle(opts, driver, device) -- Create a "fields.lua" to contain this string definition and contact switch constant return device:get_field("ZoneType") == 0x0015, subdriver_template end -- These functions could be moved to a common file as well. 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 subdriver_template = { NAME = "Zigbee Contact", zigbee_handlers = { attr = { [IASZone.ID] = { [IASZone.attributes.ZoneStatus.ID] = ias_zone_status_attr_handler } }, cluster = { [IASZone.ID] = { [IASZone.client.commands.ZoneStatusChangeNotification.ID] = ias_zone_status_change_handler } } }, can_handle = subdriver_canhandle } return subdriver_template

There will be a bit more duplicate code, but the it allows us to separate all the different types into their own files, so if we need more complicated logic we don't end up with a big mess of a function.

@pInksenberg
For this, we need to check the ZoneType can be determined before the 'can_handle' triggered.

In this driver, we can seperate sub driver following zonetype, but this edge driver read zone type in add_handler. so this device wouldn't likely to handle some message in initial time potentially.

The same problem exists whether this is a subdriver or a main driver here, until the ZONETYPE field is set on the device, we don't know what type of event we can generate, so we can't generate any event when the value changes. I still prefer the subdriver format as I think it's easier to separate the different devices, but I don't feel strongly about it, and I would be OK with this initial version, but that if any changes are made to add more complex logic that we split things out into subdrivers.

varzac · 2025-02-11T13:53:37Z

drivers/SmartThings/zigbee-sensor/src/init.lua

+  local additional_fields = {
+    state_change = true
+  }


You should not be setting state_change = true. That is only necessary, and should only be done for devices where they will emit the same value, but still need to be processed, like a button press.

drivers/SmartThings/zigbee-sensor/config.yml

varzac · 2025-02-13T15:36:18Z

drivers/SmartThings/zigbee-sensor/profiles/ias-generic-contact-sensor.yml

+  capabilities:
+  - id: contactSensor
+    version: 1
+  - id: batteryLevel


battery level is different than battery. All other Zigbee devices use the battery capability and that's what the defaults support not batteryLevel

@varzac @tpmanley
SRCN tried to use the battery capability but the result was untrustworthy.
So they removed the battery capabilty at the beginning, but I think If we cannot accurately display battery percentage, showing battery level (normal/warning/critical) instead would greatly benefit users.
SRCN suggested to use the zoneStatus(zone_status:is_battery_low_set()) because these devices are working based on IAS zone cluster. It is nice suggestion. Now, batteryLevel has 3 conditions.(normal/warning/critical) and we can know two battery condition with zoneStatus(1 – Low battery / 0 – Battery OK), so I think we can match the 'low battery' state to 'warning' state in batteryLevel. What do you think of this?

I left a somewhat similar comment here: https://github.com/SmartThingsCommunity/SmartThingsEdgeDrivers/pull/1921/files#r1956324647.

Was the BatteryPercentageRemaining attribute found to not be trustworthy? We've found that usually works well, and the problems arise when trying to make BatteryVoltage to a percentage as that's very hard to do, especially for coin cell batteries that have a pretty flat voltage for most of their life and then quickly decrease at the end. I would suggest using BatteryPercentageRemaining and the battery capability and/or ZoneStatus low battery to indicate warning like you suggested (I don't have a strong preference whether it should be warning or critical).

FrankSpringfield · 2025-02-14T11:23:36Z

drivers/SmartThings/zigbee-sensor/src/test/test_zigbee_sensor.lua

+      -- test.mock_time.advance_time(50000)
+      -- test.socket.zigbee:__set_channel_ordering("relaxed")
+      -- test.socket.zigbee:__expect_send({ mock_device_waterleak_sensor.id, IASZone.attributes.ZoneStatus:read(mock_device_waterleak_sensor) })
+      -- test.wait_for_events()


Hi, @greens @varzac
I tried to add these three pieces of code in this file.
I found that this has relationship to the capabilities in supported_capabilities in init.lua.
However, when I add capabilities contactSensor, motionSensor and waterSensor in file init.lua (the commented-out code), I found that only the front one can work and the others failed. Why did this happen?

Can you clarify what the failure is. Looking at the driver, there is no code that will send a ZoneStatus read after a delay. If you are expecting the infoChanged to happen, in the test environment that will only happen if you write test code to generate it. In addition, I don't think sending a read on the infoChanged is correct behavior.

FrankSpringfield · 2025-02-14T11:24:42Z

drivers/SmartThings/zigbee-sensor/src/init.lua

+    capabilities.refresh
+    -- capabilities.motionSensor,
+    -- capabilities.contactSensor,
+    -- capabilities.waterSensor


Only the motionSensor here can work.

varzac · 2025-02-14T15:14:08Z

drivers/SmartThings/zigbee-sensor/src/init.lua

+end
+
+-- ask device to upload its zone status, then the status of capabilities can be synchronized
+local ias_info_changed = function(driver, device)


This function will be run every time the device is updated on the cloud side. You should not be reading an attribute here. If the intent is for this to happen at some point after the device is added, you should use the call_with_delay to have the driver wait some period and then send the read.

tpmanley · 2025-02-14T15:20:53Z

drivers/SmartThings/zigbee-sensor/src/init.lua

+      event = capabilities.contactSensor.contact.closed()
+    end
+  elseif type == MOTION_SENSOR then
+    if zone_status:is_alarm1_set() then


Motion sensors can use either alarm1 or alarm2 so I would suggest reporting active if either are set

Please check the newly commit

Thanks for making the changes, but can you use the or operator instead of the extra elseif because it's more concise/easier to read?

if zone_status:is_alarm1_set() or zone_status:is_alarm2_set() then event = capabilities.motionSensor.motion.active() else event = capabilities.motionSensor.motion.inactive()

tpmanley · 2025-02-14T15:22:49Z

drivers/SmartThings/zigbee-sensor/src/init.lua

+  local type = device:get_field(ZONETYPE)
+  local event
+  if type == CONTACT_SWITCH then
+    if zone_status:is_alarm1_set() then


The ZCL spec says that contact switches can use both alarm1 and alarm2 so I think both should be checked

Please check the newly commit

tpmanley · 2025-02-14T15:26:52Z

drivers/SmartThings/zigbee-sensor/src/init.lua

+
+local battery_level_handler = function(driver, device, value, zb_rx)
+  local voltage = value.value
+  if voltage <= 25 then


It's pretty difficult to accurately translate voltage to battery level without knowing the details of the device and battery technology. I'd either suggest using the low battery indicator in the IAS Zone Status and/or switching from batteryLevel capability to battery and looking at the BatteryPercentageRemaining attribute instead of BatteryVoltage

Apologies, I just saw the similar comment here: #1921 (comment)

test result for BatteryPercentageRemaining:
using same type of battery
37 Meian meian water leak sensor Water Leak Sensor :100
20 EZVIZ EZVIZ T1C Smart Motion Sensor Motion sensor :90
21 Tuya Tuya Zigbee PIR Sensor Motion sensor :100
24 Tuya PIR Motion SensoR XZ-CGV2 Motion sensor :100
27 Tuya Tuya Human motion sensors Motion sensor :98

using different type of battery
38 EZVIZ EZVIZ T10C Water Leak Sensor Water Leak Sensor :98
34 Tuya Door Window Sensor Door and Window Sensor :100
33 EZVIZ EZVIZ T2C Door and Window Contact Sensor Door and Window Sensor :100
22 Tuya Tuya PIR Motion Sensor Motion sensor :100

Signed-off-by: frank-huang <frank.huang@samsung.com>

varzac · 2025-02-20T13:27:42Z

I think it would be good to also include a test of the device added behavior to verify that we read the zone type attribute and store it to the device record correctly.

qy-fang · 2025-02-21T01:34:21Z

I think it would be good to also include a test of the device added behavior to verify that we read the zone type attribute and store it to the device record correctly.

We will add that test.

Signed-off-by: frank-huang <frank.huang@samsung.com>

pInksenberg · 2025-02-21T11:41:18Z

I think it would be good to also include a test of the device added behavior to verify that we read the zone type attribute and store it to the device record correctly.

TC is updated

varzac · 2025-02-21T16:00:03Z

drivers/SmartThings/zigbee-sensor/src/test/test_zigbee_sensor.lua

+)
+
+test.register_coroutine_test(
+    "Configure should configure all necessary attributes(waterleak)",


These test names are not accurate as this isn't testing configure, this is testing added. This I think shows a potential issue. I think the cie address write will work, but since the configured attributes are set based on the defaults I don't think the ZoneStatus attribute will be configured for reporting. Are the devices properly reporting?

Yes, we will modify the name of the test. The device are not reporting Zone Status now, and we are in the process of configuring ZoneStatus for reporting.

varzac · 2025-02-21T16:02:31Z

drivers/SmartThings/zigbee-sensor/src/init.lua

+battery_config.reportable_change = 0x10
+battery_config.data_type = clusters.PowerConfiguration.attributes.BatteryVoltage.base_type
+
+local CONTACT_SWITCH = 0x0015


You could use https://github.ecodesamsung.com/iot-hub/scripting-engine/blob/main/lua_libs/st/zigbee/generated/types/IasZoneType.lua instead of re-defining these here

OK. we will modify it.

Signed-off-by: frank-huang <frank.huang@samsung.com>

tpmanley · 2025-02-24T16:01:48Z

drivers/SmartThings/zigbee-sensor/src/init.lua

+    attribute = clusters.PowerConfiguration.attributes.BatteryPercentageRemaining.ID,
+    minimum_interval = 30,
+    maximum_interval = 21600,
+    data_type = clusters.PowerConfiguration.attributes.BatteryVoltage.base_type,


Suggested change

data_type = clusters.PowerConfiguration.attributes.BatteryVoltage.base_type,

data_type = clusters.PowerConfiguration.attributes.BatteryPercentageRemaining.base_type,

tpmanley · 2025-02-25T16:16:37Z

drivers/SmartThings/zigbee-sensor/src/init.lua

+  elseif type == WATER_SENSOR then
+    if zone_status:is_alarm1_set() then
+      event = capabilities.waterSensor.water.wet()
+    else 


Suggested change

else

else

nit: the linter noticed trailing whitespace here

tpmanley · 2025-02-25T16:21:32Z

I enabled the github workflow to run and it's showing the tests have these failures:

zigbee-sensor: 
	test zigbee sensor ERROR in Profile should change to Motion Sensor
	test zigbee sensor FAILED on Reported motion should be handled: active
	test zigbee sensor FAILED on Reported motion should be handled: inactive
	test zigbee sensor FAILED on ZoneStatusChangeNotification from motion sensor should be handled: active
	test zigbee sensor FAILED on ZoneStatusChangeNotification from motion sensor should be handled: inactive

greens · 2025-02-25T22:29:10Z

drivers/SmartThings/zigbee-sensor/profiles/generic-sensor.yml

+  - id: firmwareUpdate
+    version: 1
+  - id: refresh
+    version: 1


I expect a category is required, but if that's not the case then this is fine.

This profile applies when the ZoneType of the IASZone has not yet been identified. In this case, the profile will be updated to other profiles to reflect other categories such as contact, motion, etc.
Until the device receives the ZoneType, we have no definitive information regarding its category; all we know is that it is a sensor.
Is there a specific device type that can solely describe a sensor?

We have a GenericSensor category I believe. Not positive what the corresponding icon is, though.

We do found that device type in OCF device type wiki.

However, we have tested the profile with GenericSenso but noticed that there is no related icon displayed on the device card, only a default icon.
Upon investigation, we confirmed that the oic.d.sensor, which is the OCFdtype for GenericSensor, does not exist in the CN production environment.

Could you please assist us in confirming whether this device type exists in the Global production environment? If it does, we would like to request our cloud team to synchronize the device type with the CN production. Thank you for your assistance in advance.

It could be that the default icon is also what's used on the global environments. I'm not sure, though. It's not a new category, so I'd be surprised if it was different on CN.

Mainly this comment was just in case the driver packager complained about the profile not including a category. I thought it might have been a required field. If it's not a required field then you can ignore this comment. Default icon is fine for a device with undetermined functionality.

greens · 2025-02-25T22:34:37Z

drivers/SmartThings/zigbee-sensor/src/init.lua

+      event = capabilities.motionSensor.motion.inactive()
+    end
+  elseif type == WATER_SENSOR then
+    if zone_status:is_alarm1_set() then


any reason why alarm2 isn't used as a trigger here?

if it should be, this function could be simplified to use a map

local event_mapping = { CONTACT_SWITCH = {active = capabilitiles.contactSensor.contact.open(), inactive = capabilities.contactSensor.contact.closed()} ... } if alarm1 or alarm2 then device:emit_event_for_endpoint(event_mapping[type].active) else ...

something like that

We will check that

As we confirmed in ZCL library, the water sensor does not support alarm2 trigger.
(Table 8-5 in ZCL library file).

Value Zone Type Alarm1 Alarm2

0x0000 Standard CIE System Alarm -

0x000d Motion sensor Intrusion indication Presence indication

0x0015 Contact switch 1st portal Open-Close 2nd portal Open-Close

0x0016 Door/Window handle See Table 8-7 See Table 8-7

0x0028 Fire sensor Fire indication -

0x002a Water sensor Water overflow indication -

greens · 2025-02-25T22:41:12Z

drivers/SmartThings/zigbee-sensor/src/init.lua

+    device:emit_event_for_endpoint(
+      zb_rx.address_header.src_endpoint.value,
+      event)
+    if device:get_component_id_for_endpoint(zb_rx.address_header.src_endpoint.value) ~= "main" then
+      device:emit_event(event)
+    end


Is this being done to future-proof a possible implementation for a sensor with multiple different endpoints? I get the instinct but you'd have to have all the capabilities on the main component already in order to do this. It's probably best to just emit from the specific component rather than trying to (in the future) duplicate everything onto main as well.

OK, we will modify this one.

qy-fang · 2025-02-26T01:31:43Z

I enabled the github workflow to run and it's showing the tests have these failures:

zigbee-sensor: 
	test zigbee sensor ERROR in Profile should change to Motion Sensor
	test zigbee sensor FAILED on Reported motion should be handled: active
	test zigbee sensor FAILED on Reported motion should be handled: inactive
	test zigbee sensor FAILED on ZoneStatusChangeNotification from motion sensor should be handled: active
	test zigbee sensor FAILED on ZoneStatusChangeNotification from motion sensor should be handled: inactive

We will check it

Signed-off-by: frank-huang <frank.huang@samsung.com>

inasail reviewed Feb 11, 2025

View reviewed changes

varzac reviewed Feb 11, 2025

View reviewed changes

lelandblue requested review from cbaumler and wkhenon February 11, 2025 14:04

inasail reviewed Feb 12, 2025

View reviewed changes

drivers/SmartThings/zigbee-sensor/config.yml Show resolved Hide resolved

pInksenberg force-pushed the add_support_for_generic_zigbee_sensor branch 3 times, most recently from 52d5eca to 7320dbe Compare February 13, 2025 11:08

varzac reviewed Feb 13, 2025

View reviewed changes

pInksenberg force-pushed the add_support_for_generic_zigbee_sensor branch from 7320dbe to 6771cba Compare February 14, 2025 10:48

add support for generic zigbee sensor

7a4d856

pInksenberg force-pushed the add_support_for_generic_zigbee_sensor branch from 6771cba to 7a4d856 Compare February 14, 2025 11:01

FrankSpringfield reviewed Feb 14, 2025

View reviewed changes

FrankSpringfield mentioned this pull request Feb 14, 2025

A test for automatically identify and provide suitable profile FrankSpringfield/SmartThingsEdgeDrivers#1

Closed

varzac reviewed Feb 14, 2025

View reviewed changes

tpmanley reviewed Feb 14, 2025

View reviewed changes

pInksenberg closed this Feb 20, 2025

pInksenberg force-pushed the add_support_for_generic_zigbee_sensor branch from 2d38ca2 to e8f7f2c Compare February 20, 2025 07:15

pInksenberg reopened this Feb 20, 2025

pInksenberg force-pushed the add_support_for_generic_zigbee_sensor branch from 2d38ca2 to d446b94 Compare February 20, 2025 07:32

Replace batteryLevel with battery

6b7d791

Signed-off-by: frank-huang <frank.huang@samsung.com>

pInksenberg force-pushed the add_support_for_generic_zigbee_sensor branch from d446b94 to 6b7d791 Compare February 20, 2025 09:38

Add test cases for added, receiving zonetype and profile changing

fa1311c

Signed-off-by: frank-huang <frank.huang@samsung.com>

FrankSpringfield force-pushed the add_support_for_generic_zigbee_sensor branch from 2e45960 to fa1311c Compare February 21, 2025 08:38

improve code and add TC

fb68377

varzac reviewed Feb 21, 2025

View reviewed changes

add configurations and related test cases

f4cc05a

Signed-off-by: frank-huang <frank.huang@samsung.com>

hongye-samsung force-pushed the add_support_for_generic_zigbee_sensor branch from e33e9d6 to f4cc05a Compare February 24, 2025 09:16

tpmanley reviewed Feb 24, 2025

View reviewed changes

tpmanley reviewed Feb 25, 2025

View reviewed changes

tpmanley requested a review from greens February 25, 2025 16:17

greens reviewed Feb 25, 2025

View reviewed changes

pInksenberg force-pushed the add_support_for_generic_zigbee_sensor branch 3 times, most recently from 7f03dd8 to fbb2301 Compare February 27, 2025 02:08

Add IasZoneType from lua.api

1dd4216

pInksenberg force-pushed the add_support_for_generic_zigbee_sensor branch from fbb2301 to 1dd4216 Compare February 27, 2025 08:21

Modify test case for changed drivers

6113590

Signed-off-by: frank-huang <frank.huang@samsung.com>

	data_type = clusters.PowerConfiguration.attributes.BatteryVoltage.base_type,
	data_type = clusters.PowerConfiguration.attributes.BatteryPercentageRemaining.base_type,

Value	Zone Type	Alarm1	Alarm2
0x0000	Standard CIE	System Alarm	-
0x000d	Motion sensor	Intrusion indication	Presence indication
0x0015	Contact switch	1st portal Open-Close	2nd portal Open-Close
0x0016	Door/Window handle	See Table 8-7	See Table 8-7
0x0028	Fire sensor	Fire indication	-
0x002a	Water sensor	Water overflow indication	-

add support for generic zigbee sensor #1921

Are you sure you want to change the base?

add support for generic zigbee sensor #1921

Conversation

pInksenberg commented Feb 11, 2025

Type of Change

Checklist

Description of Change

Summary of Completed Tests

github-actions bot commented Feb 11, 2025

github-actions bot commented Feb 11, 2025

github-actions bot commented Feb 11, 2025 • edited Loading

Test Results

github-actions bot commented Feb 11, 2025 • edited Loading

inasail Feb 11, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

inasail Feb 11, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

varzac Feb 11, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

varzac commented Feb 20, 2025

qy-fang commented Feb 21, 2025

pInksenberg commented Feb 21, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tpmanley Feb 24, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tpmanley commented Feb 25, 2025

Choose a reason for hiding this comment

FrankSpringfield Feb 26, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

FrankSpringfield Feb 26, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

qy-fang commented Feb 26, 2025

github-actions bot commented Feb 11, 2025 •

edited

Loading

github-actions bot commented Feb 11, 2025 •

edited

Loading

inasail Feb 11, 2025 •

edited

Loading

inasail Feb 11, 2025 •

edited

Loading

varzac Feb 11, 2025 •

edited

Loading

tpmanley Feb 24, 2025 •

edited

Loading

FrankSpringfield Feb 26, 2025 •

edited

Loading

FrankSpringfield Feb 26, 2025 •

edited

Loading