APsystems Sensor for Home Assistant not visible

[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.

[complex1 (Frank)]

Please beware of the confusion… I own an ECU-R device, not an ECU-C or other device.
I run version 1.1.2 not a beta.
Furthermore, I need to do some more investigation and it’s too early for me to jump to conclusions.

[ksheumaker (Kyle)]

Which ECU-R do you have? There are two different devices one is an ECU_R_PRO and ECU_R the pro version has a web-interface the non pro doesn’t. I have the non pro version. The integration will tell you which version (it’s in the firmware under the ECU section in HA devices UI) and in the response from the nc command listed above

APS1100940001<ECUID>01:+10012ECU_R_1.2.19009Etc/GMT-8END

you can see mine is ECU_R_1.2.19. There is also a known ECU_R_PRO_2.XXX they behave quite a bit differently, even though they both are just labeled as ECU-R on the outside of the device.

[Niels_St (Niels)]

When using the HACS plugin terminal this command doen’t seem to work. Same for external SSH session using putty.

ECU doesn’t work in HA so this seems logic. Gonna try to fix this connection … wish me luck.

[complex1 (Frank)]

It looks like I have the ECU_R_1.2.19

[ksheumaker (Kyle)]

Try with

nc -v XXXX 8899

You will get a more verbose message with netcat then. If you see it saying connected, then type in the APS1100160001END command.

[Niels_St (Niels)]

I’m still waiting for a restart of HA…

HACS takes a lot of time to restart

[Niels_St (Niels)]

And now this one after total reinstall:

I think I throw my towel in the ring (“Gooi mijn handoek in de ring”, as they say here in the Netherlands)

[Niels_St (Niels)]

After putting the command: “APS1100160001END” nothing happens for a long time. When using CTRL+Q to quit its saying too many output retries

[complex1 (Frank)]

Didn’t survive the night.
ECU Querying Enabled all the time.
Screenshot is from the last 24 hours
I’ve noticed that the problems only occur when it’s dark outside.
Don’t mind the last unavailable message of 11:33. This is my fault.

[ksheumaker (Kyle)]

Can you send me the output from your log with anything related to APSystems? Which version of the integration are you running?

Also there is a “Download Diagnostics” option in the integration now when you go to the ECU device under “Configuration” > “Device & Services” and then go to your ECU, if you want to PM that it might be helpful.

[complex1 (Frank)]

I’m running the “stable” version 1.1.2 and have the ECU_R_1.2.19
Sorry, but I can’t find any APSystems log.
Maybe because I restart the system to repair the last “unavailable” issue this morning.

[ksheumaker (Kyle)]

Ok next time before you restart if you can send me any output from the log that will be very helpful. That’s where the details of why the sensors went offline are kept.

Did you need to restart the ECU, or just restart HA to get it working again?

The 1.2.10 release does have some fixes/changes to the socket code, and mine has been running non-stop (querying at night even) for the last 4 days without issue.

[complex1 (Frank)]

This morning I had to turn off the power because a light switch had to be replaced, so the router, and therefore also the WiFi network, had to be turned off.
After I finished and restarted everything, HA had no connection to the ECU-R, so I restarted the HA.
However, this did not solve the problem, so I reassigned the ECU-R to the WiFi network to get it working again.
I have not restarted or power cycle the ECU-R.

How and where can I get version 1.2.10?

[ksheumaker (Kyle)]

You can switch the version by going to HACS > Integrations > the three dots next to “APSystems ECU-R” > Redownload > when the dialog comes up check Show beta versions and you should be able to pick 1.2.10.