I just started developing and integration for a Norwegian alarm company, Homely. They have a pretty straightforward rest API as well as a websocket for streaming events. I’m having some trouble getting the web socket to authenticate properly, so for now I’m focusing on the rest interface. I have built a very simple client wrapper: GitHub - kolaf/homelypy: A thin wrapper for the Homely alarm company API Which I will use for the integration.
I have managed to set up a configuration flow to deal with authenticating the user with the service and selecting the correct home for retrieving the data inside the service. I have also managed to create a very simple binary sensor platform to deal with the door sensors provided by the alarm system. However, this is where things start falling apart for me.
There is a single endpoint that provides information about all the devices and the state of their various entities. For instance, a door sensor has an alarm entity that deals with whether it is open or closed, a temperature entity, and a battery state.
I have created a data coordinator together with a window sensor entity based on the binary sensor entity, and I have successfully used this to create a device together with the binary sensor entity for the door open state. However, I am not sure how to generalise this. As mentioned above the single device supports several entities, but for now both the coordinator and the device information is defined inside the binary sensor platform. How do I best generalise this so that I can create the various types of entities (binary sensor, temperature sensor, battery state) that are tied to this single device? Do I have to implement different platform files for each of the entity types and be sure to define the same device info for each entity? I assume I can reuse my data coordinator for all the devices by simply moving it to a separate file instead of keeping it inside the binary sensor file, correct?
I realise that this is a lot to explain in a forum post, so is there perhaps some developer documentation that deals with this I had missed? I could also create a pull request for my changes if that makes discussing this easier, but since the code is nowhere near ready for official review I didn’t want to put it into the official system.
Hi,
Not sure where to contact you, but just tried your integration and am having issues with it.
I has an issue initially as i had created a standard user, and not an admin user. Once i did that i was able to access the rest of the setup. (And dump using the python tool.)
I am now getting :
Logger: homeassistant.config_entries
Source: custom_components/homely/coordinator.py:51
Integration: Homely
First occurred: 12:54:44 PM (1 occurrences)
Last logged: 12:54:44 PM
Error setting up entry Homely Tiurveien for homely
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/config_entries.py", line 382, in async_setup
result = await component.async_setup_entry(hass, self)
File "/config/custom_components/homely/__init__.py", line 22, in async_setup_entry
await homely_home.setup()
File "/config/custom_components/homely/coordinator.py", line 46, in setup
await self.update_devices()
File "/config/custom_components/homely/coordinator.py", line 51, in update_devices
self.devices[device.id] = HomelyDevice(device.id)
AttributeError: 'NoneType' object has no attribute 'id'
Hi, thanks for trying it out. I am still waiting for the initial pull request to be accepted, so it is great that you have taken time to test it. From the error message it looks like the API is returning an empty device for some reason. Could you perhaps send me the json dump? You can reach me at [email protected].
Perfect. If you want to check it out you can download version 0.0.2 from this location: Homely - Google Drive
It should be as simple as creating a folder “custom_components” inside your HA configuration folder, create a folder “homely” beneath this and unpacking the files into the homely folder. After restarting HA you should be able to add the integration through the integration page.
It supports basic states and binary sensors for the devices I know about. If your device is missing I need a dump to know the model names. The log should indicate if it discovers an unrecognised model type. I have also added a basic alarm control panel entity. This is very restricted since we do not have write access to the API, but at least it should show the arming state of the alarm system. The system still relies on polling every five minutes, so do not expect to see every door and window opening and it can take up to 5 minutes before an alarm state is updated.
I have heard from a guy who tried to develop and integration for openhab who also had problems getting the websocket to cooperate, so this is may be a bigger problem than just my incompetence. Hopefully we can get this resolved soon, if you have any input please shout.
I’m still waiting for my initial pull request with the sensor entities to go through, it is taking a while longer than expected since the response from their site has been very slow. In the meantime we can play around with this. If you have any experience with the homeassistant alarm entitis I would be glad to learn since this version with non-functioning buttons will probably not be accepted.
I have now uploaded version 0.1.0 to [Google Drive](http:// Homely - Google Drive). It is updated to use my newly pushed homelypy 0.1.0 where I have finally gotten the websocket to work. This is thanks to very useful help from this implementation: GitHub - hansrune/homely-tools: Homely alarm tools. The trick is to use socketio instead of the python websocket-client library.
The latest version of integration should support streaming updates of entities, so that door sensors, alarms, et cetera are updated in real time. I have not had a chance to run this for a longer period yet, so I am not sure what the stability of the connection looks like. It might well be that I will have to improve the reconnection functionality. Also, it might not be developed according to the best homeassistant practices. I hope this will be resolved as I progress through my pull requests.
