Put the locations in quotes.
1 Like
With locations you mean origin and destination? And double quotes?
that’s my working configuration (no quotes in origin/destination) probably works with quote too, I did not check.
- platform: waze_travel_time
origin: 41.xxx, 12.xxx
destination: 41.912974, 12.532184
name: da Casa a Stazione Tiburtina
icon: mdi:train
region: 'EU'quote type doesn’t matter. The only reason I recommend quotes here is because we don’t want the parser thinking that the origin or destination field is a number. We want it to think it’s a string. But, home assistants yaml parser has been getting better and better. They could have these types of things sorted out by now.
Why the vehicle_type was removed?
I’m with ha 0.93.1:
CONF_DESTINATION = 'destination'
CONF_ORIGIN = 'origin'
CONF_INCL_FILTER = 'incl_filter'
CONF_EXCL_FILTER = 'excl_filter'
CONF_REALTIME = 'realtime'
And missing CONF_VEHICLE_TYPE = 'vehicle_type'
Vehicle type was never removed… it’s never existed.
It was planned as an addition to the next build but the PR is stuck in limbo
Would now be a good time to raise this error again?
2019-05-20 09:33:10 ERROR (SyncWorker_2) [homeassistant.components.waze_travel_time.sensor] Error on retrieving data: empty response
Something seems to have happened but I don’t know enough about GitHub to know what it means.
I mean you’re welcome to, I suppose I could create another PR but the last one got ignored. Basically it has sat untouched waiting for merge and approval from the main devs. Coming up on month 3 now.
3 Likes
Got it working perfectly using custom component, hopefully your change will be merged in upcoming versions…
I hope so, it seems I may need to create a separate PR and hope that they don’t put the inprocess flag on it.
Well, there’s good news. I let the PR sit for months and it looks like it merged 10 days ago. Looks like it will be in 0.95
4 Likes
Glad to see the PR was finally merged!
I am on 0.95b0 and unfortunately I am still getting a ton of Error on retrieving data: empty response messages. 336 of those after just four hours of uptime. (I have 13 sensors and the default scan interval of 5 mins). Guessing that Waze API is doing lot more rate limiting in these last few months or something…
couldn’t it have to do with the HA implementation of the waze travel time component after all?
my 94.3 system fails on
- platform: waze_travel_time
name: Waze Amsterdam-Roosendaal
origin: Amsterdam, NL
destination: Roosendaal, NL
region: 'EU'
while 84.3 shows it just fine.
both have a lot of errors, but at least 84.3 doesn’t have issues in the frontend, and creates all it has to
You’re right, I suppose it could be. It always used to work fine for me until a few versions ago (maybe 0.89 or something?). The only problem I remember having before was some JSON Decode error on startup or something like that, but it worked perfectly fine in terms of the routes.
Now it’s failing more often than not, and majority of my Waze sensors are always an hour or more out of date, making them not too useful for automations. And being an hour or more out of date means they’ve failed to update 20+ times in a row which is not good…
I hope that whatever the problem is here it can be identified and fixed. This sensor is great when it works properly.
looks like my changes got pushed but the package changes didn’t. For some reason they removed the requirements=0.10 line and plopped the old broken 0.9 version in. 
Make it a custom component with the requirements being 0.10. I’m guessing it has something to do with the manifest stuff that was added and it will need another PR.
@petro - So we’re still in Beta / RC for 0.95.0, how can we get your correct change in before the GA?
Not sure, I have to investigate how manifests work and I just don’t have the time right now. You can attempt to place the requirement up to 0.10 but I do not know if that works anymore.