diy solar

diy solar

JBD BMS Wi-Fi Module

I am finally integrating the jbdtool into a NodeRed flow to send the battery data to an MQTT broker and then SignalK.
To accomplish this I use this command: jbdtool -t serial:/dev/ttyOP_electron -m localhost:electron:vessels/self/battery/bat1 -J
The MQTT receives the data but the content is Null.
It seems that the word 'vessels' inside the topic is maybe considered a reserved word?
If I use the topic written slightly different, like 'vesselt' it works fine.
I have attached an MQTT capture to show that with the word 'vessels' the content is Null, instead with the word 'vesselt' the content is the actual battery data. Even with other words works fine, this is why I thought to a reserved word.

Anyone has a clue, please?
Thanks in advance
 

Attachments

  • Capture.PNG
    Capture.PNG
    31.2 KB · Views: 29
All right, thank you so much for your kind help and taking the time to answer and give it a try, much appreciated.
So it seems all is working fine, it is just a matter of how the '-r -a' works then.
I thought it could be an issue with the USB TTL converter or something else, I am encouraged that it is the same for you. :)
;)

That's correct - it has to read every register from the eeprom and it takes a while - even over wifi
 
I had a similar problem.
I have a daemon running that polls the bms in a loop.
It worked reliably for many months.
I stopped the daemon to develop some new features and then noticed this command was returning "{}".
`jbdtool -t serial:/dev/ttyUSB0 -J`
Changing to this `jbdtool -d2 -t serial:/dev/ttyUSB0 -J` made it work.
Its a "jiggle the handle" workaround but it makes the util return a json object :)
Can you try adding -d2 and report back?
tagging @melkier .

So it doesn't work unless you enable debugging output? Oh that's going to be fun to chase down .. I'll take a look at it.
 
So it doesn't work unless you enable debugging output? Oh that's going to be fun to chase down .. I'll take a look at it.
Hi dear Melkier, first of all thanks for sharing your project and the code you developed. Tremendous help to develop JBD BMS dashboard and control.
May I add that even I erratically receive the command returning "{}"?
Furthermore, the last pi_static version gives an error if no mqtt credentials entered (I am using the SignalK mqtt plugin without authentication); I am using the previous version that works quite well.
 
I am finally integrating the jbdtool into a NodeRed flow to send the battery data to an MQTT broker and then SignalK.
To accomplish this I use this command: jbdtool -t serial:/dev/ttyOP_electron -m localhost:electron:vessels/self/battery/bat1 -J
The MQTT receives the data but the content is Null.
It seems that the word 'vessels' inside the topic is maybe considered a reserved word?
If I use the topic written slightly different, like 'vesselt' it works fine.
I have attached an MQTT capture to show that with the word 'vessels' the content is Null, instead with the word 'vesselt' the content is the actual battery data. Even with other words works fine, this is why I thought to a reserved word.

Anyone has a clue, please?
Thanks in advance
I figured it out, it is my poor knowledge of all of this stuff; blame on me.
Digging down I understood that the SignalK mqtt plugin, writes directly into SignalK keys and for that specific mqtt topic it accepts only numeric values, so any string is passed as null.
 
Hi Melkier,
find attached some debug files taken when I receive no asnwers from jbdtool.
I am not able to understand if it could be the USB TTL converter or is the same issue encountered by smoothJoey.
Hope this helps
 

Attachments

  • debug crc error.txt
    2 KB · Views: 3
  • debug empty json.txt
    2 KB · Views: 2
  • debug segmentation fault.txt
    1.3 KB · Views: 2
Hi Melkier,
find attached some debug files taken when I receive no asnwers from jbdtool.
I am not able to understand if it could be the USB TTL converter or is the same issue encountered by smoothJoey.
Hope this helps

What system/os are you running it on? Raspberry PI? If so, which one? if not, Windows? Linux?
 
ok here's a statically compiled version for the PI4B 64-bit. please test it.

this wont work if you're running a 32-bit OS on it (uname -m will tell you)
 

Attachments

  • jbdtool_pi4-64_static.zip
    2.7 MB · Views: 7
Hi Melkier, thank you so much.
The output of uname is armv7l so I guess it is a 32 bit processor.
Anyway, I have tried to run the executable you sent me and it doesn't work because it's 64 bit.
 
Try this one for a PI3B 32-bit

jbdtool: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, for GNU/Linux 3.2.0, BuildID[sha1]=e633c55ab3293efb0c64ec1ebafd6fbd54cce8a1, with debug_info, not stripped
 

Attachments

  • jbdtool_pi3-32_static.zip
    2.4 MB · Views: 5
Hi Melkier,
I tried this one and it seems to be working better, even if the first time I executed it returnd the empty brackets as well.
Would you mind suggesting how to cope with the authentication failur sending to MQTT, please?
I use the MQTT gateway embedded into SignalK without authentication and it returns the error below.
 

Attachments

  • Capture.PNG
    Capture.PNG
    11.1 KB · Views: 18
on the FIRST time executing it, can you give me the output when using -d 6?

I'll load up SignalK on a VM and test against it. I'm using the PAHO client - there may be a compatibility issue.
 
Here you go.
Thank you so much for helping on this, much appreciated.
 

Attachments

  • debug.txt
    16.4 KB · Views: 3
Here you go.
Thank you so much for helping on this, much appreciated.

OK that's very strange. Are you sure nothing else is talking to the BMS while you are pulling data from it?

Because I'm asking the BMS for the "basic information and status" (DD A5 03) and it's returning the hardware version info (DD 05). It's supposed to return DD 03 (basic info).

I've modified the source to check the register being returned and reject the packet (if it's not what was requested).

Attached is the updated program. Please re-run it again with -d 6 and send me the output.
 

Attachments

  • jbdtool_pi3-32_static.zip
    2.4 MB · Views: 3
Hi Melkier,
you are right; I completely forgot that there is a NodeRed flow running in the background that polls jbdtool.
Please find attached 2 debug files: one made with the version you sent me two days ago and one with the version you sent me yesterday.

Thank you in advance
 

Attachments

  • debug.txt
    1.9 KB · Views: 2
  • debugold.txt
    1.9 KB · Views: 2
Hi Melkier,
you are right; I completely forgot that there is a NodeRed flow running in the background that polls jbdtool.
Please find attached 2 debug files: one made with the version you sent me two days ago and one with the version you sent me yesterday.

Thank you in advance

You're using a serial connection and so only one should be using it at a given time. I've updated the program so that it will lock the target - so 2 instances of jbdtool will not be able to use it at the same time. The default behavior is to wait until the resource is free. I've added the -N option to make the program exit immediately with "resource unavailable" if another jbdtool has it in use on the same system.

Please test this new version with -d 6 and send me the output if you would. Make sure nodered is using the same version (so it locks the target).

This new version is "jbtool version 1.8 build 202204110815" - make sure all scripts are using this
 

Attachments

  • jbdtool_pi3-32_static.zip
    2.4 MB · Views: 9
Last edited:
It will lock any jbdtool instance or any using the same serial port?
I am asking because I control 2 batteries with different bms and different connection serial port.

I am going to test it now.

Thanks
 
Tested, find attached the debug file.
I also tested it running from terminal in the same moment NodeRed was using it and it waits giving the reply as soon the resource has been freed.
Nice feature indeed.

Cheers
 

Attachments

  • debug.txt
    9.2 KB · Views: 2
Back
Top