Great addition, thank you Daniel. In my repository I also have added an icon I’ve made that can be used for this integration. Is it possible to add it so it will become visible in HACS?
1 Like
Hi @Wadzio would it be possible to share the file again? I would be happy to take a look at the zigbee part.
@checking12 You can chip in at GitHub - HAEdwin/APSystems-ECU-proxy-for-cloudless-operation: APSystems ECU proxy for cloudless operation
I got it running on PyCharm for a few hours but still needs a lot of testing to see if the solution is working under all conditions.
This is the command to retrieve historical energy data from the ECU-R (compatible with YC600, YC1000 and QS1). Would be a nice feature to add to the integration for HA 
yes… .give me some time… was on holiday till now. Btw, should we get the dns edits obsolete if we configure the ecu with a proxy setting? would make it lot easier and less maintanance. I know proxy traffic is little different from direct ports comms, but if we could work with it, this could be an add in for HA and usable by bigger audience
The whole ECU cloudless subject is somewhat more complex than I expected. I’m now first logging all the traffic to a file and it’s showing a pattern that is almost equal to the github code. For daytime it’s working. But it’s missing a sequence which might be important but doesn’t tell me what it’s needed for.
Problem is that I can’t get the ECU under control when the inverters are offline. There are all kinds of things happening and this causes the ECU entities being unavailable in HA in the morning. After a reset of the ECU there’s a certain sequence to bring it all back to normal working conditions. So I’ll have to do some more monitoring. My first priority is to get it under control and understand what communication is taking place between the EMA en ECU.
1 Like
that could be solved pretty easy with proxy the traffic. when detect number of invertes online =0 , just proxy traffic and nothing else… You then can learn on the repsonses. FW upgrades no need to simulate ofcourse
Let’s see what we come up with. I now have all domains blocked except for ecu.apsystemsema.com. Wonder if that doesn’t hurt the stability.
Hi @HAEdwin and others, Great work!
I just scrolled through the whole conversation here but was not able to find if there is an overview of all the commands you guys have identified.
I would be particularly interested in the inverter maintenance functions and wonder if someone would be willing to help me to capture the corresponding zigbee traffic.
The releaseparty for HA version 2021.6 is scheduled for tomorrow, and the latest version of the integration v1.0.1 has the required version in the manifest. I installed this version manually, but was wondering of there was any progress in the HACS inclusion of this integration.
that only requires the open merge request to be done right? @ksheumaker , any chance this will happen?
I just approved the merge, and you can manually add the url to into HACS and it seems to work.
1 Like
thx a lot for that!
Thank you Kyle,
I made a pull request at Pull requests · home-assistant/brands · GitHub for branding the integration. I hope all required conditions are met and accepted.
I stopped scheduling the integration on/off by the way, it now seems to be running fine if it stays active during the night. Now and then around 03:00 in the morning there’s a short 5 minute interruption but the ECU does recover from that. I’m still uploading to EMA but have blocked domains not related to that but are tried to being reached around 03:00 (my firmware version is ECU_R_1.2.17Z50). Also noticed a new app is released by APSystems called EMA Manager. For additional commands to access the maintenance functions @kadzsol refers to, one might need elevated installer rights which I don’t have.
Furthermore I’ve withdrawn my pull requests because it was a mess 
Currently I’ve added a daily maximum power to the integration but it needs some tuning when HA is rebooted. For cloudless operation I did some further analyzing of logs using the forwarding proxy method. After sunset the ECU seems to run a datacheck against EMA data and corrects where needed. Then around 03:00 in the morning it starts maintenance (pull firmware if available). After that stable until sunrise repeats the sequence. It’s hard to generic simulate what’s all happening, It would be nice if there would be an option to just stop using the cloud but still being able to read the ECU.
I’ve installed it through HACS now, over the manually installed version. Works perfectly.
One issue needs a fix: in the ‘test.py’ a hardcoded IP is used. (which overrides my value offcourse when I (re)install using HACS.
That should replaced by using the value in the configuration.yaml, not in the code itself.
@HAEdwin : I also noticed this is much more stable and will try without using cached data between sunset and sunrise. I do have an automation in place to powercycle the ECU-R when it becomes unavailable.
Ah yes, test.py is not referenced thus should not make part of the repository. You can delete it if wished.
Thank you Edwin, I saw somewhere a guy (twaekers.net?) who had elevated rights. I will try to find him and ask for help.
My connection to the ECU-R stops working after a couple days. I’ve added some debug info, these are the last three messages:
ecu query: APS1100160001END
raw ecu data: b'APS120110000121620000510001\x00\x00\n\x8b\x00\x00\x06k\x00\x00\rT\x00\x00\x00\x00\x00\x00\x00\x00\n\x00\n10015ECU_R_PRO_2.0.0010US/Pacific\x80\x97\x1b\x02\xa1\xdc`\xc5\xa8y\xd1~00\x00\x00\x00\x00\x00\x00\x00\x00\x00\
x00END\n'
ecu id b'216200005100'
current power: 1643
Processing ECU data...
datalen: 110
checksum: 110
inverter data cmd: APS1100280002216200005100END
raw inverter data: b'APS11023900020001\x00\n !\x06\x07\x19\x04Y@\x90\x00\x197\x12\x0101\x02X\x00v\x00V\x00\xf2\x00[\x00\xf2@\x90\x00\x194\x99\x0101\x02X\x00y\x00J\x00\xf2\x00Y\x00\xf2@\x90\x00\x19@U\x0101\x02X\x00w\x00Y\x00\xf2\x00\
x00\x00\xf2@\x90\x00\x19B\x05\x0101\x02X\x00x\x00X\x00\xf1\x00X\x00\xf1@\x90\x00\x19@d\x0101\x02X\x00z\x00S\x00\xf1\x00U\x00\xf1@\x90\x00\x10b\x06\x0101\x02X\x00{\x00Y\x00\xf1\x00T\x00\xf1@\x90\x00\x10I\x85\x0101\x02X\x00y\x00U\x00\
xf2\x00U\x00\xf2@\x90\x00\x10a\x89\x0101\x02X\x00{\x00W\x00\xf2\x00W\x00\xf2@\x90\x00\x10\x91w\x0101\x02X\x00y\x00Y\x00\xf2\x00W\x00\xf2@\x90\x00\x10\x91y\x0101\x02X\x00{\x00Y\x00\xf2\x00X\x00\xf2END\n'
inverter signal cmd: APS1100280030216200005100END
raw signal data: b'APS110088003000@\x90\x00\x197\x12\xd3@\x90\x00\x194\x99\xc8@\x90\x00\x19@U\xc4@\x90\x00\x19B\x05\xcd@\x90\x00\x19@d\xde@\x90\x00\x10b\x06\xdf@\x90\x00\x10I\x85\xc6@\x90\x00\x10a\x89\xd3@\x90\x00\x10\x91w\xbf@\x90\
x00\x10\x91y\xd3END\n'
Processing inverter data...
datalen: 239
checksum: 239
Processing signal data...
datalen: 88
checksum: 88
[OK] Timestamp: 2021-06-07 19:04:59 Current Power: 1643 Actual Power: 1643
Sleeping for 300 sec
ecu query: APS1100160001END
raw ecu data: b'APS120100000121620000510001\x00\x00\n\x8d\x00\x00\x06$\x00\x00\ra\x00\x00\x00\x00\x00\x00\x00\x00\n\x00\n10015ECU_R_PRO_2.0.0000\x80\x97\x1b\x02\xa1\xdc`\xc5\xa8y\xd1~00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00END\n'
ecu id b'216200005100'
current power: 1572
Processing ECU data...
datalen: 100
checksum: 100
inverter data cmd: APS1100280002216200005100END
raw inverter data: b'APS110018000201END\n'
inverter signal cmd: APS1100280030216200005100END
raw signal data: b'APS110018003001END\n'
Processing inverter data...
datalen: 18
checksum: 18
Processing signal data...
datalen: 18
checksum: 18
[ERROR] index out of range
Sleeping for 300 sec
ecu query: APS1100160001END
raw ecu data: b''
ecu id b''
current power: 0
Processing ECU data...
datalen: -1
[ERROR] Error getting checksum int from 'ECU Query' data=b''
Sleeping for 300 sec
The last message goes on to repeat forever. The ECU is isolated from the internet and tricked into being online using APSystems-ECU-proxy-for-cloudless-operation.
Does anyone know why it keeps failing? I see some previous discussion about automatically power-cycling the unit, but I’m hoping for a software fix.