Closed jdeneef closed 3 months ago
The reason you're seeing this is https://github.com/bimmerconnected/bimmer_connected/pull/606.
Can you please provide the debug info? In the fingerprints
part of that the original BMW response is available.
Needed some time to figure out the fingerprint stuff, but was actually easy when I knew where to look (as in in my homeassistant docker). Time stuff from the fingerprint see below json. Note that this can probably also be fixed with some templating in the frontend, will try and find something there too.
As clearly visible: timestamp | fingerprint | app | homeassistant |
---|---|---|---|
timeslot start | "0001-01-01T13:30:00" | 1:30 PM | 2024-05-25T13:30:00+00:00 |
timeslot end | "0001-01-01T16:00:00" | 4:00 PM | |
departure time | "0001-01-01T19:00:00" | 19:00 TODAY |
For the home assistant timestamp homeassistant will translate this to "in 5 hours" at the moment which is +2hrs, which again makes sense, the TZ = +00:00 where in my case this should be +02:00 (aka CET) or possibly not be there at all? Same happens for when charging end time is set. Departure time is not available in homeassistant, while it is in the fingerprint?
testing in template editor: code | result |
---|---|
in {{ relative_time(now() - (as_datetime("2024-05-25T14:00:00+00:00")-now())) }} |
in 5 hours |
in {{ relative_time(now() - (as_datetime("2024-05-25T14:00:00+02:00")-now())) }} |
in 3 hours |
{
...,
"chargeAndClimateTimerDetail": {
"chargingMode": {
"chargingPreference": "CHARGING_WINDOW",
"endTimeSlot": "0001-01-01T16:00:00",
"startTimeSlot": "0001-01-01T13:30:00",
"type": "TIME_SLOT"
},
"departureTimer": {
"type": "TWO_DEPARTURE_TIMER",
"weeklyTimers": [
{
"daysOfTheWeek": [],
"id": 1,
"time": "0001-01-01T19:00:00",
"timerAction": "ACTIVATE"
},
]
},
...
}
(short bmw app rant, but could be relevant): Note that the app also shows differing time formatting AM/PM and 24hrs mixed, which has been that way since at least 2016 (previous car was 2016 model, currently 2019 model) the app could use some loving on this. Same goes for when I update from charging from app, it ends up in the car but feedback to app/homeassistant is always messed up afterwards. Most likely bmw server side issue, something we can't fix here.
short addition, I found a workaround which might be good enough for now, it's a bit of a cheat though, more info still shows the original info .. In frontend use:
type: custom:template-entity-row
entity: sensor.bmw_charging_start_time
tapaction: more-info
icon: mdi:clock-start
state: |-
{%- set t = strptime(states("sensor.bmw_charging_start_time")[0:16], "%Y-%m-%dT%H:%M", "unknown") %}
{%- if t == "unknown" %}
-
{%- else %}
{%- set t = t | as_local %}
{%- if t > now() %}
in {{ relative_time(now() - (t - now())) }}
{%- else %}
{{ relative_time(t | as_local) }} ago
{%- endif %}
{%- endif %}
Note that this is using an entries card with custom addon lovelace-template-entity-row
edit: should now automatically pick your local timezone
Can you please provide a full diagnostics lot from home assistant? This would help a lot to make sure the issue is fixes directly.
ok here you go. I did remove remaining specifics like gcid
and sessionId
, wasn't sure if that meant anything ..
Thanks!
As https://github.com/home-assistant/core/pull/118179 got merged, this should be fixed in HA 2024.6.0.
Would it be possible for you to install the 2024.6 beta when released on wednesday and test it out? If there is still something not working as expected, we could fix it during beta.
On friday I could, don't have much time on wednesday, or thursday, srry, but I will try asap, will let you know
Thanks, anything before Wednesday next week is perfect. Otherwise we put any changes into a minor release
Tested with todays dev
version which includes bimmerconnected v15.3
and timestamp returned for bmw_charging_start_time
nicely returns the correct time whereas the homeassistant stable
version still returns 2 hours later.
time in app 4 AM
time in homeassistant 2024-05-29T02:00:00+00:00
adding timezone is 04:00
; delta_time calculation is also correct now
Thanx for fixing!
Perfect, many thanks for testing!
We also now have a valid way forward whenever BMW doesn't provide correct timestamps.
fwiw, installed latest ha and tested both planned charging and immediate charging, fix is working nicely, so for both start and end of charging bmw times! thanx for the fix!
Describe the issue
bmw_charging_start_time
andbmw_charging_end_time
in homeassistant have incorrect or missing TZ info, and are thereby shifted two hours in the future (in my case for timezone CET). Where charing started at 14:00 local timesensor.bmw_charging_start_time
reports2024-05-20T14:00:00+00:00
. I can't find what BMW servers are reporting. This issue could be related to #441Expected behavior
return bmw_charging_times with correct timezone info
Which Home Assistant version are you using?
2024.5.4
What was the last working version of Home Assistant Core?
No response
What is your region?
Rest of world
MyBMW website
Number of cars
Output of bimmer_connected fingerprint
No response
Anything in the logs that might be useful for us?
Additional information
No response