Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for Homematic IP #23

Open
marianokamp opened this issue Dec 28, 2017 · 3 comments
Open

Support for Homematic IP #23

marianokamp opened this issue Dec 28, 2017 · 3 comments

Comments

@marianokamp
Copy link

Continuing from the conversation that I started here, (but was in the wrong place).

Lars, following up on the guidance you gave I had a look. In api.py/DeviceSpecs you set the interface to BidCos-RF, which I suspect is only the classic HM.

for spec in self._api.interface_list_devices(interface="BidCos-RF"):

When you query for the interfaces you get this:

[interface['name'] for interface in self._api.interface_list_interfaces()]
=> ['BidCos-RF', 'VirtualDevices', 'HmIP-RF']

We'll get a little bit further when using HmIP-RF as well. However than I ran into another issue. The additional specs provided by HmIP-RF seem to collide with the model you had in mind.

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/mkamp/repos/code/pmatic/pmatic/ccu.py", line 288, in query
    for device in self._query_for_devices(**filters):
  File "/Users/mkamp/repos/code/pmatic/pmatic/ccu.py", line 305, in _query_for_devices
    device = self._create_from_low_level_dict(spec)
  File "/Users/mkamp/repos/code/pmatic/pmatic/ccu.py", line 358, in _create_from_low_level_dict
    device = Device.from_dict(self._ccu, spec)
  File "/Users/mkamp/repos/code/pmatic/pmatic/entities.py", line 955, in from_dict
    return device_class(ccu, spec)
  File "/Users/mkamp/repos/code/pmatic/pmatic/entities.py", line 944, in __init__
    super(Device, self).__init__(ccu, spec)
  File "/Users/mkamp/repos/code/pmatic/pmatic/entities.py", line 53, in __init__
    self._verify_mandatory_attributes()
  File "/Users/mkamp/repos/code/pmatic/pmatic/entities.py", line 101, in _verify_mandatory_attributes
    raise PMException("The mandatory attribute \"%s\" is missing." % key)
pmatic.exceptions.PMException: The mandatory attribute "channels" is missing.

I unfortunately don't really have the time to work on this in earnest and there is so much around (your code, the API, homematic, Python) that I need to learn about which make it hard to do something quickly.

If you don't mind I will continue slowly, no promises) and document what I learn along the way. For you or anybody else to pitch in, so that it eventually gets solved (or eventually closed).

Btw. Nice and well documented code.

@khillman
Copy link

I think you are on the right way (HmIP-RF)... - i've tried using pmatic as well in last september for homematic ip devices with the same problem you already mentioned - more or less no devices found... As the most important feature (and the only one at this time) for me was to switch on/off a power switch i decided to hack that myself using requests and a minimal generic own jsonrpc wrapper. This approach is working like a charm but it is more (no broad pythonic api actually only list of devices/interfaces) or less (generic method to call the jsonrpc api) limited to that usecase and as i now want to integrate things with push eventing, i think about whether to build a pretty small library around that wrapper to support the eventing stuff or whether i try to fix this issue in pmatic and make a PR for that. Currently I'm not sure whether there are many complex places that are restricted to the BidCos-RF Interface as HmIP-RF was not in scope previously. Did you have learned a bit more how complex it would be to enable pmatic the use of more than one Interface for device enumeration, device usage, eventing and so on?

Due to a quick grep "BidCos-RF" is contained and hard coded at least in :

  • params.py
  • ccu.py
  • events.py
  • entities.py
  • api.py

Just to make sure - i'm not sure when i'll find the needed free time to implement one of the two options above. I just wanted to inform you that you are on the right track to solve your issue as i'm also use the HmIP-RF Interface and a call to Interface.listDevices to enumerate the known HmIP devices.

@jschmer
Copy link
Contributor

jschmer commented Mar 25, 2018

You could take a look at jschmer/pmatic@5146347 where I added support for virtual devices. Those are available in the 'VirtualDevices' interface, similar to how HM IP devices are available in the 'HmIP-RF' interface.
I think the documentation said that HM IP interface is not entirely compatible with the Bidcos-RF interface so there may be some issues along the line.
If I'm not mistaken, self._api.interface_list_devices also returns channels belonging to a device so I guess the first step is to modify the condition to detect if a 'device' is just a channel or really a device. That's probably where the error 'The mandatory attribute "channels" is missing.' comes from because it can't detect correctly if it's a channel or a device.

pmatic/pmatic/api.py

Lines 830 to 835 in adc8fa7

if "parent" not in spec:
devices[spec["address"]] = spec
else:
device = devices[spec["parent"]]
channels = device.setdefault("channels", [])
channels.append(spec)

@marianokamp
Copy link
Author

@jschmer @khillman both of your tips helped. By applying the virtual devices interfaces logic and replacing the hardcoded BidCos-RF I was able to get much further.

But now it looks like this is just the tip of the iceberg and I would also need to teach pmatic the specifics of HmIP devices as well. I got this impression after I followed the thermostat 'HM-CC-RT-DN' in entities.py. This looks very explicit and like a lot of work.

I'll have another look around. Mostly I want to get the data off of the CCU and to continuously publish it to the cloud to do some analytics there and hopefully some ML. I thought something Python based could be easily changed to export the data continuously, but I now feel that I would need to invest a lot until I can get to where I really want to go.

Thanks for your help and of course especially to Lars.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants