Background:
I’m trying to extend the support for Homematic devices. Communication with those devices is based on a XML-RPC server. As the initial data transfer is slow (10+s in my case) I like to permit the setting-up of new devices based on the configuration file at a point of time were the XML-RPC server has no confirmation that device exists (device will be set to unavailable). So far that works in the implementation of my custom component.
Challenge:
When the XML-RPC Server gets notified by the Homematic bridge (CCU) that new devices are discovered I like to
a) Set the device to available
b) Point the XML-RPC Server to a handler within the Homematic entity in HA. This will enable notification after state changes
I’m assuming the clean way to solve a) would by firing an event but I do not know how to do this.
For b) the event method seems not to work as I need a reference to the HA entity. Looking into the “hass” object I have not figured out a clean way how to get a list of devices.
You cannot ask Hass for devices. It only knows about representations of devices in the state machine.
Your component is responsible for keeping the Hass object around and polling xml rpc so it can push data to Hass once it finds new devices. For polling check the event helpers for the time changed helper .
@balloob: Thanks for the confirmation on the Hass object. Keeping Hass to setup new devices works fine. But what about changing the configuration on existing devices? I could keep track of already created devices myself but this seems not like the most elegant way to do it…
@bimbar: As far as I can see the current homematic thermostat component uses a polling approach to get updates from devices. Via the init call Homematic/Homegear offers an option to push event messages instead of polling for updates. From my understanding this would allow more immediate feedback on event states and less traffic. Both seems to be relevant for larger installations with many devices. Advice welcome
Afaik generally Hass calls the update() method on the devices once every scan_interval. This usually updates the values inside the object for polled devices.
You do not have to use this as the sole method of updating state, if possible you can register some sort of callback somewhere and update your state that way (bluetooth LE does that in a weaker form, for example).
I have implemented the callback handle and it looks pretty promising. I only struggle with the situation when the Homegear /Homematic Server is still busy with recognizing devices. When I wait for it (10+ seconds) everything is fine. But I like to avoid the waiting time and instead finalize the setup when a new device is published by the homematic server.
I just found what you are aiming to do, I wasn’t quite up to date on homegear.
How about using the homegear MQTT support since homeassistant seems to support that pretty well?
EDIT: I’m not sure this is terribly useful for homegear thermostat support, since it’s not very probable someone has loads of thermostats, but if the aim is too support all homematic devices, this could be pretty cool.
Unfortunately the documentation is rather slim, but it seems possible to do all communication via MQTT.
Ultimate goal is to support all devices. I’m just familiar with switches/dimmer and rollershutter but for thermostats I have a good template
Works with my CCU2 like a charm and I do asume CCU1 should also be no issue. What do you mean by: [quote=“bimbar, post:8, topic:727”]
… is any of this component?
[/quote]
I’m the dude that started with the homematic-library. I want to give some input at this point to clarify my intentions and why the event-driven Homematic support may make sense.
Notifications on every event that occurs (needed for intrusion detection with door-contacts, pressing switches, etc.)
100% offline and cloud-independent (in regard to the MQTT proposal)
Less latency since the state won’t just be updated once a minute or so
The library provides the required callback-functionality to do all that. But I didn’t find the time to look at how this could be integrated into HA. Fortunately jazzaj is working on that now.
Also, the library works very well with homegear (that’s what I use), and the CCU, as jazzay mentioned, works as well. So this won’t exclude any existing users. Even the MAX! thermostats recently added with some pullrequest should be easy to integrate.
Another plus-side would be, that, once this works, adding further Homematic device-types would be very easy, which in turn would make HA a good choice for a whole bunch of users out there.
That would be great, as homematic is very popular in europe and rather undersupported by HA.
I’ve found your pyhomematic library .
Looks nice - 2 points though: It doesn’t seem to me as if you have taken into account that python xmlrpc is not threadsafe.
And I’ve already addressed point 2 - the lack of MAX! Support.
Thanks for notifying me about the threading-issue. I don’t have much experience with threads, so if you have any suggestions on how I should address that instead, they are very welcome.
As for the MAX! support: ideally, platforms would stay more or less similar to how they are currently. And if MAX! works now, I guess it would work with the library. In my opinion, that’s part of the platform, not the library.
See my PR. MAX! uses different channels, for example.
The solution for the threading issue is, don’t call it twice at the same time, or alternatively, use a new ServerProxy for each request, if you want to be on the safe side.
Yes, I was aware of that. But that was an easy fix, as I thought.
Regarding the Thread-safeness: Since this is not directly related to HA, I’ve created an Issue at pyhomematic. I’d like to hear your thoughts on my current idea on how to solve the issue.
