Which integration to use? or even migrate?

[TexTown]

@HAEdwin , I've been using the AP Systems ECU-R integration from 'ksheumaker's repository for a few years, to which you have been contributing a lot (in fact you were the sole contributor for a long time I think). Now there is this new repository, which I assume wil get more attention and features.

What would be your advise? Migrate to this version? (and can that be done easily without losing sensor data?)
Or will the other repository also receive still updates from you?

I own an ECU-R 2160xxxxxxxx series

[HAEdwin]

@TexTown I'm planning on continuing this version here, trying to stay ahead of firmware changes on the ECU's.
With a 2160 there's no real need although the code has become a bit of a mess. If you want to migrate:

1. ECU entities are not migrated because the ECU-ID is now part of the Entity to enable the use of multiple ECU's
2. Inverter entities where kept the same except for the Zigbee signal (which unit is converted from % to dBm)

To prevent inverter entities to be doubled ("entity" becomes "entity" + "entity-1") you have to completely remove the old integration and reboot before activating the new one. The old entities are then first removed and later added again without loosing historical data. Always use the UI to remove an integration.

If there's a need to reboot the ECU, leave it for 10 minutes before re-configuring the ECU. If you want to connect too early, the ECU data is invalid.

[TexTown]

Thanks for the info, and updating the readme.
I've migrated to this new version, and renamed only 2 entities back to old names (ecu_lifetime_energy & ecu_current_power). These entities are also stored in an Influx DB, and would lose the reference with the old data. Luckily the Inverter sensor names remained the same, these individual sensors are also in the Influx DB.

What I'm missing is the switch entity to query the device. I was using that in an automation to powercycle an unavailable ECU (using a smartplug)
I'm altering the automation to fire upon the new cache counter reaching '5' , but how do I delay the querying of the ECU after the restart?

[HAEdwin]

No need to set a timer, the cache will be used until valid data is available again.

[TexTown]

I still have automations (disabled, tested these for short while only) that would stop querying the ECU between sunset en sunrise. I'll remove those, can't use these anymore because the switch is missing now.

[HAEdwin]

I also delved into the issues that came up and it turned out that sometimes users forgot the switch. For example, the switch remained off after the reboot and users saw restarting HA as the only solution. I now have an ECU-R (2160) and ECU-R-Pro and for both I have not had the need to reboot yet, although I regularly "abuse" them during testing. If you could share your automation for the reboot after 5 cache counts for the readme, I would appreciate it! See how things work out, If the need for the switch returns I'd be happy to bring it back.

[TexTown]

I'm still waiting for the first cache usages, so far this integration is stable en the connection to the ECU also.
No need to reboot just yet. If the automation eventually works, I'll post it.

One question about the 'Using Cache Counter' sensor: does it ever reset without the reboot?
Suppose there is a cache usage moment once every week (not a big problem), then eventually the UCC would reach 3 after 3 weeks and reboot the ECU without that being strictly necessary to keep it working...

[HAEdwin]

Yes, the UCC will always reset, even if the reboot option is failing in case of a non ECU-R-Pro. So if it reaches 5 for example, the integration will try to reboot the ECU but an automation can then as well activate the smart-plug at the same time.

[jurasjea]

I also switched to this new version, and it completely resolved the connection issues I was facing with my ECU-B (previously a daily struggle, even after reboots).
Now, the connection remains stable for several days.
Many thanks!

[HAEdwin]

Thank you, my intention was to make the integration faster but more stable. What I have learned in recent years is that, regardless of integration, there are always environmental factors that influence operation, such as local network problems. Understanding how the ECU works also plays an important role. With the new firmware of the ECU-R-Pro, there appears to be no complete data within the first 10 minutes after a restart, possibly because the ECU has not yet received current data from the inverters (which makes more sense to display that current data). I don't know if this also applies to the older ECU-R (2160). I still have to purchase a number of panels and inverters that will then run on that ECU. Feel free to award this integration with a star if you like it.

[mcattle]

@TexTown I've got the same ECU model as you, and I went with this integration, the non-proxy one.

After switching, I just had to adjust my ECU Lifetime Energy template to use the new ECU sensor with the serial number, but the individual inverter channel power sensors worked out of the box (this is a picture elements card, today is a semi-cloudy day):

[TexTown]

That looks really good! I like the 3D look.
Instead of numbers only displaying the current power of each panel I have bar charts visualizing that as well. Here's a screenshot.
All panels in the stack are positioned as layed out on the roof (flat, east/west setup). the different colors indicatie connections to specific inverters.

[TexTown]

5 QS1 inverters, 4 panels each. The bar chart runs up to the max Watt a panel can perform.

[mcattle]

The bar charts are a good idea, and I might add those to my panels. This card also uses the Sun sensor to plot the sun's current position on the card relative to the house (up is due North) so it highlights why, for example, the West-facing panels are currently showing lower numbers than the East and South-facing panels (not shown is a partial tree shadow over the two bottom panels).

[TexTown]

Today the ECU was using cached data for a longer period, but the counter never reached '3'. It went from 0, to max 2, then back to 0.
So my automation never triggered on 3. I changed that trigger to 'above 1' and it ran (rebooting the ECU-R using a smart plug).
After that, the cached data issue was resolved and I'm receiving data again.

Some screenshot of the timeline:

[TexTown]

And, as promised, the Yaml of the automation (pseudo code)

alias: ECU - Powercycle  Unavailable ECU-R
description: Notify me and Powercycle Unavailable ECU-R
triggers:
  - trigger: numeric_state
    entity_id:
      - sensor.ecu_216000000000_using_cache_counter
    above: 1
conditions:
  - condition: sun
    before: sunset
    after: sunrise
    before_offset: + 01:00:00
    after_offset: "- 01:00:00"
actions:
  - data:
      title: Zonnepanelen
      message: ECU-R unavailable, powercycling at {{now().strftime('%H:%M')}}
    action: notify.mobile_app_me
  - type: turn_off
    device_id: 9f3df64f751c49f71a1878146abcdefg
    entity_id: switch.control_outlet_XXXX_on_off
    domain: switch
  - delay:
      hours: 0
      minutes: 0
      seconds: 20
      milliseconds: 0
  - type: turn_on
    device_id: 9f3df64f751c49f71a1878146abcdefg
    entity_id: switch.control_outlet_XXXX_on_off
    domain: switch
mode: single

[HAEdwin]

Good point, I added it to the readme - when you use a smart-plug make sure the UCC is set higher than the value on which you want to reboot the ECU.