Gary Waterworth

Remember when these were bought a few years ago they were bought with 10year warranties.
The bms was supposed to manage the events you are talking about. Blaming the customer for a junk bms by saying you have a few high voltage charges is bs
I had 3 us3000. After 4 years they swelled. I had warranty rejected because of high voltage events 3 years prior.
I will never touch the brand again and will point the middle finger at them every chance I get. Crap brand

Installer sourced from Segen
Donated them to someone else who was looking for BMS controllers
Batteries were 4 years old running on a Sunynk 8K. Settings were to 40% floor normal usage with a hard floor of 20%. So no they were not abused.
Batteries had been bought with 10 year warranty registered
Still interested to see if Solar Deity PTY LTD is going to be honoring all the batteries bought over the last 10 years that were registered with 10 year warranties as an official distributer and repair center.

Remember when these were bought a few years ago they were bought with 10year warranties.
The bms was supposed to manage the events you are talking about. Blaming the customer for a junk bms by saying you have a few high voltage charges is bs
I had 3 us3000. After 4 years they swelled. I had warranty rejected because of high voltage events 3 years prior.
I will never touch the brand again and will point the middle finger at them every chance I get. Crap brand

Sorry after the run around when I had swollen US3000's and being told I overcharged , when there is supposed to be a bms to prevent this
Will never touch the brand again

Sorry after the run around when I had swollen US3000's and being told I overcharged , when there is supposed to be a bms to prevent this
Will never touch the brand again

I have been working on the next iteration of Solar Monitoring
High level it will Consist of the following addons:
Scraper that gets the solar information and populates it in MQQT
I have allready completed a bare bones of this one running under : https://github.com/gdwaterworth/sunsynkmqqt
I forked SunsynkV3 and changed it 90% to do what I want
Only prerequisite is the MQQT addon


Processor which then take the MQQT data and creates topics in MQQT that will then be processed as MQQT discovery and create entities in Home Assistant
TBD
A MQQT listener that will look at changes coming from topics in HA and then set those topics back on the inverter
TBD
I have chosen this route to be modular so in the future I can add in modules that talk to various inverters and you just implement the modules needed.

Can u pm it to me again ?
or send to my email : [email protected]

I have been working on the next iteration of Solar Monitoring
High level it will Consist of the following addons:
Scraper that gets the solar information and populates it in MQQT
I have allready completed a bare bones of this one running under : https://github.com/gdwaterworth/sunsynkmqqt
I forked SunsynkV3 and changed it 90% to do what I want
Only prerequisite is the MQQT addon


Processor which then take the MQQT data and creates topics in MQQT that will then be processed as MQQT discovery and create entities in Home Assistant
TBD
A MQQT listener that will look at changes coming from topics in HA and then set those topics back on the inverter
TBD
I have chosen this route to be modular so in the future I can add in modules that talk to various inverters and you just implement the modules needed.

I really dont mind if you fork it :)
I just dont have time atm with my other activies to really work on it

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

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

No ..
 
Your internal consumption is actually 571 + 20 - ( 252 + 265 ) = 74W , which is roughly the same as the average on the Sunsynk
You have load on UPS as well as essential. Internal sunsynk power usage is not shown as load from what I know

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

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

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

Set the lines of code relating to battery in the export data to be ignored and all other useful numbers are coming across to HA. Quick fix while I go and order my battery…
Thanks again

100% @Gary Waterworth only makes sense at the coast. With the cost of solar panels and batteries dropping constantly and wind turbines not getting any cheaper, it means that the financial argument for using wind becomes weaker all the time.
I think that we are going to see lithium batteries in SA being sold in the R1k/kwh range within the next two years (unless the rand goes down the toiled!) 
 

FYI and someone else reference
If you use this tester

There is a function that it will test and show you in which direction there is current draw to ground
Using that you can walk the fence and then find the location where current is being drawn to ground
 

 
The arrow will point to the direction of current draw. Walk the fence and wait till teh direction changes
Far easier and more exact way to faultfind
 

FYI and someone else reference
If you use this tester

There is a function that it will test and show you in which direction there is current draw to ground
Using that you can walk the fence and then find the location where current is being drawn to ground
 

 
The arrow will point to the direction of current draw. Walk the fence and wait till teh direction changes
Far easier and more exact way to faultfind
 

The error is a SSL cert that cannot be checked . This is their api website. 
You could change the https to http ( so there are no certs ) , but couldnt be bothered to be honest unless they really mess up on that front . Not sure if their api support plain http

The problem is not whether there is a data value or not ( available/unavailable ) the problem is when a data value of 0 is returned by Sunsynk. That is why I use teh forever totals and not the today totals in the energy graphs. The today totals never seem to reset at the same time and if I use teh forever totals then it is easy as they can never be 0 and also teh energy graphs will "catch up" when there is an outage
 
There is probably a use case for it in some of teh other values, but will see when I have time. 

No need . They fixed their f.... up

Same one as before total_export. Did it that way so you didnt lose history 
 
pre -> filtered -> total_export

Will look at this later. 
 
On teh other topic I will have a look at teh code to force offline the online indicater if teh logger hasnt been updated in the last x minutes
Just busy with work stuff , so may take a few days

Version 2.x was a complete rewrite and methology change as V1 had severe limitations due to the logic flow framework used.
The video was created by someone else and quite frankly I don't have the correct software or time to do a new one. 
The short guide is available on : https://github.com/gdwaterworth/Home-Assistant---E-Linter-Logger---Sunsynk/wiki
It does not make sense for me to try work remotely on someone else's system as you are not setup for me to look at the real data coming in and to set you up for that is time consuming.
My solution is a 2 pv string , so there may be something incorrect with the code for pv3/4. The only way i can check that is if someone "lends" me their login details or share their plant to [email protected]
That way I can setup my test environment and check with those details.
I know I did put in some fixes for pv3/4, and again this morning but again I cant test them.

Utility use, we would have to look at as I am not sure where it is shown or even if it is shown on sunsynk.net, but again I cannot use my system to check as I dont use that or aux power.
People must remember this is not a paid product and I am doing this free and gratis, so it get looked at when I have spare time and it takes LOTS of time. Sometimes it may go for 2 or 3 weeks where I dont look at it.
Sunsynk recently has been particularly painful with their changes to Region 2 and they are still having fairly major teething problems.
There is no API manual from sunsynk ( that is anywhere near up to date and that what is available is wrong/incomplete in a lot of places), so everything is reverse engineered and that takes time. 
ATM my focus is adding in some of the extra settings to be changable , but having some issues around it. Also being focused on is the bad data coming from Sunsynk and their API response time challenges  although the current fixes appear to be handling that correctly ( if not very smartly )