[ST Edge] Attribute won't update to non-'alternatives' value after first 'alternatives' match

[nmpu (David)]

Here’s my scenario. I suspect this will happen other places.

I have a custom presentation with a dashboard containing a pushButton that cycles a string attribute named status. Think of the pull-chain on a ceiling fan. Fast-Medium-Slow-Off repeat.

It’s my understanding that alternatives does not have to cover every possible value. If there’s a key match, the alternatives value is used in its place. Most people probably use all or none for alternatives, but what happens if you omit some keys? I’m observing a weird ‘latching’ behavior. As I’m advancing through the keys, after the first alternatives match occurs, my status attribute won’t update to anything that isn’t in alternatives. emit_event() fires with the correct value, but it’s ignored-- even if I force state_change = true.

So, why am I doing this? alternatives allows you to control the active/inactive appearance of the icon and button. By including a single generic ‘Off’/inactive in alternatives, I can display all other states programmatically. At least that’s what I was expecting. In reality, the ‘Off’ works like a pothole. Once you get stuck, you can never escape. I display the same status in detailView, so I know my code works. The actual state is stored in a Lua variable. This is a display issue.

capability

attributes:
  status:
    schema:
      type: object
      additionalProperties: false
      properties:
        value:
          type: string
commands:
  doAction:
    name: doAction
    arguments:
      - name: action
        optional: true
        schema:
          type: string

presentation

dashboard:
  states:
    - label: '{{status.value}}'
      alternatives:
        - key: 'Off'
          value: 'Off'
          type: inactive
  actions:
    - displayType: pushButton
      pushButton:
        command: doAction

[orangebucket (Graham)]

@nmpu

It’s my understanding that alternatives does not have to cover every possible value.

That isn’t my understanding but it is certainly what I’d expect, because it seems the obvious way to implement it.

@nmpu

Most people probably use all or none for alternatives , but what happens if you omit some keys? I’m observing a weird ‘latching’ behavior.

Clearly what I think is obvious isn’t the only way. I’m no developer but it seems you’d have to work at making it do that.

[nayelyz (SmartThings Developer Support)]

@nmpu

As I’m advancing through the keys, after the first alternatives match occurs, my status attribute won’t update to anything that isn’t in alternatives . emit_event() fires with the correct value, but it’s ignored-- even if I force state_change = true .

So, when you push the button in the Dashboard View, you send consecutive events to change the attribute value and you see they are displayed until you sent the “Off” event (which is part of the alternatives), after that, the state is not updated with a different value, correct?

Which OS are you in, Android or iOS?

[nmpu (David)]

Your summary is correct.

If I include additional alternatives in the sequence, they are also accepted. If I leave alternatives empty, all values are accepted. It appears that some internal logic changes once the first alternatives match occurs.

I’m using an Android phone.

[nmpu (David)]

Here’s a turnkey project which demonstrates the problem. It only occurs in the dashboard. detailView works as expected. I’ll leave the custom capabilities under my namespace so you don’t have to recreate.

[nayelyz (SmartThings Developer Support)]

Sorry for the delay.
Just to let you know, this issue was already reported, it happens in both, Android and iOS.
I tracked down the corresponding report and asked the team for an update, once I get more info, I’ll let you know.