you’re right. maybe it needs to be put in some kind of dev/debug mode or something. maybe like pressing the “ap” button but then permanently.
I ran the script, and it doesn’t even need authentication so my concern about hassle was unfounded 
My findings are similar; you can press the button and get it to broadcast its own wireless network that connects with the ECUApp. Once that expires or is configured to connect to an existing Wi-Fi, the ECU starts reporting data to the website and stops being available locally. The website seems to be the only choice for the ECU-R.
I installed appdaemon and the script, which worked out of the box but I made some tweaks, and then created my own module to pull my net metering stats from my power provider (Florida Power and Light) as well.
I’m learning how to write addons directly for HA, and am using the FPL as a sample case, but plan to do the same with the APSystems EMA as well. I’ll contribute the code for both once I have something that works.
This is a side project for me in addition to both work and school, any my first addon code, so I don’t have a timeline for completion.
Sorry, it wasn’t Frank’s script that I installed into appdaemon and ran. It was another script I found in another thread: https://github.com/felipegonzalez/homeassistant-cuau/blob/217ca75e742218df9c8bb24c116f9d28e0f825d0/appdaemon/config/apps/ap_systems.py
I was trying this way, but… I think won’t work ever!!!
I have a hass.io Rpi.
Is there a way to running it in the same Home Assistant hardware?
Did you get some good news on the Integration Implement?
Here is another threat @olivier got it working throught Scraping ECU web interface…
Aparently he got access via his ECU unit…
platform: scrape
resource: http://192.168.0.26/ 1
select: " tr:nth-child(2) > td"
name : Lifetime_generation
value_template: ‘{{ ((value.split(" ")[0]) | replace (“KW”, “”)) }}’
unit_of_measurement: “kWh”
scan_interval: 60
I’m building my Solar array this month, and will be using APSystems micro-inverters.
I was wondering if there’s a way to skip their cloud service and log everything locally?
@phrfpeixoto Are you using an ECU as well? I have written a windows program that proves that you can indeed work independently of the cloud. So it’s just a POC not a data logger. The most important thing is to return a correct timestamp to the ECU-R (don’t know if it also applies to the ECU-C). If the returned timestamp does not match the last data sent from the ECU, the ECU will retransmit buffered data frames or go into error modus. It requires some Python knowledge to deploy the four necessary socket channels for this purpose. Also, the DNS query from ECU to apsystemsema must be routed locally to the node that is capturing the data. But that was all under investigation in January of this year. Meanwhile, the necessary firmware versions for the ECU-R have been released and since I now know what is being sent, I don’t feel the urg to work off cloud anymore. Data also does not include temperature and Zigbee signal strenght.
There is an integration for HA available on Github (based on the ECUapp) and there is also a discussion on GitHub to directly read Zigbee from the inverters without ECU.
Note: registration to the EMA cloud is available for DIY installers
Hi @killabee.nl,
Since your post, there have been some changes. There is an integration available on GitHub. It reads the ECU same way the ECUapp without the need of activating the ECU’s own WiFi point. Ports are open (Wifi as well as ethernet).
@HAEdwin
Amazing work! Congratulations! Is that open source? Any way I can deploy it directly on an RPi running local and push the necessary data through MQTT?
Your screenshot shows the raw socket comms, but we can’t see exactly which parameters are being reported by the ECU, and what sensors we could create from that data.
I’d like to avoid the cloud as much as possible.
The bottom line is that the ECU expects a response to the data sent by the ECU to the EMA cloud.
Every 5 minutes the ECU opens port 8995 or 8996 and sends out the data to EMA. In response the ECU expects a timestamp -5 minutes so that the ECU data buffer is maintained. Port 8995 or 8996 is being closed after a while so response must be given while the port is open. Command and Timestamp format is 10120210328100026. If no response is sent, ECU shuts down after a while, thinking there is no internet connectivity.
I’m now investigating if timestamp responses must be given on these two ports or can also be given on 8899. This is the query port the ECUapp uses. Purpose is to keep the ECU up’n’running.
EDIT: Well this experiment failed 
It would take some programming experience to build this in Python the ECU responses can be what confusing if it empties the data buffer so it is complex. Less parameters are available (no inverter temperature and inverter signal strenght).
Apparently this is not working for me now. Is this still working for you or have they closed up this kind of access?
Due the problem with the old apsystems API that is not working anymore, I create a new HTTP APsystems Sensor. It is in HACS structure. So if you are using HACS, just add this repository:
It uses the https://apsystemsema.com web site to get the information. So it works with any APsystems inverter / ECU model.
Please, help me to test. If you like, just give me a beer 
I got access to an ECU-C for 1hour.
I found out that you can activate Sunspec Modbus on the ECU-C.
Next i have installed the Modbus Doctor Software.
https://www.kscada.com/modbusdoctor.html
Modbus TCP will work on ECU-C
I have read the holding register 40000-40399 and i got an answer.
may be other registers are also OK
it seems that the registers are the same as solaredge
Next is to find out all the registers that are used.
have a nice day
Jean
I tried today nod-red with node-red-contrib-solaredge-modbus
The solaredge node read the ECU-C values.
some calculation are wrong.
The source code for Solaredge is on github .
It can be modified for the ECU-C
Good news for everyone who owns a ECU-C.
sunspec Modbus can be activated. Modbus RTU and TCP works.
I managed to read out the values in Node-red.
You have to install the sunspec modebus tcp node.
The se_inverter.json file in the config_json Folder must be adapted.
Here are the register mapping.
Have a nice day.
Today fixed and working fine!
JQM1961, How did you enable Modbus on the ECU-C. I don’t have that option on the web interface of the ECU-C.
Hi everyone,
I was wondering how people have enabled Modbus over IP and if possible to do as owner, instead of the installer.
On other matters, I was thinking to start a local version of the APsystems sensor. Basically, the same as the above but querryng the local MCU instead of the cloud. Would people be interested on that?
I love the work from @bgbraga & @synack, but I can see 2 benefits from this. First, my unit has consumed/import sensors as well as the connection to the panels so I could get a few extra data points there. Also, since the queries are local, data could be refreshed more freely than a cloud service. Bear in mind all measurements happen in 5min slots, so there’s no point on anything smaller than that.
To do this I was looking to do HTTP requests to the MCU such as “http://<MCU_IP>/index.php/meter/old_meter_power_graph?date=2022-04-07”, however I’m unsure whether the same API is in all MCU’s. I only have MCU-C (less than 48h with it), so I’d appreciate if people can confirm it works on others.
So far I have the following entry-points:
- Power by inverter data: http://<MCU_IP>/index.php/realtimedata/old_energy_graph?date=2022-04-08&period=weekly
- Energy by inverter data: http://<MCU_IP>/index.php/realtimedata/old_energy_graph?date=2022-04-08&period=weekly
- Power measured by sensors: http://<MCU_IP>/index.php/meter/old_meter_power_graph?2022-04-07
- Energy measured by sensors: http://<MCU_IP>/index.php/meter/old_meter_energy_graph?date=2022-04-08&period=weekly
Can anyone confirm wether these work on others?
First, not me but skelgaard did the work, since the data comes only once an hour I want to take a closer look at this project:
Waiting for the ordered hardware.