Hue button - logs for device automation

[tube0013]

Here are the join jogs and zha_events for the Phillips Hue Button that recently came out.

Joining:
https://paste.ubuntu.com/p/MwpyQ4JD7s/

Events
1st single tap:

{
    "event_type": "zha_event",
    "data": {
        "unique_id": "00:17:88:01:06:54:aa:fe:1:0x0006",
        "device_ieee": "00:17:88:01:06:54:aa:fe",
        "endpoint_id": 1,
        "cluster_id": 6,
        "command": "on",
        "args": []
    },
    "origin": "LOCAL",
    "time_fired": "2019-12-10T23:36:56.921176+00:00",
    "context": {
        "id": "254a844669a5414895127a013ef23b6c",
        "parent_id": null,
        "user_id": null
    }
}

2nd single tap:

{
    "event_type": "zha_event",
    "data": {
        "unique_id": "00:17:88:01:06:54:aa:fe:1:0x0006",
        "device_ieee": "00:17:88:01:06:54:aa:fe",
        "endpoint_id": 1,
        "cluster_id": 6,
        "command": "off_with_effect",
        "args": [
            0,
            0
        ]
    },
    "origin": "LOCAL",
    "time_fired": "2019-12-10T23:36:59.457089+00:00",
    "context": {
        "id": "8a2884ad568446828d93f5b7cd5ce559",
        "parent_id": null,
        "user_id": null
    }

Here is a sequence: On > Held for about 9 seconds > Off.
https://paste.ubuntu.com/p/kBbx5dPbxJ/

the Step events seem to fire on average about ever 0.8 seconds.

Here is a sequence of holding after an Off for about 20 seconds... it does not send a stop event when held after in the "off" state:
https://paste.ubuntu.com/p/F75QmMXsDz/

[majkrzak]

I'll dive into it tomorrow.

But If i understand correctly button is not correctly detected. At least in case I was informed about, only battery measurement works. So the point is to let it act as the on/off button.

I might be wrong, I don't have much experience with zigbee yet

P.S. some link
https://community.home-assistant.io/t/does-anyone-know-if-this-will-work/154624/24

[majkrzak]

    signature = {
        #  <SimpleDescriptor endpoint=1 profile=260 device_type=2096
        #  device_version=1
        #  input_clusters=[0, 1, 3, 64512, 4096]
        #  output_clusters=[25, 0, 3, 4, 6, 8, 5, 4096]>
        ENDPOINTS: {
            1: {
                PROFILE_ID: zha.PROFILE_ID,
                DEVICE_TYPE: zha.DeviceType.NON_COLOR_SCENE_CONTROLLER,
                INPUT_CLUSTERS: [
                    Basic.cluster_id,
                    PowerConfiguration.cluster_id,
                    Identify.cluster_id,
                    64512,  # FIXME
                    LightLink.cluster_id
                ],
                OUTPUT_CLUSTERS: [
                    Ota.cluster_id,
                    Basic.cluster_id,
                    Identify.cluster_id,
                    Groups.cluster_id,
                    OnOff.cluster_id,
                    LevelControl.cluster_id,
                    Scenes.cluster_id,
                    LightLink.cluster_id
                ]
            }
        }
    }

I'm a bit confused now. Transcribing simple descriptor shows that there is OnOff cluster reported, so if my intuition is correct it should act as a switch? But Hassio only populates the battery level entity. 🤔

[majkrzak]

@dmulcahey do you know about any documentation regarding this project, especially about device_automation_triggers?

[dmulcahey]

I'm a bit confused now. Transcribing simple descriptor shows that there is OnOff cluster reported, so if my intuition is correct it should act as a switch? But Hassio only populates the battery level entity. 🤔

Nope, it is a scene controller AKA a remote. There should be no entities for this device other than the battery entity.

[dmulcahey]

@dmulcahey do you know about any documentation regarding this project, especially about device_automation_triggers?

So the TLDR; on how device_automation_triggers work is this:

They are essentially representations of the events that allow users to use actions in the UI instead of the raw events. Ex: For the Hue remote - the on button fires this event:

<Event zha_event[L]: unique_id=00:17:88:01:04:e7:f9:37:1:0x0006, device_ieee=00:17:88:01:04:e7:f9:37, endpoint_id=1, cluster_id=6, command=on, args=[]>

and the action defined for this is:

(SHORT_PRESS, TURN_ON): {COMMAND: COMMAND_ON},

The first part (SHORT_PRESS, TURN_ON) corresponds to the txt the user will see in the UI:

The second part is the event data. You only need to supply enough of the event data to uniquely match the event which in this case is just the command for this device: {COMMAND: COMMAND_ON}

If you look at another one for the same device:

(SHORT_PRESS, DIM_UP): {COMMAND: COMMAND_STEP, CLUSTER_ID: 8, ENDPOINT_ID: 1, ARGS: [0, 30, 9],},

you can see a pattern and how to match a more complex event. In this case the step command is used for the dim up and dim down buttons so we need to match more of the event data to uniquely match the event.

[jcallaghan]

Is this related to #388?

[majkrzak]

@jcallaghan for me it looks so (64512 cluster reported), @dmulcahey why did you skipped rom001 in there? 😅

[dmulcahey]

Because it’s a completely different type of device and I don’t have one to test with. The 2 remotes I did are 4 button remotes whereas this is a single button. I’ll poke through other implementations to see if they’re similar. Just FYI, I didn’t add any software based actions, I merely exposed the manufacturer specific hardware generated events. If this device doesn’t do the same thing then there won’t be anything to expose but I’ll certainly look 😀

[dmulcahey]

It looks like it may be able to function similarly based on this: Koenkk/zigbee-herdsman-converters@67762c4

Want to add the custom Philips basic and mfg cluster to replacements and try it? If it works we can then address the triggers.

[majkrzak]

I should be able to look into it at next weekend or some evening. Is there any good way to test it in the live environment (rpi), or I have to set up hassio and zha locally?

[dmulcahey]

If you’re running a venv you can just change the files in the package and restart. If in a container you need to SSH into it and do the same.

[dmulcahey]

I believe these are already in quirks now:

    device_automation_triggers = {
        (SHORT_PRESS, TURN_ON): {COMMAND: COMMAND_ON},
        (SHORT_PRESS, TURN_OFF): {COMMAND: COMMAND_OFF_WITH_EFFECT},
    }

please reopen if I am wrong.

[BenShen98]

Feel bad about commenting on a closed ticket.

But, felt device_automation_triggers should be better documented/elaborated in the Readme::Build a quirk? It took me some digging to find here, felt the process should be easier. And @dmulcahey provide a really good example helping me to understand what this data structure means. (I am happy to do it & submit a pull request, but I'm also a beginner to this framework)