yeah… thats big list too.
have some other custom components that were logging these remarks. Fixed them all by now.
Now let’s hope Kyle @ksheumaker will merge the pull request soon.
I would like to upgrade HA to 2021.12 because of some ZHA device quirks that are included, but I’m waiting a few more days.
the logs are warnings for deprecation, real effect wont be there until next month orso. So go ahead for your ZHA things i would say. (i have only one downside on hue api, but it’s minor)
Merged the latest pull request. Haven’t had a chance to update HA in a while, thanks for the code modifications.
3 Likes
Updated HA, and this integration through HACS. All warnings gone, thanks for all the work everyone!
Seems for me in Hassio the problem is not fixed. For binary_sensor.py it need to be device_state_attributes, otherwise the module will not load. The sensor.py is excepted. Anyone knows why?
Strangely enough AdGuard and ECU-R firmware ECU_R_1.2.19009 don’t get along it seems. Rebooting the ECU with AdGuard enabled prevents the ECU from connecting to WiFi. I didn’t analyse this behavior right away because it could well be an effect of wanting to implement secure DNS.
If an active AdGuard in combination with a necessary reset of the ECU leads to the ECU no longer functioning, this is something to take into account. Maybe someone can confirm this behavior?
Fix is to temporarily disable AdGuard until the ECU is up and running, then enabling AdGuard again.
Figured it out. At ECU startup it checks availablility of domains and starts with ecueu.apsema.com. I blocked this URL so that fails and prevents the ECU from connecting to the WiFi home network. Guess that’s new with this latest firmware.
1 Like
today first time i had to restart ecu and it could not get to internet again. Couldnt figure what went wrong, but also on adguard, but not blocking any aps domains afaik.
somehow it didnt query dns (no logs in adguard) when ecu was repowered… Not sure i want to try it again today, but really wonders me a lot now it works again (did turn adguard off for a while)
Today it has connection issues , had to restart a wifi access point and all seems fine now. Not sure if the new firmware has wifi client changes included, let’s see if it stays stable now
It sure is something to take into account for AdGuard users. Latest APSystems firmware (ECU_R_1.2.19009) was again OTA pushed to our devices without any release notes, I regret that.
I noticed that the installation instructions don’t mention anything about the options regarding starting and stopping the query so I was in the process of adding that. I myself do not use stopping and starting the query at sunset and sunrise. This does result in some error messages in the log around 03:00 in the morning, but after that the ECU just picks it up again without any problems. So the integration works well without. Should I add it to the instructions anyway? This is what I would like to add to the instructions:
Although you can query the ECU 24/7, it is good practice to stop the query after sunset (apsystems_ecur.stop_query) and only start the query again at sunrise (apsystems_ecur.start_query). You can do this by adding automations.
Reason for this are the maintenance tasks that take place on the ECU around 02.45 AM local time. During this period the ECU port is closed which results in error messages in the log if the integration tries to query for data. During maintenance, the ECU is checking whether all data to the EMA website has been updated, clearing cached data and the ECU is looking for software updates, updating the ECU firmware when applicable.
adding some info on it, wont harm. Better to prevent undocumented feature.
Today i restarted HA and integration did not load as ecu wasnt reachable again. There is definitely some instalbility in newer firmware regarding WIFI for me.
I’ve also stopt using the automation to disable queries between dusk and dawn (still have them, but not enabled anymore). My error messages in the log start are around 2.14, every night (Dutch timezone), but as you said the ECU picks up after that without issues.
Mentioning the possibility to stop querying in the docs is a good thing. It’s possible, someone might want to use it.
I’m running the new firmware (ECU_R_1.2.19009) for a while, but have no issues at all when restarting HA. I just did the core 2021.12.5 update this morning, both HA and this integration started without issues.
Occasionally (once every ‘x’ months) the ECU becomes unavailable, and I have an automation in place to powercycle the ECU when that happens. In the first half of 2021 that happened a lot, but with newer firmware version the ECU became more stable (IMHO).
Indeed firmware 19009 seems to perform well and still stable with the integration. Although having blocked some APsystems servers it only results in one error logline early in the morning.
Through the tweakers forum I got a tip from cmos6502. Dennis has further elaborated on the protocol on his GitHub repository GitHub - HectorMalot/ecur: Load solar production data directly from your AP systems ECU-R system, written in Go that would allow the integration to achieve a higher degree of compatibility (with ECU_R_PRO firmware). Adjustments are then necessary. For example, the elaborated protocol provides insight into missing parameters that ensure that subsequent parameters such as the version information are interpreted at the correct length. Hopefully we can work with the information to further improve the integration. In addition, cmos6502 mentioned that closing the port helps to receive the inverter data on ECU_R_PRO firmware. However, this brings with it the possibility of port exhaustion, so a solution has to be found for that.
@ksheumaker I did a pull request for some improvements. Attributes timezone, qty of inverters and qty of inverters online are now exposed. Timezone and firmware version are now anticipating on variable length. ECU_R_PRO firmware owners, please check if the display of the attributes is correct because I can’t check that.
Updated protocol sheet:
Thanks HAEdwin for the new PullRequest.
I have test it with my EDU-B (ECU-ID starts with 216300…). I think it works.
inverters: 1
online: 1
firmware: ECU_B_1.2.19
timezone: Etc/GMT-8
My start positions of the parts in the data stream (APS1100160001) are:
Ethernet MAC: 58+…
Wireless MAC: 64+…
Mark End: 70+…+
Can you verify it?
Because the Wifi MAC on the ECU-R always seems to be zero and there is little added value in displaying the MAC addresses, I have omitted this. But what do you think - shall I add them anyway?
Some time ago I tried to write it in C#.
In the DataStream the Ethernet MAC (the 2 Ports are disabled, but a number is returnd!) / Wireless MAC (0000000000) does not match the Wireless MAC that is displayed in my router.
I do not need it.
I just thought because the offest’s are in the first image from yesterday.
Ah ok, thank you for testing Andreas, I will verify and adapt the protocol sheet when needed. I have withdrawn the pull request to add support for the DS3-L inverter (EMEA) 703, thank you Roelos89, and reintroduce sync-io to enable experimenting with a new function.
HAEdwin,
The HACS update resulted in issues for the ECU_R_PRO. Reverted back to the old version again. First of all created and additional subdir in apsystem_ecur with same name, but fixed it and after restart loading was not successful, with message that the peer closed connection and possibly something to do with the self.vsl or self.tsl what is added.
I already had changed before (and working):
self.firmware = self.aps_str(data, 55, 15) to self.firmware = self.aps_str(data, 55, 18)
and self.timezone = self.aps_str(data, 70, 9) to self.timezone = self.aps_str(data, 73, 9).
Didnt investigate yet what goes wrong.
It is probably the difference in the length of the firmware version string (ECU_R_1.2.19 vs
ECU_R_PRO_2.0.3). String length difference is indeed 3 characters. In order to anticipate both lengths and keep compatibility, the length is indicated in the self.vsl (version string length) and calculates how to extract the version out of the data string. In code it can’t be a fixed length, this might work for the ECU_R_PRO but not for the ECU_R firmware owners. Can you share the error log to get more insight into where the error occurres?