Homematic component does not show CUxD devices

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. :wink:

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. :wink:

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:

  • It seems the XML-RPC interface needs to be called for the Wired and the RF interfaces separately. Since CUxD resides beside them how should they know about this one?
  • I checked the XML-API addon’s code, and it seems to access ReGA, which is the CCU-Logikschicht. As this knows about all underlying interfaces obviously it can display the CUxD devices.

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.

You are right the formulas do not need to be 100% accurate. In principle the Magnus formula is also just an approximation. However it is fatal if you try to use two different such approximations in the same automation system.

I will leave CUxD in operation as it does not add another device to the ‘crucial’ venting to prevent mold. Since I moved some of the other scripts to HomeAssistant the CCU2 can quite efficiently work on that - even when the docker container for Home Assistant is down for whatever reason.

To still display values and maybe script more on them I will try to use the BIN-RPC Converter you indicated above which can be found here: https://homematic-forum.de/forum/viewtopic.php?f=44&t=8211

Thank you for the constructive discussion. :slight_smile:

For future visitors (found the topic by Google):
To control CUxD devices from HomeAssistant you can use RedMatic on your CCU/RaspberryMatic and control the CUxD device by a mqtt broker.

1 Like

Hey that sounds promising. To be honest I have never used RedMatic and realizing a CUXD device intergration would be my only reason to start with it.

@tringler Is it possible to post an example for RedNote and mqtt newbies?

Just to avoid a misunderstanding - RedMatic is just NodeRed with Homematic Nodes as a HomeMatic 3rd party add-on.
This is my use-case to control my 433Mhz covers:

[{"id":"ad41a438.412a88","type":"tab","label":"CUxD2MQTT","disabled":false,"info":""},{"id":"f2fea849.b6047","type":"ccu-value","z":"ad41a438.412a88","name":"Rolladen schließen","iface":"CUxD","channel":"CUX4009001:2 workroom_cover:2","datapoint":"PRESS_SHORT","mode":"","start":true,"change":true,"cache":false,"queue":false,"on":0,"onType":"undefined","ramp":0,"rampType":"undefined","working":false,"ccuConfig":"38263145.35ea0e","topic":"${CCU}/${Interface}/${channel}/${datapoint}","x":590,"y":200,"wires":[[]]},{"id":"47577fb3.8e0a48","type":"ccu-value","z":"ad41a438.412a88","name":"Rolladen öffnen","iface":"CUxD","channel":"CUX4009001:1 workroom_cover:1","datapoint":"PRESS_SHORT","mode":"","start":true,"change":true,"cache":false,"queue":false,"on":0,"onType":"undefined","ramp":0,"rampType":"undefined","working":false,"ccuConfig":"38263145.35ea0e","topic":"${CCU}/${Interface}/${channel}/${datapoint}","x":580,"y":140,"wires":[[]]},{"id":"2c3aae70.8b157a","type":"mqtt in","z":"ad41a438.412a88","name":"","topic":"cover/workroom/set","qos":"2","datatype":"utf8","broker":"3be2ebe7.e23be4","x":130,"y":140,"wires":[["ca29ab58.509028"]]},{"id":"ca29ab58.509028","type":"switch","z":"ad41a438.412a88","name":"","property":"payload","propertyType":"msg","rules":[{"t":"eq","v":"OPEN","vt":"str"},{"t":"eq","v":"CLOSE","vt":"str"}],"checkall":"false","repair":false,"outputs":2,"x":330,"y":140,"wires":[["47577fb3.8e0a48"],["f2fea849.b6047"]]},{"id":"1afce398.09831c","type":"ccu-value","z":"ad41a438.412a88","name":"Rolladen schließen","iface":"CUxD","channel":"CUX4009003:2 livingroom_cover:2","datapoint":"PRESS_SHORT","mode":"","start":true,"change":true,"cache":false,"queue":false,"on":0,"onType":"undefined","ramp":0,"rampType":"undefined","working":false,"ccuConfig":"38263145.35ea0e","topic":"${CCU}/${Interface}/${channel}/${datapoint}","x":590,"y":500,"wires":[[]]},{"id":"fc718b42.08f328","type":"ccu-value","z":"ad41a438.412a88","name":"Rolladen öffnen","iface":"CUxD","channel":"CUX4009003:1 livingroom_cover:1","datapoint":"PRESS_SHORT","mode":"","start":true,"change":true,"cache":false,"queue":false,"on":0,"onType":"undefined","ramp":0,"rampType":"undefined","working":false,"ccuConfig":"38263145.35ea0e","topic":"${CCU}/${Interface}/${channel}/${datapoint}","x":580,"y":440,"wires":[[]]},{"id":"3ea6b3b1.18a97c","type":"mqtt in","z":"ad41a438.412a88","name":"","topic":"cover/livingroom/set","qos":"2","datatype":"utf8","broker":"3be2ebe7.e23be4","x":130,"y":440,"wires":[["daedf030.9a655"]]},{"id":"daedf030.9a655","type":"switch","z":"ad41a438.412a88","name":"","property":"payload","propertyType":"msg","rules":[{"t":"eq","v":"OPEN","vt":"str"},{"t":"eq","v":"CLOSE","vt":"str"}],"checkall":"false","repair":false,"outputs":2,"x":330,"y":440,"wires":[["fc718b42.08f328"],["1afce398.09831c"]]},{"id":"9398eaf0.141e08","type":"ccu-value","z":"ad41a438.412a88","name":"Rolladen schließen","iface":"CUxD","channel":"CUX4009002:2 guestroom_cover:2","datapoint":"PRESS_SHORT","mode":"","start":true,"change":true,"cache":false,"queue":false,"on":0,"onType":"undefined","ramp":0,"rampType":"undefined","working":false,"ccuConfig":"38263145.35ea0e","topic":"${CCU}/${Interface}/${channel}/${datapoint}","x":590,"y":360,"wires":[[]]},{"id":"9f6741ac.85989","type":"ccu-value","z":"ad41a438.412a88","name":"Rolladen öffnen","iface":"CUxD","channel":"CUX4009002:1 guestroom_cover:1","datapoint":"PRESS_SHORT","mode":"","start":true,"change":true,"cache":false,"queue":false,"on":0,"onType":"undefined","ramp":0,"rampType":"undefined","working":false,"ccuConfig":"38263145.35ea0e","topic":"${CCU}/${Interface}/${channel}/${datapoint}","x":580,"y":300,"wires":[[]]},{"id":"a2ede75c.81a698","type":"mqtt in","z":"ad41a438.412a88","name":"","topic":"cover/guestroom/set","qos":"2","datatype":"utf8","broker":"3be2ebe7.e23be4","x":130,"y":300,"wires":[["2f4b3626.53d13a"]]},{"id":"2f4b3626.53d13a","type":"switch","z":"ad41a438.412a88","name":"","property":"payload","propertyType":"msg","rules":[{"t":"eq","v":"OPEN","vt":"str"},{"t":"eq","v":"CLOSE","vt":"str"}],"checkall":"false","repair":false,"outputs":2,"x":330,"y":300,"wires":[["9f6741ac.85989"],["9398eaf0.141e08"]]},{"id":"38263145.35ea0e","type":"ccu-connection","z":"","name":"localhost","host":"localhost","regaEnabled":true,"bcrfEnabled":true,"iprfEnabled":true,"virtEnabled":true,"bcwiEnabled":false,"cuxdEnabled":true,"regaPoll":true,"regaInterval":"30","rpcPingTimeout":"60","rpcInitAddress":"127.0.0.1","rpcServerHost":"127.0.0.1","rpcBinPort":"2047","rpcXmlPort":"2048","queueTimeout":"5000","queuePause":"250","contextStore":""},{"id":"3be2ebe7.e23be4","type":"mqtt-broker","z":"","name":"hass-broker","broker":"192.168.178.200","port":"1883","clientid":"","usetls":false,"compatmode":false,"keepalive":"60","cleansession":true,"birthTopic":"","birthQos":"0","birthPayload":"","closeTopic":"","closeQos":"0","closePayload":"","willTopic":"","willQos":"0","willPayload":""}]

On HomeAssistant config:

cover:
  - platform: mqtt
    name: workroom
    command_topic: "cover/workroom/set"
  - platform: mqtt
    name: guestroom
    command_topic: "cover/guestroom/set"
  - platform: mqtt
    name: livingroom
    command_topic: "cover/livingroom/set"

Thanks Tom.
This is exactly the use-case that I need as well.
Now I will try to figure out how to aply this use-case to my setup.

I have already installed the Redmatic addon. (I cannot see my CUXD devices even if I try activivate the interface)

I guess next step is to install the necessary MQTT addon for HA. Do I need a Server or just a Client?

Maybe I can start a Note Red Tutorial this evening.

Hi there, I found a similar solution to get cuxd devices working.
redmatic was a good starting point, but as I only own a ccu2, and not a ccu3 this option is not available to me. But it is not necessary to have node-red running as an ccu add.on, because we already have node-red in home assistant.

so all we have to do is adding this node-red node, which is also used inside redmatic

node-red-contrib-ccu

to home assistant node-red

installation:

in node-red use menu settings -> Palette -> install and search for “node-red-contrib-ccu”

my use case:

i have some old FS20 plugs (868 mhz) that i have added to ccu2 cuxd daemon

to make them usable with my home assistant I have added an

input_boolean.homematic_fs20_st_01

which i have used inside a state node, which is connected to an ccu-set-value node.

the ccu-set-value node is configured:


"iface": "CUxD",
"deviceName": "FS20_ST_01"
"channelName": "FS20_ST_01:1",
"channelType": "SWITCH",
"channelIndex": "1",
"datapoint": "STATE"

on first connection you have to configure the network connection to your ccu with “add new ccu connection”

just enter your ccu adress ip and tick the CuxD checkbox

for debugging you can use a ccu-rpc-event node with a debug node, so see the events, that the ccu send to home assistant.

now when click on my boolean switch “homematic_fs20_st_01” the command goes via rpc-bin to the ccu/cuxd and triggers my fs20 plug

Greetings,
JohnDoe

1 Like

You need a MQTT server. You need to activate CUXD in your CCU configuration node manually. Did you activated the interface there?