Homematic IP HmIP-BSM PRESS_SHORT not triggering automation

Configuration
1

I’m running Raspberrymatic on a Pi2 and Hass.io on a separate (Ubuntu) machine. The homematic component is working perfectly fine showing status and allowing me to trigger actions, but I can’t get automations to work. There are a couple of similar topics in the forum but none resolved my specific issue:

I have a “dummy program” running in Raspberrymatic to ensure that the keypress events are submitted and I see the events coming in looking at the homeassistant log file like this:

2018-07-09 20:36:11 INFO (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: address=000855699C46EC:2, interface_id=homeassistant-ip, key=PRESS_SHORT, value=True

I’m not using name resolution coming from the CCU/Raspberrymatic but translating to “friendly names” only inside home assistant using the customization.yaml file.

Based on the documentation of the homematic component I should get an additional log entry like this:

2018-01-27 11:51:32 INFO (MainThread) [homeassistant.core] Bus:Handling <Event homematic.keypress[L]: param=PRESS_SHORT, name=your_nice_name, channel=6>

which I don’t get - so far I assumed that’s ok because I don’t use the name resolution but I’m not sure anymore. The documentation talks about the specific issue of not getting the second message and a potential solution (switch from secure to standard communication mode on the HM side). This seems not to work for HmIP-BSM devices: I see the"Übertragungsmodus" option but it’s set to “gesichert” (means secured) and is grayed out / can’t be changed. Anyhow I’m not convinced that there is any reason why it should not work in “secured” mode - the first log entry already unveils all the data required arriving on the home assistant end, therefore there is no reason why the second message should be skipped for security purposes…

Text section from the component documentation:

It may happen that “your_nice_name” is not resolved correctly; the according message (#2 in the above example) will be missing. This might be due to secure communication between your HM interface and the HM device. You can change the communication from “secure” to “standard” within your HM-interface to solve that issue (in “Einstellungen” - “Geräte” find your device and change “Übertragungsmodus” from secure to standard) - not recommended for devices that should have secure communication.

My automation looks like this (simplified as much as possible):

- id: test_automation
  alias: Test Automation
  trigger:
  - event_data:
      channel: 2
      name: 000855699c46ec
      param: PRESS_SHORT
    event_type: homematic.keypress
    platform: event
  action:
  - data:
      entity_id: light.licht_florian
    service: light.toggle

I can trigger the event manually from the home assistant UI and the light toggles, hence the action section should be fine…

2

I think that may be a limitation of the implementation in actors.py. I didn’t do the implementation. From the specs I see that this should be a switch which you should be able to toggle (so you get switch entities in HASS), and a few sensors for power consumption. Is this part wokring correctly?
No what you are trying to do is to intercept the button presses when you control the switch manually. Correct? If so, then, the part that tells HASS to actually listen to such events hasn’t been done by the auther who did the current implementation.

If you don’t mind you can open an issue here and I’ll try to get this working together with you. You would need a separate HASS installation which is not hassio based. A VM with a direct HASS installation would be best. There you could simply exchange the code and test if it is working. With hassio this can’t be easily done, and also it would impact your otherwise running system.

3

You are right - I can toggle the relay from HA and I get power consumption data.
I was just scanning through the logs filtering for the specific device and comparing to the code… it looks like the HA homematic component does not register any event listeners for channels 1 and 2 (lower/upper button) which fits your explanation. I’ll have a look tomorrow and get a test HA installation setup for debugging.

4

I got it working.

2018-07-10 00:20:46 INFO (Thread-22) [pyhomematic.devicetypes.generic] HMGeneric.event: address=000855699C46EC:1, interface_id=homeassistant-ip, key=PRESS_SHORT, value=True
2018-07-10 00:20:46 DEBUG (Thread-22) [homeassistant.components.homematic] Event PRESS_SHORT for 000855699C46EC channel 1
2018-07-10 00:20:46 INFO (MainThread) [homeassistant.core] Bus:Handling <Event homematic.keypress[L]: name=000855699C46EC, param=PRESS_SHORT, channel=1>

Actually it’s not too hard to modify directly in a running hass.io installation:

  • docker exec -it homeassistant /bin/bash
  • cd usr/lib/python3.6/site-packages/pyhomematic/devicetypes
  • edit actors.py (not so nice, I used vi)
  • exit
  • docker restart homeassistant

So here is what I did in actors.py:

...
from pyhomematic.devicetypes.helper import (
    HelperWorking, HelperActorState, HelperActorLevel, HelperActorBlindTilt, HelperActionOnTime,
    HelperActionPress, HelperEventRemote, HelperWired, HelperEventPress)
...
class HMEvent(HMDevice):
    pass
...
class IPSwitchPowermeterRemote(IPSwitchPowermeter, HMEvent, HelperEventRemote, HelperActionPress):
    """
    Switch turning plugged in device on or off and measuring energy consumption with remote handle buttons.
    """

    @property
    def ELEMENT(self):
        if "HmIP-BSM" in self.TYPE:
            return [1, 2]
        return [1]
...
DEVICETYPES = {
...
    "HmIP-BSM": IPSwitchPowermeterRemote,
...
}

I’ll test this a little further tomorrow - especially if the relay and energy monitoring still works. I’m actually not too sure what the generic HMEvent does and if it’s required (I’m not a python guru - usually working with nodejs, c++, c#, java). If this is working reliable I’ll create a pull request. Any preferences in terms of class names etc. that I should take into account?

5

Guess I need to learn a little more about multiple inheritance in python first… the events come through now but I can’t control the relay anymore from HA (pretty sure that worked before) likely because I’m redefining ELEMENT instead of just adding 1 and 2 to the list…
As far as I understand the code, HMEvent would not be required as it already inherits from HMDevice through IPSwitchPowermeter -> HMSensor -> HMDevice but just in case anything would be implemented on the HMEvent level at any point i kept it in not redefining the class as done above but importing it from misc.py.

6

I have created a the hmip_bsm branch at pyhomematic. Please try the actors.py from there. The class is called IPSwitchPowermeterRemote, so that has to be added to the homematic component of HASS (like you probably already did with your tests).
Please report if my version of the class kept all the existing functionality and now also enables the events. What I don’t know is if the device supports more than just PRESS_SHORT. I have added the other common ones in case the are also present in the device.

7

I have it fully working now (existing functionality as well as the new events firing). I actually changed the class name to IPKeySwitchPowermeter which felt more in line with classes for other devices where one version with local switches and one without exists…

Thanks for the hint that the new class name needs to be added to the homematic component - that was why the devices completely disappeared from the UI before (working now)!

The HmIP-BSM definitely supports PRESS_SHORT and PRESS_LONG. Not sure how to confirm if PRESS_CONT or PRESS_LONG_RELEASE are supported - I at least don’t see those in the log files.

I’m a little confused about your hmip_bsm branch and why I should use the actors.py from there - it shows last changed three months ago and appears to be exactly the same as the one I used before. I can for sure create the pull request against that branch if that was the intention.

EDIT:
Pull request to the branch submitted #146. For the pull request to the home assistant component please confirm what to put in as requirement? Should this end up in version 0.1.45 of pyhomematic so I should update the requirements section to 45 as well? Other than that changes to the __init__.py are simple:

REQUIREMENTS = ['pyhomematic==0.1.45']

…

    DISCOVER_SWITCHES: [
        'Switch', 'SwitchPowermeter', 'IOSwitch', 'IPSwitch', 'RFSiren',
        'IPSwitchPowermeter', 'IPKeySwitchPowermeter', 'HMWIOSwitch', 'Rain', 'EcoLogic'],

…

    DISCOVER_SENSORS: [
        'SwitchPowermeter', 'Motion', 'MotionV2', 'RemoteMotion', 'MotionIP',
        'ThermostatWall', 'AreaThermostat', 'RotaryHandleSensor',
        'WaterSensor', 'PowermeterGas', 'LuxSensor', 'WeatherSensor',
        'WeatherStation', 'ThermostatWall2', 'TemperatureDiffSensor',
        'TemperatureSensor', 'CO2Sensor', 'IPSwitchPowermeter', 'IPKeySwitchPowermeter', 'HMWIOSwitch',
        'FillingLevel', 'ValveDrive', 'EcoLogic', 'IPThermostatWall',
        'IPSmoke', 'RFSiren', 'PresenceIP', 'IPAreaThermostat',
        'IPWeatherSensor', 'RotaryHandleSensorIP'],
8

I messed the branches up there because I was also doing some other stuff related to pyhomematic. I’ll have a look at your PR.

No, 0.1.45 has become a bugfix release and is already published. 0.1.46 will be the version your work will end up in.

Regarding the PRESS_CONT and PRESS_LONG_RELEASE: they appear when you keep holding the button. PRESS_CONT will appear as an event in intervals, so you could for example gradually dim lights. PRESS_LONG_RELEASE is fired when you finally let go of the button.
Those events usually make more sense for devices that don’t have any actor included, so it could indeed be, that those events don’t get fired.

9

Page 1099 (yes, really) in the device description says that HmIP-BSM is supporting PRESS_SHORT and PRESS_LONG only…

I’m wondering if it would be possible to parse that document somehow and build the classes from it because eq-3 is actually updating it with a high frequency probably whenever a new device is added or a new firmware version has a significant impact :slight_smile: