The ECU_R_PRO_2.0.3016 is the official replease so its even longer. From packet tracer I get the following info for Version and Timezone: ECU_R_PRO_2.0.3016Europe/Amsterdam.
45 43 55 5F 52 5F 50 52 4F 5F 32 2E 30 2E 33 30 31 36 45 75 72 6F 70 65 2F 41 6D 73 74 65 72 64 61 6D
In your case the last three digits should indicate the variable length of the timezone which matches up with your TZ “Europe/Amsterdam”. In my case 009Etc/GMT-8. I’ll try to fake the data and see what comes out the vsl and tsl calculations for your case. I suppose your hex before “45 43 55 etc.” will be “30 31 35” or 015 for the length of “ECU_R_PRO_2.0.3”?
Results look allright and no errors 
Can’t reproduce the error you’re encounting 
Can you post the complete hex data string? Could be something in the way you updated the integration. Always 1. make full backup 2. Update via HACS 3. restart via Settings > Settings > Servermanagement [Restart].
Will send you it by personal message
For binary_sensor.py it need to be device_state_attributes, otherwise the module will not load
Did you update HA when this error occured? Is this issue now solved?
What do you mean? from extra_state_attributes change it to device_state_attributes?
The problem begon after upgrading apsystem_ecur to latest version. I got the error: Error getting checksum int from ‘ECU Query’ data=b’’. The module was not able to request the ecur correctly. Went back after to old version. In the old version also extra_state_attributes is used.
Just sent you a PM
This integration is being worked on actively, which is great. I’m following the details on Github, and use HACS to update. With HACS, the version number is weird. It does see a newer version each time, but the versions don’t match the actual numbers in the manifest. I have several HACS integrations, this one is the only one with these weird numbers. See the screenshot:
Whats causing this?
In this case, 80441df shows the latest GitHub commit, most likely due to not being fully compliant with HACS regulations. Therefore, the manifest file must contain certain items:
domain
documentation
issue_tracker (currently not present)
codeowners
name
version (such as using calver)
I’m not sure if adding the issue_tracker URL will solve the versioning.
HACS wants you to use tags in git to specify version numbers. The next release I’ll start doing that so you will get a nicer version number instead of the latest git hash.
2 Likes
I just published a new release and went back to using the v1.0.x scheme. It took me a couple of trys to get it right, so install v1.0.8
You should see something like this in HACS now
I apologize for the rapid multiple versions, use v1.0.9 - I’ll be setting up a test instance to prevent this from happening in the future.
No problem, versioning is working now. A new log entry was being added though: 2022-01-26 08:05:08 WARNING (MainThread) [homeassistant.components.sensor] Entity sensor.ecu_current_power (<class ‘custom_components.apsystems_ecur.sensor.APSystemsECUSensor’>) with state_class measurement has set last_reset. Setting last_reset for entities with state_class other than ‘total’ is deprecated and will be removed from Home Assistant Core 2021.11. Please update your configuration if state_class is manually configured, otherwise report it to the custom component author.
Hi guys. I’ve read mostly the entire thread and I think I know the answer but just to be 100% sure. This solution doesn’t support ECU-C right? Only ECU-R or ECU-B isn’t?
If I’d need support for ECU-C I should try this one GitHub - skelgaard/homeassistant-apsystems: An APsystems Sensor for Home Assistant right?
I would try it with ksheumaker, that should work.
Good thing is that the ECU is queried locally on the network.
skelgaard goes to the online platform which should always work.
Try it and please give feedback (it can help others).
New beta release v1.1.1
I made some changes to the integration to hopefully fix the occasional duplicate sensors showing up. The other major change in this release is support for configuration via the GUI.
Moving to the GUI also allows for viewing all the sensors in under the integration section in the config. Here’s some screenshots:
Installing the Beta
In HACS go to the integration page and click on the 3 dots and in the dialog box make sure you check show beta versions. It will then re-check the repository and allow you to upgrade to v1.1.1
Migration from configuration.yaml
The new version will automatically migrate your settings from configuration.yaml into the config fiow. This will be done on the first restart after installing v1.1.1. You can then remove those settings from your configuration.yaml file.
If you run into any issues with the beta let me know here, or on a github issue. Once this has been tested for a few days by a few people, I’ll release it as an official version.
5 Likes
Hi!
I´m trying to connect to my ECU-B but HA says me “Can`t connect to ECU-R”… ¿any idea?
Thanks
@juanka99 Hi, make sure you specify the IP-address which is assigned to the wireless ECU interface. So first configure the ECU and connect it to your home network using a fixed IP-address. This IP-address must be specified in configuration.yaml if you are not using the beta version. Please let us know which inverter you have connected to the ECU. Also make shure you are not using the temporary hotspot of the ECU which you use to set it up. This hotspot will shut down after ~15 minutes.
ECU-B should be compatible: APsystems APS ECU R local inverters data pull - #436 by Scholtzi
When I installed the beta, I had to restart the ECU-B (power off/on). Maybe it was just a coincidence!
Can you ping the ECU from your PC (command line e.g.: ping 192.xxx.xxx.xxx)?
Let see… I have the ECU configured and working with a DS3 microinverter and two 540W solar panels.
I have tried to config the integration in different ways with the same result: fail
¿Are you sure the ECU-B is compatible?
Thanks
“APSystemsInvalidData exception: Unsupported inverter type 704” is the error that HA shows in its register…
It’s possible DS3 is not supported?