Build 45f28e1 on macOS Catalina 10.15.7 (19H1922) about app HOT 44 CLOSED

Thanks for checking, when you are on the main window (by clicking previous on the screenshot) and click on the magnifying glass nothing shows up ?

from app.

Only the magnifying glass is pulsing for a while, then stops, but nothing else showing up otherwise, that's why I selected the devices button to get to the list and range view.

from app.

The no names devices are in fact devices with no names like beacons ^^ So that's not unusual, if you are in an apartment building and everyone has Apple devices and beacon you will be flooded with them...

Of course if no devices with a name show up at all that's a problem. I tested the same build without the issue on my mac though.

Regarding MQTT messaging, there won't be anything sent until a device has a known MAC address, either automatically detected with supported devices or manually set through the UI.

from app.

I'm very confident that among those devices with "No Name" in the list are also devices I know do usually come up with names and decoded details through the Decoder, also one hardware iBeacon with a name, major, minor and voltage info. Is my understanding that the Theengs Decoder decoding part, including all its devices, should already work correct, or only the previously coded devices?

I tested the same build without the issue on my mac though.

Other than the above mentioned Decoder issue I'm thinking that there is an issue with my older macOS Catalina 10.15.7, even though

#QMAKE_MACOSX_DEPLOYMENT_TARGET = 10.12

Which macOS version did you test with? Might be time to go through some macOS versions external HD testing here ;)

Thanks

from app.

I'm using macOS 12.4 on an intel mac.
I'm aware of problems with some mac, mostly reported on my WatchFlower application, but it's really hard to know what's what. I'm pretty sure there a problem with the m1 macs, but I don't have one to confirm that.
The app has been running since the macOS 10.11 era, but again it's just damn difficult and impossibly time-consuming to validate it's still working well on old macOS versions.

What's weird with your issue is that its mostly working... If there was a problem with the macOS minimum version, the app wouldn't start. If there was a problem with Bluetooth hardware or even Bluetooth permissions, you wouldn't have anything in the scanner.

from app.

Just quickly tried on an even older version on a remote Mac, with 10.13, and there I got an unexpected but expected crossed out app file and the message that this app needs 10.14 or above.

Unexpected because of the above #QMAKE_MACOSX_DEPLOYMENT_TARGET = 10.12 and you saying that it's been running since macOS 10.11
Expected because that is the correct behaviour when a higher OS version is required.

So possibly even with 10.14, and my 10.15 it might start, but not run with its full functionality.

Will have to see when I get the time and nerve to install a newer macOS on an external drive to actually get it fully working here, but it looks like the minimum macOS requirements need adjusting/defining at some stage.

from app.

It is expected, the #QMAKE_MACOSX_DEPLOYMENT_TARGET = 10.12 is commented (# is a comment in qmake) and it is what was set initially in 2018 I believe. Now it's just on "auto", and today that means 10.14, apparently (https://doc.qt.io/qt-6/macos.html).

from app.

Great, so it's clear, 10.14 or above. Still hope we can find the issue of no decoded devices showing up, otherise it might be a higher minimum macOS requirement.

from app.

It may be a macOS version problem but it might be something else entirely.
Again to be sure with these kinds of bugs, what's needed is lots of testers with lots of different environments!

from app.

Best to leave this open until I get the chance to test on further macOS versions.

from app.

Definitely

from app.

Intel iMac with macOS 11.6.7 Big Sur - same issue. Only difference is on first launch to get the macOS 11 Bluetooth entitlement dialog.

M1 iMac with macOS 12 - fine as it is for you.

Now the next step is an Intel Mac with macOS12, to see if it is an actual macOS 12+ only issue, or even possibly an Intel vs. Apple silicon problem.

from app.

Yes the Bluetooth entitlement is one of these nice breaking changes, one day that appeared out of nowhere and the already installed and working apps begun segfaulting. Because if you don't have the permission, that's what happen...
This is what makes compatibility so hard on macOS and iOS. Real breaking changes in core libraries.

from app.

Yes, that was introduced with macOS 11. Unfortunately approving it didn't make a change in the detection.

While the M1 iMac with macOS 12 worked fine in showing names of recognised devices, that particular iMac did not have any Decoder recognisable devices nearby.

Just out of curiosity, what should actually happen when "Launch detection" is clicked, which Decoder recognisable devices nearby? ;)

from app.

Lol I found your bug https://bugreports.qt.io/browse/QTBUG-73149
And https://developer.apple.com/forums/thread/109464
And many other threads on the Internet. While I never experienced it myself, it's been reported a couple of times that the app didn't find any sensors... but until now there was no 'device scanner' to check what was nearby (and nameless...)
In any case that's not good news, that's not good news at all...

Just out of curiosity, what should actually happen when "Launch detection" is clicked, which Decoder recognisable devices nearby? ;)

You mean what does it looks like?

from app.

In any case that's not good news, that's not good news at all...

Yes ;( although one of the bugs is talking about Mojave, one before my Catalina. Still very curious to see how Intel Mac with macOS 12 behaves, and if this bug might actually partly be an Intel vs. Apple silicon related BLE issue instead of just the macOS version.

You mean what does it looks like?

Yes, thanks! I actually wanted to see what has so far eluded me here :)

from app.

ADDENDUM: All my other Bluetooth scanning apps, like LightBlue, BlueSee ..., do show up with the names fine all the time though, never has been an issue for me, so not sure if it isn't a Qt implementation problem somehow.

from app.

I don't think this bug discriminate on the macOS version.
Also I have an Intel on macOS 12 it works. And I've used BLE on this Mac since 2018 (probably macOS 10.15) and I never saw this problem.

Maybe you can try the older releases of watchflower to see if that changes anything?
Because I've all used them successfully 😅
But you'll need a flower care in order to test though...

from app.

But you'll need a flower care in order to test though...

Which I'm afraid I don't have ;)

from app.

As stated above, I still suspect a major issue with the Qt BLE implementation, even if they dismissed it as a general issue in the old bug, as I've never come across a similar problem on previous and my current machinbe - macOS version independant - and all the other BT scannning apps showing all the relevant names instantly. And it's the names, obviously not the non-existent MAC addresses on macOS, which determin the success of the decoded devices grid.

Since the day before yesterday was my first encounter with Qt I'm a bit of a loss :(

from app.

I don't think this bug discriminate on the macOS version.

I'm afraid it does. After some painful testing through all macOS versions from 10.15.7 Catalina up to 12 Monterey on the same iMac, I can confirm that in macOS 12 Monterey, and only in macOS 12, all named devices show up nicely in the list view, but why my Mi Band 4 and my named iBeacon still don't come up as decoded devices in the grid view is still a mystery. As much a mystery as to why

it's just on "auto", and today that means 10.14

is true for being able to start the app, but only macOS 12 actually does a proper job with at least getting the devices names registered for me.

So it was likely the different earlier version of Qt you built your WatchFlower app with, which made it run successfully on these previous macOS versions.

from app.

Thanks for going through this extensive testing!

Regarding

Mi Band 4 and my named iBeacon,

I don't think we have a widget for those in the app. I will push more docs to make it clear for everyone.

from app.

I don't think we have a widget for those in the app. I will push more docs to make it clear for everyone.

Thanks for the clarification @1technophile.
While I do like working on the decoders I don't actually have many decoder compatible devices myself, even though almost all the dots in the first screenshot are my devices, just not all named and most of them not decoder compatible, mainly using OMG for reading from and writing to them ;)

So things are running fine on macOS12 only, at least from my testing, and I suppose the app shouldn't even start on any earlier macOS versions to avoid confusing users, unless it can be made compatible with these versions as well.

from app.

Hi @emericg, I've read up a bit in the issues and discussions of WatchFlower, and it seems you only recently updated it to Qt 6.3 and have this version in a closed beta. Have you had any feedback on it running fine on pre-macOS 12, or could it be that it is also only macOS 12 compatible now?

Unfortunately I cannot test due to missing compatible sensors, but it might be worth doing a macOS 11 test with your Intel Mac on an external drive as well to confirm.

from app.

I have no reports (yet) about anyone using it with older macOS versions no. But with macOS, I'm more used to people upgrading faster than me than the opposite.

Ok so I spent my afternoon installing macOS 11 on an external HDD (Absolutely horrible experience, these machines are not made to be downgraded. Also I lost 10 GB on my already anemic 128 GB internal hard drive too, so... not so great).

Now the results of the different tests are... a bit weird.
First of all, it works. Kinda. Using Theengs I have devices. There are definitely more unnamed devices than I had an hour ago on macOS 12. Using the latest Theengs from the CI builder.
With WatchFlower, I used the 3.0 version from the release page. So again, that version served me well, never had a problem with it. It's using Qt 5.15, and it's also pre macOS 12 (there was a special version of the 3.1 release that was compatible with macOS 12).
There too, while some devices are detected, some are clearly missing. Like my Flower Cares, and I have a few in and out of the room, so they should most definitely have been detected before the FlowerPower and Parrot Pot (that have infamous BLE quality).

So what does this all mean, I have no clue. There is something going on, but that being said, releases, OSes, and libraries that were working, now aren't.
While it's a disappointing outcome, I won't be spending much time on this right now. Maybe we'll know more about this with time and more testers.
The macOS version of Theengs isn't a primary target. Its other shortcoming (no MAC addresses on Apple devices, so no automatic way to make Theengs decoder work and send results) already makes it a version you should use if you know what you are doing.
And there is also a "simple" fix. Update to macOS 12.

from app.

So basically sort of confirming my findings here, with my devices probably in the category of your missing devices - so no named ones for me at all, unless on macOS12.

So what does this all mean, I have no clue. There is something going on, but that being said, releases, OSes, and libraries that were working, now aren't.

Still looks like a definite change in the Qt5 to Qt6.3 BLE handling and more to me. That's all I really wanted to make you and @1technophile aware of with this issue. It's not like with my limited decoder compatible device selection I'm a target end user.

The macOS version of Theengs isn't a primary target. Its other shortcoming (no MAC addresses on Apple devices, so no automatic way to make Theengs decoder work and send results) already makes it a version you should use if you know what you are doing.

I got that by now and assume the same for iOS version, with no MAC addresses ;)

And there is also a "simple" fix. Update to macOS 12.

Yes, as I stated above, probably safest to advertise the final macOS version to macOS 12 users only.

Can be closed from my end as currently unsolvable.

from app.

Maybe some changes in the macOS Bluetooth stack got backported to older point releases, and Qt isn't handling it, I don't know. I'm not sure what else it could be.

But I'm thinking about the names, we actually don't really need them with the theengs decoder, that's not how devices are detected. It's just assumed (by the app) that a device has one or it's invalid... There is probably something that I can do here to make this situation less of an issue.

from app.

Maybe some changes in the macOS Bluetooth stack got backported to older point releases, and Qt isn't handling it, I don't know. I'm not sure what else it could be.

I very much doubt that, as macOS 10.15.7 and 11 only got sparely pretty much fully documented security fixes as not current, but still supported OSs since Qt changed from Qt 5 to Qt 6. I really think that with Qt6 the BT handing was slightly changed to get better/fully working compatibility for macOS 12, but instead of also implementing a backwards compatibility layer as with the previous Qt5, they just left it with the new workings.

I think in the end only a wider user/tester base will show the full effect, also for WatchFlower, as I assume that the users which are on github, and especially ones which will join a closed beta are only the ones who also update their OSs regularly ;)

But I'm thinking about the names, we actually don't really need them with the theengs decoder, that's not how devices are detected. It's just assumed (by the app) that a device has one or it's invalid... There is probably something that I can do here to make this situation less of an issue.

I won't log any further issues unless you ask me to test something which might remedy this issue with a different decoder recognition. I'll keep my partitioned external HD for that for a while.

Not really helping, and without any UI, but Theengs Gateway is working fine for all my devices on all the macOS version in getting the names and decoding, save for my iBeacons also not showing up names - still being decoded though - but since these iBeacons also show a similar issue on ESP32 based OMG gateways every now and then I pin it down to an issue on their side. And the same missing MAC addresses of course, also with the UUIDS changing with every restart, which makes it mute for any MQTT purpose.

from app.

But the Qt 5.15 used in the WatchFlower v3 I tested today was released a year before macOS 12, and still has the issue. So that's only adding to the mystery 🤔

from app.

But the Qt 5.15 used in the WatchFlower v3 I tested today was released a year before macOS 12, and still has the issue. So that's only adding to the mystery 🤔

I suppose the only bullet proof check would be macOS 10.14, with which WatchFlower v3 should work, and which didn't get any updates at all during that time. But I doubt that currently you or I would even want to think about installing and testing that. Anyway, I have the excuse of not having any WatchFlower compatible sensors ;)

What I didn't quite get in your previous post was if and how the current Qt 6.3 based WatchFlower beta app behaved on macOS 11, or did I misread something? Did that beta show up the devices and names fine, or only the v3 from the download page?

from app.

Also I lost 10 GB on my already anemic 128 GB internal hard drive too, so... not so great

BTW, that is probably the roughly 10GB of the installer. Have a look in Applications - Install macOS Big Sur, and delete it now that you have installed in onto your external HD. Should give you back your 10 GB ;)

from app.

But the Qt 5.15 used in the WatchFlower v3 I tested today was released a year before macOS 12, and still has the issue. So that's only adding to the mystery 🤔

I suppose the only bullet proof check would be macOS 10.14, with which WatchFlower v3 should work, and which didn't get any updates at all during that time. But I doubt that currently you or I would even want to think about installing and testing that. Anyway, I have the excuse of not having any WatchFlower compatible sensors ;)

I figured out how to quote from the GitHub mobile app 😅
Yeah you are right I'm not looking forward to setup the 10.14 either

What I didn't quite get in your previous post was if and how the current Qt 6.3 based WatchFlower beta app behaved on macOS 11, or did I misread something? Did that beta show up the devices and names fine, or only the v3 from the download page?

I only tested the WatchFlower 3 on Qt 5 because the new WatchFlower 4 on Qt 6 is the same code and the same Qt library than the Theengs release, so it would likely show the same results: same devices detected and other nameless devices.

I will test WatchFlower 2 tomorrow, because while they used the same Qt 5.15 (maybe 5.14) version, WatchFlower 3 may have been built with a more recent xcode with some support for macOS 12. Maybe that's a piece of that puzzle. But I'm afraid it won't work because of the introduction of the BLE permissions system.

from app.

Also I lost 10 GB on my already anemic 128 GB internal hard drive too, so... not so great

BTW, that is probably the roughly 10GB of the installer. Have a look in Applications - Install macOS Big Sur, and delete it now that you have installed in onto your external HD. Should give you back your 10 GB ;)

Indeed that's probably related to that. But I did delete the installer and looked for some leftovers files, only to notice that the main system partition was now 37 GB, wich is more than I remember...
I did found 5 GB of chrome and steam cache in the process but still.
Maybe it will be resized during next update, or temp files will be deleted automatically at some point.

from app.

Well, guess what … I saw that you made a commit earlier, also with some QMAKE masOS and builder changes, so I kicked of the desktop builds just now . Well, still most of the list entries with No name, but now my Mi Band 4 is showing with a name, definitely a first. So looks like a step in the right direction :) all still on macOS 10.15.7

I'll monitor this and see if if constantly comes back with every launch.

from app.

And one of my Playbulb Candles

all only very sporadic though, and only after having launched the app. Something is either there right from the start, but once the list is all No Names the don't really seem to update to a name while running.

I'll test some more tomorrow, could just be a fluke ;)

from app.

No, definitely only a fluke. While I haven't seen any device names before they now only appear very sporadically and only after every nth start of Theengs, and only ever one, usually a different one of my devices' name is shown :(

Had a look through

https://doc.qt.io/qt-6/qtbluetooth-changes-qt6.html

and thought

• manufacturerData() returns a [QMultiHash](https://doc.qt.io/qt-6/qmultihash.html) rather than [QHash](https://doc.qt.io/qt-6/qhash.html#qhash). Since Qt 6 [QMultiHash](https://doc.qt.io/qt-6/qmultihash.html) is no longer derived from [QHash](https://doc.qt.io/qt-6/qhash.html#qhash).

might be relevant, but I'm sure you've gone through all that when porting WatchFlower to the new beta and implementing the devices list in Theengs.

Am still very interested to hear how the new beta WatchFlower is running for you on your external macOS 11.

Other than that leaving this as is for the time being ;)

from app.

@emericg - thanks a lot for sorting this with commit

b877b3f

Could have also been named "Solves device name recognition on pre-macOS 12" 🚀

All 9 PB Candles, the Mi Band and named iBeacon, i.e. all my named devices are instantly recognised with this build.

Will also test on macOS 11 just to make sure it's the same there, am sure you tested it on macOS12 already. Then this issue can be closed as fixed.

from app.

Closing as fully fixed with

b877b3f

Verified with macOS 10.15.7, macOS 11 and macOS12. With

QMAKE_MACOSX_DEPLOYMENT_TARGET = 10.14

let's assume this also works fine on macOS 10.14 ;)

P.S.: I also found with macOS 12 earlier today, that once signed into Home all my Apple devices like HomePods and Apple TVs also then get recognised with their names for all BLE scanning apps, the same as on iOS 15. As I've tested a HomePod decoder a while back, to see if volume setting could be deducted, but then shelved it, as the names are not available to OMG, but only on macOS/iOS devices, and then only when signed into that particular Home account. Might still be a possible future decoder idea for Theengs and Theengs Gateway on those OSs.

from app.

Could have also been named "Solves device name recognition on pre-macOS 12" rocket

Well not really. It's only what I mentioned yesterday, the application now handles devices without names better. But it is working better indeed!

The device scanner part of the app just allows empty devices to be added to the list, then later updated with a name.
The scanning for devices (the regular scanning process, to add devices in the app) also does not block empty devices so they can be handled.
Now usually that's not how scanning is supposed to work, but that's the new behavior we've been seeing with the old macOS version.

I went down the rabbit hole, and the parts of the Qt wrapper that reads advertisement results from the CoreBluetooth API does get, well, empty names. With macOS < 12. And again that wasn't the case before, because with this new behavior we get some devices correctly, always the sames (so it's probably linked to their manufacturer, the chip they use, how they send advertisement or something) but like for instance the FlowerCare are not picked up. So I guess I would have noticed that with WatchFlower...

I guess the Qt dev are to some extent aware of the issue because there is a commit dated May 7, 2021 that seems to do the same thing I did (working around getting the infos not at once) but in the Qt wrapper unlike I did directly in the app. But you can see it's also disabled by default, and can be enabled with an environment variable. With that environment variable set it looks like I get more names with the "old" Theengs build, not the one from today.
It's also post macOS 12 and well post macOS 10/11.
And you can see there isn't much traffic in that file.
https://github.com/qt/qtconnectivity/commits/dev/src/bluetooth/darwin/btledeviceinquiry.mm

So all in all. Definitely a macOS bug.

from app.

So all in all. Definitely a macOS bug.

Obviously not for you ;) but for me this is ultimately irrelevant when just using and testing the app, and how this possibly got introduced through security updates only. From my perspective it completely resolved the initial observation of this issue, with the build now working consistently for me with the same expected proper device names result over all macOS versions now. Unfortunately I cannot test it with any or as many decoder compatible devices to see if there might be negative changes.

And you can see there isn't much traffic in that file.

Exactly ;) like the very recent

qt/qtconnectivity@e24f99c

which looking at the

https://bugreports.qt.io/browse/QTBUG-103388

was only opened once Android followed suit with BT permissions with

https://bugreports.qt.io/browse/QTBUG-102373

in Android 12, whereas for macOS/iOS this could/should have been addressed well over a year earlier.

I am used to and can live with this bias, and the more I read through Qt bugs, the more it looks a bit like an "if it works on iOS/macOS fine, if not; oh well, maybe later" attitude, which also makes me a bit anxious about the upcoming macOS 13 compatibility. As said above, if you and @1technophile decide to go macOS12 only that's not a problem for me. If the commit needs to be reverted because it causes issues for you somewhere else, I won't reopen it ;)

from app.

We are doing an application that works on 5 platforms, as well as many versions of these platforms.
It didn't really use to be a problem, but the fact is, the major platforms are diverging, and fast.

I cannot humanly keep track of every changes and bugs to these platforms, and Qt developers cannot either. That's why everyone is running around fixing things as we see them breaking.
You mention the Android BLE permission system. It changed 4 times during the last 4 years. That's not even counting limitations introduced like the one we had for Theengs and Android 12 background scanning. Also, undocumented.
Every major macOS version now brings game changing modifications. I'm anxious too, believe me. Android is the same, it's mind-boggling the amount of constraints that are being added and features removed in each version. We don't have access to files and the filesystem anymore with Android 12, that's just plain stupid. By far the worst platform to work with.

A 20 year old Windows app has a good chance to work today on Windows 11, a one year old Android application just won't. That is not OK, but what can we do?
Apple and Google just expect you to make major changes to your code, rebuilt it with latest SDK only and republish, or get lost.

from app.

All I was saying is that I was very happy with your commit which fixed the original issue here for me and that i congratulated and thanked you for that, appreciating the work you are doing.

And yes, I know quite well what the challenges are with supporting multiple OSs with multiple versions of them, probably more than I let on. I think we all do.

Now I'm already feeling hesitant of logging new issues, as I'm afraid they might always turn into debates on principles of which OS is better, easier, buggier, more awkward to update, more compatible with Qt etc., instead of collectively trying to focus on getting the best working version of Theengs put together.

And if some unsurmountable road blocks appear for one or more OS versions of whichever OS, then you and @1technophile unceremoniously decide to cut them loose, and I'll be happy with that.

from app.

I'm sorry my intention wasn't to start a flame war.

from app.

👍 Let's just concentrate together to get the best possible app, on all platforms.

Maybe it'll also be a good idea to start using tags on issues. Making it easily clear now and further down the line if something 'won't be fixed' (macOS12+ only, or similar for any other platform), critical (needs looking at, but might be hard/awkward to implement right away) etc.. This would keep us all on the same page just with a quick look in the issues list.

from app.