I’m also struggling with config flow 
What I like about using the stop_id is that you can get only one direction, but it should indeed also possible to accomplish this with the api.
What I miss in your implementation is language options, for the rest it’s probably very similar?
BTW, it’s MIVB, not MVIB 
Thanks for MIVB… I will eventually correct this but it’s written everywhere 
The messages are returned in both languages by the python library and “chosen” at sensor level.
I don’t get your idea with the stop IDs. The triplet stop name + line + direction is harder code-wise but easier for the user “eg: i’m interested to know the waiting times for the stop X and for the lines Y in direction of Z” .
pystibmvib (soon-ish pystibmivb ) allows to easily abstract that by automatically crawl the shapefiles and get the techncal IDs for the stops.
Using technical IDs to identify business things is generally a bad idea.
Totally true, you just need to do it. I don’t think it’s in your code, or maybe I looked over it?. What are you doing with the line terminus option?
The messages are returned in both languages by the python library and “chosen” at sensor level.
Messages are in three languages, but stop names in two so you will need two different language options.
I also made a custom card that shows the messages, it’s mostly based on your code. Other than that I would change the colors in the icons, that black border is IMO really ugly. You can get the color of the numbers too so it’s always readable, apparently not from the shapesfile but it’s in the gtfs file.
My pull request is here: Add Stib-Mivb Brussels transport component by Emilv2 · Pull Request #32412 · home-assistant/core · GitHub , seems like I was just too late to avoid the mandatory config flow.
Totally true, you just need to do it. I don’t think it’s in your code, or maybe I looked over it?. What are you doing with the
line terminusoption?
It’s in my code and in my python Library (see the example usage in pystibmvib/README.md at master · helldog136/pystibmvib · GitHub . It retrieves the waiting times for the stop “Scherdemael” for the line 46 in the direction of Glibert)
Messages are in three languages, but stop names in two so you will need two different language options.
Yeah… Maybe we could just limit ourselves to french and dutch…
I love your custom card! espcially the way that you display the messages on the bottom of the card! pystibmvib could parse the gtfs to get this color returned too I guess.
One last thing that i think my python library does better is that the user doesn’t have to worry about the expiration of his token.
I implemented a simple client that handles the renewal of the token so you just need the client_id and secret.
I think we would both benefit to merge our work together as my python library has been implemented on the latest version of the openapi from stib and allows the abstraction of technical IDs for the stops. Your part on homeassistant seems mode advanced and reliable than mine… (both sensor and card)
I could focus on the python library while you tell me what it’s missing for your HA sensor?
I think adding a optional config to get the messages in English is pretty easy to implement?
As I understand it you’re using the terminus to filter on lines? Wouldn’t that get a little complicated with (mostly evening) lines that don’t go all the way but people would still be interested in? (or do these still have the same terminus name, I don’t really remember) There is also a direction, Suburb or City I use now to name the stops.
I could focus on the python library while you tell me what it’s missing for your HA sensor?
Sounds like a good idea. The text color for the lines is what is missing now, for the rest I would need to have a closer look at your code.
As I understand it you’re using the terminus to filter on lines? Wouldn’t that get a little complicated with (mostly evening) lines that don’t go all the way but people would still be interested in? (or do these still have the same terminus name, I don’t really remember) There is also a direction,
SuburborCityI use now to name the stops.
Correct I use the line number and the terminus to filter the lines. The terminus doesn’t change (as i recall) for late night lines but you’re right… Maybe it would be better to transform the terminus into the direction (simple boolean/number) and let the user find the correct one by trial/error…
I imagine the configuration like this:
client_id: "foo"
client_key: "bar"
messages_language: ("fr"/"nl"/"en" defaults to "en")
stops:
- stop_name: "Scherdemael" (or "Scherdemaaal" if the user speaks Dutch. the lib searches in both languages anyway)
lines (optional - unspecified = all possible lines and directions):
- line_number: 46
line_direction: 1 or 2
- stop_name: "De Brouckere"
lines:
- line_number: 5
line_direction: 1
- line_number: 4
line_direction: 2
this would create two sensors: scherdemael_46_1 and de_brouckere_5_1_4_2
I will look at that color thing and also add a way to use the direction instead of the terminus. Expect it to arrive soon in the lib
Hi,
Cool that you guys are working on this (I hope @Helldog136 you didn’t left your real client_id and secret in your example.py file 
). BTW, pyStibMivb should be available on pypi, if no one else grabbed it after I deleted my project.
I like the idea that you don’t need to look up the stop_ids any more and you’re looking it up by stop name, better not have a typo or put accents in the name then, I guess.
What about user errors, for example stop_name : “De Brouckere” with line_id : 18, just log an error or return a warning in the sensor that this line isn’t passing at this stop?
While having a card with all details of the stop (like the display at the stop) is very nice, it’s also very useful to have the waiting times for a particular line, as I trigger some automations when it’s time to leave the house to catch the next bus. I’m using for now a quick and dirty script that takes the passing times and pushes the remaining minutes with mqtt as@Emilv2 's sensor is returning this info only in an attribute. Maybe a sensor for the the stop and a sensor for every single line passing would be more useful, but in this case I thing you need to parse stops.txt to fin out what line passes at which stop…
Fin de service: would there be a way to check the timetable to have the first foreseen passing time in the next morning, that would avoid an empty state?
May I suggest to prefix the sensor name for easier filtering in the developer tools?
Let me know if you want me to test anything.
Thanks
Daniel
I like the idea that you don’t need to look up the stop_ids any more and you’re looking it up by stop name, better not have a typo or put accents in the name then, I guess.
What about user errors, for example stop_name : “De Brouckere” with line_id : 18, just log an error or return a warning in the sensor that this line isn’t passing at this stop?
With config flow I think we can check this during setup, maybe even show a list of all the possible lines per stop. Once I figure out how to get config flow working that is.
While having a card with all details of the stop (like the display at the stop) is very nice, it’s also very useful to have the waiting times for a particular line, as I trigger some automations when it’s time to leave the house to catch the next bus. I’m using for now a quick and dirty script that takes the passing times and pushes the remaining minutes with mqtt as@Emilv2 's sensor is returning this info only in an attribute. Maybe a sensor for the the stop and a sensor for every single line passing would be more useful, but in this case I thing you need to parse stops.txt to fin out what line passes at which stop…
You can use attributes in automations or make template sensors, wouldn’t that solve your problem? There are arguments for and against putting things in attributes or in separate sensors, I think keeping it the same as most other transport sensors, one sensor per stop, is the way to go.
Fin de service: would there be a way to check the timetable to have the first foreseen passing time in the next morning, that would avoid an empty state?
I think that should be possible, but the information seems to be quite scattered around in the gtfs file.
May I suggest to prefix the sensor name for easier filtering in the developer tools?
Sounds good to me, I’ll see if they accept it. Most components don’t do that but I don’t know if that is a requirement or just up to the developer.
BTW, pyStibMivb should be available on pypi, if no one else grabbed it after I deleted my project.
For the moment, my lib is called pystibmVIb thus it is already available on pypi. Tell me when you delete yours so i can prepare to post it with the right name just after that (and let’s hope that no one is using your lib :D)
better not have a typo or put accents in the name then,
Yeah that’s the drawback but i think that’s the user that must check his input. Wrong input means wrong answers from service.
I guess.What about user errors, for example stop_name : “De Brouckere” with line_id : 18, just log an error or return a warning in the sensor that this line isn’t passing at this stop?
I could detect this type of wrong configuration and throw an error like “InvalidLines” for example but only if no line matches. (a more advanced check isn’t relevant for me there… i could do it if you really want but i would consider this a bonus feature)
While having a card with all details of the stop (like the display at the stop) is very nice, it’s also very useful to have the waiting times for a particular line, as I trigger some automations when it’s time to leave the house to catch the next bus.
For this you could just define another stop entry with only one line and direction. the associated sensor would only have waiting time for the line you’re interested in.
Fin de service: would there be a way to check the timetable to have the first foreseen passing time in the next morning, that would avoid an empty state?
This can be done if we decide that the user never wants to know if it’s the end of the service.
I can replace the “end of service” by a fake waiting time based on the timetables.
I think it’s better to let “end of service” for now and in a v2.0 add that crawling of GTFS to add this info.
Guys, I found a solution for our text-color problem without looking at STIB files:
A simple calculation can determine if it’s better to have a white text or a black text
pystibmvib released in v1.1.5 (we’ll sort out the name issue later… It’s not really important after all…)
I’ve added the text_color, the direction accepted in place of the terminus and an exception that raises if the specified lines creates a stop without monitored lines (eg: de brouckere with only line 18) BUT won’t raise if the specified lines contains at least one true line (e.g. de brouckere with lines 5 and 18 won’t raise error because metro 5 passes by at de brouckere)
For the moment, my lib is called pystibmVIb thus it is already available on pypi. Tell me when you delete yours so i can prepare to post it with the right name just after that (and let’s hope that no one is using your lib :D)
The lib has been long deleted and should still be available
I would rather use the official colors, even if this method would technically be better
Hi,
I deleted pyStibMivb from pypi a couple of month ago, so if you like, go and reserve the name already, even if you don’t switch yet.
I’m totally fine with attributes, and looking again at it, I did configure several sensors with a single line for a stop so that I can use the attribute next_passages[0][‘waiting_time’] for this. Only thing by now is when configuring a line that is not in service at the time, the sensor is not showing up and you wonder why. Line 32 for stop “Saint Denis” for example, or when you do a reconfiguration of your ha installation at 2 in the morning.
Other idea for a v.2.x configuration: take the home zone’s localisation and add automatically all nearby stops and lines (and add them to the map).
I think that should not happen, there should be a message saying"einde dienst" or something similar but it does indeed frequently happen. We probably best get the lines per stop from the gtfs file. That’s a lot more complicated though.
I would rather use the official colors, even if this method would technically be better
I tested it and it gives the right colors for the STIB lines.
I don’t think it does for line 5. The color is #E6B012 (230,176,18) but (0.299*230+0.587*176+ 0.114*18)/255 = 0.68288 which should give a black text color but the official color is white. Or am I missing something?
At any rate I don’t see why we should try to reverse engineer the algorithm they use to determine the colors when the data is readily available.
I’m kind of sad because this is way less efficient but hey… dark STIB logic applies here
Renamed repo and pypi lib:
Can you open issues on the new repo if you need some additional functionalities.
I like the idea of maybe adding the gps coordinates of the stop you’re monitoring to add on a map. might be quite easy to do… We could consider this in a future version of the sensor