After doing some research we got our solar system in April 2023. We went with a company that was using AlphaESS equipment and one of the reasons for choosing that particular installer was their neat work – a neighbour of ours allowed us to have a look. Our system had to be neat since we were planning to install it in a customer facing area of our little family business.
After enjoying the free electricity during the summer I started to get curious. Being a bit old fashioned I was wondering if and how the system can be monitored and controlled without AlphaESS’s cloud backend. So in December 2023 I read a lot about Modbus RTU, Modbus TCP, ioBroker and Home Assistant (HA). After trying both ioBroker and HA I decided to go with HA – the more popular home automation solution. I installed a test system in a VirtualBox and was able to monitor the AlphaESS system shortly after. I ordered a HA Green straight away, knowing that this was something I’d like to run 24/7.
It didn’t take long until I added the logic to run a scheduled force discharge of the batteries at night (from 23:30-02:00) – just before re-charging the batteries again (from 02:00-06:00). This schedule is running since January 2024 now and hasn’t had a single hiccup.
At this stage I decided to write things down, both for my own documentation and also to share my learnings – so here we go…
Update: as of end of August 2024 my HA instance isn’t hosted on the HA Green anymore but in a Proxmox VM on a Beelink MINI S12 PRO.
Update: as of start of September 2024 the integration contains automations to prioritise grid feed-in over battery charging to reduce clipping and maximise feed-in.
Get the latest copy of integration_alpha_ess.yaml here:
https://projects.hillviewlodge.ie/_alphaess/integration_alpha_ess.yaml.
Also make sure to download a fresh copy of alphaess_view.yaml and power_diagram.yaml each time a new version of integration_alpha_ess.yaml has been released.
Note: I will post details about updates/enhancements in the official AlphaESS Facebook Group.
Useful AlphaESS reference documentation:
AlphaESS-ModbusRTU&TCP.pdf
AlphaESS-ModbusDispatchFunction.pdf
AlphaESS-ModbusProtocol.pdf
AlphaESS-HouseholdModbusRegisterMapTable.pdf
AlphaESS-HouseholdModbusRegisterParameterList.pdf
Disclaimer
Use the provided information at your own risk!
Be careful when making changes and double and triple check everything – writing inconsistent data into your AlphaESS Inverter’s Modbus registers might cause unexpected results which could damage your system!
I can’t offer official support but I’ll try to help if you need additional details, instructions or troubleshooting.
Tested on SMILE5, SMILE-G3-S5 and SMILE-Hi10 but according to AlphaESS’s documentation the register addresses and values are consistent through all supported models. Additionally is has been tested on some older models (using a Modbus RTU to Ethernet converter), which offers limited information/functionality due to its AC-coupled design.
Warning: local laws and regulations, particularly regarding grid feed-in limitations, might restrict the use of certain functionalities in this integration. It’s your responsibility to ensure your usage of this integration complies with all applicable rules and regulations.
Warning: avoid excessive write cycles of Modbus registers that are stored in the inverter’s flash memory since that will degrade the chip. The affected registers are the ones that store general system specific setting and survive system restarts, e.g. Charging and Discharging Periods and their Cutoff SoCs, PV Capacity, Max Feed to Grid percentage, Grid Safety settings, etc. The Dispatch Mode related registers are not affected, these are not stored in the flash memory.
Intended Audience
The intended audience for this guide are tech savvy persons, wanting to get more information out of their AlphaESS system without depending on AlphaESS’s cloud backend or persons, planning to access parts of the systems that cannot be accessed via App/WebUI.
Prerequisites
- Your Inverter must be connected via LAN port (not Wi-Fi). If wired network is not available you can use Powerline (€40) or a Wi-Fi Repeater with an Ethernet port (€20) to extend your network alternatively.
- Home Assistant release 2024.10 or newer.
- Basic TCP/IP knowledge: this includes an understanding of what an IP address is, the function and identification of ports, and methods for locating devices within a home network.
- Proficiency in setting up and modifying Home Assistant and YAML files: this involves skills in configuring Home Assistant and the ability to edit YAML files, which are often used for configuration settings.
- I am providing a preconfigured YAML file containing the majority of the AlphaESS system’s available information and some configuration options. If this doesn’t cover your specific use case you will either have to extend the file with the bits relevant to you yourself or contact me and I will assist in modifying the file.
- Understanding of electrical units: a fundamental grasp of key electrical concepts and units such as Kilowatts (kW), Kilowatt-hours (kWh), Watts (W), Volts (V) and Amperes (A).
Coding/programming skills are not required.
Does your AlphaESS Inverter have Modbus TCP?
Identify your Inverter’s IP address and check if port 502 is open. That indicates that Modbus TCP is enabled and listening. If the port is closed check if it can be enabled via the Inverter’s control panel or reach out to support to get it enabled (Remote configuration or firmware update).
Modbus TCP capable Inverters:
SMILE5, SMILE-Hi5, SMILE-Hi10, SMILE-G3-S3.6/B5/S5, essentially all G3 models.
If your Inverter doesn’t have Modbus TCP it might have Modbus RTU (RS485). In that case a converter can be used, there are Modbus RTU to USB (ca. €20, e.g. Waveshare USB to RS485 Converter) or, preferrable, Modbus RTU to Ethernet (ca. €50, e.g. Protoss PE11, USR-W610, Waveshare RS485 to RJ45 Ethernet Converter) converters available. I have limited experience with any of these converters therefore wouldn’t be able to provide much help.
Using a Modbus RTU to USB converter might require changes to the provided YAML file (see Appendix).
Modbus RTU capable Inverters:
SMILE-i3, SMILE-T10 and older models of SMILE5, SMILE-Hi5, SMILE-Hi10, SMILE-G3-S3.6/B5/S5.
Note: the list of inverters above was taken from official AlphaESS documentation but seems to be incomplete, esp. the Modbus TCP capable ones. While a specific model is not listed it might still support Modbus TCP, carrying out a port 502 check as described above might still return a positive result.
Note: prior to buying any dedicated Home Assistant (HA) hardware a virtual test environment can easily be configured using VirtualBox/VMware Workstation/Hyper-V on a PC or Laptop.
Feedback from some Modbus RTU to Ethernet converter users:
- SMILE-B3 with USR-W610: Read registers OK/Write registers limited
- SMILE-B3 with Protoss PE11: Read registers OK/Write registers OK
- SMILE-B3-PLUS with Protoss PE11: Read registers OK/Write registers OK
- SMILE5 (AL200) with Protoss PE11: Read registers OK/Write registers not OK (extremely slow, not usable)
- SMILE5 (AL500) with Waveshare RS485 to RJ45 Ethernet Converter: Read registers OK/Write registers OK-ish (slow, potentially causing timing issues when trying to use Excess Export)
Setup
The following instructions apply to Modbus TCP enabled Inverters only:
- Make sure your Inverter is connected via LAN port (not Wi-Fi).
- Change your Inverter’s network configuration and assign a static IP Address. Assign an IP Address that’s outside of your main router’s DHCP range to avoid conflicts in the future. Configuring DHCP Reservations on your router can be used alternatively.
- Get a HA instance installed, either in a virtual test environment or a HA device.
- Install “Samba share” under “Settings/Add-ons/Add-on Store” and configure username and password.
- From a computer connect to the HA instance (\\homeassistant) and use the Samba credentials.
- Place a copy of integration_alpha_ess.yaml in \\homeassistant\config\packages (create \packages if required).
- SMILE-B3 & SMILE-B3-PLUS users: edit \\homeassistant\config\packages\integration_alpha_ess.yaml, search for SMILE-B3/SMILE-B3-PLUS (13 occurrences) and adjust according to the comment.
- Edit \\homeassistant\config\configuration.yaml and append:
homeassistant: packages: !include_dir_named packages
- Edit \\homeassistant\config\secrets.yaml and append (without quotes):
alphaess_modbus_host_ip: "your Inverter’s IP Address" alphaess_modbus_host_port: 502 alphaess_modbus_slaveId: 85 - Perform a restart of your HA.
- Get the latest copy of alphaess_view.yaml here:
https://projects.hillviewlodge.ie/_alphaess/alphaess_view.yaml - In HA’s Overview select “Edit Dashboard/Add view/⋮/Edit in YAML” and copy in the content of alphaess_view.yaml. Click “Save”.
Note: on a fresh HA installation you might be missing the “Add view” option (a “+” sign). In that case select “Edit Dashboard/⋮/Take control”, check “Start with an empty dashboard”, then click “Take control”.
Configuration
Currently the only required configuration option is selecting your Inverter’s AC Limit. This setting will adjust the range of the Force Charging/Force Discharging/Dispatch Power sliders and is also required for the Excess Export automation to function properly.
Make sure to select the correct value for your inverter:
Force Charging/Force Discharging/Dispatch
Warning: the Force Charging/Force Discharging/Dispatch automations do not honor the configured grid feed-in limitation (Max Feed to Grid). Local laws and regulations might restrict the use of these automations in your country.
Dispatch Mode details and potential use cases:
- Battery only Charges from PV (1)
Behaviour: the battery charges from PV Output only, with the set max. amount of Power.
Required: Duration/Power
Details/Use cases:
This mode can be used to throttle charge the battery from PV Output. Power must have a negative value, positive Power values have no effect. The battery does not discharge/serve house loads in this mode. Excess PV Output will be fed to the grid. - State of Charge Control (2)
Behaviour:- Power > 0W (positive) & Cutoff SoC < Battery SoC: the battery discharges with the set amount of Power until Cutoff SoC is reached. The discharged power will go to the house loads and any excess will be exported to the grid. If available, PV Output will contribute.
- Power < 0W (negative) & Cutoff SoC > Battery SoC: the battery charges from the grid with the set amount of Power until Cutoff SoC is reached. If available, PV Output will contribute.
Required: Duration/Power/Cutoff SoC
Details/Use cases:
This mode can be used for any type of charging or discharging, it’s the mode that the Force Charging and Force Discharging automations in the Charging card facilitate. It’s also the mode that Excess Export facilitates. - Load Following (3)
Behaviour: default behaviour with a throttled battery charge/discharge rate.
Required parameters: Duration/Power
Details/Use cases:
This mode is the same as the default behaviour but limits the battery charge/discharge rate to the set Power. Power is set as an absolute value, the prefix (+/-) is being ignored.PV Output exceeding the set Power plus the house load will be capped, once the battery is fully charged the PV Output will be capped at the house load – following the load.The mode seems to be identical to Normal Mode (5). - Maximise Output (4)
Behaviour: grid feed-in is maximised.
Required parameters: Duration
Details/Use cases:
The system will maximise grid feed-in by discharging the battery. If available, PV Output will contribute. - Normal Mode (5)
Behaviour: The mode seems to be identical to Load Following (3).
Required parameters: Duration/Power
Details/Use cases: see Load Following (3). - Optimise Consumption (6)
Behaviour: battery force charges at full power.
Required parameters: Duration
Details/Use cases:
This mode maximises grid consumption, the house load will be served by the grid and the battery will start charging from the grid, while the PV Output is contributing. - Maximise Consumption (7)
Behaviour: PV Output is disabled & battery force charges at full power.
Required parameters: Duration
Details/Use cases:
In some countries electricity providers pay for using from the grid (negative prices). This mode essentially disables the solar panels and maximises grid consumption, the house load will be served by the grid and the battery will start charging from the grid, while the PV Output is throttled to zero. - No Battery Charge (19)*
Behaviour: battery charging is disabled.
Required parameters: Duration
Details/Use cases:
This mode disables charging the battery, while it’s still able to serve house loads. This mode in combination with Max Feed to Grid equals 0% can be used to eliminate grid feed-in while limiting the battery charging (to reduce battery cycles).
* Dispatch Mode 19 is not available on some older inverter models.
Excess Export (Feed-in Prioritisation)
Warning: the Excess Export automation does not honor the configured grid feed-in limitation (Max Feed to Grid). Local laws and regulations might restrict the use of this automation in your country.
Enabling “Excess Export” will change the inverter’s load serving priority, the default being the sequence: House Load > Charge Battery > Export to Grid. Once enabled the inverter will prioritise feed-in, the sequence will be: House Load > Export to Grid > Charge Battery.
Use cases:
- Clipping reduction/elimination
- Grid feed-in maximisation (for countries with grid feed-in payments higher than consumption tariffs)
Positive side effect: potentially less battery cycles.
What is “clipping”?
Below is a visualisation of clipping and the effect of the “Excess Export” automation. Clipping occurs in oversized systems, where the panels could generate more energy if the inverter had the ability to send it somewhere.
The first diagram (May 15) shows that around 7:00 a.m., solar production exceeds the house load, and the battery begins to charge. Around 12:30 p.m., the battery is full, and solar production is throttled back because the inverter (here, a G3-S5) can only handle 5 kW AC. The same effect also occurs with larger inverters, then, for example, starting at 10 kW.
In the second diagram (May 16), “Excess Export” is active. Starting at 7:00 AM, any excess power is fed into the grid, resulting in delayed battery charging. At 10:00/10:30 AM the solar production exceeds the AC amount the inverter can handle – anything above that is sent to the battery. The battery never reached 100% SOC on that day, so no energy was lost through clipping.
On both days, the starting SOC was 50% and the solar production was practically identical. The additional yield by preventing clipping is significant, on good days, my system achieves over 20%. The potential additional yield depends on the specific system: inverter model, oversizing, battery size. The “Excess Export” mode also helps to extend battery life, as the battery isn’t charged to 100% every day.
Note: If you are planning to use this automation and your inverter has a different rating, make sure to select the correct value for your inverter:
Power Diagram (optional)
Get the latest copy of power_diagram.yaml here:
https://projects.hillviewlodge.ie/_alphaess/power_diagram.yaml.
These also an extended version available here (adding additional charts):
https://projects.hillviewlodge.ie/_alphaess/power_diagram_extended.yaml.
As a prerequisite for the Power Diagram download the current apexcharts-card.js from https://github.com/RomRider/apexcharts-card/releases/latest and place the file in the folder \\homeassistant\config\www.
In HA’s Overview select “Edit Dashboard/⋮/Manage Resources/Add Resource” setting URL to “/local/apexcharts-card.js” and selecting “JavaScript Module” as the “Resource type”.
Restart HA.
In HA’s Overview select “Edit Dashboard/⋮/Manage dashboards/Add Dashboard”, pick “New dashboard from scratch”. Apply a random “Title” (random since the final title is configured in power_diagram.yaml) and click “Create”. Click “Open” on the right, then “
/⋮/Raw configuration editor”. Select the default content and replace it with the content of power_diagram.yaml. Click “Save”.
Credits for the Power Diagram go to Daniel Young and his brilliant work on the Alpha2MQTT integration (https://github.com/dxoverdy/Alpha2MQTT).
Note: if you decided to change entity names in the provided integration_alpha_ess.yaml file you will have to adjust these in the power_diagram.yaml accordingly.
Appendix
Potentially required YAML modifications for a Modbus RTU to USB converter (where /dev/ttyUSB0 is depending on your individual HA hardware):
Change:
modbus:
- name: modbuspvsystem
type: tcp
host: !secret alphaess_modbus_host_ip
port: !secret alphaess_modbus_host_port
message_wait_milliseconds: 10 # Waittime between 2 messages
timeout: 10 # Timeout in seconds before connection is closed
delay: 1 # Delay in seconds at startupTo:
modbus:
- name: modbuspvsystem
type: serial
port: /dev/ttyUSB0 #USB FTDI device connected to the Inverter’s CAN/RS485 Modbus port
baudrate: 9600
bytesize: 8
method: rtu
parity: N
stopbits: 1
message_wait_milliseconds: 10 # Waittime between 2 messages
timeout: 10 # Timeout in seconds before connection is closed
delay: 1 # Delay in seconds at startup
Axel.
One thing that’s not explained is changing the sensor names to match your own sensors in the Daily power diagram. My entities had different names. Other than that the Power diagram works great. My ideal goal is to curtail my solar feed in when my wholesaler (Amber) turns negative. Im looking to curtail feed in but power the house load and charge the battery.
Love your work
Good point, Glenn. Thanks for the feedback 🙂 I’ve added the missing information now.
I have an Alpha ESS Storion-SMILE-T10, I managed to get the ModBus communication working. But when I want to modify the registers, the device does not respond to the command and ends with a timeout.
Am I doing something wrong or do I need to enable the write somewhere first?
Reading:
send: 0x55 0x3 0x8 0x50 0x0 0x1 0x8b 0xaf
recv: 0x55 0x3 0x2 0x0 0x6e 0x8 0x64
Saves:
send: 0x55 0x6 0x8 0x50 0x0 0xd2 0x6 0x32
Thank you for your help
Hiya Frenky, from what I can see this question isn’t about using my integration but some generic form of reading/writing Modbus registers. I am not aware of any writing restrictions that have to be disabled. The only thing I do know is that initiating some processes on the AlphaESS might require the commands to be sent in the correct sequence – for example when initiating a Dispatch/Force Discharge (Dispatch Mode has to be the last command) . What are you actually trying to do?
I learned today from ESS support that Storion-SMILE-T10 has only the possibility of reading via ModBus (changing values – writing is not possible).
😞
Is there a way to prevent the Alpha from charging via grid at all?
Background: If you do have a secondary plant, another battery or anything that is capable of feeding energy into the grid, chances are that the Alpha is sucking this up because of the super conservative settings.
Hi Thoralf, unfortunately I’m not aware of a method to prevent that. I also don’t have a way of testing anything like that.
Any chances to integrate that into Github / HACS Repo? I would love to have it additionally to the cloud version or even better, have both options in one repo. I created an issue here (https://github.com/CharlesGillanders/homeassistant-alphaESS/issues/119), but Charles seems not to have modus to test it.
Hi Marius,
I currently don’t have any plans to publish on GitHub (for several reasons) and I don’t have the slightest clue about how to create HACS Repos – but there is no need for either. My integration shouldn’t have any issues coexisting with Charles’s integration.
Cheers,
Axel
Finally Installed your Integration in HA today.
Love it. Ive been wanting a level of control over my Alpha System for ages.
One thing i found is if i make a change in the integration. It reflects correctly in the Alpha APP. But if i make a change in the Alpha APP, it doesn’t .
Is there any auto refresh that syncs command from the app to show correctly in HA. or is this because commands in the APP are based on API commands.
Hey Glenn, great to hear that you love it 😉
I didn’t notice that issue and I ran a quick test a minute ago: I changed the “Discharging Cutoff SOC” in the WebUI and also in the App – both updated fine in the HA integration after seconds. Which particular values were you testing with?
Hello, first of all, thank you very much for the great work.
I have had the integration running for a few days now and I’m very satisfied. Previously, I was using the original Schnitzelweck92 variant.
For my understanding, I wanted to ask whether the Excess_Export automations relate to the approach discussed here: https://www.storion4you.de/thread/903-ladezeit-einstellen-mit-nur-pv/?pageNo=3 regarding saving or reducing unnecessary grid power consumption in the morning and evening when there is little solar energy available? Or does it pursue a different approach?
thank you!
Hi Wolfgang,
thank you very much 😉 You are right, the topic discussed there is related – what I’m trying to achieve is this: here in Ireland we are getting well paid for feeding into the grid. So I am using that functionality to maximise export by pushing out the batteries being full to as late as possible. That way I can reduce or even eliminate clipping.
The same logic can also be used to reduce or eliminate the unnecessary grid consumption during dusk and dawn – I just didn’t implement that because I don’t have a use case for that.
PS: I’ve made some minor changes to the YAML today, so I’d recommend using the new version.
PPS: I’m actually SaaX on the Storion4you forum 😉 Feel free to contact me via Email and I’ll be able to respond in German.
Cheers,
Axel
This is really great. Thanks!
I’m curious if you can give me any greater insight into the details of the different dispatch modes. I did read the Alpha doc and it gives only very high level descriptions which don’t seem to be enough detail.
– Modes 1, 2, & 3 seem pretty clear.
– For mode 4, will it charge the battery if there is excess PV? Or will excess PV go to the grid?
– Why is the description of mode 5 the same as mode 3? Are these really identical?
– in mode 7, what happens to PV.
What I want is to stop charging at less than 100% to extend battery life. I want to use PV as much as possible to reach this threshold, but if PV can’t get there before my rates increase, then I’ll use grid power to get there. For me, 00:00 – 15:00 is cheap from the grid and 15:00-24:00 is expensive. I can use mode 1 to normally get to this threshold before 15:00. I monitor the SOC and if it reaches my threshold before 15:00, then I switch to SOC control (mode 2) with a dispatch SOC value so the Alpha doesn’t exceed my threshold, and all my excess PV goes to the grid. I’ll also switch to mode 2 a bit before 15:00 so that I’m sure my batteries are topped up to my threshold. But once I get to 15:00, I don’t know what mode and parameters to use. Mode 3 (load follow) is basically what I want, but when there is excess PV (which there usually is) then it continues charging the battery to 100% which I don’t want. Unfortunately the Dispatch SOC value is only used by mode 2 and not by other modes. I want a mode where PV powers the house loads, excess PV gets pushed to the grid, if there is not enough PV then the battery will power house loads, BUT the battery won’t be charged.
Any thoughts??
Hi David,
unfortunately I have not looked into any of the other dispatch modes since 2 does everything I needed. So I don’t know how or if you can achieve what you’re looking for.
Regarding mode 5 I have found this information (translated from German): The function limits the performance of the battery when charging and discharging to the values set in registers 0881H/0882H. Otherwise charging/discharging takes place automatically. (Source: https://www.storion4you.de/thread/903-ladezeit-einstellen-mit-nur-pv/?postID=14452)
Maybe the guys on that forum have an idea, worth a try…
Cheers and good luck,
Axel
Thanks for the response. And I’ll definitely look at that link you sent for mode 5.
Of course, just like Murphy’s Law, as soon as I posted my question above, I came up with an idea. I just tested it out this morning and I am now able to achieve what I want using modes 1, 2, & 3. The key was just what you mention. I needed to also set the Dispatch_Active_Power registers (881/882). Those work with modes 1, 2, & 3 also. Voila!!
Now I want to learn more about modes 5, 6, & 7.
Hey David,
that’s great news, glad it’s working for you. I’d love to fully understand what you are doing and how, maybe something I should add to my YAML? If you don’t mind we could move that conversation to Email 😉
Cheers,
Axel
Hello Axel, I don’t think that you produce or consume 200.000 kWh ( = 200MWh ) per day ( see the “Today”s entries in your picture ). There seems to be a miscalculation in your ( and my ) configuration with kWh.
Ciao.
Sirko
Hey Sirko,
are you saying you don’t trust me? 🤣
Yeah, that’s messed up – but the calculation is actually fine. It’s the cloud update that has messed this up and it will solve itself eventually. The root cause is that the “Today” entries are calculated from the “Total” values – and some of these jumped to “zero” (or “unavailable”) and back multiple times over the weekend.
Nothing to worry about – I’ll take a new screenshot soon anyway, once I’ve finished testing some new functionality.
Cheers,
Axel
Hi Axel, “don’t trust” is the wrong wording. It would be more correct to say that I would be annoyed because I can’t achieve such values with my PV system. 90kWh was my highest daily production so far 😉
One more question about the diagram: With “legend_value: true” I can also display the current value for PV production in the legend. Can I also somehow put the daily total (i.e. a completely different value) behind it? “5.6kW / 25.3kWh”
Thanks.
Sirko
Sirko,
that is a very good question and I have no clue. I’m not exactly an experienced HA user and have even less knowledge about ApexCharts. You might find an answer or help on GitHub: https://github.com/RomRider/apexcharts-card.
If you can find some configuration options for the chart that might be useful for others let me know and I will add it to my template.
Feel free to contact me directly via mail 😉
Cheers,
Axel
This has been a lifesaver, especially given the recent API issues at Alpha – switched over easily, thank you!
Hi Reece, thanks 😉 I’ll be releasing a new version soon but am delayed with testing because of the ongoing backend issues.
You made my day Axel, I got the modbus working on my Smile5 using a PE11 RS485-UTP module thanks to your yaml files.
But I’m stuck on adding extra sensors. How do I convert eg the hex address 001AH (26 decimal) from the AlphaESS register catalog to your ‘1052’ value in your yaml? I want to add Total PV Power (I have an extra PV meter for second old PV installation), and think I can do with address 052DH (Total PV power).
Might be stupid data conversion question, but I’ve got no clue where to look.
Regards, Tom (KermtStroomt).
Hey Tom, that’s great to hear 😉
Yes, you can use any Hex to Dec converter, I’m using this one: https://www.rapidtables.com/convert/number/hex-to-decimal.html. So, 052DH would be 1325 decimal. I’m not sure about your “1052” example, that is 041CH (Inverter Grid Frequency), not 001AH (Frequent(Grid)). I’m also confused about 052DH, I don’t see that register in my AlphaESS-ModbusRegisterParameterList.pdf. Shout, if I can help, preferrable via projects@hillviewlodge.ie.
I am delighted to hear that the PE11 is working for you and would love to hear details on how to set this up. I have the same device here, unused in a drawer. When I started looking into Modbus end of last year I thought I needed one, before actually realising that my inverter supported Modbus TCP.
Cheers,
Axel
Hi Axel,
great work and result. Pefectly structured code and documentation is first class. Although I had to rewrite some automations that were based on the AlphaEss Cloud integration I am now fully independent when the Cloud API is not working like last week for about 6 days.
A big thank you for this. One question I still have to you: It seems you have implemented almost every useful field from the Modubus Doc from Alpha inluding charging switches and charging times, why did you not include the same set of fields for discharging. Maybe I did not find them in either the code or the dashboard ?
Thanks again and best regards
Juergen
Hi Juergen,
thank you very much, glad you like it 😉
Regarding the Discharging Setting: I didn’t add the setting (yet) because I actually never use them and I never had anyone ask for them before. Is that something that would be of use to you? I wouldn’t mind adding them, esp. after the recent mess with the cloud and me toying with the idea to block the inverter from Internet access all together.
Cheers,
Axel
Hi Axel,
Ja die Parameter für discharging wären sehr nützlich. Ich habe es selbst mal versucht, bin aber nicht erfolgreich gewesen.
Gruß
Jürgen
Hi Juergen,
let’s use mail (projects@hillviewlodge.ie) for the conversation in German – if you don’t mind 😉
Thanks,
Axel
Is there any way to calculate the power used by the non essential side of the inverter it’s a smile 5.
Thank you
Hi Pieter,
I’m not sure I understand what you mean – what is the “non essential side”?
Cheers,
Axel
We have the gyser and oven/stove connected between the inverter and the grid ct (we are not allowed to feed solar back to the grid) the CT is to stop feeding to the grid. But the inverter can still supply solar to the non essential side in my case the gyser and oven/stove.
I’m trying to figure out what the difference between “Inverter_Power_Total” and “Inverter_Backup_Power_Total”
Hi Pieter,
I’ll send you an email in a minute.
Cheers,
Axel
Hi Axel,
first of all THANK YOU a lot for this work and Project. You have saved me much time to get this working on my own :). One question – have you managed to calculate the “total income”? I get mad of this. I’m pretty shure my values are incorrect . 🙁
Hi Christoph,
thanks, glad it’s working for you. I haven’t looked into anything “profit” related, not sure if I will bother – but I’m happy to help if I can. If you’d like to continue the conversation in German I’d prefer if we could use email via projects@hillviewlodge.ie.
Cheers,
Axel
Thanks for this, it’s a great help since AlphaESS messed up the existing integration I’ve been using with their recent update. It’s taken me a long time to get this working on a Smile5 AL5002 without TCP, turns out my system has been set from the factory with a baudrate of 115200 not 9600 that I’ve been using to try make this work, I also connected pin3 (white/green) to the RS485 ground connection which has improved the signal on my system.
There’s a small mistake in your serial/RTU config example, the parity needs to be set with a capital N not lower case or it throws up an error in Home Assistant.
Hey Dan,
thank you very much for that feedback, I will update the website asap. If you don’t mind: which adapter are you using – just for my records?
I also have a contact in Australia who’s just in the process of connecting a Protoss PE11 (RTU > TCP), so I’m hoping to be able to add information about that adapter soon.
Cheers,
Axel
Hi Axel,
It’s the Waveshare USB/RS485 (https://thepihut.com/products/usb-to-2-channel-rs485-industrial-grade-isolated-converter), I’ll be switching to RS485 to ethernet now that I have it working on the USB version, I bought both while trying to get this to work but I accidently fried the Ethernet module in the process so I’ll need to buy another. I’ll report back if I get it working in case it helps anyone else out, I found some posts online with people struggling to get Modbus working on the early hardware version Smile5’s so it might simply be the different Baud rate causing the issue. I was experimenting with Alpha2MQTT which tries a selection of Baud rates automatically which is also how I found out about the ground connection on pin3, it didn’t work at all until I connected that.
Hi Dan,
thanks for these details, might be handy for others. You’re not planning to use the Protoss by any chance? I have one myself, ordered it before realising that my SMILE5 had Modbus TCP… Lesson learnt 😉
Cheers,
Axel
Hi Axel,
Thank you so much for the wonderful work you do and sharing your knowledge. I bought a HA Green and followed Charles’ instruction to integrate with my AlphaESS SMILE-G3-B5-INV. What I’m trying to do now is to force discharge my excess energy during the evening peak hours. However, my battery is connected to my home router using WiFi and your first prerequisite says it must connect via a LAN port. I have forced discharged my battery previously using my electricity providers (Amber) app but I’m trying to do this independently via HA. Do I need to figure out how to connect my battery via a LAN port first before I do anything? Has anyone else got this working using Wifi?
Thanks,
Mamoon
Hi Mamoon,
I might not have explained that very well I’m afraid: Modbus TCP does work via Wi-Fi, it’s just the AlphaESS Wi-Fi Stick that doesn’t work support that. So if you can’t run a LAN cable you can alternatively use either PowerLAN or a cheap Wi-Fi repeater with LAN port (like the TP-Link TL-WA850RE, very cheap and my preferred option). You can then connect the inverter via LAN port to the repeater and you’re sorted.
Hopefully that’ll help you sorting this bit, if you need any additional information fee free to ping me directly via projects@hillviewlodge.ie.
Cheers,
Axel
Thanks Axel. I’ve ordered one, will let you know how it goes.
Hi Axel, fantastic work!
I am currently using alpha2mqtt, which is working fine, so I know I can read/write to my smile5 ok. My only issue with it is node red which I don’t use for anything else, and really don’t want to learn.
Sadly my smile5 does not support TCP, so I have got a Waveshare RS485 to POE ETH to try.
All is working fine, I can see all the data in HA, except none of the write commands work, which I’m guessing is a setting in the Waveshare that I’ve got wrong.
I appreciate that you don’t have this unit, but am wondering if anyone else has got it working ok and can help with settings?
Hi John, thank you 😉
Just to clarify: you’re not using my integration to write, but Node Red? I’m asking because I did make some changes in relation to how I’m writing values, these changes were required for Modbus RTU users. It has to do with the two methods to write to registers, “Write Single Register” and “Write Data Register”. Daniel of Aplha2MQTT mentions these methods to and I have switched to “Write Data Register” because it’s working for both Modbus TCP and Modbus RTU. I have a contact who’s in the middle of connecting his system via the Protoss PE11, should be pretty similar to the Waveshare converter.
Feel free to contact me directly via projects@hillviewlodge.ie, easier than using the commenting functionality 😉
Cheers,
Axel
In the meantime I managed to install the package and I am using it on a daily basis, but only the monitoring part.
I am looking for some kind of documentation what the respective sensors and especially the buttons/input entities do.
I did scroll through the ModBus documentation but did not manage to really get behind which is what.
Is there some documentation how to use the entities (functionality of “charging/discharging setting”, the time slots, “excess export” “excess export pause”, throttle/load buttons) and the correlation/dependencies between them?
Hi Marius,
feel free to reach out via email (projects@hillviewlodge.ie) and I will try to explain some of these settings and automations. You won’t find anything about that stuff in the AlphaESS or Modbus documentation, because I created them.
I thought most would be self explaining (since they’re replication the AlphaESS App/WebUI functionality – like “Charging / Discharging Setting” and the corresponding time slots.
“Excess Export” (and “Excess Export Pause” – which is just a helper and is not to be used by users) is probably not relevant for German users, afaik you guys don’t get paid a lot for feeding into the grid. Details can be found on my website:
Enabling “Excess Export” will change the inverter’s load serving priority, the default being the sequence: House Load > Charge Battery > Export to Grid. Once enabled the inverter will prioritise feed-in, the sequence will be: House Load > Export to Grid > Charge Battery.
Throttle Charge – as the name says – charges the batteries from the grid at a throttled rate, in my YAML at 2kW instead of the the full 5kW.
Cheers,
Axel
Hi Axel,
I just want to share with the community that I got Modbus working on my AlphaESS SMILE-G3-B5-INV but I couldn’t have done it without you. Thank you so much for all your support and guidance over the last 2 weeks. You are incredibly knowledgeable and very patient when it comes to dealing with novices like me.
I’m truly grateful.
Cheers,
Mamoon
Hey Mamoon,
thanks for your kind words – I’m delighted that it’s working for you 😉
Cheers,
Axel
Hi.
I am using already for some time forced charging in same way as you do but despite setting 100% SOC inverter stops actually on 99.2% always. Have you experienced the same or your one is fully charging to 100%?
Also I found out that if battery is charged sooner (SOC reached) than set charge time elapsed, then inverter stays in this charging mode and prevents consuming loads from battery.
Hi Zdenek,
yes, I have heard from others that the system might not charge up to 100%. I never saw that happening on my SMILE5, it always charged to 100% without problems. I have recently swapped to a SMILE-G3-S5 with more battery capacity and I’m only charging 70% now to reduce/eliminate clipping. The guys that reported the problem you are seeing seem to have “fixed” this by setting register 2182 to a higher value than 250 (which is 100%). They said it was working fine once setting the register to 251. Maybe worth a try if it bothers you 😉
I’m also aware of the fact that the system stays in charging mode until the set time is elapsed – that’s bad design but it’s fine for me: since I’m charging at the cheapest night rate I actually prefer that the system stays in charge mode. That way the house loads are served by the cheap night rate until the time is elapsed and it’s not using the battery.
What’s far worse is that it does the same when force discharging. I’m force discharging down to 20% SoC at night, before my cheap rate starts. If 20% is reached before the time’s elapsed the house loads are served by the grid – and that is at the expensive rate, because the cheap rate hasn’t started yet. I’m avoiding that by using a “helper” automation that monitors the SoC and stops the dispatch mode once 20% is reached.
Cheers,
Axel
Hi Axel. Thanks for the huge amount of work you have done on this, over one year. I was impressed by the huge list of versions at the head of the .yaml, and that there were even some comments in it! 🙂
I must be getting a little too old for this stuff now, because I couldn’t work out how to change the view?
I click the Overview’s pencil to edit, it brings up an “Edit Dashboard” dialog,
but it only lists stuff about areas and hiding energy. Nothing about adding a view.
P.S. Some of the version strings seem to be parsed incorrectly. e.g.:
BMS Version 1,114 (instead of V11.14)
EMS Version Normalised Vunknown.unknown.unknown (instead of V0.11.07T)
______________________________________
Nigel, Sydney, Australia.
HAcore 2024.11.1, AlphaESS SMILE5
Hi Nigel,
thank you very much – I know that feeling of getting too old for all this 😂
I’ll respond via email if you don’t mind.
Cheers,
Axel
Hi Axel
I came across this while trying to find something for my smile-b5, it’s working great for the most part! Thanks.
However, I’ve noticed that the majority of the values are incorrect for systems that have a seperate solar system (I got my battery installed seperately from the solar system).
So values like all the PV inputs are 0, the house load is not calculated correctly and feed in is a negative number.
Is there any quick config changes I can make to correct this?
Hi Evie,
yes, some things are different for AC-couple systems, some information doesn’t exist and some can be found in different places. Also some values are off by factor 10. For these open my integration_alpha_ess.yaml and search for “B3”, you will find 6 occurrences with alternative multipliers in the comment.
The PV input per string can’t be read on AC-coupled systems, but the combined output is available, see Active Power PV Meter (sensor.alphaess_active_power_pv_meter) in the “Other” card. I’ve also added two additional sensors (AlphaESS_Total_Energy_From_PV_Meter & alphaess_todays_energy_from_pv_meter), you’ll have to add them manually to your view.
Hope this is helpful, feel free to contact me directly via projects@hillviewlodge,ie.
Cheers,
Axel
Hey Axel,
first of all thank you big time for your amazing work. I stumbled upon it when AlphaESS cloud was offline for a few days during last fall.
Recently they changed the battery grid charging / discharging UI in the official website and app to support more than 2 time windows each incl. cutoff SoC. I feel like the old registers for these values don´t work anymore but of course there is no newmodbus documentation from AlphaEss. Do you know anything about it?
Regards
Ron
Hey Ron,
thank you very much <3 I did notice a significant increase of queries during and after the cloud mess. I was starting to worry that it might be too time consuming but thankfully it has calmed down a bit ;)
I did indeed notice the new charging/discharging functionality and the additional time periods but I can confirm that the old Modbus registers are still working - at least for me. I haven't received any reports about them not working - but then I believe that only newer models have received the new functionality and old systems didn't. I can see that my old system (SMILE5 Gen2) still shows only 2 charging periods while my new G3-S5 shows the option for 6. I am still using the 2 Modbus periods register sets (since I've automated charging depending on solar forecast), all new periods in my App/WebUI are disabled.
Besides that I'm assuming that the new charging periods are stored in the cloud only and not locally on the inverter anymore (which could be easily tested by disconnecting the system from the Internet over night). Regarding any updated Modbus documentation: I was told that the AlphaESS guy who was tasked with Modbus enhancements and documentation has left the company and that that was the end of it - for now :(
Feel free to contact me directly via projects@hillviewlodge.ie – you can even contact me in German, according to your IP you’re located not too far from my hometown 😉
Cheers,
Axel
Excellent integration. Installation was straight forward and works perfectly since couple of weeks. Now I tried to add myPV ELWA2 AC to my setup and run into trouble connecting the new device to my AlphaESS Smile Inverter. Solution: Using the HA Modbus-Proxy allowed me to connect both HA-AlphaESS integration and myPV ELWA2. Perhaps this tip will help others as well.
Regards – Raffael
Hi Raffael,
thank you for the positive feedback 😉
Cheers,
Axel
Hi Axel,
I really appreciate your implementation and it works soo good, thanks for all that.
My plan is to use the whole system offline and I will use your modbus integration within Home Assistant to grab data from the inverter. Works perfectly! <3
Currently I'm facing an issue and I don't know if you can handle this via modbus as well:
I also own an AlphaESS EV Wallbox (EVC11) and it seems that this stupid wallbox is connected directly via LAN to the converter and can only work with internet connection.
I have to use the APP to change the settings of the wallbox (charge mode, start / stop). Obvoiusly the connection to the wallbox fails once I put the system offline and it seems that I cannot change the settings there.
I guess the communication between the inverter and the wallbox is the problem and I'm not sure how to use the wallbox wihtout internet.
Do you have any experience with this setup or any idea how to use the system completely offline?
I also spent time to use EVCC but my Wallbox refuses connections from "external" sources. It only accepts commands from AlphaESS inverter. I got intouch with AlphaESS and they told me that this behaviour is by design.
So long story short: is there any possibility to use modbus to have a basic control over the wallbox as well?
Thanks and best greetings from Germany,
Martin
Hi Martin,
great to hear that it’s working well for you 😉
Unfortunately I don’t have any experience with the EVC11 – thankfully I don’t have an AlphaESS EV charger (mine is a myenergi zappi). You might be able to find additional details about EVC11 offline control on the German AlphaESS forum (https://www.storion4you.de/), it seems like that charger is pretty popular in Germany.
Another thing: check your warranty conditions regarding taking the system offline for extended periods: I recently swapped from a SMILE5 Gen2 to a G3-S5, the G3 series comes with a 10 year warranty but it reduces to 3 years if not connected to their cloud for some time.
Cheers,
Axel
PS: feel free to contact me directly – even in German – via projects@hillviewlodge.ie 😉
5 minutes install … after I figured this out:
Our SMILE-T10-HV-INV was delivered today – event the solar panels are not yet on the roof I of course started to set up this integration. I struggeled because I have another modbus client – a lambda WP that is already controled via modbus from HA.
I figured I if I copy both yaml files together below one modbus tag it worked. After that it took 5 minutes to setup.
I am really impressed by the detailed integration. Really nice!
Maybe this helps someone along the way.
Thanks Christian, glad you like it 😉
Cheers,
Axel
To me it looks like the battery load value in the Daily Power Diagram is always showing doubled numbers. In your example screenshot as well as in my HA setup it has 9 or 10 kW at 100% even though the AlphaESS app displays a value of 4.5-5 kW with which the battery gets loaded. Maybe I have the wrong understanding, but to me this looks like a bug. What do you think?
I believe you’re mixing up two different things: the battery chart in the Daily Power Diagram is displayed in percent (the scale from 0% to 100% on the right side of the diagram) and not in kW. It’s doing exactly the same in the AlphaESS Power Diagram in both App and WebUI.
Depends 😉 To me it looks like the AlphaESS app addresses both scales at once – battery percentage (right) and its loading/unloading in kW (left). I checked the kW today 1-1 against the diagram and it sounds correct besides the percentage value.
Hey! First off, huge thanks for the awesome work you’re doing — really appreciate it!
Quick question: I’m using a SMILE-T10-HV-INV inverter together with the SMILE-G3-EVCT11/S wallbox.
Support told me it’s not possible to control the wallbox through the inverter’s Modbus interface.
Do you happen to have any experience with that?
Hiya David,
thankfully I don’t have an AlphaESS wallbox myself, so unfortunately I have zero experience with that. I have a myenergi zappi myself. You should ask on the German AlphaESS forum (https://www.storion4you.de/), hopefully someone there is able to help.
Cheers,
Axel
Hello Axel, just installed your yaml.files. All is working very well !
I use a SMILE-G3-T10-INV 18,2 Kwh.
Now the theory of your automations, it is all a little dark to me.
I will dive into that en study them thoroughly.
I would appreciate if you explaine some things more, or is that too much to ask ?
Thank you very much for all your nice work !!!
Piet Spoelstra, the Netherlands
Hey Piet,
great to hear that it’s working well for you 😉 If you have any questions regarding the automations: feel free to contact me directly via projects@hillviewlodge.ie.
Cheers,
Axel
Hi Axel,
Nice work you did there. And thanks for the pdf’s on the MODBUS registers and the explanations on all of it.
Recently, I got an AlphaESS system installed myself (SMILE G3 T10 with 3x SMILE g3 bat 3.8s). Since somewhere in time I used to be a C-programmer I thought, let’s make a C implementation for that MODBUS control. Works fine, I am able to read all information.
My question: did you ever try to turn off the inverter returning power to the grid? I thought setting register 0x0800 to 0 (MAX Feed into grid percentage) would do the job but that does not seem to have any effect.
Jaco Melse, The Netherlands
Hi Jaco,
I tested setting register 0x0800 to 0 in the past, it worked fine and grid export completely stopped – but that was on my old system (SMILE5 Gen2). I haven’t tested it on the G3-S5 but might get a chance tomorrow. Feel free to contact me directly via projects@hillviewlodge.ie and I’ll respond there with my findings.
Cheers,
Axel
Hi Axel,
Setting the “AlphaESS Max Feed To Grid” to 0% doesn’t seem to do anything for my SMILE G3 T10 as well. Did you get the chance to test this out?
Thanks!
Hi,
it’s supposed to work fine – tested here on both SMILE5 Gen2 and G3-S5, others are using it on different models. Are you by any chance with an electricity provider that can control your system? Maybe check on the Dutch Tweaker forum, there are a couple of G3-T10 users there (https://gathering.tweakers.net/forum/list_messages/2298732/0).
Cheers,
Axel
Hello Axel, coincidentally, I also use a Myenergi Zappi charging station. Do you have any special advice or ideas regarding your YAML automations and the AlphaESS inverter? Many thanks from a grateful user of your site.
Hi Piet, I don’t have any special advice since everyone’s requirements are different. It all depends on what you’re trying to achieve. As mentioned last time, if you’d like to discuss anything further please contact me via email (projects@hillviewlodge.ie), let’s not use the commenting function on my website 😉
Hi
I’ve done a lot of Modbus on my HA + Alpha, so fairly switched on.
I’ve just got a Zappi for my EV, and I want to be able to stop the battery discharging when the Zappi is charging.
Have you any ideas how to do that? Is it as simple as controlling “Dispatch start” 0x880H, setting 0 for disable, and 1 to re-enable?
I can’t see much documentation on the detail on these specific registers.
Thanks
Hi Mike,
I haven’t done it myself but I can see two ways straight away. You can set the AlphaESS battery into charging mode with an SoC below the current SoC (via the normal Charging Periods), or you can set the Dispatch Mode to disable any battery charging/discharging: 0x0880 = 1, 0x0881 = 32000, 0x0886 = 250, 0x0887 = “x” seconds (duration), 0x0885 = 2 – 0x0887 can be re-written before the time expires to keep it going until you stop it. That’s very similar to my AlphaESS_Excess_Export automation.
Feel free to contact me directly via projects@hillviewlodge.ie if you want to discuss further.
Cheers,
Axel
Is it possible to limit export or feed-in through Home Assistant when feed-in prices are negative?
Currently, I’m only interested in the inverter with solar panels. Battery is for later.
Hi Jonathan,
yes, sure, you can even do that via the Wi-Fi Configuration in the App – but much easier via HA by setting “AlphaESS Max Feed To Grid” to 0%.
Feel free to contact me directly via projects@hillviewlodge.ie if you have further questions.
Cheers,
Axel
Hi Axel
Fantastic integration. Thank you you have helped me solve some issues I was having. Very much appreciated.
I am having a couple of issues with the excess export function I was hoping to ask your advice on:
1. The Excess Export function seems to ignore the max-feed-to-grid setting. I’ve noticed when the batteries are charged the system will export above the max-feed-to-grid limit (e.g. 15 kW/h). Is there a setting I need to change to fix this?
2. The Export Excess function seems to reset and turn off after a period of time. Is this normal? I want to have this setting on so to priorities the grid each morning.
My setup: I have 20 kW solar panels that produce excess power, 2 x Smile G3-S5 inverer/batteries and can feed in to the grid at good feed-in rates up to 10 kW per hour. Like you I am trying to delay battery charing to maximise the grid feed in until excess power exists above the feed-in kW limit. I have the max-feed-to-grid set correctly. I’m often remote to the location and rely upon home assistant to manage the house.
Thank you
Cam
Hi Cam,
thanks for your feedback, always great to hear that things are working 😉
I’ll respond to your questions via email, I find the commenting functionality not ideal for a proper conversation.
Cheers,
Axel
I love the project. From a bit techy to tech savyyyyyy.
Either way, what I am missing, I am in VPP control, Dutch Energy Supplier; however, I think I can achieve more. Either way; charging and dispatching works perfect as expected. I just received my HA Green.
I would like to have some automation:
1 inverter for PV and one for the AlphaESS system. They are not connected, but do measure the PV installation.
So, I would want during the day, if PV export, rather first fill battery, and during peak hours (can we get a automatic read somewhere of EPEX pricing?) to dispatch to 15% of battery. This should roughly (over last 4 weeks) give me 6 bucks per day. I understand that under VPP control they could give a later API command control to overwrite, but that is ok. Start simple first.
Where would i do this?
Hi Roelant,
I’m not sure I fully understand what you’re asking for – but: there is an AlphaESS_Excess_Export automation to prioritise grid export over battery charging and there is an AlphaESS_Force_Discharge automation to dispatch the the content of the battery.
Hope this answers your questions, if not please contact me via projects@hillviewlodge.ie.
Cheers,
Axel
Hi Axel,
Working great because of your instructions but I’m not that technical. The only thing that I did not manage to get right is getting the charge now to 10KW instead of 5. Could you maybe give some guidance here what values I need to fill in?
Cheers,
Niek
Hoi Niek,
great to hear that it’s working for you and I’m happy to explain how to adjust “AlphaESS_Charging_Now” to meet your requirements. It depends on a couple of factors and might require a “proper” conversation 😉 It would be great if you could contact me via projects@hillviewlodge.ie, it’s easier to explain via mail.
Thanks,
Axel
Hi Axel,
Thank you for this great resource. I have been using it mainly to monitor the battery trough HA. I recently stopped being a battery provider for a VPP and now want to start discharging myself. I used to click the discharge button and the battery would start discharging, but after upgrading from version 2.x to 7.0 this button seems unresponsive. The dispatch does not start when trying clicking the Charging Now or Force Discharge. When I click the Throttle Charge however I see the Dispatch mode go to 2 and the active power change.
I have checked the yaml and I can’t seem to find why it wont work with Charge now and Force Dischage, but it does with Throttle Charge.
I have used the “default” file without modifications to make the troubleshooting easier.
Do you have any pointers for me?
Kind regards,
Pascal
Hey Pascal,
I have an idea: did you create copies from input controls (like input_buttons) from my provided alphaess_view.yaml into you own view?
In version 2.5 I tidied up the naming:
# 2.5 2024-05-24 Replaced “Alpha ESS*” and “Alpha_ESS*” with “AlphaESS*”
So if you copied e.g. the input_button alpha_ess_helper_charging_now this copy will not work anymore, the the trigger in newer version of Alpha_ESS_Charging_Now (now AlphaESS_Charging_Now) is referencing input_button.alphaess_helper_charging_now.
Hopefully that’s the problem 😉
Cheers,
Axel
Thanks for this, going to be trying this soon. I’d kill for you to make a YouTube video about this going over the steps and showing how to adapt it to personal needs, as modbus is a bit daunting for a noobie like me. Given how popular alpha ess systems are starting to get over here, you’d probably be helping a lot of people.
Hi Bart,
I understand that it might be a bit technical but don’t worry too much, it’ll work fine. Adapting it to personal needs is a different story though, it depends on the individual: I like it plain and simple and automated as much as possible and others like it all singing, all dancing, with bells and whistles – because they like looking at the dashboard all day 😉
Just reach out via mail, I’m happy to help – I’ve even done remote control sessions with one of my contacts. For starters, here’s a video I recorded showing how to add my provided HA view to the dashboard: https://www.youtube.com/watch?v=Zu3FVMMU7Kc
Btw: I have one contact, a retired mid-70s general practitioner, a complete amateur – and he managed to implement it, practically by himself 😉
Cheers,
Axel
is there a way to check if modbus commands are received and executed by the alphaESS? I have set upped the integration and can now see the entity sensors, but the alpha does not seem to listen to the charge and discharge commands
There are known issue with some older models (SMILE5 Gen1 & T10). When you’re running dispatch commands, can you see the relevant registers changing?
if i press AlphaESS Load Following I don’t see the dispatch mode changing. (it stays 2 on my Smile G3 T10).
my battert is on VPP. does tat cancels out all modbus commands maybe?
Yes, if you are on VPP you might not be able to overwrite settings since they are managed externally.
Where do I find the helper definitions for
input_select.alphaess_helper_inverter_ac_limit
sensor.alphaess_clipping
sensor.alphaess_dispatch_reactive_power
?
They seem to be not included in the yaml.
Line 1247: input_select.alphaess_helper_inverter_ac_limit (this is a helper)
Line 2404: sensor.alphaess_clipping (this is a template sensor)
Line 1135: sensor.alphaess_dispatch_reactive_power (this is a sensor)
The problem (as almost always) sits in front of the keyboard.
I created a backup folder to store the old configuration – but forgot to rename the file, so Homeassistant tried to load both (the old and the new) yaml file.
Well, that surely cannot end well. m(
I’m struggling a bit getting the values in the entities. If I’m using https://github.com/snitzelweck92/homeassistant_alphaess_modbus_tcp everything works fine. I see the major difference is that the adress values are in Hex. In decimal it works fine. In hex I don’t get the values.
Is there any workaround? Thanks!!!
Hi, that’s the first time I’m hearing that, are you using my provided dashboard view and are you suing an up-to-date HA version? Please contact me via projects@hillviewlodge.ie, might be easier for troubleshooting.
Hi Axel,
Thanks for the awesome work on this. Ive been following it for some time, but my older SMILE5 wasnt open to tcp. As a result Ive been using the work of various people to good effect including Alpha2MQTT, Charles Gillanders and Dehsgr node red integrations.
That all changed recently when the old inverter failed and was replaced with the same (but later hardware)
Ive revisited your work and within 5 minutes had it up and running!
Great stuff and now I can start to clean out the old code and consolidate it with yours.
One change I made with my graphing (original code, not yours – yet) was to modify the display to show PV1 + PV2 + PPV as its interesting to see how much each string is creating at different times of the day.
But anyway – love your work, keep it up!
Hi Spooky,
great to hear that the migration went very smooth, good stuff. Did you get swapped to a G3-S5?
I do host an extended Power Diagram (https://projects.hillviewlodge.ie/_alphaess/power_diagram_extended.yaml) including a diagram for the string details, a 3 day diagram and some others but it’s not linked on the website. You can see the additional diagrams in the screenshot on the website. Maybe I should add the URLs for both versions.
PS: I’ve only yesterday decided to start posting future updates about changes/enhancements in the AlphaESS Facebook Group, that’s easier than manually checking for file changes every couple of weeks.
Cheers,
Axel
Hi,
I have installed HA on my PI4 which went well.
However, I don’t have a “config” folder under the “homeassistant” folder.
So I created the “packages” folder under “homeassistant”, configured the “secrets” file and restarted HA.
I see a lot of parameters in the default dashboard but all sensors show “not available”.
I tested the modbus connection from my Windows pc with positive result. The PI4 is in the same network.
ComputerName : xxx.xxx.xxx.xxx
RemoteAddress : xxx.xxx.xxx.xxx
RemotePort : 502
InterfaceAlias : vEthernet (New Virtual Switch)
SourceAddress : xxx.xxx.xxx.xxx
TcpTestSucceeded : True
I added the IP of the PI4 in the secrets file with and without quotes but no difference.
What am I doing wrong ?
Thx in advance.
Hi Jos,
is it possible that you used something like the “File editor” add-on instead of “Samba” (and mapping the \\homeassistant\config share)? I believe the “config” folder is not visible in the “File editor” – you are looking at /config by default.
Feel free to contact me via projects@hillviewlodge.ie, that’ll be easier for further troubleshooting.
Cheers,
Axel
In the ‘integration_alpha_ess.yaml’ file the dispatch mode address is included as 0x885, but as far as the documentation goes it should be 0x727.
Thanks
You are mixing up the “Household System (Only applicable to HHE MEC)” section and the “Household Power Dispatch” section.
Ok, thanks. Both parameters report ‘0’ but the battery is behaving as described for ‘Load following’. Any idea what that means?
Not really, if all Dispatch related parameters are “0” – which means no Dispatch Mode is active. Could it be a VPP provider controlling your system?
No, I’m planning to but have not done it yet.
Dear Axel,
I followed your instruction till point 9 and i get “Integration error: packages – Integration ‘packages’ not found.”
Even in my Home Assistant Installation i dont have the config folder. So I had to create it.
Version of HA: 2025.8.3
Thanks for your reply 🙂
best regards
Ronny
Hi Ronny,
I suspect you mapped \\homeassistant\config and therefore you don’t see the config folder. Can you take a screenshot of your mapped drive and send it to projects@hillviewlodge.ie so I can have a look? Also, feel free to switch to German in your email 😉
Cheers,
Axel
Hi Axel,
Implemented the integration on a SMILE-S6-HV-INV. The maximum output of this inverter is 6kW. However the configuration options allow only 5kW or 10kW not 6kW. Are you able to add that in your integration yaml?
Hi Leo,
done, please take a fresh copy of integration_alpha_ess.yaml and reload the input selects.
Cheers,
Axel
Hi I’ve managed to hook this into my Smile B3. It did catch me out with the baud rate as the default on my PE11 was 115200 instead of 9600 the issue I have though is some of the figures it’s reporting are a bit out. They aren’t wrong but are out. For example the Current house load is showing as 63,831 W but in the alpha app it’s showing 638W the Active Power PV Meter is spot on. Also the battery power in HA was showing -576W but in the app was showing it was charging and was 576W (this one might settle as I’ve just hit 100% charged so I think it might be a slight red herring but when I look at the graph which I’ve configured it’s showing a battery level at 9kW but I only have a 5.50kW usable capacity.
It might be me but I just want to check I haven’t got anything wrong. It’s feeding back some fantastic data and will massively help me achieve what I need to but just want to make sure the data is correct.
Hi Andy,
yes, the Modbus register sensors of the B3 require some adjustments. Open the integration_alpha_ess.yaml, search for all B3 occurrences and change the “scale:” values to the ones specified in the comments. Save the edited file and reload the Modbus YAML configuration (under Developer tools).
Cheers,
Axel
Hi,
thank you for this integration. It’s really nice to have a way to get the values out of a SMILE-T10-HV-INV via Modbus, which does not require any external cloud services.
My system also contains a second inverter (a Sungrow SG10.17RT), which unfortunately does not provide reliable modbus data. While your integration is properly displaying the solar power of the string attached to the primary AlphaESS inverter, I don’t see the data of the other strings attached to the external inverter. But other values like “Feed to Grid” are correct and contain the power of full system.
In the AlphaESS cloud view I do see the full aggregated power of all strings. And since some days there is a new small hamburger menu showing a tooltip with five entries: PV1, PV2, PV3, PV4 and PV_DC. The values of PV1 to PV4 directly map to your “PV1 Power” to “PV4 Power” entiies. But I didn’t found any entity representing the value of “PV_DC”, which looks like the exact value I’m interested in. I’m currently running version 7.3 of your integration (had trouble with updating to 7.7, so stayed for now). Have you added that entity by any chance in a newer version of could you give me some hints how to get the information from the AlphaESS modbus?
Thank you!
Best regards,
Tobias
Hi Tobias,
that entity should be available in your version, it’s “Active Power PV (Meter)” in the “Other” card. It has been moved to the “PV Output” card in the current version and has also been added to the “Current PV Production” formula.
I’m sorry to hear that you had an issue with upgrading, feel free to contact me via email and also feel free to write in German 😉 I might be able to help with the upgrade, I know a lot has changed recently, esp. 8.1 was big one. The 8.1 changes were on my to-do list for some time and I’m glad it’s done now, so hopefully there won’t be any big updates in the near future.
Cheers,
Axel
Thank you Axel! The latest changes on version 8.x, esp. the inclusion of the “Active Power PV (Meter)” in the “Current PV Production” is a game changer! I updated to version 8.5 and this time, the update of the “alphaess_view.yaml” worked flawlessly. This is a really great integration! (Now, I need to figure out how to import/correct historical data).
Best regards,
Tobias
Hi Tobias,
just an FYI: 8.6 was released earlier today. File integration_alpha_ess.yaml is the only one affected, no updated view.
Cheers,
Axel
Looks like the “Total Energy from PV (Meter)” and “Today’s Energy from PV (Meter)” do not contain the energy portion of the “PV Output”, but only PV energy of the primary inverter. As a result, the HA energy view displays a 0 kWh for home in the distribution graphic. The graphic also claims, I feed more power to the grid than what came from PV (due to the missing “PV Output” portion).
Another thing is, that the “Active Power PV (Meter)” seems to be constant at “11 W” when it should be zero, e.g. at night. The values in the AlphaESS cloud view are zero. At daylight, the value seems to be correct though.
Oh, I think I need to add both, “Total Energy from PV” and “Total Energy from PV (Meter)” to the energy chart configuration as PV generators. Except the “11 W” glitch, values look more reasonable then.
Axel.
How much success have you had with curtailing Alphaess to 100%. Im on a beta program with someone so they can develop an Energy management system. The main issue is it will not curtail. The commands are being sent in Home assistant to the correct register but we feel they are either not acted on or are either being rejected or lost. Im asking you as you may know if anyone else is having this issue or if its even possible. Previously , my Energy Provider (Amber) failed to curtail even though they said it was working. The Alpha App tells a different story. Im sorry i cant discuss many aspects of the Beta program as im on a NDA agreement. Smile S5.
Thanks
Hi Glenn,
is it the Max Feed to Grid setting you’re referring to? It seems like the setting has no effect in AU, someone recently got confirmation from support. There might be another approach if limiting the grid export is what you’re trying to achieve?
Just to clarify: setting Max Feed to Grid to e.g. 0% works perfectly fine in other countries. I’ve tested it here myself. Reaching out to AlphaESS to find out the reasoning for the setting being ignored in AU might be worth it, maybe it’s a mistake… Prior to that you might want to double check that the setting also has zero effect when being configured through the AlphaESS App (under WiFi Configuration).
Cheers,
Axel