Extension: add pxt-blelog

[martinwork]

Arising from https://support.microbit.org/helpdesk/tickets/63434 (private)
@bsiever

https://makecode.microbit.org/_34pTvM91Jb7F

@abchatra

The block was intended to appear under group heading "micro:bit (V2)", but it seems this is not possible with a single block.

pxt-microbit/libs/datalogger/datalogger.ts

Line 284 in 6c8fff5

// TODO:/note intentionally does not have group, as having the same group for all

The extension has a yotta definition for open security
https://github.com/bsiever/pxt-blelog/blob/master/pxt.json#L43

This is not reflected in Project Settings and the user choice seems to be ignored, unless I choose passkey security, and look at settings as text - then there is a brief red error message (conflict on yotta setting...), followed by this:

Extension repo: https://github.com/bsiever/pxt-blelog

[abchatra]

@martinwork Yes with only one block there is no support for subcategory. You can denote V2 only in the image of the extension similar to data logger.

Is the error question for me?

[martinwork]

@abchatra
Thanks for mentioning the extension dialogue card. I didn't think of that!

@abchatra @bsiever
I flagged the problem with the Bluetooth security options for everyone to check.

Maybe it is not expected that the user chooses passkey, but what happens if they do seems broken and leads to code loss. I didn't try clicking Remove this!

@bsiever
Perhaps it would be better to let the user choose security level.

@bsiever
Could the icon and text be changed like this?

[bsiever]

I had already updated the tile text to indicate micro:bit (V2) (thanks to @martinwork's earlier concern about it), but I've updated the icon now too.

Thanks to some guidance from Martin, I've tried switching from yotta-based BLE settings. Unfortunately, there seem to be some quirks I haven't yet resolved.

For the time being I'm leaving the yotta settings. I'll look into it more as time permits. I hope to switch to the CODAL approach when I understand what's different. Details are below, but perhaps aren't relevant to this PR.

---

Yotta config:

    "yotta": {
        "config": {
            "microbit-dal": {
                "bluetooth": {
                    "open": 1
                }
            }
        }
    }

For CODAL-based settings I've tried both:

"config":{
        "DEVICE_BLE": 1,
        "MICROBIT_BLE_OPEN": 1
}

and:

    "config": {
        "DEVICE_BLE": 1,
        "MICROBIT_BLE_PAIRING_MODE": 0,
        "MICROBIT_BLE_SECURITY_MODE": 0,
        "MICROBIT_BLE_WHITELIST": 0,
        "MICROBIT_BLE_ADVERTISING_TIMEOUT": 0
    }

I need to do more testing and review, but neither worked quite like the yotta approach. I think the simple "open" led the micro:bit to show up as two bluetooth devices (one for pairing and one not). The CODAL approaches both also seemed to default to operating-system level pairing when I tried to connect. That can lead to a bad user experience following updates to the code (inconsistent connection behaviors). I'm still looking into how the yotta settings are translated into configuration options, but I'm at the end of my allocated "play time" today 😞, so I'll come back to it later.

[bsiever]

Just to confirm, I did update the icon:

This leaves the security settings issue. It seems like the problem is due to how the pxt.jsons in files and extensions are combined (not under my control). I'm open to different perspectives or conforming to requirements as necessary, but I deliberately selected security this way for a few reasons:

• I want it to be very easy to use. The pairing approach has always been clunky and prone to opaque errors for users (i.e., computer/mobile is paired, but micro:bit was re-programmed and lost the key... Devices will connect, but not behave correctly). It also requires pairing in-advance of deployment of a data collecting device, which may not be obvious to users.
• I'm not sure many users try to change the BLE security that much, other than to disable it. The error seems unlikely to come up for most users.
• The extension is meant to work with a matching library/app to retrieve data. I would expect users to mostly follow the guidance of the app(s).
  • The block set provides (weak) application-level security. If the user creates a program that includes a passphrase, data can not be read without the passphrase. ("Weak" in the sense that the passphrase could be sniffed out, but that requires close proximity and moderate effort)
  • The log data is numeric (and headers). There's not a lot of risk of the data itself revealing sensitive information.

Please let me know if anything else is needed on my end for approval.