Open marianokamp opened 6 years ago
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 :
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.
You could take a look at jschmer/pmatic@514634790ee65e98596fb72a204814fc0188548e 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.
https://github.com/LarsMichelsen/pmatic/blob/adc8fa7e52537c26127d6b1136eb575ebabe3c85/pmatic/api.py#L830-L835
@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.
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.
https://github.com/LarsMichelsen/pmatic/blob/adc8fa7e52537c26127d6b1136eb575ebabe3c85/pmatic/api.py#L828
When you query for the interfaces you get this:
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.
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.