Zappi charge mode sometimes reverts seconds after being changed through home assistant #611
Comments
|
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. |
|
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. |
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... |
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).
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? |
|
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 |
|
Thanks, it's reassuring to know it's not just me!
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.
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). |
|
I have the same issue. You are not alone. |
|
same issue here. I have changed polling time to 120 secs, but this did not change anything |
|
It failed to change to stopped for me this morning. Briefly showed stopped but then went back to fast and stayed there. |
|
It's somewhat shortsighted to consider this integration is at fault here. There are so-many intermediaries involved that could cause such issues:
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. |
Are you on Octopus Intelligent ? That will have this effect. |
|
To me it sounds like most of these issues are caused by the IOG integration and as frequently reported on the ME forum... |
|
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. |
|
I am also having this exact issue. |
|
I also have the problem and I do not use Octopus Intelligent. |
|
I started have the same issue more frequently now. For the last 2 years it was very rare. But now it happens every time. It’s really a problem since I use an automation to trigger the charge mode change. The automation runs at night because it’s depends on when the tariffs are cheapest. So the last twp weeks a i have to charge manually when prices are high. |
|
@gijsk are you sure you're not Intelligent Octopus Go and they're commanding your device back to Eco+? |
|
I've got to say it's very surprising the number of people who raise an issue saying 'it keeps resetting back to ECO+' when it's they who setup the Octopus service to do so! And this is another instance. |
|
I have also the problem and I do not use octopus intelligent or another service that use also the zappi. I only use this Integration. I can also confirm that now it happens every time and not only sometimes. So why it keeps resetting when I do not use ocotopus intelligent or something like this? |
|
It appears to be an Home Assistant issue, have you tried rewinding HA to an earlier version (backup) to find out when the issue the issue was introduced? |
|
I do use an Octopus tariff but they only talk directly to the car - when I signed up they didn't seem to know how to deal with the zappi. I am even more sure of this because when I change the mode to "stopped" on the physical zappi and then plug everything in, Octopus schedules slots but the car simply doesn't charge, the zappi stays "stopped", and OI does not do anything about this (frustrating though this may be). I had to write my own automations to switch from (anything else) to Fast when the OI slots appear. Confusingly, in my case the problem is not currently happening for me. It's always been a bit hit and miss, which of course also makes debugging/diagnosis more difficult. The change in functionality doesn't correlate with any changes to HA, this integration, or the zappi (firmware or whatever). If this was really about OI or HA or anything else "changing it back", then I'd expect to be able to see that in zappi logs or when physically observing the device. As the problem is not currently happening for me I can't do testing to make sure of this, but I'm fairly confident this is not what is happening.
Several people have now commented they see this without Octopus.
In that case I would expect the physical state of the device to reflect my change and not the HA change, or for there to be multiple API requests coming from HA and visible in the log, but that is not the case. I guess in theory it's possible HA has some bug where it randomly mangles network requests and fails to log them, but that seems fanciful. I've seen this issue on and off for many months, through many HA releases (I update reasonably quickly when new releases come out). For when the issue returns, it would be useful if there is a reasonable way of inspecting the actual API requests that the integration makes. I haven't found a way to do it, and although I've tried to use the underlying python CLI myself, I can't seem to get the auth bits right (result is always a 401) and I am reluctant to reset the API key and have to reconfigure everything. I also haven't worked out how to obtain the API key and/or password that the integration is using (HA must be storing it somewhere but I can't seem to work out where exactly). |
|
There are many Python examples (links from within ME forum) where you can manually initiate a mode change and see the response. |
|
Back in the day when I started with my integration, I found running the offical app at the same time gave this symptom. Might be worth making sure you kill any running official app as a test. |
|
There's a new comment from MyEnergi on the forum explaining that all the commands received by their servers are sent and not confirmed, and there are some customers who clearly experience local network or inter-device communication issues, which certainly explains why only a few users experience such issues. |
@G6EJD Can you link to the comment in question? This is the third time in this ticket that you have said that something is on the forum, but it is not clear what you are referring to so it is difficult to tie things together. The search function does not really allow me to find the relevant topic just from this description. An obvious question I would have and should probably ask in the relevant forum thread, is whether there is any server-side caching, or if the requests for state are always forwarded to the device by the server and do not return until the device responds. Given the latency I saw in the log in HA (responses <400ms), the latter seems unlikely - especially if all our issues are allegedly due to network issues in our own houses! - but who knows... If, as I suspect, there is some level of server-side caching of state so that the "get" requests can be answered swiftly, it would be helpful if the responses contained some indication of when that state was obtained from the device. I don't know if they do or not as I cannot get the auth part to work without a functioning API key... |
|
Just search for API its comment #8 You have to propagate the authorisation received on the first request to get the data, as I mentioned use a Python example. The problem you have is there are no means to receive or monitor the device responses to a server command, other of course than making an API status call to then extract device status. |
|
|
I have exactly the same problem: But I also notice several error-messages. Like: Logger: homeassistant.helpers.frame Detected that custom integration 'myenergi' calls Can it be related? |
|
A map of the UK rail network? This is highly likely to be an HA issue rather than the integration or you have yet another integration that is setting the mode back again. |
|
Got this working but needed a full pull down of HA Seems to get confused with existing sensors etc. |
See screenshot for what I mean:
What happens is:
(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" } }The text was updated successfully, but these errors were encountered: