With the (upcoming) release of 1.3.0, it's time to think about and work on the
next version of the Z-Wave binding. We like this as much to be a collaborative
effort as the previous version was.
Ideas and suggestions about what to implement are welcome. In case you actually
want to start coding, there is a list of items to work on below:
high priority:
- D make binding between command classes and items more dynamic. So that
switches can be bound to dimmers, sensors to contacts or switches, etc.
- M initialize / read binding values in the DYNAMIC node stage during binding
initialization.
- M Make polling a binding action, so that it is configurable from the items
file. Default should be no polling.
- D Implement associations node stage to read associations. These can be used
to query associated nodes for their status, in case the associated nodes do not
report themselves directly (don't know if this is neccessary).
- M Implement some form of serialization to save / cache the configuration of
the binding to speed up initialization.
- E Implement the SWITCH_TOGGLE_BINARY command class.
- E Implement the SWITCH_TOGGLE_MULTILEVEL command class.
- E Implement THERMOSTAT_MODE command class.
- E Implement THERMOSTAT_SETPOINT command class.
- E Implement BASIC_WINDOW_COVERING command class.
- E Implement DOOR_LOCK command class.
- E Implement ALARM command class.
- E Implement LOCK command class.
- M Implement MULTI_CMD command class. Used to group multiple commands
together. Useful for Battery operated devices to empty the wake-up queue into
one
command at once.
- E Implement SIMPLE_AV_CONTROL command class.
- DD Implement SECURITY Little information. Would require changes to
encapsulation, secure key storage in openhab. Not much information. Very useful
for locks though. One of the weaker points of Z-Wave that security was an
afterthought.
normal priority:
- M Make binding actions for alarm types, so that binding can be done on a
specific alarm. Remove alarm values from the binding again then, to make it
stateless.
- D Handle adding nodes to the network / removing nodes from the network.
- D Control node configuration parameters using a binding. (Requires changing
binding item string format to add parameter number or something).
- DD Implement neighbors node stage. Request node neighbors and update return
routes based on the neighbour list and rtt values.
- M Implement the APPLICATION_STATUS command class. Handle incoming rejected
and busy signals.
- D Implement the SWITCH_ALL command class. handle incoming switch all commands
and implement sending. Some discussion on what to do on those incoming signals
and when to send would be neccesary.
- D Implement the SCENE_ACTIVATION command class. Some discussion on how to map
scenes onto the openhab bus and vice versa would be neccessary.
- E Implement METER_PULSE command class.
- M Implement CLIMATE_CONTROL_SCHEDULE class. Requires some discussing about
how to map / handle scheduling capabilities to open-zwave.
- D Implement SCHEDULE_ENTRY_LOCK command class. Limited info on the command
class. Would probably require the a device, commercial software to control it,
and serial monitoring software.
- E Implement POWERLEVEL command class. Setting this too low, will make
communication unreliable!
- E Implement PROTECTION command class.
- E Implement NODE_NAMING command class. Would require discussion on how to
implement: e.q. use item name, or just report or free settable.
- E Implement CLOCK command class.
- E Implement HAIL command class. Some devices use a HAIL to the controller to
ask for polling.
- E Implement INDICATOR command class.
- E Implement PROPRIETARY command class. Would require discussion on how to
define properietary payloads... in item string? as files?
- E Implement LANGUAGE command class.
- E Implement TIME command class.
- E Implement GEOGRAPHIC_LOCATION command class.
- D Implement COMPOSITE command class. Variation on Multi_Instance. Requires
some changes to initialization and encapsulation etc.
- E Implement ENERGY_PRODUCTION command class.
- E Implement MANUFACTURER_PROPRIETARY command class. Would require discussion
on how to define properietary payloads... in item string? as files?
- E Implement SCREEN_MD command class.
- E Implement SCREEN_ATTRIBUTES command class.
- E Implement SILENCE_ALARM command class.
low priority:
- E Make a reporting binding action for the node stage, create separate
reporting binding actions for sleeping / dead.
- D Handle endpoints in multi-channel nodes that can be added /removed
dynamically.
- DD Handle the situation where the stick is not the primary controller. This
can be in networks with another (commercial) controller system. In this case
enabling the controller to be a SUC is advisable.
- DD implement bridging and virtual nodes. This allows items on the bus to
become virtual nodes and use Z-Wave associations or Z-Wave scenes to use items
on another bus directly in Z-Wave.
- D Separate the Z-Wave part from the binding part and make it a separate open
source library like open-zwave.
- D Implement the CHIMNEY_FAN command class. Have not been able to find a
device or documentation / code about it. Should be easy once found.
- D Implement MTP_WINDOW_COVERING command class. Limited info on the command
class. Would probably require the a device, commercial software to control it,
and serial monitoring software.
- E Implement IP_CONFIGURATION command class. Only for reporting or also to set
ip adresses?
- E Implement AV_CONTENT_DIRECTORY_MD command class.
- E Implement AV_RENDERER_STATUS command class.
- E Implement AV_CONTENT_SEARCH_MD command class.
- E Implement AV_TAGGING_MD(0x99,"AV_TAGGING_MD",null),
- D Implement TIME_PARAMETERS command class. Have not found any information.
- D Implement METER_TBL_MONITOR command class to read complex meters.
- D Implement THERMOSTAT_HEATING command class. Have not found any information.
- E Implement THERMOSTAT_OPERATING_STATE command class.
- E Implement THERMOSTAT_FAN_MODE command class.
- E Implement THERMOSTAT_FAN_STATE command class.
- D Implement THERMOSTAT_SETBACK command class. Have not found any information.
- D Implement DOOR_LOCK_LOGGING command class. Have not found any information.
ongoing:
- E Complete the list of device classes. This involves scanning software /
documents for the required info or coming along an unknown device class on a
device.
Original issue reported on code.google.com by jwsp...@gmail.com on 2 Sep 2013 at 12:45
Original issue reported on code.google.com by
jwsp...@gmail.comon 2 Sep 2013 at 12:45