Gary Waterworth

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 )

Definately looking a lot better after I put the changes in

 

Not a safe assumption. Do you not have access to some tool that gives you a graph like this one from my system? 

They are not all exactly like this, but something similar. You can see it tracing load (yellow line), power in or out of battery (purple) and battery's state of charge (green).

The left of the graph is midnight. The house is running off of the battery. A quick check shows a low of 110W, a high of about 350. This is the house ticking over at night. WIFI, outside lights, fridges, stuff on stand by, security system. 

Anyway, my point is that the load is not constant at night. Mine doesn't fluctuate a lot, but it is not constant.
 
OK... your battery has a capacity of 5.12 kWh (per the link you shared). 204 W per hour (assuming that is the average load) gives 1.02 kWh in 5 hours. So you should be losing about 20% every 5 hours - simple arithmetic. 4% an hour IF the average load is 204W, but we can't be sure of that. I lost about 7% over 4 hours, but my battery is double yours. So I can back calculate to an average of 175W.

Now your tale above shows a 62% lost over... it's not clear what period of time. We know that the battery was at 79% when charging stopped because the grid went down. But even if we assume 79% at 02:00 then you were discharging at 20% an HOUR (02:00 to 05:00) to get to 17% by 5:00, five times the rate if the average was 204W.

So something has to give. Either you are using a lot more than you know/expect at night, or some part of your system is not in good shape.

NB! The inverter itself will account for some of the load. Converting 50V DC to 230V AC is not a 100% efficient matter, and also the inverter is going to use some electricity just to keep itself up and running.

So we need to understand what the loads truly are. Either you can work a night shift monitoring the system and capturing numbers into a spreadsheet, or you need a tool like the one I show. Between you and the installer, one of you should have access to that data. Check that. If you see much higher loads than you expected then you can investigate.

Get that data. See what loads are active during the night, then you can make better judgements and decisions.

Ask the installer how possible it is that the geyser is getting power from the battery.
 

I think it is bad web requests 😕
I have added a request timeout . Changes are in the development branch atm
Existing checks are picking up the aborted request now and not exporting data after it.
 
There also may be a different problem here which is to do with templates and chaining.
I may have to work with the updates so that the flows update directly instead of this (example) :-
  - sensor:
      - name: "Sunsynk PV1 Voltage 109"
        state: >
          {{state_attr('sensor.sunsynk_usable_pv', '1_volt')|float(0)|round(1)}}
 
 

Put a whole lot more error checking in to try stop bad data being exported
Also implemented filter sensors to try stop the 0 data problem on instance reboots/reloads.
Currently changes are in the development branch. Will push to stable branch when I am happy on the results

Actually very straight forward , based on javascript,  I have a far more complicated automation flow
1 problem I see
It only triggers once at 1am. Mine triggers a check every 10 minutes. So if an update doesnt go through it will be rerequested.