Hey there.
I have a Homematic CCU2 running on a Rasperry (it’s RasperryMatic) which has 6 IP Thermostats (HMIP-eTRV) connected. According to pymatic those devices are supported.
I managed to connect HA with HomeMatic (actually it’s a RasperryMatic), but besides the virtual keys no devices are found:
homematic.switch autodiscovery done: []
homematic.light autodiscovery done: []
homematic.cover autodiscovery done: []
homematic.binary_sensor autodiscovery done: []
homematic.sensor autodiscovery done: []
homematic.climate autodiscovery done: []
Is there any additional configuration necessary in HomeMatic or something?
The XML API under 192.168.42.162/config/xmlapi/devicelist.cgi
does show the devices, so I wonder why these are not recognized?
The logfile is on pastebin (grepped for homematic/pymatic): http://pastebin.com/zHqkFhfJ
Config:
homematic:
hosts:
hmrf:
ip: 192.168.42.162
username: HomeAssistant
password: ****
primary: true
variables: false
I think the relevant part of the documentation would be:
port (Optional): Port of CCU/Homegear XML-RPC Server (default is 2001, use 2000 for wired and 2010 for IP)
IP devices are available on a different port. And since the port in your configuration is missing, you are currently trying to get the devices from the incorrect (default 2001) port.
Although I haven’t heard of anybody using RaspberryMatic yet, so there might be some compatibility issues we are not aware of yet. Please report if adding the 2010-port-setting fixes your problem.
1 Like
Thanks for you reply, Daniel
I now defined both hmrf and ip and it works now,

I did try the mentioned ports, all ended in Exceptions. I probably mixed the rf/ip configs.
To be honest, the instructions on the documentation page are confusing (at leas for me) and not really self-explanatory for a HomeMatic-Newbie (like me). I’m happy to help improve the documentation, but so far I don’t understand it myself.
- So it seems like I have to setup multiple bindings when my CCU manages standard devices and IP devices at the same time?
- hmrf, ip and wired look like fantasy/sample names, is it important which one to use? Are these connector-types or something?
- If I do need multiple bindings and the names hmrf/ip/wired are types and not fictitious names, why don’t they default to the correct port for said type?
- Why do I need multiple bindings? The XML Api seems to provide data for all types?
- What does hmrf and IP and wired stand for?
.
for the records, here is the working configuration:
homematic:
local_ip: 192.168.42.183
hosts:
hmrf:
ip: 192.168.42.162
username: HomeAssistant
password: ***
primary: true
variables: false
ip:
ip: 192.168.42.162
port: 2010
username: HomeAssistant
password: ***
primary: false
variables: false
Actually, one of the exceptions was “failed to create proxy”. So I guess I solved that one with local_ip without realizing it.
I guess the “only needed for exotic setups” is a bit missleading, my setup is pretty standard 
Glad it works now. 
- That’s correct.
- They are samples, but not “fantasy”. You are however free to choose a name you like. It just makes sense to use a name that refers to the “technology” the devices at that port use.
- Since they are not fictious and can (or have to) be set, there are no default values. If you have 5 CCUs, they all require to have a unique identifier for each port. Hence we can’t just call them all “wired” or whatever.
- The XML API is a addon you have for your CCU. Not everybody has that addon, and for HASS we only use it optionally to resolve the names of devices. Internally we use the XML-RPC API, which is something different than the XML-API you are referring to. And the XML-RPC API limits specific devices types (wired, rf and IP) to specific ports (2000, 2001 and 2010 by default).
- RF -> Radio Frequency. Those are the regular wireless devices most people use. IP: The newer IP-based devices. Still wireless, but different technology. And wired are what they are called: wired. The don’t operate wirelessly. Have a look at all the different devices you can get for HomeMatic, and you’ll see there are these different types.
Regarding the local_ip: Well, “exotic” might be the wrong term. But in a regular setup HASS should be able to detect the local IP which the CCU needs to send its events to. If that does not work for you, then there is something that is not “regular”. Regular in a way that 90% of the other users won’t have the same situation.
1 Like
I see, I see… it makes more sense now.
I think that the info from your post is what’s missing from the documentation. While I do know that there are different types, IP devices are still wireless. Unless you dig into HomeMatic, you couldn’t know what the ports are and what they do.
Wouldn’t it make sense to use the common list pattern for defining servers, like most components do?
Using a named list suggests that the names are predefined/meaningful.
Maybe HASS has trouble auto-detecting the IP because I enabled wireless and it actually has two valid external IPs. I guess quite a lot of Hassbian users do that 
IF that is the case, it’s quite misleading that it fails with “proxy creation failed” instead of “trouble with detecting my own IP”. I guess it might be worth to add a check there or just report and one should add the local_ip option.
Despite my ranting
, thanks for your help and the component itself! (I wouldn’t have installed HA in the first place without it.)
Well, IP devices are wireless, but they are specifically marketed as IP devices, and “regular” wireless devices pretty much always have “Funk-Dingsbums” in their name, without IP. So in this case, without wanting to be offensive, I would say it’s only unclear because of your newbie-state. 
The names ARE meaningful. For each host you get an entity which you have to use to access the corresponding system variables (if you plan on doing that). Also the “Servicemeldungen” are a part of them. You could have multiple CCUs, where each has it’s own count of relevant “Statusmeldungen”.
Until now nobody has reported the same issue with a similar setup. I have wireless enabled as well and I don’t need to define the local IP. However, that may also depend on how networking/DHCP is setup and what your primary route is.
Internally the error is correct though. It’s the proxy-creation that fails. It properly detects the valid IP address that the system uses for outgoing connections to your CCU. If it wouldn’t succeed doing that, there would be a warning that says “Skipping proxy…”. For now it’s just your case that the detected IP seems not to be in sync with what the CCU want’s to talk to.
I hope you enjoy your ride with HASS. It’s a very powerful alternative to other solutions out there. 
They are also marketed as cloud devices with a Gateway (aka cloud service) instead of CCU… So yeah, the type “IP” is ambiguous, since it could mean the backend system’s type. From there it’s easy to assume that wireless means “Homematic with wireless devices” (unless you know about the several APIs). Do we expect all HM / HA users to know the internas of HomeMatic, just to be able to configure the connection? no.
TL/DR: Me being a newbie and being confused by the documentation is the proof that it totally needs improvement. I guess that also makes me the perfect candidate for doing some improve… I’ll try to come up with some clarifications and update the docs 
Thanks for your help 
.
BTW I think that part with the IP was just a freak accident with a bad connection. I realized that HA fooled me with an old log snippet being shown in the web gui console, so it probably was already working fine for quite some time. Of course, I missed registering the IP part too. Ignore my concerns about the local_ip config 