BTHome: New feature

[miri64]

Contribution description

Little weekend (or rather Thursday and Friday night) project of mine. This extends Skald, who advertises to the world with BTHome, "an energy efficient but flexible BLE format for devices to broadcast their sensor data and button presses". The main use case is to integrate BLE-powered devices into Home Assistant.

Most of the spec is supported, except "Trigger based advertisements" (since Skald at the moment only advertises periodically). For encryption, I was able to confirm with the spec examples that at least from the generated output
is the expected one, given the example input, but Home Assistant is for some reason not able to decrypt the message (even the one in the examples)... So further investigation is needed.

TODOs:

• Investigate why encryption does not work with HA
• Finish doc

Testing procedure

• TODO: Provide tests

So far only tested by flashing a node and seeing the device pop-up in Home Assistant:

Issues/PRs references

None

[miri64]

Investigate why encryption does not work with HA

After talking to @BOZHENG001, I think the problem is that Skald is implementing an older BLE version than BTHome expects and thus fields (such as TXAdd which is used as part of the nonce for encryption) are not in the place Home Assistant expects them to be. Will try to confirm this somehow.

[mguetschow]

What's the rationale for introducing an event queue here? This will prevent the skald_adv_start function from returning, which should at least be documented somewhere for the user.

But I would rather call the user-provided callback within ISR context and shift thread-safety and the onus of having an event queue to the user side.

[kfessel]

instead of starting and running a queue exclusiv for skald a already exiting one might be used either given by parameter to skald_adv_start or CONFIG_SKALD_QUEUE or just depending on event_thread

[mguetschow]

just depending on event_thread

That'd sound more sensible to me. Also, I think this dependence would then only be needed for skald_bthome_saul and not for skald_update_pkt_cb.

[miri64]

I think I just copied that behavior from the other skald “daemons” (that's what I see them as). I can have a look, if I find some time.

[miri64]

Rebased to current master

[miri64]

I think I addressed all your comments now.

What I will now do, to get this in a mergeable state:

• Split out encryption into another (draft) PR. Since we need BLE 5 support for skald for this, I don't expect that to be merged anytime soon, but this way we at least have a memorandum.
• Provide tests for BTHome and or BTHome+Skald.

[miri64]

Encryption part is now in #21699

[riot-ci]

Murdock results

✔️ PASSED

ad6d2d4 squash! tests: add test for BTHome

Success	Failures	Total	Runtime
10518	0	10518	16m:28s

Artifacts

• Documentation preview

[miri64]

Added a test, it is still WIP though (did not check if the output is actually correct and I also want to increase the coverage).

[crasbe]

Suggested change

	// if ((res = skald_bthome_add_int8_measurement(
	// &_ctx, BTHOME_ID_TEMPERATURE_FACTOR_1, 0x12
	// )) < 0) {
	// printf("Unable to add temperature factor 1 measurement: %s\n", strerror(res));
	// return 1;
	// }
	/* if ((res = skald_bthome_add_int8_measurement(
	* &_ctx, BTHOME_ID_TEMPERATURE_FACTOR_1, 0x12
	* )) < 0) {
	* printf("Unable to add temperature factor 1 measurement: %s\n", strerror(res));
	* return 1;
	* }
	*/

[miri64]

I don't see any reason to keep this, actually (in case the test output is correct). However, it also serves as a test if the overflow protection works. So keeping as is ftm.