Advice on binding structure - channels three levels deep

Development Add-ons
1

Hi all,
I’ve begun development of a binding for Zabbix and looking for some advice on how to structure the binding to match how Zabbix works.

Zabbix has three levels of abstraction before you hit actual data:

  1. The server itself
  2. A host monitored by the server (server has 0-n hosts)
  3. An item associated with the host (host has 0-n items)
  4. The data value - integer, float, string etc (item has a single value)

The challenge I’m having mapping this abstraction to OpenHAB is that everything in Zabbix is very dynamic! You don’t know about the hosts or items until you query a server. The only static part about this structure is the single data value once you get to the end (which will ultimately be a channel in OpenHAB).

I’ve started with a bridge for the server and a Thing for a host, but realised I now have to statically create channels associated with the host (which map to Zabbix items), but I don’t know what to create as the items depend on the Zabbix configuration.

The alternative is to create TWO bridges (server and host) and one thing (item) with a single channel (value). I’m not sure if this is even possible or sensible with OpenHAB…

What structure should I create in OpenHAB to handle this?

2

Reading through the docs a little more, I can see a bridge - bridge - thing structure is indeed possible, but is it sensible?

3

Sure. This is what I used for the Ecobee binding. In my case, the top level bridge represents the Ecobee account, the second level bridge represents the thermostats associated with the account, and the things represent the various embedded and remote sensors.

Once the account is added and authorized, the bridge discovers the thermostats and adds them to the inbox. Once a thermostat thing is added from the inbox, it discovers the sensors and adds them to the inbox.

You can see an example of the binding here.

4

What‘s wrong with creating channels dynamically? Several bindings do that. IMO

Bridge -> Server
Thing -> Host
Channel -> Item

is the better way. If you need assistance with the channels: see my PR for TR064 binding or OneWire binding. Or ask.

5

Thanks @mhilbush and @J-N-K. I’ve looked through both of your bindings and have taken some ideas from them. There are so many bindings that it’s hard to find some similar examples.

I’m working with the structure @J-N-K suggests at this stage. The discovery service in OneWire binding helped.

Cheers

1 Like
6

I agree this makes sense for your use case. I was merely trying to point out that a Bridge->Bridge->Thing structure is possible (and sensible), and wanted to provide an example of where/how it was used. I probably should’ve been more clear that I wasn’t necessarily saying to use it for your use case.

BTW, I’d be happy to test out your Zaabbix binding when you get to the point where you’re ready for some input. I’m running Zabbix 4.4 with about 75 hosts.

7

Indeed, you taught me something with your response. I appreciate that. Hopefully this post is useful for others too. I briefly went down the path of using the bridge-bridge-thing structure for Zabbix, and it helped to wrap my head around the possible ways to do this.

It would be great if you can test the binding when it’s at a point to release. I’ll make a pull request soon, just have to find the time to get it to a point where I’m happy for others to see the code. Are you able to assist with the pull request review/process when I get there?

As a side note, how cool is Zabbix! I originally started using it for enterprise IT monitoring (we currently monitor 250 hosts). But it also works really well to monitor/alert all my sensors at home.

8

Sure. Happy to help out however I can.

Yeah, I like it a lot. I use it at home for all my devices.

I used Nagios for a while, but I was not a big fan. Zabbix is much better. Although upgrading is a bit clumsy. I just went from 3.4 to 4.4 and from Ubuntu 16.04 to 18.04. It wasn’t pretty.

1 Like