[BUG]: Graceful decay of timed-out sensor

[jebissell]

I am back at it with Rome's ATAC bus network. Recent GTFS2 updates have made the sensors more-reliable, but there are still intermittent timeouts typically lasting 2 to 10 minutes making the sensor unavailable. (This is an ATAC problem, since even their countdown signs at the bus stops go unavailable.)

In other posts I read that your general philosophy is that a missed update should make a sensor unavailable. I already use a Home Assistant to substitute scheduled departures where real-time data is not available in the attributes.

Is there a GTFS2 setting or feature that would be more-permissive about missing one or two calls to the RT data?

I am using the sensors to populate a customized countdown for home and work locations, so displaying scheduled departures in the absence of RT departures is still acceptable. If GTFS2 can't be modified, my alternative approach is to store the last valid sensor update in Home Assistant, then use a template to substitute the stored update for up to 15 minutes if the update timed out and the sensor became unavailable.

[vingerha]

You would have to specify 'making the sensor unavailable'. If it is static then this should not happen at all unless the static data source disappears. But I assume that you mean the RT attributes only (not the whole sensor).

I am not sure right now what the code does but I can try to keep the last RT value untill that time has passed as it loses its value after that. If no new RT data is received, then what would you expect?

[jebissell]

In the case of Rome ATAC, it appears the entire result, both schedule (next departures) and RT (next realtime departures), can return no data upon time out, rendering the sensor unavailable. Depending on how far into the future next departures are reported (in Rome's case it's usually buses with 4-6 future trips covering the coming 30 minutes or so). I'm not sure it makes sense to retain or plug a missed RT update at all, since to have value it would require a next level of calculation inferring how the vehicle's path has progressed. Back to the Rome situation, if the bus position suddenly becomes unavailable, in reverting to the last known schedule, it's useful to see a few upcoming arrivals to guess the frequency of service that time of day. The specialized transit planner apps including Google Maps and Citymapper simply stop displaying a RT icon when no data available, and revert to displaying schedule only.

I added a duplicate sensor for each route without enabling RT, and it always returns a result. So I can handle my application with a template that displays the non-RT sensor result if the RT sensor is unavailable. But for a future release it might be interesting to see why the GTFS2 fetch sometimes can populate a result lacking RT data while sometimes times out and makes the sensor completely unavailable.

[vingerha]

Sensor should continue to show but you throw in many variables as static, rt, position Static does (should) not 'time out' as the data is local To be clear.... I am not going to spend time to wild search for issues (unless well paid :) ..) so I need quite a bit more data than 'Rome ATAC' As per my ISSUE questions... no details means that I will ignore this

[jebissell]

OK, I understand.