Using Solar Assistant to read multiple batteries of different types

[fmeili1]

Just posted it to:

Resource icon

EG4 PowerPro WallMount OutDoor Modbus data collection in Python

Mar 8, 2025

EG4 PowerPro polling, Raspberry Pi 4, WaveShare USB/Modbus, Python

• wpns
• Software

Enjoy!

And _PLEASE_ let us know if you sniff any more useful data about the Battery One Protocol!

I'm still a bit lost and try to understand how all this is related to get a clear picture.

Btw. I'm only using open loop (no communication between batteries and AIOs and no communication between each batteries) and I still want to use SA to show my battery data!

I'll try to summarize what I've understand so far after reading your posts and the comments with your python code.

1. SA needs to use the batteries with the "default protocol" - by starting with dip switch 2 for the fist battery, 3 for the next and so on. SA is not able to use the so called "address 1 protocol" which seems to be a special EG4 protocol, which will be active if the first battery dip switch would be set to 1.
2. Does the EG4-LL protocol specification, which I've already uploaded to the resource section, only describes this special EG4 protocol (address 1 protocol)?
   If yes, what is the "default protocol" which is currently used to let SA communicate with the batteries? Is this maybe the so called "Pylontec" compatible protocol? Is there a link to a spec? In SA it's just called "USB Modbus RS232/485" in the battery communication settings.
3. My first assumption was that SA is using the protocol from the above mentioned EG4 specification (address 1 protocol) to communicate with the batteries - but this seems it was a wrong understanding from my side.
4. If I'm right, I can forget the above EG4 "address 1 protocol" spec because SA would not longer work. As a result I need to do the modbus sniffing with the "default protocol" (Modbus RTU over RS485) - whatever it is.
5. Because of your last sentence to let you know about results of the "Battery One Protocol", I now realize that your python code is using the "default protocol" (Pylontech?).

In the special EG4 "address 1 protocol" there are some additional registers defined e.g. 4 temperature sensors, cycle count, etc. which SA does NOT currently show for my EG4-LL batteries (the worst thing is that even the cycle count is missing). Here is an example from battery 1 to show which data does SA provide for my batteries - it's not very much!



This is what I'm using to connect SA to the 12 batteries.



Does this mean that the "default protocol" does not provide e.g. cycle count information or is it just a weakness of SA to not requesting/showing it?

The main reason why I want to sniff the modbus communication is to get the SOC value into my DIY Chargeverter CAN controller but it would also be great add some additional benefits while sniff some other values (e.g. cycle count, 3 more temperatures, etc.) and provide them via MQTT to my smart home system.

But now I'm not sure if these additional values are already on the "wire" to sniff them (e.g. cycle count) - independent if SA does show them or not.

I don't know if SA needs to request every defined modbus register explicitly which it displays or do the batteries broadcast all registers (e.g. including the cycle count, etc.) to the modus sbut SA is ignoring some of them? For SOC it would be possible to sniff it because SA is showing it, but I don't know if the other values e.g. cycle count are available. If not, my idea to sniff the additional data would not work. I don't even know ithe "default protocol" defined more than one temperature sensor or the cycle count, etc.

I know there are a lot of questions and thoughts - but maybe someone can bring a bit light in my confusion.

 

[wpns]

Btw. I'm only using open loop (no communication between batteries and AIOs and no communication between each batteries) and I still want to use SA to show my battery data!

Would it be possible to let SA talk Modbus to your batteries and have your own infrastructure talk to the batteries using CAN?

Alternately, subscribe to SOH from the SA MQTT broker?

1. SA needs to use the batteries with the "default protocol" - by starting with dip switch 2 for the fist battery, 3 for the next and so on. SA is not able to use the so called "address 1 protocol" which seems to be a special EG4 protocol, which will be active if the first battery dip switch would be set to 1.

I believe that to be correct, (almost?) no-one knows the Secret EG4 Combined Battery Protocol (SECBP), so SA can't use it either.

1. Does the EG4-LL protocol specification, which I've already uploaded to the resource section, only describes this special EG4 protocol (address 1 protocol)?

No, that's the normal EG4 battery protocol, which is getting a little long in the tooth and is poorly documented, and which the PowerPro WallMount batteries do not completely conform to, but it's the best we've got.

1. Because of your last sentence to let you know about results of the "Battery One Protocol", I now realize that your python code is using the "default protocol" (Pylontech?).

The larger chunk of my code is using the documented EG4 battery protocol above, there's a different routine when the battery address is one that picks out what it can that I've been able to guess at from visual inspection of the first few registers.

I was hoping that you could find out more by sniffing the SECBP, but if SA isn't using that, then that's a forlorn hope.

there are some additional registers defined e.g. 4 temperature sensors, cycle count, etc. which SA does NOT currently show for my EG4-LL batteries (the worst thing is that even the cycle count is missing).

Yeah, I've heard that the SA EG4 Modbus code is <ahem> not working well at the moment, but to be fair it's in Beta, so my expectations are low.

Does this mean that the "default protocol" does not provide e.g. cycle count information or is it just a weakness of SA to not requesting/showing it?

Both protocols provide cycle count information (SECBP at 30, though note it's pack-wide, and Normal EG4 at 29 and 30. Yes, this probably means SECBP is 29 and 30, but until I have 64K cycles it'll remain a mystery, so ask me again in a couple of hundred years. )

The main reason why I want to sniff the modbus communication is to get the SOC value into my DIY Chargeverter CAN controller but it would also be great add some additional benefits while sniff some other values (e.g. cycle count, 3 more temperatures, etc.) and provide them via MQTT to my smart home system.

If you already have CAN skills, then maybe you can talk to the batteries over the CAN bus?

But now I'm not sure if these additional values are already on the "wire" to sniff them (e.g. cycle count) - independent if SA does show them or not.

There's a lot of stuff in the normal protocol, I suspect that SA doesn't parse it all yet. Look at the SQ MQTT broker with something like MQTT Explorer and see what it says about the various batteries, and then subscribe to the data of interest (or just subscribe to everything and parse out the bits you want).

I don't know if SA needs to request every defined modbus register explicitly which it displays or do the batteries broadcast all registers (e.g. including the cycle count, etc.) to the modus sbut SA is ignoring some of them?

CAN is a broadcast thing, Modbus is 'ask for every register you want', but because that's inefficient due to the overhead of single-register queries, there's a ...read_registers command to read multiple registers at a time. However, various equipment can only return a limited number of registers at a time (40 for the inverters, 10 for the batteries), so I read all the 50 registers I need from the batteries 10 at a time.

For SOC it would be possible to sniff it because SA is showing it, but I don't know if the other values e.g. cycle count are available.

SOC is register 21 in SECBP, and 24 in the normal protocol.

I _know_ there's a lot more in the SECBP because the monitor... website shows individual battery stats, including firmware revisions, but I suspect EG4 hasn't gotten that information from LUX, or have chosen to keep it secret for "competitive" reasons, as silly as that is.

@James Showalter help us out here, you're our only hope!

 

[fmeili1]

Would it be possible to let SA talk Modbus to your batteries and have your own infrastructure talk to the batteries using CAN?

My hope was to reuse the existing wiring which already connects each battery to SA via modbus RTU - I a port left in the passive RS485 HUBs and would love to just add an additional modbus connection to my ESP32. But if nothing else works, CAN may be an alternative.

Alternately, subscribe to SOH from the SA MQTT broker?

This is what I've already implemented as a temporary solution - the DIY Chargecontroller subscribes to the SA MQTT topic for SOC to feed the ESP32 rule which decides when, with how many amps and for how long the gird should be used.
This works, but as a final solution I would get rid of the MQTT detour and hoped to get the SOC directly from the batteries via modbus (it would be great if the solar system controlling would not rely on other external systems to be functional to make it more robust - at the moment an external mosquitto broker is at least involved and even it's running on an 9 year old iNTEL NUC as a docker image, it's an additional point of failure). A direct battery communication would even work if WiFi may be down.

There's a lot of stuff in the normal protocol, I suspect that SA doesn't parse it all yet. Look at the SQ MQTT broker with something like MQTT Explorer and see what it says about the various batteries, and then subscribe to the data of interest (or just subscribe to everything and parse out the bits you want).

I've already checked that with the MQTTExplorer, but SA does just publish the exact same values which it shows in the battery details.

CAN is a broadcast thing, Modbus is 'ask for every register you want', but because that's inefficient due to the overhead of single-register queries, there's a ...read_registers command to read multiple registers at a time. However, various equipment can only return a limited number of registers at a time (40 for the inverters, 10 for the batteries), so I read all the 50 registers I need from the batteries 10 at a time.

SOC is register 21 in SECBP, and 24 in the normal protocol.

I may try to use a USB modbus adapter on my Linux laptop and do a modbus protcol sniff via wireshark to get a better understanding which communication is already going on between SA and the batteries.
So I may find out if the missing additional values like cycle count and different temperature probe values etc. are also already available in the modbus data (beside the SOC which I need to the DIY Chargeverter).

 

[wpns]

So I may find out if the missing additional values like cycle count and different temperature probe values etc. are also already available in the modbus data (beside the SOC which I need to the DIY Chargeverter).

Oh, they are definitely there, as per the document you uploaded. I'm plotting SOC, battery and cell voltages and deltas, current cycle counts, balancing stats, other stats (combined status, warning, error, protection, and I make time-lapse movies of the balancing functions.

 

[fmeili1]

Oh, they are definitely there, as per the document you uploaded. I'm plotting SOC, battery and cell voltages and deltas, current cycle counts, balancing stats, other stats (combined status, warning, error, protection, and I make time-lapse movies of the balancing functions.

I still struggle with the initial Modbus sniffing setup - maybe I need a short jump-start...

To do a first investigation (without ESP32 / ESPHome), I've ordered a simple USB-RS485 adapter and try to do a first address scan with my Linux laptop.
I've connected the A+ and B- with my two already existing passive RS485 HUBs where all the 12 EG4-LL (V2 and S) batteries are already connected in parallel and connected to SolarAssistant (open loop and the batteries are not inter-connected to each other, every battery has a separate RS485 cable to the HUB). The first battery starts with DIP switch ID 2 and up to ID 13 for the last (12th) battery to be able to communicate with SolarAssistant. Update: I've NOT connected the modbus ground!



I found this simple ModbusTools project on github to do the first tests. My Ubuntu found the USB stick on ttyUSB0 and I'm using the following settings - I hope they are correct:

• 9600 baud
• 8 data bits
• 1 stop bit
• no parity
• no flow control

I've done a scan with ID in the range from 2 to 13 and the tool is able to find the addresses . But 9 out of 10 attempts, the tool shows CRC errors for the first battery (modbus ID 2).

Is this normal or can I ignore this warning?
Wiring seems to be correct. When running these tests, there were no negative effects with my battery to SA communication which was working in parallel without issues - I think if something with the wiring was really bad it would have also influenced the SA/battery communication.

My other question is:
How can I signal the tool to passively read/sniff all the traffic of all modbus communication for all addresses (like promiscuous mode in Wireshark). Does this depends on the used tool or do I need to set my own address to a "special address" (e.g. to zero?) or how can I achieve a passive sniffing of all the modbus traffic between all other addresses?

 

[wpns]

I still struggle with the initial Modbus sniffing setup - maybe I need a short jump-start...

To do a first investigation (without ESP32 / ESPHome), I've ordered a simple USB-RS485 adapter and try to do a first address scan with my Linux laptop.
I've connected the A+ and B- with my two already existing passive RS485 HUBs where all the 12 EG4-LL (V2 and S) batteries are already connected in parallel and connected to SolarAssistant (open loop and the batteries are not inter-connected to each other, every battery has a separate RS485 cable to the HUB). The first battery starts with DIP switch ID 2 and up to ID 13 for the last (12th) battery to be able to communicate with SolarAssistant. Update: I've NOT connected the modbus ground!

I've had other RS485 interfaces give mixed results, so I've standardized on:

Amazon.com

Which in addition to being isolated (all of the RS485 ports have common ground, but they are isolated from the USB ground), has selectable terminations, which helps me figure out the signal integrity thing.

View attachment 284181 View attachment 284186

What RS485 adapter are you using for SA?

Why not connect the RS485 ground? RS485 has a limited common-mode range, and once you are outside that it's not going to work.

With that hub, where are the terminations? I mean it's probably OK with short wires and a star configuration but Modbus is supposed to be a bus with termination on both ends...

I found this simple ModbusTools project on github to do the first tests. My Ubuntu found the USB stick on ttyUSB0 and I'm using the following settings - I hope they are correct:

• 9600 baud
• 8 data bits
• 1 stop bit
• no parity
• no flow control

That looks right, but I've had to set the serial timeout to 10 seconds(!) because _sometimes_ the response time is up in the 8-second range. Not sure if that's something in the batteries or something in my hardware configuration, but it might be worth a try.

I've done a scan with ID in the range from 2 to 13 and the tool is able to find the addresses . But 9 out of 10 attempts, the tool shows CRC errors for the first battery (modbus ID 2).

Only the first battery? Feels like signal integrity, see bus/star topology and terminations above.

Is this normal or can I ignore this warning?
Wiring seems to be correct. When running these tests, there were no negative effects with my battery to SA communication which was working in parallel without issues - I think if something with the wiring was really bad it would have also influenced the SA/battery communication.

Just to be <ahem> detail oriented, you are disconnecting SA when using that tool above?

My other question is:
How can I signal the tool to passively read/sniff all the traffic of all modbus communication for all addresses (like promiscuous mode in Wireshark). Does this depends on the used tool or do I need to set my own address to a "special address" (e.g. to zero?) or how can I achieve a passive sniffing of all the modbus traffic between all other addresses?

That's one I still haven't figured out, you might have to get down in the weeds and talk to the hardware directly to make a 'promiscuous' mode (though Google doesn't match that term for modbus, maybe listen or sniff or ???). And it's going to be different with ESP32, so though it's more complex initially, maybe start there?

 

[Quattrohead]

It seems the two different RS 485 buses will run at different speeds so don't be shy to try out 19,200 and 57,600, those the most common ones I've seen alongside the 9600

 

[marionw]

All you need are the A+ and B-, no ground. I have 150ft of cat5 between my batteries and inverter and my computer. I use the brown/brown-white wires to monitor the inverter and the orange/orange-white to monitor the batteries.

Connect a second RS485 to USB in parallel to the one plugged into SA (A+ to A+ and B- to B-). With one converter plugged into SA and the other plugged into your computer you can use any serial port sniffing software to monitor the RS485 traffic. All commands sent by SA and all responses from the batteries will be available in the computer

 

[fmeili1]

I've had other RS485 interfaces give mixed results, so I've standardized on:

Amazon.com

Which in addition to being isolated (all of the RS485 ports have common ground, but they are isolated from the USB ground), has selectable terminations, which helps me figure out the signal integrity thing.

What RS485 adapter are you using for SA?

I'm using the one which SignatureSolar automatically put to the delivery when you order one or more EG4-LL batteries.

Why not connect the RS485 ground? RS485 has a limited common-mode range, and once you are outside that it's not going to work.

The original SignatureSolar RS485 battery communication adapter has just A+ and B- connected - there is no ground connector on this USB stick! Because of that, I've custom build all my RS485 cables with just A+ and B- (from all batteries to the RS485 HUBs and from the RS485 HUB to SA). This is working without issues since about 1 year now (the distance between the two battery racks is about 3 meters and from the closest RS485 HUB to SA is about 2 meters. I've placed one RS485 HUB in each battery rack and just connected both together.

With that hub, where are the terminations? I mean it's probably OK with short wires and a star configuration but Modbus is supposed to be a bus with termination on both ends...

I have no idea if an how these HUBs are terminated. It's a Growatt "RS485/CAN HUB" and the spec doesn't tell anything about termination. Also the EG4-LL-V2/S documents does not say anything about RS485 termination.

That looks right, but I've had to set the serial timeout to 10 seconds(!) because _sometimes_ the response time is up in the 8-second range. Not sure if that's something in the batteries or something in my hardware configuration, but it might be worth a try.

I'll try to increase the timeout and maybe the retry options.

Only the first battery? Feels like signal integrity, see bus/star topology and terminations above.

yes, only the 1st.

Just to be <ahem> detail oriented, you are disconnecting SA when using that tool above?

No, SA is still connected by intention! The final goal is to passively sniff/read the traffic between the batteries and SA with the ESP32 modbus controller (to sniff the SOC values which are already sent from the batteries to SA). Because of that, I left SA connected while doing my sniffing tests.

That's one I still haven't figured out, you might have to get down in the weeds and talk to the hardware directly to make a 'promiscuous' mode (though Google doesn't match that term for modbus, maybe listen or sniff or ???). And it's going to be different with ESP32, so though it's more complex initially, maybe start there?

I think I have to do more research and testing...

 

[fmeili1]

It seems the two different RS 485 buses will run at different speeds so don't be shy to try out 19,200 and 57,600, those the most common ones I've seen alongside the 9600

I'll try that!

 

[fmeili1]

All you need are the A+ and B-, no ground. I have 150ft of cat5 between my batteries and inverter and my computer. I use the brown/brown-white wires to monitor the inverter and the orange/orange-white to monitor the batteries.

good to know because all my custom made RJ45 cables (14 total - 12 from my batteries to the two RS485 HUBs, one to interconnect the two HUBs and one from a HUB to SA) are only using A+ and B- so far.

Connect a second RS485 to USB in parallel to the one plugged into SA (A+ to A+ and B- to B-). With one converter plugged into SA and the other plugged into your computer you can use any serial port sniffing software to monitor the RS485 traffic. All commands sent by SA and all responses from the batteries will be available in the computer

This is exactly what I've done (plugged a second RS485/USB in my Linux Laptop and connected it's A+ and B- to the same existing bus) to sniff the SA/battery traffic.
Which sniffing software are you using?

 

[wpns]

I have no idea if an how these HUBs are terminated. It's a Growatt "RS485/CAN HUB" and the spec doesn't tell anything about termination.

It's almost certainly a parallel connection of all 8 RJ45 pins across all the ports. They would not be terminated.

Also the EG4-LL-V2/S documents does not say anything about RS485 termination.

So there's no way to enable or disable the termination? Then there probably isn't any termination, and you should still have two terminations even in a star configuration.

No, SA is still connected by intention! The final goal is to passively sniff/read the traffic between the batteries and SA with the ESP32 modbus controller (to sniff the SOC values which are already sent from the batteries to SA). Because of that, I left SA connected while doing my sniffing tests.

Right, but when you are polling the batteries you are asking another bus master to transmit, which might cause collisions, depending on timing you have no control over. When you are polling the batteries and ensuring you can get data from them without CRC errors, disconnect SA. When you are sniffing the SA data, then you can connect the extra interface and just never transmit.

 

[fmeili1]

This picture makes to more clear how my current system is connected (open loop) with SA.
Goal is do a passive modbus/RS485 sniffing for the existing data flow on the wires showed in red color in the picture.



The only one port which was still left on my two RS485 HUBs is now connected to my USB/RS485 sniffer with my laptop.

 

[wpns]

This picture makes to more clear how my current system is connected (open loop) with SA.
Goal is do a passive modbus/RS485 sniffing for the existing data flow on the wires showed in red color in the picture.
View attachment 284370
- no interconnection between each batteries (Battery-Comm port are not used). The only used communication connector on the batteries
is the RS485 RJ45 connector!
- the word "master" for Batt 1 in the picture has no meaning because there is no closed loop communication and no battery interconnection
(it's just the first battery starting with ID 2)
- in the meantime I have updated to 12 batteries (the picture is not actual) and both racks are filled with 6 batteries each and the ID running
from #2 to #7 in Rack 1 and from #8 to #13 in Rack 2.

So there's only one RS485 port on each battery?

 

[fmeili1]

So there's only one RS485 port on each battery?

Yes!
And this is the same for the EG4-LL-V2 and also for the newer EG4-LL-S battery (I'm using both types).

It has one CAN port (3) but not used, one RS485 port (2) which I'm using and two Battery-Comm ports (10) to daisy chain all batteries which I'm not using.

I only connected the RS485 port on each battery in parallel (via RS485 HUBs) to SA and SA does correctly showing all individual battery data.

Update: This connection setup is described in the Solar Assistant documentation to connect EG4-LL batteries under the title "How to connect multiple EG4 GYLL batteries".

 

[fmeili1]

I've found some more useful information.

The currently used USB/RS485 stick which I would like to use just for testing with the PC has a fixed 120 Ohm terminating resistor included - I've opened the case and it's possible to de-solder this resistor. But after reading carefully the description of the RS485 sniffer project, I think it does not really help to sniff the traffic (even if it would fix the 120 Ohm termination problem which may help to get rid of the CRC error). It uses a SP485EEN chip for RS485 processing (not the very common MAX48X chip).

As far as I understand the documentation of this RS485 sniffer project, it's required to permanently activate the modbus receiver part (line receiver) of the modbus driver and to permanently de-activate the transmitter part (line driver) of the modbus tranceiver to implement a passive RS485 sniffing (like a promiscuous mode). All modbus testing applications I've tried so far with the PC are not able to explicitly enable only receiver and disable the transmitter. I don't know how to achieve this with this USB stick and the used modbus scanning applications I've tried (OpenModScan and ModbusTools).

The RS485 sniffer project mentiond this modbus tranceiver module which I've already have on hand and plan to use it in the final solution with my ESP32 controller. Luckily, this module uses the MAX48X chip which could be configured to always receive and never transmit (both RE/DE need to be tied to GND to achieve this - RE is inverted). Also the existing 120 Ohm resistor could be easily de-soldered.
The received data will be available on the RO pin (with TTL logic) of the modbus tranceiver module.

But I have no idea how to connect this RO pin to my Linux PC in a way that the common modbus analyzing software is able to use it (e.g. as a serial /ttyS0, /ttyS1 etc. in Linux. This is only for the test phase where I want to analyze and understand the EG4 battery protocol. For the final solution it's not required because the RO pin would just be connected to the ESP32 GPIO pin).

I think I can't use standard RS485 to RS232 converters because it would have the modbus tranceiver already included (but the the above module which I want to use already doing this). I don't know if it's possible to build just a connector which uses the RO and GND of this modules output (TTL level) and wire it to e.g. a D-SUB9 serial connector to make it accessible via a standard /tty in Linux to use it in the sniffer software.

Any ideas?

 

[wpns]

I've found some more useful information.

The currently used USB/RS485 stick View attachment 284615 which I would like to use just for testing with the PC has a fixed 120 Ohm terminating resistor included - I've opened the case and it's possible to de-solder this resistor. But after reading carefully the description of the RS485 sniffer project, I think it does not really help to sniff the traffic (even if it would fix the 120 Ohm termination problem which may help to get rid of the CRC error). It uses a SP485EEN chip for RS485 processing (not the very common MAX48X chip).

As far as I understand the documentation of this RS485 sniffer project, it's required to permanently activate the modbus receiver part (line receiver) of the modbus driver and to permanently de-activate the transmitter part (line driver) of the modbus tranceiver to implement a passive RS485 sniffing (like a promiscuous mode). All modbus testing applications I've tried so far with the PC are not able to explicitly enable only receiver and disable the transmitter. I don't know how to achieve this with this USB stick and the used modbus scanning applications I've tried (OpenModScan and ModbusTools).

The RS485 sniffer project mentiond this modbus tranceiver module View attachment 284620 which I've already have on hand and plan to use it in the final solution with my ESP32 controller. Luckily, this module uses the MAX48X chip which could be configured to always receive and never transmit (both RE/DE need to be tied to GND to achieve this - RE is inverted). Also the existing 120 Ohm resistor could be easily de-soldered.
The received data will be available on the RO pin (with TTL logic) of the modbus tranceiver module.

But I have no idea how to connect this RO pin to my Linux PC in a way that the common modbus analyzing software is able to use it (e.g. as a serial /ttyS0, /ttyS1 etc. in Linux. This is only for the test phase where I want to analyze and understand the EG4 battery protocol. For the final solution it's not required because the RO pin would just be connected to the ESP32 GPIO pin).

I think I can't use standard RS485 to RS232 converters because it would have the modbus tranceiver already included (but the the above module which I want to use already doing this). I don't know if it's possible to build just a connector which uses the RO and GND of this modules output (TTL level) and wire it to e.g. a D-SUB9 serial connector to make it accessible via a standard /tty in Linux to use it in the sniffer software.

Any ideas?

Well, you are ahead of me, thanks for the pointer to the RS485 Sniffer project, I'll take a look in my copious spare time.

Sounds like you are making some progress anyway!

I almost wonder if a MITM box with two RS485 transceivers wouldn't be easier to implement than trying to get the hardware to do something special and the Linux box to talk to that result...

 

[wpns]

Well, you are ahead of me, thanks for the pointer to the RS485 Sniffer project, I'll take a look in my copious spare time.

Sounds like you are making some progress anyway!

I almost wonder if a MITM box with two RS485 transceivers wouldn't be easier to implement than trying to get the hardware to do something special and the Linux box to talk to that result...

Hmm, maybe https://blog.davehylands.com/capturing-usb-serial-using-wireshark/ would have some hints?

 

[marionw]

The problem with "sniffing" (and I use the waveshare isolated RS485 to USB) is that many of the "responses" from the slaves do not include data that is required to properly decode the response that was "sniffed" (i.e. the command for specific data). Capturing the command send by the "Master" on the RS485 bus and then assuming the "response" on the RS485 bus is the result of the "command" can become problematic depending on how your "sniffing" software handles the "data received" stuff and is able to parse it. Timing is everything and while you are parsing something, other data on the bus has already been sent/received. If you are sniffing Modbus Ascii and know the SOI and EOI then you can more easily parse the data as you can "frame" it and then buffer it.

 

[fmeili1]

I almost wonder if a MITM box with two RS485 transceivers wouldn't be easier to implement than trying to get the hardware to do something special and the Linux box to talk to that result...

Instead of trying to sniff the traffic between SA and the batteries directly with a PC (just for testing and understanding the protocol), I think about using an ESP32 with this tranceiver module (like the final solution) to just sniff/capture the data and publish them via MQTT to my PC for later /offline analyzing.

 

[fmeili1]

The problem with "sniffing" (and I use the waveshare isolated RS485 to USB) is that many of the "responses" from the slaves do not include data that is required to properly decode the response that was "sniffed" (i.e. the command for specific data). Capturing the command send by the "Master" on the RS485 bus and then assuming the "response" on the RS485 bus is the result of the "command" can become problematic depending on how your "sniffing" software handles the "data received" stuff and is able to parse it. Timing is everything and while you are parsing something, other data on the bus has already been sent/received. If you are sniffing Modbus Ascii and know the SOI and EOI then you can more easily parse the data as you can "frame" it and then buffer it.

Sounds like it would be really problematic to do a passive sniffing (if no SOI and EOI) is implemented in the protocol. 12 batteries will produce a lot of traffic... I'll try to test it to get a better understanding and will provide feedback here.

 

[wpns]

Let us know, I'd think you could parse the queries to each of the batteries, as that'll be a known fixed-length command, and then see what bus traffic there is till the next one (and there should be a non-zero gap time, when I polled my batteries at 90Hz the inverters stopped responding, I imagine they either got some weird battery response or got no response from the batteries and didn't know how to handle the issue.