theengs / decoder Goto Github PK

Is your feature request related to a problem? Please describe.

Currently a development version of the Theengs Decoder Python package can't be easily built because setup.py doesn't have a valid version string. You have to temporarily change this to a valid version string, build the package and then don't forget to restore setup.py again.

Describe the solution you'd like

Automatic versioning from Git tags and commits, as implemented by PyScaffold. This means that every commit can be built without having to manually change a version string.

Describe alternatives you've considered

None

Additional context

This would make it easier for users to test new features in development versions, such as in this case: 1technophile/OpenMQTTGateway#1555 (comment)

Hello, I'm unable to get steps from Mi band 7 (firmware 2.1.0.1) only heart rate. I'm using latest stable and development version of OpenMqttGateway. I've tried to downgrade Zepp Life to previous v6.9.6 version but no difference. In recent and this version of Zepp Life there is only option for "Activity heart rate sharing" no steps. What I'm missing? Thank you.

Peter

{"id":"D3:EB:1F:22:65:11","name":"Xiaomi Smart Band 7 6511","rssi":-72,"distance":4.287841,"brand":"Xiaomi/Amazfit","model":"Mi Band/Smart Watch","model_id":"MB/SW","type":"BODY","act_bpm":0,"device":"Xiaomi/Amazfit Tracker","mac":"D3:EB:1F:22:65:11"}

Support for PAX Calima

I have a couple of PAX Calima fan in my house, unfortunately - the are out of range from my Home Assistant machine and I am unable to relocate it closer.

I have thought about getting an ESP32 and create a bluetoothproxy on it, but since I already have a Raspberry Pi Zero W, it would be nice to utilize this.

Here is the drivers for those fans:

https://github.com/PatrickE94/pycalima

The drivers is successfully used in this project that works great with Home Assistant:
https://github.com/eriknn/ha-pax_ble

Thank you for your work!

Describe the bug
/home/runner/Arduino/libraries/TheengsDecoder/src/decoder_c.cpp:26:10: fatal error: shared/theengs.h: No such file or directory
#include "shared/theengs.h"

To Reproduce
Steps to reproduce the behavior:
see https://github.com/matthias-bs/BresserWeatherSensorTTN/blob/test-theengsdecoder-v1.5.0/.github/workflows/CI.yml
The CI workflow works fine with v1.4.2 and fails with v1.5.0
Same error occurs when compiling with Arduino IDE v2.1.0 / ESP32 Arduino 2.07

Expected behavior
No compile error

Screenshots
If applicable, add screenshots to help explain your problem.

Environment (please complete the following information):

• version used (V0.9.3, 0.8, development)
• Context of your project

Additional context
Add any other context about the problem here.

• You should not have a compilation error if you use the versions of the libraries linked into the libraries folder, this badges show you the state of the compilation
  
• If you are not sure this is a bug or an enhancement post your question to the forum

Is your feature request related to a problem? Please describe.
have lots of bluetooth devices adverticing a lot data on bluetooth,
tried to identify all of my bt-devices with https://espresense.com/beacons/apple
that helped only with fingerprinting apple-devices, but difficult to deocde other bt-devices around
have already a handful of node-red instances running the smarthome.
node-red is a great center of integration. but a easy to confiure-bt-decoder is missing 😢

Describe the solution you'd like
would love to see bt-decoding within node-red
the node-red gui is great , and theengs could open up decoding data from moveable bt-devices

Describe alternatives you've considered
some small steps of integration is here
https://docs.openmqttgateway.com/integrate/node_red.html#integrate-ble-sensors-devices-and-display-a-dashboard
but not as a generally open bt-decoder with an nice gui as an endpoint to (different) mqtt-devices.

Additional context
Add any other context or screenshots about the feature request here.

Would love to see Govee H5179 & H5054 support added.
I may take a stab at it when time permits if no one else is able.

Thanks

Describe the bug

I have three Xiaomi Mi Flora plant sensors. Two have a green casing and are decoded correctly by Theengs Decoder; one has a white casing and isn't decoded.

To Reproduce

Steps to reproduce the behavior:

1. Data processed: service data 3102980000ad65678d7cc40d on UUID 0xfe95
2. Expected data: temperature, moisture, fertility, luminance
3. Not detected as Mi Flora sensor

Expected behavior

I expect Theengs Decoder to decode data from this Mi Flora sensor's service data (for UUID 0xfe95) just like it does for the other ones.

Screenshots

This is how OpenMQTTGateway v0.9.10 with Theengs Decoder v0.1.9 sees the advertisements of the device:

$ mosquitto_sub -t 'home/OpenMQTTGateway_ESP32_OLM_GTWE/BTtoMQTT/C47C8D6765AD' -v|ts
Feb 12 19:58:25 home/OpenMQTTGateway_ESP32_OLM_GTWE/BTtoMQTT/C47C8D6765AD {"id":"C4:7C:8D:67:65:AD","mac_type":0,"rssi":-92,"servicedata":"3102980000ad65678d7cc40d"}
Feb 12 19:59:23 home/OpenMQTTGateway_ESP32_OLM_GTWE/BTtoMQTT/C47C8D6765AD {"id":"C4:7C:8D:67:65:AD","mac_type":0,"name":"Flower care","rssi":-94,"servicedata":"3102980000ad65678d7cc40d"}
Feb 12 20:01:42 home/OpenMQTTGateway_ESP32_OLM_GTWE/BTtoMQTT/C47C8D6765AD {"id":"C4:7C:8D:67:65:AD","mac_type":0,"name":"Flower care","rssi":-94,"servicedata":"3102980000ad65678d7cc40d"}
Feb 12 20:01:49 home/OpenMQTTGateway_ESP32_OLM_GTWE/BTtoMQTT/C47C8D6765AD {"id":"C4:7C:8D:67:65:AD","mac_type":0,"name":"Flower care","rssi":-93,"servicedata":"3102980000ad65678d7cc40d"}
Feb 12 20:02:49 home/OpenMQTTGateway_ESP32_OLM_GTWE/BTtoMQTT/C47C8D6765AD {"id":"C4:7C:8D:67:65:AD","mac_type":0,"name":"Flower care","rssi":-89,"servicedata":"3102980000ad65678d7cc40d"}
Feb 12 20:03:53 home/OpenMQTTGateway_ESP32_OLM_GTWE/BTtoMQTT/C47C8D6765AD {"id":"C4:7C:8D:67:65:AD","mac_type":0,"name":"Flower care","rssi":-90,"servicedata":"3102980000ad65678d7cc40d"}
Feb 12 20:04:58 home/OpenMQTTGateway_ESP32_OLM_GTWE/BTtoMQTT/C47C8D6765AD {"id":"C4:7C:8D:67:65:AD","mac_type":0,"name":"Flower care","rssi":-88,"servicedata":"3102980000ad65678d7cc40d"}
Feb 12 20:08:17 home/OpenMQTTGateway_ESP32_OLM_GTWE/BTtoMQTT/C47C8D6765AD {"id":"C4:7C:8D:67:65:AD","mac_type":0,"name":"Flower care","rssi":-95,"servicedata":"3102980000ad65678d7cc40d"}
Feb 12 20:11:32 home/OpenMQTTGateway_ESP32_OLM_GTWE/BTtoMQTT/C47C8D6765AD {"id":"C4:7C:8D:67:65:AD","mac_type":0,"name":"Flower care","rssi":-95,"servicedata":"3102980000ad65678d7cc40d"}
Feb 12 20:12:47 home/OpenMQTTGateway_ESP32_OLM_GTWE/BTtoMQTT/C47C8D6765AD {"id":"C4:7C:8D:67:65:AD","mac_type":0,"name":"Flower care","rssi":-90,"servicedata":"3102980000ad65678d7cc40d"}
Feb 12 20:13:53 home/OpenMQTTGateway_ESP32_OLM_GTWE/BTtoMQTT/C47C8D6765AD {"id":"C4:7C:8D:67:65:AD","mac_type":0,"name":"Flower care","rssi":-93,"servicedata":"3102980000ad65678d7cc40d"}

Note that the data are always the same 12 bytes, so I'm not sure whether the device is faulty. The data seem to have a different format (31029800...) than the other two Mi Flora devices (71209800...).

Environment (please complete the following information):

• Theengs Decoder v0.1.9
• OpenMQTTGateway v0.9.10

Additional context

The same happens when I'm using Theengs Decoder directly with python3 python/ScanAndDecode.py.

Describe the bug
Hi!

I just bought 2 WS08 ThermoBeacon devices (FCC id 2ACD3-WS08).
The parsing of the advertising manufacturer data does not perform as expected.

It seems like for new devices the advertising manufacturer data has changed as of dec 22, see the issue fixed in Home Assistant:
Fix thermobeacon WS08 models that identify with manufacturer_id 27

So this could be the issue for my devices too, or something else.

To Reproduce
I'm not using a development environment, just OpenMQTTGateway v1.4.0 (which seems like the theengs decoder v1.2.0) on an esp32 board esp32dev-ble-openhab

Expected behavior
My device advertises its manufacturer data as:
{length = 20, bytes = 0x1 b002500cf1d0000d063a50cdcOObf0338270000}

I expected the output to be something in the vein of a nice json containing the brand, model, tempc, hum, volt values...

but I just get

"manufacturerdata":"1b002500cf1d0000d063a40cdc00bf0332270000"

Screenshots

Environment (please complete the following information):
OpenMQTTGateway v1.4.0
esp32dev-ble-openhab on esp32 board
WS08 ThermoBeacon devices (FCC id 2ACD3-WS08)

Property condition
"condition":["servicedata", "=", 32, "|", "servicedata", "=", 36, "&", "servicedata", 23, "!", "6"],

fails, possibly due to the added AND index check after the two OR conditions

had to work around it with

"condition":["servicedata", ">=", 32, "&", "servicedata", 23, "!", "6"],

as the model condition already checks for

"condition":["servicedata", "=", 30, "|", "servicedata", "=", 32, "|", "servicedata", "=", 36, "&", "name", "index", 0 …

it's fine here, but will need looking at eventually.

Is your feature request related to a problem? Please describe.
Why isn't the battery status of HHCCJCY01HHCC reported? Its reporting the status in the app.
According to the source HHCCJCY10 does report the battery status. MAC isnt reported btw.

Describe the solution you'd like
Update this file to report the battery status of the device.

Describe alternatives you've considered
I've considered pulling the source and trying it myself but it would probably be quicker for the code owners to do it.

Additional context

In the screenshot you can see mac isnt working

Hello Team,

This is regarding this issue : 1technophile/OpenMQTTGateway#1196

Describe the bug
Since OMG v0.9.9 there is NO battery report on Xiaomi Mi Jia devices.

This may be linked to this Theengs decoder "descriptor" that lacks battery info:
https://github.com/theengs/decoder/blob/development/src/devices/LYWSDCGQ_json.h
Which was present here :
https://github.com/1technophile/OpenMQTTGateway/blob/7f296ff5fa548ae46a6d2e0e1083f4ad8db6c1ab/main/ZgatewayBT.ino#L1424-L1425

To Reproduce
Flash v0.9.11 (esp32-lolin32lite-ble) on one ESP32 and v0.9.8 on another.
Wait (>1h) for at least a battery report from the device.
Only v0.9.8 reports battery for Xiaomi Mi Jia

Expected behavior
Battery level should be reported for Xiaomi Mi Jia when the device sends it.

Screenshots
Only OMG3 (v0.9.8) ESP32 reports batt for 582D3431FE5F, the others (v0.9.11) don't:

# mosquitto_sub -h <BROKER> -v -t 'bt/+/BTtoMQTT/582D3431FE5F' -F "%I %t %p"
2022-04-10T20:02:22+0200 bt/OMG3/BTtoMQTT/582D3431FE5F {"id":"58:2D:34:31:FE:5F","name":"MJ_HT_V1","rssi":-84,"distance":13.81901,"model":"LYWSDCGQ","tempc":21.7,"tempf":71.06,"hum":39.1}
2022-04-10T20:02:37+0200 bt/Atelier/BTtoMQTT/582D3431FE5F {"id":"58:2D:34:31:FE:5F","mac_type":0,"rssi":-89,"brand":"Xiaomi","model":"Mi Jia round","model_id":"LYWSDCGQ","tempc":21.7,"tempf":71.06,"hum":39.3}
2022-04-10T20:02:50+0200 bt/Entree/BTtoMQTT/582D3431FE5F {"id":"58:2D:34:31:FE:5F","mac_type":0,"name":"MJ_HT_V1","rssi":-85,"brand":"Xiaomi","model":"Mi Jia round","model_id":"LYWSDCGQ","tempc":21.6,"tempf":70.88,"hum":39.2}
2022-04-10T20:03:32+0200 bt/OMG3/BTtoMQTT/582D3431FE5F {"id":"58:2D:34:31:FE:5F","name":"MJ_HT_V1","rssi":-88,"distance":19.7325,"model":"LYWSDCGQ","tempc":21.5,"tempf":70.7,"hum":39.3}
2022-04-10T20:03:38+0200 bt/Atelier/BTtoMQTT/582D3431FE5F {"id":"58:2D:34:31:FE:5F","mac_type":0,"name":"MJ_HT_V1","rssi":-87,"brand":"Xiaomi","model":"Mi Jia round","model_id":"LYWSDCGQ"}
2022-04-10T20:03:58+0200 bt/Entree/BTtoMQTT/582D3431FE5F {"id":"58:2D:34:31:FE:5F","mac_type":0,"name":"MJ_HT_V1","rssi":-80,"brand":"Xiaomi","model":"Mi Jia round","model_id":"LYWSDCGQ","tempc":21.5,"tempf":70.7,"hum":39.2}
2022-04-10T20:04:39+0200 bt/OMG3/BTtoMQTT/582D3431FE5F {"id":"58:2D:34:31:FE:5F","rssi":-86,"distance":16.54559,"model":"LYWSDCGQ","tempc":21.6,"tempf":70.88,"hum":39.3}
2022-04-10T20:05:36+0200 bt/OMG3/BTtoMQTT/582D3431FE5F {"id":"58:2D:34:31:FE:5F","name":"MJ_HT_V1","rssi":-84,"distance":13.81901,"model":"LYWSDCGQ","batt":93}
2022-04-10T20:05:44+0200 bt/Atelier/BTtoMQTT/582D3431FE5F {"id":"58:2D:34:31:FE:5F","mac_type":0,"name":"MJ_HT_V1","rssi":-94,"brand":"Xiaomi","model":"Mi Jia round","model_id":"LYWSDCGQ","tempc":21.6,"tempf":70.88,"hum":39.3}
2022-04-10T20:06:11+0200 bt/Entree/BTtoMQTT/582D3431FE5F {"id":"58:2D:34:31:FE:5F","mac_type":0,"rssi":-81,"brand":"Xiaomi","model":"Mi Jia round","model_id":"LYWSDCGQ","tempc":21.6,"tempf":70.88,"hum":39.3}
2022-04-10T20:06:59+0200 bt/Atelier/BTtoMQTT/582D3431FE5F {"id":"58:2D:34:31:FE:5F","mac_type":0,"rssi":-95,"brand":"Xiaomi","model":"Mi Jia round","model_id":"LYWSDCGQ","tempc":21.7,"tempf":71.06,"hum":39.6}
2022-04-10T20:08:03+0200 bt/Atelier/BTtoMQTT/582D3431FE5F {"id":"58:2D:34:31:FE:5F","mac_type":0,"name":"MJ_HT_V1","rssi":-91,"brand":"Xiaomi","model":"Mi Jia round","model_id":"LYWSDCGQ","hum":39.5}
2022-04-10T20:08:17+0200 bt/Entree/BTtoMQTT/582D3431FE5F {"id":"58:2D:34:31:FE:5F","mac_type":0,"name":"MJ_HT_V1","rssi":-81,"brand":"Xiaomi","model":"Mi Jia round","model_id":"LYWSDCGQ","tempc":21.6,"tempf":70.88,"hum":39.5}
2022-04-10T20:08:55+0200 bt/OMG3/BTtoMQTT/582D3431FE5F {"id":"58:2D:34:31:FE:5F","name":"MJ_HT_V1","rssi":-83,"distance":12.61001,"model":"LYWSDCGQ","tempc":21.5,"tempf":70.7,"hum":39.4}

Environment:

• OpenMQTTGateway version 0.9.8 and 0.9.11 on 3 ESP32

Thanks,
Bad

I saw this PR, which seems to handle quite a wide range of Mopeka sensors:

robsweet/dbus-ble-sensors@4a01ef0

beyond the additional sensor types and fluid types, the change really relevant is handling the extened time range (TankLevelExtension)

I have no need for this, I do not have a tank which needs this range, nor do I have a sensor with extended range

notice first bye of manufacturer data which is 0x03 vs 0x0c - according to https://github.com/robsweet/dbus-ble-sensors/blob/master/src/mopeka.c#L226-L232 I would think both of the following sensors have the extension bit NOT set:

This is a Pro:

N: Send on /BTtoMQTT/D639AE4FCD0C msg {"id":"D6:39:AE:4F:CD:0C","mac_type":1,"adv_type":0,"manufacturerdata":"5900034e4250004fcd0c66d9","rssi":-54,"brand":"Mopeka/Lippert","model":"Pro Check (Universal)/BottleCheck Sensor","model_id":"M1017","type":"UNIQ","cidc":false,"tempc":26,"tempf":78.8,"lvl_cm":2.907907,"lvl_in":1.144845,"sync":false,"volt":2.4375,"batt":36.53846,"quality":0,"accx":102,"accy":-39}

This is a Pro Universal:

{"id":"D8:C6:11:CA:12:55","mac_type":1,"adv_type":0,"manufacturerdata":"59000c5f3ac440ca1255d514","rssi":-81,"brand":"Mopeka/Lippert","model":"Pro Check (Universal)/BottleCheck Sensor","model_id":"M1017","type":"UNIQ","cidc":false,"tempc":18,"tempf":64.4,"lvl_cm":7.670883,"lvl_in":3.020033,"sync":false,"volt":2.96875,"batt":100,"quality":1,"accx":-43,"accy":20}

just a note if the need arises

The past few days I have worked on reverse engineering a smart scale I happen to own. The brand is e-volve and the companion app is Fitdays.

I figured out that

• the scale is a BLE server
• it is one you cannot connect to
• weight and impedance information is simply broadcasted in the advertisement packets
• I can decode the data to read out weight information from it in kg (haven't looked at the impedance data yet) with a small calculation

I would like to process and store this information in Home Assistant, and I believe Theengs OpenMQTTGateway is a good use for an ESP32 achieving just that.

However, if I am not mistaken, I first need to get decoding support for this particular scale supported here before I program my board with Theengs. Correct?

I'd be more than happy to share my findings here and perhaps even prepare a pull request to get it sorted.

I didn't come across any pointers yet on how to get started however. Perhaps I can get some here? :-)

Thanks to @koenvervloesem for pointing me in this direction!

I have a Switchbot Meter Plus that was being picked up as a "Smart Tracker" for a bit.

To Reproduce

I collected output from runs of examples/python/ScanAndDecode.py

In the bad detection state the device sends out data like this: (MAC in output redacted, replaced with DC:FF:FF:FF:FF:FF)

DC:FF:FF:FF:FF:FF:AdvertisementData(manufacturer_data={2409: b'\xdc\xff\xff\xff\xff\xff\x03\x03\x08\x97\xad', 64: b'\x00l\x02'}, service_data={'0000feed-0000-1000-8000-00805f9b34fb': b'\x02\x00\xa3\rY\xa8\xff\x18\x14\xfa'}, rssi=-54)
data sent to decoder:  {"servicedatauuid": "feed", "servicedata": "0200a30d59a8ff1814fa", "manufacturerdata": "6909dcffffffffff03030897ad", "id": "DC:FF:FF:FF:FF:FF", "rssi": -54}
TheengsDecoder found device: {"servicedatauuid":"feed","servicedata":"0200a30d59a8ff1814fa","manufacturerdata":"6909dcffffffffff03030897ad","id":"DC:FF:FF:FF:FF:FF","rssi":-54,"brand":"Tile","model":"Smart Tracker","model_id":"TILE","type":"TRACK","cidc":false,"acts":true,"cont":true,"track":true,"device":"Tile Tracker"}
{"properties":{"device":{"unit":"string","name":"tracker device"}}}
brand: Tile , model: Smart Tracker

Note the manufacturer data confirms it is my Switchbot Meter Plus.
I don't know why the sent data was different or what the exact trigger was since I had done several things, including:

• added it in Switchbot app
• confirmed it was on latest current firmware
• removed it from the app
• held button on back for 15 seconds to fully reset it

Expected behavior
The data it sent out when it was properly tagged:

DC:FF:FF:FF:FF:FF:AdvertisementData(manufacturer_data={2409: b'\xdc\xff\xff\xff\xff\xff\x05\x03\x07\x97\xad'}, service_data={'0000fd3d-0000-1000-8000-00805f9b34fb': b'i\x00\xe4\x07\x97\xad'}, rssi=-64)
data sent to decoder:  {"servicedatauuid": "fd3d", "servicedata": "6900e40797ad", "manufacturerdata": "6909dcffffffffff05030797ad", "id": "DC:FF:FF:FF:FF:FF", "rssi": -64}
TheengsDecoder found device: {"servicedatauuid":"fd3d","servicedata":"6900e40797ad","manufacturerdata":"6909dcffffffffff05030797ad","id":"DC:FF:FF:FF:FF:FF","rssi":-64,"brand":"SwitchBot","model":"Meter (Plus)","model_id":"THX1/W230150X","type":"THB","acts":true,"tempc":23.7,"tempf":74.66,"hum":45,"batt":100}
{"properties":{"tempc":{"unit":"°C","name":"temperature"},"hum":{"unit":"%","name":"humidity"},"batt":{"unit":"%","name":"battery"}}}
brand: SwitchBot , model: Meter (Plus)

Environment (please complete the following information):

• version used: 1.6.8

Additional context
This is output for a tracker, for comparison:

F8:FF:FF:FF:FF:FF:AdvertisementData(service_data={'0000feed-0000-1000-8000-00805f9b34fb': b'\x02\x00d\x85\xdd\x85gyp\xa8'}, service_uuids=['0000feed-0000-1000-8000-00805f9b34fb'], rssi=-70)
data sent to decoder:  {"servicedatauuid": "feed", "servicedata": "02006485dd85677970a8", "id": "F8:FF:FF:FF:FF:FF", "rssi": -70}
TheengsDecoder found device: {"servicedatauuid":"feed","servicedata":"02006485dd85677970a8","id":"F8:FF:FF:FF:FF:FF","rssi":-70,"brand":"Tile","model":"Smart Tracker","model_id":"TILE","type":"TRACK","cidc":false,"acts":true,"cont":true,"track":true,"device":"Tile Tracker"}
{"properties":{"device":{"unit":"string","name":"tracker device"}}}
brand: Tile , model: Smart Tracker

I note that there is no manufacturer data for that device.
Maybe that could be used to fine-tune the tracker detection? Right now it appears to be solely based on uuid

Is your feature request related to a problem? Please describe.

I have a sensor device that advertises service data for two UUIDs, and I want to create a decoder for it (#138). Currently, Theengs Decoder seems to support only one servicedatauuid and one servicedata property.

Describe the solution you'd like

This is how service data for my particular device are sent to the decoder now:

❯ python3 examples/python/ScanAndDecode.py |grep RDL
D8:4B:C1:98:69:1E RSSI: -71 AdvertisementData(local_name='RDL52832', manufacturer_data={76: b'\x02\x15\xfd\xa5\x06\x93\xa4\xe2O\xb1\xaf\xcf\xc6\xeb\x07dx%\x00\x01\x00\x02\xd8'}, service_data={'00001803-0000-1000-8000-00805f9b34fb': b'\xd8K\xc1\x98i\x1e\x00\x01\x00\x02\x07\x03\xe8d', '00000318-0000-1000-8000-00805f9b34fb': b'\x15O8E\x01\x00\x00\x01\x00\x00\x00\x00\x00\x00\t\x07'})
data sent to decoder:  {"servicedatauuid": "1803", "servicedata": "d84bc198691e000100020703e864", "manufacturerdata": "4c000215fda50693a4e24fb1afcfc6eb0764782500010002d8", "name": "RDL52832"}

The example Python script only sends the first service data to the decoder, in this case for UUID 1803, while for this particular device I'm interested in the service data for UUID 0318.

What I would like is that I could send something like the following JSON data to the decoder and the service data for both UUIDs should then be available for further decoding:

{"servicedata": {"1803": "d84bc198691e000100020703e864", "0318": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"}, "manufacturerdata": "4c000215fda50693a4e24fb1afcfc6eb0764782500010002d8", "name": "RDL52832"}

Describe alternatives you've considered

I could first check the name of the device (e.g. in Theengs Explorer) and then send the service data for UUID 0318 to the decoder if that specific device is detected, but this is just a hack.

Additional context

I'm not sure there are many devices that advertise service data on multiple UUIDs (this is the first one I discovered), but a general approach for this case seems nice to have.

Bonjour

J'ai testé TheengsGateway sous HomeAssistant en Addons
malgré une recherche, je ne trouve pas de réponses
https://github.com/theengs/decoder/issues?q=mi+band

Certaines informations remontent , Présence / Rssi / Fréquence cardiaque ..

Mais les pas remonte inconnu, et MAC est aussi en inconnu.

Une évolution est possible pour avoir cette info et d'autre comme la surveillance du sommeil dans un futur ?.

Pour résumer:

Good morning

I tested TheengsGateway under HomeAssistant in Addons
despite searching, I can't find any answers.
https://github.com/theengs/decoder/issues?q=mi+band

Some information comes back, Presence / Rssi / Heart rate..

But the steps go back unknown, and MAC is also unknown.

Is an evolution possible to have this information and others such as sleep monitoring in the future?

To sum up:

Thx

Is your feature request related to a problem? Please describe.
ThermoPro has replaced the TP357 by the TP357S, which is recognized only as a generic device and as such no temperature/humidity is being reported.
I forked the repo and made the necessary changes to TPTH_json.h (basically just adding the TP357S in the logical OR condition) and was able to recompile the decoder library, but not to regenerate the python package (there is not much info on how to do that). I managed to create a new EGG file once, but subsequent builds failed (MSVC compiler complains about missing stddef.h or some scikit-build integration issue)
Manufacturing data produced by the TP357S:

{"manufacturerdata": "c2d60043220b01", "name": "TP357S (AEF2)", "id": "FF:AC:31:C7:AE:F2", "rssi": 0}

Other than this the gateway solution is working flawlessly (created a Systemd service on RPI4 in combination with OpenHab) - congratulation on this great project !

Describe the solution you'd like
I am happy to contribute with a pull request, but I would need to be able to build and test the python package first. Any hints appreciated.
Alternatively, if the development team is willing to add TP357S support directly, this is even a better solution :-).

Describe alternatives you've considered

1. Contribute the change myself (code change succeeded but rebuild failed).
2. Given a new (test) version, I would be happy to validate and report back.

Thanks in advance,
Ewald

Describe the bug
Installing Theengs in Windows results in numerous errors
Not sure if it's supported?

To Reproduce
Steps to reproduce the behavior:

pip install TheengsGateway

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

https://pastebin.com/2T4YwMwp

Environment
Additional context
Add any other relevant context about the problem here.

When I added LYWSD03MMC to iOS app, I can see temperature and humidity, can update it.
But in MQTT no data about this.
In MQTT i see only topic home/TheengsApp/version with data "v1.3.1"

Steps to reproduce the behavior:

1. Install app
2. add LYWSD03MMC
3. configure mqtt server settings
4. scan MAC of LYWSD03MMC with debian
5. Set MAC Address of my LYWSD03MMC into App, from previous scan
   "root@mdm:/home/london# stdbuf -oL hcitool lescan | grep LYWSD03MMC
   A4:C1:38:5C:75:B6 LYWSD03MMC"
6. click Update data in app

Expected behavior
I wanna LYWSD03MMC data in MQTT

iOS App Theengs ver 1.3.1
iPhone 14 Pro
iOS ver. 16.5.1

Hi,
I have a problem installing the decoder.
Can you help me please ?

Scanning dependencies of target decoder
[ 16%] Building CXX object CMakeFiles/decoder.dir/src/decoder.cpp.o
In file included from /home/pi/bluetooth/decoder-development/src/decoder.cpp:22:
/home/pi/bluetooth/decoder-development/src/decoder.h:26:10: fatal error: ArduinoJson.h: No such file or directory
#include "ArduinoJson.h"
^~~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [CMakeFiles/decoder.dir/build.make:63: CMakeFiles/decoder.dir/src/decoder.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:617: CMakeFiles/decoder.dir/all] Error 2
make: *** [Makefile:95: all] Error 2
pi@jeedom:~/bluetooth/decoder-development/python$ make
[ 16%] Building CXX object CMakeFiles/decoder.dir/src/decoder.cpp.o
In file included from /home/pi/bluetooth/decoder-development/src/decoder.cpp:22:
/home/pi/bluetooth/decoder-development/src/decoder.h:26:10: fatal error: ArduinoJson.h: No such file or directory
#include "ArduinoJson.h"
^~~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [CMakeFiles/decoder.dir/build.make:63: CMakeFiles/decoder.dir/src/decoder.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:617: CMakeFiles/decoder.dir/all] Error 2
make: *** [Makefile:95: all] Error 2

Is your feature request related to a problem? Please describe.

In #138 I need three .cal values to calculate acceleration in X, Y and Z axes. I defined a .cal value three times because I wanted to extract three bytes and and use these values in calculations, but it seems the decoder is only using the latest .cal value, so the three calculations are using the same extracted value.

Describe the solution you'd like

I'd like to be able to use more than one .cal value.

Describe alternatives you've considered

I haven't found an alternative way.

Additional context

This is the relevant code:

      ".cal":{
         "decoder":["value_from_hex_data", "servicedata", 12, 2, false, false],
         "post_proc":["/", 10]
      },
      "accx":{
         "condition":["servicedata", 8, "0000"],
         "decoder":["value_from_hex_data", "servicedata", 14, 2, false, false],
         "post_proc":["/", 100, "+", ".cal"]
      },
      "_accx":{
         "condition":["servicedata", 8, "0001"],
         "decoder":["value_from_hex_data", "servicedata", 14, 2, false, false],
         "post_proc":["/", 100, "+", ".cal", "+", 1]
      },
      "__accx":{
         "condition":["servicedata", 8, "0100"],
         "decoder":["value_from_hex_data", "servicedata", 14, 2, false, false],
         "post_proc":["/", 100, "+", ".cal", "*", -1]
      },
      "___accx":{
         "condition":["servicedata", 8, "0101"],
         "decoder":["value_from_hex_data", "servicedata", 14, 2, false, false],
         "post_proc":["/", 100, "+", ".cal", "+", 1, "*", -1]
      },
      ".cal":{
         "decoder":["value_from_hex_data", "servicedata", 20, 2, false, false],
         "post_proc":["/", 10]
      },
      "accy":{
         "condition":["servicedata", 16, "0000"],
         "decoder":["value_from_hex_data", "servicedata", 22, 2, false, false],
         "post_proc":["/", 100, "+", ".cal"]
      },
      "_accy":{
         "condition":["servicedata", 16, "0001"],
         "decoder":["value_from_hex_data", "servicedata", 22, 2, false, false],
         "post_proc":["/", 100, "+", ".cal", "+", 1]
      },
      "__accy":{
         "condition":["servicedata", 16, "0100"],
         "decoder":["value_from_hex_data", "servicedata", 22, 2, false, false],
         "post_proc":["/", 100, "+", ".cal", "*", -1]
      },
      "___accy":{
         "condition":["servicedata", 16, "0101"],
         "decoder":["value_from_hex_data", "servicedata", 22, 2, false, false],
         "post_proc":["/", 100, "+", ".cal", "+", 1, "*", -1]
      },
      ".cal":{
         "decoder":["value_from_hex_data", "servicedata", 28, 2, false, false],
         "post_proc":["/", 10]
      },
      "accz":{
         "condition":["servicedata", 24, "0000"],
         "decoder":["value_from_hex_data", "servicedata", 30, 2, false, false],
         "post_proc":["/", 100, "+", ".cal"]
      },
      "_accz":{
         "condition":["servicedata", 24, "0001"],
         "decoder":["value_from_hex_data", "servicedata", 30, 2, false, false],
         "post_proc":["/", 100, "+", ".cal", "+", 1]
      },
      "__accz":{
         "condition":["servicedata", 24, "0100"],
         "decoder":["value_from_hex_data", "servicedata", 30, 2, false, false],
         "post_proc":["/", 100, "+", ".cal", "*", -1]
      },
      "___accz":{
         "condition":["servicedata", 24, "0101"],
         "decoder":["value_from_hex_data", "servicedata", 30, 2, false, false],
         "post_proc":["/", 100, "+", ".cal", "+", 1, "*", -1]
      }

As seen in the test results of #138, the latest .cal value (the byte at index 28 of the service data) is used for all calculations that refer to .cal.

I want to use passive mode to listen for the broadcast messages that get sent from the SwitchBot Meter. They seem to be sent when temperature or humidity changes.

In my testing I am able to see these messages, but since they do not include the service data they are not matched and decoded.

Would it be acceptable to modify the conditions to match the manufacturer data and extract data from there?

The data I am after (temp and humidity) is included in the manufacturer data field. (these broadcast messages do not include the service data field)

In active scan mode, the data is found in both manufacturer data and service data, which get sent in that case.

Active scan has the benefit of seeing the battery level in the service data, but I only want to check that daily. Is it possible to pull the other data from the manufacturer data and just decode the battery level when it is present?

Additional context

I copied output from running https://github.com/theengs/decoder/blob/d3882a16d03a643f311190e2133670acffe5c83e/examples/python/ScanAndDecode.py

with some small modifications to allow passive mode:

# added some imports at the top
from bleak.assigned_numbers import AdvertisementDataType
from bleak.backends.bluezdbus.advertisement_monitor import OrPattern
from bleak.backends.bluezdbus.scanner import BlueZScannerArgs

# changed beginning of main() to look like this:
async def main():
    bluez_args = BlueZScannerArgs(or_patterns=[OrPattern(0, AdvertisementDataType.MANUFACTURER_SPECIFIC_DATA, b"\x69")])

    scanner = BleakScanner(bluez=bluez_args, detection_callback=detection_callback, scanning_mode="passive")
    await scanner.start()
    await asyncio.sleep(60.0)

In the below outputs, Passive is with these changes while Active is with the original script.
(MAC in outputs redacted, all but first byte replaced with FF)

Switchbot Meter (non-Plus)

# Passive:
data sent to decoder:  {"manufacturerdata": "6909ccffffffffff130305982c", "id": "CC:FF:FF:FF:FF:FF", "rssi": -57}
TheengsDecoder found device: None

# Active:
data sent to decoder:  {"servicedatauuid": "fd3d", "servicedata": "5400e405982c", "manufacturerdata": "6909ccffffffffff0b0305982c", "id": "CC:FF:FF:FF:FF:FF", "rssi": -63}
TheengsDecoder found device: {"servicedatauuid":"fd3d","servicedata":"5400e405982c","manufacturerdata":"6909ccffffffffff0b0305982c","id":"CC:FF:FF:FF:FF:FF","rssi":-63,"brand":"SwitchBot","model":"Meter (Plus)","model_id":"THX1/W230150X","type":"THB","acts":true,"tempc":24.5,"tempf":76.1,"hum":44,"batt":100}
{"properties":{"tempc":{"unit":"°C","name":"temperature"},"hum":{"unit":"%","name":"humidity"},"batt":{"unit":"%","name":"battery"}}}
brand: SwitchBot , model: Meter (Plus)

Meter Plus:

# Passive:
data sent to decoder:  {"manufacturerdata": "6909dcffffffffff25030597ac", "id": "DC:FF:FF:FF:FF:FF", "rssi": -56}
TheengsDecoder found device: None

# Active:
data sent to decoder:  {"servicedatauuid": "fd3d", "servicedata": "6900640597ac", "manufacturerdata": "6909dcffffffffff29030597ac", "id": "DC:FF:FF:FF:FF:FF", "rssi": -52}
TheengsDecoder found device: {"servicedatauuid":"fd3d","servicedata":"6900640597ac","manufacturerdata":"6909dcffffffffff29030597ac","id":"DC:FF:FF:FF:FF:FF","rssi":-52,"brand":"SwitchBot","model":"Meter (Plus)","model_id":"THX1/W230150X","type":"THB","acts":true,"tempc":23.5,"tempf":74.3,"hum":44,"batt":100}
{"properties":{"tempc":{"unit":"°C","name":"temperature"},"hum":{"unit":"%","name":"humidity"},"batt":{"unit":"%","name":"battery"}}}
brand: SwitchBot , model: Meter (Plus)

Outdoor Meter:

# Passive:
data sent to decoder:  {"manufacturerdata": "6909ddffffffffff090309972c00", "id": "DD:FF:FF:FF:FF:FF", "rssi": -55}
TheengsDecoder found device: None

# Active:
data sent to decoder:  {"servicedatauuid": "fd3d", "servicedata": "7700e4", "manufacturerdata": "6909ddffffffffff1b0309972c00", "id": "DD:FF:FF:FF:FF:FF", "rssi": -60}
TheengsDecoder found device: {"servicedatauuid":"fd3d","servicedata":"7700e4","manufacturerdata":"6909ddffffffffff1b0309972c00","id":"DD:FF:FF:FF:FF:FF","rssi":-60,"brand":"SwitchBot","model":"Outdoor Meter","model_id":"W340001X","type":"THB","acts":true,"tempc":23.9,"tempf":75.02,"hum":44,"batt":100,"mac":"DD:B6:78:C1:7C:9B"}
{"properties":{"tempc":{"unit":"°C","name":"temperature"},"hum":{"unit":"%","name":"humidity"},"batt":{"unit":"%","name":"battery"},"mac":{"unit":"string","name":"MAC address"}}}
brand: SwitchBot , model: Outdoor Meter

BM2 decoder fails to decode this "BM2 Monitor": https://www.amazon.de/dp/B09MJ4PL72 using OMG heltec-ble with decoder @5f7dca59d5cfe14d4b45f7f44d5797f455e8638d

log from OMG:

N: Device detected: 50:54:7B:22:2F:20
N: Send on /BTtoMQTT/50547B222F20 msg {"id":"50:54:7B:22:2F:20","mac_type":0,"adv_type":0,"name":"Battery Monitor","manufacturerdata":"e18911ed76d18e5ba793d5574f205b61","rssi":-53,"txpower":0}

nrfConnect says this:

and this:

@DigiH where did you take the decoding instructions from?

thanks, Michael

Is your feature request related to a problem? Please describe.
Add support for the device WoSensorTHP. This is the name in the advertisement data when using BLE passive with a THX1(W230150X) device.

Describe the solution you'd like
Add support for the device.

Describe alternatives you've considered

Additional context

DEBUG:BLEGateway:11:22:33:44:55:66:AdvertisementData(local_name='WoSensorTHP', manufacturer_data={2409: b'\xf3\xa5]\x0eW!_\x01\x04\x96)'}, service_uuids=['00001800-0000-1000-8000-00805f9b34fb', '00001801-0000-1000-8000-00805f9b34fb', 'cba20d00-224d-11e6-9fb8-0002a5d5c51b'], rssi=-70)
DEBUG:BLEGateway:Sent `{"manufacturerdata": "6909f3a55d0e57215f01049629", "name": "WoSensorTHP", "id": "11:22:33:44:55:66", "rssi": -70, "mfr": "Woan Technology (Shenzhen) Co., Ltd."}` to topic `home/TheengsGateway/BTtoMQTT/112233445566`

Hi guys,

thanks a lot for this great project. I am just setting up my smart home on OpenMQTTGateway and Mosquitto + Openhab basis.

Is your feature request related to a problem? Please describe.
I would like to integrate my bbq thermometer govee h5055 via mqtt.
Therefore i realized a python based decoder for the Govee H5055 here:
https://github.com/BastiJoe/govee_h5055_mqtt
I am switching from my Raspberry to OpenMQTTGateway on ESP32 and therefore would be glad, if my BBQ Thermometer Govee H5055 would work with OpenMQTTGateway as well.

Describe the solution you'd like
I would like to contribute to the decoder project somehow but I am quite a newbie to this stuff.
I tried to explain how the manufacturer message can be decoded in png and pptx files here:
https://github.com/BastiJoe/govee_h5055_mqtt
Can someone help me create a pull request for the decoder project in C?

Thank you very much in advance.

Best regards

Basti

Hi,

I noticed that the reading for the humidity value for a Govee H5075 jumps to a wrong value when temperature falls below 0 degree celsius. The humidity value in the Govee app meanwhile remains correct.

I think this happens because in case of negative temperature values you have to substract 8388608 (0x800000) from the basenumber to get the right temperature value. The humidity value then also has to be derived from this corrected basenumber. But in H5072_json.h the original basenumber is used for humidity and we get a wrong value.

With this change in H5072_json.h I get correct humidity readings:

const char* _H5072_json = [...], "hum":{"condition":["manufacturerdata",6,"bit",3,0],"decoder":["value_from_hex_data","manufacturerdata",6,6,false,false],"post_proc":["%",1000,"/",10]},"_hum":{"condition":["manufacturerdata",6,"bit",3,1],"decoder":["value_from_hex_data","manufacturerdata",6,6,false,false],"post_proc":["-",8388608,"%",1000,"/",10]},....

  "hum":{
     "condition":["manufacturerdata", 6, "bit", 3, 0],
     "decoder":["value_from_hex_data", "manufacturerdata", 6, 6, false, false],
     "post_proc":["%", 1000, "/", 10]
  },
  "_hum":{
     "condition":["manufacturerdata", 6, "bit", 3, 1],
     "decoder":["value_from_hex_data", "manufacturerdata", 6, 6, false, false],
     "post_proc":["-", 8388608, "%", 1000, "/", 10]
  },

But maybe there is a more elegant way to fix this.

Harald

Hello,

Is this ScanAndDecode.ino sketch operating in connected or disconnected mode ? I understand it's in scan mode so not connected. It's better I think because it's less power consuming on the Xiaomi side.

I also would like to knwo if this skectch is compliant with : https://github.com/pvvx/ATC_MiThermometer .

Thank you.

Describe the bug
I'm using the attached code to log data from several BLE temperature sensors and save the data via a web API:

code_sample.txt

After some time (hours), the payload data is all reported as zeros. The code is intended to find these scenarios and reset the ESP32, but it'd be nice if I didn't have to (try to) bounce it!

To Reproduce
Steps to reproduce the behavior:

1. Run data collection for several hours

Expected behavior
Expected to continue to see valid payload data from the temperature sensors

Environment (please complete the following information):

• Arduino 1.8.19
• ArduinoJson 6.19.4
• NimBLE-Arduino 1.4.1
• TheengsDecoder 0.9.7

There seems to have a lot of different protocol/format used to send information other bluetooth.
An attempt to provide a "standard" format is made by BTHome.
May a decoder be implemented for BTHome frames, or do I not understand anything of the IoT world ?

Hello,

I would like to help out in adding the new INKBIRD IAM-T1 air quality monitor.
This is an e-ink, Bluetooth 5.0 device that requires an active connection for polling as far as I know.

A review of the device and the photos can be found here:
https://smarthomescene.com/reviews/inkbird-e-ink-air-quality-sensor-iam-t1-review/

I own the device and managed to capture some data using the nRF Connect app on my phone, but I have no idea what any of the services mean and their characteristics.

I am open to anything that is needed and add this device:

Here are some screenshots:

Hi, how can I access ibs-th2 mass memory? (internal memory)
thanks

Hi.

I've added support for PVVX and ATC1441 alternative firmware to CGDK2 sensor.
Please, review my PR.

Allow iBeacon decoder to correctly report the battery level for iBeacons which transmit this instead of the tc power at "manufacturerdata", 48, 2

Since I have iBeacons which transmit the tx power as well as iBeacons which at the same index of the manufacturerdata transmit the battery level I have so far made the distinction and reporting in openHAB. With the new theengs decoders the tx power is reported fine for such iBeacons, but the battery power transmitting ones are falsely reporting an ever changing tx power.

Having tested a bit with the decoder definition the following

const char* _ibeacon_json = "{\"brand\":\"GENERIC\",\"model\":\"IBEACON\",\"model_id\":\"IBEACON\",\"condition\":[\"manufacturerdata\",\"=\",50,\"index\",0,\"4c00\"],\"properties\":{\"mfid\":{\"decoder\":[\"string_from_hex_data\",\"manufacturerdata\",0,4]},\"uuid\":{\"decoder\":[\"string_from_hex_data\",\"manufacturerdata\",8,32]},\"major\":{\"decoder\":[\"value_from_hex_data\",\"manufacturerdata\",40,4,false]},\"minor\":{\"decoder\":[\"value_from_hex_data\",\"manufacturerdata\",44,4,false]},\"battery\":{\"decoder\":[\"value_from_hex_data\",\"manufacturerdata\",48,2,false],\"post_proc\":[\"/\",10]}}}";
/*R""""(
{
   "brand":"GENERIC",
   "model":"IBEACON",
   "model_id":"IBEACON",
   "condition":["manufacturerdata", "=", 50, "index", 0, "4c00"],
   "properties":{
      "mfid":{
         "decoder":["string_from_hex_data", "manufacturerdata", 0, 4]
      },
      "uuid":{
         "decoder":["string_from_hex_data", "manufacturerdata", 8, 32]
      },
      "major":{
         "decoder":["value_from_hex_data", "manufacturerdata", 40, 4, false]
      },
      "minor":{
         "decoder":["value_from_hex_data", "manufacturerdata", 44, 4, false]
      },
      "battery":{
         "decoder":["value_from_hex_data", "manufacturerdata", 48, 2, false],
         "post_proc":["/", 10]
      }
   }
})"""";*/

const char* _ibeacon_json_props = "{\"properties\":{\"mfid\":{\"unit\":\"hex\",\"name\":\"manufacturer id\"},\"uuid\":{\"unit\":\"hex\",\"name\":\"service uuid\"},\"major\":{\"unit\":\"hex\",\"name\":\"major value\"},\"minor\":{\"unit\":\"hex\",\"name\":\"minor value\"},\"battery\":{\"unit\":\"Volt\",\"name\":\"battery\"}}}";
/*R""""(
{
   "properties":{
      "mfid":{
         "unit":"hex",
         "name":"manufacturer id"
      },
      "uuid":{
         "unit":"hex",
         "name":"service uuid"
      },
      "major":{
         "unit":"hex",
         "name":"major value"
      },
      "minor":{
         "unit":"hex",
         "name":"minor value"
      },
      "battery":{
         "unit":"Volt",
         "name":"battery"
      }
   }
})"""";*/

works fine in reporting

…,"major":1,"minor":1,"battery":1.5}
and
…,"major":1,"minor":2,"battery":2.8}

for two of my battery voltage transmitting iBeacons.

So my idea was to have both the tx power and battery voltage included in the decoder, both with appropriate conditions, as in

…
"power":{
         "condition":["manufacturerdata", 48, "b"],
         "decoder":["value_from_hex_data", "manufacturerdata", 48, 2, false]
      },
      "battery":{
         "condition":["manufacturerdata", 48, "0"],
         "decoder":["value_from_hex_data", "manufacturerdata", 48, 2, false],
         "post_proc":["/", 10]
      }
…

obviously along with the appropriate _ibeacon_json and _ibeacon_json_props definitions.

Trying this I came across two issues:
• even just adding the condition "condition":["manufacturerdata", 48, "0"], to the plain vanilla battery only iBeacon_json.h above, which should report my 1.5 V iBeacon, OMG throws an exception, whenever an iBeacon is recognised. While the docs say, that "manufacturerdata" is a valid properties condition, I have not found any other decoders, which have a manufacturerdata properties condition. Could there be an issue with it - or where is my thinking wrong here?

• Also, if the manufacturerdata properties condition would not throw an exception, to fully implement the tx power vs. battery voltage differentiation it would require many OR conditions, with "condition":["manufacturerdata", 48, "8"] up to "condition":["manufacturerdata", 48, "f"] to recognise as tx power and "condition":["manufacturerdata", 48, "0"] up to "condition":["manufacturerdata", 48, "7"] for the battery voltage. Any possibility to have such ranges definitions shortened in properties conditions?

Any help with why my currently testing properties condition with manufacturerdata throwing an exception would be greatly appreciated, as without the manufacturerdata properties conditions it is either tx power or battery voltage.

A possibly shorter range definition might be a nice to have for the future.

Looking to get a decoder for a Fluval Plant Nano 3.0 aquarium light. I suspect this would work for their other Plant and Marine lights as well.

I have found the following from the unit I have:

• OpenMQTTGateway BLE gateway sends this message from the device:
  • Topic: ble/OpenMQTTGateway/BTtoMQTT/44A6E572B3C6
  • Payload: {"id":"44:A6:E5:72:B3:C6","mac_type":0,"name":"Nano5Gallon","manufacturerdata":"30313532303130330000000000000000000000000000","rssi":-82,"txpower":-97}
• Using nRF Connect I am able to connect to the unit and get information, but do not see a way to export it so I grabbed screen shots, below. They overlap a bit and should be in order.

I am willing to do some leg work but don't know what I need to do beyond this step.

First Client Item:

Second Client Item:

Third Client Item:

Server Items:

Describe the bug
Theengs detected BM2 battery monitor, but only shows a single sensor which display only 100%, not actual values like voltage.

To Reproduce
Steps to reproduce the behavior:

1. Data processed
2. Expected voltage reading from device in mqtt
3. Showing 100%, not voltage

Environment (please complete the following information):

• version used (theengs gateway for HA v1.8)

Additional context
Read technophiles post on HA forum mentioning it should work under theengs and OMG. Unsure if this part of the component is using the correct theengs decoder, or if I'm doing something wrong

Thanks!

Is your feature request related to a problem? Please describe.
Sort of? I'm trying to use TheengsGateway to read/write data to a SwitchBot Curtain 3, and the data is not coming back decoded.

Describe the solution you'd like
Given I am running the gateway with decoding on, and there is a SwitchBot Curtain 3 in detectable range
When I look at the MQTT output for the SwitchBot device's topic
Then I should see decoded information

Describe alternatives you've considered
I have not considered very many alternatives, but I did try to get this python script to work, which it didn't. Even if it had, it would have been a development effort and a half to get working with MQTT as I am not very experienced with it.

Additional context
I ran this to get some sample undecoded data packets from 2 SwitchBot Curtain 3 devices:

python -m TheengsGateway -H localhost -padv 1

And using MQTT-Explorer, I found these events:

{
  "manufacturerdata": "6909e77d785a859e1803641204014f", 
  "id": "<MACADDR>", 
  "rssi": -60, 
  "servicedatauuid": "fd3d",
  "servicedata": "7bc04f641204", 
  "mfr": "Woan Technology (Shenzhen) Co., Ltd."
}

{
  "manufacturerdata": "6909f8552ba34b38ee016311040157", 
  "id": "<MACADDR>", 
  "rssi": -69, 
  "servicedatauuid": "fd3d", 
  "servicedata": "7b4057631104", 
  "mfr": "Woan Technology (Shenzhen) Co., Ltd."
}

For context, I'm coming from this openhab forum thread, where it was suggest to me to provide the sample undecoded data json. You can see my original reply just above the linked one, which has further details on set up and process for what I was trying to do.

If this is a good first issue and anyone would be willing to help guide me a little, I'd love to contribute to the solution, or at least understand how to make similar changes from sample data.

Hi,
I'm working on a plugin for Jeedom in partnership with Switchbot who generously sent me all of their hardware for testing.
So I would like to complete the list of devices :-)

Je rencontre un petit problème lorsque je lance le scan, j'ai l'erreur suivante :
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_M_construct null not valid
Aborted

Do you have any idea where the problem comes from?
Thanks for your help !!!

pi@jeedom:~/bluetooth/decoder/examples/python$ python3 ScanAndDecode.py CD:2D:2A:D7:FD:AA RSSI: -78 AdvertisementData(manufacturer_data={2409: b'\xcd-*\xd7\xfd\xaa\x92,\x10\x9f'}, rssi=-78) data sent to decoder: {"manufacturerdata": "6909cd2d2ad7fdaa922c109f"} TheengsDecoder found device: None 00:00:00:00:00:00 RSSI: -78 AdvertisementData(rssi=-78) 56:41:61:68:61:6D RSSI: -31 AdvertisementData(rssi=-31) C6:8A:0E:B8:51:72 RSSI: -74 AdvertisementData(manufacturer_data={89: b'\xc6\x8a\x0e\xb8Qr'}, service_data={'00000d00-0000-1000-8000-00805f9b34fb': b'c@@c\x11\x04'}, service_uuids=['cba20d00-224d-11e6-9fb8-0002a5d5c51b'], rssi=-74) data sent to decoder: {"servicedatauuid": "0d00", "servicedata": "634040631104", "manufacturerdata": "5900c68a0eb85172"} TheengsDecoder found device: None 02:0D:00:00:00:00 RSSI: 89 AdvertisementData(rssi=89) DF:3A:05:45:33:F6 RSSI: -64 AdvertisementData(manufacturer_data={2409: b'\xdf:\x05E3\xf6\x00\xffc\xd9[S'}, rssi=-64) data sent to decoder: {"manufacturerdata": "6909df3a054533f600ff63d95b53"} TheengsDecoder found device: None A8:03:2A:C3:91:3A RSSI: -74 AdvertisementData(manufacturer_data={741: b'\xa8\x03*\xc3\x91:'}, rssi=-74) data sent to decoder: {"manufacturerdata": "e502a8032ac3913a"} TheengsDecoder found device: None 84:F7:03:AF:EC:06 RSSI: -66 AdvertisementData(manufacturer_data={2409: b'\x84\xf7\x03\xaf\xec\x06\x8d\\"\x00\x00'}, rssi=-66) data sent to decoder: {"manufacturerdata": "690984f703afec068d5c220000"} TheengsDecoder found device: None FB:65:48:0A:ED:16 RSSI: -62 AdvertisementData(manufacturer_data={2409: b'\xfbeH\n\xed\x16\t\x83\x08 '}, rssi=-62) data sent to decoder: {"manufacturerdata": "6909fb65480aed1609830820"} TheengsDecoder found device: None DF:3A:05:45:33:F6 RSSI: -64 AdvertisementData(manufacturer_data={2409: b'\xdf:\x05E3\xf6\x00\xffc\xd9[S'}, rssi=-68) data sent to decoder: {"manufacturerdata": "6909df3a054533f600ff63d95b53"} TheengsDecoder found device: None CB:AC:B0:D9:7B:5C RSSI: -84 AdvertisementData(manufacturer_data={2409: b'\xcb\xac\xb0\xd9{\\\xe6n3X\xff\xffB'}, rssi=-84) data sent to decoder: {"manufacturerdata": "6909cbacb0d97b5ce66e3358ffff42"} TheengsDecoder found device: None C5:2B:C2:A1:CF:8B RSSI: -78 AdvertisementData(manufacturer_data={89: b'\xc5+\xc2\xa1\xcf\x8b'}, rssi=-78) data sent to decoder: {"manufacturerdata": "5900c52bc2a1cf8b"} TheengsDecoder found device: None A0:76:4E:36:4A:C6 RSSI: -70 AdvertisementData(manufacturer_data={2409: b'\xa0vN6J\xc6\x8a\xbc"\x0c\x00\x00\x00\x00\x00\x00'}, service_data={'0000fd3d-0000-1000-8000-00805f9b34fb': b'r\x00d'}, rssi=-70) data sent to decoder: {"servicedatauuid": "fd3d", "servicedata": "720064", "manufacturerdata": "6909a0764e364ac68abc220c000000000000"} terminate called after throwing an instance of 'std::logic_error' what(): basic_string::_M_construct null not valid Aborted pi@jeedom:~/bluetooth/decoder/examples/python$

Is your feature request related to a problem? Please describe.

I'd like to implement a decoder for AirTag advertisements. The public key advertised by an AirTag is partly encoded in the device's Bluetooth address. So the decoder should have access to this address.

Describe the solution you'd like

A function device_address that returns a hex string of the Bluetooth address, e.g. de479e575f8b.

Describe alternatives you've considered

None

Additional context

I think I'll also need some kind of concatenation function for hex strings. See https://github.com/koenvervloesem/openhaystack-zephyr/blob/main/modules/openhaystack/src/openhaystack.c for how the public key is encoded. The first six bytes of the public key are encoded in the Bluetooth address, then come some bytes encoded in the manufacturer data.

is possible to read data over wifi from Inkbird IBS-TH3 ?

what other options are to read data from IBS-TH3 ?

Is your feature request related to a problem? Please describe.

I need to use the decoder library in another project that already uses bleak to handle the Bluetooth connections - basically, I need a reliable parser of advertisement packets that can be installed via pip.

Describe the solution you'd like

Release pre-compiled packages of the decoder library that can be installed via pip.

Describe alternatives you've considered

• Importing the whole Theengs gateway as a dependency for my project, since that already comes with a pre-compiled version of the library
• Building the decoder library manually

Добавьте пожалуйста поддержку чайника xiaomi MiKettle