Open ungrim97 opened 2 years ago
On version 0.0.20 (Though the const.py file has a "0.0.18" which I believe is a bug as it is the same in the repo for that tag
I see the same error in the HA log. I have just installed the integration, and I have the V2.1 Zappi with built-in hub.
I have the same issue, did you manage to resolve?
Nope. It is very irritating.
On Mon, Dec 12, 2022 at 4:16 PM olej24 @.***> wrote:
I have the same issue, did you manage to resolve?
— Reply to this email directly, view it on GitHub https://github.com/CJNE/ha-myenergi/issues/217#issuecomment-1346816226, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARS4MDPUNPRNYPB2DN5WFDWM5FXFANCNFSM6AAAAAAQAVPX2E . You are receiving this because you authored the thread.Message ID: @.***>
I have the same issue as well. Zappi grid charging shows, but Zappi solar charging does not.
I have the same issue. The myenergi app shows me how much the zappi has charged today, but HA has 0kwh for energy used today. My zappi is new as of October, which I think makes it a V2 device (built in WiFi)?
The API has been changed for V2.1 devices and (of course) MyEnergi has never to this day released any API information, so this issue is much more likely to require someone in the community to reverse engineer the changing API - also rather than posting issues contributors here should be coming up with analysis of the issue together with proposed solutions too!
"also rather than posting issues contributors here should be coming up with analysis of the issue together with proposed solutions too!"
Maintainers should look at the posted issue and provide feedback on how people, who may have no programming knowledge whatsoever, can help rather than being snarky
It’s how GitHub works, it’s not for glibly posting an issue and expecting the problem to be solved, don’t forget this is a free service provided by the wider community and if MyEnergi changes the API which they have, then someone needs to do the analysis and document the new API changes so they can be implemented, who’s going to do that? Well that’s where contributors come in and help out…for the good of all.
Sure, but given that HA is used by many people who have no idea how these things work, they will require assistance providing that analysis.
Indeed I had provided some of that (that unique ids aren't being set on entities) but got no response. Even something as simple as "It looks like the API might have changed, can you make some requests to X urls and record the output here" would be constructive and encourage contribution.
GitHub doesn't "work" in any specific way. Open source software works through a mix of people posting issues, and some people trying to fix them. But it works best when people try to be supportive rather than critical.
This appears to be a fairly big issue for the latest Zappis, which means it will become a bigger issue over time. And it has been 4 months with no response to my issue even asking for additional information. At that stage I assume this is dead software and I stop relying on it and move on.
As I pointed out in my initial post, I am more than happy to assist if I am given direction. I even happen to be a software developer so can likely assist more than others. Though my inclination to do so is waning with passive aggressive responses to people just trying to get information on what could be a bug, but could also just have been poor HA configuration.
On Fri, Jan 27, 2023 at 12:33 PM G6EJD @.***> wrote:
It’s how GitHub works, it’s not for flint posting an issue and expecting the problem to be solved, don’t forget this is a free service provided by the wider community and if MyEnergi changes the API which they have, then someone needs to do the analysis and document the new API changes so they can be implemented, who’s going to do that? Well that’s where contributors come in and help out…for the good of all.
— Reply to this email directly, view it on GitHub https://github.com/CJNE/ha-myenergi/issues/217#issuecomment-1406439885, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARS4MCP3YIYYU4TQS3ZJFLWUO6ATANCNFSM6AAAAAAQAVPX2E . You are receiving this because you authored the thread.Message ID: @.***>
I'd actually argue that this is exactly what posting issues is for? I mean, don't get me wrong - my post was not a complaint, but for me personally, the project states it does a thing that it doesn't. Whether that's because of a bug or a change in the Myenergi API is irrelevant. Like I said, my post was not a complaint. I was simply adding weight to the argument that it's likely related to later versions of the Zappi - i.e. helping to pinpoint the issue
, which will hopefully make it easier for someone to identify and fix.
I'm also a software developer, but HA is new to me, and I'm not particularly familiar with python either. Given that it appears to be only two values not being populated, it may just be a case of these properties being renamed in the API. When I get time, I can take a look.
I was looking into this issue as I noticed my value for sensor.myenergi_$sensorname_energy_used_today
was showing no value. I think the value ha-myenergi tries to use is actually the wrong value and it uses the amount of power that is charted by boosting.
I noticed that base_device.py
in the used `pymyenergi' lib does this:
"device_total": round(
(energy_wh["h1b"] + energy_wh["h2b"] + energy_wh["h3b"]) / 1000, 2
),
But according to https://myenergi.info/viewtopic.php?p=30705#p30705 h1b, h2b and h3b are the values used for boost mode.
To test this theory I boosted my Zappi and after a few minutes I now have a value of "0,29kWh". Can someone else verify this observation?
Using the api in the GitHub link I’ve managed to test a few days and can reconcile back usage roughly to the app for Zappi and eddi. (After converting from joules). however, my zappi is recording both solar and grid charge through h1d and nothing through h1b. My eddi is recording solar charge through h1d and grid charge through h1d as expected. presumably the Zappi is setup wrong and hence it’s not showing up in HA. Is this likely to be a setting on the device or placement of CT clamp?
I’ve just tried a manual boost in the myenergi app and this comes through as h1b. But I don’t ever use this to charge the car. I either use eco+ to charge via solar or set to fast and use intelligent octopus tariff to manually charge. I’d assumed this counted as “boost” but appears to show as divert still. But I think chkron is right, the coding doesn’t work above for my setup. Where is the file you mention above stored and is it as simple as going into it and amending the h1b to h1d?
h1boost
h1b is boosted (manual, smart or scheduled) h1d is diverted
If you boost when the sun is shining it's possible to have both h1b and h1d where some of the energy going to your EV is supplied by excess micro generation, (or storage battery discharge,) rather than grid import.
[...] Where is the file you mention above stored and is it as simple as going into it and amending the h1b to h1d?
It's in the pymyenergi lib this project uses from the same maintainer.
I'd suggest renaming the value to "boosted" will clear up things.
But I have no idea what values actually contain the total consumption or at least allow us to calculate the overall value.
If we somehow can figure this out I'd try to create a patch.
Thanks for researching and sorry for the lack of response from my part, I haven't had much time to look in to this. I have the old hardware as well which makes it difficult to analyze the data. I'm happy to implement any change you collectively come to an agreement on though 👍
I am using the cgi-jday-Z data in a little web app. I collate the h1b and h1d values into 'charging sessions' based on when there is a gap between the minutes and divide each total by 3600000 to convert to kWh.
I have single phase supply.
The 'logs' count in my screenshot is the number of minute data rows returned by cgi-jday-Z(appi) and cgi-jday-E(ddi)
Thanks, that would be appreciated. are we able to agree to add h1d to the sensor: sensor.myenergi_$sensorname_energy_used_today?
@LeiChat So basically the sum of boosted and diverted is the power used, right? (h1b+h2b+h3b+h1d+h2d+h3d)
I've forked @CJNE's pymyenergi repository and changed the code to reflect this. See https://github.com/CJNE/pymyenergi/commit/d6d443d4dc5c3b64fa31ad4b2c9237c35e253c4a for details.
If someone could confirm this I can create a PR for the base library used in the integration. After the verification I also could get started on creating a change for the integration or Johan could change the integration afterwards.
Hi any update on this?
I'm happy to merge a PR in pymyenrgi, let me know if there's anything I can do to help!
@CJNE i created https://github.com/CJNE/pymyenergi/pull/6 as the foundation for the fix/change.
Could you maybe do the appropriate changes in the HASS-Integration if you have some time? Otherwise let me know and I'll try to set up a dev environment to do the changes myself.
Thanks for the PR @chkorn, it's now merged. I can do the change to the integration, is there anything else than using the updated pymyenergi version that is required? This issue was originally another problem, that the hub green energy today sensor had a name conflict with the zappi green energy today sensor. I've renamed the hub "Green energy today" sensor to "Total green energy today", which should fix that issue.
On a possibly related note, can an integration define a default of zero for an entity/sensor that has no calculated value based on the days API data?
I'm now familiar with using | default(0)
in Home Assistant templating to define a value that should be returned when the entity doesn't return a value but, I have just noticed 'sensor.myenergizappi*****_charge_added_session' is returning 'unknown' for my zappi today. Correct in the sense that it hasn't added any charge since the cable was plugged in to the car but it would be nicer if it returned 0, so the card would display 0kWh rather than 'unknown'. Apologies, not exactly related to the entities mentioned in #217 but thought I would avoid raising another issue as my request might apply to these entities too.
@CJNE any date on the release of this change?
@CJNE I have a Zappi 2.1 and encountering this issue, I'd be happy to test if you push your dev branch
Any progress on this getting rolled into a release? Happy to test as well.
Does [sensor.myenergi_home_green_energy_today] use the zappi green energy entity? (Is it a sum of the various device_green values?) Will that be automatically fixed when #217 is fixed?
@chkorn Just having a nose at your pymyenergi fork. Is there a reason to include the division by 1000 and rounding? Why not leave it in Wh?
@LeiChat the calculation was already done in the original code so I just went along with it. Most likely Home Assistant will require power data as kW, as this is the common unit used.
@CJNE Sorry, I totally missed your question a while back. No further changes required if I remember correctly. Total energy should be fixed with the merge.
Apologies, you are correct. I had a nose at a few other integrations and they all seem to specify kWh as the unit_of_measurment. As the myenergi API returns Ws (which is being divided by 3,600 for Wh in the pymyenergi library) my preference would be to not round the kWh value to two decimal places, just for the benefit to value captured by HA's long-term statistics.
My Zappi energy used values aren't being populated at the moment. (
sensor.myeneri_zappi_$id_energy_used_today
) is always 0 regardless of charge added. And thesensor.myenergi_zappi_$id_green_energy_used_today
) sensor doesn't exist.The latter is likely related to the error I get in HA logs:
Which I think is suggesting that the Hubs green energy used today sensor is somehow conflicting with the zappis one?
Not entirely sure if this is a bug with the integration or just a oddity of the fact that I have had 3 Zappis in quick succession (I had 2 replaced with faults) and the latest one is the V2 with built in vHub
DEBUG log for pymyenergi & custom_component.myenergi:
But there isn't really anything there
Happy to provide more info as needed