I kind of confirmed your observation, as I restarted HA during the time my car was charging, and the sensor.XXX_charging_power was populated.
Regarding your question: For parameters that tend to change quickly and infrequent (i.e. charging power - jumping from none to 11kW, to 150kW or so), I would prefer a “0” as the default.
For parameters that tend to change slowly (i.e. (average) consumption), your idea of using the last known value seems the right idea.
Or could a “none” (or the HA equivalent) work here?
On a related note: I noticed that the attribute “chargingstatus” (inside sensor.XXX_range_electric) looks like an integer, but is coded as a string.
Is that something that the MB API spits out, or a conscious decision on your part? I’m good either way, just did cost me some hours figuring out why my comparison to 0 (as the number) failed.
thanks for the feedback. Could you give a little bit more background on what was missing before you enabled “Disable cap checks”? I implemented this option for US market some years ago and it should have no effect in Europe.
BR Rene
ReneNulschDE
(Rene Nulsch (on vacation until mid of Oct. - expect slower responses))
1650
thanks for your feedback. Let me try to implement this, I will start with the “0”-Default Value sensors…
Regarding:
Yes, all the values should be strings as the MB-API delivers the values as string. (and the API gives also a hint regarding the type but I never found the energy or value to implement this) - Therefore: All attributes should be handled like strings.
just noticed the update of the integration, with the included buttons for the pre-entry climate.
I just want to share my previous solution, a simple toggle switch, and looking for both the commanded pre-entry climate, as well as the timer based one.
Put the code I shared into configuration.yaml (if you already have a section called “switch:”, put the code without the switch: part below your definition, before the next section starts).
Do not forget to change the sensor.XXX to your sensor name, and change the vin W1Kxxx to your VIN.
ReneNulschDE
(Rene Nulsch (on vacation until mid of Oct. - expect slower responses))
1655
418, message=“I’m a teapot”,
The integration is not working right now. For some of you the teapot error is not new, means MB changed their APIs again and gave me a christmas present…
Update 1: The code in the master branch on github should work for Europe again. Working on the other regions and plan to push a release soon.
1 Like
ReneNulschDE
(Rene Nulsch (on vacation until mid of Oct. - expect slower responses))
1656
I have published an Hotfix Release to address the teapot error. As always something new was in the making and is part of the release too. (Even it is not 100% final - but should work) v0.9.8 - Teapots, Windows, TranslationsLatest
IMPORTANT
Please open your MB mobile app and check if you have to accept new terms & conditions.
Fixes
Teapot error message fix for (hopefully) all regions (fixed: #159) - Can’t test this for all regions but US and EU looks good
The option to reload the component in the frontend was removed for now - please restart HA in case of problems (fixed: internal)
FIN/VIN is masked in the homeassistant.log now
New
Some attributes of the Lock sensor have translated names and values now. This is in the frontend only and should have no impact on automations, scripts and so on. English only. Use the developer-tools/states function to see the original values if needed.
Internal
There is an early support for default value handling for sensors. Its disabled for now but should solve the “missing sensor at startup”-problem in the future. (In case you miss for example the chargingkw sensor, get in touch with me whenever you want to test this)
On December 15th, my Mercedes Me (mbapi2020) all of a sudden stopped working: There is no error message in the integration or the device, but all entities are ‘unavailable’.
I don’t find error messages when I enable debug loggin on the intergation. Just these messages:
Hi Rene,
thanks for the reply.
One of the actions I did to try to solve the issue, was indeed to upgrade to the latest version. Both home-assistant and the MercedesMe2020 code.
I tried and tried again re-configuring the integration and never got it working. I did notice that the integration saw no problems but no entities were active.
In home-assistant.log (now already replaced by a new version), I noticed that the Mercedes cloud api reported no cars found, with the data sent to it.
In the end I deleted the configuration and the .mercedesme-token-cache and reconfigured everything. Than it worked and the car’s details all came back correctly, with the same name as before.
I don’t know what was at the root of all of this and I’m afraid the data to find out are already gone.
But I’m a happy user again.
Happy holidays,
Wim
1 Like
ReneNulschDE
(Rene Nulsch (on vacation until mid of Oct. - expect slower responses))
1666
I have published a new minor release v0.9.9 to keep up with some changes in HA 2024.01.
Notable changes:
Sensor “Charging Power” gets created even if the API does not provide values at HA startup.
Fixes:
Removal of a couple of deprecation warnings that otherwise would appear in Home Assistant 2024.1.0
Notes:
The sensor “charging power” is created for all vehicles, even if the vehicle has no charging options. Please ignore or hide the sensor if needed. Thanks to @Thomas01 and @Markus76 for testing.