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.
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
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.
@petro - I think all that is required is in this PR. I’ve gone ahead and submitted it and lets see if the tests pass… Might help if you chimed in on my PR and “blessed it” as you are the original PR author. Thanks
No, that is the old way. The new way uses manifests and that PR will never go through, which is why it wasn’t done in the first place when it was merged.
That is the new way. The manifest doesn’t exist in the current version.
My PR appears to be green at this point, so perhaps you can chime in and bless that ?
Looks like it’s going to get merged so we good. Still going to have to add a manifest at a later date.
Appears to have been merged in 0.95 and so far the initial results are looking very promising.
I only got a few “Error on retrieving data: empty response” errors right after startup and only a handful have come in after that in the last 24 hours. Before this PR those errors would be flowing in non-stop and I’d have literally thousands of errors in my logs at this point.
I’m still a little confused on how exactly the sensors get updated though. From my limited testing, it appears when I’m away from home they update faster and more consistently. When I’m home for awhile, some of the Waze sensors can often go an hour before being updated. Not sure if that’s an intentional thing (possibly to prevent necessary updates if device_tracker location hasn’t changed in a while?) Or maybe it’s just a coincidence?
Thanks for getting this fixed and merged.