Deconz-rest-plugin: Philips Hue Smart Button - Support Request

Created on 16 Nov 2019  路  40Comments  路  Source: dresden-elektronik/deconz-rest-plugin

Hello,

I bought a Philips Hue Smart Button and I would like to use it with deCONZ / Home Assistant.
URL: https://www2.meethue.com/en-us/p/hue-smart-button/046677553715

It was a bit tricky to pair it with deConz / Conbee II (multiple resets where required) but I finally managed to do it.

Basic

Node Info

I enabled the advanced log but I did not seen anything for the node address when pressing the button, only the following lines are referencing the address.

11:41:01:666 CTRL skip polling while permit join is set 11:41:01:668 APS-DATA.indication srcAddr: 0xfea4, srcEp: 0x00 dstAddrMode: 2, profile: 0x0000, cluster: 0x8002, lqi: 255, rssi: -53 11:41:01:668 APS-DATA.indication request id: 143 -> finished 11:41:01:668 APS-DATA.request id: 143 erase from queue 11:41:01:668 ZDP status = 0x00 -> SUCCESS 11:41:01:668 ZDP Node_Descriptor_rsp 0x001788010606815C - 0xFEA4 11:41:01:673 FP indication 0x0000 / 0x8002 (0x001788010606815C / 0xFEA4) 11:41:01:673 ... (0x001788010606815C / 0xFEA4) 11:41:01:673 ZDP indication search sensors 0x001788010606815C (0xFEA4) cluster 0x8002 11:41:01:673 ZDP indication search sensors 0x001788010606815C (0xFEA4) clear timeout on cluster 0x8002 11:41:01:679 [2] get active endpoints for 0x001788010606815c 11:41:01:679 APS-DATA.request id: 147, addrmode: 0x02, addr: 0xfea4, profile: 0x0000, cluster: 0x0005, ep: 0x00 -> 0x00 queue: 0 len: 3 tx.options 0x00 11:41:01:746 skip device discovery while end devices is added

Let me know if I can provide any additional information about the device.

Thanks for your help. 馃槃

Most helpful comment

Clusters come in pairs:

  • The device being controlled implements the server (blue) cluster;
  • The controlling device implements the client (grey) cluster.

A binding tells a device (_Source_) where (_Destination_) to send messages associated with the cluster:

  • Either a (list of) unicast(s) to (an)other device(s), where you specify the IEEE address and endpoint by dragging and dropping the endpoint (not the cluster);
  • Or a groupcast, where you specify the group ID, by selecting the radio button and edit the group id in hex.

There's nothing magical about a binding, its just a configuration on the source device. Unfortunately, the deCONZ GUI doesn't support querying the binding table, so there's no easy way to check bindings. Most devices have limited (non-volatile) memory for the binding table, so a single binding to a group is preferred over multiple bindings to individual devices.

Now here's the tricky part:

  • Client clusters send commands to the associated server cluster. Typically you want to use a groupcast message for these, so you'd create a binding from a client (grey) cluster to a group;
  • Server clusters send notifications (reports) about their (changed) state. Typically you want a unicast message for these, so you'd create a binding from a server (blue) cluster to (typically) the coordinator (RaspBee/ConBee).

Now here's the really tricky part:

  • A physical device typically implements multiple functions (clusters) and might be the controller for one function and, at the same time, the controlled device for another function. This is actually the case for the Hue dimmer (and, I assume, the smart button), see below;
  • The same logical function might be implemented differently by different devices. Typically Hue and Xiaomi devices act as controlled devices, sending notifications to the bridge/gateway, whereas Tr氓dfri and most other devices act as controllers, sending commands to (a group of) lights. In other words: Xiaomi switches behave like sensors and the Tr氓dfri motion sensors behave like wireless switches. The device type might give a clue, but better check the clusters to be sure.

Now here's the really, really tricky part: The Hue dimmer and, I assume, the Hue smart button are hybrids:

  • When paired with the Hue bridge, they act as a sensor, sending notifications about the buttonevent to the bridge.
  • When used standalone, they act as wireless switch, sending commands to the bound (group of) lights.

This is reflected well by device types on the Hue dimmer endpoints: _Non color scene controller_ on endpoint 0x01 (with the client _On/Off_ and _Level control_ clusters) vs _Simple sensor_ on endpoint 0x02 (with the server 0xfc00 cluster).

So you need the following bindings for the Hue dimmer and, I assume, the Hue smart button:

  • From the server 0xfc00 cluster to endpoint 0x01 of the ConBee/RaspBee, so that the switch sends buttonevent notifications to the gateway;
  • From the server _Power Configuration_ cluster to endpoint 0x01 of the ConBee/RaspBee, so that the switch sends battery reports to the gateway (you also need to configure reporting for the _Battery Percentage Remaining_ attribute 0x0021);
  • From the client _On/Off_ and _Level Control_ clusters to the associated group (which will be reported as config.group once the switch will be supported), to control the lights in that group, even when deCONZ is not running.

Once supported, the REST API plugin should setup these bindings on the switch. Sometimes this fails, and manually creating the bindings fixes this.

After a few minutes, the Button goes in "deep sleep". It is not available in deCONZ and it's not possible to wake up it by pressing the button for a short or long period.

I've seen other switches (Tr氓dfri) hibernate when no appropriate bindings have been setup.

All 40 comments

Hm, it looks like a ZigBee 3.0 version of the Hue dimmer switch, with both endpoints combined. I see they have an EU version of this new switch as well (may only different wall plate?), but none of my regular webshops carry that (yet?).

Whitelisting the device is simple, the trick will be to find out if it reports the buttons on the server 0xfc00 cluster (like the Hue dimmer when paired with the Hue bridge), on the client _On/Off_ and _Level Control_ clusters (like the Hue dimmer switch when paired directly to a light), or maybe both (with some magic setting of 0x0000/0x0031). We'd probably need a sniffer log of the device being paired to a Hue bridge.

If you have a Hue bridge: could you please list the REST API resource(s) it creates for the switch? I asked the same question in the Hue developer's forum.

Thank you for your quick reply.

Here is the info from the bridge:

"87": {
    "state": {
        "buttonevent": 1002,
        "lastupdated": "2019-11-16T11:48:24"
    },
    "swupdate": {
        "state": "noupdates",
        "lastinstall": "2019-11-16T10:54:58"
    },
    "config": {
        "on": true,
        "battery": 100,
        "reachable": true,
        "pending": []
    },
    "name": "Hue Smart button 2",
    "type": "ZLLSwitch",
    "modelid": "ROM001",
    "manufacturername": "Philips",
    "productname": "Hue Smart button",
    "diversityid": "8b18a40c-eb6a-40d7-a0af-eb0906613d41",
    "swversion": "2.21.0_r29784",
    "uniqueid": "00:17:88:01:06:06:81:5c-01-fc00",
    "capabilities": {
        "certified": true,
        "primary": true,
        "inputs": [
            {
                "repeatintervals": [
                    800
                ],
                "events": [
                    {
                        "buttonevent": 1000,
                        "eventtype": "initial_press"
                    },
                    {
                        "buttonevent": 1001,
                        "eventtype": "repeat"
                    },
                    {
                        "buttonevent": 1002,
                        "eventtype": "short_release"
                    },
                    {
                        "buttonevent": 1003,
                        "eventtype": "long_release"
                    }
                ]
            }
        ]
    }
}

It looks like that additionnal virtual sensors are created to maintain the different states:

"82": {
    "state": {
        "status": 1,
        "lastupdated": "none"
    },
    "config": {
        "on": true,
        "reachable": true
    },
    "name": "dimDirection",
    "type": "CLIPGenericStatus",
    "modelid": "HUELABSENUM",
    "manufacturername": "Philips",
    "swversion": "1.0",
    "uniqueid": "2:10:9237-6fb7-4329-9315",
    "recycle": true
},
"83": {
    "state": {
        "status": 1,
        "lastupdated": "none"
    },
    "config": {
        "on": true,
        "reachable": true
    },
    "name": "isDimming",
    "type": "CLIPGenericStatus",
    "modelid": "HUELABSENUM",
    "manufacturername": "Philips",
    "swversion": "1.0",
    "uniqueid": "2:11:9cc2-2e04-4b05-9e3b",
    "recycle": true
},
"84": {
    "state": {
        "status": 0,
        "lastupdated": "none"
    },
    "config": {
        "on": true,
        "reachable": true
    },
    "name": "slotState",
    "type": "CLIPGenericStatus",
    "modelid": "HUELABSENUM",
    "manufacturername": "Philips",
    "swversion": "1.0",
    "uniqueid": "0:12:496a-10d7-46fa-936c",
    "recycle": true
},
"85": {
    "state": {
        "status": 1,
        "lastupdated": "none"
    },
    "config": {
        "on": true,
        "reachable": true
    },
    "name": "cycling",
    "type": "CLIPGenericStatus",
    "modelid": "HUELABSENUM",
    "manufacturername": "Philips",
    "swversion": "1.0",
    "uniqueid": "3:13:d595-91ab-439a-ad81",
    "recycle": true
},

Here is the info from the bridge:

Thanks, that's very useful. Looking at the uniqueid it reports the buttonevent values on cluster 0xfc00. I'll see if I can whitelist the sensor and re-use the logic for the Hue dimmer switch.

Could you try and (in deCONZ) create a group, add a light to that group, and then bind the client _On/Off_ cluster to that group? With luck, the switch should be able to control the light directly, without help from the gateway.

It looks like that additionnal virtual sensors are created to maintain the different states:

Yes, these are created by the Hue labs formulae. You'll probably find matching rules and resourcelinks. Getting Hue labs (and more generally, the Hue app) to run on deCONZ is a different story (much related to API differences for groups and scenes).

Can you explain me how to "bind the client On/Off cluster to that group"?

I am not sure how to do this since I usually don't do it with deCONZ directly.

I am using Hass.io with Phoscon and deCONZ. The Smart Button is not appearing yet as a switch in Phoscon.
I paired my Philips Hue Dimmer to a Test group (n掳3) in Phoscon, with key bindings and it works properly.

I found the "Bind Dropbox" panel and tried the following:
image

I tried with of the clusters of the Smart Button, it's not switching the smart plug but it may be interesting to know that there is a LED feedback of the button with FC00 cluster. After a bind, first click gives a solid red for 2 seconds, then each push gives a short green light feedback. The short green flash feedback is the default behavior when using the Hue hub.

Edit: I tried with the On/Off cluster and with Group "3".
Edit 2: I tried to bind On/Off cluster of the Dimmer Switch with the On/Off cluster of the Smart Plug and it works properly. I just don't have such "On/Off" cluster for the Smart Button.
image

There is another "issue". After a few minutes, the Button goes in "deep sleep". It is not available in deCONZ and it's not possible to wake up it by pressing the button for a short or long period. A reset is mandatory and a new pairing must be done.

Clusters come in pairs:

  • The device being controlled implements the server (blue) cluster;
  • The controlling device implements the client (grey) cluster.

A binding tells a device (_Source_) where (_Destination_) to send messages associated with the cluster:

  • Either a (list of) unicast(s) to (an)other device(s), where you specify the IEEE address and endpoint by dragging and dropping the endpoint (not the cluster);
  • Or a groupcast, where you specify the group ID, by selecting the radio button and edit the group id in hex.

There's nothing magical about a binding, its just a configuration on the source device. Unfortunately, the deCONZ GUI doesn't support querying the binding table, so there's no easy way to check bindings. Most devices have limited (non-volatile) memory for the binding table, so a single binding to a group is preferred over multiple bindings to individual devices.

Now here's the tricky part:

  • Client clusters send commands to the associated server cluster. Typically you want to use a groupcast message for these, so you'd create a binding from a client (grey) cluster to a group;
  • Server clusters send notifications (reports) about their (changed) state. Typically you want a unicast message for these, so you'd create a binding from a server (blue) cluster to (typically) the coordinator (RaspBee/ConBee).

Now here's the really tricky part:

  • A physical device typically implements multiple functions (clusters) and might be the controller for one function and, at the same time, the controlled device for another function. This is actually the case for the Hue dimmer (and, I assume, the smart button), see below;
  • The same logical function might be implemented differently by different devices. Typically Hue and Xiaomi devices act as controlled devices, sending notifications to the bridge/gateway, whereas Tr氓dfri and most other devices act as controllers, sending commands to (a group of) lights. In other words: Xiaomi switches behave like sensors and the Tr氓dfri motion sensors behave like wireless switches. The device type might give a clue, but better check the clusters to be sure.

Now here's the really, really tricky part: The Hue dimmer and, I assume, the Hue smart button are hybrids:

  • When paired with the Hue bridge, they act as a sensor, sending notifications about the buttonevent to the bridge.
  • When used standalone, they act as wireless switch, sending commands to the bound (group of) lights.

This is reflected well by device types on the Hue dimmer endpoints: _Non color scene controller_ on endpoint 0x01 (with the client _On/Off_ and _Level control_ clusters) vs _Simple sensor_ on endpoint 0x02 (with the server 0xfc00 cluster).

So you need the following bindings for the Hue dimmer and, I assume, the Hue smart button:

  • From the server 0xfc00 cluster to endpoint 0x01 of the ConBee/RaspBee, so that the switch sends buttonevent notifications to the gateway;
  • From the server _Power Configuration_ cluster to endpoint 0x01 of the ConBee/RaspBee, so that the switch sends battery reports to the gateway (you also need to configure reporting for the _Battery Percentage Remaining_ attribute 0x0021);
  • From the client _On/Off_ and _Level Control_ clusters to the associated group (which will be reported as config.group once the switch will be supported), to control the lights in that group, even when deCONZ is not running.

Once supported, the REST API plugin should setup these bindings on the switch. Sometimes this fails, and manually creating the bindings fixes this.

After a few minutes, the Button goes in "deep sleep". It is not available in deCONZ and it's not possible to wake up it by pressing the button for a short or long period.

I've seen other switches (Tr氓dfri) hibernate when no appropriate bindings have been setup.

Hi,

I would like to vote for this device request as well. I picked up a switch today, but couldn't make it properly work.

Br, Botond

Hi, I have this new smart button as well.

With home-assistant I am able to configure the button using
zigpy-deconz and then detect the button presses, (both long and
short). I've also been able to automate on/off behavior in
home-assistant by matching the ZHA events in a simple automation
script.

I patched deconz-rest-plugin to attempt to add support for the smart button,
see the enclosed patched. With the patch, the deconz gui now shows
the zigbee device with the name "ROM001 2" however I still cannot get
the device to be detected thru phoscon. I wonder what else needs to
be done to make this work with deconz?
diffs.txt

@ebaauw : Thank you so much for taking the time to explain it. Really appreciated. 馃憤

@b-cole : Thank you for the patch and good job! 馃帀 Does the device have to be visible in Phoscon to be visible in HA? Or getting it recognized by deconz is enough to get the events in HA? From what I saw in other issues, the support for the device in Phoscon may require an update from @manup . It would be so great if Phoscon was open source to get pull requests from the community. 馃槃

@b-cole, cool can you please make a PR for the patch? I have a hue button here for testing (sadly still in the package). For the next release it can be made visible at least in the Phoscon App switches list, with a proper integration wizard and Phoscon App switch editor support following later on.

Any update on this? Thank you in advance for the support.

Hi Mincka,
I managed to get the short press reading in fhem by using the patch from b-cole.
Wolf

Thank you for the confirmation @derwolfk

I think it's a bit complicated for me to patch it manually since I use Hassio and the Deconz integration (with the Docker image). I think I would have to access the container, install the dev package and recompile it. Still, it would be ephemeral. That's why I hope for an integration in deconz-rest-plugin so the Docker image that relies on the precompiled binaries will benefit from the update.

any news on this? I'm having a real bad time to follow the developments on Deconz since the release pages have no updates since .71 release back in November... :(

Hoping for Smart Button support to be added to deConz also.
Do you need more info? Is there something we can help with?

This issue tracker is a bit inconclusive on whether a solution was ever found

It adds to the confusion the fact that the last 3 releases have no changelog.

I don't have the smart button myself, so cannot test, but I'll try to add support cf. the Hue dimmer switch.

@ebaauw Is there a way I could ship you one from UK, for testing?

Or maybe an Amazon code or Paypal so you can order one?

Sure. The _contribute_ shield on homebridge-hue should link to my Paypal account. It's still hard to get here in the Netherlands, but I can order it from store.meethue.com for EUR 25 (incl. delivery). If it's cheaper to send from the UK, please contact me by email for my address.

@ ebaauw Awesome! Paypal on it's way :-)

Cool, thank you. Ordered the button right away. Will report back here when I'll receive it.

Above commit should add support for the smart button. It's quite a sophisticated device, so I expect to have made some errors and/or overlooked something. Of course, I'll test when I'll have received the button, but if some-one feels like testing in the meantime:

  • Please list the ZHASwitch /sensors resource created for the smart button;
  • Please check that you receive buttonevents 1000, 1001, 1002, 1003 for press, hold, release, long release;
  • Please check that the button reports how long it's been pressed through state.eventduration (my latest addition for the dimmer switch);
  • Please check that config.battery gets populated (should be after 5 minutes or so);
  • Please check that config.group gets populated (after pressing the button);
  • Please check that button indeed controls lights added to that group. I'm not quite sure what commands the button will be sending, though; maybe the _Scenes_ cluster needs to be bound to the group as well.

Above commit should add support for the smart button

How to install this commit? When will be the next release including this Huw Button Commit?

Received the button, paired it to deCONZ: resource is created, but no button events. In the deCONZ log, I see commands from the client clusters (causing config.group to be exposed), but nothing from 0xfc00.

Time to activate the sniffer.

The pairing sequence with the Hue bridge is very similar to that of the Lutron Aurora (see https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2305#issuecomment-584330969). It starts with the usual descriptor requests and reading of the _Basic_ attributes. Then a series of 0x82 commands to cluster 0xfc00, but with a different payload than to the Aurora. The button responds with 0x83 commands on the same cluster. The sniffer didn't capture all of them, I'm afraid. Next, the writing of 0x0000/0x0031 with 0x000b, the bindings for 0xfc00 and 0x0001 and the attribute reporting for 0x0001/0x0021 (battery percentage): 900/900/2. Next the reading of unsupported attributes 0x0000/0x0033 and 0x0032.

On button actions the button sends command 0x00 from 0xfc00, with the same payload as the Aurora. As with the Aurora, I see no commands from the client clusters, so no hybrid mode like the Hue dimmer.

Now receiving button events, incl. the eventduration! Not sure exactly what I've done to make the button change behaviour; I reset the button, paired it to deCONZ, ran my little deconz-cli-plugin script to replay the Aurora setup, bound the 0xfc00 cluster (tried to delete the binding first: no entry?!) and voil脿... button events.

Sounds promising! How did you pair it to deConz, I couldn't even get mine paired?

Im just using Phoscon running under Home Assistant at the moment. Should I be using something else, or does Phoscon automatically rely on the REST api to do its work?

I first paired it to the Hue bridge, straight out of the box, without any issues. The bridge upgraded the firmware (as I expected/hoped) to 2.30.0_r30777 (released late December). I removed it from the bridge using the app, but it wouldn't blink (indicating it's ready for pairing). So I opened the back and pressed the reset button for 10 seconds. After that it would pair.

I have a feeling there might also be some pairing issues with deCONZ or the REST API plugin, but I cannot put my finger on it. To retest, I reset the button again, and tried to re-pair it. No joy, even after several resets. I then removed the deconz-cli-plugin, restarted deCONZ and now the switch would pair. Once it's found in the GUI, the REST API resource gets created without fail, but it seems the REST API plugin doesn't setup the binding for the 0xFC00 cluster. After binding it manually, I see the button events (no need to replay the 0x82/0x83 setup sequence).

I now have it sending both 0xFC00 commands and _On/Off_ / _Level Control_ commands: hybrid mode! Not sure how, though, but at least we know it's possible.

On short release the button alternates between sending _On_ and _Off_; on hold it sends a _Step_ of 30 with a transitiontime of 0.9 seconds, alternative (per press/hold/long release sequence) between _Up_ and _Down_. It picks its own group and reports that through _Get Group Identifiers_ on the _ZLL Commissioning cluster. Unlike the Aurora, that doesn't support this command.

Is support likely to be added into Phoscon once it's working, or are you not associated with that project?

I'm a little confused on whether I am even using the REST API plugin right now
Im using Home Assistant with its deConz add-on, which also exposes the Phoscon GUI

WIth above PR, the Hue smart button is fully supported in the REST API; button events as well as directly controlling lights through the associated group.

There was quite some ancient and even dead code for the Hue dimmer switch. I refactored it to the latest patterns for ZB3 devices and uniform handling of the Hue dimmer and the Hue smart button.

I'm a little confused on whether I am even using the REST API plugin right now

You are; (web) apps (like Phoscon) and plugins for home automation systems connect to deCONZ through the REST API.

Is support likely to be added into Phoscon once it's working, or are you not associated with that project?

That's not an open source project, so it's up to dresden elektronik.

@ebaauw Thanks for the explanation. I had assumed this was an official dresden-electronik repo, and so you were involved in the development of Phoscon too.

I will start digging into accessing the REST API directly from Home Assistant, and perhaps find a way to avoid using Phoscon altogether.

I hardly ever use Phoscon. I control my devices from HomeKit using homebridge-hue. I've created the rules in deCONZ using scripts, that interact directly with the API thru ph.

Hi!
The Deconz addon for HA has just been updated to V2.05.75.

I am very happy to confirm that I was able to pair the button and get the events in HA.
I used Phoscon and enabled the pairing in Switches, type Other.

I unpaired the Hue button from the bridge and reset it with the button near the battery (held for 10 seconds, till the light blinks with all the colors).

Nothing will appear in Phoscon but I was confident that the button was paired when I got the green light feedback on click.

I can confirm the events and the delay of 800 ms between repeat:

"events": [
    {
        "buttonevent": 1000,
        "eventtype": "initial_press"
    },
    {
        "buttonevent": 1001,
        "eventtype": "repeat"
    },
    {
        "buttonevent": 1002,
        "eventtype": "short_release"
    },
    {
        "buttonevent": 1003,
        "eventtype": "long_release"
    }
]

Very good job to everyone! 馃帀 Thanks @ebaauw @manup @carpii (for the donation) @stickpin (for the add-on update in HA)

Not sure why but after playing a bit with the button (almost 1000 events... with short, long, very long presses), I get two green blinks instead of one for a single push and release. Do you have the same behavior @ebaauw ? I am going to reset it again. I don't think it was like this just after the pairing. Sometimes, during a long press sequence, I get intermittent 1002/1000 events between the 1001s.

@Mincka I'm seeing this too. It blinks on button press, then button release.
For button hold it continues blinking (but doesn't necessarily blink once more on release)

I have the events coming into Home Assistant, but not yet sure how to trigger an automation based on it

I didn't really look at the led before, but indeed, two green blinks on press/release. I take it, it doesn't do that when connected to the Hue bridge?
I would guess it's because deCONZ puts the button in hybrid mode, controlling lights directly trough it's associated group, and reporting the event to the coordinator.

I get intermittent 1002/1000 events between the 1001s.

I would expect to see a 1003/1000 before any 1002/1000. It does seem possible for the button to register intermittent contact while holding it, not pressing too hard (but still hard enough to prevent the button from "popping"). E.g. below, I managed to get three presses within 0.1 second. The wrong order is probably due to deCONZ handling events asynchronously (I didn't have the sniffer active to confirm).

Mar 10 21:24:23 pi1 dc_eventlog[783]: /sensors/2/state: {"buttonevent":1000,"eventduration":0,"lastupdated":"2020-03-10T20:24:23"}
Mar 10 21:24:23 pi1 dc_eventlog[783]: /sensors/2/state: {"buttonevent":1002,"lastupdated":"2020-03-10T20:24:23"}
Mar 10 21:24:23 pi1 dc_eventlog[783]: /sensors/2/state: {"buttonevent":1002,"lastupdated":"2020-03-10T20:24:23"}
Mar 10 21:24:23 pi1 dc_eventlog[783]: /sensors/2/state: {"buttonevent":1000,"lastupdated":"2020-03-10T20:24:23"}
Mar 10 21:24:23 pi1 dc_eventlog[783]: /sensors/2/state: {"buttonevent":1000,"lastupdated":"2020-03-10T20:24:23"}
Mar 10 21:24:24 pi1 dc_eventlog[783]: /sensors/2/state: {"buttonevent":1001,"eventduration":8,"lastupdated":"2020-03-10T20:24:24"}
Mar 10 21:24:24 pi1 dc_eventlog[783]: /sensors/2/state: {"buttonevent":1003,"eventduration":14,"lastupdated":"2020-03-10T20:24:24"}

I have the events coming into Home Assistant, but not yet sure how to trigger an automation based on it

- id: '1581172155087'
  alias: Turn on Julien's lamp
  description: ''
  trigger:
  - event_data:
      event: 1002
      id: rom001_29
    event_type: deconz_event
    platform: event
  condition: []
  action:
  - device_id: 8a2b486817a4476aab4813eb01630755
    domain: light
    entity_id: light.julien
    type: turn_on

@Mincka Thanks, that's very helpful
I wasn't quite sure how to structure the event data in the trigger condition, but all working now

@ebaauw, thanks too, for your great work in adding support for this

I don't know why the Hue Button is not working in Phoscon? I have the newest Gateway Version, newest RaspBee Version and newest Button Version updated with Hue Bridge. Pairing is working in GUI, but 0xFC00 cluster is unknown. In Phoscon the button is not showing up.
Can anybody tell me how to pair it into Phoscon?

0xFC00 cluster is unknown

That's normal. I could add it to general.xml, so the GUI would display a name, but the cluster has nothing to expose in the _Cluster Info_ panel.

Can anybody tell me how to pair it into Phoscon?

dresden elektronik needs to add support for the button in Phoscon first.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

stevenwfoley picture stevenwfoley  路  3Comments

salopette picture salopette  路  4Comments

philko123 picture philko123  路  3Comments

lynix picture lynix  路  4Comments

flex-0 picture flex-0  路  4Comments