Closed DigiH closed 1 year ago
@1technophil and I tested further with some RDL52832 decoder changes. With
https://github.com/theengs/app/actions/runs/3473682549
no crash so far on macOS. Will need to be verified with the same build run for iOS with a TestFlight version.
@koenvervloesem could you have a look at the RDL52832 model condition changes I made and let me know what you think?
https://github.com/DigiH/decoder/commit/2fc887fefc5a327c25e51997e744079e434712fa
RDL52832 is still sometimes recognised with manufacturerdata only, so no name, serviceuuid and servicedata, therefore still recognised and decoded as an iBeacon in those instances. Not sure if and how this could have cause the crash, but the current changes seem to have addressed it.
@emericg - with this build the macOS menu item is back unfortunately. I'm not exactly sure with which previous builds this was reintroduced, but you had removed it before, hadn't you?
This looks reasonable, although this way the device isn't detected anymore as an RDL52832 if the user has changed its name, right?
although this way the device isn't detected anymore as an RDL52832 if the user has changed its name, right?
Correct, the name is now part of the model condition.
Crash resolved and verified on macOS with
Verified with version 1.2 on iOS and macOS
Having an active RDL52832 beacon around crashes the app when doing a search/scan for new sensors on iOS and macOS, making it impossible to use this functionality until the RDL52832 beacon is being turned off.
I suspect some relationship with the RDL52832 using the iBeacon protocol, but not falling under the iBeacond decoder, which AFAIK has been disabled for the app.
Similarly this might also be affecting other iBeacon protocol sensors like BM2 and ABTemp, and would need to be verified with these and also on Android and Windows, as having such sensors in the vicinity could compromise a vital functionality of the app.
Excerpt from the macOS crash log: