Driver Issues: Ikea Zigbee Sound Controller

🛎️ Get Help
1

I'm experiencing some difficulties with the new driver for the Ikea Zigbee Sound Controller.

First, whenever I try to use the setLevel command, I get the following error:

image
image.png746×53 4.42 KB

When I try to use "on", I get this error:

image
image.png759×94 6.37 KB

And when I try to use "off" i get this error:

image
image.png727×63 5.82 KB

These 3 errors make this driver pretty much useless if you want to use it with an app like Switch Bindings. And you can only use it with MirrorMe if the only thing you're ever going to use to control the device is this remote, since you can't change it's switch or level from anywhere else. (note: all of these commands were direct from the edit device page)

Also, I am seeing that when you press button 1 on the edit device page, that does not toggle the switch like you would get if your pushed the button physically. Pushing it physically gives you this:

image

While pushing it on the edit device page gives you this:

image

Next, I found that occasionally the device will go into a "run-away" state where even after the released has been captured, the device will continue to change. I was able to capture logs for one.

image

You can see the release but the device continues to change. These were the settings at the time.

image
image.png1299×131 3.95 KB

I am seeing the same problem in a driver I adapted from the ST DTH. I am using runInMillis and a state variable to make the level changes and then stop when the dial stops turning by setting the state variable to false. At the top of the function, I check that the value of the state variable is true but it seems that isn't being capture accurately or not checked accurately at the top of each execution of the level changing function. I was expecting that I might get one extra level change for everything to catch up with itself but it seems that something else is not being capture completely within the driver's execution. I'm even changing the state variable to false in two places to help catch the change but it still misses occasionally.

And lastly, I do not see any implementation of the triple tap of the primary button. I know no one around here is fond of the triple-press capability but what about using button 4 pushed instead? Currently, triple taps show up as a double tap. But triple tap is a separate report from the device.

2

I have troubles here too. Turning the controller sometimes does raise level and sometimes doesnt....also sometimes with a lag.

The things is that I was having these issues with the ikea hub as well which is why I couldnt make use of the controller. I was hoping hubitat had found a better way of implementing the controller.

3

Well, I would be more worried if it wasn't actually receiving the message that you've stopped rotating it. But it obviously is by the logs. I will say, after pairing it to the hub, i had to factory reset the controller and then re-discover it in Hubitat to get it to work correctly. It seems that everything to configure the controller is not received the first time it is paired.

4

@mike.maxwell I hear rumors of a hotfix release. Any chance of getting issues 1-3 (the big ones) into that? The devices is pretty much useless without those being fixed. Thanks.

5

i'm confused, when you say you're trying to use the setLevel command, meaning what, trying to use the command from the driver?

setLevel, on and off aren't implemented in the driver, which is an omission, however typically for controllers that generate switch and level commands, the on off and setLevel methods do not send any events, as many of these controllers maintain their own internal states for these attributes, and they cannot be changed from the driver, only the physical device.

Again with button controllers, the device commands aren't being nor intended as a proxy for the physical device actions for the reasons noted above.

As far as runaway is concerned, you can try changing the rate of change, that may help.

Triple tap isn't supported in our schema currently, and we aren't going to fake map it into another button id.

6

Yes...but if we are using the internal level to sync with another device, say a light, we have to be able to set the level of remote the same way that we would with any other virtual device. Otherwise they will get out of sync.

Same with on and off. If i set up Mirror to sync this with a light, if I want to turn the light off from Hubitat, the controller is what I'm supposed to issue the command to, correct? So, wouldn't the controller have to respond to On and Off commands too?

Have you not implemented a setLevel for the RGBGenie remote drivers?

Then why do you have the switch and switchLevel capabilities in the device if it's only intended to be a button controller?

7

Not to hijack this thread, but are there any plans to change that? I know you (and human memory) have to draw the line somewhere, but Inovelli and HomeSeer switches both support up to a quintuple-tap, and I think most Zooz (maybe GE?) support triple. Five seems like it would cover all of the current scene switches and eliminate the "fake map" you're talking about...which also makes me wonder what the Inovelli drivers mentioned as targeted for 2.1.8 might implement (if it maxes out at double taps, you'll lose out on more than half of the features of the switch). But then that's a lot of capabilities (perhaps the only time ST's single "Button" capability might look more appealing...ha).

8

Our drivers mimic the way that these controllers work when touchlinked directly to another device, in those cases, there is no updating the controller with the state of its members.
Neither the controller nor the endpoint device is aware of the other's state.

And as I said, many controllers maintain their own internal states for on/off and level, there is no way to read these from the device, so we can't allow the driver to make changes to the states that the controller has sent.

That would be nice, but these are outClusters, not inClusters, so the internal device states cannot be changed via command.
This isn't an HE specific issue, every button device I've worked with operates this way, they send commands, they do not respond to commands...

Yes, the commands are there, however they only log the fact that they aren't implemented.

Well, without that how would an app subscribe to, much less find the device?, it's also required for the relevant attributes.

9

Maybe I'm not making myself clear Mike. If you only use this as a button controller you cannot use it for devices that have not implemented the the startChanging and stopChanging command implemented. Take the Chromecast Beta implementation for example. You could not use this controller with this driver to change the level of a Google Mini with its default driver. Because the mini doesn't have startChanging and stopChanging. I don't really care about the level or switch state that the device thinks it has, only what Hubitat thinks. So, if you wanted to use an app like MirrorMe to sync the level of a google home mini with this device, you could. But that would mean you could not modify the level from anywhere other than on the remote, because it doesn't accept those commands. Do you see what I am saying now?

I have a driver I ported over myself from ST that does it this way and it works perfectly. I am able to use mirror me to match it to a light that doesn't support change level. But then control the remote from hubitat to change it as well.

So, how do the RGB Genie remote drivers work then? If I have one matched to a color bulb and turn the bulb on via the remote, I thought I had to issue the off command to the virtual device created by the remote, not the bulb. If i issue the off to the bulb, the remote and the bulb are now out of sync. That seems pretty useless.

10

you're wrong:
inClusters:"0000,0001,0003,0020,1000", outClusters:"0003,0004,0006,0008,0019,1000"
cluster 1000 is touchlink

This driver doesn't implement changeLevel, and I don't understand how startLevel change from a dimmer device is going to map to an audio level change anyway.

I could have written this thing to taylor specifically to audio devices, however by mapping it into standard commands for these types of controllers we've not limited it to being a sound controller.

No, i really don't, but if you have a driver that does what you want with this device, then awesome.

The driver that we implemented for this device follows implementation specifics, and operational functionality that we have deployed for all devices of this class.

11

Yes, I correct my post.

But the device itself doesn't have a level. It has 3 commands..step, move and stop. That's it. If you were only going to implement a button controller, there is no need for switch and level capabilities since the device doesn't have them or report them. So, I don't really understand why they're there. They aren't able to be used at all if you can only modify them from the remote itself.

But far be it for anyone to question what Hubitat decides to do. You took setLevel off the fan controller too. How'd that turn out for ya?

12

Okay....let's go back to my other question...how do the drivers for the RGB Genie remotes work? Do they create a virtual device that accepts any of the standard color/level/on/off commands?

13

nope, they work the same way that this driver does.

14

So the remote is completely unsynced with the device it controls? But MirrorMe forces them into alignment. So, you're saying that you just have to have them not be synced? I don't see how that is useful at all. So, if i turn a light on by a remote and then off by hubitat. If i want to turn that light on again from the remote, i have to first turn the remote off and then back on again? That's ridiculous.

All you would have to do is implement the command and have them send the events from the driver. That's all....and that problem would be fixed. You just have to update the attributes in Hubtiat. Who cares what the remote itself thinks. It doesn't know the difference.

If you paired the remote directly to a light and then controlled that light from the Hue app, you wouldn't have this behavior. Because the remote itself doesn't have a switch attribute. It just tells the bulb to switch the power. if it's on, it turns off, if it's off, it turns on. It doesn't store it's own attributes. So, why should Hubitat force it to?

15

My point is, is that some of them do (the Hue button and one or two of the RGBgenie controllers), different buttons do different things depending on the stored internal state of the controller.

I don't know why you're arguing with me, you have a driver that does what you want.

16

Because I wanted to get the RGB Genie remote too.....and if this is how it works I'll save myself $40. I mean....what would be problem with implementing those commands in the driver? I don't see the downside of making the device more functional.

17

wrong again, this device certainly issues commands over cluster 0006, and guess what, there's only two of them, on and off...

18

You said it worked just like this remote. This remote doesn't have a switch attribute. So, they are not the same.

You know what....never mind. leave everything exactly how it is. Sorry to have bothered you.

19

what?
the ikea sound controller driver advertises the switch capability, as do most if not all the RGBgeneie controller drivers

With the hue button, switch and level were completely ignored and the device is simply a button controller due to the inconsistent implementation of the switch and level commands that it emits...

20

When you press the button once, does it always send the same message to Hubitat or are there different messages it sends?

EXACTLY!!!! THE DRIVER has the attribute....NOT the device itself!!! You just proved my point. If the driver is the thing that is in control of the attribute, why can't it accept commands to change it. The device itself isn't on or off. It's the driver that is maintaining that.

With a bulb, the device definitely has a state. It's either on or off. And the driver has to follow what the actual device is. If the bulb is on, the driver should report the bulb is on. But we don't have a real device with a state in this case. The switch attribute in the driver is 100% virtual and arbitrary. Because you've created a virtual device to represent the command coming from the remote in a more user friendly way. So, why not simply allow the commands to control the virtual device you've created just like any other virtual device? Simply accept them and save the attribute and send the event so apps can use them appropriately.

For example, if I have 10 bulbs set up with MirrorMe to an RGBGenie remote and I want to turn those 10 bulbs off. I could send the off command to the remote, then MirrorMe would publish the off command to the 10 bulbs. If the remote doesn't accept the off command, then i would have to turn all 10 bulbs off and they are now no longer in sync with the remote since the remote's virtual device is still on.

So, how does that work with level? If the bulbs are off and the remote thinks they are on at 90% and i hit brighten, the immediately jump to 90% and start ramping from there? Wouldn't it be a lot better if the remote was also off like the lights were and therefore started ramping from 0 just like if you issued the startChaning to the Bulb itself?

In essence, what I am proposing is making the remote kind of like the Group device, except without the backwards reporting.