raZberry: add support for binary sensors

[tobser]

this commit adds a raZberry_binary_sensor class which has the states on
and off.
raZberry_openclose is derived from raZberry_binary_sensor and basically
translates the on/off states to open/close.
raZberry_window and raZberry_door are both derived from
raZberry_openclose and only change the default floorplan icon

[hplato]

I've looked this over, and I'll add the child objects to my working code so that all the new objects can be updated at once. I've made a few modifications, if there is disagreement, happy to explore further.

• I removed the z_log method. I use main::print_log elsewhere, and having a child object with a different logging method can create confusion.
• I removed the push '@States' part in the new method. If states are set, then they can be controlled by the web interface. Since these objects should only be set by the devices themselves, I don't think manual control makes sense. When the poll happens the objects will be set to the state from the Z_Way server, even if the '@States' isn't set.
• I'm not sure about the razberry_door and razberry_window', and their sole purpose to just add the floorplan icon set. Might create object proliferation; I just set those icon sets in user code. It is a neat idea, so I don't know the best approach.

[tobser]

Am 15.05.2016 um 03:22 schrieb hplato:

I've looked this over, and I'll add the child objects to my working
code so that all the new objects can be updated at once. I've made a
few modifications, if there is disagreement, happy to explore further.

• I removed the z_log method. I use main::print_log elsewhere, and
  having a child object with a different logging method can create
  confusion.

  OK with me, I simply thought it might be useful to immediately see
  which device is causing a log message.

• I removed the push '@States https://github.com/states' part in
  the new method. If states are set, then they can be controlled by
  the web interface. Since these objects should only be set by the
  devices themselves, I don't think manual control makes sense. When
  the poll happens the objects will be set to the state from the
  Z_Way server, even if the '@States https://github.com/states'
  isn't set.

That's good to know, I wasn't aware of this feature, always thought you
can change the state even if it is added later on.

• I'm not sure about the razberry_door and razberry_window', and
  their sole purpose to just add the floorplan icon set. Might
  create object proliferation; I just set those icon sets in user
  code. It is a neat idea, so I don't know the best approach.

I wasn't sure about this up roach either... so two people in doubt
probably means we actually should get rid of those objects.
After I sent the pull request, I also saw that there already exists a
generic door item ( lib/Door_Item.pm ). It actually looks like this
should be used with the raZberry_binary_sensor but I haven't checked it
out yet. So we can also get rid of the raZberry_openclose object.

There doesn't seem to exist a Window_Item, but one could till use the
Door_Item with a window iconset, that's probably what others are doing,
right?

Maybe Door_Item should actually be OpenClose_Item and users should set
the appropriate iconset. We could derive Door_Item from it to not break
existing setups..