I see that you made some changes. It is still not very clear however that both DEVEUI and APPEUI should be in MSB format.
I.m.o. you could have left the original comments (only add MSB to the DEVUI comment just like APPEUI) and then add a separate brief remark on top, something like:
Note that DEVEUI, APPEUI and APPKEY should all be specified in MSB format.
(This is different from standard LMIC-Arduino which expects DEVEUI and APPEUI in LSB format.)
Please make pull request.
It worked 
Somehow it doesnāt find my own phone and BLE watch (OnePlus 5T and Gear S3). Is it possible that those are not in the vendor file?
Yes, this is possible. The static vendor OUI list in vendor_array.h is a workaround. Would be great, if someone could contribute a better solution here to the project.
You may try switching off vendor filtering by commenting out line #define VENDORFILTER in paxcounter.conf, after this your smartphone should be counted.
Besides that, you should update the software. I found a bug causing breaking the LoRaWAN transmit sometimes (āLORA BUSYā) and solved this today. And i made some modifications to speed up Wifi and Bluetooth scan.
I switched off vendor filtering, but it looks like it still can not find my phone and BLE watch. Weird.
Regarding the vendor OUI, The following project has a complete list published which might be of interest.
I found that a MAC address spoof filter can be made. Filter all MAC addresses when the 2nd character of the MAC is a 2, 6, a or e.
P.s. can you explain a bit more how you have completed the list, so I can understand it and might help you.
You can try to modify the Bluetooth timing parameters Window + Interval in paxcounter.conf, and check again if your devices are regonized.
Filtering MACs: whatās the rationale behind your filtering scheme? I canāt see the specs in IEEE802.x what match against this?
I general i donāt expect to get absolute valid valuea from this approach to count people. But it still gives a reasonable metering for very low price and installation effort.
TTGO v2 with new 1.3.6 version of paxcounter software
New TTGO v2.1 working stable with paxcounter v1.3.6
(But blue battery indicator LEDs are far to bright)
Just found the fix of the ino file on Github, thank you!
āplatform.ini: enforcing espressif32 v0.12.0, otherwise .elf too largeā
That error was driving me crazy for the better part of yesterday.
And iām driven crazy by the new v1.0.0 of espressif32 platform, which causes to grow the binary of paxcounter code by 30% (300kb). No chance to shrink code to compensate this.
Has anyone an idea how to solve this?
See @paulbās suggestion: Enforce PlatformIO to use an older (v0.12.0) version of the Espressif 32 platform for the project:
In platformio.ini specify: platform = espressif32@0.12.0
30% binary image increase using the new Espressif32 v1.0.0 platform. Hopefully this is a bug that can be fixed (soon).
FYI latest version is v1.0.1. See https://github.com/platformio/platform-espressif32/releases.
same problem with latest version.
I already expected because the release notes mention nothing about code size issues.
Not sure of this is a problem of espressif32 platform lib, or arduino-espressif32 lib.
I forced paxcounter project in paxcounter.ini to use espressif32 platform v0.12.0, which generates suitable binary footprint.
It is possible to increase flash memory partition for app code of esp32 boards by modifying their partition table, but this is board dependent and needs some tayloring of the IDE. I decided to not offer this, as long as espressif32 v0.12.0 exists. The paxcounter code runs stable on top of v0.12.0. I have a handful different boards running in continously test. Pycom Lopy has nearly 40 days uptime now, without reset. So donāt change a running system.
A new v1.0.x of the Espressif 32 framework should not have such a dramatic impact that code size suddenly increases 30%. Starting to modify partition tables sounds like trying to fix symptoms instead of trying to find and (let) fix the actual cause of the problem.
Weāre talking on embedded frameworks here. Binary file growth by 300Kb as seen here with not one byte of source code changed is not acceptable.
Iām keeping the code on Espressif32 platform v0.12.0, but nevertheless i gave the new platform version 1.0.1 a try by increasing the app flash memory partition.
This can be done by changing the partition table.
I used āmin_spiffs.csvā which can be found in
...\.platformio\packages\framework-arduinoespressif32\tools\partitions
This way you get 1,88 MB of flash memory for the application code (instead of 1,25 MB with default partition table):
PLATFORM: Espressif 32 > Espressif ESP32 Dev Module
SYSTEM: ESP32 240MHz 288KB RAM (1.88MB Flash)
DEBUG: CURRENT(minimodule) EXTERNAL(minimodule, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h)
This is enough to upload the paxcounter binary with Espressif32 1.0.1 version. It seems the code is running without issues, but i need to further test this.
But running the code we see the next memory leak: RAM space decreased from around 80KB with 0.12.0 to 50KB with 1.0.1 
The footprint of the new v1.0.1 seems too bold for embedded software to me.
I found a way to completely automate partition table switching in PlatformIO.
New paxcounter version 1.3.7 created, now running on top of new Espressif32 v1.0.1 platform.
You can find it in development branch of repo.
Please test!
I also found this today.
I see that you explicitly specify board_upload.maximum_size.
I had the impression that this was read from the partition table csv automatically, because specifying a different preset partition (e.g. no_ota) did make it upload successfully without error message, without having to explicitly specify maximum_size.
The underlying problem - the 30% size increase between compiling v0.12.0 and compiling with v1.0.x - however still exists.
I also tested with the Blink sketch. This gave an increase of 3% (not the 30% increase of Paxcounter).
If you use the construct below that will require changes to be made only once in a single place instead of separately for each boardtype:
[common_env_data]
platform_espressif32 = espressif32@>=1.0.1
board_build.partitions = no_ota.csv
[env:<boardtype>]
platform = ${common_env_data.platform_espressif32}
board_build.partitions = ${common_env_data.board_build.partitions}
(When using board_build.partitions with versions older than 1.0.0 the .csv extension has to be omitted and only preset default.csv exists.)
Thatās a good hint, thank you. I changed platformio.ini this way in the development branch.
I tried to remove max size definition, but then platformio is using the default which is given in the board json. To me it seems necessary to override a definition in .json by explicitly define it. Did you find another way?