Are you filtering out your events if they are duplicates in your driver? Historically, as long as the driver called "SendEvent()", the Last Activity At field was updated properly by the platform. The platform should de-duplicate the incoming events, except in the case of a device like a button controller, that might issue multiple "pushed" events in a row, for example. In that case, one would add the "isStateChange: true" parameter to the sendEvent() or createEvent() call.
Only add the "isStateChange: true" parameter IF your device needs to issue the same event multiple times in a row. Normally, this is not what a typical device driver should do. Usually just passing the attribute, value, and optionally a detailed decription of the event is all that is required.
I am not an expert on Zigbee device drivers. However, what I believe is happening with that call is the platform is taking the raw incoming data ("description") and attempting to decode it into something that can be easily used to generate an event. This prevent the author of the driver from needing to know the details of the Zigbee protocol. So, if your device is Zigbee, that call should be used for standard zigbee devices.
If it was creating events the Last Activity would update, that is what causes it to update. In my zwave drivers I started to always send the events even if duplicated and as @ogiewon said the platform will only post the new events (but still update the activity time). The only thing I filter out is the text logging, I only send it to the logs if it is a "new" event. isStateChange: true should only be used if you want to FORCE the event to be logged in the event history (such as button presses or energy reporting stats).
Sensirion SHT30 sensor. Great specifications if they are real.
Acurite LCD indoor display that shows indoor and outdoor temperature, humidity, Atmospheric pressure and predictive weather icon.
The Arduino ProMini (small 8Mhz processor) reads the SHT30 sensor. It then formats a bit stream to simulate an Acurite remote sensor sending the SHT30 data to the Acurite display using a 433Mhz transmitter.
It then formats the temperature and Humidity in a serial friendly form and sends it to the CC2530 Zigbee board. The Hub receives the data as a string and parses it to show status, temperature and humidity.
Currently it is fully functional but not installed in the final location.
So basically its an exercise in keeping an old guy busy and out of the bars