Hi there.
I use a Homematic CCU2 device with the CUxD addon (https://github.com/jens-maus/cuxd).
For me the main benefit is that my temperature/humidity sensors get wrapped into virtual devices that also provide calculated values for absolute humidity.
HomeAssistant proves to be a better user experience than the Homematic native interface. But for some reason the virtual devices never get displayed. Why that? How can I change it?
Hiran
CUxD devices don’t work with Home Assistant. In contrast to regular wireless and wired devices (which use the plain XML-RPC protocol), CUxD useres binary RPC. The library that is being used for communication between Home Assistant and the CCU (pyhomematic) does not support binary RPC. And it will likely never be supported. So you’ll have to find an alternative way of integrating those devices into Home Assistant.
Edit:
I just did a quick search. If you speak german this thread might be useful for you. Seems as if this tool is capable of acting like a proxy. So you could add an interface just like for the regular devices that points to this proxy.
Edit 2:
Another solution to at least read the state manuall would be by querying for the value via HTTP. A query would look like this: http://192.168.1.23:8181/do.exe?r1=dom.GetObject('CUxD.CUX2803001:1.STATE').State
Hi Daniel.
Thank you again for the quick reply. Yes, I do speak german and will checkout that link.
I will also investigate a bit on the CCU. Somehow your statement that CUxD devices are not visible via JSON-RPC is a surprise for me. I have already successfully created an CCU2 Exporter for Prometheus so I can visualize the data on Grafana. Here I used the XML-RPC interface and have access to all devices - including CUxD.
Hiran
JSON-RPC != XML-RPC != BIN-RPC 
JSON-RPC is what you can look at by browsing to http://ccu/api/homematic.cgi. We use this to resolve the names of devices and get/set variables. I have never checked if CUxD devices are available here.
XML-RPC uses a dedicated module in Python to communicate with ports 2000, 2001, 2010 etc… By using this module I was not able to see CUxD devices. Obviously they don’t show up on the default ports. And connecting to the CUxD port 8701 only returns empty strings when using the Python module. Here’s an example:
>>> from xmlrpc.client import ServerProxy
>>> p = ServerProxy("http://192.168.1.23:8701")
>>> p.getValue("CUX2803001:1", "STATE")
''
If you succeed, please let me know how.
And finally there’s BIN-RPC, which as far as I know is the only protocol CUxD actually talks. The tool mentioned in my previous answer has manually implemented BIN-RPC in PHP. Theoretically this could also be done in Python. But I have never found someone doing it. And I don’t see a big value in it for Home Assistant, because a lot of devices which for which CUxD is being used have native support in Home Assistant, or can be implemented with not too much effort.
Hi Daniel.
I am aware we are talking about three different interfaces.
So now I checked the JSON-RPC on my CCU. And interestingly my CUxD devices are listed. Here is an excerpt of the resonse I got from calling Device.listAllDetail:
{
“id” : “9946”,
“name” : “executor”,
“address” : “CUX2801001”,
“interface” : “CUxD”,
“type” : “HM-RC-19”,
“operateGroupOnly” : “false”,
“isReady” : “true”,
“channels” : [ {
“id” : “9960”,
“name” : “executor:1”,
“address” : “CUX2801001:1”,
“deviceId” : “9946”,
“index” : 1,
“partnerId” : “”,
“mode” : “MODE_DEFAULT”,
“category” : “CATEGORY_NONE”,
“isReady” : true,
“isUsable” : true,
“isVisible” : true,
“isLogged” : false,
“isLogable” : true,
“isReadable” : true,
“isWritable” : true,
“isEventable” : true,
“isAesAvailable” : false,
“isVirtual” : false,
“channelType” : “KEY”
}
and another one
{
“id” : “9896”,
“name” : “TH_Abstellraum”,
“address” : “CUX9002022”,
“interface” : “CUxD”,
“type” : “HM-CC-TC”,
“operateGroupOnly” : “false”,
“isReady” : “true”,
“channels” : [ {
“id” : “9902”,
“name” : “TH_Abstellraum:1”,
“address” : “CUX9002022:1”,
“deviceId” : “9896”,
“index” : 1,
“partnerId” : “”,
“mode” : “MODE_DEFAULT”,
“category” : “CATEGORY_NONE”,
“isReady” : true,
“isUsable” : true,
“isVisible” : true,
“isLogged” : false,
“isLogable” : true,
“isReadable” : true,
“isWritable” : false,
“isEventable” : true,
“isAesAvailable” : false,
“isVirtual” : false,
“channelType” : “WEATHER”
}, {
“id” : “9914”,
“name” : “TH_Abstellraum:2”,
“address” : “CUX9002022:2”,
“deviceId” : “9896”,
“index” : 2,
“partnerId” : “”,
“mode” : “MODE_DEFAULT”,
“category” : “CATEGORY_NONE”,
“isReady” : true,
“isUsable” : true,
“isVisible” : true,
“isLogged” : false,
“isLogable” : true,
“isReadable” : true,
“isWritable” : true,
“isEventable” : true,
“isAesAvailable” : false,
“isVirtual” : false,
“channelType” : “CLIMATECONTROL_REGULATOR”
}, {
“id” : “9919”,
“name” : “TH_Abstellraum:3”,
“address” : “CUX9002022:3”,
“deviceId” : “9896”,
“index” : 3,
“partnerId” : “”,
“mode” : “MODE_DEFAULT”,
“category” : “CATEGORY_NONE”,
“isReady” : true,
“isUsable” : true,
“isVisible” : true,
“isLogged” : false,
“isLogable” : false,
“isReadable” : false,
“isWritable” : false,
“isEventable” : false,
“isAesAvailable” : false,
“isVirtual” : false,
“channelType” : “SWITCH”
} ]
}
Maybe this has changed after you made your tests, but now the devices are available. Which lets me come back to the initial question: Why are they not displayed in HomeAssistant?
Edit: I am no Python expert but maybe the example code you have is too complicated. Just enter this URL into your browser (runs a GET request), then parse the received XML as you like:
http://ccu/addons/xmlapi/devicelist.cgi
Because Home Assistant uses XML-RPC to communicate with devices. The XML-RPC API of the CCU has an operating mode where you can subscribe to receive changed states of devices. In short, the pyhomematic library creates an XML-RPC server, to which the CCU sends information like “the sensor X now has the value Y”. By doing this we instantly get the current values without ever having to poll the API.
The problem with JSON-RPC is, that it does not have this functionality. You can’t tell the CCU to send state by any other way than via XML-RPC or BIN-RPC. And BIN-RPC is not available in pyhomematic.
So you use XML-RPC for the communication, and JSON-RPC is just used to resolve names? But then again the CUxD devices are listed. In my case here is a snippet:
<device name="TH_Dusche" address="CUX9002025" ise_id="10366" interface="CUxD" device_type="HM-CC-TC" ready_config="true"><channel name="TH_Dusche:1" type="22" address="CUX9002025:1" ise_id="10372" direction="UNKNOWN" parent_device="10366" index="1" group_partner="" aes_available="false" transmission_mode="DEFAULT" visible="true" ready_config="true" operate="true"/><channel name="TH_Dusche:2" type="17" address="CUX9002025:2" ise_id="10384" direction="UNKNOWN" parent_device="10366" index="2" group_partner="" aes_available="false" transmission_mode="DEFAULT" visible="true" ready_config="true" operate="true"/><channel name="TH_Dusche:3" type="26" address="CUX9002025:3" ise_id="10389" direction="UNKNOWN" parent_device="10366" index="3" group_partner="" aes_available="false" transmission_mode="DEFAULT" visible="true" ready_config="true" operate="true"/></device>
Yes. And variables.
When using JSON-RPC. But I’m sure you don’t get that data via XML-RPC. And again, it’s XML-RPC that’s used to create all the entities you see in Home Assistant. In contrast, the variables you get via JSON-RPC are all just attributes of your hub entity. It was never the objective of pyhomematic to fetch device-data by any other way than XML-RPC, because every kind of HomeMatic hub (CCU, Homegear and others) provides the XML-RPC API. And for XML-RPC there’s a native module for Python.
And as metioned above, if we would implement to also use JSON-RPC for CUxD devices, these devices could only be polled. So their value would only be updated once a minute. That could be done. But I don’t see value in that. For example, there’s a ping-sensor for CUxD to check if devices are online in the network. Home Assistant can do that. And CUxD has support for EnOcean devices. And Home Assistant supports those natively. So for the rest of the few potential devices that CUxD might add to the mix, it’s just not worth the effort for the few people that use them. Unless I would get paid to do that. 
You make me speechless. Did you read what I posted above? I can see the devices are listed. You say “I am sure you don’t get that data”…
:-S
Then please use the Python code I have posted above as an example so I can test it. The output the XML-RPC API provides looks totally different than what you have posted.
Then I get the feeling we are talking about a fourth interface. My browser title says “XML API”. Hooray Homematic!
I will try to invoke your example.
So that’s where the confusion comes from. You’re talking about the XML API addon. I am talking about the XML-RPC API which is directly embedded into the CCU without installing any addon.
'Python 3.6.7 (default, Oct 22 2018, 11:32:17)
[GCC 8.2.0] on linux
Type “help”, “copyright”, “credits” or “license” for more information.
from xmlrpc.client import ServerProxy
p = ServerProxy(“http://192.168.178.39:8701”)
p.getValue(“CUX9002022:1”, “STATE”)
‘’
’
Seems now I am accessing the XML-RPC interface. And I get the same result as you. Not what I liked to see, but now we are in sync.
So XML-RPC cannot see the devices. And JSON-RPC can but does not offer callbacks.
Maybe I need to raise an issue with Homematic - probably they won’t care about CUxD devices.
I’m also checking the XML-RPC documentation you linked above. It states ports 2000 and 2001, which I specified in the HomeAssistant configuration. Where does 8701 come from?
They can’t really do anything about that. HTTP is rather inefficient for this job. It could be done, but it would make much more sense to add a new API that’s based on websockets. But I’m 99% sure they won’t do that. XML-RPC is perfectly fine and works for everything. Just not CUxD, which is just an addon. If you were to reach out to someone, then it would be the CUxD developer to tell him to add the XML-RPC API, because that’s the standard every other HomeMatic hub implements. But then again he will argue that other software like ioBroker bothered to actually implement BIN-RPC. We’re all lazy.
There are even more. 2010 for HomeMatic IP and 9292 for thermostat groups. And on the SSU3 with enabled SSL the all have a leading 4. So 42001 for example for regular wireless devices.
The 8701 is the port the CUxD developer chose to use for his BIN-RPC implementation. If you open the CUxD interface (http://ccu/addons/cuxd/index.ccc), there’s a textbos with all kinds of information. There RPCPORT by default is set to 8701.
I think I am slowly getting into it. There is a nice architecture diagram in the CUxD documentation (https://homematic-forum.de/forum/download/file.php?id=54596&sid=6109799f40ac8a79284aae60e15e31d6, page 4). From this everything we discussed above makes perfectly sense:
The strange thing is why the JSON-RPC interface would know about CUxD unless it also operates on ReGA. I am also wondering what purpose the Event methods in JSON-RPC are supposed to serve.
As far as I know, when subscribing to the events you still have to poll, but from poll to poll you only get the data of changed devices, not your entire inventory.
However, I don’t see JSON-RPC as an efficient solution. The only solution that would make sense would be to either have BIN-RPC support in pyhomematic or XML-RPC in CUxD. I would highly prefer CUxD supporting XML-RPC, because BIN-RPC support in pyhomematic would require starting an additional RPC-server (for the BIN-events), which consumes as least one extra thread and an additional socket. If instead CUxD would support XML-RPC we would just have one extra object in memory that handles the outgoing communication. So that would be a lot more performant compared to anything else. And exactly this setup can already be achieved now if you use the converter-daemon I have mentioned above.
But then there’s another problem: HomeMatic devices have exact specifications. We know which channel does what for each device type. With CUxD devices this may not always be clear. So even if we could talk to CUxD, we wouldn’t know how to handle the data we receive.
If I may ask: what kind of devices are you using in CUxD that are not already compatible with Home Assistant?
It seems I wrongly replied to the email I received, which just came back as not deliverable. Hence my late reply…
As far as I know, when subscribing to the events you still have to poll, but from poll to poll you only get the data of changed devices, not your entire inventory.
However, I don’t see JSON-RPC as an efficient solution. The only solution that would make sense would be to either have BIN-RPC support in pyhomematic or XML-RPC in CUxD. I would highly prefer CUxD supporting XML-RPC, because BIN-RPC support in pyhomematic would require starting an additional RPC-server (for the BIN-events), which consumes as least one extra thread and an additional socket. If instead CUxD would support XML-RPC we would just have one extra object in memory that handles the outgoing communication. So that would be a lot more performant compared to anything else. And exactly this setup can already be achieved now if you use the converter-daemon I have mentioned above.
But then there’s another problem: HomeMatic devices have exact specifications. We know which channel does what for each device type. With CUxD devices this may not always be clear. So even if we could talk to CUxD, we wouldn’t know how to handle the data we receive.
It seems this is more complicated when looking at details.
If I may ask: what kind of devices are you using in CUxD that are not already compatible with Home Assistant?
As you mentioned many features can be implemented on HomeAssistant straight away. What I was missing in Homematic was absolute humidity. I need this to decide whether to activate a fan to swap inside/outside air.
There is an excellent explanation in this article: Homematic Raumklimaüberwachung und Entfeuchtung | SMART WOHNEN
Unfortunately humidity is measured relavitely (and given in %). You need a path from relative humidity and temperature to absolute humidity. I coded this in Homematic Script. It was ugly, ate performance and was error prone. Finally I found CUxD to perform this calculation in the background and very well.
This is my current leftover use case for CUxD. So far I have not seen anyone trying to calculate absolute humidity in HomeAssistant. Do you know a way? It might be useful on any humidity/temperature sensor - not just Homematic.
Hiran
That indeed would be useful. I’ve done a quick search at google and found this Python code (from here):
import math
# Compute saturated water vapor pressure in hPa
# Param t - temperature in °C
def svp(t):
svp = 6.112 * math.exp((17.67*t)/(243.5+t))
return svp
# Compute actual water vapor pressure in hPa
# Param rh - relative humidity in %
# Param t - temperature in °C
def vp(rh, t):
vp = rh/100. * svp(t)
return vp
# Compute the absolute humidity in g/m³
# Param rh - relative humidity in %
# Param t - temperature in °C
def ah(rh, t):
mw = 18.016 # kg/kmol (Molekulargewicht des Wasserdampfes)
rs = 8314.3 # J/(kmol*K) (universelle Gaskonstante)
ah = 10**5 * mw/rs * vp(rh, t)/(t + 273.15)
return ah
Does the result of ah(54, 24.5) (as an example 54% humidity and 24.5°C) roughly match what the CUxD solution reports as absolute humidity? If so, it wouldn’t be a lot of work to make a custom component for this. It’s probably a bit too complex for a template sensor.
Edit:
Probably the easiest short term solution would be to modify the code from above to make it a standalone Python script which you call with the temperature and humidity passed as arguments. Then you could use the Command line sensor together with templates for the values of your sensors to get the absolute humidity.
It’s been a while since I did that. What I can say at that time I tried to implement the Magnus formula
(https://de.wikipedia.org/wiki/Sättigungsdampfdruck#Berechnung_und_Einflussfaktoren) which seems to be more complex as it differences liquid and icy surfaces. Inbetween I also saw methods that simplify that approach since only a limited temperature range is required. But how would you rate the quality of a two-dimensional function by comparing a single pair of input values?
In this case I’d either use a matrix of input values, fill the fields with the function’s result and compare the matrixes that each of the functions would fill. Or I’d try to compare the source code.
Unfortunately the source code comparison seems not to work out. The code is no longer open:
https://homematic-forum.de/forum/viewtopic.php?t=13244
Since I don’t know how to fake CCU2 devices I also cannot inject the required test values into CUxD to fill the matrix. In this case I’d simply have to guess the values you have are good enough to start with.
The code I have posted also uses the Magnus formula. And honestly, I assume the place where you are going to use this is not some sort of high tech laboratory where 100% accurate calculations are necessary. In home automation it’s more about “should I vent after taking a shower?”, and for that purpose a simplified solution for a rather narrow temperatur-range should be more than enough.
I have assumed you already have a system running that outputs absolute humidity. At least you were asking for support for CUxD, so I thought you already have such a number in place. If so, you could just take a look of the humidity and temperature for that location and what the calculated absolute humidity is. Take those numbers and feed it into the code from above. If CUxD says 11.3 and the code 11.7 it’s close enough to work with this.
If that does not fit your needs, have a look at this thread. There a user has tried to calculate absolute humidity by using AppDaemon. You could reach out to him to see if he has gotten useful results with his work.