Hi Erik, did you allready try to use an automation to disable ECU querying at sunset and enableing it again at sunrise?
Edwin, I’ll try that out and report back in a few days. Thanks!
looks kind of how my ecu was behaving, invalid data responses at most unpredictable moments.
In the end it was related to WIFI instability caused by bad antenna, it even showed ‘failed association’ errors on my WIFI system (eap245 managed wifi).
I took off the wifi antenna and after that it completely stabalized.
It would be great to figure out what it’s saying in the second message. That’s the last time it sends back anything.
APS110018000201END\n
APS110018003001END\n
Any idea how we could decode these?
Nope, @Wadzio maybe the firmware shines a light on that? Only thing we know is that 18 represents the length of the datastring (checksum). Unfortunately we don’t have a functional design document 
Btw, I haven’t seen these commands pass by after extensive logging, maybe due to older firmware on my part (ECU_R_1.2.17Z50)
No luck @HAEdwin, it failed this morning, with this as its last message again:
ecu query: APS1100160001END
raw ecu data: b'APS120100000121620000510001\x00\x00\x0e\x7f\x00\x00\x01\x88\x00\x00\x000\x00\x00\x00\x00\x00\x00\x00\x00\n\x00\n10015ECU_R_PRO_2.0.0000\x80\x97\x1b\x02\xa1\xdc`\xc5\xa
8y\xd1~00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00END\n'
ecu id b'216200005100'
current power: 392
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
I stopped querying it between 9 pm and 5 am which is around sunset and sunrise here. The change seemed to make it survive longer. Maybe there’s a limited number of queries it can handle?
Believe me, there’s no limit on queries it can handle. Do you block EMA updates? There’s still an issue on that. When the ECU cannot process the buffer correctly, it seems to overflow. I’ve done a lot of proxying on the ECU and the validation of completeness on the EMA part is build-in rather solid. So missing data would accumulate in the buffer if not handled correctly.
Yup, the device is on an isolated wifi network, no data is able to get through to the internet.
if i dont route ecu.apssystems.com , i dont get any data at all locally. Its the main url it uses here. I found some other py i did before, which included forwarding queries to ema, i think we can combine some of that into you project to have it behave nicely in the night. I’m now using yours ro to find some weird drops in graphs i have on some days. Occasionaly some inverters report 0 power, i wonder if its really 0 or inverter just not sharing data.
Hi All,
I now also get an APSystems YC-600 inverter for a small PV, and so I only will use ECO-B (which should be the “small brother up to 4 inverters” of the ECU-R … is anyone knowing if this also works the same way?
Additionally: Do anyone know if they send discovery packages with UDP or MSDN or such into the network? Because I expect that the mobile app can auto discover the device, or?
Thank you!
Ingo
Hi Ingo, the ECU-B also communicates with the ECUapp available in the appstore. Therefore I would expect that this integration also works with the ECU-B but please drop us a note if it does or does not because this integration uses port 8899 to communicate with the ECU-R and it is not documented.
Fact is that the ECU-R (the bigger brother) does not have SNMP and certainly no UDP (due to inaccuracy in data transport) capabilities. Initial setup of the ECU works by connecting the ECUapp to the WiFi signal of the ECU hotspot. After a certain amount of time this hotspot will die out and the ECUapp cannot connect to the ECU anymore.
Hello,
I have a ECU-R with QS1A (UID:804000049009-1) do you think it should be possible to include in Home Assistant?
I have installed custom_components from yours GitHub, but received a Log Message saying that it is incompatible (Unsupported inverter type 804).
In HA open /config/custom_components/apsystems_ecur/APSystemsECUR.py and change line 35 to self.qs1_ids = [ “802”, “801” ,“804”] save the file and restart HA. Hope this will solve the issue.
Edit: If is does not unfortunately the protocol has to be rediscovered for this QS1A. Please let us know if it is succesfull
1 Like
Hi, Thank youm that solved.
Thank you for the feedback, I will do a code change and pull request.
1 Like
The code change was commited in Github, now HACS shows an update is available, but the version numbers are wrong/confusing:
I think it is a hash from HACS and might reflect the updated version number from the manifest. Update went well for me though (checked files). However, the finding leads to a review of the way in which version numbering has been applied. It is better to use calVer (for example) in the next release.
Hey guys,
I also got my ECU-B yesterday and after a lot of issues connecting it I now have it on my WLAN.
A telnet on port 8899 gives a connection refused … anyone an idea? Or did I missed something in that thread?
It is connected to cloud and also reporting to cloud every 5 mins
And yes it is WLAN connection, no ethernet or such
Initially try PacketSender.com and send the string “APS1100160001END” to IP and port 8899 of your ECU-B. See if you get response. Do not expect a login prompt or something.
% telnet 192.168.178.155 8899
Trying 192.168.178.155…
telnet: connect to address 192.168.178.155: Connection refused
telnet: Unable to connect to remote host
… no other tool will change something here … or?!