-cK-

Thanks @-cK- , the updated download open successfully. Will connect to my bank to check functionality.

You will need to determine what BMS the batteries are using and then look into a third party option to access that BMS data.
EG. My batteries uses the Pace BMS and I have an addon in Home Assistant that can pull the Pace BMS data from the batteries using an ESP32 bridge to the master battery's RS232 port.

@Skyden if you want to you can check the previous page for what I've done, not sure if this will work for you as I just added a separate card for my batteries below slipx's card.
https://powerforum.co.za/topic/17970-home-assistant-sunsynk-power-flow-card-and-dashboard/page/23/#findComment-221673
https://powerforum.co.za/topic/17970-home-assistant-sunsynk-power-flow-card-and-dashboard/page/23/#findComment-221786

@Bobster. Yes Tuya still needs to go through the cloud, there was a tuya local integration but seeing how my setup has my IOT on a VLAN and my HA on my main network and due to initial configurations with the solar setup and the fact I never could get the main network to bridge to the vlan without breaking my whole network setup all my IOT must go through cloud at this point so I never fiddled with that and I think it might no longer be working as it is unmaintained it think but don't quote me on that.
So initial pairing is still via the app for which ever route you go but once pulled into HA everything else is done from HA on my setup.
@Denns The lag is only present on HA as far as I recall the app itself works fine.
Where this became a deal breaker for me was with my cascade shutdown rules as everything on my home is on the 5kW inverter and if the Geyser, stove, 2x AC's and microwave is all on at the same time this can trip the inverter and if that load persist beyond the 10s buffer of the inverter has for spikes like this it becomes important to not have 5-10s delays in power readings. With my sonoff's I get near instant power readings when turning on the device with live reading updates where tuya seems to be on 5s+ refresh updates. As I knew I was going the HA route this was an important factor to consider given the scope of my setup with about 55 sonoff's deployed at this point in time.

@Sc00bs Cool, yea just had a chat with my neighbor after he got his batteries back earlier this week and the answer he got from hubble when he ask them spesifically about using those ports on their batteries to get data to HA is a solid Nope. Utter BS imo but yea what can one do if you don't want to risk voiding a warranty, so getting the data from the canbus will be awesome.
Eagerly awaiting that update and video.

I have access to my sunsynk account. Will be enough to check logins etc.
Just a matter of finding time to find a way to do the same in node red.
Main problem is trying to fnd equiv functions in node-red

PROBLEM SOLVED!
I am actually a little embarrased as I should have checked his settings before posting - nevertheless the point here is never assume that your installer setup your installation correctly :-(
In essence, everyone was correct - the dip switch settings on 2 batteries were wrong as well as the communication cables were not in the correct ports - thanks @-cK- and @I84RiS - your posts made me double check my friends settings and we found it.
Herewith the correct settings / cable ports (he has a 12kwh Deye Inverter with 3 x Hubble AM-5 batteries).
The Picture of the Li-BMS now shows the 300A that was missing previously :-)

Perhaps just to add to that 7 panels per string, that would be 7 panels in series.
The way I remember it
Series = Volts get added together amps stay the same
Parallel = amps get added together volts stay the same
Only when you really want to mix and match odd sizing panels will you play with series and parallel connections between panel to get the max performance out of the mix set to best match the MPPT spec. Hence normally it is just easier to stick with same size panels per string as far as possible.

Are the comms cable between the batteries connected and are the dip switches set correctly will be my first check.
I don't have a Deye but a Sunsynk and on that last screen it looks to me it is only seeing 1 battery. I'm pretty sure those current limit should be showing 240A at least for 3 batteries. When I was on 3 batteries (different battery make) I had those showing as 240A on charge and discharge and when the comms cables was pulled during some testing those would drop down accordingly.
Perhaps worth a double check to make sure.

Thanks cK
Just reverted mine back as well and it looks like its working fine. I was a bit apprehensive about doing that in case it broke something else
🤦‍♂️. FYI I am on 2025.8 and it seems to be working fine.
Thanks again 👍

This is in my sensors.yaml file but I'm using the Open-Meteo Solar Forecast integration. If you are using Solcast the change required is in the last post https://github.com/dbuezas/lovelace-plotly-graph-card/discussions/422
Remember to update your sensors

- platform: template sensors: energy_production_today_sum: friendly_name: "Energy Production Today Sum" unit_of_measurement: "kWh" device_class: energy value_template: >- {% set sensor1 = states('sensor.energy_production_today_2') |float %} {% set sensor2 = states('sensor.energy_production_today_3') |float %} {% set total_watts = sensor1 + sensor2 %} {{ total_watts }} attribute_templates: watts: >- {% set sensor1 = state_attr('sensor.energy_production_today_2', 'watts') %} {% set sensor2 = state_attr('sensor.energy_production_today_3', 'watts') %} {% set ns = namespace(output={}) %} {% for time, value in sensor1.items() %} {% if time in sensor2 %} {% set sum_value = value + sensor2[time] %} {% else %} {% set sum_value = value %} {% endif %} {% set ns.output = dict(ns.output, **{time: sum_value}) %} {% endfor %} {% for time, value in sensor2.items() %} {% if time not in sensor1 %} {% set ns.output = dict(ns.output, **{time: value}) %} {% endif %} {% endfor %} {{ ns.output }} wh_period: >- {% set sensor1 = state_attr('sensor.energy_production_today_2', 'wh_period') %} {% set sensor2 = state_attr('sensor.energy_production_today_3', 'wh_period') %} {% set ns = namespace(output={}) %} {% for time, value in sensor1.items() %} {% if time in sensor2 %} {% set sum_value = value + sensor2[time] %} {% else %} {% set sum_value = value %} {% endif %} {% set ns.output = dict(ns.output, **{time: sum_value}) %} {% endfor %} {% for time, value in sensor2.items() %} {% if time not in sensor1 %} {% set ns.output = dict(ns.output, **{time: value}) %} {% endif %} {% endfor %} {{ ns.output }} energy_production_tomorrow_sum: friendly_name: "Energy Production Tomorrow Sum" unit_of_measurement: "kWh" device_class: energy value_template: >- {% set sensor1 = states('sensor.energy_production_tomorrow_2') |float %} {% set sensor2 = states('sensor.energy_production_tomorrow_3') |float %} {% set total_watts = sensor1 + sensor2 %} {{ total_watts }} attribute_templates: watts: >- {% set sensor1 = state_attr('sensor.energy_production_tomorrow_2', 'watts') %} {% set sensor2 = state_attr('sensor.energy_production_tomorrow_3', 'watts') %} {% set ns = namespace(output={}) %} {% for time, value in sensor1.items() %} {% if time in sensor2 %} {% set sum_value = value + sensor2[time] %} {% else %} {% set sum_value = value %} {% endif %} {% set ns.output = dict(ns.output, **{time: sum_value}) %} {% endfor %} {% for time, value in sensor2.items() %} {% if time not in sensor1 %} {% set ns.output = dict(ns.output, **{time: value}) %} {% endif %} {% endfor %} {{ ns.output }} wh_period: >- {% set sensor1 = state_attr('sensor.energy_production_tomorrow_2', 'wh_period') %} {% set sensor2 = state_attr('sensor.energy_production_tomorrow_3', 'wh_period') %} {% set ns = namespace(output={}) %} {% for time, value in sensor1.items() %} {% if time in sensor2 %} {% set sum_value = value + sensor2[time] %} {% else %} {% set sum_value = value %} {% endif %} {% set ns.output = dict(ns.output, **{time: sum_value}) %} {% endfor %} {% for time, value in sensor2.items() %} {% if time not in sensor1 %} {% set ns.output = dict(ns.output, **{time: value}) %} {% endif %} {% endfor %} {{ ns.output }} energy_production_d2_sum: friendly_name: "Energy Production D2 Sum" unit_of_measurement: "kWh" device_class: energy value_template: >- {% set sensor1 = states('sensor.energy_production_d2') |float %} {% set sensor2 = states('sensor.energy_production_d2_2') |float %} {% set total_watts = sensor1 + sensor2 %} {{ total_watts }} attribute_templates: watts: >- {% set sensor1 = state_attr('sensor.energy_production_d2', 'watts') %} {% set sensor2 = state_attr('sensor.energy_production_d2_2', 'watts') %} {% set ns = namespace(output={}) %} {% for time, value in sensor1.items() %} {% if time in sensor2 %} {% set sum_value = value + sensor2[time] %} {% else %} {% set sum_value = value %} {% endif %} {% set ns.output = dict(ns.output, **{time: sum_value}) %} {% endfor %} {% for time, value in sensor2.items() %} {% if time not in sensor1 %} {% set ns.output = dict(ns.output, **{time: value}) %} {% endif %} {% endfor %} {{ ns.output }} wh_period: >- {% set sensor1 = state_attr('sensor.energy_production_d2', 'wh_period') %} {% set sensor2 = state_attr('sensor.energy_production_d2_2', 'wh_period') %} {% set ns = namespace(output={}) %} {% for time, value in sensor1.items() %} {% if time in sensor2 %} {% set sum_value = value + sensor2[time] %} {% else %} {% set sum_value = value %} {% endif %} {% set ns.output = dict(ns.output, **{time: sum_value}) %} {% endfor %} {% for time, value in sensor2.items() %} {% if time not in sensor1 %} {% set ns.output = dict(ns.output, **{time: value}) %} {% endif %} {% endfor %} {{ ns.output }}

I've made a small tweak to my markdown card with regard to the information it displays.
I've added in a check to indicated if the SOH of the battery drops below 100% to display a warning, see below:

This is the updated markdown section if anyone want to incorporate that as well.
IndBattMarkdownv2.yaml

Sure thing.
I'm using a Grid-layout Dashboard:

My layout config is as follow, adjust to fit your needs:
grid-template-columns: 35% 35% 10% 10% 10% grid-template-rows: auto grid-template-areas: | "flow flow flow2 flow2 flow2" "batt1 batt2 acc acc acc" justify-items: stretch mediaquery: "(max-width: 800px)": grid-template-columns: 100% grid-template-areas: | "flow" "batt1" "batt2" "flow2" "acc"Here is one of the pairs of yaml.
IndBatts.yaml
Just adjust your parameters to your battery specs.
There is also 2 monitors related to the Temp section. One for min and max with 🌡️ icon and one for when there is a big deviation on the temp sensors ⚠️icon. Adjust or remove as you see fit.
Note I've set them up in a pair configuration so that when viewed on my phone I have pair showing in one row, you can split it off as 4 indivuals if you want but this is how I have mine setup.

I've made a small tweak to my markdown card with regard to the information it displays.
I've added in a check to indicated if the SOH of the battery drops below 100% to display a warning, see below:

This is the updated markdown section if anyone want to incorporate that as well.
IndBattMarkdownv2.yaml

@slipx I've seen this request on your github and here for more batteries in the card (3, 4 and 5 etc).
Seeing as this card is severely space limited with all the info and options already added in, the only option I see for more batteries in the card self beyond the 2 battery option currently, is when running it in full mode and on a wide panel setup. Just trying to think about how you would incorporate that to the card makes my brain hurt. So what I've done is add my batteries using standard grid layout cards and markdown cards below this one to get what I want on my one dashboard.
It is still WIP but perhaps the easiest solution to all those request for additional batteries would be to make an independent card for just batteries or enable an option that the card can be setup for just displaying the battery section that can then be stacked up or something 🤷‍♂️.
This option using markdown cards however is very flexible and customizable to setup your own info and monitoring.

@slipx I've seen this request on your github and here for more batteries in the card (3, 4 and 5 etc).
Seeing as this card is severely space limited with all the info and options already added in, the only option I see for more batteries in the card self beyond the 2 battery option currently, is when running it in full mode and on a wide panel setup. Just trying to think about how you would incorporate that to the card makes my brain hurt. So what I've done is add my batteries using standard grid layout cards and markdown cards below this one to get what I want on my one dashboard.
It is still WIP but perhaps the easiest solution to all those request for additional batteries would be to make an independent card for just batteries or enable an option that the card can be setup for just displaying the battery section that can then be stacked up or something 🤷‍♂️.
This option using markdown cards however is very flexible and customizable to setup your own info and monitoring.

@slipx I've seen this request on your github and here for more batteries in the card (3, 4 and 5 etc).
Seeing as this card is severely space limited with all the info and options already added in, the only option I see for more batteries in the card self beyond the 2 battery option currently, is when running it in full mode and on a wide panel setup. Just trying to think about how you would incorporate that to the card makes my brain hurt. So what I've done is add my batteries using standard grid layout cards and markdown cards below this one to get what I want on my one dashboard.
It is still WIP but perhaps the easiest solution to all those request for additional batteries would be to make an independent card for just batteries or enable an option that the card can be setup for just displaying the battery section that can then be stacked up or something 🤷‍♂️.
This option using markdown cards however is very flexible and customizable to setup your own info and monitoring.

I set my Sunsynk inverter to discharge down to 20% during the evenings however I did not know nor was I informed before hand the SOC you get on the inverter is only the avg SOC accross my batteries. You would expect the BMS to keep the battery levels in check accross all 4 but that is not the case it would seem. With it being winter I don't always get to 100% each day to "sync up" the SOC's accross the batteries, so every day you only partially charge and discharge the variance between the batteries gets bigger and bigger.
One would expect that if the inverter is set to 20% the BMS would prevent the individual batteries going below 20% but that was not the case and it would run things down until the avg SOC reach 20% irrespective if one or more of your batteries are already below 20%. So without knowing it 2 of my batteries was running down to the point the the batteries BMS would actually put the battery in a protected shutdown state on while I thought everything was cool as the inverter showed I was above 20% things was far from it. I only noticed it when I saw my SOC graph the one day drop from 20 to 18 instantly. Needless to say cells got damaged and is being replaced hence the 2 offline batteries.
Below you will see the massive gaps between the 4 SOC's that would creep in after 2 or more days not charging up to 100%. This would register as 36% on the inverter.

See how the SOC starts to deviate between the 4 batteries (this was after the damage was done but this shows what I'm looking for and monitoring now).

I have an automation set to adjust my SOC on my Slot 1 to match the avg SOC as soon any one of the batteries reach 20% or any one of the 64 cells reach 3volts or if any battery reaches 49V.
And if the variance between the max SOC and Min SOC is more than 10% it would set slot 5 to 100% and enable grid charge to force a top up of the batteries now.
A bit overkill but once bitten, twice shy.
Never let things go this far:

I set my Sunsynk inverter to discharge down to 20% during the evenings however I did not know nor was I informed before hand the SOC you get on the inverter is only the avg SOC accross my batteries. You would expect the BMS to keep the battery levels in check accross all 4 but that is not the case it would seem. With it being winter I don't always get to 100% each day to "sync up" the SOC's accross the batteries, so every day you only partially charge and discharge the variance between the batteries gets bigger and bigger.
One would expect that if the inverter is set to 20% the BMS would prevent the individual batteries going below 20% but that was not the case and it would run things down until the avg SOC reach 20% irrespective if one or more of your batteries are already below 20%. So without knowing it 2 of my batteries was running down to the point the the batteries BMS would actually put the battery in a protected shutdown state on while I thought everything was cool as the inverter showed I was above 20% things was far from it. I only noticed it when I saw my SOC graph the one day drop from 20 to 18 instantly. Needless to say cells got damaged and is being replaced hence the 2 offline batteries.
Below you will see the massive gaps between the 4 SOC's that would creep in after 2 or more days not charging up to 100%. This would register as 36% on the inverter.

See how the SOC starts to deviate between the 4 batteries (this was after the damage was done but this shows what I'm looking for and monitoring now).

I have an automation set to adjust my SOC on my Slot 1 to match the avg SOC as soon any one of the batteries reach 20% or any one of the 64 cells reach 3volts or if any battery reaches 49V.
And if the variance between the max SOC and Min SOC is more than 10% it would set slot 5 to 100% and enable grid charge to force a top up of the batteries now.
A bit overkill but once bitten, twice shy.
Never let things go this far:

Been updating my one dashboard as well that is used on my tablet to get a quick overall view of the most important info. Added the individual battery info because of an issue I ran into requiring me to get 2 batteries warranty repaired. This way I get a visual indication in conjunction with my new rules I put in place to prevent a similar occurrence from happening again.

This what I can comment on if that helps.

Do they replace/repair the battery;
According to the warranty terms it is at their discretion whether to repair or replace. Thus far they have opted to repair my batteries each time I had an issue.

What's their time frame if repairing;
When I spoke to the tech the other day the turn around can be from 1 week to 3 weeks depending on what they need to do.
E.G.
Re-balance of cells was said should be about a week
The rebuild and replacement of bad cells about 3 weeks

Warranty - from real world experiences
So far both instances I had was covered under warranty.
1st was a temp sensor that was faulty, battery was send in and sensor was replaced. (3 weeks as this was during all of the public holidays during Easter so this caused some external delays)
Currently have 2 batteries send back for repairs after the tech came out to the site and pulled the logs to make sure what happened to the batteries.

After-sales support (in person and online) - for firmware updates if need be
This will depend on your installer I think, had to get a firmware update a while back and this was done by my installer with them remotely logging in to the setup via the installers laptop.
I've dealt directly with some of the technician as well and they had no problem with me contacting them directly as my installer actually directed me to speak to them directly regarding my more technical questions I had at that time that my installer could not answer.

Ability to have battery communicate with a desktop or laptop using the CAN/RS485/RS232 port independent of the inverter for accurate readings
The R100 I have uses the Pace BMS so I'm reading my battery info via Home Assistant and a RS232 and ESP32 link for individual battery monitoring.

How long the company has been operating for and hope they keep going for a long time
No idea but my installer has been operating for 10 years and said during his time dealing with them they have not had any issue with warranties.

This what I can comment on if that helps.

Do they replace/repair the battery;
According to the warranty terms it is at their discretion whether to repair or replace. Thus far they have opted to repair my batteries each time I had an issue.

What's their time frame if repairing;
When I spoke to the tech the other day the turn around can be from 1 week to 3 weeks depending on what they need to do.
E.G.
Re-balance of cells was said should be about a week
The rebuild and replacement of bad cells about 3 weeks

Warranty - from real world experiences
So far both instances I had was covered under warranty.
1st was a temp sensor that was faulty, battery was send in and sensor was replaced. (3 weeks as this was during all of the public holidays during Easter so this caused some external delays)
Currently have 2 batteries send back for repairs after the tech came out to the site and pulled the logs to make sure what happened to the batteries.

After-sales support (in person and online) - for firmware updates if need be
This will depend on your installer I think, had to get a firmware update a while back and this was done by my installer with them remotely logging in to the setup via the installers laptop.
I've dealt directly with some of the technician as well and they had no problem with me contacting them directly as my installer actually directed me to speak to them directly regarding my more technical questions I had at that time that my installer could not answer.

Ability to have battery communicate with a desktop or laptop using the CAN/RS485/RS232 port independent of the inverter for accurate readings
The R100 I have uses the Pace BMS so I'm reading my battery info via Home Assistant and a RS232 and ESP32 link for individual battery monitoring.

How long the company has been operating for and hope they keep going for a long time
No idea but my installer has been operating for 10 years and said during his time dealing with them they have not had any issue with warranties.

I would second the HA + Kellerza method. Near instant readings and if you can depending on your batteries pull those in as well to HA from its BMS system.
You will be able to monitor much more in detail and setup so many custom notifications. It is a bit of work but worth the time and effort.

And yes I'm aware to the 2 issues on my batteries and waiting on the manufacture/installer regarding repairs/warranty.

I would second the HA + Kellerza method. Near instant readings and if you can depending on your batteries pull those in as well to HA from its BMS system.
You will be able to monitor much more in detail and setup so many custom notifications. It is a bit of work but worth the time and effort.

And yes I'm aware to the 2 issues on my batteries and waiting on the manufacture/installer regarding repairs/warranty.

ok got mine working . Looks like changes on gzip and some header stuff as well
In this


Change the variable headers_with_bearer to ( I changed encoding - removed gzip , referrer and origin )

    var headers_with_bearer = {
        "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:124.0) Gecko/20100101 Firefox/124.0",
        "Accept": "application/json",
        "Accept-Language": "en-US, en; q=0.5",
        "Accept-Encoding": "deflate",
        "Content-Type": "application/json;charset=UTF-8",
        "Authorization": "Bearer " + global.get("SS.Bearer"),
        "Origin": "https://api.sunsynk.net",
        "Connection": "keep-alive",
        "Referer": "https://api.sunsynk.net/",
        "Sec-Fetch-Dest": "empty",
        "Sec-Fetch-Mode": "cors",
        "Sec-Fetch-Site": "same-site",
        "TE": "trailers"
    }

I may need to make changes on the setting one , but will try work that out later
Will update the git repo when I get some time