Hannesvz

This is great. The registers on the 8KW Sunsynk are definitely different. I've managed to toggle system timer, and grid charge per timezone, as well as set the SOC using the config below.
switch: - platform: modbus_controller # 248 Toggle System Timer use_write_multiple: true modbus_controller_id: sunsynk name: "Toggle System Timer" id: sunsynk_esphome_toggle_Time_of_Use register_type: holding address: 248 bitmask: 1 entity_category: config icon: "mdi:toggle-switch" - platform: modbus_controller # 274 Toggle Grid Charge Timezone1 use_write_multiple: true modbus_controller_id: sunsynk name: "Toggle Grid Charge Timezone1" id: sunsynk_esphome_toggle_grid_charge_timezone1 register_type: holding address: 274 bitmask: 1 entity_category: config icon: "mdi:toggle-switch" - platform: modbus_controller # 275 Toggle Grid Charge Timezone2 modbus_controller_id: sunsynk use_write_multiple: true name: "Toggle Grid Charge Timezone2" id: sunsynk_esphome_toggle_grid_charge_timezone2 register_type: holding address: 275 bitmask: 1 entity_category: config icon: "mdi:toggle-switch" - platform: modbus_controller # 276 Toggle Grid Charge Timezone3 modbus_controller_id: sunsynk use_write_multiple: true name: "Toggle Grid Charge Timezone3" id: sunsynk_esphome_toggle_grid_charge_timezone3 register_type: holding address: 276 bitmask: 1 entity_category: config icon: "mdi:toggle-switch" - platform: modbus_controller # 277 Toggle Grid Charge Timezone4 modbus_controller_id: sunsynk use_write_multiple: true name: "Toggle Grid Charge Timezone4" id: sunsynk_esphome_toggle_grid_charge_timezone4 register_type: holding address: 277 bitmask: 1 entity_category: config icon: "mdi:toggle-switch" - platform: modbus_controller # 278 Toggle Grid Charge Timezone5 modbus_controller_id: sunsynk use_write_multiple: true name: "Toggle Grid Charge Timezone5" id: sunsynk_esphome_toggle_grid_charge_timezone5 register_type: holding address: 278 bitmask: 1 entity_category: config icon: "mdi:toggle-switch" - platform: modbus_controller # 279 Toggle Grid Charge Timezone6 modbus_controller_id: sunsynk use_write_multiple: true name: "Toggle Grid Charge Timezone6" id: sunsynk_esphome_toggle_grid_charge_timezone6 register_type: holding address: 279 bitmask: 1 entity_category: config icon: "mdi:toggle-switch" number: - platform: modbus_controller # 268 Settings SoC Timezone1 use_write_multiple: true modbus_controller_id: sunsynk id: sunsynk_esphome_set_soc_timezone1 name: "Set SoC Timezone1" unit_of_measurement: "%" address: 268 min_value: 0 max_value: 100 step: 5 value_type: U_WORD - platform: modbus_controller # 269 Settings SoC Timezone2 use_write_multiple: true modbus_controller_id: sunsynk id: sunsynk_esphome_set_soc_timezone2 name: "Set SoC Timezone2" unit_of_measurement: "%" address: 269 min_value: 0 max_value: 100 step: 5 value_type: U_WORD - platform: modbus_controller # 270 Settings SoC Timezone3 use_write_multiple: true modbus_controller_id: sunsynk id: sunsynk_esphome_set_soc_timezone3 name: "Set SoC Timezone3" unit_of_measurement: "%" address: 270 min_value: 0 max_value: 100 step: 5 value_type: U_WORD - platform: modbus_controller # 271 Settings SoC Timezone4 use_write_multiple: true modbus_controller_id: sunsynk id: sunsynk_esphome_set_soc_timezone4 name: "Set SoC Timezone4" unit_of_measurement: "%" address: 271 min_value: 0 max_value: 100 step: 5 value_type: U_WORD - platform: modbus_controller # 272 Settings SoC Timezone5 use_write_multiple: true modbus_controller_id: sunsynk id: sunsynk_esphome_set_soc_timezone5 name: "Set SoC Timezone5" unit_of_measurement: "%" address: 272 min_value: 0 max_value: 100 step: 5 value_type: U_WORD - platform: modbus_controller # 273 Settings SoC Timezone6 use_write_multiple: true modbus_controller_id: sunsynk id: sunsynk_esphome_set_soc_timezone6 name: "Set SoC Timezone6" unit_of_measurement: "%" address: 273 min_value: 0 max_value: 100 step: 5 value_type: U_WORD  

Vital to being able to keep within the inverter output limits (and avoid importing expensive grid power unnecessarily) is having the means to display the relevant information in an immediate and accessible way.
That's what I told my wife, anyway.  Really, I'd just scored a bunch of old RC servos on ebay for £5 and I wanted to play with them. 😉

 
In context:

 
It uses 6 servos, a Wemos d1 mini clone and a tri-colour LED.  Dial faces are 3D printed, with a filament change from white to black (which turned out much better than I imagined, TBH).
The servos only had around 90° of sweep angle, so I 3D printed some little holder/gearbox things to get over 180° and provide a shaft for the needle to go on, plus some 'steampunk' needles.


 
All run buy the obligatory D1 mini and held together using the very latest in 'twist and tape' technology.

 
Yee-haw! 🤠
It gets fed the data from 'node-red' running on a Victron CerboGX via UDP packets over WiFi, updating as often as the data changes (approx 3 second intervals).  The LED changes colour according to state, so 'All OK' is green, 'You're getting very close to/exceeding the inverter output limit, so if you don't want to pay for grid, don't turn anything else on' is red, then blue for 'dumping power into the hot water tank'.
It's by no means silent in operation.  I originally made a single-servo version for just PV generation and coded it so that the meter movements were gradual (a kind of PID to get from one value to the next), but apparently it 'sounded like we have cockroaches' when it made it's ticky-scratchy transitions between values, so the big version just jumps between values with a 'zzziiiiiup!' sound.
It's actually quite reassuring to have an audible indication when the sun comes out for 5 seconds, or it starts charging at night.
I'd also put a little radar sensor in there, with the aim of having it detect when there was nobody around, so it could stop displaying to save power/noise.  Unfortunately, that meant that every time you entered the room, all 6 needles would suddenly move at the same time, making you jump out of your skin and spill your horlicks, so we just leave it 'on' all the time now.
There's also a basic web UI, so you can see the same data on your phone or whatever, plus it's useful for troubleshooting:

 
I had fun and learned loads making it - and now it's become a family game to try to cook dinner without making the red light come on. 🙂
 
Libraries used are 'ESPUI' and 'servo', plus 'arduinoOTA'.  Code, FreeCad file for the gearbox & stl file for the arrow-head needle are all in the attached zip.
Power_meters_v2..zip

You can also just run homeassistant and nodered in a docker container.
 

Yes u can. 
node-red is multi-platform. 
here are the instructions for a windows install: https://nodered.org/docs/getting-started/windows

Ideal Low Cost Basic Loadshedding Protection Solution.
Tidy install with C.O.C

Oh forgot to mention - For those who did not know, ESP recently released a loadshedding API which can be used by personal users and integrated directly into HA. Just need to request an API key from them. Been using it for a week. Works very well

The thing that fixed the inverter not speaking back to me was the modbus sn was set to 0, when I set it to 01 it fixed the issue immediately. For curiosity I tried to put it back to 0 and was unable to do so. @kellerza you should add to your github that people should remember to set the modbus sn to 01 < .  Thanks for helping me everyone.  

@Hannesvz glad you got it fixed!
I would still change the wiring to be on a pair to minimise errors. No point in trying to fight the physics behind differential signals

The thing that fixed the inverter not speaking back to me was the modbus sn was set to 0, when I set it to 01 it fixed the issue immediately. For curiosity I tried to put it back to 0 and was unable to do so. @kellerza you should add to your github that people should remember to set the modbus sn to 01 < .  Thanks for helping me everyone.  

Good day All,
Over the past couple of months I have received numerous requests to share my NodeRed flows used for monitoring the status of the SunSynk inverter.  My initial idea was to package all of the flows into an easy to use package and user interface, however my work loads have not provided me the luxury of time to play around and make it a fool proof system. 
Please note that the use of these flows are at your own discretion with no liability to either myself, this site nor any members of this site.  Do not attempt implement these flows if you are unfamiliar with the working of the ModBus protocol or basic programming.
Brief overview of the flows:
LoadShedStatus - This flow determines the loadshedding status through a webscraper.  I use this information to trigger a secondary set of settings to the inverter in case of load shedding. ModBusRead - This flow is responsible for reading information from the Inverter via the Modbus Flex getter ModBusWrite - This flow is responsible for writing settings back to the inverter via the Modbus flex getter Inverter Monitoring - This flow is responsible for obtaining all of the inverter monitoring values.  The values are then send to Home Asssistant via MQTT as well as logged to an InfluxDB for monitoring via Grafana SSFormRead - This flow reads the current system settings from the inverter and display it via the NodeRed UI SSFormWrite - This flow writes any changes made to the system settings via the NodeRed UI back to inverter SSDSRead - This flow reads the "Default Settings" from storage and displays it via the NodeRed UI.  I use the "Default Settings" to store my optimal system settings when there is no Load Shedding. SSDSWrite - This flow writes the "Default Settings" from the storage to the Inverter.  The flow is also triggered automatically from the LoadShedding status flow SSLSRead - This flow reads the "Load Shedding Settings" from storage and displays it via the NodeRed UI.  I use the "Default Settings" to store my optimal system settings when there is no Load Shedding. SSLSWrite - This flow writes the "Load Shedding Settings" from the storage to the Inverter.  The flow is also triggered automatically from the LoadShedding status flow TimeMode - This flow triggers different settings on different days of the week.  My PV Solar is currently not big enough to carry my whole house, I utilize this flow to feed electricity back into the non-essential loads on the days which my domestic worker is not working.  This helps me to optimize my savings on certain days of the week while maintaining healthy battery levels. NodeRed Palettes required for the flows:
node-red-contrib-actionflows node-red-contrib-influxdb node-red-contrib-modbus node-red-contrib-queue-gate node-red-contrib-schedex node-red-contrib-simple-gate node-red-dashboard The next couple of posts have been reserved to further expand on the hardware requirements and basic set up of the monitoring.
The idea of sharing my flows is to contribute to the community, let us keep this going as a community project by assisting and contributing to project.
flows (5).json sunsynk_modbus.docx

Hi TJ 
On the Modbus document that I have, it has the 417 Register marked as R/W so strange that it cannot be written to. 
Maybe someone else who has more experience with Modbus can comment, can only guess that there may be some other setting/value that needs to be changed to allow that value to be written. 
Good luck, keep us posted please. 
 
 
sunsynk_modbus - no chinese.docx