Craig, I know of no other reports regarding increased traffic. But there are few using MQTT, who also need to monitor their data volume, so maybe you're just the only one noticing. Yet I still think testing in chronological order is not going to produce sensible results, as you mix unfinished intermediate commits from different development branchs, their commit order normally does not match the chronological order of each other or of the master branch. As written before, you need to concentrate on single branches when doing that. The recommended tool for narrowing down bugs by commits is git bisect. In your case, 78a49a59 is not a master commit, it's one part of pull request #1081. Just as an example, commit 98606bb5304a5c2b832ffbb0d26391a632e5fc17 is dated after 78a49a59 but was added to master before. So it doesn't make any sense to test 78a49a59, unless you're on the #1081 development branch. Use gitk, git log --graph, or similar to view the branch/commit associations. Regards, Michael Am 13.07.25 um 19:08 schrieb Craig Leres:
On 7/13/25 01:31, Michael Balzer via OvmsDev wrote:
as we don't make any progress on the CAN issues (affecting only few users), and "main" users struggle with bugs that have long been fixed in "edge", I'd say we release 3.3.005 now.
Am I really the only one who sees a 10X increase in cellular usage when running anything newer than 3.3.004-313-g78a49a59?
I've been busy with other projects but the last time I looked at this I was having trouble testing git hash/versions in chronological order. I have been running 3.3.004-323-gbc1f75c9 without issue and I *think* 78a49a59? is the next hash and I tested that it's problematic for me.
Craig
-- Michael Balzer * Am Rahmen 5 * D-58313 Herdecke Fon 02330 9104094 * Handy 0176 20698926