Custom Component: here_travel_time

klogg · July 16, 2019, 12:07pm

Yeah, fair enough. I think I knew that there would be people who liked it as it was!

Yes it is… My main ‘issue’ is the truncated route.
But whatever @eifinger chooses to do, I’m basically very happy!

klogg · July 16, 2019, 3:24pm

Did you get a chance to look at what the default scan_interval is?

I have 5 sensors set up and my dashboard shows that I have used very nearly 27,000 api calls in only about three days:

At that rate I think I will go through the 250,000 limit well within a month.

eifinger · July 16, 2019, 4:33pm

New Release: v.1.2.0

Breaking Changes

Default scan_interval changed from 30 seconds to 300 seconds (5 minutes). This can be overridden by defining scan_interval in the configuration.

Changes

Included information for scan_interval in the docs (info.md and README.md)
Included information for unit_system in the docs (info.md and README.md)

Features

Bugfixes

@klogg: The possibility to change the unit_system was there all along. I forgot to put in in the docs. Sorry
The default scan_interval for sensors is 30s. I set the default to 300s. This can be changed by defining scan_interval in the configuration for each sensor.

@JozMar: Your error is fixed in this release. Its actually a wrong configuration of the sensor itself but now you should get a meaningful error message that helps you fix it. Please let me know if this works for you.

eifinger · July 16, 2019, 4:48pm

I am sorry I did not really get your point. Could you try to explain it again?

Currently the implementation is:

traffic_mode: true Returns the actual current value
traffic_mode: false Returns estimated value based on historic data

I also found out that you can provide departure or arrival options. I will implement them in the future.

eifinger · July 16, 2019, 4:52pm

Does the truncate only happen on the state/lovelace representation of the sensor? Could you check under /dev-state if the attribute value is truncated there also?

If not you could implement your own truncate algorithm with a template sensor until I have decided on the best implementation option.

Holdestmade · July 16, 2019, 6:55pm

Just updated to 1.2.0, changed to imperial units and now the distance and duration are shown in about 10 decimal places, is it possible to round it to 1 decimal place ?

Thanks

Pirol_62 · July 16, 2019, 6:56pm

Ah, that was the information I asked for.
My understanding was, that Here combines both methods. If you plan a long distance journey, it calculates on the one hand the current traffic. But as you will arrive your destination maybe in several hours, here uses historical information of the destination to estimate the duration more accurate.
I wasn’t sure, if that is a special function only for professional use.
Thanks

eifinger · July 16, 2019, 7:46pm

Is there an usecase which can’t be implemented by an template sensor which rounds the value?

Holdestmade · July 16, 2019, 8:04pm

No I guess not but I’d have to make 2 template sensors for each of the HERE sensors ? Would just be nice in each of the HERE sensors. Not a problem though, was just a suggestion. Thanks again for making this.

eifinger · July 16, 2019, 8:14pm

I’m glad you have a use for it. I don’t want to force a rounded value as I’m sure somebody else does have a use for it

VDRainer · July 17, 2019, 9:17am

My log fills with

2019-07-17 11:07:01 ERROR (MainThread) [homeassistant.helpers.entity] Update for sensor.home_to_work fails
Traceback (most recent call last):
  File "/srv/ha/lib/python3.7/site-packages/homeassistant/helpers/entity.py", line 221, in async_update_ha_state
    await self.async_device_update()
  File "/srv/ha/lib/python3.7/site-packages/homeassistant/helpers/entity.py", line 380, in async_device_update
    await self.hass.async_add_executor_job(self.update)
  File "/usr/lib/python3.7/concurrent/futures/thread.py", line 57, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/home/homeassi/.homeassistant/custom_components/here_travel_time/sensor.py", line 215, in update
    self._here_data.update()
  File "/home/homeassi/.homeassistant/custom_components/here_travel_time/sensor.py", line 293, in update
    if not re.fullmatch(pattern, self.origin):
  File "/srv/ha/lib/python3.7/re.py", line 178, in fullmatch
    return _compile(pattern, flags).fullmatch(string)
TypeError: expected string or bytes-like object

Does anyone else see this?

eifinger · July 17, 2019, 10:07am

Could you please open an issue for that with the version installed, your config etc under https://github.com/eifinger/here_travel_time/issues

Thank you

VDRainer · July 17, 2019, 10:42am

Sure…done.

Holdestmade · July 17, 2019, 10:50am

Yes I’ve the same errors, added a comment on Github

Holdestmade · July 17, 2019, 10:55am

Don’t know if you changed anything but durations are now with only 2 decimal places. The distance is still showing 51.017060367454064, not sure if that accuracy is needed !

Pirol62 · July 17, 2019, 11:19am

Hi, tip for all who are struggeling with this extremely accurate duration and distance:
Use the waze-card.
Looks like this

You can get it in hacs
Config:

entities:
  - entity: sensor.here_sensor1
    name: way to destination
    zone: zone.destination
  - entity: sensor.here2
    name: back
    zone: zone.home
title: Way to work
type: 'custom:waze-card'

@eifinger
Thanks for the changes. Works great now.

eifinger · July 17, 2019, 11:37am

@Holdestmade @VDRainer I identified the bug and will release a fix soon.

eifinger · July 17, 2019, 12:18pm

New Release v1.2.1

Breaking Changes

Changes

Component should now be async

Features

Bugfixes

Fix TypeError: expected string or bytes-like object

Pirol62 · July 17, 2019, 1:37pm

Upgraded, works without issues

Holdestmade · July 17, 2019, 1:48pm

Deprecated - replaced by this: