Migration from Legacy SNAPtoolbelt (Py2)

This page includes notable changes from SNAPtoolbelt (Py2).

Output format is always JSON

SNAPtoolbelt now relies more on external tools for formatting its output.

Example unformatted output:

$ toolbelt node bridge info
{"current.channel":"12","current.network-id":"0x1234","device.address":"00:1c:2c:00:26:06:a7:f2","device.feature-bits":"0x0d1f","device.name":null,"device.platform":"SN220","device.script-crc":"0x3771","device.script-name":"temp","device.type":"thing","device.vendor-config-bits":"0x4003","firmware.core":"2.8.2","firmware.cpu":"ATMEGA","firmware.platform":"SM220/RF220UF1/SN220","firmware.rev":"(Apr  4 2017 / 6f4980c)","security.enable-encryption":"AES-128","security.lockdown-bitmask":null}


The jq utility can - among other things - be used to pretty-print this output:

$ toolbelt node bridge info | jq .
    "current.channel": "12",
    "current.network-id": "0x1234",
    "device.address": "00:1c:2c:00:26:06:a7:f2",
    "device.feature-bits": "0x0d1f",
    "device.name": null,
    "device.platform": "SN220",
    "device.script-crc": "0x3771",
    "device.script-name": "temp",
    "device.type": "thing",
    "device.vendor-config-bits": "0x4003",
    "firmware.core": "2.8.2",
    "firmware.cpu": "ATMEGA",
    "firmware.platform": "SM220/RF220UF1/SN220",
    "firmware.rev": "(Apr  4 2017 / 6f4980c)",
    "security.enable-encryption": "AES-128",
    "security.lockdown-bitmask": null

See https://jqlang.github.io/jq/ for more info.


Miller’s xtab format is the closest to what SNAPtoolbelt (Py2) called dkvp (delimited key-value pairs).

$ toolbelt node bridge info | mlr --ijson --oxtab cat
current.channel            12
current.network-id         0x1234
device.address             00:1c:2c:00:26:06:a7:f2
device.feature-bits        0x0d1f
device.name                null
device.platform            SN220
device.script-crc          0x3771
device.script-name         temp
device.type                thing
device.vendor-config-bits  0x4003
firmware.core              2.8.2
firmware.cpu               ATMEGA
firmware.platform          SM220/RF220UF1/SN220
firmware.rev               (Apr  4 2017 / 6f4980c)
security.enable-encryption AES-128
security.lockdown-bitmask  null

See https://miller.readthedocs.io/en/latest/ for more info.

Configuration changes

Configuration is now a SQLite DB

This helped us fix a long-standing bug in SNAPtoolbelt (Py2) where file I/O glitches would sometimes result in a change to one profile or network causing the deletion of all other profiles or networks.

Use toolbelt config import to import the SNAPtoolbelt (Py2) configuration into SNAPtoolbelt.

config scan updates profiles w/ matching names

Since 2.10+ Core has improved the UART handling, it’s not unreasonable to run w/ your bridge at 115200 instead of 38400. When you re-scan, if we find the bridge at 115200, we’ll update the profile to indicate that, rather than create a new profile.

Logging is controlled by RUST_LOG

This is on the “things to fix” list, but for now, if you need more logging info, you’ll need to set the RUST_LOG environment variable, rather than using the -l flag. (That flag is still recognized, but its value isn’t used, because the logging library we started with doesn’t support reconfiguring the log level on the fly.)

For example:

$ RUST_LOG=debug toolbelt node bridge ping

All RPCs are dmcast by default

All operations (node info, &c.) are done via dmcast RPCs.

Exceptions: You can still send unicast RPCs with toolbelt rpc send unicast and toolbelt rpc call unicast, and you can do unicast firmware and script uploads with toolbelt node $TARGET firmware unicast-upload and toolbelt node $TARGET script unicast-upload.