Zappi charge mode sometimes reverts seconds after being changed through home assistant

[gijsk]

See screenshot for what I mean:

What happens is:

1. I use a HA widget to change the charge mode to "Fast" (in this instance, but I've seen this with any change)
2. this appears to work (as far as I can tell from HA)
3. a few seconds later, HA updates the charge mode to go back to whatever it was before, registering another change in the logbook. This change corresponds to the refresh times in the logs (ie it must be updating the state based on fetching state from the zappi)

(and then in this instance, I change it in HA again, and this time the change "works".)

I've also seen this happen with automations, which ends up breaking their logic as they do not expect that their changes sometimes get "revoked".

Version of the custom_component

0.0.29

Debug log

I turned on debug logging but the only thing in the log relevant to myenergi is messages every minute that it is doing "Refresh history local start of day in UTC [datestamp UTC]" followed by "Finished fetching myenergi data in 0.358 seconds (success: True)". As noted above the timing of these corresponds to when the charge mode "resets" to what it was previously.

Config

{
  "integration_manifest": {
    "domain": "myenergi",
    "name": "myenergi",
    "codeowners": [
      "cjne"
    ],
    "config_flow": true,
    "dependencies": [],
    "documentation": "https://github.com/cjne/ha-myenergi",
    "iot_class": "cloud_polling",
    "issue_tracker": "https://github.com/cjne/ha-myenergi/issues",
    "requirements": [
      "pymyenergi==0.2.2"
    ],
    "version": "0.0.29",
    "is_built_in": false,
    "overwrites_built_in": false
  },
  "setup_times": {
    "null": {
      "setup": 3.9619999999018773e-05
    },
    "8a52c3ed1dcec970ab068da26e00ff34": {
      "wait_import_platforms": -2.2659578200000006,
      "wait_base_component": -0.00023066400000004705,
      "config_entry_setup": 3.1010098809999995
    }
  },
  "data": {
    "[sno removed]": {
      "deviceClass": "HARVI",
      "dat": "02-01-2025",
      "tim": "09:30:17",
      "ectp1": -12,
      "ectp2": 353,
      "ectp3": 0,
      "ectt1": "Grid",
      "ectt2": "Generation & Battery",
      "ectt3": "None",
      "ect1p": 1,
      "ect2p": 1,
      "ect3p": 1,
      "fwv": "3170S0.000",
      "productCode": "3170"
    },
    "[sno removed]": {
      "deviceClass": "ZAPPI",
      "dat": "02-01-2025",
      "tim": "09:30:17",
      "ectp1": 0,
      "ectp2": 0,
      "ectp3": 0,
      "ectt1": "Internal Load",
      "ectt2": "None",
      "ectt3": "None",
      "bsm": 0,
      "bst": 0,
      "dst": 1,
      "div": 0,
      "frq": 50.05,
      "gen": 0,
      "grd": -38,
      "pha": 1,
      "pri": 1,
      "sta": 1,
      "tz": 0,
      "vol": 2377,
      "che": 14.18,
      "isVHubEnabled": true,
      "bss": 0,
      "lck": 24,
      "pst": "B1",
      "zmo": 4,
      "pwm": 4999,
      "zs": 13570,
      "rdc": 1,
      "rac": 4,
      "zsh": 53,
      "zsl": 2,
      "ectt4": "None",
      "ectt5": "None",
      "ectt6": "None",
      "beingTamperedWith": false,
      "batteryDischargeEnabled": false,
      "g100LockoutState": "NONE",
      "phaseSetting": "SINGLE_PHASE",
      "wifiLink": true,
      "ethernetLink": false,
      "ocppEnabled": false,
      "mgl": 100,
      "sbh": 17,
      "sbk": 5,
      "sbm": 0,
      "fwv": "3562S5.542",
      "cmt": 254,
      "newAppAvailable": false,
      "newBootloaderAvailable": false,
      "productCode": "3562"
    }
}

[G6EJD]

It's odd that there are no other reports of this issue occurring, this suggests you have another activity running that is making changes. The most common is an integration with your energy supplier or that you have added some form of automation that is creating this effect.

[LeiChat]

Might it just be that the myenergi servers take a while to communicate and confirm your requested change with your zappi and in the meantime, the HA integration reads the 'current' state from the myenergi API which is not, at that moment, aware of the state change you've requested.

Similar behaviour is observable in the myenergi app, which generally takes a while to make amendments to boost schedules, etc. and sometimes appears to ignore the change you requested.

[gijsk]

It's odd that there are no other reports of this issue occurring, this suggests you have another activity running that is making changes. The most common is an integration with your energy supplier or that you have added some form of automation that is creating this effect.

In that case I would expect the log view for the entity to show those changes as having come from the other integration in question, which it doesn't. It'd also be super surprising that the timing of the "reverting" change would correspond exactly with when the log indicates the myenergi integration is polling for state...

[gijsk]

Might it just be that the myenergi servers take a while to communicate and confirm your requested change with your zappi and in the meantime, the HA integration reads the 'current' state from the myenergi API which is not, at that moment, aware of the state change you've requested.

Does the myenergi API give no indication of when the change propagates? (ie is the http response an optimistic 200 OK but a subsequent poll produces old data? That would be... disappointing).

Similar behaviour is observable in the myenergi app, which generally takes a while to make amendments to boost schedules, etc. and sometimes appears to ignore the change you requested.

Huh, that is interesting, I've pretty much stopped using the app because of this integration...

I do agree it's surprising that nobody else has this problem - perhaps the wifi connection on my zappi is dodgy enough that it just takes longer for the change to propagate in my case? AFAICR the 60 second polling interval that the integration is using on my end was the default, though I suppose it's possible I've forgotten that I changed that?

[FatBeard]

Hi. I've noticed this problem too over the past few weeks (May have been going on longer). Usually when I'm changing from fast to stopped. My assumption was it's an api delay. Ha requests the entity is stopped, changes the entity directly, the my energy api takes time to update the zappi. In the mean time the my energy integration gets an update of the status from the api (separate call i assume) and it's still in fast mode. Ultimately it goes back to stopped but it can take several minutes to do so. In the mean time my car is still charging.

I will note that I believe the call failed completely on one occasion and remained in charge mode

[gijsk]

Thanks, it's reassuring to know it's not just me!

AFAICR the 60 second polling interval that the integration is using on my end was the default, though I suppose it's possible I've forgotten that I changed that?

I checked, the default is indeed 60 seconds. So a poor man's fix might be to increase the interval such that it is less likely that the change has not propagated to the "read" side since it was "written". 60 seconds does seem frequent for cloud polling, though I suppose for some sensors (like the amount charged or current wattage on CT sensors) that is somewhat necessary for effective use. Local polling would be better but I'm aware myenergi do not document/support doing that.

It's odd that there are no other reports of this issue occurring, this suggests you have another activity running that is making changes. The most common is an integration with your energy supplier or that you have added some form of automation that is creating this effect.

One other thing that I thought of later is that in theory there could be some other consumer of the myenergi API outside of home assistant that is doing this - but then I wouldn't expect it to "eventually" settle to the value chosen in HA (as outlined by @FatBeard ), and it would be somewhat weird that it would happen repeatedly. I'm also not aware of hypothetical other consumers like that - although I use the octopus energy HACS integration, and octopus talk to my car, AFAIK they don't touch the charger (though I told them I had it... they seem to prefer talking to the car).

[greytuk]

I have the same issue. You are not alone.

[zorak1103]

same issue here. I have changed polling time to 120 secs, but this did not change anything

[FatBeard]

It failed to change to stopped for me this morning. Briefly showed stopped but then went back to fast and stayed there.

[G6EJD]

It's somewhat shortsighted to consider this integration is at fault here. There are so-many intermediaries involved that could cause such issues:

1. The RF link between the Hub and Zappi.
2. The atmosphere such as high humidity absorbs RF energy rendering the link spasmodic.
3. Electrical noise in your vicinity.
4. Poor hub or Zappi installation and installation errors
5. The link between the hub and Router
6. The Router.
7. The Broadband service provider may be providing a slow or intermittent service especially at night.
8. The MyEnergi servers.
9. The internet overall performance.
10. The Home Assistant platform or operating system.

And so-on, oh it must be the integration...

It's apparent that only a small percentage of users are experiencing issues and one only has to watch the MyEnergi forum to see the near daily constant stream of My Zappi won't charge issues emerging and nearly all are associated with an incorrect installation or local communication issues.

You really need to be doing your own local investigations to get your systems running correctly before posting an issue that is clearly not one.

[plord12]

a few seconds later, HA updates the charge mode to go back to whatever it was before, registering another change in the logbook. This change corresponds to the refresh times in the logs (ie it must be updating the state based on fetching state from the zappi)

Are you on Octopus Intelligent ? That will have this effect.

[G6EJD]

To me it sounds like most of these issues are caused by the IOG integration and as frequently reported on the ME forum...

[AJediIAm]

I posted a work around here: #616 (comment) but I haven't tested it yet since I don't experience the issue myself. I hope it helps and please share any improvements.

It's not a permanent solution, so let's continue the investigation to find the root cause in a constructive way.

[finalbillybong]

I am also having this exact issue.

[t785634]

I also have the problem and I do not use Octopus Intelligent.