“holdRelease” expression does not seem to do anything

didu · 2020-02-16 17:50:58 UTC

1) Give a description of the problem
In an (modified) example piston the “holdRelease” expression does not seem to change the variables which in turn should stop the dimming (up or down) cycle. Any idea what is wrong?

2) What is the expected behaviour?
(PUT YOUR INFO HERE)

3) What is happening/not happening?
(PUT YOUR INFO HERE)

4) Post a Green Snapshot of the piston

5) Attach logs after turning logging level to Full
(PASTE YOUR LOGS HERE THEN HIGHLIGHT ALL OF THE LOGS AND CLICK ON THE </> ICON TO FORMAT THEM CORRECTLY)

REMOVE BELOW AFTER READING
If a solution is found for your question then please mark the post as the solution.

WCmore · 2020-02-16 18:06:12 UTC

Your format on lines 79 & 83 do not match all of the working IF blocks…

To really see what is going on behind the scenes, please turn on Trace, and set logging level to Full … The next time you have an error, please post a fresh green snapshot and errors shown in your log.

didu · 2020-02-16 19:00:57 UTC

Hi,

What to you mean “79 & 83 do not match”?
I switched on Trace and looking at the Logs, but once I push the dim down (1) or up button (3) the async kicks in a keeps cycling. If i push the dim down and up buttons after each other the two cycles keep “fighting” and i see the light dimming up and down rapidly.

To me it obvious that the “holdRelease” never gets registered, but why?

This log is just an example as this keeps repeating infinitely so I have to pause the piston.

2/16/2020, 9:07:12 PM +58ms
+0ms ╔Received event [Home].time = 1581880030357 with a delay of 1700ms
+124ms ║RunTime Analysis CS &gt; 30ms &gt; PS &gt; 35ms &gt; PE &gt; 59ms &gt; CE
+127ms ║Runtime (43609 bytes) successfully initialized in 35ms (v0.3.110.20191009) (126ms)
+128ms ║╔Execution stage started
+154ms ║║Comparison (boolean) true is (boolean) true = true (2ms)
+156ms ║║Condition #74 evaluated true (6ms)
+165ms ║║Condition group #68 evaluated true (state did not change) (15ms)
+167ms ║║Cancelling statement #69's schedules...
+759ms ║║Executed physical command [Hue go].refresh() (588ms)
+760ms ║║Executed [Hue go].refresh (590ms)
+770ms ║║Skipped execution of physical command [Hue go].setLevel([100]) because it would make no change to the device. (4ms)
+771ms ║║Executed virtual command [Hue go].adjustLevel (8ms)
+798ms ║║Executed physical command [Hue go].refresh() (25ms)
+800ms ║║Executed [Hue go].refresh (27ms)
+803ms ║║Executed virtual command [Hue go].wait (1ms)
+804ms ║║Requesting a wake up for Sun, Feb 16 2020 @ 9:07:13 PM EET (in 1.0s)
+809ms ║║Fast executing schedules, waiting for 996ms to sync up
+1830ms ║║Comparison (boolean) true is (boolean) true = true (1ms)
+1831ms ║║Condition #74 evaluated true (5ms)
+1832ms ║║Condition group #68 evaluated true (state did not change) (6ms)
+1834ms ║║Cancelling statement #69's schedules...
+1860ms ║║Executed physical command [Hue go].refresh() (23ms)
+1861ms ║║Executed [Hue go].refresh (25ms)
+1871ms ║║Skipped execution of physical command [Hue go].setLevel([100]) because it would make no change to the device. (4ms)
+1871ms ║║Executed virtual command [Hue go].adjustLevel (7ms)
+1895ms ║║Executed physical command [Hue go].refresh() (22ms)
+1896ms ║║Executed [Hue go].refresh (22ms)
+1899ms ║║Executed virtual command [Hue go].wait (1ms)
+1900ms ║║Requesting a wake up for Sun, Feb 16 2020 @ 9:07:14 PM EET (in 1.0s)
+1905ms ║║Fast executing schedules, waiting for 996ms to sync up
+2925ms ║║Comparison (boolean) true is (boolean) true = true (1ms)
+2927ms ║║Condition #74 evaluated true (5ms)
+2928ms ║║Condition group #68 evaluated true (state did not change) (6ms)
+2930ms ║║Cancelling statement #69's schedules...
+2955ms ║║Executed physical command [Hue go].refresh() (22ms)
+2956ms ║║Executed [Hue go].refresh (24ms)
+2967ms ║║Skipped execution of physical command [Hue go].setLevel([100]) because it would make no change to the device. (5ms)
+2969ms ║║Executed virtual command [Hue go].adjustLevel (10ms)
+3019ms ║║Executed physical command [Hue go].refresh() (46ms)
+3021ms ║║Executed [Hue go].refresh (50ms)
+3026ms ║║Executed virtual command [Hue go].wait (1ms)
+3028ms ║║Requesting a wake up for Sun, Feb 16 2020 @ 9:07:16 PM EET (in 1.0s)
+3034ms ║║Fast executing schedules, waiting for 996ms to sync up
+4057ms ║║Comparison (boolean) true is (boolean) true = true (1ms)
+4059ms ║║Condition #74 evaluated true (5ms)
+4060ms ║║Condition group #68 evaluated true (state did not change) (7ms)
+4063ms ║║Cancelling statement #69's schedules...
+4088ms ║║Executed physical command [Hue go].refresh() (23ms)
+4089ms ║║Executed [Hue go].refresh (25ms)
+4099ms ║║Skipped execution of physical command [Hue go].setLevel([100]) because it would make no change to the device. (4ms)
+4100ms ║║Executed virtual command [Hue go].adjustLevel (8ms)
+4126ms ║║Executed physical command [Hue go].refresh() (24ms)
+4127ms ║║Executed [Hue go].refresh (26ms)
+4130ms ║║Executed virtual command [Hue go].wait (0ms)
+4132ms ║║Requesting a wake up for Sun, Feb 16 2020 @ 9:07:17 PM EET (in 1.0s)
+4137ms ║║Fast executing schedules, waiting for 996ms to sync up
+5158ms ║║Comparison (boolean) true is (boolean) true = true (1ms)
+5159ms ║║Condition #74 evaluated true (5ms)
+5160ms ║║Condition group #68 evaluated true (state did not change) (6ms)
+5163ms ║║Cancelling statement #69's schedules...
+5189ms ║║Executed physical command [Hue go].refresh() (24ms)
+5190ms ║║Executed [Hue go].refresh (26ms)
+5200ms ║║Skipped execution of physical command [Hue go].setLevel([100]) because it would make no change to the device. (5ms)
+5201ms ║║Executed virtual command [Hue go].adjustLevel (8ms)
+5345ms ║║Executed physical command [Hue go].refresh() (142ms)
+5347ms ║║Executed [Hue go].refresh (145ms)
+5352ms ║║Executed virtual command [Hue go].wait (1ms)
+5354ms ║║Requesting a wake up for Sun, Feb 16 2020 @ 9:07:18 PM EET (in 1.0s)
+5361ms ║╚Execution stage complete. (5232ms)
+5362ms ║Setting up scheduled job for Sun, Feb 16 2020 @ 9:07:18 PM EET (in 1s)
+5370ms ╚Event processed successfully (5370ms)
2/16/2020, 9:07:15 PM +603ms
+225ms ╔Stopping piston...
+318ms ╚Piston successfully stopped (93ms)

WCmore · 2020-02-16 19:25:15 UTC

Different format… Line 68 is working, but line 79 is not.

Note: I will not look at your log unless you post a green snapshot with Trace turned on.

orangebucket · 2020-02-16 19:30:59 UTC

The button capability does not define ‘holdRelease’ so it would have to be a custom feature of the button device handler. So does the device handler for your button definitely generate a ‘holdRelease’ event?

WCmore · 2020-02-16 19:43:54 UTC

To add to what @orangebucket said… When testing a new capability, it helps to create a simple (one block) piston to test and get familiar with your device’s capabilities.

IE:

execute
    IF Keypad 6's button #3 gets X
        Then Log to console "Success"
    END IF
end execute

This clears the clutter in the log, and lets you focus on the problem child.

didu · 2020-02-16 20:02:06 UTC

Here is the traced test run.

I have updated so that it uses expressions. It works the same way. On/off works flawlessly, dimming up and down never gets the holdRelease.

didu · 2020-02-16 20:04:38 UTC

It is an Ikea Trådfri 6 button remote which worked without any custom device handler. I was very surprised by this by the way.
Checking the device capabilities it only has “pushed” and “hold”, nothing else.

orangebucket · 2020-02-16 21:41:31 UTC

A variety of values are defined for the ‘button’ attribute in the ‘new’ environment, but they are basically variations on “pushed” and “held”. Unlike most attributes, ‘button’ is used to define the last thing the button did, so a “pushed” or “held” could have happened days ago. Apps that work with buttons know this (the SmartThings app displays ‘standby’ for example). Although there is at least one device handler that adds a “holdRelease” state, that doesn’t seem likely to be terribly robust as SmartThings is a largely cloud based event driven system, not a real time control system.

WCmore · 2020-02-17 01:46:54 UTC

As @orangebucket mentioned, this is common with buttons.

When a button is pressed, if it is released quickly, it acknowledges the ‘push’… If it is held longer than X milliseconds, then it acknowledges the ‘held’.

didu · 2020-02-17 05:53:33 UTC

@orangebucket and @WCmore

I understand these, but I can’t understand how it relates to not getting the holdRelease? It should happen after every hold event, isn’t it?

WCmore · 2020-02-17 10:11:31 UTC

Quick answer:

SmartThings “built-in” Device Handlers are designed to communicate with as many devices as possible. This means any device using it, there is almost a guarantee that some of the code will not work with that particular device.

This is normal, and why I usually suggest really getting familiar with new devices before going all crazy logic. (using a simple testing environment)

Once you know the acceptable commands for that specific device, it makes all future piston building much more streamlined & hassle-free.

Side Note:

If you are unhappy with your device’s test results, that is usually the time to seek out an alternative Device Handler (if one exists). If you use one at random, you may actually loose functionality, but if you find one made for your specific device, then you may have access to many more options.

orangebucket · 2020-02-17 10:58:59 UTC

Should it?

It would require the Tradfri switch to be reporting such a thing. Does it? Some buttons seem to report a release (not necessarily a hold release), some don’t.

It would then require the device handler to recognise such a report. If there is a report to recognise, the Tradfri device handler shows no indication of having done so or wanting to use it.

It would then require the device handler to do something with the report. The button capability only caters for pushed and held events so this is something of a deterrent. The device handler might store information in its local state, or it might use custom attributes, or it might use a non-standard value for an attribute. It might even treat a release as another push but with a different button number. The Tradfri handler doesn’t do any of those things.

You then need an app that can work with custom attributes or that will handle non-standard values.

The only place I’ve come across a ‘holdRelease’ value for the button attribute is in the device handler for a Go Control switch. That doesn’t mean other handlers don’t do it, only that I’m not aware of them.

didu · 2020-02-17 13:40:33 UTC

Thanks @all for the answers. I will implement dimming an other way. Too bad, as the example code was rather elegant, more than mine will be