I too ordered a couple of the single switch version… I’ll be back in 2 weeks (or however long it takes for them to ship it) to report!
edit They’re on their way… lol!
I too ordered a couple of the single switch version… I’ll be back in 2 weeks (or however long it takes for them to ship it) to report!
edit They’re on their way… lol!
Who could we contact to have them unblock it? Maybe @Tyler? or @JDRoberts?
@tyler no longer works for SmartThings and I never did, so someone else would have to look into it. Maybe @jody.albritton would know.
@danielccm @JDRoberts Do you mean two buttons or some kind of double tap functionality? And what do you mean blocked by SmartThings. I need the context to try and figure this out.
Basically there’s these 2 versions of the wireless light switch… one with just a single button… one with a double button… But @enchoss seems to have been able only to use the one-button fully… while the 2-button one acts as a single button…
The fun part would be to have the double switch control 2 different sets of lights or scenes or virtual switches… wirelessly… via zigbee…
edit: I’ve not even considered the wired versions… but I guess the procedure will be the same for those?
Just as a refresher… these are the 2 kinds of switches…
Wired: https://www.gearbest.com/alarm-systems/pp_610096.html
Wireless 2-key: https://www.gearbest.com/alarm-systems/pp_610095.html
Wireless 1-key: https://www.gearbest.com/access-control/pp_626696.html
@tyler no longer works for SmartThings
ouch! That’s some news I didn’t expect!
Basically there’s these 2 versions of the wireless light switch… one with just a single button… one with a double button… But @enchoss seems to have been able only to use the one-button fully… while the 2-button one acts as a single button…
The fun part would be to have the double switch control 2 different sets of lights or scenes or virtual switches… wirelessly… via zwave…
The Aqara line are zigbee switches, not zwave, although the end result should be the same. However, there of been a lot of issues with the Xiaomi switches in the past, although the Aqara line is supposed to be certified to the same profile that smartthings uses, ZHA, they seem to be somewhat idiosyncratic.
idiosyncratic?
idiosyncratic?
Peculiar.
I was just searching for the term… lol! Thanks!
As an engineering term, it means “doesn’t follow the standard exactly.“ Has its own way of doing things.
And what do you mean blocked by SmartThings.
This thread speaks about it, ind i’m sure i have read it some where else too, with way more technical details - just can’t find the thread… Still searching…
There is a great deal for the Xiaomi wall switch: But it looks no one has yet a working DH
I received one last week. But when I tried to adapt a DH to this version. When you press one of the two button you receive always: “on/off: 1” from both, so you cannot differentiate left or right button from the info received. Other issue you don’t receive info when button is released, So you cannot have a button held position.
Because Aqara did it in a way, which I think is reasonable, by sending different key presses via differient endpoints. Basically smartthings backend decided to filter the endpoint information for on/off command in early years. Now that smartthings believe it would break a lot of outdated DTHs to include those information, which a lot of people believe there are plenty of ways to avoid that. In the meantime the dev team believe that is rather low priority to make this happen due to low demand from customers, which I highly doubt that. I don’t really think this will get supported in the very near future.
So basically, the safest bet as of February/March 2018 is to purchase/install the single button Aqara switches, both in the wired and wireless versions…?
“Blocked by SmartThings” means “Blocked by the lack of Zigbee endpoint support in SmartThings”.
If we got a way to get the unparsed message from the device, we would do it ourselves in the DH as a workaround, but the platform is converting the message from the devices and stripping the endpoint in the description sent to parse().
It could be solved by just adding a new signature for parse() that would accept the unparsed message in a second optional parameter. This would be enough, without breaking any backwards compatibility in the existing device handlers, while ST takes their time to find a better / permanent approach.
But this request has been silently ignored for months (I would now say years) from ST, which makes me think Zigbee support is not really in the strategic roadmap for ST. Otherwise, this basic functionality of Zigbee would have been supported somehow a while ago.
I just thought of a possible workaround… Could we use Domoticz?
Zigbee support is not really in the strategic roadmap for ST.
Zigbee is definitely part of our road map. We are working on number of things including reliability improvements and Zigbee 3.0 support. Providing the complete message isn’t trivial in all cases because the hub strips out that information at a low level. Some of this will be addressed in future hub updates while other parts will be addressed in our new API and capabilities model.
I created a github repo with the code from @enchoss with his permission… Please use it, update it, make it the best it can be… I’m no programmer… I’ll only be the guy who created the repository… lol!
Contribute to XiaomiAqaraLightSwitch development by creating an account on GitHub.
(oh and if you can tell me why it’s NOT appearing in my github integration here… I’ll appreciate it…)
Thanks!
the naem of the file must be something like this:
xiami-aqara-light-switch-wireless
https://github.com/danielccm/XiaomiAqaraLightSwitch/blob/master/xiamiaqaralightswitchwireless.git
.groovy
I’ll be back in 2 weeks
Damn… Took WAY longer than expected… but HEY! The switches arrived this morning (it’s already past midnight in Spain) and only a few minutes ago did I get to install one of them… I’m leaving the 2nd one for some other use some time in the near future…
For starters… BE PATIENT… They will work… BUT! You must add it via the add device IN THE DEV TOOLS (graph.api.smarthings…)
I’ve got the guide from somewhere here in the forums but just to summarise:
Put the ST app in pairing mode… yeah, even though I said you have to do it in the dev tools… this first step is kinda crucial.
in the Dev tools… go to the hub’s own logs… not the live log… in the hub… (My hubs - List Events)
Click the switch and look for a “catchall” line in the log… (might have to refresh)
Jot down the 7th group of numbers and letters… you’ll need it.
I’ll assume at this point you’ve already added the DH that’s in this thread somewhere (I have it in a Github)… Go to the devices area and add a new device… network address will be the 4 letters/numbers you jotted down before…
Enjoy!
Took me a good half hour or more (but less than an hour) to figure it all out… Worth every second!