February 6, 20242 yr 1 hour ago, brussel said: Hi All I've attached some screen shots from HA. My energy reporting is all over the show On the 2nd it looked normal but on the other days I've got all sorts of erratic readings some showing solar production in the MW which would be cool if it was true. Sunsynk is showing all the correct data. any ideas? You have to go to developer tools, statistics and change the high readings to 0. Open a new tab check for the high readings in energy and between what times they are, increase statistic sensors by 10 minutes until all the high readings are ironed out.
February 6, 20242 yr Author I know about this. still not sure why. Looking at a way to import historical information from the sunsynk api into ha Bit of a "longer term" project for me atm On paper I have a process mapped out to probably fix the historical data. Still busy looking and experimenting Biggest hurdle I have to get past is how to expose the statistics db to the node red docker instance Edited February 6, 20242 yr by Gary Waterworth
February 6, 20242 yr @Gary WaterworthIs this a new issue eith the newer versions? I've not seen it before on the older versions of your integration. Will the solution suggested by @Ronnie1102 be a usable workaround?
February 6, 20242 yr Author 1 hour ago, brussel said: @Gary WaterworthIs this a new issue eith the newer versions? I've not seen it before on the older versions of your integration. Will the solution suggested by @Ronnie1102 be a usable workaround? 1. no idea 2. It's how I do it as well
February 7, 20242 yr Author 15 hours ago, Gary Waterworth said: 1. no idea 2. It's how I do it as well This is half teh reason we battle. Some web calls work , some dont I am busy putting in more checks so that export of data to entities is not started if there are issues Old or new version. Both are going to be problematic Edited February 7, 20242 yr by Gary Waterworth
February 8, 20242 yr Be wary for those that use automations to set the battery capacity's, I have a automation that sets soc 1 and soc 2 to 100% if load shedding is at a certain time with a delay of 1 minute between them and soc 2 was just changed back to 49% by supervisor whilst soc 1 was successful. Is 1 minute too short @Gary Waterworth or is this just a HA thing? Happens at times but not always. Edited February 8, 20242 yr by Ronnie1102
February 8, 20242 yr Author 32 minutes ago, Ronnie1102 said: Be wary for those that use automations to set the battery capacity's, I have a automation that sets soc 1 and soc 2 to 100% if load shedding is at a certain time with a delay of 1 minute between them and soc 2 was just changed back to 49% by supervisor whilst soc 1 was successful. Is 1 minute too short @Gary Waterworth or is this just a HA thing? Happens at times but not always. What is your dongle interval? But even if your dongle is 60s I would still use 2 to 3 min. This is the problem with automations and why I prefer using node red Edited February 8, 20242 yr by Gary Waterworth
February 8, 20242 yr 1 minute ago, Gary Waterworth said: What is your dongle interval? But even if your dongle is 60s I would still use 2 to 3 min. It is 60 seconds, will bump up to 2 and test then bump to 3 if necessary.
February 8, 20242 yr Is there any way to switch the work mode to “Selling first”? I notice there’s a work mode entity 1/2/3 but it doesn’t seem to do anything. when I change in HA the mode doesn’t change in the app and vice versa
February 9, 20242 yr Author 7 hours ago, Benseb said: Is there any way to switch the work mode to “Selling first”? I notice there’s a work mode entity 1/2/3 but it doesn’t seem to do anything. when I change in HA the mode doesn’t change in the app and vice versa It is not fully implemented yet
February 9, 20242 yr Author Note : This was all fine yesterday , going to reset my dongle again Revamping the error checking in the flows again. This is why I prefer functions to automations. Automation wont pick this up : Gateway itself says it was last seen at midnight : Gateway gathered shows gateway in warning mode, website doesnt show that But the Stats were just updated 😕 Go Figure the shitty Sunsynk data gathering Edited February 9, 20242 yr by Gary Waterworth
February 9, 20242 yr 13 hours ago, Gary Waterworth said: What is your dongle interval? But even if your dongle is 60s I would still use 2 to 3 min. This is the problem with automations and why I prefer using node red Node red is not easy though is it? I look at node red and it looks like a map of doom to me so I do not fiddle with it. This is what one of my automations look like, not sure how easy it is to pull off in node red? alias: No load shedding from 5am to 7am setting battery to 49% description: "" trigger: - platform: time at: "00:01:00" condition: - condition: and conditions: - condition: numeric_state entity_id: sensor.load_shedding_area_eskdo_4_uvongohibiscuscoastkwazulunatal attribute: starts_in above: 500 - condition: numeric_state entity_id: sensor.load_shedding_stage_eskom attribute: stage below: 5 action: - service: input_text.set_value target: entity_id: input_text.sunsynk_cap1 data: value: "49" - delay: hours: 0 minutes: 3 seconds: 0 milliseconds: 0 - service: input_text.set_value data: value: "49" target: entity_id: input_text.sunsynk_cap2 - service: notify.notify data: message: No load shedding from 5am to 7am setting battery to 49% mode: single
February 10, 20242 yr Author 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
February 10, 20242 yr Author On 2024/02/09 at 10:17 AM, Ronnie1102 said: Node red is not easy though is it? I look at node red and it looks like a map of doom to me so I do not fiddle with it. This is what one of my automations look like, not sure how easy it is to pull off in node red? alias: No load shedding from 5am to 7am setting battery to 49% description: "" trigger: - platform: time at: "00:01:00" condition: - condition: and conditions: - condition: numeric_state entity_id: sensor.load_shedding_area_eskdo_4_uvongohibiscuscoastkwazulunatal attribute: starts_in above: 500 - condition: numeric_state entity_id: sensor.load_shedding_stage_eskom attribute: stage below: 5 action: - service: input_text.set_value target: entity_id: input_text.sunsynk_cap1 data: value: "49" - delay: hours: 0 minutes: 3 seconds: 0 milliseconds: 0 - service: input_text.set_value data: value: "49" target: entity_id: input_text.sunsynk_cap2 - service: notify.notify data: message: No load shedding from 5am to 7am setting battery to 49% mode: single 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. Edited February 10, 20242 yr by Gary Waterworth
February 10, 20242 yr @Gary Waterworth our main use is to turn the “Use timer” on/off as this allows us to force charge the battery during off peak electric its working well now, but occasionally the update doesn’t get through which means we end up charging the car from the battery Is there any sort of retry mechanism in Node are to retry the update if it fails? Or an entity I can check that will say the update failed so I can trigger a notification to do it manually? thanks. Great integration!
February 10, 20242 yr 54 minutes ago, Gary Waterworth said: 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. You are right, will add a few more checks rather in case. I steer clear from javascript do not have a clue on it but I am sure chat gpt should assist me mostly, will have a look at see what it comes up with.
February 11, 20242 yr Author Very puzzled atm. Looking at the short term data the point in time readings are correc , but the sum jumps 😕 from 112596 -> 150134. Was no stats reset I can see Defies what I know of how the recorder works State data shows the problem Somewhere a figure of 37538.2 was returned .... Attribute data for raw data on Usable_pv for same time range Attributes for that time : Now etotal is a simple totalling for all inverters of which I have 1 : Tracing back further is hard, so going to have to see how I can log actual inverter data without breaking HA Got 2 options atm : 1. play with the filters I am testing to remove outliers 2. Keep digging and try see if I can log actual return data from the api Could be 2 causes : 1. Sunsynk is giving crap data ( not unheard of ) 2. Race condition in the node red flow. I am leaning to a race condition as the 37,538.2 value is exactly double what it should be This can only be caused by a longer running web api query. Will look at increasing the delay Edited February 11, 20242 yr by Gary Waterworth
February 11, 20242 yr Author Added request timeouts to all web requests , going to make it a config item , but allready seeing this 😕
February 11, 20242 yr I am seeing this more and more as well with the soc going to 0 a lot not sure what is causing it
February 11, 20242 yr Author 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)}} Edited February 11, 20242 yr by Gary Waterworth
February 11, 20242 yr Author 20 hours ago, Benseb said: @Gary Waterworth our main use is to turn the “Use timer” on/off as this allows us to force charge the battery during off peak electric its working well now, but occasionally the update doesn’t get through which means we end up charging the car from the battery Is there any sort of retry mechanism in Node are to retry the update if it fails? Or an entity I can check that will say the update failed so I can trigger a notification to do it manually? thanks. Great integration! There is currently no retry. Last update status is in : sensor.new_sunsynk_update_status Edit : Need to check that this still updates correctly on web timeouts Edited February 11, 20242 yr by Gary Waterworth
February 11, 20242 yr Author Latest changes are in Delopement branch. Going to stop changes for now and just monitor for a while. Made quite a few. Going to maybe play with the request timeouts even on 4 seconds there are a LOT of requests that are failing due to timeout 😕 Also need to readup on the filter entities I am using for the energy graph entities to see if that helps with outliers Edited February 11, 20242 yr by Gary Waterworth
February 12, 20242 yr On 2024/02/11 at 8:06 AM, Gary Waterworth said: Latest changes are in Delopement branch. Going to stop changes for now and just monitor for a while. Made quite a few. Going to maybe play with the request timeouts even on 4 seconds there are a LOT of requests that are failing due to timeout 😕 Also need to readup on the filter entities I am using for the energy graph entities to see if that helps with outliers 4000ms is horrendous for an API should be a few hundred ms Sunsynk really need to get their 💩 together
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.