Lidl Melinera Smart LED string lights

[sonar98]

Device

• Product name: The device name as shown on the product or package.
• Manufacturer: _TZE200_s8gkrkxk
• Model identifier: TS0601
• Device type : Light

Screenshots

[Mimiix]

What is missing on this one? seems to be alright?

[sonar98]

Choosing a color is not working correctly. Colors do not match the choosen color. And the lights have buttons for different programs. These are not available in zigbee.

[Mimiix]

@Smanar Can you include this 😃?

[Smanar]

I m searching the product to have information, but a part a video on youtube, and not sure was the same. Do you think you can act on button using zigbee ? (instead of using them manually ?) Do you have seen something special about color ? For exemple orange instead of blue ?

For button, if you enable log, you will be probably able to see log starting with "Tuya debug X: xxxxxxxxxxxxxxxxxxxxx"

When using them

[sonar98]

How can I enable log? Is that possible on a RPI or windows computer?

[Mimiix]

@sonar98 From deconz gui click "Help" and click "debug view"

[sonar98]

I tried but I don't see any line starting with: "Tuya debug X

[Mimiix]

Even if you enable all ?

[Smanar]

You will have this kind of log every time the device use the tuya cluster. So try to use the switches on the devices.

BTW which one color have you instead of full red, full blue and full green ?

[sonar98]

When I switch it on I see: 16:58:12:200 Tuya debug 4 : Address 0x588E81FFFEDB7E9A Payload 00280101000101 16:58:12:200 Tuya debug 5 : Status: 0 Transid: 40 Dp: 257 (0x01,0x01) Fn: 0 Data 1 16:58:12:397 Tuya debug 4 : Address 0x588E81FFFEDB7E9A Payload 00280101000101 16:58:12:399 Tuya debug 5 : Status: 0 Transid: 40 Dp: 257 (0x01,0x01) Fn: 0 Data 1 16:58:12:599 Tuya debug 4 : Address 0x588E81FFFEDB7E9A Payload 00280101000101 16:58:12:600 Tuya debug 5 : Status: 0 Transid: 40 Dp: 257 (0x01,0x01) Fn: 0 Data 1 16:58:12:803 Tuya debug 4 : Address 0x588E81FFFEDB7E9A Payload 00280101000101 16:58:12:804 Tuya debug 5 : Status: 0 Transid: 40 Dp: 257 (0x01,0x01) Fn: 0 Data 1 16:58:12:997 Tuya debug 4 : Address 0x588E81FFFEDB7E9A Payload 00280101000101 16:58:12:999 Tuya debug 5 : Status: 0 Transid: 40 Dp: 257 (0x01,0x01) Fn: 0 Data 1 16:58:13:191 Tuya debug 4 : Address 0x588E81FFFEDB7E9A Payload 00280101000101 16:58:13:192 Tuya debug 5 : Status: 0 Transid: 40 Dp: 257 (0x01,0x01) Fn: 0 Data 1 16:58:13:393 Tuya debug 4 : Address 0x588E81FFFEDB7E9A Payload 00280101000101 16:58:13:394 Tuya debug 5 : Status: 0 Transid: 40 Dp: 257 (0x01,0x01) Fn: 0 Data 1 16:58:13:684 Tuya debug 4 : Address 0x588E81FFFEDB7E9A Payload 00280101000101 16:58:13:686 Tuya debug 5 : Status: 0 Transid: 40 Dp: 257 (0x01,0x01) Fn: 0 Data 1 16:58:13:794 Tuya debug 4 : Address 0x588E81FFFEDB7E9A Payload 00280101000101 16:58:13:795 Tuya debug 5 : Status: 0 Transid: 40 Dp: 257 (0x01,0x01) Fn: 0 Data 1 16:58:13:999 Tuya debug 4 : Address 0x588E81FFFEDB7E9A Payload 00280101000101 16:58:14:000 Tuya debug 5 : Status: 0 Transid: 40 Dp: 257 (0x01,0x01) Fn: 0 Data 1 16:58:14:189 Tuya debug 4 : Address 0x588E81FFFEDB7E9A Payload 00280101000101 16:58:14:190 Tuya debug 5 : Status: 0 Transid: 40 Dp: 257 (0x01,0x01) Fn: 0 Data 1 16:58:14:391 Tuya debug 4 : Address 0x588E81FFFEDB7E9A Payload 00280101000101 16:58:14:392 Tuya debug 5 : Status: 0 Transid: 40 Dp: 257 (0x01,0x01) Fn: 0 Data 1 16:58:14:592 Tuya debug 4 : Address 0x588E81FFFEDB7E9A Payload 00280101000101 16:58:14:593 Tuya debug 5 : Status: 0 Transid: 40 Dp: 257 (0x01,0x01) Fn: 0 Data 1 16:58:14:797 Tuya debug 4 : Address 0x588E81FFFEDB7E9A Payload 00280101000101 16:58:14:798 Tuya debug 5 : Status: 0 Transid: 40 Dp: 257 (0x01,0x01) Fn: 0 Data 1 16:58:14:983 Tuya debug 4 : Address 0x588E81FFFEDB7E9A Payload 00280101000101 16:58:14:984 Tuya debug 5 : Status: 0 Transid: 40 Dp: 257 (0x01,0x01) Fn: 0 Data 1 16:58:15:188 Tuya debug 4 : Address 0x588E81FFFEDB7E9A Payload 00280101000101 16:58:15:189 Tuya debug 5 : Status: 0 Transid: 40 Dp: 257 (0x01,0x01) Fn: 0 Data 1 16:58:15:390 Tuya debug 4 : Address 0x588E81FFFEDB7E9A Payload 00280101000101 16:58:15:391 Tuya debug 5 : Status: 0 Transid: 40 Dp: 257 (0x01,0x01) Fn: 0 Data 1 16:58:15:595 Tuya debug 4 : Address 0x588E81FFFEDB7E9A Payload 00280101000101 16:58:15:597 Tuya debug 5 : Status: 0 Transid: 40 Dp: 257 (0x01,0x01) Fn: 0 Data 1 16:58:15:783 Tuya debug 4 : Address 0x588E81FFFEDB7E9A Payload 00280101000101 16:58:15:785 Tuya debug 5 : Status: 0 Transid: 40 Dp: 257 (0x01,0x01) Fn: 0 Data 1 16:58:15:988 Tuya debug 4 : Address 0x588E81FFFEDB7E9A Payload 00280101000101 16:58:15:990 Tuya debug 5 : Status: 0 Transid: 40 Dp: 257 (0x01,0x01) Fn: 0 Data 1 16:58:16:188 Tuya debug 4 : Address 0x588E81FFFEDB7E9A Payload 00280101000101 16:58:16:190 Tuya debug 5 : Status: 0 Transid: 40 Dp: 257 (0x01,0x01) Fn: 0 Data 1 16:58:16:380 Tuya debug 4 : Address 0x588E81FFFEDB7E9A Payload 00280101000101 16:58:16:382 Tuya debug 5 : Status: 0 Transid: 40 Dp: 257 (0x01,0x01) Fn: 0 Data 1 16:58:16:603 Tuya debug 4 : Address 0x588E81FFFEDB7E9A Payload 00280101000101 16:58:16:604 Tuya debug 5 : Status: 0 Transid: 40 Dp: 257 (0x01,0x01) Fn: 0 Data 1 16:58:16:782 Tuya debug 4 : Address 0x588E81FFFEDB7E9A Payload 00280101000101 16:58:16:784 Tuya debug 5 : Status: 0 Transid: 40 Dp: 257 (0x01,0x01) Fn: 0 Data 1 16:58:16:984 Tuya debug 4 : Address 0x588E81FFFEDB7E9A Payload 00280101000101 16:58:16:986 Tuya debug 5 : Status: 0 Transid: 40 Dp: 257 (0x01,0x01) Fn: 0 Data 1

But when pushing the buttons nothing happens

[Smanar]

Hooow, I think we can call this spam ^^, 10 request by seconds.

And yes 0x01 0x01 is good, like you said, it s generaly the command used to turn on a device. But useless, as the cluster 0x0006 is already working

Unfortunately, the tuya cluster is the only one possible to receive information about the switches.

Do you know if the official lidl app can change the programs too ?

[sonar98]

I don't know (yet). The Lidl app only works with the silvercrest gateway. Friday there Will be a special offer in the shop. I will try to get a silvercrest gateway to test the capabilities.

Screenshot in the commercial looks like it is possible

https://www.voordeelmuis.nl/img/jpg/2786/2786583.jpg

[Smanar]

Do you have a picture of the switches on the device ?

Perhaps it s memorised scene, but the "setting" of the scene can come from another device, you can change locally the programs and it s working, but nothing usefull is visible on log ? (other than tuya debug)

[sonar98]

There are two physical buttons.

1. Color
2. Function

[Smanar]

And what they are doing ? You don't see anything on log when using them (about scenes for exemple), even it s not tuya cluster ?

[alex3305]

An online manual is also available for this device. And this seems to be the Zigbee Alliance certification.

[Smanar]

Ok I hve found some informations on z2m https://github.com/Koenkk/zigbee2mqtt.io/blob/master/docs/devices/HG06467.md

But How to use those with deconz ... Perhaps using "state/effect" for effect, "state/colorloopspeed" for speed and for color will see later ...

[sonar98]

Is this usefull?

https://github.com/Koenkk/zigbee-herdsman-converters/pull/1799

[Smanar]

Yep, but I prefer avoid to make a so hudge code for a device used only 1 month by year ^^ I have checked the deconz code, I think I will avoid to use the api command just for that, I will use an hidden command with same parameter than the z2m code, like that I will not break the deconz code, and can make all the code in a separate file.

Do you have the json generated for this device ?

Do you need some return from it, or just be able to ask for effect ?

[sonar98]

"5": {
        "etag": "d47e9d5b3db50b4459f4ed3e1bd203cc",
        "hascolor": true,
        "lastannounced": null,
        "lastseen": "2020-11-24T13:16Z",
        "manufacturername": "Heiman",
        "modelid": "TS0601",
        "name": "Color dimmable light 5",
        "state": {
            "alert": "none",
            "bri": 2,
            "colormode": "xy",
            "effect": "none",
            "hue": 65018,
            "on": true,
            "reachable": false,
            "sat": 127,
            "xy": [
                0,
                0
            ]
        },
        "swversion": null,
        "type": "Color dimmable light",
        "uniqueid": "58:8e:81:ff:fe:db:7e:9a-01"
    }

[ebaauw]

The user manual is online, https://www.lidl-service.com/cps/rde/xchg/SID-1FC8C7D5-504DC4E3/lsp/hs.xsl/product.html?id=5019460647&title=LED-verlichtingsketting&count=1.

Strip is for inside and outside use. No individual control of lights (at least from the app), but 16 pre-programmed effects. The app seems to support selecting speed and colours for (some of the) effects. Looks like we'll need their gateway to sniff how to set the effects. EUR 70 for gateway and strip, I'm tempted...

[sonar98]

Tomorrow I will receive the gateway.

[sonar98]

Some screenshots from the LIDL Home app when using the Silvercrest gateway:

[ebaauw]

Got one, incl. gateway, see #3762. Zigbee sniffer is working overtime.

The X-Mas lightstrip consists of 200 LEDs, which seem to be individually addressable, at least from the controller. I think LEDs are chained, connecting the data in of the next LED to the data out of the previous LED, like the Neopixel or Pimoroni Blinkt! (see Homebridge RPi). When setting the strip to a single colour, the new colour "travels through" the strip, suggesting a serial protocol. Same for the occasional erroneous setting of a single LED.

I'm not sure of this detailed level of control is exposed over Zigbee, though.

The strip seems to be controlled from cluster 0xEF00, but no Manufacturer Specific bit. Any change (be it white, colour or scene) results in a 0x00 command, followed by one or more 0x01 commands. The commands have a variable payload, up to 56 bytes. Even combined, the payloads doesn't seem to be large enough to hold the RGB and brightness values per LED. Presumably, the controller uses the payload to generate the serial signal.

BTW, if you hold an X-Mas tree, a window pops up to change the speed and colours for the scene.

[Smanar]

@ebaauw, the protocole is already sniffed and decrypted (look at z2m project) it use classic tuya command, can use the tuya code without problem.

bool DeRestPluginPrivate::SendTuyaRequest(TaskItem &taskRef, TaskType taskType , qint8 Dp_type, qint8 Dp_identifier , QByteArray data )

My problem is include this device without adding 5/6 command in deconz core for only one device, used 1 month by year.

I think using only 1 command, that take aall params, and put the code in tuya file.

[Smanar]

I have not the device, so nothing is tested, just deductions.

The command to use are for exemple for effect

//command
#define MELINERA_MODE 2
#define MELINERA_COLOR 5
#define MELINERA_EFFECT 6

//Mode
#define MELINERA_MODE_EFFECT 0x02
#define MELINERA_MODE_COLOR 0x01
#define MELINERA_MODE_WHITE 0x00

//Effect
QByteArray effect = QByteArray("\x48\x52", 2); // "04" for twinkle 
QByteArray speed = QByteArray("\x49\x48", 2); // speed = 10
QByteArray color= QByteArray("\x52\x52\x52\x49\x49\x49", 6); // color RGB 44,44,44 and color RGB 11,11,11 as twinkle  use 2 color

data = effect  + speed + color

SendTuyaRequest( taskRef, taskType , DP_TYPE_ENUM, MELINERA_MODE  , MELINERA_MODE_EFFECT)
SendTuyaRequest( taskRef, taskType , DP_TYPE_STRING, MELINERA_EFFECT , data)

Or for color

//command
#define MELINERA_MODE 2
#define MELINERA_COLOR 5
#define MELINERA_EFFECT 6

//Mode
#define MELINERA_MODE_EFFECT 0x02
#define MELINERA_MODE_COLOR 0x01
#define MELINERA_MODE_WHITE 0x00

//Color
QByteArray c1 = QByteArray("\x48,\x49,\x54,\x56", 4); // color 360
QByteArray c2 = QByteArray("\x48,\x51,\x101,\x56", 4); // color 1000
QByteArray c3 = QByteArray("\x48,\x51,\x101,\x56", 4); // color 1000

data = c1 + c2 + c3

SendTuyaRequest( taskRef, taskType , DP_TYPE_ENUM, MELINERA_MODE  , MELINERA_MODE_COLOR )
SendTuyaRequest( taskRef, taskType , DP_TYPE_STRING, MELINERA_COLOR , data)

brightness

//command
#define MELINERA_MODE 2
#define MELINERA_COLOR 5
#define MELINERA_EFFECT 6
#define MELINERA_Brightness 3

//Mode
#define MELINERA_MODE_EFFECT 0x02
#define MELINERA_MODE_COLOR 0x01
#define MELINERA_MODE_WHITE 0x00

//Brightness
QByteArray data = QByteArray("\x00,\x00,\x00,\x88", 4);

SendTuyaRequest( taskRef, taskType , DP_TYPE_ENUM, MELINERA_MODE  , MELINERA_MODE_WHITE )
SendTuyaRequest( taskRef, taskType , DP_TYPE_VALUE, MELINERA_Brightness , data)

[sonar98]

if you tell me how, I can test.

[ebaauw]

OK with help from @Smanar , pointing me to earlier work by @Koenkk, I think I now understand how the X-mas lightstrip works.

The device seems to be "write-only": you can set it's state, but it doesn't report its current state. The app doesn't reflect the actual state, when changing the state manually, using the buttons on the controller. As advertised, the device supports 16 effects, which, depending on the effect, can be modified for speed and up to 6 colours used. The strip can also be set to a single colour for all LEDs. While the LEDs are individually addressable by the controller, this level of control doesn't seem to be exposed over Zigbee (for sure the LIDL Home app isn't using this).

The strip uses Tuya cluster 0xEF00. The gateway sends a 0x00 command to set the lightstrip state; the lightstrip returns a 0x01 command, echoing the state. Basically, the payload of these commands follows a TVL16-like scheme. It consists of a one-byte status (always? 0x00), a one-byte sequence number, and one or more TVL16 encoded "attributes". The "type" consists of one-byte attribute ID (data point in Tuya speak), followed by a one-byte data type. The length is two-byte, big-endian. The encoding of the value obviously depends on the data type.

The lightstrip supports three modes: white, colour, and effect. It seems to keep separate states for each mode. So does the LIDL Home app, but as the lightstrip is "write-only" the states aren't synced when updating the state manually.

The lightstrip supports the following attributes:

attribute	data type	length	description
0x01	0x01 (bool)	1	On/Off Values: 0x00: off, 0x01: on
0x02	0x04 (enum)	1	Mode Values: 0x00: white, 0x01: colour, 0x02: effect
0x03	0x02 (number)	4	Brightness (in 0.1%). Value is a big-endian u32.
0x05	0x03 (string)	4+4+4	Hue (in °), sat (in 0.1%), bri (in 0.1%). Values are ascii-encoded, big-endian hex values.
0x06	0x03 (string)	2+2+n*6	Effect (0x00 - 0x0F), speed (in %, or 0 if n/a), n Colours in RGB (0-255). Values are ascii-encoded, big-endian hex values.

Attribute 0x03 seems applicable only in white mode; 0x05 only in colour mode; and 0x06 only in effect mode. The gateway typically sends attributes 0x01, 0x02, and 0x06 in a single 0x00 command. Note that in colour mode, 16-bit hue/sat values are used, whereas in effect mode, 8-bit RGB values are used. You cannot control brightness while in effect mode.

I haven't yet tried the strip with deCONZ, but I seriously doubt that the Color Control cluster would be usable. I don't think the lightstrip supports the CIE 1931 colour space, so the xy values would be bogus.

Supporting the lightstrip in the REST API will be challenging from a design perspecitive and ugly from an implementation perspective.

• I don't think we currently expose mode for lights. We could use "effect": "none" to switch to colour mode, and {"effect": "name"} to switch to effect mode. I'm not sure how to switch to white mode.
• It's probably easiest to use hue and sat in colour mode, but this will be hell for API clients, who (should) use xy. I suppose we better use xy values, and transform them to RGB hue/sat values. On the other hand, setting sat to 0 would be a natural way for switching to white mode.
• Exposing the effects using effect with new values for the effect names seems doable. We already have colorloopspeed; best rename that to effectspeed (speed is already taken by fans, unfortunately). The effect colours are best modelled as an effectcolors array of RGB values. I suppose few API clients will go to this level of detail (I, for one, wouldn't know how to expose this to HomeKit), so accepting xy values and translating them to RGB seems to have little benefit.

[ebaauw]

Some more observations:

• The LIDL Home app correctly shows the lightstrip as on, after power cycling it. I guess it uses the Device Announcement for this;
• Paired the lightstrip with deCONZ. The On/Off and Level Control clusters seem to be doing the right thing.
  • Both OnOff and Current Level send attribute reports;
  • When setting the level, the lightstrip exits effect mode;
  • On, Off, Toggle, On with Timed Off seem to work just fine;
  • Move to Level (with On/Off) turns the lightstrip on and off, as it should;
  • Step and Step (with On/Off) seem to work fine as well;
  • However, Current Level isn't updated on Move and Move (with On/Off). On Stop, Current Level is set to 100. These are the commands used by the Trådfri on/off switch.
  • Adding the device to a controller group works as expected. Note that the device state isn't updated correctly when the controller uses Move / Stop, see previous point.
• Color Control actually seems almost usable. Move to Hue and Saturation as well as Move to Color seem to work, but the colours are too white, not saturated enough. Seems like the lightstrip is in a sort of combined white/colour mode. Setting level to 1 39 or lower shows better colours (but obviously not bright enough). The lightstrip doesn't support Move to Color Temperature.
  • The device seems to ignore transition time throughout.

There's something weird with the API, maybe another Tuya hack, @Smanar? It doesn't seem to accept updates to bri:

$ ph put -v /lights/13/state '{"bri": 127}'
ph put: warning: api error 6: parameter not available
[
  {
    "error": {
      "address": "/lights/13/state/on",
      "description": "parameter not available",
      "type": 6
    }
  }
]

Updating bri through a group works as expected.

[ebaauw]

There seems to be something in general.xml to construct a 0xEF00 command from Status, TransID, Dp, fn, and data. However, there's no chance in Hell that that'll ever work: the payload isn't ZCL. As I mentioned above, Dp is actually two fields, the data point and data type. I think fn is the high byte of the length; the first byte in data is actually the low byte of length.

[ebaauw]

Looks like I can control the lightstrip through the CLI plugin. It responds with several dozen of 0x01 commands, since deCONZ doesn't send a default response.

$ echo "zclcmd 0xfa81 1 0xEF00 0000000101000101" | nc localhost 5008
<-APS attr 0x677B 1 0x0000 0x0006 0x42 
zclcmd 0xfa81 1 0xEF00 0000000101000101
 --> send OK
<-ZCL serverToClient 0xFA81 1 for cluster 0xEF00 00 00 01 01 00 01 01 
<-ZCL serverToClient 0xFA81 1 for cluster 0xEF00 00 00 01 01 00 01 01 

Note that the last parameter is the Zigbee command followed by the payload:

00 00 00 01 01 0001 01
|  |  |  |  |  |    + Value 0x01: true
|  |  |  |  |  + Length: 1
|  |  |  |  + Data type: 0x01: boolean
|  |  |  + Data point 0x01: on/off
|  |  + Transaction ID: 0x00
|  + Status: 0x00
+ Zigbee command 0x00: set

Similarly, setting the twinkle effect at a speed of 50:

$ echo "zclcmd 0xfa81 1 0xEF00 0000000603000430343332" | nc localhost 5008
zclcmd 0xfa81 1 0xEF00 0000000603000430343332
 --> send OK
<-APS attr 0x677B 1 0x0000 0x0006 0x42 
<-ZCL serverToClient 0xFA81 1 for cluster 0xEF00 00 00 06 03 00 04 30 34 33 32 
<-ZCL serverToClient 0xFA81 1 for cluster 0xEF00 00 00 06 03 00 04 30 34 33 32 

Decoding of the parameter:

00 00 00 06 03 0004 3034 3332
|  |  |  |  |  |    + value: 0x30403332 = ascii "0432" = 0x04 (twinkle), 0x32 (speed: 50)
|  |  |  |  |  + Length: 4
|  |  |  |  + Data type: 0x03: string
|  |  |  + Data point 0x06: effect
|  |  + Transaction ID: 0x00
|  + Status: 0x00
+ Zigbee command 0x00: set

[Smanar]

@ebaauw

There's something weird with the API, maybe another Tuya hack, @Smanar? It doesn't seem to accept updates to bri:

It's not realy because a hack ^^, ATM this device is reconized as switch (cf the other issue), but Tuya switch, so this part need to be skipped by your device

    else if (UseTuyaCluster(taskRef.lightNode->manufacturer()))
    {
        //window covering
        if ((taskRef.lightNode->manufacturer() == QLatin1String("_TYST11_wmcdj3aq")) ||
            (taskRef.lightNode->manufacturer() == QLatin1String("_TZE200_xuzcvlku")) ||
            (taskRef.lightNode->manufacturer() == QLatin1String("_TZE200_wmcdj3aq")) ||
            (taskRef.lightNode->manufacturer() == QLatin1String("_TYST11_xu1rkty3")) )
        {
            return setWindowCoveringState(req, rsp, taskRef, map);
        }
        //switch
        else
        {
            return setTuyaDeviceState(req, rsp, taskRef, map);
        }
    }

Your device use tuya cluster, but is not covering, so the code use the switch part, just need to add

elseif ((taskRef.lightNode->manufacturer() == QLatin1String("YOURMANUFACTURENAME")) 
{
}

And this part will be skipped for this device

Supporting the lightstrip in the REST API will be challenging from a design perspecitive and ugly from an implementation perspective.

I have checked the code, I think using using "effect" and "colorspeed" is a bad idea, because :

• Need lot of modification in code just for 1 device used 1 month by year
• Can provoque problem in the core, thoses field can be used elsewhere.

In my mind was easier to make an hidden command like PUT /api/<apikey>/lights/ID with {"effect":["rainbow",20,12345,6578]} For exemple

Will be harder for integration in third app, but even if we use standard deconz param it will be, so ....

With this way, less code to do, less dangerous for core, and can put all the code in separate file (the tuya one)

It consists of a one-byte status (always? 0x00), a one-byte sequence number, and one or more TVL16 encoded "attributes". The "type" consists of one-byte attribute ID (data point in Tuya speak), followed by a one-byte data type

I think yes, always see 0x00 After the sequence number, always the DP identifier , then always the DP type, then the length .... The identifier depend of the device.

[sonar98]

@Smanar about third party... It would be nice if the device could be used in domoticz.

[Smanar]

Lol, will see, christmas is just in 28 days.

[GH2user]

Maybe the HG06467 protocol is useful to you guys, https://pastebin.com/pcgWVjCp as it describes all options for the Xmas lights.

[Goldwing1973]

Maybe the HG06467 protocol is useful to you guys, https://pastebin.com/pcgWVjCp as it describes all options for the Xmas lights.

Your URL doesn’t work, this link should work. https://pastebin.com/pcgWVjCp

[MichielMag]

I wanna chime in real quick on that pastebin: that was my first look at the protocol a while ago. When I made it I didn't really understand the values. Finally it clicked that the tuya protocol defined datatypes and that one of them (0x03) is string. Which means that 0x30 = '0'. Therefor a scene code is for example (0x3031 = '01'). Same goes for the speed and the HSB string in the color command.

What I'm currently missing (which is also missing from the implementation I did for Z2M) are :

• color temperature (the packaging claims the LED string has support for it)
• RGB 'color' (when you press the physical 'C' button enough times, it changes the string to a classic colored christmas LED string)

I've emailed Lidl support with the question if these things will be added to the app later. But I also have my hoped on you guys to maybe figure it out, so I'm subscribing to this topic :)

[ebaauw]

color temperature (the packaging claims the LED string has support for it)

No proof of that sniffing the LIDL gateway. The LEDs appear to be RGBW, so no physical support for colour temperature either.

RGB 'color' (when you press the physical 'C' button enough times, it changes the string to a classic colored christmas LED string)

As I mention above, the light strip's 0xEF00 cluster is pretty much "write-only". You can set its state, but it doesn't report its current state. The 0x01 command in reply to the 0x00 command simply echoes the 0x00 payload. When setting the state through the On/Off, Level Control, or Color Control clusters, those attributes are updated (except for Move, see above); but those attributes aren't updated when setting the 0xEF00 cluster.

[ebaauw]

Above PR adds REST API support.

{
  "etag": "765141a6915c0c78b8399aea0f3096ee",
  "hascolor": true,
  "lastannounced": null,
  "lastseen": "2020-11-29T22:13Z",
  "manufacturername": "_TZE200_s8gkrkxk",
  "modelid": "TS0601",
  "name": "Color dimmable light 13",
  "state": {
    "bri": 2,
    "colormode": "hs",
    "effect": "twinkle",
    "hue": 0,
    "on": true,
    "reachable": true,
    "sat": 0
  },
  "swversion": null,
  "type": "Color dimmable light",
  "uniqueid": "58:8e:81:ff:fe:d8:83:cc-01"
}

To control the Xmas light strip:

• Set on for on/off. I added support for ontime, but the strip doesn't seem to support it;
• Set hue (0 - 65535), sat (0 - 254), and bri (0 - 254) as HSL values for colour mode;
• Set sat to 0 and bri (0-254) for white mode;
• Set effect and, optionally, effectSpeed and effectColours for effect mode, e.g. {"effect": "flag", "effectSpeed": 10, "effectColours": [[255,0,0],[0,255,0],[0,0,255]]} The effects are: "steady", "snow", "rainbow", "snake", "tinkle", "twinkle", "fireworks", "flag", "waves", "updown", "vintage", "fading", "collide", "strobe", "sparkles", "carnival", "glow";
• Set "effect": "none" to revert to previous mode (white or colour).

[canim60]

Above PR adds REST API support.

{
  "etag": "765141a6915c0c78b8399aea0f3096ee",
  "hascolor": true,
  "lastannounced": null,
  "lastseen": "2020-11-29T22:13Z",
  "manufacturername": "_TZE200_s8gkrkxk",
  "modelid": "TS0601",
  "name": "Color dimmable light 13",
  "state": {
    "bri": 2,
    "colormode": "hs",
    "effect": "tinkle",
    "hue": 0,
    "on": true,
    "reachable": true,
    "sat": 0
  },
  "swversion": null,
  "type": "Color dimmable light",
  "uniqueid": "58:8e:81:ff:fe:d8:83:cc-01"
}

To control the Xmas light strip:

* Set `on` for on/off.  I added support for `ontime`, but the strip doesn't seem to support it;

* Set `hue` (0 - 65535), `sat` (0 - 254), and `bri` (0 - 254) as HSL values for colour mode;

* Set `sat` to 0 and `bri` (0-254)  for white mode;

* Set `effect` and, optionally, `effectSpeed` and `effectColours` for effect mode, e.g.
  `{"effect": "flag", "effectSpeed": 10, "effectColours": [[255,0,0],[0,255,0],[0,0,255]]}`
  The effects are: `"steady"`, `"snow"`, `"rainbow"`, `"snake"`, `"tinkle"`, `"fireworks"`, `"flag"`, `"waves"`, `"updown"`, `"vintage"`, `"fading"`, `"collide"`, `"strobe"`, `"sparkles"`, `"carnival"`, `"glow"`;

* Set `"effect": "none"` to revert to previous mode (white or colour).

Is that now Working? how can i set effects on Deconz? like Snow Rainbow?

[FunkOdyssey2001]

Does anyone have any suggestion on how to mix a warm light just using saturation?

And could it be that scenes aren't working?

[Smanar]

@sonar98 if you can pm me on discord or domoticz forum ( I m Thorgal789) for its integration on domoticz pls.

[snozzlebert]

Is it possible to have a static "flag" or "rainbow" effect?

[ebaauw]

Does anyone have any suggestion on how to mix a warm light just using saturation?

I’d try something yellow-ish colour with a lower sat value. Should be a hue value around 60°, or API value 60 * 65535 / 360, or somewhere around 11000.

And could it be that scenes aren't working?

I assume you mean Zigbee scenes. Haven’t tried these yet, but I doubt they’ll work, except maybe for on/off. I don’t expect much use for Zigbee groups either.

Is it possible to have a static "flag" or "rainbow" effect?

Can you set these from the LIDL app, when the strip is connected to their gateway?

[snozzlebert]

Is it possible to have a static "flag" or "rainbow" effect?

Can you set these from the LIDL app, when the strip is connected to their gateway?

I don't own a Lidl gateway and don't have the Lidl app. I bought the light string yesterday and I'm just curious if someone else knows it. Thanks for building the API integration in deCONZ!

[sonar98]

I'm testing if it is working now but I get aan error.

`{
  "error": {
    "address": "/lights/5/state",
    "description": "invalid value, snake, for parameter, effect",
    "type": 7
  }`

[ebaauw]

Are you sure you're using the right light resource? If so, please list the resource.

[sonar98]

`{
  "etag": "f5f8d2a1f2919d44ddde4b290339d5c8",
  "hascolor": true,
  "lastannounced": "2020-12-01T11:36:47Z",
  "lastseen": "2020-12-01T11:48Z",
  "manufacturername": "Heiman",
  "modelid": "TS0601",
  "name": "Color dimmable light 5",
  "state": {
    "alert": "none",
    "bri": 180,
    "colormode": "hs",
    "effect": "none",
    "hue": 43862,
    "on": true,
    "reachable": true,
    "sat": 100,
    "xy": [0.6994, 0.2959]
  },
  "swversion": null,
  "type": "Color dimmable light",
  "uniqueid": "xxxxxxxxx"
}`

[ebaauw]

The manufacturername incorrectly lists as "Heiman". Consequenlty, the Xmas light strip isn’t recognised nor exposed correctly. Did you delete the resource and re-pair the lightstrip after updating deCONZ?

[sonar98]

yes I readded the device and it is still recognized as Heiman.