From version 21.1
edited by David Nestle
on 2019/03/01 09:46
To version 22.1
edited by David Nestle
on 2019/03/01 09:53
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -35,7 +35,7 @@
35 35  
36 36  == Driver extensions ==
37 37  
38 -Note: An example extension bundle as source code is provided in [[https:~~/~~/github.com/ogema/tutorial/tree/master/src/homematic-sample-channel>>url:https://github.com/ogema/tutorial/tree/master/src/homematic-sample-channel]]. For the development of a homematic driver extension it is recommended to configure a rundir on the development PC to connect to relevant homematic devices via a CCU2 or a semabox as described above.
38 +Note: An example extension bundle as source code is provided in [[https:~~/~~/github.com/ogema/tutorial/tree/master/src/homematic-sample-channel>>url:https://github.com/ogema/tutorial/tree/master/src/homematic-sample-channel]]. For the development of a homematic driver extension it is recommended to configure a rundir on the development PC to connect to relevant homematic devices via a CCU2 or a semabox as described above. To access channels provided by the Homematic Lowlevel Driver directly there is also a special app available now in the ogema core repository at //src/drivers/homematic-xmlrpc-cfg// (expected for release 2.2.1). Note that the web interface of the app may only be accessible if a homematic connection could be started.
39 39  
40 40  A HomeMatic device consists of a main or top level device which contains a hierarchy of sub devices called 'channels'. Sensor and actor control data is usually transmitted on channels, so most driver implementations actually do not identify top level devices directly and only work on channels which are identified by their device type. To implement a new device driver you have to provide an implementation of //org.ogema.drivers.homematic.xmlrpc.hl.api.DeviceHandler//, usually by extending //AbstractDeviceHandler//. See e.g. //org.ogema.drivers.homematic.xmlrpc.hl.channels.IpShutterContact// as example.
41 41  A new //DeviceHandler// implementation must then be registered in the OSGi framework with a //DeviceHandlerFactory// (this can be integrated into the class extending //AbstractDeviceHandler// as it is done in //IpShutterContact//. The OGEMA HomeMatic driver will build a list of all registered //DeviceHandlerFactories//, ordered by their OSGi service ranking (starting with the highest rank, see the @Component annotation in //IpShutterContact// source) and offer each available device or channel to all installed handlers until the first handler accepts the device. This way, there will be only one handler controlling a channel and generic handlers can be overridden by more specific ones.