Upgrade Issues

[tamorgen]

Good morning,
I apologize if this subject has been covered. I did try the search, but I'm not coming up with any topics on my issue.

I'm running userauth-24137-57b41335, bare metal installation on Fedora 39 Server.

I have a rule set up to turn the Eco mode off on my Nest Thermostat when the thermostat is set to Away (Rule State: Away Mode), the user (Driver) presence in my car changes to true, and the destination is set to home.

This works fine for most days, where I'm headed home from work (commute is about 45 minutes). What I don't want it to do is set change it to Eco mode if my ETA is more than an hour.

There is a sensor/entity for Time to Arrival when the Destination is set. What it appears to provide is the Time OF arrival/ETA, not time until arrival. If it was Time until Arrival, and it was a numeric value, I could simply test if the value is less than 60 and be done with it.

I pulled up the history through Home Assistant for my morning commute and this appears to be what it is providing.

So what I need to do is to do a calculation of the the ETA from the sensor value and subtract the current time, and get a value in minutes that I can determine if it's less than 60.

I believe I can do this with the local expression, but I don't see anything for the system time, or local time. Also, do the local expressions update themselves if the sensors do?

[toggledbits]

@tamorgen said in Need assistance: How do I calculate time based upon current time and an ETA:

I don't see anything for the system time, or local time.

In the docs, Date/Time Handling Functions.

@tamorgen said in Need assistance: How do I calculate time based upon current time and an ETA:

do the local expressions update themselves if the sensors do?

Absolutely.

[tamorgen]

@toggledbits said in Need assistance: How do I calculate time based upon current time and an ETA:

In the docs, Date/Time Handling Functions.

Okay, I missed that. That raises more questions.

I'm thinking it's easier to convert my ETA sensor to Unix Epic, and then do the math from there, correct? Do you have any examples on how I would go about doing this?

I went to lunch and pulled up MSR so I could get the actual, real time output of time to a destination.

[tamorgen]

I tested using a static unix epoch time, and I pulled the time for one of my other sensor so I can work on testing the conversion.....

Getting there.

[tamorgen]

And I figured it out....

[tamorgen]

May have spoke too soon....

Since the current value is null, it's going to throw a yellow triangle, because it can't be evaluated.

@toggledbits Is there a way to clear that flag for a local expression that is only periodically filled?

Correction: the value for the sensor is "unavailable", not null....

The value for the local expression becomes "null", because of the "unavailable" value for the sensor.

[tamorgen]

It also throws an error in the status pane.

[toggledbits]

Try this:

D=getEntity( "hass>sensor_spaceball_1_time_to_arrival" ).attributes.string_sensor?.value,
if "unavailable" === D
  then null
  else do
    D = time( D ),
    D = isNaN( D ) ? null : round( ( D - time() ) / 60000 )
  done
endif

The first line sets up the attribute value in a temporary local variable (i.e. available only inside the expression) called eta.

Line 2 checks to see if it's the string unavailable, and if so, line 3 will cause this expression to produce null as a result.

Otherwise, the else block beginning at line 4 starts by converting the string in eta to a time in milliseconds (line 5), and if that result isn't NaN (line 6), then the difference between that time and now in minutes is computed.

The test ? true-expr : false-expr form on line 6 is a ternary operator, if you haven't used it before. It's equivalent to IF test THEN true-expr ELSE false-expr ENDIF, just shorter.

[tamorgen]

@toggledbits,
Thank you Patrick. It's not throwing an alert now. Very elegant solution.

I'll verify that it works once I get in the car after work and marked the thread as solved.