AduroSmart Eria #939
Comments
|
With some logging in |
|
I'm able to pair with the lamps if they are really close to the controller - did not realize that was an issue as I never encountered that with ZWave. The lamp shows up as I put in a Home Assistant mapping, and the light shows up as 'off', as no messages about its status are received or sent. Trying to turn the light 'on' (while it in reality already is on): I will keep messing with this, but any help is appreciated. |
|
Could you post the |
|
The light, that seems to do very little: The switch, that crashes |
|
Lets start with the light.
{
zigbeeModel: ['ZLL-ExtendedColo'],
model: 'TODO',
vendor: 'AduroSmart Eria',
description: 'TODO',
extend: generic.light_onoff_brightness_colortemp_colorxy,
ep: (device) => {
return {
'': 2,
};
},
}, |
|
https://adurosmart.com/products/adurosmart-eria-smart-bulb-a19-white-and-color-dimmable-cri-90-60w-equivalent-hub-required Although not fully sure, the descriptions above suggest, dimmable, color and color temperature. |
|
When instead of the |
|
Great, could you make a PR? Then we can continue with the next device. |
|
I'm happy to. There are some (minor) issues - we can discuss those on the PR. |
|
One issue that I think is not related to the code, so discussing here: I have three of these bulbs and they are very close together. Looking at the network map, one is connected to the controller, the two others are connected to the first one acting as a router. One of the lamps (consistently the same one) that is connected through the router sometimes gets in a state where it doesn't seem to accept commands. The log shows This happened a few times, and I seemed to be able to get it working again by turning the physical power off and on to the lamp, and restarting zigbee2mqtt. Or so I thought... it seems to be the exact physical position of the lamp. Switching out one lamp with another, the lamp in the same position now becomes non-responsive. If I move the lamp literally an inch up or down, it works. In that exact same spot, it doesn't. It shows online in the network map, has good link quality, connects through a router (other lamp) that's very close, but doesn't accept commands. Hold it an inch higher - all good. Have you ever seen something like this before? Happy to move this to a new issue if you prefer, because while troubleshooting and typing I realize it has little to do with the original issue. EDIT: I don't think this has anything to do with this specific lamp. The three lamps are in a fixture like this (https://www.target.com/p/avenal-shaded-arc-floor-lamp-project-62-153/-/A-52937505) and I can rotate the base a few inches and one of the lamps doesn't respond; rotate it in the other direction and a different light doesn't respond. They all show online in the network map. The link quality of the router-lamp is on the low end (15-ish) - but that's not the lamp that has issues (sometimes it has and the other ones don't). I think there's more to "parent" than I know and the controller might still try to talk directly to the lamps? Anyway, I've ordered parts to make a sniffer with RF and antenna, that will likely fix it. Apologies for this long-winding non-report :0. |
|
Can you update to the latest dev branch? This has a more complete network map. |
|
Looks like they're all connected to each other as routers with good link quality, but also to the controller with close to zero link quality. Assuming depending on the exact location some messages don't get through, and aren't routed through the routers as there also is a direct connection. Is there anything that can be done about that (e.g., retry through a router)? Not that big of an issue - as said, I'm already in the process of getting an RF+antenna setup and this is only relevant if you're at the edge of the network range I suppose... Working on PR against latest dev branch - only issue I see is that the devices don't seem to update status after setting it - i.e., the |
|
The state isn't updated because the commands don't succeed, hopefully this will be fixed by your new RF coordinator. |
|
I think these lamps just don't send updates when their state is changed. Even with the lamps positioned close to the controller and the commands obviously succeeding, state only shows on or off and nothing else. When issueing an explicit get for brightness/color, the lamp responds and the state gets updated. |
|
Can you try with // AduroSmart
{
zigbeeModel: ['ZLL-ExtendedColo'],
model: '81809',
vendor: 'AduroSmart',
description: 'ERIA colors and white shades smart light bulb A19',
extend: generic.light_onoff_brightness_colortemp_colorxy,
configure: (ieeeAddr, shepherd, coordinator, callback) => {
const device = shepherd.find(ieeeAddr, 2);
const cfg = {direction: 0, attrId: 0, dataType: 16, minRepIntval: 0, maxRepIntval: 1000, repChange: 0};
const actions = [
(cb) => device.bind('genOnOff', coordinator, cb),
(cb) => device.foundation('genOnOff', 'configReport', [cfg], foundationCfg, cb),
];
execute(device, actions, callback);
},
ep: (device) => {
return {
'': 2,
};
},
}, |
|
Doesn't seem to fix anything. The only time the state actually seems to get updated (besides on/off, which always worked) is when explicitly publishing to the When I turn the light on, this is in the log: Changing color or brightness looks similar, with only on/off state reported, no brightness. The configuration does seem to be accepted: I've also tried with a When manually retrieving state, this is the log: Interesting enough, this state is remembered by zigbee2mqtt, any command after this will now report the same brightness back that we got from this explicit get command. |
|
The brightness and color is never reported back, as Home Assistant doesn't need a confirmation, this is not needed (the slider will stay at the position where you moved it to). |
So for this specific light, I see three solutions: My preference would be option b) above, as it actually gives the most accurate information and mimics what the light normally should be doing anyway. Let me know what you think and I'll make a PR for your preferred solution. Then we can move on to the switch :). |
|
I think I misunderstood you. The Can you confirm when the zigbee command succeeds, the state is correctly updated? |
|
Thanks for your help getting the lights working perfectly! I'm having some slightly different models on the way, so more will be supported soon! Next, on to the remote. Could you give some pointers as to how to solve the unknown cluster error, or maybe just ignore it? |
|
Add a After that you have to define the cluster and it's commands like I did in: Koenkk/zcl-id@4db172c and Koenkk/zcl-packet@e233d22 |
|
I think we can close this issue - both the lights and the switch are supported now in the dev branch. Thanks for all your help! |
Hi!
I'm in the process of adding support for AduroSmart Eria devices. I have a wireless switch and some lamps. At the moment I'm running into two issues, that might be related.
Zigbee2mqtt is running in a Docker container with the image
koenkk/zigbee2mqtt:1.0.1-arm32v6.First, the switch. I managed to pair it, and add some lines in
devices.js. Now, when zigbee2mqtt starts, at least I see:0x00158d000198d02e (0x00158d000198d02e): 81825 - AduroSmart Eria wireless dimming switch (EndDevice)However, any button press results in:
As per #852 (comment) I've added the
console.logline inaf.js, but no more logging appears.The second issue is that I cannot pair the lamps at all. When I put one in pairing mode (and the lamp confirms so by flashing as per the user manual), nothing happens on the zigbee2mqtt side. Not sure what to do next here.
Any help is appreciated. These devices seem a good cheap alternative to Philips Hue lamps - and more importantly (to me) they claim a CRI of 90, so the white light should be of better quality.
The text was updated successfully, but these errors were encountered: