Home-Assisant-Sensor-OvApi
Home-Assisant-Sensor-OvApi copied to clipboard
Many-updates-in-one pull request...
Hi, when the stop queried is the first/last one of the line, there are chances that there are duplicated records, for the tram/bus that arrives and for when it leaves. I have seen this for example for this code:
https://v0.ovapi.nl/tpc/31008732
The same metro arrives and leaves the other way with the same route code and the same time, therefore I propose to ignore times of departure when the stop is the last stop of the line, i.e. the 'JourneyStopType' attribute is 'LAST'.
For me this cleanly deduplicates the timings at this stop. I tested the change locally and it works fine for me.
I have added all my fixes in the same pull request. It works on my setup, but please test on your side!
I have noticed that you were not showing the delay on the "master" entity, i.e. the first sensor. I reverted this to have the same display on all entities, but it's just a personal taste.
For example the first instance here shows delay as well as the "future" sensors. Also it now shows negative delay when the tram arrives early (yes, sometimes!).
Same with real delay, the first instance now shows the delay instead of showing the actual arrival time. the reason why I reverted for this is that by keeping the original arrival time you can still recognise if it is the tram or bus that you usually expect, not the previous one that was very late (like "19:30" could be the tram from "19:25 + 5m" or the tram from "19:32 -2m" so you would better know in which tram you get in).
I also created a "Search_code" attribute that either displays the Timing point code or the stop_code + route_code depending on the setup of the sensor:
or
I also changed the display of the delay when there is no delay:
and when there is:
I've updated my lab environment and pulled HA out of the dust. I'm doing some upgrades now to bump to the latest version. I'll keep you posted on the progress...
great! I've added another small commit to this pull request to improve the state display for the 'unknown' schedules.
That how it looks at the end of the day:
Hi again
I have implemented the reload service call in init.py and also I have created a new file services.yaml
I am not sure how this works, but at least it works and I can reload the sensors from the Developer tools page and it works without having to restart HA completely :)
So that's the end of my contribution everything works as I was expecting at the start. Hope you like it. Cheers!
Ultimate change to add a new attribute that calculates how many minutes remain until transport arrives. Convenient to use in a remote display without having the remote chip to do the maths...
@Gyosa3 Thank you for this PR! There are unfortunately a few errors which were blocking the code to run:
- missing semicolon after
else
on lines 180 & 247 - a typo on line 293,
stop_list
instead ofstops_list