search

ksheumaker / homeassistant-apsystems_ecur

Home Assistant custom component for local querying of APSystems ECU-R Solar System
Apache License 2.0
166 stars 42 forks source link

Integration broke Home Assistant 2021.8.0 #16

Closed adriaanh closed 2 years ago

adriaanh commented 2 years ago

I installed this integration via HACS and rebooted the system. After reboot, I added the following to my configuration.yaml. I have the ecu-r connected through wifi as per instruction and the secret has the ip address of the wifi connected ECU-r. 

apsystems_ecur: 
  host: !secret apsystems_ecur_host

After rebooting, home assistant wouldn't start. I had to go back to a previous snapshot in order to get HA working again. No issues in the logs. Is this an issue with compatibility of home assistant?

I have the ECU-r with QS1 inverters, and connected both via WiFi and ethernet.

Thanks!

adriaanh commented 2 years ago

I'm going to try it out on an empty home assistant environment to check whether it fails there as well.

HAEdwin commented 2 years ago

Configuration.yaml should look like this (example):

apsystems_ecur:
    host: 172.16.0.5

The latest core release of HA (core-2021.8.0 and higher) introduced a renamed parameter for Voltage (ELECTRIC_POTENTIAL_VOLT) !!

So after installing using HACS you have to patch (if you are using core-2021.8.x): Line 30 and 67 in sensor.py from VOLT to ELECTRIC_POTENTIAL_VOLT

Do not forget to reboot. Btw what is your current ECU-R firmware version? Also take a look here: [https://community.home-assistant.io/t/apsystems-aps-ecu-r-local-inverters-data-pull/260835/359]

HAEdwin commented 2 years ago

I have the ECU-r with QS1 inverters, and connected both via WiFi and ethernet.

Make sure you've added the WiFi connected IP-address to the configuration.yaml not the ethernet connected IP-address

adriaanh commented 2 years ago

Thanks for the quick response! I have firmware 2.0xx

I have validated the setup with a clean install of 2021.8.X with the changes you proposed to VOLT. I doublechecked the IP-address, which is the correct one. Still Home Assistant wouldn't start anymore.

I have the following logs (checked with ha-cli:

[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] udev.sh: executing... 
[cont-init.d] udev.sh: exited 0.
[cont-init.d] done.
[services.d] starting services
[services.d] done.
2021-08-05 13:02:08 WARNING (SyncWorker_0) [homeassistant.loader] We found a custom integration apsystems_ecur which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant
2021-08-05 13:02:08 WARNING (SyncWorker_1) [homeassistant.loader] We found a custom integration hacs which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant

Supervisor logs:

21-08-05 13:02:01 INFO (SyncWorker_1) [supervisor.docker.interface] Restarting ghcr.io/home-assistant/qemux86-64-homeassistant
21-08-05 13:02:01 INFO (MainThread) [supervisor.api.proxy] Home Assistant WebSocket API error: Received message 8:1000 is not str
21-08-05 13:02:01 INFO (MainThread) [supervisor.api.proxy] Home Assistant WebSocket API connection is closed
21-08-05 13:02:07 INFO (MainThread) [supervisor.homeassistant.core] Wait until Home Assistant is ready
21-08-05 13:02:09 INFO (MainThread) [supervisor.resolution.evaluate] Starting system evaluation with state CoreState.RUNNING
21-08-05 13:02:09 INFO (MainThread) [supervisor.resolution.evaluate] System evaluation complete
21-08-05 13:02:40 ERROR (MainThread) [supervisor.homeassistant.api] Error on call http://172.30.32.1:8123/api/config: 
21-08-05 13:02:42 ERROR (MainThread) [supervisor.homeassistant.api] Error on call http://172.30.32.1:8123/api/config: 
21-08-05 13:03:12 ERROR (MainThread) [supervisor.homeassistant.api] Error on call http://172.30.32.1:8123/api/config:
adriaanh commented 2 years ago

Ok, I tried again without an ethernet connection (so only WiFi is connected). Still the same response..

hofvanta commented 2 years ago

I also have the ECU 2.0 and problems with HA. It would not start sometimes. After disabling apsystems_ecur is coming back again. Has something to do with the unstable communication with the ECU which influence the startup of HA.

adriaanh commented 2 years ago

There is sadly not much information in the debug logs of Home Assistant. It does not show the front-end, and in the log there is only the following message (regarding the custom_component).

2021-08-05 16:10:58 DEBUG (MainThread) [custom_components.apsystems_ecur] Querying ECU

Memory is blowing up however, so something is going wrong here.

hofvanta commented 2 years ago

Yes I have the same. Processing or waiting on ECU seems like.

adriaanh commented 2 years ago

Ok, I think I have an idea what the issue is. It seems that it will not get the correct ecu_id populated from the raw data. When I hardcode the ecu_id in the code it sort of works. It does not fetch the (correct) data, but at least it doesn't fail. It tries to get the data, but I think it has the same problem as getting the data from the ecu_id: the raw response seems to be different.

self.ecu_id = 'APS1100280002'+myECUID+"END'

Home assistant logs:

2021-08-05 20:01:55 DEBUG (MainThread) [custom_components.apsystems_ecur] Querying ECU
2021-08-05 20:01:58 WARNING (MainThread) [custom_components.apsystems_ecur] Using cached data from last successful communication from ECU. Error: [Errno 113] Connect call failed ('192.168.98.82', 8899)
2021-08-05 20:01:58 DEBUG (MainThread) [custom_components.apsystems_ecur] Returning {'data_from_cache': True, 'querying': True}
2021-08-05 20:01:58 DEBUG (MainThread) [custom_components.apsystems_ecur] Finished fetching apsystems_ecur data in 3.089 seconds

Maybe an idea to:

Or trying different responses might also help?

ksheumaker commented 2 years ago

Taking a different code path for a 2.0 or PRO ECU shouldn't be a big deal if we can figure out how to decode the data.

I took a look at the test script on the tweakers site, it doesn't issue the all the same queries the integration does. The first one the integration does is tells us the the ECU ID, firmware version, lifetime energy, today energy, current power, etc. This query is:

APS1100160001END

Can someone run that on the 2.0 device and provide the output of what is returned?

adriaanh commented 2 years ago

Ok, I added a lot of debug messages in the code. I hardcoded the ecu_id. Getting the following messages (XXXX = ecu_id I put manually in (of course the correct one, not XXXX ;-) )

2021-08-05 20:51:27 DEBUG (MainThread) [custom_components.apsystems_ecur.APSystemsECUR] ecu_raw_data: b'APS1201160001XXXXXXXXXXXXXX\x00\x00\x085\x00\x00\x00*\x00\x00\x07: !\x08\x05 I\x00\x00\x03\x00\x0310015ECU_R_PRO_2.0.1016Europe/Amsterdam\x80\x97\x1b\x02\xaa?`\xc5\xa8y\xdbi00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00END\n'
2021-08-05 20:51:27 DEBUG (MainThread) [custom_components.apsystems_ecur.APSystemsECUR] Data received. Now processing data
2021-08-05 20:51:27 DEBUG (MainThread) [custom_components.apsystems_ecur.APSystemsECUR] Processing ecu data - Check checksum
2021-08-05 20:51:27 DEBUG (MainThread) [custom_components.apsystems_ecur.APSystemsECUR] Processing ecu data - Checksum complete
2021-08-05 20:51:27 DEBUG (MainThread) [custom_components.apsystems_ecur.APSystemsECUR] Processing data complete. Now query inverter
2021-08-05 20:51:27 DEBUG (MainThread) [custom_components.apsystems_ecur.APSystemsECUR] Inverter cmd: APS1100280002XXXXXXXXXXXXEND

2021-08-05 20:51:27 DEBUG (MainThread) [custom_components.apsystems_ecur.APSystemsECUR] Send read from socket attempt 1
2021-08-05 20:51:27 DEBUG (MainThread) [custom_components.apsystems_ecur.APSystemsECUR] Writer encode to utf 8. Now drain
2021-08-05 20:51:27 DEBUG (MainThread) [custom_components.apsystems_ecur.APSystemsECUR] Within try except block -> wait for read from socket

Looking at the code, it seems that it stops working when it is trying to get the inverter data. Looking at the functions and logic, it stops working at function async_query_ecu() in APSystemsECUR.py. The logic:

  1. OK: async_query_ecu -> getting the ecu raw data
  2. OK: async_query_ecu -> processing the ecu data
  3. OK: processing_ecu_data() > checksum ecu data
  4. NOT OK: async_query_ecu -> async_send_read_from_socket inverter data (lines 112-113) 
    cmd = self.inverter_query_prefix + self.ecu_id + self.inverter_query_suffix
self.inverter_raw_data = await self.async_send_read_from_socket(cmd)

    And then it stops at the try/except block on lines 95-96:

            try:
                return await asyncio.wait_for(self.async_read_from_socket(), 
                    timeout=self.timeout)
            except Exception as err:
                pass

Anyone any idea what's going on?

adriaanh commented 2 years ago

@ksheumaker When sending the APS1100160001END command, I get the following response:

b'APS1201160001XXXXXXXXXXXXXX\x00\x00\x085\x00\x00\x00\xb2\x00\x00\x074 !\x08\x05 \x13W\x00\x03\x00\x0310015ECU_R_PRO_2.0.1016Europe/Amsterdam\x80\x97\x1b\x02\xaa?`\xc5\xa8y\xdbi00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00END\n'
ksheumaker commented 2 years ago

2021-08-05 20:51:27 DEBUG (MainThread) [custom_components.apsystems_ecur.APSystemsECUR] Inverter cmd: APS1100280002XXXXXXXXXXXXEND

I'm assuming the XXXXXX are replaced with the correct ECU_ID?

And on your question on lines 95-96 that's reading from the socket and awaiting a response. It should timeout after 5 seconds. But you can add a debug statement above the pass in the Exception block like this

_LOGGER.info(f"Failed on asyncio.wait: {err}")

And maybe we can get a little more details on if there was an exception and what it is

adriaanh commented 2 years ago

Yes I replaced with the correct values ;-).

The script never comes to the Exception block, I have a debug message there already, but it doesn't trigger/show up.

ksheumaker commented 2 years ago

There was some talk about closing the socket and re-opening it between queries? are you doing that? if not replace the async_query_ecu function with this:

    async def async_query_ecu(self):
        self.reader, self.writer = await asyncio.open_connection(self.ipaddr, self.port)
        _LOGGER.info(f"Connected to {self.ipaddr} {self.port}")

        cmd = self.ecu_query
        self.ecu_raw_data = await self.async_send_read_from_socket(cmd)

        self.process_ecu_data()

        if "ECU_R_PRO" in self.firmware:
            self.writer.close()
            _LOGGER.info(f"Re-connecting to ECU_R_PRO on {self.ipaddr} {self.port}")
            self.reader, self.writer = await asyncio.open_connection(self.ipaddr, self.port)

        cmd = self.inverter_query_prefix + self.ecu_id + self.inverter_query_suffix
        self.inverter_raw_data = await self.async_send_read_from_socket(cmd)

        if "ECU_R_PRO" in self.firmware:
            self.writer.close()
            _LOGGER.info(f"Re-connecting to ECU_R_PRO on {self.ipaddr} {self.port}")
            self.reader, self.writer = await asyncio.open_connection(self.ipaddr, self.port)

        cmd = self.inverter_signal_prefix + self.ecu_id + self.inverter_signal_suffix
        self.inverter_raw_signal = await self.async_send_read_from_socket(cmd)

        self.writer.close()

        data = self.process_inverter_data()
        data["ecu_id"] = self.ecu_id
        data["today_energy"] = self.today_energy
        data["lifetime_energy"] = self.lifetime_energy
        data["current_power"] = self.current_power

        return(data)
ksheumaker commented 2 years ago

I'm assuming this lines up with your system?

Qty inverters 3
FW ECU_R_PRO_2.0.1
Lifetime Energy 210.1
Today Energy 18.44
Current Power 178
adriaanh commented 2 years ago

@ksheumaker Yes it does.

I replaced the function with the new one. Looks better, no freeze until now, but still no (correct) data, but now there is a message abount inverter type 806!


2021-08-05 21:10:09 INFO (MainThread) [custom_components.apsystems_ecur.APSystemsECUR] Connected to 192.168.98.82 8899
2021-08-05 21:10:09 DEBUG (MainThread) [custom_components.apsystems_ecur.APSystemsECUR] Send read from socket attempt 1
2021-08-05 21:10:09 DEBUG (MainThread) [custom_components.apsystems_ecur.APSystemsECUR] Writer encode to utf 8. Now drain
2021-08-05 21:10:09 DEBUG (MainThread) [custom_components.apsystems_ecur.APSystemsECUR] Within try except block -> wait for read from socket
2021-08-05 21:10:09 DEBUG (MainThread) [custom_components.apsystems_ecur.APSystemsECUR] Processing ecu data - Check checksum
2021-08-05 21:10:09 DEBUG (MainThread) [custom_components.apsystems_ecur.APSystemsECUR] Processing ecu data - Checksum complete
2021-08-05 21:10:09 INFO (MainThread) [custom_components.apsystems_ecur.APSystemsECUR] Re-connecting to ECU_R_PRO on 192.168.98.82 8899
2021-08-05 21:10:09 DEBUG (MainThread) [custom_components.apsystems_ecur.APSystemsECUR] Send read from socket attempt 1
2021-08-05 21:10:09 DEBUG (MainThread) [custom_components.apsystems_ecur.APSystemsECUR] Writer encode to utf 8. Now drain
2021-08-05 21:10:09 DEBUG (MainThread) [custom_components.apsystems_ecur.APSystemsECUR] Within try except block -> wait for read from socket
2021-08-05 21:10:09 INFO (MainThread) [custom_components.apsystems_ecur.APSystemsECUR] Re-connecting to ECU_R_PRO on 192.168.98.82 8899
2021-08-05 21:10:09 DEBUG (MainThread) [custom_components.apsystems_ecur.APSystemsECUR] Send read from socket attempt 1
2021-08-05 21:10:09 DEBUG (MainThread) [custom_components.apsystems_ecur.APSystemsECUR] Writer encode to utf 8. Now drain
2021-08-05 21:10:09 DEBUG (MainThread) [custom_components.apsystems_ecur.APSystemsECUR] Within try except block -> wait for read from socket
2021-08-05 21:10:09 DEBUG (MainThread) [custom_components.apsystems_ecur.APSystemsECUR] Processing inverter data - Check checksum
2021-08-05 21:10:09 DEBUG (MainThread) [custom_components.apsystems_ecur.APSystemsECUR] Processing inverter data - Checksum complete
2021-08-05 21:10:09 DEBUG (MainThread) [custom_components.apsystems_ecur.APSystemsECUR] Processing signal data - Check checksum
2021-08-05 21:10:09 DEBUG (MainThread) [custom_components.apsystems_ecur.APSystemsECUR] Processing signal data - Checksum complete
2021-08-05 21:10:09 WARNING (MainThread) [custom_components.apsystems_ecur] Using cached data from last successful communication from ECU. Error: Unsupported inverter type 806
2021-08-05 21:10:09 DEBUG (MainThread) [custom_components.apsystems_ecur] Returning {'data_from_cache': True, 'querying': True}
2021-08-05 21:10:09 DEBUG (MainThread) [custom_components.apsystems_ecur] Finished fetching apsystems_ecur data in 0.704 seconds
ksheumaker commented 2 years ago

Ok, what type do you have, are they QS1? If so add "806" to array at line 35.

adriaanh commented 2 years ago

YES! Added '806' to the QS1 array and rebooted. Now getting all kinds of data :-)

adriaanh commented 2 years ago

Shall I provide a pull request with the changes made? (new function + adding 806 to the QS1 data)

ksheumaker commented 2 years ago

Sure if you'd like to that would be great!

adriaanh commented 2 years ago

Worked for quite some time today, but stopped working again (HA unresponsive). 

2021-08-06 13:46:53 DEBUG (MainThread) [custom_components.apsystems_ecur] Finished fetching apsystems_ecur data in 0.886 seconds
2021-08-06 13:47:53 DEBUG (MainThread) [custom_components.apsystems_ecur] Querying ECU
2021-08-06 13:47:53 INFO (MainThread) [custom_components.apsystems_ecur.APSystemsECUR] Connected to 192.168.98.82 8899
2021-08-06 13:47:53 DEBUG (MainThread) [custom_components.apsystems_ecur.APSystemsECUR] Send read from socket attempt 1
2021-08-06 13:47:53 DEBUG (MainThread) [custom_components.apsystems_ecur.APSystemsECUR] Writer encode to utf 8. Now drain
2021-08-06 13:47:53 DEBUG (MainThread) [custom_components.apsystems_ecur.APSystemsECUR] Within try except block -> wait for read from socket
adriaanh commented 2 years ago

This might actually be the same kind of issue: https://stackoverflow.com/questions/41932359/timeout-for-python-coroutines

adriaanh commented 2 years ago

Tried to debug again. When I put the following in the function where it stops, I get the following. Seems that we need to create something to stop the while loop if the data is rubbish:

        while end_data != self.recv_suffix:
            self.read_bytes = await self.reader.read(self.recv_size)
            self.read_buffer += self.read_bytes
            size = len(self.read_buffer)
            end_data = self.read_buffer[size-4:]
            _LOGGER.debug(f"Read buffer {size} with end data {end_data}")

Debug logs:

2021-08-06 15:55:32 INFO (MainThread) [custom_components.apsystems_ecur.APSystemsECUR] Connected to 192.168.98.82 8899
2021-08-06 15:55:32 DEBUG (MainThread) [custom_components.apsystems_ecur.APSystemsECUR] Send read from socket attempt 1
2021-08-06 15:55:32 DEBUG (MainThread) [custom_components.apsystems_ecur.APSystemsECUR] Writer encode to utf 8. Now drain
2021-08-06 15:55:32 DEBUG (MainThread) [custom_components.apsystems_ecur.APSystemsECUR] Within try except block -> wait for read from socket
2021-08-06 15:55:33 DEBUG (MainThread) [custom_components.apsystems_ecur.APSystemsECUR] Read buffer 0 with end data b''
2021-08-06 15:55:33 DEBUG (MainThread) [custom_components.apsystems_ecur.APSystemsECUR] Read buffer 0 with end data b''
2021-08-06 15:55:33 DEBUG (MainThread) [custom_components.apsystems_ecur.APSystemsECUR] Read buffer 0 with end data b''
2021-08-06 15:55:33 DEBUG (MainThread) [custom_components.apsystems_ecur.APSystemsECUR] Read buffer 0 with end data b''
2021-08-06 15:55:33 DEBUG (MainThread) [custom_components.apsystems_ecur.APSystemsECUR] Read buffer 0 with end data b''
2021-08-06 15:55:33 DEBUG (MainThread) [custom_components.apsystems_ecur.APSystemsECUR] Read buffer 0 with end data b''
2021-08-06 15:55:33 DEBUG (MainThread) [custom_components.apsystems_ecur.APSystemsECUR] Read buffer 0 with end data b''
ksheumaker commented 2 years ago

I didn't mean to close this - I added a change to the latest version that incorporates the suggestion from the stack overflow post. Your ECU seems to be less reliable in sending out data than mine, since i've never run into getting 0 bytes back from the socket. Let me know if it helps you.

adriaanh commented 2 years ago

Thanks for adding these changes! I have installed the latest version. It doesn't block Home Assistant, however, does not connect to the ECU. I tried manually and no 'asnwer' there either. It connects, provides the ECU_ID, but doesn't provide the inverter data.

After I rebooted the ECU all started working. I suspect the ECU doesn't like all the requests or something. Maybe lowering the number of requests would help.

Possible to enable a configuration that indicates the update_interval? I can do that with an automation, but integrated in the configuration would be slick.

ksheumaker commented 2 years ago

added support for adding

scan_interval: [SECS]

to the configuration, default is 60 if you leave it out. Let me know what value you seems to be safe with your ECU

hofvanta commented 2 years ago

adriaanh,

did you check the tweakerscript when HA broke? Seems like you get also rubbish from the ECU then also. I have it atleast. Same behavior again and dont know what causing it. Restart of ECU solves it temporary again.

hofvanta commented 2 years ago

I got after last update of apsystems_ecur: 2021-08-06 18:51:33 WARNING (MainThread) [custom_components.apsystems_ecur] Using cached data from last successful communication from ECU. Error: Unable to convert binary to int location=35 data=b'415053313130303138303030323032454e440a'

Reponse is not long enough seems like and it stopped.

adriaanh commented 2 years ago

added support for adding

scan_interval: [SECS]

to the configuration, default is 60 if you leave it out. Let me know what value you seems to be safe with your ECU

I'll try out whether this helps, thanks!

adriaanh commented 2 years ago

adriaanh,

did you check the tweakerscript when HA broke? Seems like you get also rubbish from the ECU then also. I have it atleast. Same behavior again and dont know what causing it. Restart of ECU solves it temporary again.

No rubbish, just no answer from the inverter query. The other queries work.

adriaanh commented 2 years ago

Quick update: until now everything works! I'll give an update again around 24-48hours to see whether the ECU stays working

adriaanh commented 2 years ago

I had some issues in between, but now having the scan_interval: 360 looks like it's helping.

HAEdwin commented 2 years ago

@adriaanh I was wondering how it is running now and if it is stable. Can the issue be closed?

adriaanh commented 2 years ago

Thanks for asking. It is actually broken for some time now. Tried reinstall and reconfig, but no luck. I kind of gave up that my ECU-R will work properly. I am however able to see the web page, so maybe scraping that is possible.

HAEdwin commented 2 years ago

Too bad it won't work. Is it an ECU-R pro? I know of the existence of the ECU-R ECU-B and ECU-C but no pro version? ![image](https://user-images.githubusercontent.com/82239374/147571477-7ce3c5b5-c5fe-4e25-b5e8-eea0f0f6ebe0.png) What do you mean by "I am able to see the web page"? Is there a GUI build in your ECU-R? I you want, install packetsender on a PC/Laptop and do the following: image Then press [send]. You should get te following: image Does this work for you until this stage? And what is the full response you get?

adriaanh commented 2 years ago

Thanks for the quick response. I have the ECU-R, not a PRO. I think I messed up the name of the merge request.

I noted from other forums that there is a GUI (old one). You need to go to http://index.php/realtimedata for example. I get the following overview: image

I tested with the packet sender, I got a response, but it seems empty (not like your screenshot): image

adriaanh commented 2 years ago

I restarted the ECU-R, and now I got the following response: image

adriaanh commented 2 years ago

Tried again, now it's empty again: image

HAEdwin commented 2 years ago

This is very weird, almost looks like a invalid firmware implementation. Under normal circumstances you should be able to send the string APS1100160001END almost 24 hours a day and expect a response that you got after a reboot of the ECU-R. Can you post the full response to the command by double click on het ASCII results? I've tried to access the ECU-R web GUI you posted but it doesn't seem to be there. If your firmware is different I would recommend contacting APS because this is not as expected.

HAEdwin commented 2 years ago

Oh wait I see your response earlier in this thread and firmware ECU_R_PRO_2.0.1016. Very different from the maintained ECU-R firmware that is currently at ECU_R_1.2.19. I wonder where you got your ECU-R and how it got flashed with the ECU_R_PRO_2.0.1016 firmware. I suggest you ask APS if this is supposed to be happening on your ECU-R. This firmware version clearly does not work with this integration unfortunately. Just found out that Roy must have a similar issue with his NodeJs implementation because of his firmware version ECU_R_PRO_2.0.3012. He's at https://github.com/rkokkelk/apsystems_ecur

HAEdwin commented 2 years ago

@adriaanh I noticed that when the inverter(s) go down, you receive empty responses. Yours is around 18:03, so this matches up. De integration will not work from this point on because the references to the hardware are missing. For me responses came back after a few minutes but best is to try things when inverters are up and running.

adriaanh commented 2 years ago

Oh wait I see your response earlier in this thread and firmware ECU_R_PRO_2.0.1016. Very different from the maintained ECU-R firmware that is currently at ECU_R_1.2.19009. I wonder where you got your ECU-R and how it got flashed with the ECU_R_PRO_2.0.1016 firmware. I suggest you ask APS if this is supposed to be happening on your ECU-R. This firmware version clearly does not work with this integration unfortunately. Just found out that Roy must have a similar issue with his NodeJs implementation because of his firmware version ECU_R_PRO_2.0.3012. He's at https://github.com/rkokkelk/apsystems_ecur

I got mine with the solar panels, quite recently actually (August 2021). I didn't do anything to the firmware, and as far as I could tell the one installing the panels took it out of a new packaging.

And regarding Roy's problem, is there any forum activity about it?

adriaanh commented 2 years ago

@adriaanh I noticed that when the inverter(s) go down, you receive empty responses. Yours is around 18:03, so this matches up. De integration will not work from this point on because the references to the hardware are missing. For me responses came back after a few minutes but best is to try things when inverters are up and running.

I did some more testing, but the requests indeed fail when they're down, but works when they're up. Would that be a way forward? Checking some things in the code on whether the inverters are down? Now the entire reading fails, but might be logical from a ECU-R-PRO firmware standpoint.

HAEdwin commented 2 years ago

In my fork I have supplemented the description with the previously not described option to stop the reading after sunset and start again at sunrise. You can allready use the functions _apsystems_ecur.stopquery and _apsystems_ecur.startquery in automations to prevent the issue with getting empty responses.

In automations.yaml it would look like:

  alias: stop ecu query
  description: ''
  trigger:
  - platform: sun
    event: sunset
    offset: '0'
  condition: []
  action:
  - service: apsystems_ecur.stop_query
  mode: single

There's no record of an ECU-R-Pro on the internet, does the ECU look identical to the ECU-R? What is written on the back of the ECU?

adriaanh commented 2 years ago

Thanks for providing the stop query info, it still doesn't work but I will take a look at maybe using a little lean time to give some time for the converters to show up. Meanwhile I made a photo of the device, seems to be a ECU-R IMG_20220107_084017

HAEdwin commented 2 years ago

Ok, thanks! The difference is the IEEE2030.5 CSIP certification. This standard defines the mechanisms for exchanging application messages (IoT) and is often associated with RESTful (Representational State Transfer Application Program Interface). Possible API capabilities. Anyway it's compatible with the sunspec alliance https://sunspec.org/wp-content/uploads/2020/01/SunSpec-APSystems-certificate-CS-000012.pdf and the testcases are here https://sunspec.org/wp-content/uploads/2020/04/SunSpec-PICS-AltEnergy-CSIP-ECU.xlsx

This firmware also includes a webinterface if I'm not mistaken? Looking at the date (2021.3.1) the ECU-R-PRO firmware might be limited to this and later models of the ECU-R. Which means my older model might never get this firmware. :(

Meanwhile on the dutch tweakers forum cmos6502 has good experiences with closing the socket after querying the ecu (also with ECU-R-PRO firmware). I hope to receive the improvements from him so that the integration also works stably with the ECU-R-PRO firmware. In the future, we may be able to talk to the ECU with an API.

IMG_4073

tv3 commented 2 years ago

@HAEdwin working on it. The pro version has ecu-id starting with 216200..... Also I think the first two bytes in the request/response are something like an API/message version. the pro firmware responds with APS12. But hey, I've been playing with this for just a few days now :-) Also: what's the best way to share my changes? Maybe a separate branch on your repo?

adriaanh commented 2 years ago

Interesting. Good to know there are developments. Furthermore, I noticed a new option within the web interface: that is related to the certification you mentioned. Not sure what is does, but might be interesting. The web interface is far from finished btw, you can only go there if you go to either [IP]//index.php/management or [IP]//index.php/realtimedata

image

HAEdwin commented 2 years ago

Also: what's the best way to share my changes? Maybe a separate branch on your repo? I don't mind if you do, I can do some testing before adding it.

@adriaanh Indeed, the web interface does not look ready yet, I suppose the dropdown lists are empty and there is no live data? In the meantime, I'm curious to see where the developments at APSystems are going, it's nice that they have opted for open standards. We've never asked but I suppose they are watching ;) It's great to see our PV data in HA.