-
Notifications
You must be signed in to change notification settings - Fork 506
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
Lidl Melinera Smart LED string lights #3716
Comments
What is missing on this one? |
Choosing a color is not working correctly. Colors do not match the choosen color. |
@Smanar Can you include this 😃? |
I m searching the product to have information, but a part a video on youtube, and not sure was the same. For button, if you enable log, you will be probably able to see log starting with When using them |
How can I enable log? Is that possible on a RPI or windows computer? |
@sonar98 From deconz gui click "Help" and click "debug view" |
I tried but I don't see any line starting with: "Tuya debug X |
Even if you enable all ? |
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 ? |
When I switch it on I see: But when pushing the buttons nothing happens |
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. 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 ? |
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 |
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) |
There are two physical buttons.
|
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 ? |
An online manual is also available for this device. And this seems to be the Zigbee Alliance certification. |
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 ... |
Is this usefull? |
Yep, but I prefer avoid to make a so hudge code for a device used only 1 month by year ^^ Do you have the json generated for this device ? Do you need some return from it, or just be able to ask for effect ? |
|
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. |
Tomorrow I will receive the gateway. |
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. |
@ebaauw, the protocole is already sniffed and decrypted (look at z2m project) it use classic tuya command, can use the tuya code without problem.
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. |
I have not the device, so nothing is tested, just deductions. The command to use are for exemple for effect
Or for color
brightness
|
if you tell me how, I can test. |
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 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 Supporting the lightstrip in the REST API will be challenging from a design perspecitive and ugly from an implementation perspective.
|
I use it as a OpenHAB integration |
Can you reach it through the LIDL app? As far as I can tell, the Steady scene only takes a single colour. The strip does not report its actual state, so our only change would be catching the LIDL app and gateway in the act of setting this mode. The LIDL gateway does some magic when pairing the device (writing some manufacturer-specific attributes, sending some Tuya commands with a very small payload). The LED strip responds with some Tuya commands as well. However this doesn't seem to influence the working of the strip. I tried sending all Tuya commands from 0x00 to 0x1F (using the CLI plugin), to see if one of them could lure the strip into reporting its state, but no joy.
No, I only use HomeKit. I don't even use Phoscon.
The circuit board would likely contain a Zigbee chip and a microcontroller (or a single chip combining both functions). The microcontroller generates the serial signal to the LEDs, controlling each LED individually. However, it only accepts a fixed number of effects over Zigbee, so we cannot control each LED individually over Zigbee. The serial signal is write-only by nature. The microcontroller is write-only by (poor) design, maybe limited by the resources on the board. So there's no way to get the current state of the microcontroller. |
Actually, I don't have a LIDL gateway, just operate it via deconz, so I can't crosscheck. Anyway, thank you very much for having this checked from you side. |
Someone can tell me if RGB color are working fine using phoscon ? |
First of all thanks to @ebaauw and everybody participating here to add support for the new 'xmas' device! There ist one issue with the device identification: according to the initial data the manufacturername currently has to be "_TZE200_s8gkrkxk". I have seen this name only once, when i included the device for the FIRST time, on my Hue bridge (luckily I did not yet delete the device data). I can confirm the modelid is "TS0601". But I have no knowledge if modelid TS0601 alone would be sufficient to identify the device (and whether using the effect routine on other devices could harm them). After building the code locally with an additional OR condition with Heiman and TS0601 within isXmasLightStrip, i can use the effects via API. (Before that I had already updated Conbee II firmware to version 26680700, no idea if that was also a requirement for it to work.) Maybe @ebaauw could add a fix to his code. [UPDATE: not required] Thanks again for all the efforts - if I can aid with some tests, I'd be glad to participate, as I am used to squeeze all out of the (Hue) API - deconz is still very knew to me. And because I haven't written any C code for the last 5 years, that would not yet be a point to contribute. @Smanar: "sat" basically works, but the colors (I just tested red) were only saturated when "bri" was between 16 and 39. Increasing "bri" from 39 to 40 then lead to a green tone with very low brightness. The color changes do really behave a bit odd. With best regards, |
"Heiman" again ? Because of the tuya code where I m looking in the database ? but it need to be writted inside before ... And we realy need to use manufacture name, because you can have different device with the same model id "TS0601" Have you tried to :
|
Not a clue where that comes from. Could you attach Homebridge Hue’s debug dump file?
That’s courtesy of Homebridge Hue.
No, other devices use that model id as well. We need the manufacturer name (which obviously isn’t) to identify the device.
Then you’re not running my code, or the device isn’t recognised so my code doesn’t kick in. Be sure to re-pair the light strip after upgrading to v2.7.0. |
Hello again, and thank you for your quick and helpful replies. |
After upgrading to v2.7.0 and re-pairing the device i still have the situation described above. I deleted the fairy lights via Phoscon and added new. Do I have to delete directly via the deconz GUI? |
What does the Deleting it from Phoscon and re-pairing should be enough, I think, but maybe you need to delete the record physically from the database. |
The
Can you give me a little instruction please what i should do next? :) |
The |
I think I remember that the device was called Color dimmable light 25 at the beginning and after deleting and adding it was also called Color dimmable light 25. Maybe I have to try again? |
I'm sorry your guess is as good as mine. Your list above shows id 26 instead of 25, suggesting its a newly created resource, rather than a restored one. |
That's the right version, afaik. |
Try reading the manufacturer name from basic cluster in deconz GUI. That should update the name in the DB as well as in Phoscon. |
The Thermostate-thing is also something that occurred (or better is still present) in phoscon. After adding the device to an group I can control it via phoscon. Maybe that's also the reason why homebridge is kinda Buggy for me. Will dump homebridge tomorrow. BTW: first updated to 2.07. before added those lights the first time.
|
That worked for me! Thanks everybody for your help :) |
@Somberland The model identifier is also exposed by some thermostats, so that's the reason why. |
BTW I m interested by the log when including the device, if someone still have "heiman" as manufacture name. |
Für die einzelnen Effekte können auch mehrere Farben definiert bzw. übermittelt werden: https://github.com/Koenkk/zigbee2mqtt.io/blob/master/docs/devices/HG06467.md |
Hi there, As this topic is slowly turning into a generic help topic, i am closing this off. Phoscon needs to add support by itself, please open a issue in their repository. @ebaauw told me he wanted to have another PR in regards to this issue. He will keep this issue updated with the latest developments. If anyone has a issue with this device, feel free to open a user question issue or stop by in our discord server! Thanks for anyone involved 👍 ! |
The PR is already there, #3716 (comment). I just want it to be merged in the next (beta) release. |
Latest PR doesn't work out as I'd hoped. Setting the brightness when in colour mode might change the colour, see ebaauw/homebridge-hue#860. Need to revert supporting |
Device
Screenshots
The text was updated successfully, but these errors were encountered: