Nayely,
Consider the button capability and attribute. The only actual events generated have the values pushed, held etc but in the mobile app we get to see ‘Standby’ displayed.
Similarly for momentary which doesn’t have an attribute at all and yet can display ‘Pushed’ when activated and then return to ‘Standby’.
So in both cases the app display can be changed without an event being generated.
For stateless attributes, such as the HTTP code example @TAustin presented, it makes no sense to permanently display the value of the last event. At the very least it should be possible to display an intermediate message as was possible in the Classic app.
It seems our only option to change the status reported in the app is to set the attribute and if we do that an event is generated in the device history and propagated to apps. Both are undesirable, with the event being a particular problem.
So are we overlooking something?
Another issue, which is related but off topic for this particular thread, relates to state change.
With the Classic platform, the ‘system’ would only propagate events where there was a state change. For stateless events, like pushing a button, developers could override this behaviour and force the event to be considered as a state change.
It appears the same is possible in Edge drivers, although undocumented, which seems odd as it would be critical. Does the ‘new’ platform behave the same as the old one in this respect? My assumption had been that as subscriptions can be limited to state changes, all events must be propagated. But then I saw a state change added to direct connected devices and I’ve seen it used in Edge drivers. So unless it is purely for back compatibility with the legacy platform I am confused.