From version 22.2
edited by Jakob Ruckel
on 2019/04/26 11:23
To version 23.1
edited by David Nestle
on 2019/05/14 12:37
Change comment: There is no comment for this version

Summary

Details

Page properties
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.jruckel
1 +XWiki.dnestle
Content
... ... @@ -21,8 +21,19 @@
21 21  
22 22  For each homematic system to access a separate (usually toplevel) resource of type org.ogema.drivers.homematic.xmlrpc.hl.types.HmLogicInterface has to be set up. This is mainly relevant if Homematic and Homematic IP shall be used in parallel - see Section on Homematic IP below.
23 23  
24 -An example XML file to create such a resource is provided below. In your development rundir you can save the file in the replay-on-clean directory to let the system create the resources on a clean start. Usually only the address of the Homematic-base-process or the CCU has to be adapted in the //clientUrl// value (here: http:~/~/192.168.1.9:2001).The //port// value specified should be the HTTP port on which the OGEMA system is listening to receive callback messages from the Homematic system. This should usually not need to be changed on a development system. The //networkInterface// subresource can either be 'lo' (for loopback, Homematic process on same IP as OGEMA), 'wlan' or can be deactivated in order to let the driver find the right network itself (recommended for Microsoft Windows).
24 +An example XML file to create such a resource is provided below. In your development rundir you can save the file in the replay-on-clean directory to let the system create the resources on a clean start. Usually only the address of the Homematic-base-process or the CCU has to be adapted in the //clientUrl// value (here: http:~/~/192.168.1.9:2001).The //port// value specified should be the HTTP port on which the OGEMA system is listening to receive callback messages from the Homematic system. This should usually not need to be changed on a development system. The //networkInterface// subresource can either be 'lo' (for loopback, Homematic process on same IP as OGEMA), 'wlan' or can be deactivated in order to let the driver find the right network itself (recommended for Microsoft Windows). If automated interface detection does not work, the respective IP and port can be given explicitly in the resource baseUrl, e.g. add the following to the homematic XML file used to create the homematic resource via replay-on-clean after the networkInterface entry. The following is an example for this:
25 25  
26 +{{code}}
27 + <resource xsi:type="og:StringResource">
28 + <name>baseUrl</name>
29 + <type>org.ogema.core.model.simple.StringResource</type>
30 + <path>HomeMatic/baseUrl</path>
31 + <decorating>false</decorating>
32 + <active>true</active>
33 + <value>http://192.168.0.10:8080</value>
34 + </resource>
35 +{{/code}}
36 +
26 26  The console commands can be called in the name space which is defined by the name of the configuration resource (here HomeMatic, see documentation of OSGi console commands below).
27 27  
28 28  If you want to access more than one HomeMatic system from a single OGEMA instance the names of the toplevel resources have to be different, of course, and thus also the name spaces for console commands. Also the 'alias' entries should be different. Use only lower case letters here, the alias is used as URL path. Port 2001 is the standard for BidCos-RF, for HomeMatic-IP on a new CCU2 you should use port 2010 (the sema-box soes not yet support HomeMatic-IP).
HomematicChannels.png
Size
... ... @@ -1,1 +1,1 @@
1 -0 bytes
1 +86.0 KB
Content
homematic-config.ogx
Size
... ... @@ -1,1 +1,1 @@
1 -0 bytes
1 +1.8 KB
Content