Neey - developments with Web GUI and Modbus TCP

[paulalting]

I am starting a new discussion here on my developments with a Neey 4th generation active balancer.

My discussions first started in another discussion #402 NEEY 4TH SERIAL PORT, but has become too polluted with other stuff not related.

The outline of the developments:
I purchased a Neey 4th gen unit with the expectation that I would at some point hack it to communicate over hard wire rather than over Bluetooth.

I do not favour Bluetooth for anything that needs reliability and dependability, hardwire is the only method in my opinion for robust and reliable communications.

So, after having the Neey installed in my main system, 16 cells of 400Ahr LiFeYPO4, Winston cells and operating for the best part of one year very nicely, the time came for me to take it out and start my hacking adventures, which led me to this site.

Thanks to @syssi - Sebastian and the work he has already done with some others in decoding the data frames that both the Neey and Heltech active balancers share, the job was made a lot easier for me, thank you.

The first thing I needed to do was to sniff data that was being sent from the balancer MCU to the BLE module. I did this with a simple TTL to USB interface, with just the receiver line connected to the balancer MCU transmit line. I got data, great.

The next thing was to remove the Bluetooth module, carefully lifting it off the board. Then with that out of the way, connect the TTL USB interface transmit line to the balancer board MCU receive line.

Then some coding was in order, so started to code away and do some testing, the results are in the other discussion #402.

So, the whole point of what I am trying to achieve is to have a nice solid reliable hardwire connection 24/7 that never drops out.
This will be connected to my SCADA system, something I make that runs on Debian. I do not use ESPHome.

Some of my initial thoughts were around using my dedicate small low power MSI Cubi 3 (NUC) running Debian headless with soem Python code to communicate directly with the Neey. The idea would work and is not a bad idea, just I thought it would be better to have a small cheep controller board handle the simple data processing directly and present it as I need to the main SCADA software I run on the Debian system which will handle my off-grid system.

To prove I have control of the Neey in every respect, I take a small 32 bit Arduino type board based on a SAMD-21 MCU, very cheep and has the necessary features. Most importantly, one communications port that can directly connect to the Neey MCU communications port, remembering this is all 3.3V logic.

So, back to coding, I code up some code that presents as a VT220 type terminal to the connected computer to display a nice cursor based screen so that data is locked to screen position. The Arduino type board then is able to send and receive and decode data from the Neey itself. This data is displayed on the computer screen. It accepts commands from the computer, such as the various commands that are available from the Android application, such as setting number of cells, the various start and stop voltages and the enable of the balancer function plus others.

I then got to thinking. The thinking led me to then swapping out the Seeed XIAO board with an Adafruit Feather board based on the same MCU, just more I/O.

I started a new project and with very little work migrated the code over to the Adafruit Feather board and again, it all worked well.
Then, after a bit more thinking I thought, well, I have some W5500 Ethernet modules, so I popped one of them on my development breadboard and wired it up to the Feather using SPI.

I then set about coding a simple HTTP web interface and showed that that was easily possible, although it needs more work to take input via the web interface and I would want for other features too, such as using javascript to handle client side with AJAX back to the Feather and possibly websockets just to add to the fun.

But then my thinking needed me to get back on track and get back to what I really need now. I can play other more fancy web interfaces later.

So, I pulled in the Modbus TCP libraries and have now started some initial testing with this, which looks very promising.
In fact, I have the Feather still having the HTTP web interface on port 80 while the Modbus TCP is working simultaneously on port 502 being accessed from another computer than the web interface.

Again, all this in action while the VT220 terminal code in the Feather is functioning as well, so I find that quite impressive.
At some point, I will remove the VT220 command console from the Feather once I have developed the HTTP web interface to a point that allows the full functionality of real time viewing of the system as well as being able to program the various setpoints in the Neey.

Another benefit of having the Modbus TCP is that if you have multiple Neey's then each one is addressable and then easily accessed by what ever Modbus TCP client you choose to use. I know there have been people out there that have been looking for a way to individually access these units.

I'll like to keep this discussion open for people who might also be interested in what I am doing for their own needs based around the Neey Active Balancer.

I will create my own project repository at some point, which will have the code with more detailed information as thinsg get developed.
Vonbaron :)

[karibe66]

This is a great job, I can confirm that bluetooth connection with Neey balancer is very poor and not stable. Unfortunately I usually work with Home Assistant, will your work be integrated for Home Assistant too?

[paulalting]

Hi Mario, thanks, I am actively working on the code, mostly to fit my own needs.
But it is possible that this could be available for integration, I would need to check with Sebastian on the details at some point in time.

As I mentioned, the code has a Modbus TCP server built in now and it functions reliably, though I still need to do some work around having setting of new values. The real time reading of all the data is fine. If Home Assistant can work with Modbus, then this might be an easy solution. We would need to make sure the Modbus mappings were defined correctly for Home Assistant.

There might be other methods too, as the project is now using a more advanced http server, so serving up json data now is working. If Home Assistant can use json formatted data over http, then that is another solution.

I have been spending the past week on a lot of testing of the serial communications and I am now confident this is solid.
Much better than using radio waves such as Bluetooth.

I'll keep this discussion updated as I develop, but ask any questions and maybe Sebastian may have some input.

[paulalting]

A sample of Neey data in json format from the little Feather M0 http server.
This json packet will be expanded to include other features I have in mind, to make this a real BMS, not just a balancer.

[syssi]

@karibe66 At some point I would like to rewrite the heltec_balancer_ble component. The BLE layer must be replaced by some UART handling. I don't own the Heltec balancer so I'm dependent on heavy testing of users.

[karibe66]

Thank you. I would be glad to test the Neey Balancer with modbus TCP. As far as my skills can handle it of course. Il lun 22 gen 2024, 14:00 Sebastian Muszynski ***@***.***> ha scritto:

…

@karibe66 <https://github.com/karibe66> At some point I would like to rewrite the heltec_balancer_ble component. The BLE layer must be replaced by some UART handling. I don't own the Heltec balancer so I'm dependent on heavy testing of users. — Reply to this email directly, view it on GitHub <#413 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFJAYFDYBTIUJ7GFER3M7K3YPZPF5AVCNFSM6AAAAABB2CG7CCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DEMBYGM2TM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[karibe66]

Good job Paul , as far as I know json code can be handle in Home Assistant via mqtt. So I am sure that you and syssy can provide a solution adaptable to Home Assistant too. Thanks Il lun 22 gen 2024, 12:38 Paul Alting van Geusau ***@***.***> ha scritto:

…

A sample of Neey data in json format from the little Feather M0 http server. This json packet will be expanded to include other features I have in mind, to make this a real BMS, not just a balancer. image.png (view on web) <https://github.com/syssi/esphome-jk-bms/assets/6613172/566fa0f2-cfa4-4ea6-ab68-57f5fe79fa0c> — Reply to this email directly, view it on GitHub <#413 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFJAYFEDWX7RMDLYYXAFY3TYPZFULAVCNFSM6AAAAABB2CG7CCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DEMBXGUYTA> . You are receiving this because you commented.Message ID: ***@***.***>

[paulalting]

A little update.
Progressing along with the web application part over the past few days.
Have it now at a point that I can control the balancer from the web application, being able to set the various settings at the click or two of the mouse.

The underlying web application uses a small amount of javascript and a small helper library to provide data binding.
This allows the web application to then request a simple json data packet from the server on a regular time period, say each one or two seconds. This json data packet is kept small in size, at around 1kB.

The web application is at around 10kB in size and there is also a small css file served as well.

Using an approach like this provides a nicer web interface, it is not a simple refresh of the complete web page, which would then consume a lot more data in each update.

Anyhow, below is the current appearance of the web application, running very nicely.
I can access this from multiple computers and again, the Modbus TCP server is also running and works concurrently with the http server.

Next will be adding some BMS functions and other statistical things and perhaps some other graphical goodies, like bar charts.

[paulalting]

And this is the little proto setup, very simple.
The 3.3 volt supply is supplied from the main Neey from the 12V line, actually 13.8V to power a little efficient switch mode supply to take it to 3.3V.

The whole proto board takes around 50mA, that is power supply, Feather M0 and a W5500 Ethernet module, pretty good actually and is not a problem from the main Neey supply. That power supply could be connected directly to the battery, in my case 55V LiFeYPO4.

The USB cable is simply for programming and is not used otherwise.
I have the Feather on board regulator disabled so the USB does not power the whole show. The Feather has this feature already, the enable line to the regulator, just pull it down to ground.

[Lukas-Scholz]

Hey Paul, you are working on great project so far. Do you have any new information you can share with us? Or is it possible that you can share your developed code in status quo so that the community can help to further develop this project?

[paulalting]

Hi Lukas,
No new information to date, the system is performing well so far.
I also would like to get MQTT or maybe other protocols when I get back to it in a few months from now.
There is more I wish to do yet, but currently in the middle of large project commissioning for my work side of life.
I am happy to share what I have, and can make the code available when I return from on site commissioning in around 14 days if that works ? You can email me directly too Lukas and I can probably get code base to you sooner if I am able.

This is how it is at the moment with cover off.