Homematic HMGeneric.event as trigger

Hello all, Hello @danielperna84,

in the home assistant logs we can see many events similar to these:

2021-03-21 15:47:25 INFO (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: address=NEQ0935446:1, interface_id=homeassistant-rf, key=TEMPERATURE, value=19.8
2021-03-21 15:47:25 INFO (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: address=NEQ0935446:1, interface_id=homeassistant-rf, key=HUMIDITY, value=39
2021-03-21 15:47:26 INFO (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: address=001F5A4993D74B:0, interface_id=homeassistant-ip, key=DUTY_CYCLE_LEVEL, value=5.5
2021-03-21 15:47:27 INFO (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: address=001F5A4993D74B:0, interface_id=homeassistant-ip, key=CARRIER_SENSE_LEVEL, value=4.0

These values are generally represented by entity values or attributes. However in case of the CARRIER_SENSE_LEVEL that is not the case and I’d be happy to contribute a PR if you point me in the right direction.

Related to the issue, as part of my learning experience, I wanted to ask if there is any way to react to these HMGeneric.event’s directly? I am not seeing them in the HA developer view and suspect there is not.

Thanks!

As I don’t know which device has the CARRIER_SENSE_LEVEL parameter I can’t be exact. But you’ll probably have to add it to a devices sensornode somewhere around here.

No. Only event that are within the eventnode will be forwarded as events in Home Assistant. As soon as this is the case, you can follow these instructions.

Thanks for that. So this is a change that needs to be added in pyhomematic. Do you want to discuss further in a ticket over there?

In my setup the parameter is generated by the RPI-RF-MOD but according to 3.55.10.20210213 released - RaspberryMatic :

added a Carrier Sense monitoring. Now, if an RPI-RF-MOD , HmIP-CCU3 or HmIP-HAP device is found to be present its CARRIER_SENSE_LEVEL parameter is queried and in case it reaches >80% a warning is added to the syslog. Furthermore, if the carrier sense level reaches >= 98% a “CarrierSense-Alarm” is triggered so that users are notified.

This part of the code aimed at the HmIP-HAP looks about right.
pyhomematic/pyhomematic/devicetypes/sensors.py at b771ab8a0022ea4e6011fe433860a2b260a44891 · danielperna84/pyhomematic · GitHub
Would probably make sense to create a copy for RPI-RF-MOD, in case things diverge at some point. What do you think?

Best!

Yes, that’s roughly what needs to be done. I haven’t updated my RaspberryMatic in a while, so I can’t contribute in this regard. Anyways, I’m fairly sure the XML-RPC API does not provide a device for RPI-RF-MOD. Have a look at your HM-RCV-50 device (or HmIP, depending on what you are using). If it’s similar to the HmIP-HAP, then it should also have the CARRIER_SENSE_LEVEL on channel 0 I guess.

You can do this manually with a python3 shell the following way:

from xmlrpc.client import ServerProxy
p = ServerProxy("http://1.2.3.4:2001")
# Show the available value-parameters
p.getParamsetDescription("BidCoS-RF:0", "VALUES")
# If CARRIER_SENSE_LEVEL is listed, get the value
p.getValue("BidCoS-RF:0", "CARRIER_SENSE_LEVEL")

If this succeeds, then it should be possible to add this as a sensor of some kind.

Edit: You may have to adjust the BidCoS-RF to something else. That’s the question currently (to find out which device in the API provides the data).

You might to be on to something.

>>> p.getValue("BidCoS-RF:0", "CARRIER_SENSE_LEVEL")
Traceback (most recent call last):
...
xmlrpc.client.Fault: <Fault -5: 'Unknown parameter'>
>>> p.listDevices()
[{'ADDRESS': 'BidCoS-RF', 'CHILDREN': ['BidCoS-RF:0', 'BidCoS-RF:1', 'BidCoS-RF:2', 'BidCoS-RF:3', 'BidCoS-RF:4', 'BidCoS-RF:5', 'BidCoS-RF:6', 'BidCoS-RF:7', 'BidCoS-RF:8', 'BidCoS-RF:9', 'BidCoS-RF:10', 'BidCoS-RF:11', 'BidCoS-RF:12', 'BidCoS-RF:13', 'BidCoS-RF:14', 'BidCoS-RF:15', 'BidCoS-RF:16', 'BidCoS-RF:17', 'BidCoS-RF:18', 'BidCoS-RF:19', 'BidCoS-RF:20', 'BidCoS-RF:21', 'BidCoS-RF:22', 'BidCoS-RF:23', 'BidCoS-RF:24', 'BidCoS-RF:25', 'BidCoS-RF:26', 'BidCoS-RF:27', 'BidCoS-RF:28', 'BidCoS-RF:29', 'BidCoS-RF:30', 'BidCoS-RF:31', 'BidCoS-RF:32', 'BidCoS-RF:33', 'BidCoS-RF:34', 'BidCoS-RF:35', 'BidCoS-RF:36', 'BidCoS-RF:37', 'BidCoS-RF:38', 'BidCoS-RF:39', 'BidCoS-RF:40', 'BidCoS-RF:41', 'BidCoS-RF:42', 'BidCoS-RF:43', 'BidCoS-RF:44', 'BidCoS-RF:45', 'BidCoS-RF:46', 'BidCoS-RF:47', 'BidCoS-RF:48', 'BidCoS-RF:49', 'BidCoS-RF:50'], 'FIRMWARE': '3.57.4.20210320', 'FLAGS': 9, 'INTERFACE': ...

No mentioning of RPI-RF-MOD or CARRIER_SENSE_LEVEL. Question remains, how did the value end up in the Home Assistant log as HMGeneric.event and can that be extracted?

Just so we are clear: I don’t need the value, I just thought it might be worth pointing out that it exists and is currently not reflected in Home Assistant. As the developer of pyhomematic maybe you can best decide how to handle this.

I didn’t have your log in mind when writing down the Python code. If you replace BidCoS-RF:0 with 001F5A4993D74B:0 and connect to http://1.2.3.4:2010 instead, you should get the value. Still, we’d need to find out the name of the device.

Try doing the following:

# Get the name
p.getDeviceDescription('001F5A4993D74B')['TYPE']
# Get the value
p.getValue('001F5A4993D74B:0', 'CARRIER_SENSE_LEVEL')

That worked. I’m not sure what you asked for with your last question. the output of your two commands ist pretty straight forward:

>>> p = ServerProxy("http://192.168.0.25:2010")
>>> p.getDeviceDescription('001F5A4993D74B')['TYPE']
'RPI-RF-MOD'
>>> p.getDeviceDescription('001F5A4993D74B')
{'TYPE': 'RPI-RF-MOD', 'SUBTYPE': 'CCU', 'ADDRESS': '001F5A4993D74B', 'RF_ADDRESS': 11645407, 'CHILDREN': ['001F5A4993D74B:0'], 'PARENT': '', 'PARENT_TYPE': '', 'INDEX': 0, 'AES_ACTIVE': 1, 'PARAMSETS': ['MASTER', 'SERVICE'], 'FIRMWARE': '4.2.14', 'AVAILABLE_FIRMWARE': '0.0.0', 'UPDATABLE': True, 'FIRMWARE_UPDATE_STATE': '', 'VERSION': 2, 'FLAGS': 9, 'LINK_SOURCE_ROLES': '', 'LINK_TARGET_ROLES': '', 'DIRECTION': 0, 'GROUP': '', 'TEAM': '', 'TEAM_TAG': '', 'TEAM_CHANNELS': [], 'INTERFACE': '', 'ROAMING': 0, 'RX_MODE': 0}
>>> p.getValue('001F5A4993D74B:0', 'CARRIER_SENSE_LEVEL')
1.5
>>>

The line with TYPE in it was the one that got the name. And indeed, the device is available as RPI-RF-MOD (I didn’t expect that). So it could be implemented much like the HAP-device that’s already present. :+1:

1 Like

Great, sounds positive. Happy to assist with testing!

Hey @danielperna84, not sure where we left off here but without some help I wouldn’t know where to start. Are you able to work on this improvement? Happy to provide whatever is needed. Once again everything as received from RaspberryMatic 3.61.5.20211113.

2021-11-20 12:57:32 INFO (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: address=001F5A4993D74B:0, interface_id=homeassistant-ip, key=CARRIER_SENSE_LEVEL, value=50.0
>>> from xmlrpc.client import ServerProxy
>>> p = ServerProxy("http://192.168.0.25:2001")
>>> p.getDeviceDescription('001F5A4993D74B')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/homebrew/Cellar/[email protected]/3.9.7_1/Frameworks/Python.framework/Versions/3.9/lib/python3.9/xmlrpc/client.py", line 1116, in __call__
    return self.__send(self.__name, args)
  File "/opt/homebrew/Cellar/[email protected]/3.9.7_1/Frameworks/Python.framework/Versions/3.9/lib/python3.9/xmlrpc/client.py", line 1458, in __request
    response = self.__transport.request(
  File "/opt/homebrew/Cellar/[email protected]/3.9.7_1/Frameworks/Python.framework/Versions/3.9/lib/python3.9/xmlrpc/client.py", line 1160, in request
    return self.single_request(host, handler, request_body, verbose)
  File "/opt/homebrew/Cellar/[email protected]/3.9.7_1/Frameworks/Python.framework/Versions/3.9/lib/python3.9/xmlrpc/client.py", line 1176, in single_request
    return self.parse_response(resp)
  File "/opt/homebrew/Cellar/[email protected]/3.9.7_1/Frameworks/Python.framework/Versions/3.9/lib/python3.9/xmlrpc/client.py", line 1348, in parse_response
    return u.close()
  File "/opt/homebrew/Cellar/[email protected]/3.9.7_1/Frameworks/Python.framework/Versions/3.9/lib/python3.9/xmlrpc/client.py", line 662, in close
    raise Fault(**self._stack[0])
xmlrpc.client.Fault: <Fault -2: 'Unknown instance'>

Not sure what changed…

In your code you are using port 2001, which is the port for old devices. But looking at the address, you’re trying to get the device description of a HmIP device. So you should use port 2010 instead.

Right. Beats me.

>>> p = ServerProxy("http://192.168.0.25:2010")
>>> p.getDeviceDescription('001F5A4993D74B')
{'TYPE': 'RPI-RF-MOD', 'SUBTYPE': 'CCU', 'ADDRESS': '001F5A4993D74B', 'RF_ADDRESS': 11645407, 'CHILDREN': ['001F5A4993D74B:0'], 'PARENT': '', 'PARENT_TYPE': '', 'INDEX': 0, 'AES_ACTIVE': 1, 'PARAMSETS': ['MASTER', 'SERVICE'], 'FIRMWARE': '4.4.12', 'AVAILABLE_FIRMWARE': '0.0.0', 'UPDATABLE': True, 'FIRMWARE_UPDATE_STATE': '', 'VERSION': 2, 'FLAGS': 9, 'LINK_SOURCE_ROLES': '', 'LINK_TARGET_ROLES': '', 'DIRECTION': 0, 'GROUP': '', 'TEAM': '', 'TEAM_TAG': '', 'TEAM_CHANNELS': [], 'INTERFACE': '', 'ROAMING': 0, 'RX_MODE': 0}
>>> p.getValue('001F5A4993D74B:0', 'CARRIER_SENSE_LEVEL')
6.0
>>>