How to Model HVAC in Binding

Add-ons Bindings
,
1

I am looking to create a Binding for the Airtouch Air-Conditioning control system.

The Airtouch is a popular hardware solution that connects to many different brands of ducted air-conditioners. It presents as a wall mounted Android based tablet for controlling the system. The software on the tablet provides a server I can connect to via TCP, and I have successfully written a library that allows control of the system.

I want to use this library as a base for an OpenHAB binding, but am struggling to map the Airtouch model to the OpenHAB model.

  • The Airtouch has up to four air-conditioning units attached.
  • Units have a set of attributes (name, set temperature, actual temperature, on/off, mode, fan speed, etc)
  • The Airtouch is divided into Zones (or Groups). These typically represent a room.
  • A zone is associated with one AC unit
  • Zones have a set of attributes (name, set temperature, actual temperature, on/off, control mode - temperature or air-flow)
  • The power state of the unit matters. Nothing works unless the unit is on. I mention this because I can’t just present the zone power state. I need a way to present both unit state and zone state.
  • There are multiple versions of the Airtouch hardware/software available. I have the spec for v4, and v5.
  • Airtouch is discoverable via UDP broadcast.

Here is a rough tree of the model within the Airtouch.

  • Airtouch
    • Unit 1
      • Zone 1
      • Zone 2
      • Zone 3
    • Unit 2
      • Zone 4
      • Zone 5

How to handle multiple versions of the Airtouch from a single binding?
My current thinking is to provide a single Bridge that can detect the Airtouch on the Wifi. If I am to support v4 and v5, does the Bridge use a mediator pattern to present back a single Airtouch bridge?
Does the bridge support the different discovery methods, and determine the version or do I let the user decide which bridge version to use and then broadcast to determine the IP, version etc?

How do I translate the Airtouch hierarchy into Bridge, Things, and Channels?
I imagine AC Units are Things, and also Zones are Things.
Units and Zones then have channels. The actual channels available will differ depending on whether it’s a unit or a zone. Channels will also probably differ due to the attributes available in each Airtouch version.

Do I try to do something clever like present the Unit state, mode, etc as channels on a Zone? I suggest this because, a Zone is useless until the Unit is switched on, and the mode set. However, any changes to a Zone’s “unit channels” would effect all Zones on that Unit.

Admittedly. that feels weird, and my view at the moment is to present the units as their own Things, and let the user handle the relationship themselves. Or is there a way to present Things in a hierarchy within OpenHAB?

All suggestions welcomed. Thanks!

2

If you can differ the version from the discovery, the just model two different bridges, one for each version.

I would go for a single thing per unit and modell the channels into groups as dynamic channels (just create the ones really exist). You can then have a group for the unit channels and one group for each zone.

3

You can then have a group for the unit channels and one group for each zone.

I don’t quite understand what you’re referring to here.
Is there an example binding I could look at to see how this works?

Also, when you refer to “group each zone”, is that a function in openhab, or do you mean they’re grouped by having a similar name?

4

I have found the following in the documentation.

I presume that’s what you are referring to @hmerk

Thanks. I’m read up on that.