Using [CLI] - Error: Unable to convert `3` to PlugState - Dacia spring
Hello,
New to guthub. I hope my question is formaly right.
I am using the renault-api CLI commands and get this error which preclude me from getting any status.
www-data@doma:~/.local/bin$ ./renault-api status
Error: Unable to convert 3 to PlugState.
Context:
- Debian GNU/Linux 10 (buster)
- Python 3.12.4
- renault-api, version 0.2.4
Thanks a lot,
Regards,
I can confirm - same issue here when dacia spring is unplugged.
You can look at this file, where PlugState is defined.
https://github.com/hacf-fr/renault-api/blob/main/src/renault_api/kamereon/enums.py
You can open a PR
I also suggest that you use --debug argument to get the full json
Well, since a few days, it looks like the problem solved by itself, (e.g. was solved by Renault).
plugStatus is set to "0" again when the car is unpluged.
Battery level 58 % Last updated 2024-07-20 12:09:23 Range estimate 132 km Plug state PlugState.UNPLUGGED Charging state ChargeState.NOT_IN_CHARGE Time remaining 5 min Total mileage 30040.0 km GPS Latitude xxx GPS Longitude xxx GPS last updated 2024-07-20 10:47:40 HVAC status off
I voluntarily replaced above the GPS coordinates. They were right.
I will wait a few more days and close this issue.
:-)
Too bad, lpugStatus is back to "3" today.
This has been for a while for me. Maybe around 2 months already. I assumed this is mainly a problem from Renault/Dacia, mainly because I get this status randomly, not just when unplugged, but also plugged.
This also affects the official MyDacia app, where instead of "Unplugged/Plugged" it prints "--"
Also running into this, maybe plugstate 3 should be defined as unknown too. Not completely sure.
yes same here, I confirm (and sorry for the duplicate bug) it seems that State 3 is indeed a "plugged" state do you confirm on your side? (my car is effectively plugged when it happens ).. .even if I have the issue in my app too that sees it has unplugged. The HA plug binary sensor is erroneously as unplugged too in HA, the only one correct is the "charging state" stating waiting for charge I can fo a quick PR on this, but I'm not sure of this state really is.
What you you see from your car when you have this state? to me it seems correlated with "waiting for charge state" ? anyone can confirm?
Just made some experiments here : I do confirm : this new plug state 3 seems to be a "plugged and waiting for charge" one .. probably not supported yet by the renault app
I'm forking, but the HA part will need a fix too unfortunately to set the correct plug (in or not)
v0.2.6 has been released: https://github.com/hacf-fr/renault-api/releases/tag/v0.2.6
In my Dacia spring it seems that plug state 3 becomes set at every start of the car, resulting in a “Plugged in” state on ha even when the car is not
I'm happy to take PRs to revert this to some kind of "unknown" state - neither plugged in nor unplugged
I'm happy to take PRs to revert this to some kind of "unknown" state - neither plugged in nor unplugged
I’m not sure how we would classify that as we already have unknown defined, unknown2?
I think that maybe 3 should be removed from the enum, and "get_plug_status" should be amended to return None if plugStatus is 3.
try:
if self.plugStatus is None:
return None
return enums.PlugState(self.plugStatus)
except ValueError as err:
log_exception(...)
return None
Hi back on this:
# 3 is unconfirmed, as it is currently unsupported on the App (see #1262)
PLUGGED_WAITING_FOR_CHARGE = 3
=> actually I do confirm that for the twinge ZE it was legit and the right value
@epenet : I can see how to submit a PR so this is woking this way for this car perhaps? what would be the best way to still have this value"3" only valid for the Twingo car?
I don't like so much adding a big "if twingo" in the middle of: try: if self.plugStatus is None: return None return enums.PlugState(self.plugStatus)
but if it is the only way? ... do you have a better way / idea to handle car specific stuff like this, something more generic?
Another option would be to expose the number as a second property, as well as the enum. Then people could action on the number even if the enim is None
Yep why not, could be also that this plug state that we expose is not the one from the underlying renault state anymore, but a true translation that is not mapping the numbers one to one from the API. Will see, but from what I see form different callbox and OCPP EV charge box, they have this notion of "CAR _PLUGGED_BUT_WAITING_FOR_CAR_DEMAND" that the state 3 is representing for the twingo at least, so could be consistant that our plug state is following it. Will probably open a new bug on this specifically for the twingo, to keep track and to fix against that.
well actually there is already a data that can be used for that : the chargeStatus one ... will probably just support it properly in HA