APsystems Sensor for Home Assistant not visible

[Niels_St (Niels)]

Log:

Logger: custom_components.apsystems_ecur.config_flow
Source: custom_components/apsystems_ecur/APSystemsECUR.py:231
Integration: APSystems PV solar ECU-R (documentation)
First occurred: 16:26:15 (5 occurrences)
Last logged: 16:28:27

APSystemsInvalidData exception: Error getting checksum int from ‘ECU Query’ data=b’’
Traceback (most recent call last):
File “/config/custom_components/apsystems_ecur/APSystemsECUR.py”, line 228, 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 40, in async_step_user
test_query = await ap_ecu.async_query_ecu()
File “/config/custom_components/apsystems_ecur/APSystemsECUR.py”, line 112, in async_query_ecu
self.process_ecu_data()
File “/config/custom_components/apsystems_ecur/APSystemsECUR.py”, line 254, in process_ecu_data
self.check_ecu_checksum(data, “ECU Query”)
File “/config/custom_components/apsystems_ecur/APSystemsECUR.py”, line 231, in check_ecu_checksum
raise APSystemsInvalidData(f"Error getting checksum int from ‘{cmd}’ data={debugdata}")
custom_components.apsystems_ecur.APSystemsECUR.APSystemsInvalidData: Error getting checksum int from ‘ECU Query’ data=b’’

In configuration.yaml I now have:
apsystems_ecur:
host: 192.168.XXX.XX

When I don’t put in the IP adres and only the line
apsystems_ecur:
Nothing happens, which I think is understandable

[ksheumaker (Kyle)]

Can you try power cycling your ECU? This is unfortunately an error condition we’ve seen from these devices. What’s happening at this stage, is the integration opened the connection and issued the first command APS1100160001END which when the ECU works correctly will cause it to return data about itself.

For some reason ECUs can get into a state where they just return no data at all, which is what your device is doing (indicated by data=b’’) - basically an empty byte array. We haven’t been able to figure out why this happens, other than the device and/or firmware isn’t very good.

When we’ve seen this the only solution has been a power-cycle of the device.

[Niels_St (Niels)]

@ksheumaker

his the only solution has been a power-cycle of the device.

When its open:

When its closed:

I have to unbold everything to power down this ECU. There is no reboot function from the webportal of this machine (yet).

Using the ethernetport of the device instead of wifi ip also doesn’t fix the problem.

Tomorrow a new day

[ksheumaker (Kyle)]

Oh wow, that’s quite a complicated setup. My ECU just plugs into a regular wall outlet, and I’ve put a smart switch on it, so I can just power cycle it that way. Sorry I don’t have a better answer. It would be really nice if APSystems would just make and publish an API that they would support for local query.

[Niels_St (Niels)]

This one is using CT clamps to see the actual energy consumption on the main wires (3 phase a 25 A). Sometimes I regret buying this complicated ECU-C instead of a ECU-R…NOT

[ksheumaker (Kyle)]

Yes, I looked at the “C” models and seemed pretty nice, but my installer didn’t really offer it. I installed a z-wave power monitor that has CT clamps on my incoming electrical feed, which has worked surprisingly well.

[Niels_St (Niels)]

Sorry for not posting if solution above works in my case (power down+new version 1.2.5). My EPU-C broke down…the button I meant.

Now my installer going to install a new ECU-C. My trust in APS has dropped quite a bit. I’'ll be back when everything is fixed over here.

[Niels_St (Niels)]

The ecu has been replaced. Thumps up for the installer ;-). But I can’t get the integration from https://github.com/ksheumaker/homeassistant-apsystems_ecur working (v.1.2.5) yet. It keeps reporting that the ip address is not correct and have just checked it on ECU-C web interface and am sure I entered the correct address. In configuration.yaml I have the following text:
apsystems_ecur:
** host: 192.168.XXX.XXX (WIFI IP ADDRESS).**

logfile:
This error was caused by a custom integration.

Logger: custom_components.apsystems_ecur.APSystemsECUR
Source: custom_components/apsystems_ecur/APSystemsECUR.py:147
Integration: APSystems PV solar ECU-R (documentation)
First occurred: 14:29:47 (1 occurrences)
Last logged: 14:29:47

Unkonwn error from ECU after issuing cmd=APS1100280002XXXXXXXXXXXXXEND error=[Errno 104] Connection reset by peer. Closing socket and trying again try 1 of 3

Maybe I’m doing something wrong: Did make an issue on github https://github.com/ksheumaker/homeassistant-apsystems_ecur/issues/40. Anybody knows what I am doing wrong?

[nc1264]

The ip-address needs to be from the wireless connection. You probably have a wired connection. On my ECU-R I needed to logon to it, activate the wireless connection and use that ip-address.
It could be the same for your setup

[Niels_St (Niels)]

The v1.2.5 beta integrations doesn’t work with the ECU-C (I think). I am trying v.1.1.2 and it’s working for now.
With 1 ECU-C, 6 micro-inverters (3xQS1 and 3xYC-600) and 18 solarpanels I now got 7 devices and 47 entities:
.
In grafana it now looks like this:

Hope it still works tomorrow.

[Niels_St (Niels)]

No it was the ip-adres of wifi I’m sure. In the ECU-C you can check that in the local portal of the ECU itself. Is more advanced than the ECU-R

[nc1264]

Your setup is very impressive indeed.

[Niels_St (Niels)]

Today everything was gone from this APS ECU-integration. Strange to see 8 devices instead of 7 with a warning in HA.

More info on: https://github.com/ksheumaker/homeassistant-apsystems_ecur/issues/40

[complex1 (Frank)]

This morning I had the same issue.
Suddenly there was 1 extra device added: ECU None
Then I re-installed the Integration, but get an error when I entered the WiFi address
After re-assigning the ECU-R to the WiFi network, I was able to install the integration and all is working now without issues.
I will see what tomorrow brings.

[Niels_St (Niels)]

Here the same. I now did install the beta v1.2.5 and it still keeping his error on ip-adres when integration comes up in integration menu.

Here are some pictures:

When i put in the mark close and re-open i get another message (Can’t connect to ECU, check log) then when not marked:

When nothing is marked ([%key:common::config_flow::error::unknown%]:

The config screen where ip put in my wifi ip-adres:

Screen of integration coming up under integrations:

Version v1.2.5 beta installed using HACS:

In configuration.yaml:
apsystems_ecur:
host: XXX.XXX.XX.XX

Powercycling the ECU-C doen’t work at all in my case.

Did post my logfile on: https://github.com/ksheumaker/homeassistant-apsystems_ecur/issues/40. Maybe you should do the same.

[Niels_St (Niels)]

Did a complete reinstall after deleting costum maps by using file editor in HA.
Pictures:
Wifi ip-adress:

ip adres ethernetport:

All webportals are working but can’t get it connected from HA. Same issues.
When scanned using ip scanner it looks like there using the same mac adress. Is that possible? I think there is still something wrong in code. I’m sorry

[Niels_St (Niels)]

It looks like the version 1.1.2 did survive the night. I hope it keeps working. What I did was reconnecting the wifi of the ecu-c by replacing it’s former ip-adress by a pushing a new one. Changed the ip in the configuration.yaml and now its (still) working the next day🤞

[complex1 (Frank)]

It survived the night, but this morning, the integration become unavailable, say 3 minutes after the command apsystems_ecur.start_query was executed.
It stays unavailable from 07:30 till 08:45 and suddenly it becomes available again, without doing something.
Strange !
I wonder how far it will survive the coming night.

[Niels_St (Niels)]

Same over here only later. Devices where working till 12u. After that, see bellow:
Entities:

Integrations:

Devices:

logfile:
warning logile1:
Using cached data from last successful communication from ECU. Error: index out of range
11:41:02 – (WAARSCHUWING) APSystems PV solar ECU-R (aangepaste integratie)
Deze fout is ontstaan door een aangepaste integratie.

Logger: custom_components.apsystems_ecur
Source: custom_components/apsystems_ecur/init.py:101
Integration: APSystems PV solar ECU-R (documentation)
First occurred: 11:41:02 (1 occurrences)
Last logged: 11:41:02

Using cached data from last successful communication from ECU. Error: index out of range

Fault logfile 2:
Unexpected error fetching apsystems_ecur data: Cached data doesn’t contain a valid ecu_id
11:45:02 – (FOUT) APSystems PV solar ECU-R (aangepaste integratie) - bericht kwam voor het eerst om 11:41:02 en verschijnt 5 keer

Deze fout is ontstaan door een aangepaste integratie.

Logger: custom_components.apsystems_ecur
Source: custom_components/apsystems_ecur/init.py:56
Integration: APSystems PV solar ECU-R (documentation)
First occurred: 11:41:02 (5 occurrences)
Last logged: 11:45:02

Unexpected error fetching apsystems_ecur data: Cached data doesn’t contain a valid ecu_id
Traceback (most recent call last):
File “/config/custom_components/apsystems_ecur/init.py”, line 77, in update
data = await self.ecu.async_query_ecu()
File “/config/custom_components/apsystems_ecur/APSystemsECUR.py”, line 151, in async_query_ecu
data = self.process_inverter_data()
File “/config/custom_components/apsystems_ecur/APSystemsECUR.py”, line 310, in process_inverter_data
signal = self.process_signal_data()
File “/config/custom_components/apsystems_ecur/APSystemsECUR.py”, line 283, in process_signal_data
strength = data[location]
IndexError: index out of range

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File “/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py”, line 187, in _async_refresh
self.data = await self._async_update_data()
File “/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py”, line 147, in _async_update_data
return await self.update_method()
File “/config/custom_components/apsystems_ecur/init.py”, line 102, in update
data = self.use_cached_data(msg)
File “/config/custom_components/apsystems_ecur/init.py”, line 56, in use_cached_data
raise Exception(f"Cached data doesn’t contain a valid ecu_id")
Exception: Cached data doesn’t contain a valid ecu_id

Running v1.1.2 of integration.

[ksheumaker (Kyle)]

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. 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) type the following:

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 some other 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 a little.