Deconz-rest-plugin: [Request Device Support] Tint remote control by Müller-Licht

Yes! Another requests to add this Remote Devices from me!

Any news here?

Trying to connect my Tint remote with deconz.

But the sesor search in not finding my remote.

How did you connect it?

How did you connect it?

Press the reset button in the battery compartment and start a sensor search. It won't be visible in Phoscon because support for this remote has not been added yet.

+1 on the request list for Müller tint support of the remote. Thank you very much!

Just bought a GU10 and remote so hoping for support in the future.

I noticed Also are selling these off cheap now (€14 for the GU10 RGB + remote, €5 for the GU10 white and €7 for GU10 RGB). That's all they had.

So is the remote usuable as it is? Does it publish anything to the API?

@Philje123
Short form: YES

If you are starting a sensor search from the api, you will get the address and the id of your remote control.

But it does NOT appear in Phoscon app.

Thank you.

That will be fine as I mainly use home assistant to control my lights so as long as it the message gets through to there i can set it up to do what i want.

Any update on this?

I've tried to use the remote in it's current form but I don't get anything showing in Hass.io when I listen to "deconz_event". Do the remote buttons not get pushed through this way?

Nope ...

Push

somehow i think about abandoning raspbee now and moving over to a direct zigbee binding in openhab2

this missing device support is kind of annoying.

sadly it's not even open source.

it would be nice if this remote were supported

Vote +1 for an integration

Count me in as well.
Is there anything to be done by people having this remote to ease the integration? I am willing to test and give information needed. Just give a heads up.

Vote +1 for an integration

I managed to connect the tint remote with the system and it was possible for me to pair it with the lightbulbs and using the remote control, the groups in Phoscon app and the Hue Essentials app on android at the same time. But after a while the remote control does not react anymore and I have to pair it again with the bulbs. The new pairing leads to conflicts in the Phoscon app and I have to assign all light devices in the groups once again.
A similar problem when I restart the Raspberry Pi with RaspBee module. After reboot not only the remote control but also the groups in Phoscon app don´t work and everything has to be set up once again.
Does anybody have the same problems and maybe a solution for it?

I also would be grateful, if this device could be added to Phoscon.

+1

Remote and bulps are also available in Globus Baumarkt.

just fyi:
the remote bundled with lamps was available in aldi süd in germany again potentially increasing market share of this product yet again.

there is also zigbee light strips from müller-licht now.
i bought two of them so if you need any deconz output just ping me.

I also got the pair, E27 bulb and the remote... just if anyone needs testing. A question, how do you pair the bulb with homebridge (raspbee)??

I also got the pair, E27 bulb and the remote... just if anyone needs testing. A question, how do you pair the bulb with homebridge (raspbee)??

I've used the deconz app. Started search for new light. Switched the light on and off several times and it was there...

Thanks monotek, I did it like that... It will be nice to be able to use the remote... If there's a way I could help, just ask me. Thanks!!

I was not able to pair the remote with openhab. But I've read somewhere you can pair both devices. So you can switch the light with the remote & openhab for example.

First you have to pair the bulb and after that you can pair the bulb with the remote

+1

just bought a black one in Toom market

me too!

I was not able to pair the remote with openhab. But I've read somewhere you can pair both devices. So you can switch the light with the remote & openhab for example.

Hello,
This solution works only for some minutes after you Have connected remote with the bulb. Then you Have to reconnect it again.
So it would be very nice, if the remote will be supported by deconz directly.

I'd like a solution for a direct pairing in the phoscon app also. Thanks in advance.

next week at aldi again...

I would also appreciate support of Tint within Phoscon. I think about it, to buy LED-Panels with Zigbee and Remote for 3 rooms.

So +1 for Support

Still not supported?

Thank you.

That will be fine as I mainly use home assistant to control my lights so as long as it the message gets through to there i can set it up to do what i want.

I use home assistant too, how do you add it directly without the deconz integration??

Usually deconz team are fast in adding products.

This time no, some German rivalry?

+1

+1

With my Raspbee the remote is visible in deconz, but it seems not to be paired, Phoscon doesn't show the remote and the Plugin doesn't send any signal when buttons are pressed.

So please intrgrate!
+1

+1

+1

At the moment the remote can be bought in Amazon Germany for 15 €.
Maybe this is interesting for a developer.

Maybe @ebaauw or @SwoopX needs one. 😊

Otherwise is there any documentation on how to add new devices as a pull request?

No, I'm sorry, I don't need one. Have plenty of unused remotes lying around already. For me this is a hobby, and I don't want to spend money on devices I'm not going to use myself.

I'll be happy to have a look at it, if some-one can lend me or donate one.

I can send my over, not needed right now.

Please PM me on Discord for my address details.

Hello @serenity182 and @ebaauw,
thank you very much!

@serenity182 I received the remote yesterday, thanks Marc!

Does any-one have a manual for this remote? I can only find an uninformative _Datenblatt_ on the Müller web site. I'm not sure I understand all the nuances of the remote.

My first impressions:

• To reset the remote, hold the little button in the battery compartment for 5+ seconds until the red LED blinks quickly. After that, I pairs to deCONZ without any issue.
• It's a ZHA _Color Controller_, but with a _ZLL Commissioning_ cluster. The cluster reports four groups, but the device seems to send commands to different groups? Also, I cannot seem to get the remote to use the fourth group.
• No _Power Configuration_ cluster, but the _Power Descriptor_ seems legit.
• The remote has state. Pressing the _On/Off_ button cycles between sending _On_ and _Off_. No hold nor long presses.
• Pressing or holding the colour wheel results in a _Move to Color_ command. The xy values depend on the last values sent and where on the wheel you press or hold. I think the wheel has four different contacts (let's call them North, East, South, West). Each press "moves" the xy values towards the corresponding point on the CIE 1931 colour space: North: (0.3010, 0.1487) - pink-ish, East: (0.7, 0.3) - red, South: (0.3726, 0.5885) - green-ish, and West: (0.1164, 0.3473) Turquoise-ish. A hold "moves" directly to the corresponding point.
  So e.g. to get yellow, hold South for green-ish and then press East to move towards red. There seem to be eight steps between adjacent directions; opposite directions go through an in-between direction: East/West over South; and North/South over East. So a total of 36 different xy values.
• Pressing the _Warm_ and _Cool_ button sends _Move to Color Temperature_. It seems to remember the colour temperature and use for steps: 153, 200, 250, and 370. _Warm_ goes up one step, _Cool_ goes down one step.
• The _DimDown_ and _DimUp_ buttons behave fairly standard: _Step_ on press; _Move_ on hold, and _Stop_ on release (after hold).
• The six scene buttons send a _Write Attributes_ to manufacturer-specific (0x121b) uint8 attribute 0x4005 of the _Basic_ cluster. The value indicates the scene, although the order is a bit odd: _Read_: 3, _Day_: 1, _Disco_: 2, _Night_: 6, _Fire_: 4, _Love_: 5.
• The multi-light button doesn't send anything, but cycles between the groups. I cannot seem to find out what all it means when all four green LEDs are lit. I would expect a broadcast or fourth group, but the remote doesn't seem to send anything.
• The groups used by the remote are 0x4004 (left green LED), 0x4005 (middle), 0x4006 (right). I expect these to be picked at random when the remote is reset. The _ZLL Commissioning_ cluster reports groups 0x8bd3, 0x8bd4, 0x8bd5, and 0x8db6. I'm not sure whether to trust this: Wireshark reports malformed packages (actually both on the _Get Group Identifiers Request_ and on the _Get Group Identifiers Response_), and the device sends commands using different groups.

Exposing this remote will be interesting:

• I need to figure out how to deal with the groups. Other devices sending commands to multiple groups use different source endpoints. Based on that, we know to which position in config.groups the group corresponds. As long as you only use one group, it's probably OK to use a single value in config.groups, but I'm worried the REST API might want to delete the previous group when switching to the next, thinking the remote has been configured for a new group;
• The _On/Off_, DimUp_, _DimDown_ and scene buttons are pretty straightforward: 1002, 2001, 2002, 2003, 3001, 3002, 3003, and six x002 button events;
• The _Warm_ and _Cool_ buttons might be a bit challenging, as the REST API plugin needs to remember the last value and compare the current value to deduce which button was pressed. I think I've already done something similar for the Lutron Aurora;
• I won't be possible to deduce which area on the wheel is pressed: when e.g. you're at full East, pressing South and West result in the same new xy value. On first attempt, I think I'll simply expose the wheel as a single button (x002).
• It will be possible to link each of the 36 xy values to an angle representing the colour sent (rather than the position pressed or held). Not sure how best to expose that: it doesn't quite fit button event nor rotary event nor tilt angle. Could also expose state.xy with a note that it's only valid for the corresponding button event value x002.

Unter https://www.mueller-licht.de/fileadmin/404013_tint-BDA_021.pdf gibt es eine Anleitung für das Set in der auch die FB beschrieben wird.

Great to see you are looking into this @ebaauw!

• The multi-light button doesn't send anything, but cycles between the groups. I cannot seem to find out what all it means when all four green LEDs are lit. I would expect a broadcast or fourth group, but the remote doesn't seem to send anything.

My remote only has three LEDS at the bottom. When all three are lit, it controls the lights in all of the three groups.

• I won't be possible to deduce which area on the wheel is pressed: when e.g. you're at full East, pressing South and West result in the same new xy value. On first attempt, I think I'll simply expose the wheel as a single button (x002).
• It will be possible to link each of the 36 xy values to an angle representing the colour sent (rather than the position pressed or held). Not sure how best to expose that: it doesn't quite fit button event nor rotary event nor tilt angle. Could also expose state.xy with a note that it's only valid for the corresponding button event value x002.

A single button event looks like the easiest way for now. With just a simple button event, an app could configure the rules to send a hue_inc/xy_inc command to cycle through the colours. Unfortunately there is no way to match the light colour to the colour wheel this way.

A state.xy would be interesting, but I am not sure how that could be used in the rules. What about something like state.angle? It would be easier to configure the rules that way.

A ZLLRelativeRotary sensor could also be used. This way it is possible to detect if the wheel is "rotated" to the left or the right. (alternatively left/right rotation could be two button events?). A drawback of using a rotary sensor is that it is still not possible to know exactly which colour to send to the light.

The manual does give some more insights:

• It confirms the four contacts on the colour wheel, and the short vs long press function.
• When holding the _Warm_ and _Cool_ buttons the remote sends some more values with _Move to Color Temperature_, all the way up to 555 mired (down to 1800 K). Unfortunately, the API cannot distinguish between press and hold.
• The scenes, of course, have more inspiring names than what I can come up with: _Work Light_, _Sunset_, _Party_, _Night Light_, _Campfire_, _Romance_. From the description these would actually trigger dynamic effects on the lights (except for _Work Light_ and _Night Light_). Might be cool to expose these through the API using state.effect on the /lights resource.
• The fourth group is actually the other groups combined (makes kinda sense as all green LEDs are lit). I think it works only when lights are touch-linked to the remote.

My remote only has three LEDS at the bottom. When all three are lit, it controls the lights in all of the three groups.

I assume you touch-linked the lights to the remote? Or are using the out-of-the-box pairing?

A state.xy would be interesting, but I am not sure how that could be used in the rules. What about something like state.angle? It would be easier to configure the rules that way.

My thoughts exactly. There is already a state.tiltangle (for the vibration sensors).

A ZLLRelativeRotary sensor could also be used. This way it is possible to detect if the wheel is "rotated" to the left or the right. (alternatively left/right rotation could be two button events?). A drawback of using a rotary sensor is that it is still not possible to know exactly which colour to send to the light.

I suppose when remembering the previous xy value / absolute angle, the relative (delta) angle for the rotaryevent could be deduced. I'm not sure that's very informative, though. It would be +10° or -10° for presses, and anywhere between -170° to 180° (in 10° steps) for hold, with no clue about the position pressed, nor the current colour. The absolute angle would seem far more useful.

I assume you touch-linked the lights to the remote? Or are using the out-of-the-box pairing?

This was without deCONZ. I just paired the remote to the lights like described in the manual.

First attempt, but I think I nailed most of it.

config.group will be populated with the three groups, as the remote sends commands to them. The corresponding /groups resources should be created as config.group is populated. Note that the uniqueid of the /groups resources isn't.

I use the same buttonevent values for all groups, see the table below:

buttenevent | button | action | remarks
-- | -- | -- | --
1002 | _On/Off_ | press
2001 | _DimUp_ | hold
2002 | _DimUp_ | press
2003 | _DimUp_ | long release
3001 | _DimDown_ | hold
3002 | _DimDown_ | press
3003 | _DimDown_| long release
4002 | _Warm_ | press, hold | multiple 4002 events while holding
5002 | _Cool_ | press, hold | multiple 5002 events while holding
6002 | Colour Wheel | press, hold | see below
7002 | _Work Light_ | press
8002 | _Sunset_ | press
9002 | _Party_ | press
10002 | _Night Light_ | press
11002 | _Campfire_ | press
12002 | _Romance_ | press

Note that there's no way to tell holding the colour temperature buttons (_Warm_ and _Cool_) from pressing them. Holding them could result in multiple x002 events, as long as the temperature is changing.

Note that state.xy and state.angle are updated only on buttonevent 6002. If you set websocketnotifyall to false, they'll only be included in the web socket notification when they change.

The is one unsolvable bug: when you hold _Warm_, ct will go up to 555. If you then press _Warm_, it goes down to 370, which generates a 5002 instead of a 4002, same as pressing _Cool_ in that situation. There is no way to tell these buttons apart in this case.

For completeness: here's the /sensors resource:

$ ph get /sensors/16
{
  "config": {
    "group": "16388,16389,16390",
    "on": true,
    "reachable": true
  },
  "ep": 1,
  "etag": "3e8679bd6e84ebfefca53031ae2a62c9",
  "lastseen": "2020-05-30T18:44:50.385",
  "manufacturername": "MLI",
  "mode": 1,
  "modelid": "ZBT-Remote-ALL-RGBW",
  "name": "Tint",
  "state": {
    "angle": 90,
    "buttonevent": 1002,
    "lastupdated": "2020-05-30T18:44:50.386",
    "xy": [
      0.7,
      0.3
    ]
  },
  "swversion": "20180605-17",
  "type": "ZHASwitch",
  "uniqueid": "00:15:8d:00:03:41:88:92-01-1000"
}

And the /groups resources (again, with a non-unique uniqueid):

$ ph get /groups/16388
{
  "action": {
    "bri": 127,
    "colormode": "hs",
    "ct": 0,
    "effect": "none",
    "hue": 0,
    "on": false,
    "sat": 127,
    "scene": null,
    "xy": [
      0,
      0
    ]
  },
  "devicemembership": [
    "16"
  ],
  "etag": "3e8679bd6e84ebfefca53031ae2a62c9",
  "id": "16388",
  "lights": [
    "7"
  ],
  "name": "ZBT-Remote-ALL-RGBW 16",
  "scenes": [],
  "state": {
    "all_on": false,
    "any_on": false
  },
  "type": "LightGroup",
  "uniqueid": "00:15:8d:00:03:41:88:92"
}
$ ph get /groups/16389
{
  "action": {
    "bri": 127,
    "colormode": "hs",
    "ct": 0,
    "effect": "none",
    "hue": 0,
    "on": false,
    "sat": 127,
    "scene": null,
    "xy": [
      0,
      0
    ]
  },
  "devicemembership": [
    "16"
  ],
  "etag": "cb3c2706803fd865a2c20362806d8427",
  "id": "16389",
  "lights": [],
  "name": "ZBT-Remote-ALL-RGBW 16",
  "scenes": [],
  "state": {
    "all_on": false,
    "any_on": false
  },
  "type": "LightGroup",
  "uniqueid": "00:15:8d:00:03:41:88:92"
}
$ ph get /groups/16390
{
  "action": {
    "bri": 127,
    "colormode": "hs",
    "ct": 0,
    "effect": "none",
    "hue": 0,
    "on": false,
    "sat": 127,
    "scene": null,
    "xy": [
      0,
      0
    ]
  },
  "devicemembership": [
    "16"
  ],
  "etag": "2aea617ebc2640c6e997b1869e8e49c3",
  "id": "16390",
  "lights": [],
  "name": "ZBT-Remote-ALL-RGBW 16",
  "scenes": [],
  "state": {
    "all_on": false,
    "any_on": false
  },
  "type": "LightGroup",
  "uniqueid": "00:15:8d:00:03:41:88:92"
}

@ebaauw thanks a lot for your work. I have a sitting remote, that soon thanks to you will come back to life

Wow. Awesome work. I don't understand most of it... But thank you! 😁😂🤣

The scenes, of course, have more inspiring names than what I can come up with: Work Light, Sunset, Party, Night Light, Campfire, Romance. From the description these would actually trigger dynamic effects on the lights (except for Work Light and Night Light). Might be cool to expose these through the API using state.effect on the /lights resource. >

Since I use the REST API exculively it would be fantastic to get some more effects besides the coloorwheel, especially the camp fire effect would be great.

Happy to take shot at that, if some-one can lend or donate me a Tint bulb.

Don't have tint bulbs yet, only the remote, but would be happy to donate if you let me know how. I guess the cheapest would be a GU10 RGB on Amazon.nl right now...
https://www.amazon.nl/Müller-Licht-LED-lamp-reflector-wit-kleur-wittinten/dp/B07ND91HGT/ref=sr_1_1?__mk_nl_NL=%C3%85M%C3%85%C5%BD%C3%95%C3%91&dchild=1&keywords=m%C3%BCller+licht+tint&qid=1591181929&sr=8-1

Happy to take shot at that, if some-one can lend or donate me a Tint bulb.

Hi. If you can find a store in your area where to buy it I don't mind paying it....

Just tell me how much it was and give me a method to send you the money (paypal, maybe??).

Regards!!

Manuel.

Thanks, @Viguri. It’s not needed as @scholzmichael already ordered a GU.10 to be delivered at my home, ETA Jun 6. Will keep you posted.

The GU.10 arrrived today already!

I must say, I'm quite impressed:

• ZHA _Extended colour light_ with ZGP _GP Proxy Basic_. ZCL version 2, so no ZB3;
• Supports _PowerOn OnOff_ and _PowerOn Level_. It also exposes _PowerOn Color Temperature_, but that doesn't seem to do anything.
• Turns on and off on _Move to Level (with On/Off)_.
• Colour temperatures from 153 (6500K) to 555 (1800K);
• Colour gamut: red [0.5245, 0.2337], green: [0.1112, 0.7717], blue: [0.1277, 0.1277]. It doesn't seem to report these, but it does report the actual colour (rather than the colour set), so ph probe works;
• I'm not sure how many channels the spot has: the warmest colour temperatures seem to have colours mixed in them, but there's definitely a white channel. It's very bright at ct 370. The green and blue are more vibrant than the gamut-B Hue lights;
• Supports attribute reporting for "all" attributes (even the custom attribute to set the special scenes);
• Colour temperature is stored as _Enhanced Hue_ in scenes;
• 16 scenes; It doesn't report the supported number of groups;
• OTAU cluster appears to be functional.

One caveat: It reports _Color Capabilities_ 0x001f, but _Enhanced Hue_ stays at 0 all the time, and it doesn't support the commands to set _Enhanced Hue_. It does report _Enhanced color mode_ as _Enhanced current hue and current saturation_ when colour loop is active.

Thanx @ebaauw for all the work and time you invest in this project. Looking forward to see if we can get the REST API enhanced with a little more effects. Also thanks a lot for the first review. I'm using Osram and Ledvance right now, considering to use Müller Licht Tint in future.
P.S. What is also missing would be a nice X-mas effect (slowly fading between red and green)...starting to dream again, but after all still 6 month to go till this would be needed :)

The Müller scenes are actually handled by the light’s firmware, similar to colour loop. They would need to support an X-mas scene before the API.

For my X-mas effect, I simply created a view scenes, with different green and red patterns for my living room lights. I simply run a bash script that recalls these scenes in an endless loop.

Sounds interisting, Could you share the bash script? Should then obviosly work with most or all RGBW Zigbee devices if I understand correctly...

Hi,

i am quite new to the zigbee topic, but with much interest i followed this discussion here.
I own a buld (tint mueller light), a hue go and since quite some time this tint remote control.

Now the updated software is available, but somehow i am still not able understand the whole topic.
Formerly i was not able to connect the remote, now it seems to work somehow.

Mainly I am using Phoscon, so i went to the switch section and tried to pair (i thought the RC is a switch), but this did not work. Using the Sensort Section I was able to connect the remote, at least the UI showed me a green OK when I clicked the reset for button for 5s and then click the group buttons several times.
But the RC is not shown in the Phoscon App:

also no groups are shown:

But I can see 3 groups in the Open Wireless Light Control (2016):

these groups I cannot delete...
_I also had the case where i just had one group and could add additional groups by doing the connection steps once again. after that i completely reset the gateway and connectecd all devices again, after that i directly get all three devices_

deconz shows me a single device:

So I thought the three groups are somehow connection to the group switch, althought "group all" does not have any effect. I think this is what was ment by "The multi-light button doesn't send anything..."
But I cannot see the device or the groups in phoscon.
I could do some configuration in Hue Essentials for a button, but this i could not see in phoscon or Open Wireless Light Control.

So my question(s)

• Did i understand something wrong, or did i do something wrong?
• Why is the device or the groups not shown in phoscon?
• How could I delete the device or the groups? btw. initially all groups are named equal.
• How would I configure the other buttons with scenes in Phoscon?
• And one question for me: What are you mainly using to maintain configure your smarthome: Phoscon, Deconz or something like hue essentials, or do you use something like openhab/homeautomation.
  And i think if you prefer one, you are mainly doing the configuration only with the selected Software.

I encountered the same, sensor is visible in deCONZ, but not in Phoscon, allthough the Pairing showed green in phoscon. I actually thought that I might have to connect a tint bulb first (which I don't have yet)...

The REST API plugin creates the ZHASwitch /sensors resource on pairing, and the /groups resources, as it sees a command to each group. You need to select each group, and press a button for the corresponding group to be created (and listed in /config/group).

Phoscon doesn't yet support the remote and, I understand, it doesn't show empty groups. The old web app shows empty groups. Once you've added a light, I think, the group should be visible in Phoscon. The lights added to one of the groups are controlled directly by the remove (even when deCONZ is down). In addition to this you can define rules on the buttonevent values of the ZHASwitch for advanced automation.

If you reset the remote, it will pick new (random) groups. The REST API plugin should cleanup the stale groups after re-pairing the remote (as it sees the new groups), but I'm not too sure that will be done correctly in all cases.

Ok, the old app sees the empty groups and I can add a bulb, control it via the old app as well. Control via remote in this case does not seem to work, and Phoscon does not show the group at all.

You need to set the remote to the corresponding group. Double-check that the group is still listed under the remote’s config.group.

Seems to be, it is even shown in node red as "ZBT-Remote-ALL-RGBW 2(Lights: 1)

That means that the group was created for the remote, not that the remote still sends commands to that group.

It does show me 3 groups in "config.group" when I do a get api/apikey/sensors/(ID of the tint) where in one of them is the corresponding bulb so I guess it should be setup correctly. The only thing that I must admit is that it is not a Müller Licht bulb, but a Ledvance PAR16 RGBW Z3, but turn on/off should at least be working as it does from the old app, and it should be shown in phoscon, or not?

Anyway, I cannot use the remote's functionality (within the api) as it was palnned since even in the api the Group limit for the tint remote actions is limited to 3 groups, I would have needed 4 Groups at least. That would mean I must use a second (tint remote) sensor and I don"t think its possible to create it only virtually within the api, or is it?

It does show me 3 groups in "config.group" when I do a get api/apikey/sensors/(ID of the tint) where in one of them is the corresponding bulb so I guess it should be setup correctly.

For me the same

The only thing that I must admit is that it is not a Müller Licht bulb, but a Ledvance PAR16 RGBW Z3, but turn on/off should at least be working as it does from the old app, and it should be shown in phoscon, or not?

I setup 2 of the 3 groups for testing, one has a tint bulb in, the other a philips hue.

• if remote is on group one, i can only switch the tint on off incl. color selection and built-in scenes of tint bulb (without configuration)
• if remote is on group two (hue), i can only switch the hue on off incl. color selection (no scenes)
• if remote is on all group, nothing happens, although the remote red led goes on for a click (3 times) which assumes me it sends the command to all three groups, but nothing happens here

nevertheless as you already said, the groups do not show up in Phoscon, although if they are not empty

if remote is on all group, nothing happens, although the remote red led goes on for a click (3 times) which assumes me it sends the command to all three groups, but nothing happens here

No, it doesn’t. In fact it doesn’t send anything at all when all groups are selected.

Note that the scenes are Tint specific and only work for Tint lights.

if remote is on group one, i can only switch the tint on off incl. color selection and built-in scenes of tint bulb (without configuration)

tried again, you're right, I can reproduce this to 100%

No, it doesn’t. In fact it doesn’t send anything at all when all groups are selected.

Ok, didn't know that, my impression was to control all 3 groups once they are selected at one stage...

if remote is on all group, nothing happens, although the remote red led goes on for a click (3 times) which assumes me it sends the command to all three groups, but nothing happens here

No, it doesn’t. In fact it doesn’t send anything at all when all groups are selected.
although, the indicator led blinks red? very strange. As from blinking behaviour I thought it sends the message to all three groups.

When I write a rule, do I know which group is selected?
Or in other words can I write a rule for one of the scene buttons (condition 1), which only applies in a dedicated group (condition 2)?
As the default scenes are only applied to the dedicated group: If i have two tint bulbs one in grp1 the other in grp2, only grp1 bulb starts the scene if remote is in grp1.

Note that the scenes are Tint specific and only work for Tint lights.

Sure, I understand. Can I disable the behavior of the scene buttons for tints.
When I add one tint bulb and a non tint bulb into the same group, only the tint bulb understands the scene and starts doing something, therefore i would like to use the buttons for my own scenes

When I write a rule, do I know which group is selected?

You don’t. Neither does the REST API plugin, see my explanation above.

Can I disable the behavior of the scene buttons for tints.

No, as with most consumer-grade remotes, that’s hard-coded in the remote’s firmware. You could refrain from adding lights to the groups, and solely control lights using rules.

ok, this seems to be rather difficult to handle. I've got 3 tint bulbs now in a ZHA gourp (old webIF). turning on and off as well as colour setting works fine from old app as well as the corresponding tint remote. The special scenes as I understood are implemented in the FW of the bulbs and can only be set by the remote, not by using webIF old, not by the api either. Within phoscon nothing can be done since the group is not shown there at all. So what I did is create a group in phoscon itself to be able to control basic functionality via api and phoscon. This works of course. The lack of effects in the deCONZ api is a pitty. I hope that at one stage in time some more effects will be available for all colour bulbs.

The lack of effects in the deCONZ api is a pitty.

I already added API support for the special scenes, but forgot to mention that here. Should already be Included in 2.05.78. Set "effect" to "sunset", "party", "worklight", "campfire", "romance", or "nightlight". To cancel, set to "none". API also reports current effect when set thru the remote, incl. web socket notification.

@ebaauw,
thanx again, but it seems its not in yet. Response is:
"error": {
"address": "/groups/16388/action/effect",
"description": "invalid value, campfire, for parameter, effect",
"type": 7
}
I'm on 2.05.78
this is the ZHA group containing 3 tint GU10 bulbs...

Sorry, that’s only available in the /lights api. Still need to refactor the /groups part, but better iron out any issues with /lights first.

Hi, seems I always run into trouble, trying the wrong thing first…:), tint effect for lights is working fine, thanx. I saw that the group functionality in the api works a little strange, in fact if you swop from group effect to a steady value for the group not all bulbs seem to work sometimes, meaning sometimes one bulb seems to stay in the effect mode, need to analyse this isuue when I get to it.

Thanx again for your work implementing this.

By the way, would you mind sending me your X-mas script and the corresponding light settings as well? Are you running the script on your pi or a win machine?

I saw that the group functionality in the api works a little strange, in fact if you swop from group effect to a steady value for the group not all bulbs seem to work sometimes, meaning sometimes one bulb seems to stay in the effect mode, need to analyse this isuue when I get to it

I'm afraid that's courtesy of the Tint firmware. If you start the effect while the bulb is off, the effect takes place, but the bulb won't report as on. I think the bulb behaves differently in this state, than when it was already on before starting the effect. Also, there doesn't seem to be a documented way to cancel the effect. Setting "effect": "none" sends the command to stop a colour loop, which, as it turned out, also happens to cancel the Tint special effect, but the remote doesn't provide something similar.

would you mind sending me your X-mas script and the corresponding light settings as well?

It wasn't even a script, but a bash alias:

alias xmas='while true; do  ph put /groups/220/scenes/3/recall; sleep 2; ph put /groups/220/scenes/4/recall; sleep 2; done'

I'd run this on the Pi.

Scene 3 would put the "odd" lights to red, and the "even" to green; scene 2 would put the "odd" lights to green and the "even" to red.

I'm afraid that's courtesy of the Tint firmware. If you start the effect while the bulb is off, the effect takes place, but the bulb won't report as on. I think the bulb behaves differently in this state, than when it was already on before starting the effect. Also, there doesn't seem to be a documented way to cancel the effect. Setting "effect": "none" sends the command to stop a colour loop, which, as it turned out, also happens to cancel the Tint special effect, but the remote doesn't provide something similar.

Its not a big issue if its known, I just send the string "effect": "none" within the next "on" command and it seems to work fine…and I don't use the remote, only needed it to pair, so I can use the functionality within the api.

Thanx a lot for your alias, will def. try this.

I got myself one of these remotes to play around with and I am quite impressed. This is what is working so far:

• Setup of groups (only tested one)
• Color control through the wheel without any rules/setup (the behavior is actually quite good, I really like it)
• Reporting of key events for all keys (including the scene keys!) through the API

So thank you very much for your efforts @ebaauw. This is a really cool ZigBee remote and a good replacement for my old TouchLink Hue remotes, which unfortunately no longer work with DeCONZ.

Issues so far:

• The color temperature of a group cannot be controlled directly. Is this a known issue or is color temperature supposed to work? I have only tested this with a Hue bloom so far and it does not seem to react to the color temp buttons. Now I could set up rules for this externally, but that's quite clumsy.
• After my ConBee was offline for a few days the remote lost it's connection to it and does not reconnect to it. It can still directly control the ZigBee lights in it's group, because this works without the coordinator. Pulling batteries of the remote causes it to reconnect.

The Hue Bloom doesn’t support colour temperature; these are _Color Light_ devices.

I’m not sure what you mean by “lost the connection”. There are no connections in Zigbee.

OK, I messed up the terminology here. I actually meant color saturation. The (round) Philips Hue remote allows me to shift the colors more into white and I was expecting the "color temperature" button to do the same thing here. But as you said, it seems to be color temperature only and my guess is that this really is a firmware thing which cannot be changed within deCONZ.

Thankfully these button presses are reported through the API, so they are scriptable.

What I meant by "losing connection" is the line between the remote and the ConBee in the deCONZ Qt UI. The Conbee and deCONZ were down for a while and after a restart the line between the remote and the Conbee (the coordinator) would not come back. Only the line between the remote and the lights it is controlling. The result was that the button presses were not reported by the deCONZ API any more. The remote "sensor" was stuck with a last_updated attribute which was a few days old, however the remote could still control the lights.

As I said pulling batteries of the remote worked around this. I am not sure wether this is a deCONZ issue or an issue with the remote's firmware.

Only the line between the remote and the lights it is controlling.

That is not what the line represents.

The result was that the button presses were not reported by the deCONZ API any more.

That's not related to the lines. It's also odd, as the remote sends broadcast messages, which are picked up by the light and by the coordinator equally well. Probably an issue with deCONZ and/or the coordinator dropping off the network. You might want to check the deCONZ log for errors.

Thanks for the clarifications, @ebaauw

There is one more thing: the color wheel moves the color of my Hue Bloom to the desired color. However deCONZ never picks up the color change, the light is stuck on the old color there. I have checked the REST API for the light and the xy/color and hue values never change when the light is controlled through the remote. However the bri attribute is updated when setting the brightness through the remote.

To me this also sounds more like a bug in deCONZ, as it should poll the device's state from time to time and update the exposed color eventually. Or is it supposed to be like this that color changes through the remote will never show up on the API/Phoscon?

Hm interesting. I think the light is simply not being polled by the API plugin. To check: if you read the _Color Control_ cluster attributes in the GUI, xy should be updated. Is bri updated immediately, or delayed?

Hm interesting. I think the light is simply not being polled by the API plugin. To check: if you read the _Color Control_ cluster attributes in the GUI, xy should be updated. Is bri updated immediately, or delayed?

bri is updated automatically with a little delay (up to ~10 seconds). And you are right, as soon as I press the _Read_ button in the _Color Control_ cluster xy is also updated both in the REST API and in the cluster info panel under _Attributes_. So yeah, it looks like a polling issue. Is there a way to tell the API plugin to poll the light? Can you reproduce this with other Hue lights or is this just my particular Hue Bloom?

I have already restarted deCONZ, replugged the Hue Bloom and the Conbee II and xy still won't update automatically. My guess is that this has nothing to do with the remote.

My guess is that this has nothing to do with the remote.

Correct. The light updates, and when queries, reports the correct xy value.

So yeah, it looks like a polling issue. Is there a way to the the API plugin to poll the light? Can you reproduce this with other Hue lights or is this just my particular Hue Bloom?

No the API plugin handles the polling itself. I always found this a bit opaque, some lights seem to be polled more frequently than other, and after restarting deCONZ this changes. Note that colour is only queried when the light reports on (same for brightness, though).

I think it's an API plugin bug for the Bloom (or for light types similar to the Bloom). Did you try the remote with other colour lights? When I run ph -v probe on one of my Blooms, it times out, probably meaning deCONZ hasn't queried the colour cluster in over five minutes.

Took out the sniffer: even when the Bloom is off, the _Color Control_ cluster is queried, but for attributes 0x0008, 0x4001, 0x400a, 0x400b, 0x400c. When the Bloom is on, the _Level Control_ cluster is queried. Still the same query to _Color Control_. Looks like the API is stuck trying to initialise ctmin (0x400b) and ctmax (0x400c), but these attributes are unsupported for type _Color Light_.

Best open a new issue for this.

Did you try the remote with other colour lights?

I have just tried it with a Hue E27 bulb and the light's color updates fine through the API, even when set through the remote. So my Hue Bloom turned out to be a bad light for playing around with the remote :smile:

Thank you very much for opening the issue regarding the Bloom and for figuring out the details @ebaauw. Your efforts in this project are highly appreciated. :+1:

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Can we avoid to close this “issue”?? Thanks a lot!! It’s an interesting thread.

De: stale[bot] notifications@github.com
Enviado el: domingo, 16 de agosto de 2020 23:56
Para: dresden-elektronik/deconz-rest-plugin deconz-rest-plugin@noreply.github.com
CC: Viguri manoloviguri@gmail.com; Mention mention@noreply.github.com
Asunto: Re: [dresden-elektronik/deconz-rest-plugin] [Request Device Support] Tint remote control by Müller-Licht (#1209)

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1209#issuecomment-674582866 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ACPNQ2FT3V2GGRYMXHNKASLSBBIYBANCNFSM4GT6GGOA .

Can we avoid to close this “issue”?

Why? The remote is supported by the API and I’m not aware of any remaining open points.

Hello. Ok, sorry if that the case. Is there any notes how to operate with it?

De: Erik Baauw notifications@github.com
Enviado el: lunes, 17 de agosto de 2020 8:02
Para: dresden-elektronik/deconz-rest-plugin deconz-rest-plugin@noreply.github.com
CC: Viguri manoloviguri@gmail.com; Mention mention@noreply.github.com
Asunto: Re: [dresden-elektronik/deconz-rest-plugin] [Request Device Support] Tint remote control by Müller-Licht (#1209)

Can we avoid to close this “issue”?

Why? The remote is supported by the API and I’m not aware of any remaining open points.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1209#issuecomment-674675455 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ACPNQ2B67VUMLPOMGTFT7QTSBDBWXANCNFSM4GT6GGOA .

See above, e.g. https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1209#issuecomment-636373482
You might need to unhide the hidden comments.

Is the /groups part implemented yet? I did not read anything about it in the latest beta releases, and furthermore, will it be visible in the phoscon app in future as well? Didn't update yet since I did not see anything documented regarding the above mentioned points...

Has been from the first support. Note that Phoscon no longer shows groups associated with switches.

For support of the remote in Phoscon, please open an issue in their repo. It's closed source, so I cannot help there.

You can configure the individual buttons in my app Hue Essentials. The configuration is stored in deCONZ.

Hi Erik, I was referring to your comment from June 25th

Sorry, that’s only available in the /lights api. Still need to refactor the /groups part, but better iron out any issues with /lights first.

So if this is in by now its fine, and thank you. I guess personally I can live without seeing the remote in phoscon allthough it would have been nice to at least see the groups which can be seen in the old app. Thanx to all who worked on this.

Sorry, you mean setting the Tint scenes through the API using a /groups resource, my bad. No, that is still on the todo list, refactoring the handling of a PUT to the action. However, that’s not related directly to supporting the Tint remote. Best open a new issue for that, if you want to track it.

Hi Erik,
correct, thats what I meant,
but no problem, its not a real urgency if you are still going to work on this I'll just wait and read the release notes till I see it.

As there hasn't been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.

Hi guys. Thank you for your hard work!
I have the remote working, only question is regarding ColorWheel and home assitant.
I can see in REST API that when I press the color wheel - angle parameter changes:

{ "config": { "group": "16388,16389,16390", "on": true, "reachable": true }, "ep": 1, "etag": "e622c29f2a6c54a3b4645da6a0a435d5", "lastseen": "2020-09-12T13:56:18.871", "manufacturername": "MLI", "mode": 1, "modelid": "ZBT-Remote-ALL-RGBW", "name": "ZBT-Remote-ALL-RGBW 13", "state": { "angle": **180**, "buttonevent": 6002, "lastupdated": "2020-09-12T13:56:18.647", "xy": [ 0.3726, 0.5885 ] }, "swversion": "2.0", "type": "ZHASwitch", "uniqueid": "00:15:8d:00:03:56:b6:1f-01-1000" }

however when I listen to even 6002 in deconz all I get is this (there no state information in the notification):

`
Event 154 fired 14:56:

{
"event_type": "deconz_event",
"data": {
"id": "zbt_remote_all_rgbw_13",
"unique_id": "00:15:8d:00:03:56:b6:1f",
"event": 6002
},
"origin": "LOCAL",
"time_fired": "2020-09-12T13:56:18.874560+00:00",
"context": {
"id": "bb8ea20cf4ff11eaa0f8d733934ab1f1",
"parent_id": null,
"user_id": null
}
}
`

Is this an expected behaviour that home assitant only gets a button press, but no state?
If yes - how to get angle information in home assistant?
Do I need to do POST request after getting a deconz_event?

Thank you!
Irek

That is expected behavior right now. I am working on exposing the angle and xy values through Home Assistant. Stay tuned 😉

@ebaauw I found a bug with this remote. I just got myself a second tint remote for development purposes and it looks like the second tint remote did not create new ZigBee groups. It's using the same groups as the first tint remote. This is the API output:

In [15]: requests.get("http://gandalf/api/xxx/sensors/12",).json()
Out[15]: 
{'config': {'group': '16388,16389,16390', 'on': True, 'reachable': True},
 'ep': 1,
 'etag': 'b1336f750d31300afa441a04f2c69b68',
 'lastseen': '2020-09-15T16:42Z',
 'manufacturername': 'MLI',
 'mode': 1,
 'modelid': 'ZBT-Remote-ALL-RGBW',
 'name': 'ZHA Remote 1',
 'state': {'angle': 10,
  'buttonevent': 6002,
  'lastupdated': '2020-09-08T18:58:24.193',
  'xy': [0.3381, 0.1627]},
 'swversion': '2.0',
 'type': 'ZHASwitch',
 'uniqueid': '00:15:8d:00:03:61:xx:xx-01-1000'}

In [14]: requests.get("http://gandalf/api/xxx/sensors/26",).json()
Out[14]: 
{'config': {'group': '16388,16389,16390', 'on': True, 'reachable': True},
 'ep': 1,
 'etag': '5303999b3185631a9bad1e009ad18c2c',
 'lastseen': '2020-09-15T17:30Z',
 'manufacturername': 'MLI',
 'mode': 1,
 'modelid': 'ZBT-Remote-ALL-RGBW',
 'name': 'ZHA Remote 2',
 'state': {'angle': 0,
  'buttonevent': 4002,
  'lastupdated': '2020-09-15T17:30:07.711',
  'xy': [0.301, 0.1487]},
 'swversion': '2.0',
 'type': 'ZHASwitch',
 'uniqueid': '00:15:8d:00:04:6e:xx:xx-01-1000'}

The apparently not so random groups are picked by the remote. Nothing the API plugin can do. I think the remote should pick other groups, after a factory reset.

Hi @Thomas-Vos , my screen looks different in my Hue Essentials App.

Hi @Thomas-Vos , my screen looks different in my Hue Essentials App.

Hello @foscoj, thanks for the feedback. Could you make sure you are using the latest version of Hue Essentials from Google Play? Should be version 1.14.3 (or higher).

If you are using the latest version, please do the following: On the screenshot you sent of Hue Essentials, tap the three dots at the top, tap Details, and copy the Identifier.

Then go back to the devices (Geräte) screen, select your deCONZ gateway, tap Api Debugger, tap Continue. Replace the URL (default value /config) with /sensors/<id>, where <id> is the identifier you copied earlier. Then tap the GET button. Please copy the response and paste it in a reply here, so I can see what goes wrong.

Funny thing, wanted to copy the ID from the switch device and got the right screen now...

App version is 1.14.4, checked right after the screenshot this afternoon and there was no update pending, strange. Ia it possible, that some action within deconz triggered the right attributes to recognize it for hue essentials?

Anyway, thanks for the great app and the fast response!

Edit: pressing all buttons, one after the other, helped with the other remotes to be recognized.

First of all thank you for the great work done here! Would it be possible for someone to write a list of instructions on how to connect this remote to deconz? I understand that phoscon is not able to show it. I'm able to see the remote in the deconz ui however it won't show up as a sensor inside deconz or in @Thomas-Vos's app. Here is what I got and tried so far:

• Make sure the remote is not listed inside deconz (delete node if it exists)
• Open phoscon pwa and start the search for new sensors (also tried doing that via the deconz rest api touchlink scan)
• Press the reset button in the Remotes battery compartment.

After that I'm able to see the remote as a new device in deconz however it's not listed as a sensor. I can't see it in the app from @Thomas-Vos nor in the rest api by deconz (http://x.x.x.x:8080/api/<id>/sensors).

Here's what I can see in deconz:

@David-Development try switches 😉

@foscoj That's a very good point 🤦 😅 I tried reconnecting it 10 times now (as a switch instead of a sensor) but unfortunately it's still not showing up. Phoscon is just searching for 3 minutes and then it says something like "nothing found". I'm not sure why it's not able to read the zcl version, hw version etc.

Does it blink fast during the reset press and if you let it go blink slow? It's only connected when it stops blinking within 30 seconds.
Just had an issue with one of mine, after changing the batteries it worked like a charm (original batteries, worked before, two weeks old...)

@foscoj Sorry for the delay, I had to double check. While I press the reset button the red light is blinking rapidly. As soon as I let go it will blink one more time, just a little slower, then it will stay red for another two seconds and then the red light shuts off for good.
In deconz I can see the device showing up immediately - the indicator bubble in the top left corner is flashing green rapidly for a couple seconds. When I press a button on the remote it flashes blue (which means data transfer is happening).

However after three minutes phoscon just says "connection failed". Do I need to press some other buttons?

Interesting enough.. when I try deleting the node from deconz it keeps on showing up again after a few seconds even though I removed the batteries from the remote. Do you think my deconz is messed up? Maybe I should try resetting my deconz setup.

@foscoj Sorry for the delay, I had to double check. While I press the reset button the red light is blinking rapidly. As soon as I let go it will blink one more time, just a little slower, then it will stay red for another two seconds and then the red light shuts off for good.
In deconz I can see the device showing up immediately - the indicator bubble in the top left corner is flashing green rapidly for a couple seconds. When I press a button on the remote it flashes blue (which means data transfer is happening).

However after three minutes phoscon just says "connection failed". Do I need to press some other buttons?

Interesting enough.. when I try deleting the node from deconz it keeps on showing up again after a few seconds even though I removed the batteries from the remote. Do you think my deconz is messed up? Maybe I should try resetting my deconz setup.

Pairing seems to be successful then, phoscon should report some name within switches, configuration is not supported by phoscon.

That's why I use hue essentials afterwards

@foscoj I tried resetting deconz three times yesterday (delete database, create new network etc) however phoscon still won't pick it up. And I can't see the device in the hue essentials app either. I bought two IKEA switches yesterday and they both were recognized immediately..
What version of deconz are you guys on? Is there a version of the phoscon app? I couldn't find a version info for the pwa.

In Hue essentials you should see some Z something device, can't look it up right now. Phoscon as well, but configuration is only possible in hue essentials. Sorry I can't help further, with new batteries it worked on all three for me...
Deconz version should be current, phoscon is bundled with it

The apparently not so random groups are picked by the remote. Nothing the API plugin can do. I think the remote should pick other groups, after a factory reset.

@ebaauw I did a factory reset of the second remote, removed it from DeCONZ and paired it again. Unfortunately the second remote always picks the same groups (16388,16389,16390) as the first remote. You have already said that the groups are picked by the remote but can we change this somehow afterwards? Maybe through some direct device binding or something?

@foscoj and @Thomas-Vos: I can reproduce the missing remote screenshot in the setup screen of Hue Essentials. The remote shows in the list, but the setup screen only shows a buttenevent input field right after pairing. As soon as you have pressed a few buttons on the remote, especially the color wheel, it's displayed correctly. I suspect that Hue Essentials expects the device['state']['angle'] attribute to be set, which is set the very first time the color wheel is touched after pairing.

Maybe through some direct device binding or something?

That would be a neat trick, as the remote only has one endpoint.

As there hasn't been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.

As there hasn't been any response in 28 days, this issue will be closed. @ OP: If this issue is solved post what fixed it for you. If it isn't solved, request to get this opened again.