Spelling for settings values

[Gr3mlin13]

Hi,

Thanks for the great work so far, got me going on setting up my inverter with Home Assistant. I noticed a bug that would make the setting of charging times on and off very inconsistent. The spelling when setting the values matters, in Postman I teste that "time1On" would work, but "time1on" would not for example. I have it consistently setting zones to charge from grid when loadshedding is two hours away, and just using solar when no loadshedding is expected after changing the spelling.

I am happy to share the changes I made back if that would help you. It is working fine for now, but will be dissecting it a bit further once I have the time. happy to conbtribute the learnings back if you need, otherwise I will just fork and make my changes there.

Thanks,

[gdwaterworth]

Need to understand what you are changing. Yes case matters when sending the update to sunsynk. Are you using the input boolean fields that were created for end user use ?

I dont recall time1On ( Capital O) being used anywhere . The sunsynk website doesnt accept that either and the examples I have from submitting to them allways showed a small o

There is a caveat when setting timeXon and genTimeXon . Both have to be submitted in the same request or it will not be accepted. But the node red flows cater for this.

If there is a real problem I will go recheck their api

A json extract from a submission to them

// msg.payload = "{sn:xxx,"safetyType":"2","battMode":"-1","solarSell":"0","pvMaxLimit":"8000","energyMode":"1","peakAndVallery":"0","sysWorkMode":"1","sellTime1":"00:00","sellTime2":"04:00","sellTime3":"09:00","sellTime4":"15:00","sellTime5":"22:00","sellTime6":"23:00","sellTime1Pac":"8000","sellTime2Pac":"8000","sellTime3Pac":"8000","sellTime4Pac":"8000","sellTime5Pac":"8000","sellTime6Pac":"8000","cap1":"50","cap2":"40","cap3":"30","cap4":"90","cap5":"70","cap6":"60","sellTime1Volt":"49","sellTime2Volt":"49","sellTime3Volt":"49","sellTime4Volt":"49","sellTime5Volt":"49","sellTime6Volt":"49","zeroExportPower":"20","solarMaxSellPower":"9000","mondayOn":true,"tuesdayOn":true,"wednesdayOn":true,"thursdayOn":true,"fridayOn":true,"saturdayOn":true,"sundayOn":true,"time1on":true,"time2on":true,"time3on":true,"time4on":true,"time5on":true,"time6on":true,"genTime1on":true,"genTime2on":true,"genTime3on":true,"genTime4on":true,"genTime5on":true,"genTime6on":true}"

[Gr3mlin13]

Okay, to be more specific. In your NodeRed flows you use "timeXon", with a lowercase. This is consistent with the payload recieved from them when calling settings read.

However, this was not giving me consistent results, so I tested the following payloads to narrow down the issue, with my results:

• Payload1 Lowercase O : Result no changes to setting { "time1on": "1" }
• Payload2 Uppercase O : Results, changes the setting { "time1On": "1" }

From my testing it looks like the API is not consistent in what it returns and what it expects.

Also note that I did not include genTimeXon in any payloads, or anything else. Those are my full payloads in Postman. It may be that either the combination or the other spelling will get the job done.

My changes were in "Setup Global Vars" and "Export Data Export To Entity" to change from timeXon to timeXOn, and is working consistenly now with the rest of your code.

[gdwaterworth]

Hi Sorry 1st , What is postman ?

You cannot just change Global Vars and Export Data as those setups are used in a variety of places It is also used in the mapping and pairing tables to determine when fields have changed and what needs to be set in the inverter.

My testing so far has been consistent and you need to take into account the requirements when setting that variable and updating the inverter.

Also you need to take into account that there is a deliberate time delay inserted to allow time for the inverter to actually get the change and implement it. It is not realtime and can take up to a minute ( or longer ). If you do changes before that timer runs out then you may see inconsistent results. That timer is there for a reason

timeXon has always been lowercase coming from the api and submitting to the api. There are others where there is a capital in the name, but the timeXon is not one of them

Regards

From: Gr3mlin13 @.> Sent: Tuesday, January 2, 2024 9:01 AM To: gdwaterworth/Home-Assistant---E-Linter-Logger---Sunsynk @.> Cc: gdwaterworth @.>; Comment @.> Subject: Re: [gdwaterworth/Home-Assistant---E-Linter-Logger---Sunsynk] Spelling for settings values (Issue #44)

Okay, to be more specific. In your NodeRed flows you use "timeXon", with a lowercase. This is consistent with the payload recieved from them when calling settings read.

However, this was not giving me consistent results, so I tested the following payloads to narrow down the issue, with my results:

• Payload1 Lowercase O : Result no changes to setting { "time1on": "1" }
• Payload2 Uppercase O : Results, changes the setting { "time1On": "1" }

From my testing it looks like the API is not consistent in what it returns and what it expects.

Also note that I did not include genTimeXon in any payloads, or anything else. Those are my full payloads in Postman. It may be that either the combination or the other spelling will get the job done.

My changes were in "Setup Global Vars" and "Export Data Export To Entity" to change from timeXon to timeXOn, and is working consistenly now with the rest of your code.

— Reply to this email directly, view it on GitHubhttps://github.com/gdwaterworth/Home-Assistant---E-Linter-Logger---Sunsynk/issues/44#issuecomment-1873674219, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AUYVNI6OHWJZF66CEFG75GLYMOWERAVCNFSM6AAAAABBJFCHTCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZTGY3TIMRRHE. You are receiving this because you commented.Message ID: @.**@.>>

[gdwaterworth]

In addition what region are you on ?

From: Gr3mlin13 @.> Sent: Tuesday, January 2, 2024 9:01 AM To: gdwaterworth/Home-Assistant---E-Linter-Logger---Sunsynk @.> Cc: gdwaterworth @.>; Comment @.> Subject: Re: [gdwaterworth/Home-Assistant---E-Linter-Logger---Sunsynk] Spelling for settings values (Issue #44)

Okay, to be more specific. In your NodeRed flows you use "timeXon", with a lowercase. This is consistent with the payload recieved from them when calling settings read.

However, this was not giving me consistent results, so I tested the following payloads to narrow down the issue, with my results:

• Payload1 Lowercase O : Result no changes to setting { "time1on": "1" }
• Payload2 Uppercase O : Results, changes the setting { "time1On": "1" }

From my testing it looks like the API is not consistent in what it returns and what it expects.

Also note that I did not include genTimeXon in any payloads, or anything else. Those are my full payloads in Postman. It may be that either the combination or the other spelling will get the job done.

My changes were in "Setup Global Vars" and "Export Data Export To Entity" to change from timeXon to timeXOn, and is working consistenly now with the rest of your code.

— Reply to this email directly, view it on GitHubhttps://github.com/gdwaterworth/Home-Assistant---E-Linter-Logger---Sunsynk/issues/44#issuecomment-1873674219, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AUYVNI6OHWJZF66CEFG75GLYMOWERAVCNFSM6AAAAABBJFCHTCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZTGY3TIMRRHE. You are receiving this because you commented.Message ID: @.**@.>>

[gdwaterworth]

Also note that I did not include genTimeXon in any payloads, or anything else.

This is why your testing is inconsistent That is a requirement from my testing

Did you also exclude the sn: from your payload ?

From: Gr3mlin13 @.> Sent: Tuesday, January 2, 2024 9:01 AM To: gdwaterworth/Home-Assistant---E-Linter-Logger---Sunsynk @.> Cc: gdwaterworth @.>; Comment @.> Subject: Re: [gdwaterworth/Home-Assistant---E-Linter-Logger---Sunsynk] Spelling for settings values (Issue #44)

Okay, to be more specific. In your NodeRed flows you use "timeXon", with a lowercase. This is consistent with the payload recieved from them when calling settings read.

However, this was not giving me consistent results, so I tested the following payloads to narrow down the issue, with my results:

• Payload1 Lowercase O : Result no changes to setting { "time1on": "1" }
• Payload2 Uppercase O : Results, changes the setting { "time1On": "1" }

From my testing it looks like the API is not consistent in what it returns and what it expects.

Also note that I did not include genTimeXon in any payloads, or anything else. Those are my full payloads in Postman. It may be that either the combination or the other spelling will get the job done.

My changes were in "Setup Global Vars" and "Export Data Export To Entity" to change from timeXon to timeXOn, and is working consistenly now with the rest of your code.

— Reply to this email directly, view it on GitHubhttps://github.com/gdwaterworth/Home-Assistant---E-Linter-Logger---Sunsynk/issues/44#issuecomment-1873674219, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AUYVNI6OHWJZF66CEFG75GLYMOWERAVCNFSM6AAAAABBJFCHTCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZTGY3TIMRRHE. You are receiving this because you commented.Message ID: @.**@.>>

[Gr3mlin13]

Postman is a tool to build and test APIs. I use it to query call the API directly, removing the variable of NodeRed to test just one thing at a time. I find it much quicker to work in there and figure out the API, as I am not yet that proficient in NodeRed yet.

I was simplifying, but you use the variables set in global to build your payload. When I changed those after my testing, I noticed the settings from the inverter were not updating correcly anymore, so I updated the Export Data entity to match the changes in Global Vars.

I am aware of the timer, I was waiting for confirmation that the post has happened anbd the reply recieved before checkning on the inverter that the settings have changed. Same process as when testing with the API directly.

On region 2 as everyone else after the migration.

As I said above, I get consistent results with the entire payload being just the one option, no genXon, no sn: { "time1On": "1" }

[Gr3mlin13]

This is howe I tested and figured it out. I started with sending back the variables recieved the api call GET : https://api.sunsynk.net/api/v1/common/setting/XXXXXXXXXX/read: { "code": 0, "msg": "Success", "data": { "sellTime1": "02:00", "genTime2on": false, "beep": 0, "sellTime2": "06:00", "wattOverExitFreqStopDelay": 0, "sellTime5": "18:00", "sellTime6": "22:00", "sellTime3": "10:00", "sellTime4": "14:00", "exMeterCtSwitch": 0, "sdChargeOn": 1, "lockInVoltVar": "0.0", "time2on": false, "batWarn": 0, "wattVarEnable": 0, "reconnMinVolt": 0, "caFStart": 0, "pvMaxLimit": 3000, "sensorsCheck": -1, "underFreq2Delay": 0, "varQac2": "0", "varQac3": "0", "varQac1": "0", "wattUnderExitFreq": 0, "overVolt1": 0, "overVolt2": 0, "varQac4": "0", "genPeakPower": 8000, "meterB": 0, "eeprom": 0, "meterA": 0, "comSet": 3819, "caVoltPressureEnable": 0, "meterC": 0, "wattUnderFreq1": 0, "solarMaxSellPower": 6500, "acCoupleOnGridSideEnable": 0, "thursdayOn": true, "time3On": 0, "batteryRestartCap": 35, "overFreq1Delay": 0, "bmsErrStop": 0, "checkTime": 10, "atsSwitch": 0, "acCurrentUp": 0, "sacPowerControl": 0, "rsd": 0, "batteryOn": 1, "genTime1on": false, "volt12": 490, "volt10": 550, "volt11": 490, "time1on": false, "wattUnderFreq1StartDelay": 0, "rcd": 0, "chargeVolt": 56, "wednesdayOn": true, "floatVolt": 55.2, "workState": 0, "loadMode": 0, "sysWorkMode": 2, "sn": "XXXXXXXXXX", "genCoolingTime": 0, "genPeakShaving": 0, "sellTime3Volt": 49, "sellTime2Pac": 5500, "current12": 0, "time2On": 0, "current10": 0, "current11": 0, "batteryEfficiency": 99, "genAndGridSignal": 1, "wattV4": "0.0", "acFreqLow": 48, "wattV2": "0.0", "wattV3": "0.0", "reactivePowerControl": 0, "wattV1": "0.0", "batteryEmptyV": 45, "open": 1, "reconnMaxFreq": 0, "standard": 0, "wattVarReactive2": "0", "disableFloatCharge": 0, "inverterType": 0, "wattVarReactive3": "0", "wattVarReactive4": "0", "solarPSU": 0, "fridayOn": true, "wattVarReactive1": "0", "time4on": false, "cap6": 60, "generatorForcedStart": 0, "overLongVolt": 0, "cap4": 80, "cap5": 60, "batteryChargeType": 1, "genOffVolt": 51, "cap2": 40, "cap3": 60, "absorptionVolt": 57.6, "genToLoad": 0, "mpptNum": 0, "underFreq2": 0, "underFreq1": 0, "wattPfEnable": 0, "remoteLock": 0, "generatorStartCap": 10, "batteryMaxCurrentCharge": 40, "overFreq1": 0, "tuesdayOn": true, "genOnVolt": 54, "overFreq2": 0, "solar2WindInputEnable": 72, "caVStop": 0, "time5On": 0, "battMode": -1, "genOnCap": 100, "gridAlwaysOn": 0, "batteryLowVolt": 47.5, "acFreqUp": 0, "cap1": 60, "chargeLimit": 0, "generatorStartVolt": 0, "overVolt1Delay": 0, "sellTime1Pac": 5500, "californiaFreqPressureEnable": 0, "activePowerControl": 0, "batteryRestartVolt": 52, "zeroExportPower": 20, "overVolt2Delay": 0, "equChargeCycle": 90, "dischargeCurrent": 100, "solarSell": 0, "mpptVoltLow": 200, "time3on": false, "wattVoltEnable": 0, "caFwEnable": 0, "maxOperatingTimeOfGen": 24, "micExportGridOff": 0, "importPower": 850, "pvLine": 0, "three41": 0, "caVwEnable": 0, "batteryShutdownVolt": 46, "volt3": 21.6, "volt4": 26.4, "volt1": 12, "volt2": 16.8, "startVoltUp": 1000, "volt7": 550, "volt8": 550, "riso": 0, "volt5": 550, "sellTime6Pac": 5500, "volt6": 550, "time4On": 0, "sellTime4Volt": 49, "volt9": 550, "facLowProtect": 47.5, "wattOverFreq1": 0, "wattPf4": "0.000", "lowNoiseMode": 8000, "tempco": 5, "arcFactFrz": -172135026, "wattPf1": "0.000", "wattPf2": "0.000", "wattPf3": "0.000", "meterSelect": 0, "genChargeOn": 0, "externalCtRatio": 2000, "gridMode": 0, "sellTime5Pac": 5500, "lowThrough": 0, "drmEnable": 0, "underFreq1Delay": 0, "energyMode": 1, "ampm": 0, "gridPeakShaving": 0, "time6on": false, "fac": 0, "vacLowProtect": 185, "chargeCurrentLimit": 95, "caLv3": 0, "sundayOn": true, "genTime6on": false, "batteryImpedance": 8, "safetyType": 0, "varVolt4": "0.0", "varVolt3": "0.0", "varVolt2": "0.0", "specialFunction": 0, "varVolt1": "0.0", "mondayOn": true, "commAddr": 0, "saturdayOn": true, "dischargeLimit": 0, "atsEnable": 0, "exMeterCt": 0, "overFreq2Delay": 0, "phase": 0, "autoDim": 1, "batteryWorkStatus": 1, "genToLoadOn": 0, "timeSync": 1, "wattOverWgralFreq": 0, "sdBatteryCurrent": 40, "peakAndVallery": 1, "batteryEmptyVolt": 45, "batteryLowCap": 30, "underVolt2Delay": 0, "equChargeTime": 0, "battType": 0, "gridPeakPower": 8000, "reset": 0, "vacHighProtect": 265, "genTime5on": false, "pwm": 0, "time5on": false, "highThrough": 0, "lockOutVoltVar": "0.0", "lockInWattPF": "0.0", "caVStart": 0, "acVoltUp": 130, "wattFreqEnable": 0, "wattOverExitFreq": 0, "sellTime5Volt": 49, "caFStop": 0, "lowPowerMode": 0, "varVoltEnable": 0, "acCoupleFreqUpper": 52, "impedanceLow": 0.1, "acType": 0, "facHighProtect": 51.5, "recoveryTime": 600, "underVolt2": 0, "lithiumMode": 0, "underVolt1": 0, "gridSignal": 1, "wattOverFreq1StartDelay": 0, "testCommand": 0, "time6On": 0, "signalIslandModeEnable": 0, "upsStandard": 0, "reconnMinFreq": 0, "parallelRegister2": 0, "parallelRegister1": 0, "startVoltLow": 300, "smartLoadOpenDelay": 100, "genTime4on": false, "sellTime1Volt": 49, "wattVarActive4": "0", "wattVarActive3": "0", "genConnectGrid": 0, "flag2": 0, "softStart": 0, "lockOutWattPF": "0.0", "sdStartCap": 30, "current4": 490, "current3": 490, "current2": 490, "current1": 490, "gfdi": 0, "current8": 0, "current7": 0, "current6": 0, "current5": 6, "checkSelfTime": 1, "limit": 2, "wattW3": "0", "wattVarActive2": "0", "wattW4": "0", "wattVarActive1": "0", "externalCurrent": 0, "wattW1": "0", "wattW2": "0", "vnResponseTime": 0, "batteryShutdownCap": 20, "wattUnderExitFreqStopDelay": 0, "offset": 0, "sellTime4Pac": 5500, "wattActivePf1": 0, "current9": 0, "dischargeVolt": 0, "qvResponseTime": 0, "wattActivePf4": 0, "time1On": 0, "wattActivePf2": 0, "four19": 0, "wattActivePf3": 0, "micExportAll": 0, "batteryMaxCurrentDischarge": 90, "isletProtect": 0, "californiaVoltPressureEnable": 0, "equVoltCharge": 57.6, "batteryCap": 100, "genOffCap": 95, "powerFactor": 1000, "genTime3on": false, "sellTime6Volt": 49, "sellTime3Pac": 5500, "acCoupleOnLoadSideEnable": 0, "sdStartVolt": 49, "generatorBatteryCurrent": 40, "reconnMaxVolt": 0, "modbusSn": 0, "inverterOutputVoltage": 0, "chargeCurrent": 95, "solar1WindInputEnable": 24, "dcVoltUp": 500, "parallel": 0, "limter": 0, "batErr": 0, "backupDelay": 0, "dischargeCurrentLimit": 100, "arcFactT": 1659059040, "wattUnderWgalFreq": 0, "commBaudRate": 0, "equipMode": 0, "gridSideINVMeter2": 0, "underVolt1Delay": 0, "arcFaultType": 0, "arcFactB": 401629572, "normalUpwardSlope": 0, "arcFactC": 518409641, "pf": 1, "arcFactD": 976377442, "genMinSolar": 0, "sellTime2Volt": 49, "arcFactF": 884630023, "arcFactI": -383828332, "acVoltLow": 0, "genSignal": 0 }, "success": true }

Checking this now, it seems like both are available in the response. It might be that timeXOn works on its own, while timeXon needs the other variables to be consistent. I just used the uppercase one as 1 and 0 are shorter to type than true and false. "time2on": false, "time3On": 0, "time1on": false, "time2On": 0, "time4on": false, "time5On": 0, "time3on": false, "time4On": 0, "time6on": false, "time5on": false, "time6On": 0, "time1On": 0,

[gdwaterworth]

Hi

That is not the way that the sunsynk/pv.inteless.com website handle the api update I try emulate them as close as possible hence why I do not use the O version Also excluding the sn is dangerous in multi inverter/plant setups.

I am happy with the way the updates happen when I pair the gen and normal time, so will not be changing that

Regards

From: Gr3mlin13 @.> Sent: Tuesday, January 2, 2024 9:42 AM To: gdwaterworth/Home-Assistant---E-Linter-Logger---Sunsynk @.> Cc: gdwaterworth @.>; Comment @.> Subject: Re: [gdwaterworth/Home-Assistant---E-Linter-Logger---Sunsynk] Spelling for settings values (Issue #44)

Postman is a tool to build and test APIs. I use it to query call the API directly, removing the variable of NodeRed to test just one thing at a time. I find it much quicker to work in there and figure out the API, as I am not yet that proficient in NodeRed yet.

I was simplifying, but you use the variables set in global to build your payload. When I changed those after my testing, I noticed the settings from the inverter were not updating correcly anymore, so I updated the Export Data entity to match the changes in Global Vars.

I am aware of the timer, I was waiting for confirmation that the post has happened anbd the reply recieved before checkning on the inverter that the settings have changed. Same process as when testing with the API directly.

On region 2 as everyone else after the migration.

As I said above, I get consistent results with the entire payload being just the one option, no genXon, no sn: { "time1On": "1" }

— Reply to this email directly, view it on GitHubhttps://github.com/gdwaterworth/Home-Assistant---E-Linter-Logger---Sunsynk/issues/44#issuecomment-1873697843, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AUYVNI6LLWWI7QJV2LF3UJLYMO23JAVCNFSM6AAAAABBJFCHTCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZTGY4TOOBUGM. You are receiving this because you commented.Message ID: @.***>

[Gr3mlin13]

Okay quick test, it looks like the pairing works as well, but have to use true and false instead of the numbers. { "genTime1on": true, "time1on": true }

So can use the pairing with true or false, or just uppercase with 1 or 0. Will go and check why your default did not work for me.

That is not the way that the sunsynk/pv.inteless.com website handle the api update Do you have a reference for how the sunsynk website hadles it, would be much easier than the manual testing I have been doing so far?

[gdwaterworth]

Yes , It has always been that way

I just checked the website submission again : They only use : time1on true time2on true time3on true time4on true time5on true time6on true

The capital O being returned in the settings get call is something new There was a problem a while back where the timeslot times were “broken” and is probably due to that I wouldn’t use them

battMode "-1" cap1 "50" cap2 "30" cap3 "25" cap4 "85" cap5 "80" cap6 "70" energyMode "1" fridayOn false genTime1on true genTime2on true genTime3on true genTime4on true genTime5on true genTime6on true mondayOn false peakAndVallery "1" pvMaxLimit "8000" safetyType "2" saturdayOn false sellTime1 "00:00" sellTime1Pac "8000" sellTime1Volt "49" sellTime2 "04:30" sellTime2Pac "8000" sellTime2Volt "49" sellTime3 "05:00" sellTime3Pac "8000" sellTime3Volt "49" sellTime4 "15:30" sellTime4Pac "8000" sellTime4Volt "49" sellTime5 "22:00" sellTime5Pac "8000" sellTime5Volt "49" sellTime6 "23:00" sellTime6Pac "8000" sellTime6Volt "49" sn XXXXXX solarMaxSellPower "9000" solarSell "0" sundayOn false sysWorkMode "1" thursdayOn false time1on true time2on true time3on true time4on true time5on true time6on true tuesdayOn false wednesdayOn false zeroExportPower "20"

From: Gr3mlin13 @.> Sent: Tuesday, January 2, 2024 9:58 AM To: gdwaterworth/Home-Assistant---E-Linter-Logger---Sunsynk @.> Cc: gdwaterworth @.>; Comment @.> Subject: Re: [gdwaterworth/Home-Assistant---E-Linter-Logger---Sunsynk] Spelling for settings values (Issue #44)

Okay quick test, it looks like the pairing works as well, but have to use true and false instead of the numbers. { "genTime1on": true, "time1on": true }

So can use the pairing with true or false, or just uppercase with 1 or 0. Will go and check why your default did not work for me.

That is not the way that the sunsynk/pv.inteless.com website handle the api update Do you have a reference for how the sunsynk website hadles it, would be much easier than the manual testing I have been doing so far?

— Reply to this email directly, view it on GitHubhttps://github.com/gdwaterworth/Home-Assistant---E-Linter-Logger---Sunsynk/issues/44#issuecomment-1873708150, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AUYVNI46JGYCBSHID3BDI4LYMO42DAVCNFSM6AAAAABBJFCHTCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZTG4YDQMJVGA. You are receiving this because you commented.Message ID: @.**@.>>

[Gr3mlin13]

Got it, would be helpfull if there was easily accesible API docs available. For now will keep using as is.

Thanks,

[gdwaterworth]

You are wishing. What is being done here is not condoned by Sunsynk and done at your own risk

From: Gr3mlin13 @.> Sent: Tuesday, January 2, 2024 10:04 AM To: gdwaterworth/Home-Assistant---E-Linter-Logger---Sunsynk @.> Cc: gdwaterworth @.>; Comment @.> Subject: Re: [gdwaterworth/Home-Assistant---E-Linter-Logger---Sunsynk] Spelling for settings values (Issue #44)

Got it, would be helpfull if there was easily accesible API docs available. For now will keep using as is.

Thanks,

— Reply to this email directly, view it on GitHubhttps://github.com/gdwaterworth/Home-Assistant---E-Linter-Logger---Sunsynk/issues/44#issuecomment-1873712294, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AUYVNIZ7QZNW7GGPYGCPY4LYMO5QZAVCNFSM6AAAAABBJFCHTCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZTG4YTEMRZGQ. You are receiving this because you commented.Message ID: @.**@.>>

[gdwaterworth]

Just to phrase it nicely

There are some “limited” api docs available which are available in the git repo There is absolutely nothing on setting settings

Everything that has been done in this work is all reverse engineered from looking at the application traffic

From: Gr3mlin13 @.> Sent: Tuesday, January 2, 2024 10:04 AM To: gdwaterworth/Home-Assistant---E-Linter-Logger---Sunsynk @.> Cc: gdwaterworth @.>; Comment @.> Subject: Re: [gdwaterworth/Home-Assistant---E-Linter-Logger---Sunsynk] Spelling for settings values (Issue #44)

Got it, would be helpfull if there was easily accesible API docs available. For now will keep using as is.

Thanks,

— Reply to this email directly, view it on GitHubhttps://github.com/gdwaterworth/Home-Assistant---E-Linter-Logger---Sunsynk/issues/44#issuecomment-1873712294, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AUYVNIZ7QZNW7GGPYGCPY4LYMO5QZAVCNFSM6AAAAABBJFCHTCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZTG4YTEMRZGQ. You are receiving this because you commented.Message ID: @.**@.>>

[Gr3mlin13]

Great Thanks,

I have the basics sorted now, so will not be without power when loadshedding hits.

Now the fun can start and tinkering to figure everything out properly.

Thanks for the assist, will check back in if I figure someting else out. Hopefully I can assist back sometime in the future.