Deleted Post

I have now tested this out for myself. Having written all that stuff earlier, I found that could receive a button push event just fine, even with ‘stateChangeOnly = true’. That was using the ‘main’ component.

1 Like

Hello @anon19023406,

Please see below the code snippet to create the subscriptions and print the events when they are received.

// SmartApp init
const testSmartApp = new SmartApp();

// SmartApp definition
testSmartApp.appId('SmartApp example')
  // Uncomment to check logs.
  // .enableEventLogging(2)
  .disableCustomDisplayName(true)
  .permissions(['r:devices:*', 'r:locations:*'])
  .page('mainPage', (ctx, page, configData) => {
    page.complete(true)
      .name('Button monitor')
    // Devices input section
    page.section('Button devices:', section => {
      section.deviceSetting('buttonDevices')
        .name('')
        .description('Tap to select')
        .capabilities(['button'])
        .required(true)
        .multiple(true)
        .permissions('rx')
    })
  })
  .updated(async (context, updateData) => {
    // Clear subscription to avoid duplication
    await context.api.subscriptions.unsubscribeAll();
    // Create/Update subscriptions
    await context.api.subscriptions.subscribeToDevices(
      context.config.buttonDevices, '*', '*', 'buttonSubscription'
    );
  })
  .subscribedDeviceEventHandler('buttonSubscription', async (context, event) => {
    console.log(event);
  });

Please note it is created using the SmartThings NodeJS SDK.

Let us know if you have any questions.

I had a suspicion that was what you might be using. I’ll try with one of those in the morning. I only started playing with the Webhook Endpoint apps yesterday so I am on a learning curve. I’m also using PHP and doing it all from scratch as I just prefer good old procedural programming …

1 Like

OK …

The Ikea On/Off buttons (known as Wireless Dimmers if you are reading the catalogue instead of the back of the button) are implemented as a component device. The ‘main’ component has both the ‘Button’ and the long since deprecated ‘Holdable Button’ capability which share the same ‘button’ attribute. The ‘button1’ and ‘button2’ components likewise have the ‘Button’ and ‘Holdable Button’ capabilities. The ‘main’ component, the parent device, implements the old style handling of multiple buttons where a ‘buttonNumber’ is added to the event data (the same trick gets used for multiple presses and things in older handlers and apps).

I authorised an Ikea button using just the parent/main component, choosing just read permissions, and used wildcards to subscribe to it to see what turned up (I chose to do this in the UPDATE lifecycle):

{
    "sourceType": "DEVICE",
    "device": {
        "deviceId": "UUID",
        "componentId": "*",
        "capability": "*",
        "attribute": "*",
        "value": "*"
    }
}

Reading back the subscriptions gave me (redacted and slightly trimmed top and bottom):

       {
            "id": "UUID",
            "installedAppId": "UUID",
            "sourceType": "DEVICE",
            "device": {
                "deviceId": "UUID",
                "componentId": "main",
                "capability": "*",
                "attribute": "*",
                "value": "*",
                "stateChangeOnly": true,
                "modes": []
            }
        }

I then pressed a button, and got SIX events returned, which I logged (in the form: ‘component capability attribute value’ as:

[10-Jun-2020 10:20:57 Europe/London] button2 holdableButton button pushed
[10-Jun-2020 10:20:57 Europe/London] button2 button button pushed
[10-Jun-2020 10:20:57 Europe/London] main button button pushed
[10-Jun-2020 10:20:57 Europe/London] main button button pushed
[10-Jun-2020 10:20:57 Europe/London] main holdableButton button pushed
[10-Jun-2020 10:20:57 Europe/London] main holdableButton button pushed

I imagine ‘button’ and ‘holdableButton’ turn into two events because they share the same attribute name. I don’t really know what ‘holdableButton’ is even doing in the device handler.

I am not entirely sure why all the ‘main’ events double up. From what I can see they are pretty useless anyway as the event doesn’t seem to carry the ‘buttonNumber’ data.

A trimmed and redacted sample of the event data received is:

{
    "lifecycle": "EVENT",
    [ ... SNIP ...[
    "eventData": {
        "AuthToken": "REALLY LONG TOKEN"
        "installedApp": {
            "installedAppId": "UUID",
            "locationId": "UUID",
            "config": {
                "thebutton": [
                    {
                        "valueType": "DEVICE",
                        "deviceConfig": {
                            "deviceId": 'UUID",
                            "componentId": "main"
                        }
                    }
                ]
            }
            "permissions": [
                "R: devices: UUID"
            ]
        }
        "events": [
            {
                "eventTime": "2020-06-10T09: 20: 57Z",
                "eventType": "DEVICE_EVENT",
                "deviceEvent": {
                    "eventId": "UUID",
                    "locationId": "UUID",
                    "deviceId": "UUID",
                    "componentId": "main",
                    "capability": "holdableButton",
                    "attribute": "button",
                    "value": "pushed",
                    "valueType": "string",
                    "stateChange": true,
                    "date": [],
                    "subscriptionName": "UUID"
                }
            }
        ]
    }
    "settings": []
}

Having seen all that, I then changed to using two individual subscription requests for just the components of the buttons, using the form:

{
    "sourceType": "DEVICE",
    "device": {
        "deviceId": "UUID",
        "componentId": "button2",
        "capability": "button",
        "attribute": "button",
        "value": "*"
    }
}

That cleans things up rather nicely, as here are the events from pressing and holding both buttons:

[10-Jun-2020 10:38:13 Europe/London] button1 button button pushed
[10-Jun-2020 10:38:18 Europe/London] button2 button button pushed
[10-Jun-2020 10:38:22 Europe/London] button1 button button held
[10-Jun-2020 10:38:26 Europe/London] button2 button button held

Here is a clip of the received data for the last one of those:

        "events": [
            {
                "eventTime": "2020-06-10T09:38:26Z",
                "eventType": "DEVICE_EVENT",
                "deviceEvent": {
                    "eventId": "UUID",
                    "locationId": "UUID",
                    "deviceId": "UUID",
                    "componentId": "button2",
                    "capability": "button",
                    "attribute": "button",
                    "value": "held",
                    "valueType": "string",
                    "stateChange": true,
                    "data": [],
                    "subscriptionName": "UUID"
                }
            }

I am still pondering ‘stateChangeOnly’. I think on reflection it must be plumbed in earlier than I imagined and be respecting the device handlers declaring the button presses as state changes.

2 Likes

I think I have solved the problem! Or rather “understand it better”!

So it wasn’t the JS code, and it wasn’t the way I was using the REST API.

Here is the investigation, pruned of all the fruitless diversionary paths:

  1. In desperation, I decided to start all over again. Factory reset my IKEA button (4 quick presses on the pairing button under the back cover), removed all trace of the button from Smartthings, including apps and automations which may have referred to it.

  2. Paired the button with the hub in accordance with the instructions on the app (4 quick presses on the pairing button, while the hub was searching for it). Success! Button tile appears on App.

  3. Pressed a button. Something I don’t think I’d seen before - the tile status text changed from “standby” to “pressed” and back to “standby”!

  4. Installed and configured my testing SmartApp and started receiving events! Problem solved!

So it must have lost it’s pairing with the hub, although the app was still showing the tile, allowing me to create automations based on it, and allowing me to refer to it in SmartApp and REST API calls…But the fact that the system knew about the button was evidence was that it must have been paired at some stage. So how can it lose it’s pairing? Then I realised I hadn’t finished restoring my setup to it’s previous state. I hadn’t paired it with my IKEA light.

  1. Followed the instructions according to IKEA. Held the button near the light and held the pairing button down until the light dimmed and brightened to acknowledge. Success. Can now control the light with the button.

  2. Went back to Smartthings. No more events triggered. No more response from the button tile. Problem replicated!

Now before all the defenders of the faith leap to Smartthings defence, and say “you unpaired it! That’s why it won’t talk to Smartthings again”, I would make the following points:

a. I didn’t unpair it. According to IKEA a button (steering device) is capable of talking to more than one device. 4 quick presses on the paring button resets all pairing. A long press requests to add a pairing.

b. Zigbee NWK layer fully supports multiple destinations.

c. Why does Smartthings ask for a reset of the button as part of the pairing? In doing so, it is requiring that the button is removed from all existing pairings (so much for interoperability).

d) Question for both IKEA and Smartthings: when adding a pairing to a new light, why does it lose it’s pairing with the hub?

e) Definitely one for Smartthings developers: Why does the dead body of an unpaired button still show in the system long after it’s gone? If a light is powered off or unreachable, it comes up as offline. Why isn’t there any indication that a button hasn’t been heard from for a few months? Instead it still allows me to define it in my Automations and SmartApps, and shows the battery level at 37% (what happens when the battery is dead? Or removed?)

Nothing’s perfect, of course, so I thought I’d try to work with the known limitations. Immediate problem, if I still want it to control a light I’ll probably have to forget about the press-n-hold dimming, and accept that my lighting will only respond a second or so after a round trip to Europe.

Still, it’s allowed me to press on with my evaluation, and I must admit it raises some more questions, which should be the subject of new threads.

Because that’s the way it’s designed. You stopped using the remote to send messages through the hub and started using it to send them directly to the bulbs. That method is really intended for ZLL networks, not Zigbee 3.0, that is networks where there isn’t a hub at all.

Based on what @GSzabados Reported in one of your other threads, it sounds like the issue is specific to the two button model and that when you go to do the groupcast binding it is switching from a ZHA profile to a ZLL profile, where the remote assumes there isn’t a hub at all.

If you want to use the button with the hub, you should be using the hub to handle the messaging to the bulbs. If you want to just use the button as a parallel means of control, then you can bind the individual bulbs to the button. Just be aware that smartthings doesn’t tend to maintain this kind of binding very well and you may have to reset every once in a while.

You can contact IKEA and ask them if the two button device is going to be upgraded to Zigbee 3.0. That might help solve the problem. There’s nothing you can do about it from the smartthings side if it’s using an incompatible profile.

I’ll admit, seeing the exact same question in what is now four different threads this morning has physically exhausted me. I can’t keep track of what conversations are happening where. (Remember I have to do everything in my head since I rely on text to speech.) So I’m going to leave this discussion at this point and you can carry-on with other folks.

2 Likes

This is not working with the Dimmer/2 button device. The way how it pairs to the bulb changes the group assignment, I guess. Meanwhile the 5 button remote is capable to pair to the bulb and keep connected to SmartThings. Indeed the Dimmer keeps connected to SmartThings as well as battery reporting still goes through, and that makes me believe that the TouchLink pairing changes the group assignment.

And as @JDRoberts wrote, please stop making multiple threads about the same device/issue. It just makes complicated everything.
Your approach to the issue is like riding a horse sitting backward. You should have tried first how the devices are working before starting to bombard support and the forum with an Armada of topics and emails about a SmartApp what wouldn’t work due to your device set up and the current limitations (I use limitation, but it is really a feature what you are trying to use) of the system.

2 Likes

Also, please give the model number of your button. IKEA has released a number of different handheld remotes over the last two years, and they have different functionality.

Originally, the plug-in pocket socket was sold in a “kit“ with a two button remote. That one could detect pressed or held. It did not send setlevel, so it could not be used for dimming. But because it could distinguish between press and long press, you actually got four functions out of the two button remote.

Then there was a dimmer which you could spin.

And in the last 12 months they have released two new devices. One is a button that does do setlevel, so it can be used for dimming.

And the newest one is a “shortcut“ button.

So which one do you have and which DTH are you using for it?

This forum was set up many years ago, before the Samsung acquisition, So that customers could help other customers with ideas and projects. It is not an official support channel.

99% of the people posting here are just other customers, and we are all doing the best we can to help each other.

(There are a few staff members who post here from time to time, and we are grateful for their participation, but that’s not really what the forum is for. Their profiles will identify them as staff members.)

With regards to the official materials, warranty support, or refunds, you would need to go through an official support channel

UK:

https://support.smartthings.com/hc/en-gb

US:

https://support.smartthings.com/hc/en-us

You can use the search in the top and you would have a lot of answers. This is a community forum, not an official documentation.

The on/off switch works as a button with SmartThings and you can assigne actions to the press, held functions for each (top/bottom) buttons as well.

And if you would spend 15 pound on the 5 button remote, then you could do what you wanted to do at the first place as that one works like that.

FYI, the motion sensor would leave you, the developer, fool, as well, by it’s dead body, if you pair it with the long press to a bulb.

Sigh.

I use voice reader software. You could at least give a post number. I’m not going to go through and listen again to all the posts in this thread hoping to find the model number. If you can’t help us to help you, there just isn’t a lot we can do.

From one of your posts today, I’m sorry I don’t remember exactly where it was, it really sounds like you were looking for a developer platform. Smartthings isn’t that.

Check out Home Assistant, Hubitat, and Insteon. They are likely to be better candidates for what you’re looking for.

1 Like

You are right that the IKEA Type E1743 TRADFRI ON/OFF SWITCH does not support dimming in the ‘setlevel’ sense. It uses the ONOFF_CLUSTER (values 0 and 1) for ‘pushed’ on the two buttons, and the LEVEL_CONTROL_CLUSTER (1 and 5) for ‘held’ on the two buttons.

However the ‘IKEA TRADFRI Wireless Dimmer’ IS the E1743 TRADFRI ON/OFF SWITCH, or at least it is in the UK. So it doesn’t really dim either. It is just branded as a dimmer, presumably using presets when using the IKEA ‘gateway’.

1 Like

Thanks! Very confusing!

It doesn’t help that the device handler sets the ‘deviceJoinName’ to ‘IKEA Remote Control’ for all three of the models it supports, especially when one of them (the round five button thing) is actually called the ‘Remote Control’.

1 Like

It does dimming when paired to the bulbs, by holding the on or off button. Or I have misunderstood your sentence.

I was referring to its interaction with the SmartThings device handler. What it does when paired to bulbs seems to be something different.

2 Likes

I bought the Shortcut Button E1812 recently, but it’s removed from the Ikea website.

It’s a single button pushbutton, waterresistant IP44, so it can be used near the frontdoor to switch on/off lights.

Added it to SmartThings hub v2, but no functionality like the battery level is 0%.

Text from Ikea (Google is my friends)

IMPORTANT NOTE:
The TRÅDFRI shortcut button works only in
conjunction with TRÅDFRI gateway and you cannot
add IKEA Home smart products directly to your
shortcut button.

Here about the single square Shortcut Button E1812, howto pair.

I tried to scan for the device, nothing, pressed 4x, pressed 10 seconds, didn’t pair.

Then I removed the battery to reset the device and I noticed from the rear a small red LED flashing inside when I reinstalled the battery.

When you turn over the button, the screw at the lower side, the LED is at the upper righthand frontside.

Pressing 4 times fast at the pair button, the red light starts to blink.

Now I went to the Device, Brand, Ikea, Button, Ikea Button and started paring. Pushed 4x fast on the pair button and voila, the button paired.

Still working on Battery level and Push, no result.

Grtn Ben

Other link, about the Shortcut Button E1812

Change the driver to Zigbee Button. The battery level and the push on, push off work.