Add bm2 battery monitoring device

[1technophile]

Description:

Add BM2 12V car battery monitoring

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.

[1technophile]

Not sure what is the best way to have the IBEACON decoder not detect this device, so that it is read only by its own decoder

Also, we could modify the IBEACON decoder to read the battery percentage when we detect that we have this device model. (instead of volts) But it will exclude this device from all the filters that are based on IBEACON Model_ID (OMG and Theengs Gateway).
So I would prefer a way to reduce the scope of the IBEACON.

Tested the add of:
"condition":["manufacturerdata", "=", 50, "index", 0, "4c00","&","name", "index", 0, "!" ,"Battery Monitor"], to the IBEACON decoder but still have an issue with the BlueCharm:

comparing value: 4c000215426c7565436861726d426561636f6e730efe1355c5 to 060001 at index 0
comparing value: BlueCharm_135727 to BatteryMonitor at index 0
FAILED! Error parsing: iBeacon : BlueCharm_135727 : 4c000215426c7565436861726d426561636f6e730efe1355c5

[DigiH]

Are the two test cases actual data of one device, or also partly made up? Some other BLE sensors which use the iBeacon protocol use fixed major and/or minor to identify themselves. Not the case here thought if the test cases are actual data :(

Possibly some part of the uuid?

Since the name is model fixed and non changeable by the user we could do a NOT name comparison for the general iBeacon decoder., like the positive name check in this decoder.

[1technophile]

Are the two test cases actual data of one device, or also partly made up?

They are actual data.

Since the name is model fixed and non changeable by the user we could do a NOT name comparison for the general iBeacon decoder., like the positivename check in this decoder.

I tried this but getting an error with the bluecharm. Not sure why. I added the data to my first msg.

Possibly some part of the uuid?

Maybe the path to follow. We would need other devices uuid to confirm this

[DigiH]

Shouldn't the mfid be unique to the device/manufacturer?, which we could then include in its decoder and possibly also exclude from the generic iBeacon?

[1technophile]

Thanks! I will try that

[DigiH]

Sorry, too late and hot here ;) mfid is obviously always the same for all the iBeacons, meant the first part of the uuid, which should be device/manufacturer specific. Do you know of nay one else with the device to double check for the similarities in the uuid?

[DigiH]

Thinking more about this though, and with more and more sensors piggy bagging on the iBeacon protocol, some April Brother sensors etc., I think the best bet here is the unique name, which could then easily be added as a NOT condition to the generic iBeacon decoder.

We just need to add this functionality ;) maybe not use a NOT with the index and all which woudl make it longer, but a "not_contain" comparison?

[DigiH]

@1technophile, do you mind me pushing something to this branch, as I've been trying on it?

[DigiH]

Proposal with "not_contain", to be able to get more iBeacon protocol using sensors compatibility. Hopefully not too many, as not to have too long a "not_contain" chain.

development...BM2_with-has_not

[1technophile]

Note that for the moment I haven't found a way to retrieve the voltage. Maybe for later on.

[DigiH]

Note that for the moment I haven't found a way to retrieve the voltage. Maybe for later on.

I suppose from the two sample data test sets, and with it using the iBeacon protocol it can only be the major, having similar data in both sets, with the minor being totally "0000" in the first sample.

So
f644 and f441
big endian to
63044 and 62529
divided by
4500
is
14.0 and 13.89 volt

Depending on the battery condition and the car starting/running these would be realistic expected values.

But more likely I just worked it that way to come out ;)

Really would need actual device testing and comparing with a different on board voltage indicator, like a cigarette lighter USB charger with voltage indicator included.

Or just the first byte of the major
f6 and f4
divided by 20
12.3 and 12.2 volt

Also good values for a stationary car ;)

[1technophile]

What I have found so far is that these 2 numbers are always =

And between it is changing but not in a way that make sense relative to the voltage

[DigiH]

Hmm, that wouldn't even be a single hex byte, but the end digit of the first byte of the major I mentioned above and the first digit of the second major byte,

If both are changing it might be that it is the usually major part of the iBeacon protocol, but not big endian as I mentioned above, but little endian
44f6 and 41f4
decimal: 17654 and 16884
divided by 1500 ????
11.77 and 11.26 volt, which would be quite low and indicating the battery needs charging :)

Any chance of getting the actual voltage of the battery when readings are done, possibly with a voltmeter?

[1technophile]

I sent you a link to the spreadsheet by PM on the OMG forum.

[DigiH]

Already there for a while now, watching your changes and wondering what the data contains ;)

Sent you a reply back by PM.