(EDGE Driver-Mc): Zigbee Drivers for Motion, Open/Close, Moisture, Smoke-Co Sensors and others Devices

Hello @nayelyz,
Analyzing the logs, I don’t think the problem is using MoveToLevelWithOnOff

I think the problem is in the automation. It is the problem that has already been reported that in order to establish actions of other capabilities it is always necessary to also activate the switch to on.

Then 2 commands are sent: (See the previous logs posted)

  • Turn On: Turn on the device with the last known level. (currentLevel)
  • MoveToLevelWithOnOff: turn the device On and to the level set in the command

This is confirmed if you turn off the device at 100% level and directly execute MoveToLevelWithOnOff in the details view, entering a level of 5%, for example.

It never turns on the device at the last known 100% level, it turns it on directly at the 5% level.
See logs with stock zigbee Switch version 2022-02-23T00:49:26.1289948

2022-02-24T11:33:32.052807930+00:00 INFO Zigbee Switch <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0x1786] (Luz Mesita)> received command: {“component”:“main”,“positional_args”:[5],“args”:{“level”:5},“capability”:“switchLevel”,“command”:“setLevel”}
2022-02-24T11:33:32.067793930+00:00 TRACE Zigbee Switch Found CapabilityCommandDispatcher handler in zigbee_switch → ZLL Dimmer Bulb
2022-02-24T11:33:32.085218930+00:00 INFO Zigbee Switch <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0x1786] (Luz Mesita)> sending Zigbee message: < ZigbeeMessageTx || Uint16: 0x0000, < AddressHeader || src_addr:
0x0000, src_endpoint: 0x01, dest_addr: 0x1786, dest_endpoint: 0x03, profile: 0x0104, cluster: Level >, < ZCLMessageBody || < ZCLHeader || frame_ctrl: 0x01, seqno: 0x00, ZCLCommandId: 0x04 >, < MoveToLevelWithOnOff || level: 0x0C, transition_time: 0xFFFF, options_mask: 0x00, options_override: 0x00 > > >
2022-02-24T11:33:32.109081596+00:00 DEBUG Zigbee Switch Luz Mesita device thread event handled
2022-02-24T11:33:32.128604263+00:00 DEBUG Zigbee Switch Luz Mesita device thread event handled
2022-02-24T11:33:32.261906596+00:00 TRACE Zigbee Switch Received event with handler zigbee
2022-02-24T11:33:32.303585263+00:00 INFO Zigbee Switch <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0x1786] (Luz Mesita)> received Zigbee message: < ZigbeeMessageRx || type: 0x00, < AddressHeader || src_addr: 0x1786, src_endpoint: 0x03, dest_addr: 0x0000, dest_endpoint: 0x01, profile: 0x0104, cluster: Level >, lqi: 0xB8, rssi: -54, body_length: 0x0005, < ZCLMessageBody || < ZCLHeader || frame_ctrl: 0x18, seqno: 0x4F, ZCLCommandId: 0x0B >, < DefaultResponse || cmd: 0x04, ZclStatus: SUCCESS > > >
2022-02-24T11:33:32.418452263+00:00 DEBUG Zigbee Switch Luz Mesita device thread event handled
2022-02-24T11:33:32.444408596+00:00 TRACE Zigbee Switch Received event with handler zigbee
2022-02-24T11:33:32.514967930+00:00 INFO Zigbee Switch <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0x1786] (Luz Mesita)> received Zigbee message: < ZigbeeMessageRx || type: 0x00, < AddressHeader || src_addr: 0x1786, src_endpoint: 0x03, dest_addr: 0x0000, dest_endpoint: 0x01, profile: 0x0104, cluster: OnOff >, lqi: 0xB8, rssi: -54, body_length: 0x0007, < ZCLMessageBody || < ZCLHeader || frame_ctrl: 0x18, seqno: 0x8C, ZCLCommandId: 0x0A >, < ReportAttribute || < AttributeRecord || AttributeId: 0x0000, DataType: Boolean, OnOff: true > > > >
2022-02-24T11:33:32.641229263+00:00 TRACE Zigbee Switch Found ZigbeeMessageDispatcher handler in zigbee_switch
2022-02-24T11:33:32.657440930+00:00 INFO Zigbee Switch Executing ZclClusterAttributeValueHandler: cluster: OnOff, attribute: OnOff
2022-02-24T11:33:32.710351263+00:00 INFO Zigbee Switch <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0x1786] (Luz Mesita)> emitting event: {“component_id”:“main”,“attribute_id”:“switch”,“capability_id”:“switch”,“state”:{“value”:“on”}}
2022-02-24T11:33:32.801464930+00:00 DEBUG Zigbee Switch Luz Mesita device thread event handled
2022-02-24T11:33:32.831217263+00:00 TRACE Zigbee Switch Received event with handler zigbee
2022-02-24T11:33:32.863446263+00:00 INFO Zigbee Switch <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0x1786] (Luz Mesita)> received Zigbee message: < ZigbeeMessageRx || type: 0x00, < AddressHeader || src_addr: 0x1786, src_endpoint: 0x03, dest_addr: 0x0000, dest_endpoint: 0x01, profile: 0x0104, cluster: Level >, lqi: 0xB8, rssi: -54, body_length: 0x0007, < ZCLMessageBody || < ZCLHeader || frame_ctrl: 0x18, seqno: 0x8D, ZCLCommandId: 0x0A >, < ReportAttribute || < AttributeRecord || AttributeId: 0x0000, DataType: Uint8, CurrentLevel: 0x0C > > > >
2022-02-24T11:33:33.045299597+00:00 TRACE Zigbee Switch Found ZigbeeMessageDispatcher handler in zigbee_switch
2022-02-24T11:33:33.054061930+00:00 INFO Zigbee Switch Executing ZclClusterAttributeValueHandler: cluster: Level, attribute: CurrentLevel
2022-02-24T11:33:33.068711263+00:00 INFO Zigbee Switch <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0x1786] (Luz Mesita)> emitting event: {“component_id”:“main”,“attribute_id”:“level”,“capability_id”:“switchLevel”,“state”:{“value”:5}}
2022-02-24T11:33:33.108776597+00:00 DEBUG Zigbee Switch Luz Mesita device thread event handled

Once the level event is emitted, the attributes 0x0000 de OnOff and level is read and the level 5% event is emitted again

2022-02-24T11:33:34.121596597+00:00 INFO Zigbee Switch <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0x1786] (Luz Mesita)> sending Zigbee message: < ZigbeeMessageTx || Uint16: 0x0000, < AddressHeader || src_addr:
0x0000, src_endpoint: 0x01, dest_addr: 0x1786, dest_endpoint: 0x03, profile: 0x0104, cluster: Level >, < ZCLMessageBody || < ZCLHeader || frame_ctrl: 0x00, seqno: 0x00, ZCLCommandId: 0x00 >, < ReadAttribute || AttributeId: 0x0000 > > >
2022-02-24T11:33:34.135484597+00:00 INFO Zigbee Switch <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0x1786] (Luz Mesita)> sending Zigbee message: < ZigbeeMessageTx || Uint16: 0x0000, < AddressHeader || src_addr:
0x0000, src_endpoint: 0x01, dest_addr: 0x1786, dest_endpoint: 0x03, profile: 0x0104, cluster: OnOff >, < ZCLMessageBody || < ZCLHeader || frame_ctrl: 0x00, seqno: 0x00, ZCLCommandId: 0x00 >, < ReadAttribute || AttributeId: 0x0000 > > >
2022-02-24T11:33:34.162285264+00:00 DEBUG Zigbee Switch Luz Mesita device thread event handled
2022-02-24T11:33:34.248066597+00:00 TRACE Zigbee Switch Received event with handler zigbee
2022-02-24T11:33:34.260388597+00:00 INFO Zigbee Switch <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0x1786] (Luz Mesita)> received Zigbee message: < ZigbeeMessageRx || type: 0x00, < AddressHeader || src_addr: 0x1786, src_endpoint: 0x03, dest_addr: 0x0000, dest_endpoint: 0x01, profile: 0x0104, cluster: Level >, lqi: 0xB8, rssi: -54, body_length: 0x0008, < ZCLMessageBody || < ZCLHeader || frame_ctrl: 0x18, seqno: 0x50, ZCLCommandId: 0x01 >, < ReadAttributeResponse || < AttributeRecord || AttributeId: 0x0000, ZclStatus: SUCCESS, DataType: Uint8, CurrentLevel: 0x0C > > > >
2022-02-24T11:33:34.299747597+00:00 TRACE Zigbee Switch Found ZigbeeMessageDispatcher handler in zigbee_switch
2022-02-24T11:33:34.308163931+00:00 INFO Zigbee Switch Executing ZclClusterAttributeValueHandler: cluster: Level, attribute: CurrentLevel
2022-02-24T11:33:34.315910264+00:00 INFO Zigbee Switch <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0x1786] (Luz Mesita)> emitting event: {“component_id”:“main”,“attribute_id”:“level”,“capability_id”:“switchLevel”,“state”:{“value”:5}}

Ok, you can “unselect” any of the switch options if you tap on the blue circle again, this means that the automation won’t have the part of “turn on” but you mention that MoveToLevelWithOnOff turns on the device.
Can you test the behavior of the automation doing that, please?
See the example here:

3 Likes

So it works perfectly.

This function was requested and we did not know that it had been added to any of the latest updates of the app.

Good to Know!!!

Now we will have to rebuild some automations

I have also tried other devices that have custom capabilities and now you can, for example, activate or deactivate them in automations without having to turn on the device

3 Likes

Apparently, it was there since the beginning but it wasn’t clear for a lot of users (including me), even when I asked the team, nobody mentioned it.
Someone shared that in another post:

3 Likes

Does this creates opportunity to change level and light Temperature to without turning lights on?

Yes, and active/deactive others custom capabilities as random on off, circadian, progressive on off, color effects…

1 Like

That works indeed. However, auto turn off options is not available then. So I have to create a new automation combined with a virtual switch. It’s a workaround but shouldn’t be need this complex combination for such a simple logic, should be?

Regards.

Hey Mariano, buenos dias.

Another model and FP to Zigbee Lock MC: Yale Door Lock - YDF40

Data

  • application: 0B
  • endpointId: 01
  • firmwareFullVersion: 0000000B
  • firmwareImageType: 0
  • firmwareManufacturerCode: 4491
  • manufacturer: ASSA ABLOY iRevo
  • model: iZBModule01
  • zigbeeNodeType: SLEEPY_END_DEVICE

Raw Description 01 0104 000A 00 09 0000 0001 0003 0004 0005 0009 000A 0020 0101 02 000A 0019

Thanks!

This model exist in stock beta zigbee lock.

- id: "ASSA ABLOY iRevo/iZBModule01"
    deviceLabel: "Yale Door Lock"
    manufacturer: ASSA ABLOY iRevo
    model: iZBModule01
    deviceProfileName: base-lock
2 Likes

I don’t know anything about zwave or zigbee locks.
The only thing I did was add a fingerprint of a zigbee model very similar to the existing ones.

From zwave I guess they will make the stock driver the same as they did with zigbee

1 Like

Hello Mariano, accordind to you could be possible to mannually chsnge the type of device in the driver or somewhere in the settings?

For example i would turn a contact sensor in a smoke sensor or vibration sensor.

In this way we could tranform every non-smart sensor in the correct type of sensor using an “universal” contact sensor…

Obviously i need to do some hardware hacks in the sensors, but could be nice that smartthings recognize the correct type

It’s a crazy idea?

I don’t remember saying something like that or I don’t quite understand what you mean.

The devices have their specific data input and output clusters, which define what functions they perform.

for example 0006 is switch, 0402 is temperature, 0500 IAS is used for various, contact, motion, button, water leak…

This cannot be changed.

The only thing that can be done in the driver is to add capabilities, which could function as virtual and emit events or receive commands that are handled with code within the driver.

For example, the thermostat driver can turn any device that has cluster 0402, temperature, into a thermostat, by adding these capabilities and the code to handle them.

I don’t know if this is what you mean

@Mariano_Colmenarejo Hello my friend, how are you ! Please you add this device, thanks again!

sorry for my English.
I will try to explain my idea better with a real case.

I have a smoke sensor which is very good but it is not smart, it is just standalone …
In this case I can connect the smoke sensor output to a zigbee device such as a contact sensor instead of the reed switch.
In this way, when the smoke sensor closes the circuit, the zigbee device will be activated …
But we get notifications about the type of device used, obviously not like the smoke sensor …

I solve this problem by building an automation with a virtual edge device smoke sensor that is activated by the real contact sensor.

But it would be nice if the sensor type could be changed in the driver by the user based on usage.

My idea is to create a “universal” sensor driver starting from a contact sensor or a button that could be used in several ways.

But shoud be mandatory that the users select the kind of the sensor manually in driver settings

In specific cases like the one you mention of Smoke sensor, it could be easily used, but not all device activation or desctivstion outputs carries with it a discrete change, voltage, open/closed circuit, that can be easily detected, interpreted and redirected to the platform by a contact sensor or button.

Most of the time, devices send an encoded value in a radio transmission (zigbee, zwave, wifi), which the receiver (driver, DTH), decodes to know the status of the device and broadcast the event to the platform.

That is why the option of doing something universal with a contact sensor or button does not seem possible to me.

There were DTH’s written for contact sensors to make them behave like smoke detectors, moisture sensors, etc. Monoprice had an open/close sensor with internal connects that were useful.

Data * MSR: 0109-2001-0102

  • endpointId: 0
  • networkSecurityLevel: ZWAVE_LEGACY_NON_SECURE
    Raw Description zw:L type:2001 mfr:0109 prod:2001 model:0102 cc:71,85,80,72,30,86,84

I have used them as Smoke Detectors (Smoke/Clear), Moisture Sensors (Wet/Dry), Security System (Armed/Disarmed) among others. I would welcome a driver with these capabilities.

Most Yale models have a removeable radio module. They make these modules for a number of different protocols, including zwave, zigbee, Bluetooth, HomeKit—they’ve even announced there will be one for Matter later this year.

The lock always has the same model number, but the suffix changes depending which radio module it was shipped with. The modules are easy to swap out, basically like changing batteries. (Assa Abloy is Yale’s parent company.)

image


Each module only has one protocol (except one which has WiFi and Bluetooth) so it will operate on EITHER zigbee or zwave, not both at the same time.

Zigbee:

Zwave:

But while it’s easy to switch the modules, the DTH/Edge Driver must also be changed to match. Zwave for Zwave, Zigbee for Zigbee.

2 Likes

I’m not sure what’s available in Europe. :thinking:

Be careful because some of the Zigbee modules will only work with Control4, which uses its own proprietary zigbee profile. Those won’t work with smartthings.

1 Like

Added to this driver version

┌─────────────┬──────────────────────────────────────┐
│ Name        │ Zigbee Switch Mc                     │
│ Version     │ 2022-03-01T12:43:17.365554           │
└─────────────┴──────────────────────────────────────┘
  - id: "_TZ3000_v7gnj3ad/Switch"
    deviceLabel: TUYATEC Switch
    manufacturer: _TZ3000_v7gnj3ad
    model: TS0001
    deviceProfileName: single-switch
1 Like

Thanks man !

1 Like