Test bt-2 compatibility

[cyrils]

Test if the library works with bt-2 type adapter. Some existing libraries (ex: neilsheps/Renogy-BT2-Reader) indicates the characteristics and register values are same, but I was unable to test it with a bt-2 adapter as I don't have one.

[wodrsoftware]

Hello! I have tried the last version on Windows 11 and Pyhton 3.10. But it doesn't work:

C:\Renogy> python3 example.py INFO:root:Starting client: BT-TH-0DCEC0A9 => 02:54:ED:CE:C0:A9 Traceback (most recent call last): File "C:\Renogy\renogy-bt1-2.0\example.py", line 25, in BTOneClient(config, on_data_received).connect() File "C:\Renogy\renogy-bt1-2.0\renogybt\BTOneClient.py", line 36, in connect self.manager = DeviceManager(adapter_name=self.config['device']['adapter'], mac_address=self.config['device']['mac_addr'], alias=self.config['device']['alias']) File "C:\Renogy\renogy-bt1-2.0\renogybt\BLE.py", line 9, in init super(). init(adapter_name) TypeError: object.init() takes exactly one argument (the instance to initialize)

bye, Wolfgang

[cyrils]

Hello, the gatt library for BLE communication is not supported in Windows platform, please try in a Linux environment (ex: Raspberry Pi)

[RichardHyde]

Hi,

I tried this out my BT-2 and I'm not getting very good results. I do see data out occasionally, but sometimes all the values are zeros, and most of the time I get "unknown operation" warnings.

My setup consists of a Renogy BT-2 attached to a Renogy DC-DC 50 and two 100ah Renogy Lipo batteries. A 100w folding solar panel is supplying the sun juice for the time being. The software is running on a Pi Zero 2 W with a fresh install of Raspberry PI OS and all the latest apt updates applied. As far as I can see everything is running the latest firmware

I've attached a log file created running the example.py for about 30 minutes with a 30 second update interval if that helps.

Let me know if there's any more information you need, or if you need anything captured from the BT-2. I'm new to BLE but I'll try and help, and pick it up as quickly as I can.

renogy-bt2.log

[cyrils]

@RichardHyde Thanks for checking. From the logs it looks like its technically possible, but there is some minor glitch on intrepreting response. Do you also mind logging the received hex response? BTOneClient.py:82 -> logging.info("on_data_received: {}".format(value))

[RichardHyde]

@cyrils No problem. See the attached log file.

Again, covering about 30 minutes with a 30 second update from this morning.

Hope that helps and let me know if you need anything else.

renogy-bt2.log

[cyrils]

Looks like BT-2 sends data in chunks of 20 bytes in contrast to BT-1 which sends everything together. So I should either read multiple times and combine the responses or break down the requests into smaller parts.

[RichardHyde]

I was just playing around with storing the received data until there's enough to process a response.

From what I can see the read responses (starting 0xff 0x03) always seem to come back in one chunk, however there are other operations being returned which seem to be split into multiple chunks. Do you see these other operation responses on a BT-1?

Is looks like __on_data_received is only being called once per polling interval, rather than when there's data available, meaning data from other operation types is buffered until the next loop, rather than being processes and ignored as it comes in. Does that sound plausible?

[cyrils]

I expect only read response 0xff 0x03 from bt-2 as well. The other 'unknown operation' could be a misinterpretation from the partial data chunk. Buffering / reading multiple times sounds like the right solution to me. This is not an issue in bt-1 as it sends entire data in one chunk.

[RichardHyde]

I think I've found the problem. As I mentioned my setup includes two Renogy batteries, which also have communications ports, and are linked into a Renogy communication hub along with the solar charger, and the BT-2 plugs into the primary port of the hub. If I disconnect the batteries from the hub I just get the 0xff 0x03 messages back reliably for each request and nothing else, so the battery chatter is throwing things off.

So I'd say that this library is working with the BT-2 providing you're only talking to the charge controller.

I'll have a play around and see if I can request the values just from the charge controller and not the batteries.

[cyrils]

I'm curious if the Renogy BT app will work with this setup.

[RichardHyde]

The official Renogy DC Home app does and gives information of the batteries. I wish I had some the aurdino skills/equipment to give the Renogy BT2 Reader library you linked to a try to see how/if that handles it.

Did you want me to put together a pull request with the changes I've made to buffer the received data until there's enough for a complete response?

[cyrils]

Yes, please create a pr against buffering branch.

There is a separate Renogy BT app, is that working with your system? The device id 0xff is supposed to handle the device targeting, not sure why everything responds to this.

[RichardHyde]

I tried out the Renogy BT app (iOS) and sure enough it stopped updating with the batteries plugged into the communication hub, but started updating again once they were unplugged

[cyrils]

Makes sense.

[cyrils]

@RichardHyde I just realized why the chatter from all the devices, because 255 device id means we are broadcasting to all devices. If you somehow figure out the individual device Ids you might still be able to communicate with controllers and batteries individually. Related issue https://github.com/cyrils/renogy-bt/issues/34.

[RichardHyde]

@cyrils Interesting. Do you have any idea what a device id would look like? A byte or something longer? I'll take a look into it. If it's something short i could try brute forcing it see what I get a response from.

[cyrils]

So far the possible device ids for battery are 48, 33 and 247. The code base has changed since then, it supports reading batteries, you might have to checkout the new readme for details. No idea what are possible values for charge controller though. You might have to check Android bluetooth HCI dump as mentioned in above issue.

[RichardHyde]

Thanks for the update. I'll get the latest code base and test it out tomorrow, and report back what I find out

[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.

[RichardHyde]

That's working great! I used your device_id branch with the batteries unplugged and a device_id of 255 in the config and got back a device_id of 97 in the output, so changed the config to 97, reconnected the batteries and I'm getting a response back from the controller now.

[cyrils]

Great, I wonder if this trick works with batteries too. (If you want to know the individual cell data). Let me know the hex output printed in case you run 255 with single battery.

[RichardHyde]

I did try disconnecting the controller and running with a device_id of 255 and a type of RNG_BATT but I didn't get any data back. I'll try again tomorrow with just one battery connected.

[RichardHyde]

Yep, with only one battery connected and a device_id of 255 and a type of RNG_BATT I got a response with a device_id I can then use to query the device directly even with everything connected. 48 and 49 for each of the batteries in my case.

I've currently created three config files, one for each of the batteries and one for the controller, which I then pass to example.py in turn, and post the controller and battery data to MQTT.

It'd be nice to get that device information in one config file (hint, hint)

[cyrils]

Gotcha, thanks for testing. And about the separate configs, I thought it gives more flexibility in logging for different types of devices, like deciding which fields to log, frequency of reading etc. I can look into how to better consolidate it.

[RichardHyde]

That's fine don't worry, it's an example so I don't expect it to get too advanced 😀

The whole point of creating a Renogy python module as a building block for people to use to write their own specific tools, I just need to pull my finger out and write my own python script to query the three devices.