Simple line of code in a driver -> sendEvent(name: "lastStatus", value: new Date())
In Current States it shows lastStatus and the date/time, as expected.
Refresh the device page and Poof it's gone. Not in Current States any more.
It does appear in the Event Log for the device.
Anyone know why?
While I'm at it, why would some sendEvent commands not cause an Event Log entry???
For example, sendEvent(name:"smoke", value:"clear") never creates anything in the Event Log - yet is executed right next to sendEvent(name: "lastStatus", value: new Date()) which does????
More particulaly, for an attribute to "stick", I think you either have to declare a capability with that attribute, or else declare a custom attribute. This might be your problem with "lastStatus." And for it to appear in the log, I think (not 100% sure) there needs to be a change -- so if "smoke" is already "clear", then another "clear" won't be logged unless the sendEvent includes: "isStateChange": true
And as a further tip, usually you don't want to log events that are mere duplicates, so typically, you wouldn't force "isStateChange":true, rather, let the platform handle it. For example, if a light is already "on", and you receive another "on" command, it generally is not treated as a new event. There are some exceptions. For example, for Central Scene, if the last event was a button press, and then there is another button press, those should be treated as two distinct button press events so you do include isStateChange:true for Central Scene (I think!).
In this case it's a smoke sensor. So logging "clear" every hour is probably a good thing. I have users of my driver complaining that the device status is not getting logged. That now seems to be because they need to test the sensor (or have a real smoke event) to get it to log a changed state.
All depends on the attribute and its use. I agree though, that unless you need duplicate events for a technical reason then the default behavior is correct.
Duplicates on on/off are sometimes used in drivers for secondary function (resetting timers, etc). Battery % as state change is typical due to the low frequency of events. Etc.
