If you install an already installed driver from the ST CLI, it will update it immediately.
Updated the drive version, but the malfunction persists in a different way. When you turn it on and off within the device page it shows the correct on and off status. However, when you return to the room page, the status is not updated. When you try to call from the room page, the LED turns on but the status on the APP is off. If you enter the device page and update the page, when you exit it will be updated correctly on the room page.
Gravei tela pra vc poder verificar com mais detalhe… https://youtu.be/MtvckhCTpqE?si=EPKSqdWOIlCI01H1
If you no longer get network errors, it should work fine.
Smartthings has introduced some filters to reduce the number of events that are emitted to the platform and I think this is causing problems between what is displayed in the mosaic and the detail view, I see this daily on other devices, especially with temperature and watts events.
If you leave it, it does not sync on its own after a while?
This is what smartthings answered me about how the events are filtered, I don’t understand it
The team mentioned that the full release of the fix had not been done so you didn’t see a change but that you would expect the following:
- An old device that has not interacted with often, whose capabilities have been updated, should now accept events within maybe 2-3 seconds
- An old device that is interacted with often, whose capabilities have been updated, should still require up to a few minutes before new events are accepted
- A new device should immediately accept new events
Only if you send me logs with the CLI of when you press on and off in the app, I could analyze what the device and the driver sends
@Mariano_Colmenarejo I might not remember correctly, since you added Gledopto controller to your driver long time ago, but there are controllers that are zigbee 3.0 and same are ZLL. PRO models are Zigbee 3.0 and work bidirectional instantly. Other controllers, PLUS and regular, work instantly Smartthings to Gledopto, but have delay when work opposite Gledopto to Smartthings, or some will not update status until you do refresh.
I have one PLUS that is very slow with updating status, but rest of the controllers are PRO and they work perfect.
2 Likes
With circadian deactivated it works perfectly, when I click on on the mosaic the LED lights up and it appears on in the APP, both on the mosaic and in the device details. When I turn on the circadian function, then when I click on on the mosaic the Led turns on but the mosaic remains off, after more than 5 minutes it switches to on. (if I go into the device details and refresh the page, it appears as on both in the details and in the mosaic).
@Mariano_Colmenarejo, I’ve tested your Zigbee Light Multifunction Mc and the
ATTEMPT Restore State if Power Lost does work with a unit but doesn’t with others which seem to be Zigbee 3, can we dig into this further?
This attribute is optional and some zigbee 3.0 devices support it and others does not.
If you know what cluster, attribute and values your devices use for that function, then you can share it and I will try to add it to the driver.
1 Like
In the version I posted I added a device:refresh() with a 2 sec delay in the On function with circadian function, just like it does when the circadian function is not activated. So it should work fine.
-- added to ZLL devices get turn on state
device.thread:call_with_delay(2, function(d)
device:refresh()
end)
This is what is done in the stock smartthings drivers with ZLL devices like yours
@higorchv Updated:
I’ve checked the code again and I’ve seen that I was missing refreshing the ZLL device outside the circadian time when it is activated, so it could fail if you were outside the circadian time when you tested it.
Thanks for reporting this
Fixed in this version of the driver
───────────────────────────────────────────────────
Name Zigbee Light Multifunction Mc
Version 2024-06-03T15:38:46.802666523
───────────────────────────────────────────────────
2 Likes
@Mariano_Colmenarejo, It looks it’s the FC0F cluster to which a 0x01 command has to be issued accoriding to this thread.
This bulb is not saving the state:
Manufacturer: LEDVANCE
Model: B40 TW Z3
FingerPrinted_EndPoint.Id: 0x01
App Version: 0x01
ZCL Version: 0x02
Network ID: 0x6AE3
Zigbee EUI: F0D1B80000139A09
Device ID: b80d582e-df72-4ebf-bb04-308295982b2a
Server Cluster:
Ep: 0x01={ 0000,0003,0004,0005,0006,0008,0300,
0B05,1000,FC0F }
Client Clusters:
Ep: 0x01={ 0019 }
Signal Metrics:
LQI: 128 .... RSSI: -82 dbm
However, this one is saving the state properly:
Manufacturer: OSRAM
Model: Classic B40 TW - LIGHTIFY
FingerPrinted_EndPoint.Id: 0x03
App Version: 0x10
ZCL Version: 0x01
Network ID: 0x0990
Zigbee EUI: 7CB03EAA00AAE588
Device ID: 7c48dba7-a7cf-438b-ae5e-c97523b50cf9
Server Cluster:
Ep: 0x03={ 1000,0000,0003,0004,0005,0006,0008,
0300,FC0F }
Client Clusters:
Ep: 0x03={ 0019 }
Signal Metrics:
LQI: 132 .... RSSI: -53 dbm
Any ideas what’s going on?
After updating the drive, I did the tests and it is working perfectly with the circadian function activated… I don’t know if it’s just me, but the LED activation seems to be even faster… Thank you very much for the excellent work
2 Likes
Either I’m not understanding the issue or I think you’re mixing up two different functions.
The preference that is in my driver is to TRY TO ESTABLISH what the device should do after the power is restored:
- Maintain previous state before power outage (value 255)
- Set state Off (value 0)
- Set state On (value 1)
This is done in my driver sending values to cluster 0006, attribute 4003 for standard zigbee devices
For Tuya devices it sends to cluster 0006, attribute 8002 the same values except that it sends value 2 instead of value 255.
What you refer of command 0x01 for Osram devices (cluster FC0F) and Ledvance (cluster FC01) is to save the level, colorTemperature and color values as defaults for the following device power-ups.
In this function my driver does not do or send anything, because it is not implemented.
In any case, zigbee 3.0 bulbs, as you said in your previous post, setting some values of level, color temperature and color and keeping them for 30 seconds, are automatically saved in device for the next power On.
My tuya zigbee 3.0 bulbs do it perfectly, but an Osram Classic ZLL does not do it and it did not work sending the 0x01 command to the FC0F cluster when I tested it and therefore I did not implement this function in my driver.
So it is possible that one of your bulbs is zigbee 3.0 and the other ZLL.
I cannot provide more data, because I do not know more, if you still have doubts you can contact LEDVANCE or OSRAM
2 Likes
Yes, that’s what I’m referring to.
For some reason the Ledvance bulbs (which seem to be zigbee 3.0 ) don’t honor the setting and always start with maximum brightness and 2700K if power is cut. I’ve seen these bulbs aren’t in the fingerprint file, although I can assign them your driver, does this have any consequences on the behavior?
If the device is paired with the correct profile using the generic clusters, then there is no problem.
@Mariano_Colmenarejo, I correct myself, the status is not being saved neither in the ZZL nor in the Zigbee 3.0 ledvance/osram bulbs so the only thing to test would be to send the 0x01 command to the custom cluster and see what happens.
@Mariano_Colmenarejo , I’ve noticed that with a rule which is set to turn on the bulb progressively it turns on immediately at 100% brightness, is this the expect behaviour if you set the rule this way?
1 Like
The progressive “on” must be active when the on command arrives to driver.
You need two routines, one to activate progressive function and other to On commad.
Or set the progressive function by default in this device
Alright! Thank you.
@Mariano_Colmenarejo, Something’s gone wrong with the RGB bulbs suddenly. The circadian and the turning off and on was working perfectly till today. I have all the other settings disabled including the circadian mode. I turned on the color mode for half hour by setting the color changing mode to active but now,
- The bulb is not turning off at all and when I try to hit the turn off button in the app, it gave me a network error. Then, it switched off automatically and I am now able to just turn it on or off and set colour mode but not the full brightness of warm and cool whites as mentioned in the next point
- The bulb does not produce full brightness of cool and warm whites, instead they are displaying a dull white light
- Cannot specify the colour temp in the app as I cannot find any setting
I have not done any settings change for the last one month. Can you let me know what happened please?
I have no idea what could happen, the driver has not been modified for more than a month.
My bulbs work fine.
I am still using the previous version, 1.8.14.26 of Android
