No data being returned from BT-2

[mavenius]

I have things up and running, and connecting successfully to my BT-2 adapter, but I'm not getting any on_data_received logs. I am connected to three 100AH batteries (daisy-chained.) Do the changes you made as part of #15 not work when daisy-chaining? As I say that, I realize I can test it out myself by just unplugging the input cable to the battery connected to my BT-2; I'll try that and report back asap.

Either way, having this report on all batteries attached to the module would be great.

Output:

INFO:root:subscribed to notification 0000fff1-0000-1000-8000-00805f9b34fb
INFO:root:found write characteristic 0000ffd1-0000-1000-8000-00805f9b34fb
INFO:root:resolved services
DEBUG:root:create_request_payload 5000 => [48, 3, 19, 136, 0, 17, 5, 73]
INFO:root:characteristic_enable_notifications_succeeded
INFO:root:characteristic_write_value_succeeded
DEBUG:root:create_request_payload 5000 => [48, 3, 19, 136, 0, 17, 5, 73]
INFO:root:characteristic_write_value_succeeded
...

[mavenius]

Update: I'm seeing the same behavior with a single battery connected:

INFO:root:subscribed to notification 0000fff1-0000-1000-8000-00805f9b34fb
INFO:root:found write characteristic 0000ffd1-0000-1000-8000-00805f9b34fb
INFO:root:resolved services
DEBUG:root:create_request_payload 5000 => [48, 3, 19, 136, 0, 17, 5, 73]
INFO:root:characteristic_enable_notifications_succeeded
INFO:root:characteristic_write_value_succeeded
DEBUG:root:create_request_payload 5000 => [48, 3, 19, 136, 0, 17, 5, 73]
INFO:root:characteristic_write_value_succeeded
DEBUG:root:create_request_payload 5000 => [48, 3, 19, 136, 0, 17, 5, 73]
INFO:root:characteristic_write_value_succeeded

[cyrils]

Some people see different device Id for battery. Can you try 247 in BateryClient.py ?

[mavenius]

Thanks for the quick response! No change, however (except that the payload has [247,...] instead of [48,...] in the logs.)

[cyrils]

The likely issue is sill the wrong address in my opinion. I guess you set up the batteries individually using the app first and it assigned a custom address to each battery. Its hard to guess what Id they set without bluetooth snooping or brute forcing it in a for loop.

[mavenius]

Haha I considered both and already started snooping it. I'll report back as soon as I find anything out.

Thanks again!

On Fri, Sep 29, 2023, 14:00 Cyril Sebastian @.***> wrote:

The likely issue is sill the wrong address in my opinion. I guess you set up the batteries individually using the app first and it assigned a custom address to each battery. Its hard to guess what Id they set without bluetooth snooping or brute forcing it in a for loop.

— Reply to this email directly, view it on GitHub https://github.com/cyrils/renogy-bt/issues/34#issuecomment-1741290236, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABO65BHIHRNEBVCHC3K6PP3X44EDLANCNFSM6AAAAAA5MXSOQM . You are receiving this because you authored the thread.Message ID: @.***>

[mavenius]

Well, I learned a lot today!

My battery (at least the one I still have connected) has a device Id of 33. I used an Android bluetooth HCI dump and wireshark to find this, and now I can get data back from my setup. The previous message from the BT-2 to Android might be indicating that this is the device Id:

The message from Android -> Renogy to request the data (note that both start with 21 (hex for 33.)

I'll poke at it some more when I have more than one battery connected to see what the data looks like then; I'm wondering if this project could request the device Id from the BT-2 instead of having that value hard-coded.

[cyrils]

Makes sense, I wonder how this response will look like when there are multiple batteries. If you can add the hex logs we can use it to debug.

In BaseClient.py#62

logging.info(f"on_data_received: response for read operation {response.hex()}")

With one battery vs multiple batteries

[mavenius]

It looks like we'd need to query for each battery individually (with different device Ids.)

INFO:root:subscribed to notification 0000fff1-0000-1000-8000-00805f9b34fb
INFO:root:found write characteristic 0000ffd1-0000-1000-8000-00805f9b34fb
INFO:root:resolved services
DEBUG:root:create_request_payload 5000 => [33, 3, 19, 136, 0, 17, 6, 8]
INFO:root:characteristic_enable_notifications_succeeded
INFO:root:characteristic_write_value_succeeded
INFO:root:on_data_received: response for read operation 210322000400210021002100210000000000000000000000000000000000000000000000001164
INFO:root:on_data_received: response for read operation
DEBUG:root:create_request_payload 5017 => [33, 3, 19, 153, 0, 17, 86, 13]
INFO:root:characteristic_write_value_succeeded
INFO:root:on_data_received: response for read operation 210322000400960096009600969512000000000000000000000000000000000000000000008843
INFO:root:on_data_received: response for read operation
DEBUG:root:create_request_payload 5042 => [33, 3, 19, 178, 0, 6, 102, 11]
INFO:root:characteristic_write_value_succeeded
INFO:root:on_data_received: response for read operation 21030cff8900850001834d000186a02d50
INFO:root:on_data_received: response for read operation
DEBUG:root:create_request_payload 5122 => [33, 3, 20, 2, 0, 8, 231, 92]
INFO:root:characteristic_write_value_succeeded
INFO:root:on_data_received: response for read operation 2103105242543130304c46503132532d47310068d7
INFO:root:on_data_received: response for read operation
INFO:root:on_read_operation_complete
INFO:root:BT-TH-774B0DED => {'function': 'READ', 'cell_count': 4, 'cell_voltage_0': 3.3000000000000003, 'cell_voltage_1': 3.3000000000000003, 'cell_voltage_2': 3.3000000000000003, 'cell_voltage_3': 3.3000000000000003, 'sensor_count': 4, 'temperature_0': 59.0, 'temperature_1': 59.0, 'temperature_2': 59.0, 'temperature_3': 59.0, 'current': -1.19, 'voltage': 13.3, 'remaining_charge': 99.149, 'capacity': 100.0, 'model': 'RBT100LFP12S-G', '__device': 'BT-TH-773B0DED', '__client': 'BatteryClient'}
INFO:root:Exit: Disconnecting device: BT-TH-774B0DED [F4:60:77:4B:0D:ED]

I'll grab another sniff with all 3 batteries connected to see what the app is doing.

[mavenius]

Well, at least in this case, I got three consecutive Ids (33, 34, and 35.)

I've been confused for a bit as to what's going on, as I see a bunch of handshaking back and forth (but nothing where the BT-2 tells the phone what IDs to use) and then all of a sudden, the phone starts requesting data using the correct IDs.

Then I remembered that the "pairing" process in the app is where the app discovers all of the batteries. I have a feeling that is where either the app scans for all possible Ids or the BT module tells the app which Ids to use. Based on how the app presents the data (found 1 battery, found 2, found 3 in my case,) I have a feeling it's scanning. I'll dig on a new sniff of the pairing process to see.

[cyrils]

Well, its their app and their batteries, its possible they have a pre-defined range of Ids to choose from. We will know from the hex log if its bt-2 giving correct id when we try with invalid id (ex: 48 in you case). May be its a combination of both.

[cyrils]

I figured the best way to solve multiple device problem is to first connect individual devices to bt module and read using broadcast id 255. And then find out the actual device id from this output log.

I created a branch device_id for this purpose. Let me know if it prints correct device_id for you.

[mavenius]

Hmm... now I'm getting back different results depending on the run (without changing anything, just retrying a few times) :

One try:

INFO:root:subscribed to notification 0000fff1-0000-1000-8000-00805f9b34fb
INFO:root:found write characteristic 0000ffd1-0000-1000-8000-00805f9b34fb
INFO:root:resolved services
DEBUG:root:create_request_payload 5000 => [255, 3, 19, 136, 0, 17, 20, 182]
INFO:root:characteristic_enable_notifications_succeeded
INFO:root:characteristic_write_value_succeeded
WARNING:root:on_data_received: unknown operation=0
WARNING:root:on_data_received: unknown operation=204

Another:

INFO:root:subscribed to notification 0000fff1-0000-1000-8000-00805f9b34fb
INFO:root:found write characteristic 0000ffd1-0000-1000-8000-00805f9b34fb
INFO:root:resolved services
DEBUG:root:create_request_payload 5000 => [255, 3, 19, 136, 0, 17, 20, 182]
INFO:root:characteristic_enable_notifications_succeeded
INFO:root:characteristic_write_value_succeeded
WARNING:root:on_data_received: unknown operation=179
WARNING:root:on_data_received: unknown operation=238

One more:

INFO:root:subscribed to notification 0000fff1-0000-1000-8000-00805f9b34fb
INFO:root:found write characteristic 0000ffd1-0000-1000-8000-00805f9b34fb
INFO:root:resolved services
DEBUG:root:create_request_payload 5000 => [255, 3, 19, 136, 0, 17, 20, 182]
INFO:root:characteristic_enable_notifications_succeeded
INFO:root:characteristic_write_value_succeeded
INFO:root:on_data_received: response for read operation
DEBUG:root:create_request_payload 5017 => [255, 3, 19, 153, 0, 17, 68, 179]
INFO:root:characteristic_write_value_succeeded
WARNING:root:on_data_received: unknown operation=33
WARNING:root:on_data_received: unknown operation=66

It seems like we might be reading from the wrong part of a buffer, maybe?

[cyrils]

Is that when single battery is connected or multiple batteries connected?

[mavenius]

This is with multiple connected.

On Mon, Oct 2, 2023, 10:51 Cyril Sebastian @.***> wrote:

Is that when single battery is connected or multiple batteries connected?

— Reply to this email directly, view it on GitHub https://github.com/cyrils/renogy-bt/issues/34#issuecomment-1743166808, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABO65BAD57BKCY3YALPNRPTX5LIGTAVCNFSM6AAAAAA5MXSOQOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONBTGE3DMOBQHA . You are receiving this because you authored the thread.Message ID: @.***>

[cyrils]

Okay, thats expected since 255 is broadcast id and every device will respond simultaneously. The idea is to connect individual batteries and then use 255 to get the actual device_id of each battery.

I know you have already figured out that by bluetooth debug, but just wanted to know if this broadcast id trick works.

[cyrils]

Ok, no probs, I got confirmation from another user that this works. I would make this the recommended method of configuring going forward.

[mavenius]

Cool; thanks!