Hi,
Yes, I ping without any problem.
Looks like you have a slightly different version of the ds3. We currently only knew about the 703 model if you take a look at the code
self.ds3_ids = [ "703" ]
I’ll add 704 in here, and release a new beta to see if it will then work for you.
New beta release v1.1.2
- Adds support for ds3 inverter type 704 for @juanka99
- When adding the integration the default now is to query every 300 seconds instead of 60. This is in an effort to have it be more stable since the ECU devices are low powered and like to crash. You can still change this to 60 if you wish, and if you already have the integration installed with 60 it will not change. You will need to remove it and re-add to change the query interval.
- Detect an ECU-C and take the same code path as the ECU_R_PRO which will close the socket between each query, where the standard ECU_R seems fine to do the 3 queries without closing the socket - another attempt to make the integration more stable with different ECUs.
You will need to make sure you have beta enabled in HACS, and if you choose “re-download” you can force it to offer you v1.1.2 instead of waiting for it to refresh in the background.
Beta release v1.1.2 works fine with my DS3.
Thanks a lot! 
I just had my system installed with an ECU-R, and I could not for the life of me get it connected to my Wifi. I finally gave up and just plugged it in with a network cable. Interestingly, the HASS integration seems to work just fine using wired connection to the ECU-R, even though it explicitly says during setup that it’s important that I use Wifi.
I much prefer using a wired connection but should I expect this to stop working? Or am I missing out on something that only works over wifi?
Yes, that’s because you have ECU-R-Pro firmware. The ECU-R firmware does not allow users to talk to port 8899 using an ethernet connection. There are issues with the stability of the ECU-R-Pro firmware and the use of querying the 8899 port. For the short term it’s fine (else you wouldn’t be able to setup the ECU using the ECUapp), but for the long term the ECU gives up responding to queries on this port. Because the ECU-R-PRO firmware is certified SunSpec compatible there might be a solution in using the HA-SUNSPEC custom component although it is not clear to me if it supports serial RS485 allready. The ECU does but the custom component might not yet support it. If this works it might be a more stable solution.
@albatorsk If you can please report back after a few days if there are any stability problems in querying your ECU. I made some adjustments in the 1.1.2 that I hope will make it better, but not having my own version of this device makes testing difficult. If you do run into any issues please check the home-assistant.log file for anything related to apsystems_ecur and create a new GitHub issue here: https://github.com/ksheumaker/homeassistant-apsystems_ecur/issues
Ok, looks like I got lucky then!
Sure, I will keep an eye on it for the coming week and report back on Friday next week, unless it breaks before then.
So far, no problems polling the ECU-R using this integration version 1.1.2.
I noticed today that version 1.2.2 is available, so I went ahead and upgraded. Unfortunately, that broke the integration for me, and about 30 minutes later, I downgraded to version 1.1.2 again and now it works just fine again. I will log an issue according to your instruction above.
Thanks. There are now two different versions out there. 1.1.2 has been marked as stable and is no longer just available in the beta channel.
Still working on 1.2.X branch with a few new features and code cleanup, hoping to make it stable, but probably not there yet.
One of the differences between 1.1.2 and 1.2.2 is the use of
self.reader.read(self.recv_size)
versus
self.reader.readline()
Is it worth testing if there is a problem in using readline()?
v1.2.5 beta has the read instead of readline. v1.2.4 is readline, so it can be easy to try different versions. It does appear the 1.2.5 is better in my prelim testing.
I checked here and QS1 = 805 (BR)
@danilodene Thank you for this addition. Are you able to add 805 to the series before the next release yourself?
So I think it’s time for a status update; I started using the integration last Friday (2022-02-04), and so far, it has not had any problems with polling the ECU-R. One big thing to note, though, is that I started out with integration version 1.1.2, and this week I upgraded to version 1.2.5. The upgrade was seamless, but it only worked if I upgraded an already set up integration. If I try to set it up again using version 1.2.5, it always fails. Going back to version 1.1.2, setting it up and then upgrading to 1.2.5 works fine.
Also, I still have not connected my ECU-R to wifi, only to cabled network.
I have not bothered with disabling polling during night time, as so far the polling has not stopped working.
Thank you for the update. There is a new version 1.2.10 that also fixes some issues, and changes some socket code as well. I’ve been running this on my ECU-R (non PRO) for a few days without issue.
To clear up some issues on how the integration works, I wrote some additional info that I thought would be useful to include here, as well as in the forum and a couple of github issues.
The 1.2.10 has changed the socket code in a hope for more stability with the C and ECU_R_PRO devices. But I can tell you weird behavior from the ECUs seems to be the norm more than anything.
We’ve reverse engineered this protocol, and this protocol was intended only for their ECU phone app to connect and initially provision the ECU by your installer. We’ve seen all kinds of issues where the ECU stops responding on the wifi address, it shuts down the service running on port 8899 we are connecting to, or it just spits out bogus data. We’ve not been able to figure out reasons behind any of this - other than bad firmware or quirks in the device we just don’t understand. I’m pretty sure they ever intended it to be queried non-stop like the integration is doing. The devices’s webportal and ability send data to their EMA app usually are not impacted even when the integration fails.
I only have an ECU-R device, so obviously it’s a little hard for me debug issues with the C or R_PRO. To fully make sure your device is working, you need to use something like netcat to test connection to the device.
Here’s an example (nc is in hassio so you should be able to bring up a terminal on your HA instance)
Run this command (replace the with your ECU’s ip)
nc <IP address> 8899
Once it connects (which will just be a blank line - not the command prompt) type the following followed by pressing enter:
APS1100160001END
You should then get a response with something like this
APS1100940001<ECUID>01:+10012ECU_R_1.2.19009Etc/GMT-8END
Where will have your ECU’s ID and additional data. If this fails to work the integration is not going to work in the state your ECU is in. It could be an invalid IP address, or the ECU has shut down the port and a power cycle is necessary.
Hope this helps everyone a little.
1 Like
I have successfully updated the integration to version 1.2.10, but the same issue remains, whereas if I try to set up the integration using version 1.2.10, it does not work. It only works if I set it up using version 1.1.2, and then upgrade to version 1.2.10.
Snippets from home-assistant.log:
Setting up 1.2.10 without “Close and reopen…”
2022-02-15 09:08:04 WARNING (MainThread) [custom_components.apsystems_ecur.APSystemsECUR] Status of reopen_socket False
2022-02-15 09:08:04 WARNING (SyncWorker_0) [custom_components.apsystems_ecur.APSystemsECUR] Unkonwn error from ECU after issuing cmd=APS1100280002216200014656END error=[Errno 104] Connection reset by peer. Closing socket and trying again try 1 of 3
2022-02-15 09:08:04 ERROR (MainThread) [custom_components.apsystems_ecur.config_flow] Unhandled exception: [Errno 32] Broken pipe
Traceback (most recent call last):
File "/config/custom_components/apsystems_ecur/config_flow.py", line 45, in async_step_user
test_query = await self.hass.async_add_executor_job(ap_ecu.query_ecu)
File "/usr/local/lib/python3.9/concurrent/futures/thread.py", line 52, in run
result = self.fn(*self.args, **self.kwargs)
File "/config/custom_components/apsystems_ecur/APSystemsECUR.py", line 190, in query_ecu
self.inverter_raw_data = self.send_read_from_socket(cmd)
File "/config/custom_components/apsystems_ecur/APSystemsECUR.py", line 110, in send_read_from_socket
self.sock.sendall(cmd.encode('utf-8'))
BrokenPipeError: [Errno 32] Broken pipe
Setting up 1.2.10 with “Close and reopen…”
2022-02-15 09:09:18 WARNING (MainThread) [custom_components.apsystems_ecur.APSystemsECUR] Status of reopen_socket False
2022-02-15 09:09:18 ERROR (MainThread) [custom_components.apsystems_ecur.config_flow] APSystemsInvalidData exception: Error getting checksum int from 'Inverter data' data=b''
Traceback (most recent call last):
File "/config/custom_components/apsystems_ecur/APSystemsECUR.py", line 255, in check_ecu_checksum
checksum = int(data[5:9])
ValueError: invalid literal for int() with base 10: b''
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/config/custom_components/apsystems_ecur/config_flow.py", line 45, in async_step_user
test_query = await self.hass.async_add_executor_job(ap_ecu.query_ecu)
File "/usr/local/lib/python3.9/concurrent/futures/thread.py", line 52, in run
result = self.fn(*self.args, **self.kwargs)
File "/config/custom_components/apsystems_ecur/APSystemsECUR.py", line 201, in query_ecu
data = self.process_inverter_data()
File "/config/custom_components/apsystems_ecur/APSystemsECUR.py", line 330, in process_inverter_data
self.check_ecu_checksum(data, "Inverter data")
File "/config/custom_components/apsystems_ecur/APSystemsECUR.py", line 260, in check_ecu_checksum
raise APSystemsInvalidData(error)
custom_components.apsystems_ecur.APSystemsECUR.APSystemsInvalidData: Error getting checksum int from 'Inverter data' data=b''
Setting up 1.1.2 and then upgrading to 1.2.10 works perfectly.
Output from nc:
$ nc <IP address> 8899
APS1100160001END
APS1201190001<ECUID>01�D " Q
10018ECU_R_PRO_2.0.4upd016Europe/Stockholm��`ŨzFk00END
Notice that the ECU-R (not ECU-R-Pro) received new firmware (at least I did)
ECU_R_1.2.20.
My ECU-R wil not conect. The type 670 seems to be the problem. How can I solve this?
Deze fout is ontstaan door een aangepaste integratie.
Logger: custom_components.apsystems_ecur.config_flow
Source: custom_components/apsystems_ecur/APSystemsSocket.py:348
Integration: APSystems PV solar ECU (documentation)
First occurred: 11:46:17 (1 occurrences)
Last logged: 11:46:17
APSystemsInvalidData exception: Unsupported inverter type 670 please create GitHub issue.
Traceback (most recent call last):
File “/config/custom_components/apsystems_ecur/config_flow.py”, line 45, in async_step_user
test_query = await self.hass.async_add_executor_job(ap_ecu.query_ecu)
File “/usr/local/lib/python3.9/concurrent/futures/thread.py”, line 52, in run
result = self.fn(*self.args, **self.kwargs)
File “/config/custom_components/apsystems_ecur/APSystemsSocket.py”, line 158, in query_ecu
data = self.process_inverter_data()
File “/config/custom_components/apsystems_ecur/APSystemsSocket.py”, line 348, in process_inverter_data
raise APSystemsInvalidData(error)
custom_components.apsystems_ecur.APSystemsSocket.APSystemsInvalidData: Unsupported inverter type 670 please create GitHub issue.
Tell us something about which inverter you have. 670 is not added as an inverter type yet. Is it a QS1,YC600, YC1000, DS3 or…