Bloubul7

I have a Pylontech US3000 3.5kWh 48v Lithium-Ion Solar Battery available for sale. The battery and has never been used. With loadshedding on the rise, this is the best way to get your home on backup when there is power outage. Shipping included price. Pm me please.
Item: Pylontech US3000 
Age: 2 years
Price: R6500
Payment Method Accepted: Instant EFT
Warranty: No
Packaging: No
Condition: Good, 
Location: Sandton
Reason: Upgraded
Shipping: YES
 

I will share my Node Red flows to do this over the weekend.  Currently in Germany and don't have access to my server

What I have done is to set up different timetables in Node Red variables.  When loadshedding is detected through the API (eskomsepush) then a flow would change the battery charge points in relation to the set timetables.  Different settings set up for different loadshedding stages.
 
 

It all depends on what you want to achieve. 
Light switches - No need to flash with Tasmota.  Can integrate directly with HA.  For those places where you can't get a neutral to light switch you can have a look at the Eachen switches as well, they use the same Ewelink platform Normal On/ Off control of devices - No need to flash. Integrates directly with HA Complicated load control - For example controlling Geysers.  Suggest to flash with Tasmota. The advantage of the Tasmota is the ability to set up "Rules" on the device itself which are stored in the ROM.  This provides additional backup should your HA fail for some odd reason or the unit looses it's WiFi connection.  For example, I have the following rules running on the TH16's controlling my geysers
Switch off when the temperature exceeds 65C.  Home assistant is set up to heat the Geysers to 60C, if HA fails to switch off the unit at 60 then I know the unit will switch off itself at 65 Keep the unit switched off when the temperature drops below 5C.  This is just incase the unit looses connection to the temperature sensor Switch off when the MQTT connection to HA fails.  This prevents the Geyser from heating if the Wifi connection drops or my HA fails. Some examples of items which I have currently automated/ controlling through HA
27 light switches.  Majority of them runs on Sonoff switches, the down stairs switches runs on Eachen as it is a hassle to get a neutral through the concrete slab. 2x Geysers.  Using Sonoff TH16 with DS18B20 temperature sensors, tasmota firmware and 40a relays 1x Pool Pump. Using Sonoff TH16.  Automated to run only when excess Solar generation is available. 1x Fountain pump.  Using Sonoff Basic, automated to run on a timer SunSynk Inverter.  Inverter values are communicated to HA via MQTT Wifi Mesh System.  Asus based Wifi Mesh, provides notifications when certain devices join/ drop off the network. 2x Home Theatre receivers.  The one receiver is automated to automatically turn on the projector, turn off the downlights and turn on the LED light strips when switched on.  Reverse when the receiver is turned off  1x Aircon.  Using Sensibo as gateway. Automated to operated at different modes based on the target temperature.  Will only turn on based on room temperature, time schedule and if we are at home Robotic Vacuum Cleaner.  Garden Sprinkler System.  Integrated with my Bhyve system.  Watering schedules based on weather forecast. Garage Doors. Using Sonoff SV flashed with Tasmota.  Can check if the doors are open or closed.  Can also open/ close via the app All of the above are nicely integrated with the mobile App.  I'm not using the HA cloud service, using port forwarding with integrated firewall in my router setup.
Some other nice features which you can build into the automations:
Limit/ reduce loads based on Load shedding status Check who is at home (based on wifi connections) Shopping List.  Useful to add notes of items to buy, I'm thinking of mounting an old tablet in the kitchen to easily add items as the need arise.

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

It all depends on what you want to achieve. 
Light switches - No need to flash with Tasmota.  Can integrate directly with HA.  For those places where you can't get a neutral to light switch you can have a look at the Eachen switches as well, they use the same Ewelink platform Normal On/ Off control of devices - No need to flash. Integrates directly with HA Complicated load control - For example controlling Geysers.  Suggest to flash with Tasmota. The advantage of the Tasmota is the ability to set up "Rules" on the device itself which are stored in the ROM.  This provides additional backup should your HA fail for some odd reason or the unit looses it's WiFi connection.  For example, I have the following rules running on the TH16's controlling my geysers
Switch off when the temperature exceeds 65C.  Home assistant is set up to heat the Geysers to 60C, if HA fails to switch off the unit at 60 then I know the unit will switch off itself at 65 Keep the unit switched off when the temperature drops below 5C.  This is just incase the unit looses connection to the temperature sensor Switch off when the MQTT connection to HA fails.  This prevents the Geyser from heating if the Wifi connection drops or my HA fails. Some examples of items which I have currently automated/ controlling through HA
27 light switches.  Majority of them runs on Sonoff switches, the down stairs switches runs on Eachen as it is a hassle to get a neutral through the concrete slab. 2x Geysers.  Using Sonoff TH16 with DS18B20 temperature sensors, tasmota firmware and 40a relays 1x Pool Pump. Using Sonoff TH16.  Automated to run only when excess Solar generation is available. 1x Fountain pump.  Using Sonoff Basic, automated to run on a timer SunSynk Inverter.  Inverter values are communicated to HA via MQTT Wifi Mesh System.  Asus based Wifi Mesh, provides notifications when certain devices join/ drop off the network. 2x Home Theatre receivers.  The one receiver is automated to automatically turn on the projector, turn off the downlights and turn on the LED light strips when switched on.  Reverse when the receiver is turned off  1x Aircon.  Using Sensibo as gateway. Automated to operated at different modes based on the target temperature.  Will only turn on based on room temperature, time schedule and if we are at home Robotic Vacuum Cleaner.  Garden Sprinkler System.  Integrated with my Bhyve system.  Watering schedules based on weather forecast. Garage Doors. Using Sonoff SV flashed with Tasmota.  Can check if the doors are open or closed.  Can also open/ close via the app All of the above are nicely integrated with the mobile App.  I'm not using the HA cloud service, using port forwarding with integrated firewall in my router setup.
Some other nice features which you can build into the automations:
Limit/ reduce loads based on Load shedding status Check who is at home (based on wifi connections) Shopping List.  Useful to add notes of items to buy, I'm thinking of mounting an old tablet in the kitchen to easily add items as the need arise.

Not sure Node-Red give you that much from a dashboarding and UI perspective. You have a UI to modify some system settings on Node-Red, which can just as easily be done on Home Assistant these days.
For everything else, Node-Red simply feeds the information via MQTT to Home Assistant. Home Assistant is where the dashboards, energy management UI, and even automation in many cases lives. It's all on an app and integrates with a 1000+ services devices.
There is even ESPHome (once again a Home Assistant project) code that could probably read these register values into Home Assistant with your existing hardware.
Node-Red might be somewhat more flexible for automations, but for everything else and 98.5% of automations you have Home Assistant. But I admit I might be biased, in the past I've built my own hardware - based on ATmegas and electric Imps ;-), UIs and eventually settled on HASS in 2016. Today it is one of the most active opensource projects out there, which obviously serves as some nice confirmation bias 😉  

Installed my Sunsynk inverter today and the first (and only) thing I miss is the realtime information and integration with my Home Assistant.  Looking at the inverter it would appear like it is has modbus communication available on the RS485 port. 
I have ordered a USB to RS485 receiver to see if I can decode the the communication.  Once decoded I want to create a stand alone ESP8266 which will receive and translate the Modbus and communicate it in realtime via MQTT.  

You need to change the device/ unit ID on the inverter to 1

You need to change the device/ unit ID on the inverter to 1

Awesome, that did it. Thank you.

For future posterity, it is the "Modbus SN" setting in the advanced menu. Will require a restart of the inverter to take effect,

Not that I know off directly from the monitoring side.  You could try a mix between using the forecast solar from solcast and then turning on a high draw appliance for a period with some node red logic

Not that I know off directly from the monitoring side.  You could try a mix between using the forecast solar from solcast and then turning on a high draw appliance for a period with some node red logic

See below screenshots from the Node Red Dashboard.  These flows are active as part of the flows shared.  On the Time mode screen you can select the time and days when the inverter should switch to limit to load only.  Make sure to press the buttons next to the timer to set these times.

Awesome,
Just an explanation on the other menus:
System Settings: Reads the settings that is currently applied on the inverter.  You can change settings and write it back to the inverter
Default Settings:  This save your default settings (typically used) to the local storage
LoadShedding Settings: This save a second set of settings (to be used when there is loadshedding) to the local storage.
The flow checks a website to see if loadshedding is currently active.  If not active it applies the "Default settings" to the inverter, if loadshedding is active then it applies the load shedding settings.  I use this flow to preserve the battery capacity during loadshedding times, our area used to be load shedded 4 hours at a time.
 

The neutral for your inverter must also be connected before the Earth Leakage otherwise the EL will trip when it notices an inbalance between the live and neutral. 
The neutral from your inverter output should go into a seperate neutral bar

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

Well done, it is looking good

For my Sunsynk5.5 Simple Local Monitoring and Graphing Solution I use a single RPi4 2gig + 1 terabyte external HDD + Official RPi4 Power-supply.
The comms between my RPi4 and the Sunsynk 5.5 inverter is done using the Sunsynk BMS RS485 port wired to a standard (RS485 to RS232 Converter) and then to a standard (RS232 to USB converter).
This comms setup gave me the most stable and fastest/reliable way to get the data from the Sunsynk.
You can still use your Solarman or Sunsynk dongle at the same time.
Credits
Shout out again to @Bloubul7 who has an awesome post going about using nodered and Sunsynk
That was the foundation for setting up my own dashboard running on a different platform for simple visualisation.
Note: This guide is not for noobs, you need at least good understanding of how to use a raspberry pi and install and run stuff on it from the command line.

After you have completed this setup guide, both Step 1 and Step 2, you will/should end up with a good starting point for Your Own Customisable Data Dashboard for your Sunsynk.



 
STEP 1
Assumptions
You already know how to install headless OS (RASPBERRY PI OS LITE (Legacy) Buster Lite works best) on your RPi4
You already know how to make sure you have configured your RPi4 so you can access the RPi4 using your wifi/ethernet and putty shell.
If the above has you confused then this guide may not be for you.
Ok, let's dive right in.
Do a fresh Install Of RASPBERRY PI OS LITE (Legacy) Buster
Now for the fun stuff.
Do not try taking shortcuts, do each line of command on its own one by one in the order posted below
Start with the following commands on your RPi4 shell.
sudo apt update sudo apt upgrade sudo apt -y install build-essential git nano wget Easy, that's the basic essentials out the way.
Now do the following:
sudo apt install openjdk-11-jdk Now check to see that it installed correctly:
java -version That should give you an output similar to this:
openjdk version "11.0.xx"
OpenJDK Runtime Environment (...)
OpenJDK 64-Bit Server VM (build ...)
Next we download thingsboard:
wget https://github.com/thingsboard/thingsboard/releases/download/v3.3.4.1/thingsboard-3.3.4.1.deb Now we install thingsboard:
sudo dpkg -i thingsboard-3.3.4.1.deb That was sooo easy
Next we install the database system to store all the data and run thingsboard on:
# import the repository signing key:
wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add - Now add the repository contents to your system:
RELEASE=$(lsb_release -cs) echo "deb http://apt.postgresql.org/pub/repos/apt/ ${RELEASE}"-pgdg main | sudo tee /etc/apt/sources.list.d/pgdg.list Now install and launch the postgresql service:
sudo apt update sudo apt -y install postgresql sudo service postgresql start Once PostgreSQL is installed you may want to create a new user or set the password for the the main user.
The instructions below will help to set the password for main postgresql user:
sudo su - postgres psql \password \q Then, press “Ctrl+D” to return to main user console and connect to the database to create thingsboard DB:
psql -U postgres -d postgres -h 127.0.0.1 -W CREATE DATABASE thingsboard; \q Now type the following command to get back to your root:
exit Now we can configure thingsboard:
sudo nano /etc/thingsboard/conf/thingsboard.conf Add the following lines to the the bottom of the configuration file.
Don’t forget to replace “PUT_YOUR_POSTGRESQL_PASSWORD_HERE” with your real postgres user password you created earlier.
Here you can copy all the code in one go and paste to the configuration file:
# DB Configuration export DATABASE_TS_TYPE=sql export SPRING_JPA_DATABASE_PLATFORM=org.hibernate.dialect.PostgreSQLDialect export SPRING_DRIVER_CLASS_NAME=org.postgresql.Driver export SPRING_DATASOURCE_URL=jdbc:postgresql://localhost:5432/thingsboard export SPRING_DATASOURCE_USERNAME=postgres export SPRING_DATASOURCE_PASSWORD=PUT_YOUR_POSTGRESQL_PASSWORD_HERE # Specify partitioning size for timestamp key-value storage. Allowed values: DAYS, MONTHS, YEARS, INDEFINITE. export SQL_POSTGRES_TS_KV_PARTITIONING=MONTHS # Update ThingsBoard memory usage and restrict it to 256MB in /etc/thingsboard/conf/thingsboard.conf export JAVA_OPTS="$JAVA_OPTS -Xms256M -Xmx256M" Ctrl x then choose yes to save the settings you pasted.
Once ThingsBoard service is installed and DB configuration is updated, you can now execute the following script:
# --loadDemo option will load demo data: users, devices, assets, rules, widgets.
sudo /usr/share/thingsboard/bin/install/install.sh --loadDemo Execute the following command to start ThingsBoard:
sudo service thingsboard start Perfecto, This is so easy up till now
Now let's move on to installing Nodered the easy and correct way.
Do not try cheating and using nodered install via raspberry, this way is the better way.
To Easily Install nodered run the following:
bash <(curl -sL https://raw.githubusercontent.com/node-red/linux-installers/master/deb/update-nodejs-and-nodered) NOTE: The script will ask you a couple of questions about whether you are sure you want to proceed, and whether to install Pi-specific nodes. Say “y” (yes) to both questions.
Node-RED can be extended by installing modules to give it extra features that we will need.
We need to do that now so that it can be ready for the flows we will be using later.
Some of these may already be installed, install all anyway one by one.
If you are prompted that it already exists simply continue to the next.
Use NPM to install the following nodes one at a time:
npm install node-red-contrib-batcher npm install node-red-contrib-buffer-parser npm install node-red-contrib-cycle npm install node-red-contrib-hcl-iterate-loop npm install node-red-contrib-influxdb npm install node-red-contrib-modbus npm install node-red-contrib-moment npm install node-red-contrib-play-audio npm install node-red-contrib-queue-gate npm install node-red-contrib-simple-gate npm install node-red-node-openweathermap npm install node-red-node-pi-gpio npm install node-red-node-ping npm install node-red-node-random npm install node-red-node-serialport npm install node-red-node-smooth Great another job well done
At this point Node-RED is installed, but you still need to configure it to be automatically started on boot:
sudo systemctl enable nodered.service You can start the service manually this time, but in future it will happen automatically when your Pi starts up:
sudo systemctl start nodered.service By now everything should be ready and waiting for you to start using
You will/should now be able to open the thingsboard Web UI on your pc/laptop using the following link (Replace With Your Network IP for Your RPi):
http://YOURPILOCALIPADDRESS:8080/ Default admin login info: System Administrator username: [email protected] System Administrator password: sysadmin You will/should now also be able to open the nodered Web UI on your pc/laptop using the following link (Replace With Your Network IP for Your RPi):
http://YOURPILOCALIPADDRESS:1880 If you do not know what the network IP is then use the following command on your Pi:
ifconfig That should show similar to this.
pi@yourpihostname:~ $ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.253  netmask 255.255.255.0  broadcast 192.168.120.255  - THE PART IN BOLD SHOULD BE WHERE YOUR IP SHOWS
        inet6 fe80::b44e:b3e5:8e66:fd02  prefixlen 64  scopeid 0x20<link>
        ether dc:a6:32:33:a2:82  txqueuelen 1000  (Ethernet)
        RX packets 26208  bytes 5851724 (5.5 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 17944  bytes 4846864 (4.6 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 451007  bytes 74785599 (71.3 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 451007  bytes 74785599 (71.3 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.2.5  netmask 255.255.255.0  broadcast 192.168.130.255  - THE PART IN BOLD SHOULD BE WHERE YOUR IP SHOWS
        inet6 fe80::966a:72cb:c7d4:c3c2  prefixlen 64  scopeid 0x20<link>
        ether dc:a6:32:33:a2:84  txqueuelen 1000  (Ethernet)
        RX packets 13381  bytes 4282322 (4.0 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 193  bytes 29382 (28.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
Coming Soon....
Setup Guide Step 2 (Adding Nodered Flows and Setting Up Your 1st Dashboard)

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,
Yes, reading the settings will retrieve the current settings from the inverter and populate the dashboard.  You can then make changes if you like and press write settings to push back the changes to the inverter.
Some explanation on the different dashboards:
System Settings - Provides you with the ability to read and write the live settings from the inverter Default Settings - This stores a set of default settings to the file system on Pi.  This was utilized to store my non-loadshedding settings.  These settings are automatically pushed to the inverter based on the loadshedding status Loadshedding Settings - This stores a set of loadshedding settings to the file system on Pi.  This was utilized to store my loadshedding settings.  These settings are automatically pushed to the inverter based on the loadshedding status Time Mode - I use the Time Mode to trigger feeding back into my non-essential loads on certain days of the week.  Due to my solar setup currently being undersized to power the entire house on days when my domestic worker (higher loads due to washing, tumble dryer, ironing etc) is here, this allows me to save some additional power on the alternate days by feeding back into the non-essentials. A note for everybody else, if you want to access the dashboards then go to the following address http://[your pi's IP]:1880/ui

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

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

@Bloubul7
Thank You, this is awesome work, I followed your guide to get direct data from my Sunsynk and I must say, IT FREAKING WORKS GREAT !!!
Next I will try your settings integration and then automate the heck out of my system.
I cannot believe all these years I did not use nodered, that is an awesome bit of kit.
No more need for crappy dongle data and guessing what the hell is actually going on inside

Mine has been set to indefinite and haven't had any issues.  Need to log in and check the database size just for interest sakes.
The JSON is attached hereto.  
Sorry I couldn't help more actively during your setup, work has been crazy for the past 6 months (can't moan during the current economic state).   One interesting new Node Red feature I have seen recently is a Whatsapp integration.  This could be quite useful to set up a couple of warning flows and have the system send you a Whatapp message should they be triggered. 
SunSynk-1617804388751.json