That would be a really good idea … but as you’ve already found, we cannot inspect the existing state to decide if there was a change or not.
Off-topic - for the same reasons, the Modbus binding implements this as an internal option, because it is generally a fast-polling service, and can be set to only pass changes through.
A side effect of many updates can be churning away saving persistence records too - this can have real performance impacts, it’s not just a cosmetic nuisance.
I doubt there’ll be any such feature in the MQTT binding anytime soon, you would have to add some internal caching.
That’s your real problem.
But can we deal more gracefully with a rogue device?
Going to guess that’s not quite true, and the logs are changes? Updates-to-same are not usually logged, unless you’ve chosen that.
So assuming it’s a lot of changes like 245.75 volts to 245.74 volts …
You should be able to reduce some churn by rounding to fewer digits in a transformation.
The updates will still take place, but not be logged when no change e.g. 245.7.
To instead treat it as a cosmetic issue, just filter off the offending logs to a separate logfile
There’s a number of posts, like this giant -
But do consider your persistence as well - are you persisting every update unnecessarily, and should configure for every change instead?