Feature/broodminder w

[ztox]

Description:

Broodminder hive sensors promote a better understanding of honeybee hive properties over time, and is a useful tool for citizen science. Useful sensor and device status data is available in the manufacturerdata payload.

I only have access to a W5 half-hive scale, and implemented decoders for the models below based on documentation and potentially outdated example code (for older models). Appreciate updates from other real-world devices out there.

Model ID	Hex	Model Name	Capability
41	29	T/H	Temperature, Humidity
42	2a	T/H (TH2)	Temperature, Humidity
43	2b	W (Half Hive Scale)	Half-hive Scale
47	2f	(TSM) T,T2,T3, SwarmMinder	Temperature, Swarm Detection
49	31	W3, W4 Full Hive Scale	Full-hive Scale, Temperature, Humidity
56	38	(THSM) TH3, SwarmMinder	Temperature, Humidity, Swarm Detection
57	39	W5 (Half Hive Scale)	Half-hive Scale, Temperature, Humidity
58	3A	Scale-DIY Board	Full-hive Scale, Temperature, Humidity

Checklist:

• The pull request is done against the latest development branch
• Only one feature/fix was added per PR and the code change compiles without warnings
• I accept the DCO.

[ztox]

@DigiH - tests appear to fail on AprilBrother, think this is related to the PR?

[DigiH]

Hello @ztox

Thanks a lot for this submission! This looks like a great addition to Decoder supporting other bee keepers with BrrodMinder equipment.

A few comments about the PR in its current state
• The different devices, or at least device categories, which have diverging properties should be kept in separate decoder files with one _props definition applicable to all decoders in one file.
• The same applies to the documentation files, where each device/device category should have its own document.
• In the _props property definitions the "name" prop should always have the proper Home Assistant convention defined devices classes for correct auto-discoveries - i. e. for all weights this needs to be "name":"weight", for all temperatures "name":"temperature", etc.

tests appear to fail on AprilBrother, think this is related to the PR?

Most likely, as without these additions all tests pass the validation runs. This also means that for each new devices there should also be some regression tests added.

You having the actual W5 half-hive scale, I think it might be best if we start with the above changes with a singe file decoder for the W5, also adding some tests from sample MQTT messages you can receive with Advertisement and advanced data set to true.

Then adding the remaining devices/categories with their own files according to the manufacturer API documentation.

What do you think about this suggestion?

[ztox]

Appreciate the sensible suggestion – will recut and focus on the W5 scale initially. I am a little confused about how to best align to home assistant device classes: temperature(s), and weight(s) make sense, but some fields like sample count and firmware version seem tricky. Sample count could be an entity attribute? And firmware version needs to be cast as a string instead of the current decoded float.

[DigiH]

From looking at the encoding scheme on their site I think that the W5 Half Cale and the W3 and W4 Full Sales could be in one decoder, while the W Half Scale would require a separate decoder as it has very different property encodings.

The firmware version is actually encoded in a float, so I would say this can stay as is, as well as the sample to be a integer counter.

I have created a quick sample decoder for the combined W3, W4 and W5 scales, but for a test case I only had the mot really fitting W scale sample. If you could provide some manufacturerdata from your W5 scale we can extend these test cases for verification.

DigiH@5598d07

[ztox]

Here are a few samples captured from a live W5 scale via MQTT (TBRIDGE02). The hive scale records changes over longer time periods, so these are from roughly 10 minute intervals

{"id":"06:09:16:57:41:25","mac_type":0,"adv_type":0,"name":"57:41:25","manufacturerdata":"8d02391604f96424042e1b1ae79fff7f4b00000000ef9f","rssi":-85,"txpower":3}

{"id":"06:09:16:57:41:25","mac_type":0,"adv_type":0,"name":"57:41:25","manufacturerdata":"8d02391604f96424042e1b1ae79fff7f4b00000000ef9f","rssi":-87,"txpower":3}

{"id":"06:09:16:57:41:25","mac_type":0,"adv_type":0,"name":"57:41:25","manufacturerdata":"8d02391604786424042e1b1be79fff7f4b00000000dc9f","rssi":-84,"txpower":3}

{"id":"06:09:16:57:41:25","mac_type":0,"adv_type":0,"manufacturerdata":"8d02391604786424042e1b1be79fff7f4b00000000dc9f","rssi":-92,"txpower":3}

{"id":"06:09:16:57:41:25","mac_type":0,"adv_type":0,"name":"57:41:25","manufacturerdata":"8d023916041c7b2504b51b1ce39fff7f4400000000e89f","rssi":-87,"txpower":3}

[DigiH]

Thanks for the sample manufacturerdata. Unfortunately the encoding details on their site is somehow incomplete and not really fully defined, even with their given example. In your last sample above, with

"manufacturerdata":"8d023916041c7b2504b51b1ce39fff7f4400000000e89f"

the battery byte is 7b, which would decode to 123%, not likely, but also not unusual that when masking the remaining bits still getting a correct 100%, but it should at least be documented what the remains bits indicate - which is not the case in their documentation.

I think we can still get your W5 half scale to decode properly, but with their incomplete and unclear documentation I doubt that we can properly get decoders for the other devices which you do not own.

Could you post 2 or 3 more sample like above, but with the temperature, battery and different weight values as reported by the native app at the same time the samples are taken?

[ztox]

An update from the support folks regarding the batt values of 123:

In the newer firmware, we are logging chargeRemaining as a battery value. It is a percent of remaining battery life based on how long the device has been running instead of battery voltage. It is roughly every other reading. Here is the parsing for that: 
if(battery > 100){
    remainingCharge = (battery - 100)*4;
    battery = null;
}

Unfortunately I don't think there is currently a way to express this in a conditional property.

[DigiH]

Thanks for this clarification.

I do commend every company which published their encoding schemes - I just wish they'd keep it updated and also make it sufficiently accurate to be able to implement it without further reverse engineering 😉

I'm also unsure about the

… instead of battery voltage …

part, as otherwise this byte gives the battery percentage already. So what exactly the difference between battery = 100 % and percent of remaining battery life = 92 % is I'm still a bit unsure :) And as you stated, we'd have to think about how to condition this difference, as there doesn't seem to be a bit indicating this different broadcast.

As I stated above, unless you can supply additional sample message as above, but with property details of the native app at the same time I think it'll be impossible to create a correct decoder only with the information on their BLE advertising page.