The initial issue was filtering out 'caused by me' expected events that came back from a device I had just sent a command to. (By this I actually mean I am updating the HE virtual device status to match a new status reported by the remote MQTT device, not sending a command to the remote device). They are really state updates to the HE virtual device, implemented via the commands.
The RM reference just refers to me within in my app being able to see that RM had sent the command to a device that resulted in this event.
If I change a few attributes (via commands) on a device then if RM triggers off these and sends other commands back to the device immediately then the events get interleaved in my app and I have difficulty determining what the final state should be.
Assuming this is your driver in use, simply create a separate command for RM to use (with Custom Action).
If state is too slow for your use, what about using @Field? I'm assuming you need to set a flag in the driver when you send a command so that you know the next response is a result of that command.
By that you mean the next events I receive ?
I am sending commands to the HE virtual device (from my app not driver) to update its state eg 'switch' ' on' . I want to ignore the events that come back caused by my command , but to receive any that come form elsewhere e.g. RM
Yes essentially but it could be that RM or any other app that subscribes to one of these virtual devices also tries to control this same device at the same time. The events get interleaved. I don't know how to recognise that situation. These devices are all using Hubitats included virtual drivers each as a representation of the remote MQTT devices.
I don't think you can solve this problem using built-in drivers. The only way to attack it is in the driver for the device that represents the remote MQTT device. It's the only place you can distinguish and stand a chance of knowing which response is the one to ignore.
OK - The only driver in my app is the one single child MQTT driver - I don't have 'drivers' for any remote MQTT devices - I wanted to use your standard virtual ones !
So it's just not feasible for an event originating from a (any) device to return an extra property saying which appID triggered this event ? (a feature request)
Drivers don't know what app invokes a command. That's not part of the architecture of the hub. Doing that would pretty much entail a completely new design. That doesn't make sense.
I don't think "really difficult to implement" captures what's at stake here. This would entail a completely different approach to the hub platform. It's not a feature request, it's a request for a different product with a different design from the ground up.
Oh, I didn't want a building, I wanted an airplane. Can't you put wings on the building?
