I have 3 identical Aurora Zigbee dimmers (AU-A1ZBR1GW), but I can only see logged events for 1 of them. The other 2 remain silent whenever pressed/rotated.
Some additional information:
the dimmers are not officially compatible with SmartThings Hub (they require the Aurora AOne Hub), but I managed to modify the default Device Handler for a “Zigbee Dimmer” and the 1 dimmer that actually sends events now works perfectly fine;
the fact that it is 2 dimmers that are not working makes me think it is unlikely that they are both malfunctioning.
the other 2 dimmers also pair ok (they appear as “Things” but I can change the Device Handler to my bespoke Device Handler through the Groovy IDE);
once paired, the 2 dimmers output a couple of events (one with cluster id of 1 and the other with cluster ID of 32801) and then go silent;
I suspect they have a different firmware from the one working, but I don’t know how to verify that given tha the Groovy IDE page for these devices there is no firmware version.
How would you go about debugging this? Is there a way to see logged events at a lower level than printing out everything that is sent to the “parse()” function?
Since it is two out of three, my guess would be that rather than malfunctioning, the devices are probably using a zigbee feature which the smartthings hub does not expose. Maybe groups. Which could explain why the first one would work and any subsequent ones would not.
But, as you note, it could also be a firmware issue or something else about them. I’m sorry I don’t know any more specifics.
I’ve put the model number into the topic title just in case that gets the attention of someone who does know more.
Looks like people in the MQTT community have found the hardwired Aurora dimmer to be decent, but this specific device (the battery powered button) to be very challenging to integrate because it has quite an unusual reporting pattern. It will first send a button press but then it will send a whole bunch of reporting notifications, so if your hub doesn’t know what to do with those, it becomes unreliable. See the following conversation. My guess is that that’s why it’s not in the official integration. It also means that you won’t be able to substitute other DTHS for it, it’s going to require custom code because it’s a non-standard messaging pattern.
Thanks @JDRoberts ! Answers to your points:
(1) indeed battery powered, so “remote” not “dimmer switches”.
(2) It does not matter in which order I pair them to the hub–it is always one of them that works and the other 2 don’t, so an issue related to groups seems unlikely.
(3) Yes, I also came across the MQTT on that matter. I did manage to create a Device Handler that just ignores those spurious reporting notifications. It wasn’t too complicated as they have a specific pattern.
Thanks also for tagging @AndyPrice-Aurora . Looking forward to hearing from you and/or Andy or anyone else!
If it is either the first one paired that always works or the same physical device that always works it could still be Zigbee groups, but for different reasons, or it could be something completely different.
In the meantime I have made some progress. First of all–am I correct in assuming that the logger may not show any events if the device handler is not behaving correctly?
Essentially, by re-pairing the devices and then switching the Device Handler in a specific sequence (“Zigbee Accessory Dimmer”, and then “Zigbee Battery Accessory Dimmer” and then “Zigbee Button” and finally to “Zigbee Dimmer”) for some reason the device comes to life. Then I can switch to my own Device Handler and voila’ it is all working. The sequence of change did not always work like that, so my changing of the device handler in that sequence may have had nothing to do with it.
As a good engineer, I am not entirely happy now–why does it work? What if this happens again?
Also, I have a fourth dimmer (yes, I know…) with 2 gangs, but I don’t get any messages related to the second rotary dimmer. Is it possible this problem as well as the previous one has to do with setting up incorrect metadata in the device handler? Is it possible that if that is incorrect, then the “parse” object is not being called upon receipt of certain events from the device?
I do not understand completely what exactly you are trying to do.
A sad story is that the ST platform does not support dimmers, esp rotary dimmers. There is even no good UI representation for this type of devices.
As far as I know, the best thing you can do is to connect the dimmers to the Zigbee network and bind them directly to the light groups.
Depends what you mean by ‘the logger’. If you mean the live Logs page in the IDE then I think you will only see any activity when the DTH in running in the cloud. If it is capable of running locally in the hub you won’t get any logging when it does. So if you don’t see anything it could be broken or it could be working perfectly.
With regard to the 2G dimmer, what handler are you using for that? I don’t think the Zigbee Dimmer has a scooby about the second gang.
Thank you! That makes sense. I can see in the “My Device” page on the IDE, that the Dimmers Execution Location is “Cloud”. Does that mean the the Live Logging page in the IDE would report all events? If not, is there a way I could access the local (hub) events?
I created a modified version of the standard Zigbee device handler. Given that the proprietary Aurora hub must be able to differentiate between the two gangs somehow, then it stands to reason that one could tell them apart from their message format. That is only possible though if those events were actually getting through…
So will there be an edge driver to make this device work?
I have a load of hardwired Rotary Zigbee dimmers that work brilliantly with SmartThings without the need for custom code.
I was hoping to get one of these and pair is as a remote to “mirror” behaviour of the hard wired ones from places that I have no possibility of getting wiring to.
Is there such a way I can use the Aurora battery dimmer? Their other products work ok-ish. They are officially supported by SmartThings but can be glitchy. Im not sure why they didnt include this battery dimmer on the list of supported products? Is it to do with ST?
As mentioned above, is it possible to pair as a remote?
The old rotary battery ikea dimmers worked brilliantly so why cant these?