Oh...so, how is whatever issued the command to Hubitat (through MQTT) confirming that the state changed if a corresponding MQTT message is not received confirming that the device did, indeed, chagne state?
See, I would have expected that your APP would issue an MQTT message whenever the state changed, regardless of where it originated. But I can see why you would want to avoid that if your could to cut down on the number of messages.
But it seems more logical to me that whatever is subscribing to the device updates through MQTT should sort out whether it needs to do anything with the messages it is receiving.
This is the same logic that goes into the command/event system. An app issues a command and then knows that it was executed because the event is issued. It's up to the app to figure out if it needs to do anything with the event. I would think the same would hold true with MQTT. Your app is just issuing messages when an event occurs, it's up to whoever is subscribing to those messages to sort it out.
But with devices external to Hubitat so, whereever the actual "event" started, triggering the update to the virtual, device created by your app, is probably not subscribed to MQTT messages from Hubitat, so, there is no cross-checking. So, the outbound message is useless. It still doesn't mean I wouldn't expect it to happen.
Maybe make the distinction that "blatant". Never send MQTT messages for virtual devices created by the MQTT app unless the user specifically enables it.
(It took me a minute for my train to pull into your station....but it got there eventually, isn't that what's important? )