OneBusAway - Multiple Bridge Bindings

Add-ons Bindings
, ,
1

Are there examples of using multiple bridge configurations with the OneBusAway integration?

I’m a relatively new OH 2.2 user (Linux - Raspberry Pi Jessie) and haven’t used bridges in OH configs before. I’ve only been able to get my first stop and route combination to take effect (it’s the only thing that ever is displayed in logs and makes it to my items and sitemap). I’ve tried both the (sanitized) config below and placing the bridge config for stop 8888 inside a single bridge API (the first stanza).

I’ve updated my OneBusAway plugin to the 2.3-SNAPSHOT as of Jan 19 to address the known bug in 2.2 where only a single OneBusAway API was being issued on the life of an instance.

Bridge onebusaway:api:REGION [apiKey="SECRET", apiServer="api.REGION.onebusaway.org"] {
  Bridge onebusaway:stop:1_6666 [stopId="1_6666", interval=60] {
    Thing onebusaway:route:1_7777 "Route A" [routeId="1_7777"]
  }
}
Bridge onebusaway:api:REGION [apiKey="SECRET", apiServer="api.REGION.onebusaway.org"] {
  Bridge onebusaway:stop:1_8888 [stopId="1_8888", interval=60] {
    Thing onebusaway:route:1_9999 "Route B" [routeId="1_99999"]
  }
}

Thanks for the work on the project and this plugin!

David

2

Bumping this topic for visibility in case the weekend pulled eyes away. :slight_smile: I’ve been stumped getting the OneBusAway plugin configured to make things for two routes, each at a separate stop. I’ve tried turning up the logging on the binding and do see a series of ARRIVAL and DEPARTURE channel notifications for the route that never populates (confirmed via console review of the thing). There seem to be no other errors and I’m stumped on how to do further debugging without familiarity with the code base.

Manual queries to the OneBusAway plugin all look well structured. Quite the mystery!

3

Hi David,

I am also interested in using transit information in openHAB as well, and it looks like OneBusAway might be the way to go, but I am not completely sure what is needed to make it work. There is only a handful of topics mentioning it here, so I think the binding is not so widely used yet.

I still need to start playing with it, but my current problem is that my region is not listed on OBA’s list of Deployments. Are you using one of the existing deployments? I am wondering if I will have to setup my own deployment and if my Raspberry Pi 3 would be powerful enough to host it for personal usage…

Why are you trying to use two bridges? Do you need to connect to multiple deployments on your solution? It sounds like an unusual requirement, as the existing OBA deployments seem to be quite far away geographically from each other.

4

Hi, Flavio.

I’m fortunate to be in a region (Puget Sound) where OBA is deployed. As I understand the plugin, two levels of bridges are required, a top level bridge per region and a second level bridge for the particular transit stop. Within the stop, individual things can be defined for each route that calls at that stop. For my deployment, I want to get the departure times of routes at two different stops (the departure times of my typical bus to work and my typical bus to home). As I understand it, that requires the following structure:

  • Region-level bridge
    • Stop 1 bridge
      • Thing for Route A
    • Stop 2 bridge
      • Thing for Route B

I’ve only been able to get a single thing online, with the second thing throwing a strange sequence of channel events but never populating. Even stranger, my thing configuration (limited to just this plugin) is throwing some warnings on thing syntax misconfiguration, but the file validates in VS Code and manual inspection without incident. I’ve not found a way of increasing the logging to find out specifically what OH2 is complaining about here. With the 2.2 released version of the binding having a pretty major bug where the binding would only call the OBA API once per launch, I wouldn’t be surprised if there are other quirks with the plugin.

Hope this provides a bit of insight. I’m happy to try debugging further though I’m currently out of ideas.

5

Since I am not as fortunate as you, I will have to explore the possibility of running my own OBA deployment first, before attempting to integrate it with openHAB.

While this means that unfortunately I cannot help you test that for now, I see that you propose the following structure which makes sense according to the Binding configuration:

  • Region-level bridge
    • Stop 1 bridge
      • Thing for Route A
    • Stop 2 bridge
      • Thing for Route B

However, what your code above seems to be doing is:

  • Region-level bridge
    • Stop 1 bridge
      • Thing for Route A
  • Region-level bridge
    • Stop 2 bridge
      • Thing for Route B

Perhaps the duplicated Region-level bridge might be causing or contributing to the problems you’re experiencing.

6

Appreciate the dialog! Unfortunately, I’ve tried with both the posted double API bridge and with a single API-level bridge with no positive effect. I’ll have to spend some time with the source code and possibly open an issue on GitHub to try to directly engage the contributor. Thanks for the attempt!

1 Like
7

Fixed! The nested format with a single API bridge at the top level does work. My problem with at least some previous attempts was a subtle character interchange in route/stop IDs between the thing configuration and the item configuration. Naming things is hard. :stuck_out_tongue:

8

Good to know! Ultimately, did you use two region-level bridges or just one?

9

While both configs worked (once I had my names straightened out), I settled on a single region-level bridge. That seemed a bit cleaner.