Attribute button only displays `gets` as a trigger

[rboy1]

Possibly a bug, for the button attribute it only shows gets as a trigger. For other attributes it shows a whole host of triggers.

This limits the way the button devices can be used since buttons are often held which means they will continue to show held as the status until they are released and the piston should be able to use the current status of a button in a if condition when triggered by another device.

e.g. keep holding the button which triggers a volume increase which triggers the piston which checks if the button is still held and then increases the volume and this continues in a loop into until the button is released.

Ideally it should show the same triggers as any other attribute (e.g. switch or alarm).

[cscheiene]

+1 to this issue. I have to modify each button DH I want to use with webcore to get all the functions I need

[idpaterson]

I don't have any devices to test this out but if you want to modify the code at account.smartthings.com and test locally I'll gladly review a pull request. The code that controls the trigger is in webcore.groovy.

The conditions and triggers in the selected code specify applicable attribute groups in this format g:"bs" (probably boolean and string). Add the letter corresponding to buttons m (probably momentary) to show a condition or trigger for buttons, e.g. g:"bsm".

Once changes have been made to the code in the SmartThings IDE it can be saved and published. You may see the change in the webCoRE dashboard or it may require refreshing its local database. To trigger a refresh just go to webCoRE in the ST mobile app and tap through Settings > Available devices > Available devices then press Back. The dashboard will reload its database on the next refresh.

[rboy1]

@idpaterson thanks. I tried that and must be missing something. I've added m to some conditions and triggers:

    	conditions: [
        	changed							: [ d: "changed",																	g:"bdfism",						t: 1,	],
        	did_not_change					: [ d: "did not change",															g:"bdfism",						t: 1,	],

        triggers: [
    		gets							: [ d: "gets",																		g:"m",		p: 1						],
			happens_daily_at				: [ d: "happens daily at",															g:"t",		p: 1						],
    		arrives							: [ d: "arrives",																	g:"e",		p: 2						],
    		executes						: [ d: "executes",																	g:"v",		p: 1						],
    		changes 						: [ d: "changes",							dd: "change",							g:"bdfism",								],
    		changes_to 						: [ d: "changes to",						dd: "change to",						g:"bdism",	p: 1,						],
    		changes_away_from 				: [ d: "changes away from",					dd: "change away from",					g:"bdism",	p: 1,						],
    		changes_to_any_of 				: [ d: "changes to any of",					dd: "change to any of",					g:"dism",	p: 1,	m: true,			],
    		changes_away_from_any_of 		: [ d: "changes away from any of",			dd: "change away from any of",			g:"dism",	p: 1,	m: true,			],

Refreshed webcore on the ST app, logged out the dashboard and logged in again but I'm still not seeing anything expect gets for the button devices.

I see the capabilities in webcore defines button and holdableButton but I don't see any reference to them apart from that. Are there any other pieces of code that need to be modified?

[idpaterson]

Sorry I guess this is one that would only be updated in the local db when the webCoRE version number changes. You can log out and back in to the dashboard to refresh that data and see your changes.

[rboy1]

I was able to change the conditions unfortunately it doesn't seem to work as expected. I think it's because it's treating a button device and its attribute differently from other attributes.

Here's the piston being used and the issues are:

1. Doesn't lower the dimmer when button 2 is pressed (it increases it by 10%)
2. It evaluates the conditions as false when the dimmer triggers the piston (the button state is still held)

Here are the logs

(THIS EVENT IS TRIGGERED WHEN THE DIMMER CHANGES VALUE WHICH SHOULD TRIGGER ANOTHER DIMMER REDUCTION BECAUSE THE BUTTON ATTRIBUTE IS STILL "HELD" BUT IT EVALUATES TO FALSE)
4/1/2020, 12:34:48 PM +635ms
--
+1ms | ╔Received event [Heatit Z-Dim].level = 45 with a delay of 66ms
+73ms | ║RunTime Analysis CS > 18ms > PS > 36ms > PE > 18ms > CE
+75ms | ║Runtime (38380 bytes) successfully initialized in 36ms (v0.3.110.20191009) (73ms)
+76ms | ║╔Execution stage started
+88ms | ║║Cancelling condition #5's schedules...
+89ms | ║║Condition #5 evaluated false (7ms)
+91ms | ║║Cancelling condition #4's schedules...
+92ms | ║║Condition group #4 evaluated false (state changed) (9ms)
+99ms | ║║Condition #9 evaluated false (4ms)
+100ms | ║║Condition group #8 evaluated false (state did not change) (6ms)
+102ms | ║╚Execution stage complete. (26ms)
+104ms | ╚Event processed successfully (103ms)

(THIS EVENT IS WHEN THE 2ND BUTTON IS FIRST "HELD", IT TRIGGERS THE PISTON BUT IT INCREASES THE DIMMER INSTEAD OF REDUCING IT AS PER THE PISTON RULES)
4/1/2020, 12:34:45 PM +938ms
+1ms | ╔Received event [Heatit Z-Push Button 8].button = held with a delay of 70ms
+1479ms | ║RunTime Analysis CS > 1392ms > PS > 68ms > PE > 19ms > CE
+1482ms | ║Runtime (38395 bytes) successfully initialized in 68ms (v0.3.110.20191009) (1479ms)
+1483ms | ║╔Execution stage started
+1492ms | ║║Comparison (enum) held is (string) held = true (1ms)
+1494ms | ║║Cancelling condition #5's schedules...
+1495ms | ║║Condition #5 evaluated true (6ms)
+1496ms | ║║Cancelling condition #4's schedules...
+1497ms | ║║Condition group #4 evaluated true (state changed) (9ms)
+1499ms | ║║Cancelling statement #6's schedules...
+1541ms | ║║Executed physical command [null].setLevel([45]) (35ms)
+1542ms | ║║Executed virtual command [Heatit Z-Dim].adjustLevel (39ms)
+1545ms | ║╚Execution stage complete. (63ms)
+1546ms | ╚Event processed successfully (1546ms)

[rboy1]

BTW, it works correctly with "Gets" but not with "Is" so I'm guessing that Webcore handles buttons differently that other devices.

[idpaterson]

Yes, unfortunately the data model based on single letters makes it nearly impossible to grep around and follow the logic. I haven't done any work with device features in the webCoRE codebase and don't know where to point you for this one. You may consider posting this problem and code tweak to community.webcore.co to see if anyone else wants to chip in on getting the conditions to work.