theengs / app Goto Github PK

With the inclusion of the external probe property for TH-1/TH-2 my TH-1 is now displayed only as a generic device with the latest macOS build (also not seeming to update its values), while the iOS app 1.2 (with previous old decoder) still shows it with the correct Thermometer widget.

I'm also not sure if and how the pool thermometer P01B, which is included in the same decoder, and only has temperature, but not humidity, is being displayed in general in the app.

Current latest macOS

iOS 1.2

I really like the idea of the App and the project.
Unfortunately I understood the concept wrong and thought that all devices are supported. May be it is possible that a Polar Heart Sensor H10 could be supported also. Especially the mobile app is great for all fitness devices.
Thank you for your feedback.

When I added LYWSD03MMC to iOS app, I can see temperature and humidity, can update it.
But in MQTT no data about this.
In MQTT i see only topic home/TheengsApp/version with data "v1.3.1"

Steps to reproduce the behavior:

1. Install app
2. add LYWSD03MMC
3. configure mqtt server settings
4. scan MAC of LYWSD03MMC with debian
5. Set MAC Address of my LYWSD03MMC into App, from previous scan
   "root@mdm:/home/london# stdbuf -oL hcitool lescan | grep LYWSD03MMC
   A4:C1:38:5C:75:B6 LYWSD03MMC"
6. click Update data in app

Expected behavior
I wanna LYWSD03MMC data in MQTT

iOS App Theengs ver 1.3.1
iPhone 14 Pro
iOS ver. 16.5.1

Having looked at the Qingping Air Monitor Lite UI a bit closer I thought that the stips next to the PM2.5, PM10 and CO2 values change colour, depending on the levels. So fanning smoke onto the sensor I got the CO2 strip to change colour nicely, along with the lung graphic.

For PM2.5 and PM10 the stips are always green, possibly as they have different scales to CO2, usually divided into six categories

which could nicely be cut down to the same three categories as CO2 has - green, orange, and red, with

PM2.5
<=60=green, <=120=orange, >120=red

PM10
<=100=green, <=350=orange, >350=red

The PM2.5 and PM10 values also do not need a decimal, as their value is braodcast as integers, the same as the CO2 value.

Also in the list view there is an extra wind icon appearing when the CO2 value is above green (1000 ppm?). This extra icon is then overlapping with the name.

I'm not sure this extra icon is needed, as the now totally orange CO2 scale is already a clear indicator.

Lastly - is there any reason why the units for PM2.5, PM10 and CO2 are behind the labels in the widget view, and not behind the actual values, as with all the other property displays, at least for all the other sensors I have? They should fit nicely after the values, especially when OM2.5 and PM10 are integer values. The unit ppm should also be lower case.

While in the snow theme and the night theme the selection ring colour of selected devices in the visual view are easily distinguishable for all rssi device colours, in the default Theengs theme any not so good rssi devices are orange themselves and and not as clearly visible when selected

as the green rssi devices are.

Since the default Theengs theme heading colour is blue, I thought it might be nice to have the same blue selection ring colour for easy visibility of all rssi devices.

Similar to
#15
while I think this would be nice, since it is not really a vital functionality issue, it can be considered as nice to have possibly later or even not to be fixed.

With version 1.2 (1020001) and my
2 x IBS-TH1
2 x CGDN1
IBT-2X
XMTZC05HM

the list view order is always the same, no matter which sorting I use and at which location I am trying the sorting.

With Order by: sensor model I would expect the two TH1s to be together, and with Order by: location in the above video the two Qingping Air Monitor Lites should have been sorted to the top, as this was done about 20 cm away from them, with all the other sensors being more than 7 m away.

No matter where and how I try it, I never see any changes in the list order of my sensors.

Since @1technophile seems to have a working sort order with his different sensor models this makes me think it could be model related.

I am unable to connect to HiveMQ broker cloud where I have configured the URL: 96b3edf4aadc47238e12bd937aba7897.s1.eu.hivemq.cloud
Name: ….
Password: …….
Port: 1883

text: qsTr("Connects to a remote MQTT broker. Setup is at your own charge.")

sounds a bit like monetary charge to me ;) maybe

text: qsTr("Connects to a remote MQTT broker. The setup is your own responsibility.")

Just a thought

iOS release version 1.2

Having received my new Qingping Alarm Clock CGD1 and trying to add it to Theengs iOS 1.2 I always only ever get it to be recognised as Offline. With the (later Actions run build) macOS version it shows up fine immediately.

Looking through the code I also found
https://github.com/theengs/app/blob/development/src/devices/device_hygrotemp_cgd1.cpp#L114

if ((data[0] == 0x88 && data[1] == 0x16) || // CGG1
            (data[0] == 0x08 && data[1] == 0x07) || // CGG1
            (data[0] == 0x88 && data[1] == 0x10) || // CGDK2
            (data[0] == 0x08 && data[1] == 0x10) || // CGDK2
            (data[0] == 0x08 && data[1] == 0x09) || // CGP1W
            (data[0] == 0x08 && data[1] == 0x0c))   // CGD1
        {

which should be adjusted to only take the data[1] byte as the device ID condition - like all the adjusted decoders do for the sole device ID- as the data[0] byte alters with hardware revisions. Also in other similar occurrences it should just be

if (data[1] == 0x16 || // CGG1
            data[1] == 0x07 || // CGG1
            data[1] == 0x10 || // CGDK2
            data[1] == 0x09 || // CGP1W
            data[1] == 0x0c)   // CGD1
        {

Why however my CGD1, which broadcasts manufacturerdata starting with 880c…, is correctly recognised and updated with its data on macOS I haven't really investigated.

iOS

macOS

Tested with version 1.1 (1010008)

For my IBT-2X there are three different inconsistent temperature displays. Assuming the same for the remaining IBT iBBQ thermometers with 4 and 6 probes/Tenergy SOLIS 6 BBQ

Rounded temperature in list view with no decimals and only the degree unit sign

Temperatures in the widget view, with one decimal place, degree unit sign and Celsius sign, then when sliding over the history graph, only the temperatures with one decimal but no degree unit nor Celsius

So 21º, 20.9ºC and 20.9 all for the same temperature.

My suggestion here would be to follow the Inkbird iBBQ thermometers themselves by not displaying any decimals at all, especially with the high temperatures of BBQ thermometers I don't think it is necessary here and still allows for the shorter display to fit in the list view, especially with 6 temperatures.

Also to only use the degree unit sign º everywhere, but NOT the C for Celsius, as this is defined in the preferences anyway. I would not display C or F anywhere for temperatures in the app. The user knows which unit system they selected ;)

My vote for rounded no decimal only degree unit 21º everywhere for all iBBQ thermometers.

For any other temperatures I would suggest a one decimal only degree unit 22.7º format.

While working on the device list name recognition issue I stated that I do not have a decoder compatible BT device, which is totally wrong, as I have the Xiaomi Mi Body Composition Scale. Usually I just stand on it, read the weight from the display, being confident that OMG registered it in the background and passes on the details to my backend for processing. That's why I completely forgot about it.

So i got it from the bathroom and it sitting next to the desk I found the following

macOS 12

macOS 10.15 and macOS 11

If this is an issue with the widget name recognition, the widget display and if this might also have been a reason for the different device recognition for WatchFlower on the different macOS version is pure conjecture on my side.

In the device list, the name shows fine and consistent across all versions.

Also with no weight and impedance shown on all versions, only always Offline, it seems that the Mi scales are not yet fully implemented, so possibly not the best device to currently test with.

Probably due to the non device/name specific recognition with every restart/new usage of the scale a new unnamed offline device widget is added.

Hey everyone,

I installed the App today in a Tablet mounted in a Wall near a Bluetooth Sensor and wanted to use IT to Push the Data to my mqtt Server in Home assistant.

I followed the steps for granting all rights in Android 13 plus making Sure the optinization of accu ist turned Off for the App.

My Sensor is schön in the App and I also See the Data in my Mqtt Server. But after Like 5 minutes and when the Display goes in sleep Mode, the App loses mqtt Connection and i geht No new Updates for my Sensors.

Ist there anything i could so to prevent that from Happening?

Blacklisted and deleted devices are back in the list with next search for new sensors, even when the device is still listed as black-listed ⊖ in the device browser.

Verified on iOS and macOS

Also the heading and text for white-listing a device in the device browser again is confusingly talking about black-listing - i.e. same strings as for initial black-listing - only the button has now changed to Whitelist.

Describe the bug
I purchased the Theengs app a few days ago. I have a Govee H5101 thermometer. I can see it in the device browser, but "Launch Detection" doesn't do any thing. The particular model number is not listed as supported, but it seems it should work because shows up the browser and also it is listed in the theengs/decoder/blob/development/src/devices/H5102_json.h file.

Is this a bug, a device support request, or am I missing something else?

Thanks!

To Reproduce
Steps to reproduce the behavior:

1. BlueTooth enabled.
2. View device browser to verify device is available and not blacklisted
3. Click "Launch Detection"
4. Nothing happens

Expected behavior
I believe this device should work since it's visible and seems to be covered by the H5102_json.h file.

Screenshots
N/A

Environment (please complete the following information):

• Apple iPhone 12

Additional context
N/A

Tested with version 1.1 (1010008)

Really nice list view indicating the CO2 state, and details widget with all the remaining properties!

On a smaller iOS screen the widget graphic has a slight clipping at the top.

Also wondering if CO2 could be written with subscript 2 - CO₂ everywhere - similar to the already implemented superscript ³ in the PM unit μg/m³

Tested with version 1.1 (1010008)

The current display shows ºRH for the unit of the humidity.

Should be using the percentage % sign instead of the degree º

I'm also don't think we need to specify the RH - Relative Humidty - only for this particular case, as all the other thermometer humidity displays only show % and they all are also showing the relative humidity. So just % will be fine here as well.

vs.

Describe the bug
Currently, we support the IBS-TH1 with its internal sensor. This sensor can also be connected to an external probe, when done the decoder advertise the data like below:

{"id":"","mac_type":0,"name":"sps","rssi":-64,"brand":"Inkbird","model":"TH Sensor","model_id":"IBS-TH1","cidc":false,"tempc2_ext":25.17,"tempf2_ext":77.306,"hum":60.31,"batt":81}

Note that it also advertize the internal sensor data:

Expected behavior
To be discussed

Environment (please complete the following information):

• Tested with this build on windows

Having the Mi Body Composition scale I would suggest the following implementation adjustments:

• shorter date/time format (possibly for all graph displays for all widgets), as with the current very long format, and at least my smaller screen real estate, there are clippings

possibly by omitting the day name completely or only using abbreviated day names and also abbreviated month names or using a coplete short date format, like 12/10/2022. Maybe also just a comma between the date and the time, to keep it as short as possible.

• Short from having to implement a complicated selection functionality, which I don't think is really necessary, I suggest to exclude any object weighing from the graphing data. I only got the above screenshot with the clipping while sliding along the graph from a previous 2,5 kg object weighing to a higher person weighing. I don't think many, if any, people would want to chart their object weighings, and the ups and down of having objets data in between the person data is unnecessary.

• Similar to the above, when an object is being weighed there shouldn't be the display of the last impedance data showing from the last barefoot person weighing. The same when a person is weighing themselves with socks or shoes on, and an impedance is not being broadcast, the last impedance values should not be displayed in either the widget nor the list view.

Hi @emericg and @1technophile,

just tested build 45f28e1 on macOS Catalina 10.15.7 (19H1922) and launching fine, scanning seems to work fine, but the Decoder side doesn't seem to work on macOS, only showing the list with all sensors as "No name" and the rssi.

Also the connection to my MQTT broker seems fine, showing up in MQTT Explorer, but only with the version message, and no device messages, due the non-decoding.

Or is this non-decoding expected at this stage?

Thanks

Assigned locations get cleared when closing/reopening the app, or when the app is being updated with a new version.

Verified on macOS and iOS

While trying out and testing

#8

and the Xiaomi Mi scales widget not showing any details for me, and digging in the code briefly I saw that currently only only the weight and impedance is included for display.

else if (boxDevice.isScale) {
                if (boxDevice.hasImpedance)
                    loaderIndicators.sourceComponent = componentText_2l
                else
                    loaderIndicators.sourceComponent = componentText_1l
            }

else if (boxDevice.isScale) {
                    text.text = (settingsManager.tempUnit === 'C') ? boxDevice.weight.toFixed(1) : (boxDevice.weight * 2.20462).toFixed(1)
                    unit.text = (settingsManager.tempUnit === 'C') ? qsTr("kg") : qsTr("lbs")
                }
…
else if (boxDevice.isScale) {
                    textOne.font.pixelSize = bigAssMode ? 26 : 24
                    textTwo.font.pixelSize = bigAssMode ? 22 : 20

                    textOne.text = (settingsManager.tempUnit === 'C') ? boxDevice.weight.toFixed(1) + qsTr("kg") : (boxDevice.weight * 2.20462).toFixed(1) + qsTr("lbs")
                    if (boxDevice.impedance > 0) textTwo.text = boxDevice.impedance + " Ω"
                }

This is a feature request to also include the weighing_mode for both models inn the widget on all platforms.

Currently the CO2 levels indicated in the CGDN1 CO2 semicircle and bar indicators seem to have a base value of 0.

The base CO2 level of clean fresh air however is around 400 ppm - these days - and cannot get lower no matter what.

So it might be a nice idea to use this 400 ppm base level as the actual base for these graphic indicators, as not to give the impression that a 406 ppm CO2 level, as in the example below, is only in the middle of the green CO2 concentration, when it actually is at the very low end of it.

The suggested value ranges would be

400 to <= 1000 = green
1000 to <= 2000 = orange
and >= 2000 = red

With generic devices being displayed on a generic widget page I would suggest the following

• if the unit is int show the value as a integer only without decimals, and do not show the unit
• if the unit is either string or status, just show the value without the unit
• if a status value is a boolean, show it as true/false and don't convert/display it to/as 1/0

Example from the SmartDry discussion for the Shake and Wake properties, but applicable to all other generic devices.

Shake
241

Wake
true

When opening the devices list, with the visual devices view to the right of it, the devices view often 'hides' devices outside the visible view size. This can be a bit confusing, especially when selecting a device in the left list, and then not seeing it at all in the right side view, until possibly making the app window wider.

In the sample video there is only one device with this issue, but I often observe this with multiple devices 'hiding'.

Unless there might be an easy fix to constrain the devices' dots drawing within the view, and since this is not really a vital functionality issue, it can be considered as nice to have possibly later or even not to be fixed.

Nothing major, but again going a long way in making the macOS build appear Mac like and adhering to macOS standards, it should have

About Theengs

Preferences ⌘,

on top of the current application menu items

These menu entries are the minimum of every single macOS application, and even Microsoft themselves adhere to that rule with every of their macOS applications.

Surprisingly enough, the Preferences keyboard shortcut ⌘, is already working and implemented in

https://github.com/theengs/app/blob/development/qml/DesktopApplication.qml#L299

and from reading

https://doc.qt.io/qt-6/qkeysequence.html

this Preferences StandardKey is a macOS only implementation already.

So adding these two menu items would only additionally require that the About Theengs would also go to/open appContent.state = "About" and the menu would look totally familiar and as expected to every macOS user.

The device name of my BT temperature sensor that I have set resets to the Mac address after a short period/a day.

is possible to read data over wifi from Inkbird IBS-TH3 ?

what other options are to read data from IBS-TH3 ?

Probably a macOS only issue, and as I don't know how the apps will be distributed eventually or if this is an artifact distribution problem, but every time I click to download the macOS binary I get a double zipped file in the download

the same with various browsers.

This then unzipps into

Theengs-1.0-macOS.zip

which then needs to be unzipped again into the final Theengs app.

I tried changing the various related .zip options in

builds_desktop.yml
and
deploy_macos.sh

but the only things which really changed something for me was changing
name: ${{env.APPLICATION}}-${{env.VERSION}}-macOS.zip
to
name: ${{env.APPLICATION}}-${{env.VERSION}}-macOS

which gave a single zip

Theengs-1.0-macOS.zip

download name in the browsers, but still resulted in having to be double unzipped ;)

Nothing more than a bit annoying at the moment, but might needs looking into for a wider user base.

BTW, the same thing happens when downloading the Theengs-1.0-win64.zip on macOS.

With the recent testing of the app's MQQT integration with version 1.2, and for logging #52 I found that the newly introduced Home Assistant discovery is not optional, but seems to be always active.

With my all manually textually defined OpenHAB setup I would rather not have all the auto discovered devices piling up in my in-box, but would like to be able to use the MQTT integration without discovery.

I have. A chinies bbq ble meter, that I saw in the GitHub it should have a decoder, also I have inkibird bbq.

It does not show in the android app

Describe the bug
I bought the android application to send data from my LYWSD03MMC to mqtt server but it's not happening. App has found my sensor, connected with it, connected with mqtt server and even sent data to it (home/TheengsApp/version) but it doesn't send any data from the sensor.

To Reproduce
Steps to reproduce the behavior:

1. Run app on android device
2. Connect with LYWSD03MMC and mqtt server
3. There is no data on mqtt server

Expected behavior
Data should appear on mqtt server

Screenshots

Environment (please complete the following information):

version: 1.2
phone: Redmi Note 7, Android 10, MIUI 12.5.3
mqtt: mosquitto in docker container
mqtt client: mqtt explorer subscribed to #, $SYS/#, home/#, no authorization

Additional context
Add any other context about the problem here.

• You should not have a compilation error if you use the versions of the libraries linked into the libraries folder, this badges show you the state of the compilation
  
• If you are not sure this is a bug or an enhancement post your question to the forum

Curently the macOS app only has an icon in the dock when launched, with an alpha channel

but the app itself in the Finder does not have it's own icon, but displays with a generic App icon.

Followed the Apple guidlines to create a white background alpha rounded corner drop shadow .icns file

The dock icon is still showing the full alpha version though, so am not sure how this was implemented.

Does it need

ICON = theengs.icns

in the build instructions?

https://doc.qt.io/qt-6/appicon.html

Might be iOS only? Needs verification on Android.

When I want to get the widget view graphs details pop-ups I would expect the pop-ups to appear for the initial touch down event, then being able to slide along for the pop-ups to show the history details.

The initial pop-ups, and it's related vertical time line indicator, only show up with by first touch up event though.

Making it a bit unexpected and awkward with touch down - wondering - touch up - now I see them - touch down again and slide to get what I wanted.

Same when the pop-ups and time line indicator is already showing, touch down at a new location doesn't do anything, as would be expected, only touch up again makes the indicator and pup-up values jump to the newly selected position.

Describe the bug
impossible to get connection to Hive MQ
Top right stay DISCONNECTED
ID/PASSWORD double checked

To Reproduce
HiveMQ Cloud
APP on android / samsung galaxyJ7 prime

Theengs.pdf

Expected behavior
should connect to broker to statrt push MSG

Screenshots
If applicable, add screenshots to help explain your problem.

Environment (please complete the following information):

• version used (V0.9.3, 0.8, development)
• v1.0
• Context of your projec

Additional context
Add any other context about the problem here.

• You should not have a compilation error if you use the versions of the libraries linked into the libraries folder, this badges show you the state of the compilation
  
• If you are not sure this is a bug or an enhancement post your question to the forum

Describe the bug
When using the paid Theengs app on iOS on an iPhone 14 Pro Max running iOS 16.4.1(a), the Theengs app does not show any Sensors on the Sensors tab even though Bluetooth permissions have been granted.

To Reproduce
Steps to reproduce the behavior:

1. Open the Theengs app.
2. Tap on Sensors from the hamburger menu.
3. Tap Launch Detection
4. (No sensors show up)

Expected behavior
Sensors should be shown on the Sensors screen.

Screenshots

Environment (please complete the following information):

• iOS App Version: 1.3.1

Additional context
When tapping on Device Browser, I can scan for nearby BLE devices, one of which is a BlueCharms BC08 Beacon, which is listed as supported on the Theengs documentation. I can blacklist the sensor and whitelist it from this view, but no sensors show up at all on the Sensors list, no matter how many refreshes take place.

While on the main list view page a (from very left edge of the screen to the right) swipe brings up the options side bar, otherwise called up by the burger menu, but when being in a detail widget view this swipe should adhere to the iOS standard of going back - as not to have to reach all the way up to the top left to hit the back arrow.

If the swipe behaviour cannot be assigned differently to different view I'd prefer it to always have the default back behaviour as this would be user a lot more often than calling up the options side bar.

The default behaviour can most easily be seen in the iOS Preferences, and most other iOS apps.

I saw this before on a previous version, but didn't pay too much attention to it. Now with it still showing with 1.1.1 (1010101)

Going into the widget view of a IBS-TH1 the first thing that is apparent is that one of the graphs - the blue one - is cut off and stop well before the current date, although both the temperature and humidity are always broadcast together and therefore I assume are recorded together.

Assuming the blue graph indicates the humidity and green the temperature, sliding over the graph to get the details display, neither the humidity, nor the temperature changes align with the currently displayed blue graph.

Looking at the jumps of the green graph it almost looks like the blue graph is somehow time condensed, and would fit along with the green graph and the details changes if it was also stretched out over the whole time line - as can also been seen by both the temperature and humidity details views during sliding, even for the section after the blue graph has stopped.

Assigned MAC addresses get cleared when closing the app and opening it again, verified on macOS and iOS 1.2

This requires any MAC addresses to be entered again for all devices to be able to get functioning published MQTT messages again.

The assigned MAC addresses need to be persistent across app restarts.

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:

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Segmentation fault: 11
Termination Reason:    Namespace SIGNAL, Code 0xb
Terminating Process:   exc handler [2308]

VM Regions Near 0:
--> 
    __TEXT                 0000000103a9e000-0000000103bda000 [ 1264K] r-x/r-x SM=COW  /Applications/Theengs.app/Contents/MacOS/Theengs

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_platform.dylib      	0x00007fff6c1559c2 _platform_memmove$VARIANT$Haswell + 194
1   com.theengs.app               	0x0000000103ab5565 TheengsDecoder::decodeBLEJson(ArduinoJson6183_71::ObjectRef&) + 6293
2   com.theengs.app               	0x0000000103ada84a DeviceManager::createTheengsDevice_fromAdv(QBluetoothDeviceInfo const&) + 5402
3   com.theengs.app               	0x0000000103acd1c2 DeviceManager::addBleDevice(QBluetoothDeviceInfo const&) + 5634
4   com.theengs.app               	0x0000000103ad678d DeviceManager::updateBleDevice(QBluetoothDeviceInfo const&, QFlags<QBluetoothDeviceInfo::Field>) + 10189
5   org.qt-project.QtCore         	0x0000000105b279d4 0x105a68000 + 784852
6   org.qt-project.QtBluetooth    	0x000000010526a244 QBluetoothDeviceDiscoveryAgent::deviceDiscovered(QBluetoothDeviceInfo const&) + 52
7   org.qt-project.QtBluetooth    	0x00000001052ba2ca 0x105262000 + 361162
8   org.qt-project.QtCore         	0x0000000105b200e9 QObject::event(QEvent*) + 729
9   org.qt-project.QtWidgets      	0x0000000104477da7 QApplicationPrivate::notify_helper(QObject*, QEvent*) + 247
10  org.qt-project.QtWidgets      	0x0000000104478d63 QApplication::notify(QObject*, QEvent*) + 499
11  org.qt-project.QtCore         	0x0000000105ad73ba QCoreApplication::notifyInternal2(QObject*, QEvent*) + 170
12  org.qt-project.QtCore         	0x0000000105ad8373 QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) + 803
13  libqcocoa.dylib               	0x00000001080e8bdb 0x1080cf000 + 105435
14  libqcocoa.dylib               	0x00000001080e92eb 0x1080cf000 + 107243
15  com.apple.CoreFoundation      	0x00007fff32ee0f92 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
16  com.apple.CoreFoundation      	0x00007fff32ee0f31 __CFRunLoopDoSource0 + 103
17  com.apple.CoreFoundation      	0x00007fff32ee0d4b __CFRunLoopDoSources0 + 209
18  com.apple.CoreFoundation      	0x00007fff32edfa7a __CFRunLoopRun + 927
19  com.apple.CoreFoundation      	0x00007fff32edf07e CFRunLoopRunSpecific + 462
20  com.apple.HIToolbox           	0x00007fff31b5daad RunCurrentEventLoopInMode + 292
21  com.apple.HIToolbox           	0x00007fff31b5d7c5 ReceiveNextEventCommon + 584
22  com.apple.HIToolbox           	0x00007fff31b5d569 _BlockUntilNextEventMatchingListInModeWithFilter + 64
23  com.apple.AppKit              	0x00007fff301a63c9 _DPSNextEvent + 883
24  com.apple.AppKit              	0x00007fff301a4c10 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1352
25  com.apple.AppKit              	0x00007fff3019691e -[NSApplication run] + 658
26  libqcocoa.dylib               	0x00000001080e80fc 0x1080cf000 + 102652
27  org.qt-project.QtCore         	0x0000000105ae0446 QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) + 486
28  org.qt-project.QtCore         	0x0000000105ad79b5 QCoreApplication::exec() + 133
29  com.theengs.app               	0x0000000103abae04 main + 3828
30  libdyld.dylib                 	0x00007fff6bf5fcc9 start + 1

Thread 1:
0   libsystem_pthread.dylib       	0x00007fff6c15fb68 start_wqthread + 0

Thread 2:
0   libsystem_pthread.dylib       	0x00007fff6c15fb68 start_wqthread + 0

Thread 3:
0   libsystem_pthread.dylib       	0x00007fff6c15fb68 start_wqthread + 0

Thread 4:: com.apple.CFSocket.private
0   libsystem_kernel.dylib        	0x00007fff6c0a90ee __select + 10
1   com.apple.CoreFoundation      	0x00007fff32f09e93 __CFSocketManager + 641
2   libsystem_pthread.dylib       	0x00007fff6c164109 _pthread_start + 148
3   libsystem_pthread.dylib       	0x00007fff6c15fb8b thread_start + 15

Thread 5:: QQmlThread
0   libsystem_kernel.dylib        	0x00007fff6c0a73c6 poll + 10
1   org.qt-project.QtCore         	0x0000000105c5d98e qt_safe_poll(pollfd*, unsigned int, timespec const*) + 94
2   org.qt-project.QtCore         	0x0000000105c5f258 QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) + 792
3   org.qt-project.QtCore         	0x0000000105ae0446 QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) + 486
4   org.qt-project.QtCore         	0x0000000105bd9b1a QThread::exec() + 282
5   org.qt-project.QtQml          	0x00000001055b11a7 0x1053bb000 + 2056615
6   org.qt-project.QtCore         	0x0000000105c635f3 0x105a68000 + 2078195
7   libsystem_pthread.dylib       	0x00007fff6c164109 _pthread_start + 148
8   libsystem_pthread.dylib       	0x00007fff6c15fb8b thread_start + 15

Thread 6:: Thread (pooled)
0   libsystem_kernel.dylib        	0x00007fff6c0a3872 __psynch_cvwait + 10
1   libsystem_pthread.dylib       	0x00007fff6c164425 _pthread_cond_wait + 698
2   org.qt-project.QtCore         	0x0000000105c6dab6 0x105a68000 + 2120374
3   org.qt-project.QtCore         	0x0000000105c6d7ce 0x105a68000 + 2119630
4   org.qt-project.QtCore         	0x0000000105c6d71e QWaitCondition::wait(QMutex*, QDeadlineTimer) + 94
5   org.qt-project.QtCore         	0x0000000105c67c6f 0x105a68000 + 2096239
6   org.qt-project.QtCore         	0x0000000105c635f3 0x105a68000 + 2078195
7   libsystem_pthread.dylib       	0x00007fff6c164109 _pthread_start + 148
8   libsystem_pthread.dylib       	0x00007fff6c15fb8b thread_start + 15

Thread 7:: Thread (pooled)
0   libsystem_kernel.dylib        	0x00007fff6c0a3872 __psynch_cvwait + 10
1   libsystem_pthread.dylib       	0x00007fff6c164425 _pthread_cond_wait + 698
2   org.qt-project.QtCore         	0x0000000105c6dab6 0x105a68000 + 2120374
3   org.qt-project.QtCore         	0x0000000105c6d7ce 0x105a68000 + 2119630
4   org.qt-project.QtCore         	0x0000000105c6d71e QWaitCondition::wait(QMutex*, QDeadlineTimer) + 94
5   org.qt-project.QtCore         	0x0000000105c67c6f 0x105a68000 + 2096239
6   org.qt-project.QtCore         	0x0000000105c635f3 0x105a68000 + 2078195
7   libsystem_pthread.dylib       	0x00007fff6c164109 _pthread_start + 148
8   libsystem_pthread.dylib       	0x00007fff6c15fb8b thread_start + 15

Thread 8:: Thread (pooled)
0   libsystem_kernel.dylib        	0x00007fff6c0a3872 __psynch_cvwait + 10
1   libsystem_pthread.dylib       	0x00007fff6c164425 _pthread_cond_wait + 698
2   org.qt-project.QtCore         	0x0000000105c6dab6 0x105a68000 + 2120374
3   org.qt-project.QtCore         	0x0000000105c6d7ce 0x105a68000 + 2119630
4   org.qt-project.QtCore         	0x0000000105c6d71e QWaitCondition::wait(QMutex*, QDeadlineTimer) + 94
5   org.qt-project.QtCore         	0x0000000105c67c6f 0x105a68000 + 2096239
6   org.qt-project.QtCore         	0x0000000105c635f3 0x105a68000 + 2078195
7   libsystem_pthread.dylib       	0x00007fff6c164109 _pthread_start + 148
8   libsystem_pthread.dylib       	0x00007fff6c15fb8b thread_start + 15

Thread 9:: Thread (pooled)
0   libsystem_kernel.dylib        	0x00007fff6c0a3872 __psynch_cvwait + 10
1   libsystem_pthread.dylib       	0x00007fff6c164425 _pthread_cond_wait + 698
2   org.qt-project.QtCore         	0x0000000105c6dab6 0x105a68000 + 2120374
3   org.qt-project.QtCore         	0x0000000105c6d7ce 0x105a68000 + 2119630
4   org.qt-project.QtCore         	0x0000000105c6d71e QWaitCondition::wait(QMutex*, QDeadlineTimer) + 94
5   org.qt-project.QtCore         	0x0000000105c67c6f 0x105a68000 + 2096239
6   org.qt-project.QtCore         	0x0000000105c635f3 0x105a68000 + 2078195
7   libsystem_pthread.dylib       	0x00007fff6c164109 _pthread_start + 148
8   libsystem_pthread.dylib       	0x00007fff6c15fb8b thread_start + 15

Thread 10:: QQuickPixmapReader
0   libsystem_kernel.dylib        	0x00007fff6c0a73c6 poll + 10
1   org.qt-project.QtCore         	0x0000000105c5d98e qt_safe_poll(pollfd*, unsigned int, timespec const*) + 94
2   org.qt-project.QtCore         	0x0000000105c5f258 QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) + 792
3   org.qt-project.QtCore         	0x0000000105ae0446 QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) + 486
4   org.qt-project.QtCore         	0x0000000105bd9b1a QThread::exec() + 282
5   org.qt-project.QtQuick        	0x0000000103e38d61 0x103c4c000 + 2018657
6   org.qt-project.QtCore         	0x0000000105c635f3 0x105a68000 + 2078195
7   libsystem_pthread.dylib       	0x00007fff6c164109 _pthread_start + 148
8   libsystem_pthread.dylib       	0x00007fff6c15fb8b thread_start + 15

Thread 11:
0   libsystem_pthread.dylib       	0x00007fff6c15fb68 start_wqthread + 0

Thread 12:: Dispatch queue: com.Metal.CommandQueueDispatch
0   libsystem_kernel.dylib        	0x00007fff6c0a0e26 semaphore_wait_trap + 10
1   libdispatch.dylib             	0x00007fff6bf06aed _dispatch_sema4_wait + 16
2   libdispatch.dylib             	0x00007fff6bf06fbf _dispatch_semaphore_wait_slow + 98
3   com.apple.Metal               	0x00007fff383f4c08 -[_MTLCommandQueue _submitAvailableCommandBuffers] + 909
4   libdispatch.dylib             	0x00007fff6bf06658 _dispatch_client_callout + 8
5   libdispatch.dylib             	0x00007fff6bf08818 _dispatch_continuation_pop + 414
6   libdispatch.dylib             	0x00007fff6bf184be _dispatch_source_invoke + 2084
7   libdispatch.dylib             	0x00007fff6bf0baf6 _dispatch_lane_serial_drain + 263
8   libdispatch.dylib             	0x00007fff6bf0c5d6 _dispatch_lane_invoke + 363
9   libdispatch.dylib             	0x00007fff6bf15c09 _dispatch_workloop_worker_thread + 596
10  libsystem_pthread.dylib       	0x00007fff6c160a3d _pthread_wqthread + 290
11  libsystem_pthread.dylib       	0x00007fff6c15fb77 start_wqthread + 15

Thread 13:
0   libsystem_pthread.dylib       	0x00007fff6c15fb68 start_wqthread + 0

Thread 14:: QSGRenderThread
0   libsystem_kernel.dylib        	0x00007fff6c0a0e3e semaphore_timedwait_trap + 10
1   libdispatch.dylib             	0x00007fff6bf06b6b _dispatch_sema4_timedwait + 76
2   libdispatch.dylib             	0x00007fff6bf06f97 _dispatch_semaphore_wait_slow + 58
3   com.apple.QuartzCore          	0x00007fff3e7f661f -[CAMetalLayer nextDrawable] + 837
4   org.qt-project.QtGui          	0x0000000104f0a3f5 0x104a7d000 + 4772853
5   org.qt-project.QtGui          	0x0000000104cc72ab QRhiCommandBuffer::beginPass(QRhiRenderTarget*, QColor const&, QRhiDepthStencilClearValue const&, QRhiResourceUpdateBatch*, QFlags<QRhiCommandBuffer::BeginPassFlag>) + 43
6   org.qt-project.QtQuick        	0x0000000103d857c1 QSGBatchRenderer::Renderer::render() + 81
7   org.qt-project.QtQuick        	0x0000000103da0b4e QSGRenderer::renderScene() + 302
8   org.qt-project.QtQuick        	0x0000000103d47f19 QQuickWindowPrivate::renderSceneGraph(QSize const&, QSize const&) + 841
9   org.qt-project.QtQuick        	0x0000000103f02b44 0x103c4c000 + 2845508
10  org.qt-project.QtQuick        	0x0000000103f03a91 0x103c4c000 + 2849425
11  org.qt-project.QtCore         	0x0000000105c635f3 0x105a68000 + 2078195
12  libsystem_pthread.dylib       	0x00007fff6c164109 _pthread_start + 148
13  libsystem_pthread.dylib       	0x00007fff6c15fb8b thread_start + 15

Thread 15:: CVDisplayLink
0   libsystem_kernel.dylib        	0x00007fff6c0a3872 __psynch_cvwait + 10
1   libsystem_pthread.dylib       	0x00007fff6c164457 _pthread_cond_wait + 748
2   com.apple.CoreVideo           	0x00007fff34e76cdb CVDisplayLink::waitUntil(unsigned long long) + 229
3   com.apple.CoreVideo           	0x00007fff34e761e8 CVDisplayLink::runIOThread() + 482
4   libsystem_pthread.dylib       	0x00007fff6c164109 _pthread_start + 148
5   libsystem_pthread.dylib       	0x00007fff6c15fb8b thread_start + 15

Thread 16:: com.apple.NSEventThread
0   libsystem_kernel.dylib        	0x00007fff6c0a0dea mach_msg_trap + 10
1   libsystem_kernel.dylib        	0x00007fff6c0a1160 mach_msg + 60
2   com.apple.CoreFoundation      	0x00007fff32ee1135 __CFRunLoopServiceMachPort + 247
3   com.apple.CoreFoundation      	0x00007fff32edfc02 __CFRunLoopRun + 1319
4   com.apple.CoreFoundation      	0x00007fff32edf07e CFRunLoopRunSpecific + 462
5   com.apple.AppKit              	0x00007fff30347bf4 _NSEventThread + 132
6   libsystem_pthread.dylib       	0x00007fff6c164109 _pthread_start + 148
7   libsystem_pthread.dylib       	0x00007fff6c15fb8b thread_start + 15

Thread 17:: Thread (pooled)
0   libsystem_kernel.dylib        	0x00007fff6c0a3872 __psynch_cvwait + 10
1   libsystem_pthread.dylib       	0x00007fff6c164425 _pthread_cond_wait + 698
2   org.qt-project.QtCore         	0x0000000105c6dab6 0x105a68000 + 2120374
3   org.qt-project.QtCore         	0x0000000105c6d7ce 0x105a68000 + 2119630
4   org.qt-project.QtCore         	0x0000000105c6d71e QWaitCondition::wait(QMutex*, QDeadlineTimer) + 94
5   org.qt-project.QtCore         	0x0000000105c67c6f 0x105a68000 + 2096239
6   org.qt-project.QtCore         	0x0000000105c635f3 0x105a68000 + 2078195
7   libsystem_pthread.dylib       	0x00007fff6c164109 _pthread_start + 148
8   libsystem_pthread.dylib       	0x00007fff6c15fb8b thread_start + 15

Thread 18:: Thread (pooled)
0   libsystem_kernel.dylib        	0x00007fff6c0a3872 __psynch_cvwait + 10
1   libsystem_pthread.dylib       	0x00007fff6c164425 _pthread_cond_wait + 698
2   org.qt-project.QtCore         	0x0000000105c6dab6 0x105a68000 + 2120374
3   org.qt-project.QtCore         	0x0000000105c6d7ce 0x105a68000 + 2119630
4   org.qt-project.QtCore         	0x0000000105c6d71e QWaitCondition::wait(QMutex*, QDeadlineTimer) + 94
5   org.qt-project.QtCore         	0x0000000105c67c6f 0x105a68000 + 2096239
6   org.qt-project.QtCore         	0x0000000105c635f3 0x105a68000 + 2078195
7   libsystem_pthread.dylib       	0x00007fff6c164109 _pthread_start + 148
8   libsystem_pthread.dylib       	0x00007fff6c15fb8b thread_start + 15

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x00007ffeec15f391  rbx: 0x00007ffeec15f391  rcx: 0x0000000000000008  rdx: 0x0000000000000004
  rdi: 0x00007ffeec15f391  rsi: 0x0000000000000000  rbp: 0x00007ffeec15f280  rsp: 0x00007ffeec15f280
   r8: 0x0000000000000000   r9: 0x0000000000000fa0  r10: 0x00007ff30f95ec70  r11: 0x00007ffeec15f391
  r12: 0x0000000000000000  r13: 0x0000000000000004  r14: 0x00007ff30f95c04d  r15: 0x0000000000000000
  rip: 0x00007fff6c1559c2  rfl: 0x0000000000010246  cr2: 0x0000000000000000
  
Logical CPU:     4
Error Code:      0x00000004 (no mapping for user data read)
Trap Number:     14