-
-
Notifications
You must be signed in to change notification settings - Fork 169
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Heltec - GW-24S4EB / HW-2.8.0 / SW-1.1.0 Device info works, but no data #384
Comments
Could you provide your YAML? Do you use the |
Sure mate! Here's the YAML - I'm using esp-idf. |
@syssi I've just managed to extract a packet capture, using the app on android. In this capture, I first connect using the app, then turn the balancer on and off a few times, finishing with an 'on'. Then I change the start voltage to 0.004 and back to 0.002. Then I change the max balance to 4, then back to 2. Then I change the battery capacity to 300, and back to 280. Then I go back to the main screen, turn the balancer off, then back on again and wait for a little while. While there I take a screenshot of the present values. The snoop log and the last screenshot are attached. If you would be kind enough to please give me any tips about how to interpret the capture / protocol, and which files need to be modified in your repository to make it compatible, I'd be really thankful - would love to learn how to do this. I've also attached a screen recording of exactly what I did during the capture - had to zip it to make it fit here - Note unfortunately I've also captured my headphones :) The relevant devices are 3c:a5:51:89:34:c5 (the Heltec Balancer) and 22:22:c9:a5:59:05 (the android tablet I took the capture on). Screenshot_2023-10-28-14-22-29-430 vlc-record-2023-10-28-14h29m25s-recording_20231028_133711.mp4-.zip |
My time is pretty limited today but I try to provide some first steps so you could move on. I will provide some more details later the weekend.
To speed things up I select all frames and use
|
|
It looks like the If you use another Android device are all frames still limited to 3 bytes per frame? This is uncommon for JK/Heltec devices. |
@syssi - I've said it before, but you're a bloody legend. Repetitive commands noted - It was because my particular flavour of android doesn't save a btsnoop_hci.log file in the debug zip - I had used btsnooz to reconstruct the logfile and it evidently did a really poor job. Regardless, I've spent the day rooting an old phone with /e/ os and have been successful at taking a new capture, this time WITH the commands and without the extraneous stuff (and in the process learnt a whole lot about adb, android etc). It is attached, along with the relevant movie . I've analysed per your suggestions above, and here's my interpretation of the command strings (frame number, vs bluetooth attribute 'write' command) - I think I can surmise that the middle 4 bytes (eg frame 1145, 6f12033c) are the set values. How '6f12033c' equates to 0.008 is beyond me though?
btsnoop_hci.log |
Aaah... breakthrough... I see now that the middle 4 bytes (6f12033c) are little endian floats - made easier to find out by using this tool - Checked and looks like my summary above is right... To turn the balancer on or off you send an INT32 1 (01000000) or 0 (00000000) respectively to register 00050d14. start voltages (command 00050214) are little endian floats commands 01040014 and 0102000014 seem to somehow be something to do with changing tabs? suspect 04 = tab2, 02 = tab 1... the last two bytes of each write command appear to be some type of CRC... I've tried a couple of things on crccalc (eg for frame 1145 ) but haven't had anything jump out at me yet... Now whats the next step to adapt your code, @syssi? |
I will try to compare your traffic with the implemented one of the past: #109 (comment) Commands: #109 (comment) |
Commands extracted from btsnoop_hci.log. See #384 (comment). |
Hmmm.. ok @syssi - well those commands look to be exactly the same commands to me... What do you think I should look at next to understand why this isn't working on this version of the Heltec? I'm happy to do the legwork :) Is there, for instance, any way that I can extract from the esp logging to understand exactly what section of code is broken / blocking for this iteration of the balancer? |
We should focus on the first few frames / interactions between the app and the balancer and try to find the difference to the ESPHome implementation. Let's extract the important parts from your ESPHome log above:
|
May be the BLE module of your balancer is a bit different to the one in the past. I will prepare a more verbose version of the component. |
Please update your YAML slightly to use this feature branch (
Flash your ESP again and provide another
|
G'day @syssi - I've made the changes requested, logs attached. I'm going to try again with ble tracker removed. |
with BLE tracker off... seems to make the connection ok, but complains about blocking too long most of the time after 'request device info'... |
Please ignore these warnings:
for now. They were introduced recently and doesn't harm in our case. See esphome/issues#4717 |
Note for myself:
|
(I'm off to bed now Syssi - so if I don't answer it's because I'm catching Z's down in the antipodes for about 7 hours or so :) ) |
I'm a bit confused it's working if the BLE tracker is disabled. Especially the disconnect of the BLE connection is unusual. May be you are right about blocking stuff / bad timings. |
@oguzatagan Could you provide the hardware and software version of your balancer? It looks like you have the same issue. |
@syssi TBH I usually turn off the BLE tracker as I don’t really know / understand what it achieves. I just turned it off in the hope that it might leave a few more cycles if the problem really was blocking behaviour. After coffee consumption has occurred, Im going to try with a different esp32 board version today just in case the problem is the board itself, to prevent us chasing our tails… TY for all your help to date👍 |
logs_heltec2_logs.txt |
|
@syssi - testing is complete. I have tested the process repeatedly - it's the board, or more specifically something about how the timings of the integration interact with the board, that is the problem. Please find attached photos of two different boards. The one on the left with the yellow legs works (it's a nodemcu clone), the one on the right (a devkit 1) does not. Please find attached two yamls - note that the only difference between these yamls and Syssi's Heltec Example Yaml is:- a) the change requested by Syssi to the debug and external source. Please also find attached to debugs logs. Any ideas about what might be issues? These two boards should really be exactly the same in behaviour - they both use ESP-Wroom-32. It's bizarre. Interestingly, in the past, I've also had issues with OTA timeouts on the board type on the right - it's the reason I introduced the following code as standard on my esphome builds:-
Cheers - M
|
Working this through I've found, using esptool, that the module on the left (the one that works) uses an ESP32-D0WDQ6-V3 chip, whereas the module on the right (the one that does not work) uses ESP32-D0WD-V3. I've been researching and come across this link regarding the problem... now researching to find the solution... the esp32-DOWD-V3 is actually a newer iteration of the Wroom-32.... |
Bizzare - I've just tried with a third board, which also uses the ESP32-DOWD-V3 chip, and this one also works... So there is something inherently 'off' with the DoIt board - perhaps it's counterfeit. Strange as your other integrations work just fine on these boards - On the bright side, though... I have found a bug. When you turn the balancing switch off in the dashboard, it does indeed actually turn balancing off... , but you need to reboot the board to see that reflected in the sensors (they continue to show balancing 'on' and operation status 'balancing'. Hitting 'retrieve settings' or 'retrieve device info' doesn't help. A reboot does. Cheers - M Apologies @syssi for wasting your time here... at the least we can now say that your integration is compatible with these earlier balancers. |
Interestingly, also, I also use Syssi's esphome-jk-bms with the exact same ESP32 board, and it works just fine controlling JK BMS's using platform: jk_bms_ble - it's only if I use platform: heltec_balancer_ble that I get this bizzaro behaviour. |
Hi All - Closing due to resolution - problem was --> board incompatibility with generic DoItESP32 using ESP-DOWD-V3. There's obviously something 'different' around BLE or Wifi with this integration that makes it not work with these boards, as the JK bms section works with them, just not the heltec. Thankyou @syssi - sorry once again for the false alarm and thankyou for the teaching / learning! TBH I'm a bit disappointedn this wasn't a different protocol in need of modifications as I wanted to learn how! Cheers - M |
The new protocol or different BLE characteristics will happen some day. Feel free to ping me again! :-) |
G'day Syssi,
I have an earlier model NEEY / Heltec Balancer and got started trying to get it to work with the ESP32 today.
seems to get the device info frame no dramas, but upon "Write register: AA.55.11.01.02.00.00.14.00.00.00.00.00.00.00.00.00.00.F9.FF (20)", request status notification, it just times out.
Have you come across any problems similar? Logs attached.
Hope you well - M
logs_neey_logs.txt
The text was updated successfully, but these errors were encountered: