Pack2, Pack3, etc about pylontomqtt

[ellingo]

I just noticed by listing data coming from the ESP32 over the COM port that Pack Count is found to be 1.
When running the PbmsTools utility it says the Pack Qty is 1. It should be 2 and I can get data from both.

[ellingo]

Weirdly, it is working now, at least almost. I am not aware of having changed anything.
The only obvious error I can see is that the BarCode is the same in both packs when they are really not.

[tclausing]

I'm using ESP32 and I see only Pack1 too. PBMS Tools on 232 and Solar Assistant on 485 each recognize four packs.

I have the oldest jakiper model, non-pro, no official inverter communication support on 485 port. I'm curious whether that BMS communicates differently than newer ones leading to only Pack1 being recognized by this software.

I'd be happy to follow any debugging steps. I have no experience with ESP32 beyond flashing this software, so not sure how to view log output, ttl data, etc.

[ellingo]

I believe the pro and non-pro both use the same Pace P16S100A BMS. The pro may have newer firmware though.
Very early, the code asks the rack for the number of packs and I believe it lists the result to the USB port (if you have a terminal emulator connected). All packs must, of course, be turned on before that.

[tclausing]

All packs are on and recognized by Solar Assistant and PBMS tools. I noticed when SA detects the packs it says "Pack address 1" for each discovered pack, instead of address 1, 2, 3, 4 as selected by the dip switches on the packs. That could be a coincidence but could also be related to why GetPackCount returns 1. I wonder if SA and PBMS are just testing every pack address rather than trusting the reported pack count. Though not sure how they'd query an individual pack if all are at address 1. Maybe I should try hardcoding pack count to 4 and re-flashing....if I can figure out how to do that.

[ellingo]

In my experience, the pack addresses has to be set correctly - 1, 2, 3, 4. Also, I had to connect to the serial port on pack 1, otherwise I would only see the pack I was connected to. I just ignore the displayed pack addresses in PBMS.
I do not know if pack 1 already knows the number of packs in the rack or if they must be counted by accessing packs one by one.
I can check the code, but I switched to using the Raspberry Pi version, so that's the one I "trust". At times it detected one pack too many, but I was never able to figure out that one.

[tclausing]

I tried hard coding pack count to 4 and re-flashing, but that caused a timeout and reset when pack 2 fails to read. I tried PBMS again and noticed that pack count is always 1, and no matter which pack I select to connect to, the address always shows 1 (or whatever the address of the first pack is). Further I confirmed that PBMS cannot read packs 2+ unless the dip switches are all set correctly in ascending order. So I think this eliminates things I may be doing wrong and seems like my pack firmware is behaving differently than this software is written for. At this point it looks like I would need to capture and compare the data between PBMS and the packs to see how it's specifying the pack number to query data from. Next google search, com port multiplexer...

[ellingo]

Yes, the PBMS interface is confusing regarding pack count and address. It still is with Jakiper pro batteries.
Good luck with your experiments!

[tclausing]

Findings...my firmware does respect pack addresses over RS485 but not RS232. But it doesn't respond to GetPackCount over 485, so I had to hardcode that, TODO to make it configurable through the config page. I also had to make changes to make the software play nice on a shared 485 bus (shared with Solar Assistant) basically decouple the 1:1 receiving and sending of messages. Another TODO is to make the received message type detection better, it's currently hardcoded based on the message lengths that my packs happen to send. These changes are on my fork if anyone's interested.