Power On Behaviour Packet Sniff - TS0505B / _TZB210_tmi0rihb "Zigbee 3.0 5 in 1 LED Strip Controller Model LM052"

[jarrah31]

What happened?

Hi Koenkk,

Would you be able to help me add power_on_behavior for the Laimi / Tuya TS0505B, _TZB210_tmi0rihb device please? (originally added as a new device here: #12168)

I contacted the Laimi manufacturer to ask if the device supported power_on_behavior, and they replied with the following:

You can buy a Tuya Zigbee gateway connect with our controller, use the Tuya Smart Life APP to set "Do Not disturb function“”. Our controller has memory, after you set "Do Not disturb function", the controller will save it automatically.
Kind Regards,
Sky Liu
Shenzhen You Lai Mi Technology Co.,Ltd

Unfortunately I don't have a Tuya hub to sniff the packets when this option is set, but I'm ready and willing to run any test commands or external_converters on a dev zigbee2mqtt that I have this device paired to. If this isn't possible, I'm willing to buy the Tuya hub to help get this working.

Thanks in advance!

What did you expect to happen?

No response

How to reproduce it (minimal and precise)

No response

Zigbee2MQTT version

1.29.2

Adapter firmware version

20221102

Adapter

zzh

Debug log

No response

[jarrah31]

I now have a Tuya Zigbee Gateway and I have been able to set the "Do Not Disturb" feature for this LED controller. I will attempt the sniff the traffic over the next few days to see if this helps you figure out the required setting.

One thing worth noting is that Do Not Disturb is an on or off setting, there's no option to define the previous state. It also work different to what I expected - when the feature is enabled and you turn power back on, the LED strip briefly lights up for around 5-7 seconds and then turns off. It does this no matter what state the light was previously in.

[jarrah31]

Packet has now been sniffed! Hopefully the attached packet trace will help you figure out the required setting @Koenkk

tuya_TZB210_tmi0rihb_PwOnSetting.pcapng.zip

Decryption key is: 5be76546b74e7add78c0dc72dd0a56e4

Packets 46 and 158 are the off messages sent when I press save in the above screenshot.

Packet 106 and 192 are the on messages.

Good luck and thanks in advance!

[Koenkk]

@jarrah31 could you find out the data point of do_not_disturb using https://www.zigbee2mqtt.io/advanced/support-new-devices/03_find_tuya_data_points.html

[jarrah31]

Hi @Koenkk, thanks for your help!

The data point for do_not_disturb is 34!

[Koenkk]

Can you try with:

const fz = require('zigbee-herdsman-converters/converters/fromZigbee');
const tz = require('zigbee-herdsman-converters/converters/toZigbee');
const exposes = require('zigbee-herdsman-converters/lib/exposes');
const reporting = require('zigbee-herdsman-converters/lib/reporting');
const extend = require('zigbee-herdsman-converters/lib/extend');
const ota = require('zigbee-herdsman-converters/lib/ota');
const tuya = require('zigbee-herdsman-converters/lib/tuya');
const utils = require('zigbee-herdsman-converters/lib/utils');
const globalStore = require('zigbee-herdsman-converters/lib/store');
const e = exposes.presets;
const ea = exposes.access;

const definition = {
    zigbeeModel: ['TS0505B'],
    model: 'TS0505B',
    vendor: 'TuYa',
    description: 'Zigbee RGB+CCT light',
    whiteLabel: [{vendor: 'Mercator Ikuü', model: 'SMD4106W-RGB-ZB'},
        {vendor: 'TuYa', model: 'A5C-21F7-01'}, {vendor: 'Mercator Ikuü', model: 'S9E27LED9W-RGB-Z'},
        {vendor: 'Aldi', model: 'L122CB63H11A9.0W', description: 'LIGHTWAY smart home LED-lamp - bulb'},
        {vendor: 'Lidl', model: '14153706L', description: 'Livarno smart LED ceiling light'},
        {vendor: 'Zemismart', model: 'LXZB-ZB-09A', description: 'Zemismart LED Surface Mounted Downlight 9W RGBW'},
        {vendor: 'Feconn', model: 'FE-GU10-5W', description: 'Zigbee GU10 5W smart bulb'},
    ],
    extend: extend.light_onoff_brightness_colortemp_color(
        {colorTempRange: [153, 500], disableColorTempStartup: true, disablePowerOnBehavior: true}),
    toZigbee: [...extend.light_onoff_brightness_colortemp_color(
        {colorTempRange: [153, 500], disableColorTempStartup: true, disablePowerOnBehavior: true}).toZigbee, tz.tuya_do_not_disturb],
    exposes: [...extend.light_onoff_brightness_colortemp_color(
            {colorTempRange: [153, 500], disableColorTempStartup: true, disablePowerOnBehavior: true}).exposes,
        exposes.binary('do_not_disturb', ea.STATE_SET, true, false)
            .withDescription('Do not disturb mode'),
    ],
    meta: {applyRedFix: true, enhancedHue: false},
};

module.exports = definition;

• save this as file next to configuration.yaml as ext_converter.js
• add it to configuration.yaml:

external_converters:
  - ext_converter.js

• start z2m, check if issue is fixed

[jarrah31]

Thanks @Koenkk, I can confirm that do_not_disturb now works as intended for this device!

One more question if I may - I set the availability option on this device with a timeout of 1, expecting Z2M to detect that my light state was off after returning from power (it was on before turning power off/on), but even though the light is off, several minutes later I find Z2M still thinks the device is on.

The same is true if I set do_not_distrub to false, turn the light off from within Z2m, power off and then on the device, the light resumes on and stays on, but Z2M still shows it as off 5 mins later.

Is it perhaps because the device is running as an external converter and all will be ok once it's properly integrated?

This is my config just in case it helps:

homeassistant: false
permit_join: true
mqtt:
  base_topic: testzigbee
  server: mqtt://192.168.1.10
  user: mqttuser
  password: password
serial:
  port: /dev/ttyUSB0
advanced:
  homeassistant_legacy_entity_attributes: false
  legacy_api: false
  legacy_availability_payload: false
device_options:
  legacy: false
devices:
  '0xa4c1389473a50933':
    friendly_name: '0xa4c1389473a50933'
    availability:
      timeout: 1
frontend:
  port: 8080
external_converters:
  - ext_converter.js

[Koenkk]

z2m should read the state when the device is powered off again, but only if z2m detected the device as being OFF. Could you provide me the debug log of this?

See https://www.zigbee2mqtt.io/guide/usage/debug.html on how to enable debug logging.

[jarrah31]

Debug and herdsman logs in the following log files. I've added comments to show what I did at each stage of the logs to hopefully make it easier to follow.
https://textbin.net/eikxmfp1c1
Thank you @Koenkk

[Koenkk]

This seems to be a bug of the device firmware:

Zigbee2MQTT:debug 2023-02-01 20:20:43: Retrieving state of '0xa4c1389473a50933' after reconnect
  zigbee-herdsman:controller:endpoint Read 0xa4c1389473a50933/1 genOnOff(["onOff"], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) +2s
  zigbee-herdsman:adapter:zStack:adapter sendZclFrameToEndpointInternal 0xa4c1389473a50933:50252/1 (0,0,1) +2s
  zigbee-herdsman:adapter:zStack:znp:SREQ --> AF - dataRequest - {"dstaddr":50252,"destendpoint":1,"srcendpoint":1,"clusterid":6,"transid":13,"options":0,"radius":30,"len":5,"data":{"type":"Buffer","data":[16,10,0,0,0]}} +2s
  zigbee-herdsman:adapter:zStack:unpi:writer --> frame [254,15,36,1,76,196,1,1,6,0,13,0,30,5,16,10,0,0,0,168] +2s
  zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,1,100,1,0,100] +2s
  zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,1,100,1,0,100] +1ms
  zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 1 - 3 - 4 - 1 - [0] - 100 +0ms
  zigbee-herdsman:adapter:zStack:znp:SRSP <-- AF - dataRequest - {"status":0} +2s
  zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [] +1ms
  zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,3,68,128,0,1,13,203] +3ms
  zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,3,68,128,0,1,13,203] +0ms
  zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 3 - 2 - 4 - 128 - [0,1,13] - 203 +1ms
  zigbee-herdsman:adapter:zStack:znp:AREQ <-- AF - dataConfirm - {"status":0,"endpoint":1,"transid":13} +2s
  zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [] +0ms
  zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,28,68,129,0,0,6,0,76,196,1,1,0,105,0,52,164,132,0,0,8,24,10,1,0,0,0,16,1,76,196,29] +13ms
  zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,28,68,129,0,0,6,0,76,196,1,1,0,105,0,52,164,132,0,0,8,24,10,1,0,0,0,16,1,76,196,29] +1ms
  zigbee-herdsman:adapter:zStack:unpi:parser <-- [181] +2ms
  zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,28,68,129,0,0,6,0,76,196,1,1,0,105,0,52,164,132,0,0,8,24,10,1,0,0,0,16,1,76,196,29,181] +0ms
  zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 28 - 2 - 4 - 129 - [0,0,6,0,76,196,1,1,0,105,0,52,164,132,0,0,8,24,10,1,0,0,0,16,1,76,196,29] - 181 +0ms
  zigbee-herdsman:adapter:zStack:znp:AREQ <-- AF - incomingMsg - {"groupid":0,"clusterid":6,"srcaddr":50252,"srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":105,"securityuse":0,"timestamp":8692788,"transseqnumber":0,"len":8,"data":{"type":"Buffer","data":[24,10,1,0,0,0,16,1]}} +17ms
  zigbee-herdsman:controller:log Received 'zcl' data '{"frame":{"Header":{"frameControl":{"frameType":0,"manufacturerSpecific":false,"direction":1,"disableDefaultResponse":true,"reservedBits":0},"transactionSequenceNumber":10,"manufacturerCode":null,"commandIdentifier":1},"Payload":[{"attrId":0,"status":0,"dataType":16,"attrData":1}],"Command":{"ID":1,"name":"readRsp","parameters":[{"name":"attrId","type":33},{"name":"status","type":32},{"name":"dataType","type":32,"conditions":[{"type":"statusEquals","value":0}]},{"name":"attrData","type":1000,"conditions":[{"type":"statusEquals","value":0}]}]}},"address":50252,"endpoint":1,"linkquality":105,"groupID":0,"wasBroadcast":false,"destinationEndpoint":1}' +2s
Zigbee2MQTT:debug 2023-02-01 20:20:43: Received Zigbee message from '0xa4c1389473a50933', type 'readResponse', cluster 'genOnOff', data '{"onOff":1}' from endpoint 1 with groupID 0
  zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [] +10ms
Zigbee2MQTT:info  2023-02-01 20:20:43: MQTT publish: topic 'testzigbee/0xa4c1389473a50933', payload '{"brightness":4,"color_mode":"color_temp","color_temp":370,"do_not_disturb":true,"linkquality":105,"state":"ON"}'

The device responds its state with:

Received Zigbee message from '0xa4c1389473a50933', type 'readResponse', cluster 'genOnOff', data '{"onOff":1}' from endpoint 1 with groupID 0

And onOff 1 means ON.

[jarrah31]

Great, thanks for finding this out, I will report it back to the manufacturer!

Thank you also for adding the power_on_behaviour. I'll be happy to test a dev version with this new feature when available.

[Koenkk]

Fixed by Koenkk/zigbee-herdsman-converters#5444, do_not_disturb will now be supported for all TuYa lights.

Changes will be available in the dev branch in a few hours from now. (https://www.zigbee2mqtt.io/advanced/more/switch-to-dev-branch.html)

[rbickel]

Packet has now been sniffed! Hopefully the attached packet trace will help you figure out the required setting @Koenkk

tuya_TZB210_tmi0rihb_PwOnSetting.pcapng.zip

Decryption key is: 5be76546b74e7add78c0dc72dd0a56e4

Packets 46 and 158 are the off messages sent when I press save in the above screenshot.

Packet 106 and 192 are the on messages.

Good luck and thanks in advance!

Hi Jarrah, how do you get the encryption key of your tuya hub? I'd like to sniff the traffic from the tuya app to compare it to z2m. Thanks

[jarrah31]

I sniffed the key out with a CC2531 when a device joins the network using instructions found here: https://www.zigbee2mqtt.io/advanced/zigbee/04_sniff_zigbee_traffic.html#prerequisites

[rodolfomachado]

Sorry guys to talk in here but I have the same device and I'm using in ZHA and I'm not able to change DND.
I googled around and didn't have success.
Could you please tell me which Cluster, Attribute, Value and manufacturer code should I use/change?
Tks in advance.
(maybe it's time to change do z2m)