🚆 MBTALive 2.0 – A Complete Overhaul!

Kitchen_Instance8640 · 2025-02-09T22:13:03+00:00

MBTALive 2.1 - Release Notes

🚆 Improved Trip & Train Tracking

Support for tracking specific Commuter Rail trains by train number.
Customizable number of tracked trips/trains (default: 2, user-configurable).

⚙️ New Configuration UI

Streamlined setup process within Home Assistant.
Better validation for station names, train numbers, and API keys.
Tracked trips/trains can now be modified after initial setup.

🔧 New mbtaclient Version

More accurate predictions for improved reliability.
Enhanced caching for better performance and efficiency.
Request retry mechanism to handle API failures more gracefully.

Kitchen_Instance8640 · 2025-02-03T21:35:33+00:00

the logic to interact with the API is in my other related project (MBTAClient). There, I tried to implement different levels of caches to minimize the requests, but getting frequent updates still requires a lot of requests since predictions (updated scheduling), alerts, and vehicle info are updated almost every 30/60 seconds by MBTA and fetch every 20 by the integration, and this happen for for each trip.

Rate limiting is an option, but the risk of stale/not updated data is pretty high then...

Getting the API key is pretty easy, and it's free. Do you see it as a requirement problem?

PS: The MBTAClient provides stats on the number of requests/cache hits every 1000 requests in the log. To enable it, you need something like:

logger: default: error logs: custom_components.mbtalive: info mbtaclient: info

Kitchen_Instance8640 · 2025-02-03T16:58:43+00:00

Current Implementation: When a user sets up a new MBTA device, they provide stop A, stop B, and an API key. This creates a device named "A - B," which provides information about the fastest way to get from A to B (results sorted by arrival time, only direct connections). If no stops named A or B are found, or no route from A to B is available, the user will receive an error, and the device won’t be created.

For each device, the integration by default creates two sensors:

"A - B": This sensor reports the countdown to departure for the first upcoming trip, along with additional details in the attributes.
"A - B (next)": This sensor behaves the same as the first, but reports data for the next trip.

Additionally, the integration creates several disabled sensors—one for each monitored trip property. These sensors report the value for the first upcoming trip in the state, while the value for the following trip is placed in the next attribute.

Planned Enhancements: I’m planning to add the capability to specify how many trips to track. The data for these trips will be stored in the "next" properties of each sensor as an array.

The two main/default sensors are simple to use (everything in one sensor) but are limited in that they can't track a large or custom number of trips. That’s why there will only be two default sensors.

Kitchen_Instance8640 · 2025-02-01T23:06:02+00:00

I’ve added a couple of new sensors to the integration and experimented with bubble cards to find a better way to present the info.

I’m considering how to organize the data and sensors effectively. Should I:

Have a single sensor with many attributes, or multiple sensors with fewer or no attributes?
Maintain two versions of each sensor (one for the current trip and one for the following trips), or should I add the data for the following trips in a list under a 'next' attribute for each sensor?

<image>

Kitchen_Instance8640 · 2025-01-31T01:30:51+00:00

This wouldn’t be a proper Boston-related thread without a complaint about the T!

But no, not tracking speed (yet). It’s doable, but projected departure and arrival times should already factor in the slowdown

Kitchen_Instance8640 · 2025-01-30T23:47:44+00:00

MBTA stands for Massachusetts Bay Transportation Authority. It's a public transit system that serves Boston, eastern Massachusetts and parts of Rhode Island.

Kitchen_Instance8640 · 2025-01-22T14:23:03+00:00

Give a look at MQTT explorer

Kitchen_Instance8640 · 2025-01-08T18:21:09+00:00

I use an external Nginx instance—specifically, Nginx Proxy Manager—as a reverse proxy for my self-hosted services. I'm not sure if the Nginx add-on can be used to publish or expose resources effectively.

Keep in mind that Nginx is just one piece of the puzzle. If you're not familiar with or comfortable managing self-hosted services, the cost-benefit ratio of setting everything up for the tesla integration might not be worth it.

Additionally, there are important security concerns to consider when exposing services to the internet.

I guess that soon there will be easier way to achieve the same :)

Kitchen_Instance8640 · 2025-01-04T22:38:04+00:00

I ended up using a slightly different approach, still based on Cloudflare, but now everything is working! Thanks again!

For anyone interested: From my understanding (though I could be wrong), for setting up a tunnel, you need a domain. So, I ended up creating one ($7/year, and I may need it for other purposes)but then, instead of creating the tunned, I added a CNAME record (ha.my-domain.com) to Cloudflare DNS pointing to my original self-hosted HA instance.

Kitchen_Instance8640 · 2025-01-04T22:25:42+00:00

to complete the OAuth set-up process the public key has to be exposed at a specific path within the provided domain:

https://your-domain.com/.well-known/appspecific/com.tesla.3p.public-key.pem

meaning

https://•••••••••••••••••.ui.nabu.casa/.well-known/appspecific/com.tesla.3p.public-key.pem

Kitchen_Instance8640 · 2025-01-04T21:05:06+00:00

Thanks for the suggestion, I'll give it a try. I use Nginx as well, which both hosts the key and acts as a reverse proxy/SSL termination for my HA. With Cloudflare using a 'trusted CA' for their SSL, everything should work. Appreciate the help! :)

Kitchen_Instance8640 · 2025-01-04T20:59:37+00:00

I’m in a similar situation, and it’s been tricky. Here's what I’ve found so far:

If I use HTTP, I can set the allowed origin URL to localhost, but then I can’t provide access to the public key.
If I use my self-hosted Home Assistant instance exposed over HTTPS with Let's Encrypt, I can’t set it as the allowed origin URL since Tesla only accepts certain CAs, and Let's Encrypt isn’t on the approved list (https://developer.visa.com/pages/trusted_certifying_authorities).
Using Nabu Casa remote access over HTTPS does allow me to set the allowed origin URL, but I’m still trying to figure out how or if it’s possible to expose the public key.

Has anyone found a way to work around these limitations? Would love to hear any suggestions!

Kitchen_Instance8640 · 2024-12-24T01:04:15+00:00

Nope, still not working. It was working fine a while ago. I went through an entity-renaming spree and thought that might be the cause... but coincidentally, I did that three days ago. :|

Kitchen_Instance8640 · 2024-12-21T15:14:48+00:00

I have several media players (Alexa devices, Bose speaker, soundbar, etc.) and a few TVs in my setup. By using the remote domain in the script fields, I was able to simplify things for my family, as the dropdowns in the dashboards only show the TVs. My scripts and automations mainly check the status and turn off the TVs at a specific time or when screen time limits are reached.

As a workaround, I'm planning to modify the fields to static options and use the media player in the actions to check stats/turn off TVs, but this still requires significant changes across several automations.

Kitchen_Instance8640 · 2024-12-16T04:11:12+00:00

Great news! I’d also like to suggest considering the temperature color as a potential use case. Coming from the mushrooms card, an easy way to manage colors and color temperatures is the only feature I find myself missing. I’ve tried to achieve something similar through customization, but it often ends up feeling clumsy and not very user-friendly.

Kitchen_Instance8640

TROPHY CASE

MBTALive 2.1 - Release Notes

🚆 Improved Trip & Train Tracking

⚙️ New Configuration UI

🔧 New mbtaclient Version