I am trying out coding an app for Homey, and I have an operational device. Now when I have the device running in a given zone, I want to go through the other devices in the same zone.
I have been able to fetch a list of all devices from the api (homey-api module) using api.devices.getDevices(). But I found no data on the device class about the active zone (such as this.zone). So I thought I would need to fetch the device-object from the API so I can read the zone id and find what devices is in the same zone. However, to fetch a device (api.devices.getDevice()), I require the ID of the active device. It is not available on this.id, there is no getId() function (similar to getName etc) and the only id I can find is this.getData().id which is not the same ID as the device id, but the one that I gave it when it was paired.
How can I get the active device/zone inside the device code?
I have done something similiar in my Zone Memory app.
What I do is, I fetch the all zones data by athom-api.zones.getZones()
And then I match the ID’s up with the devices. I think the device object should have a zone ID on it.
This is how I find the devices belonging to a zone. So on the device object from the api is .zone and this matches the zone’s id from what you get from getZones.
For the device id itself I somewhere matched them up from getData. The information is available on the webapi too I think to remember.
So you do this inside the driver class (in driver-folder/driver.js)? Do you have to fetch all devices then, to be able to match something from getData to the data-objects to find out what device object the device you are currently representing in the class?
Seems a bit strange to me that the actual id of the device (as well as the zone id) is not available from the device class…
hmm maybe Zone Memory was not the best example as I have no devices there. But I also use the zones in my LIFX LAN app. There I get all devices and match up my devices by the actual device ID I store in the data object. But am not calling it from the driver. It is an action flowcard which gets the zone as input parameter and then I match up all my apps devices with that Zone info by getDevices from the webApi. This way I enable zone based actions for the lights instead using the devices directly.
So the answer to your question is “yes” I get all devices to find the ones I am looking for. Not sure if the filter object can be used in combination with the data object. Never tried that.
Do you know why? It seems a bit strange to be in a class representing the inner logic of a device, and you are not allowed to know what device you are in so that you can do things like fetch the zone or other devices from the same zone. Except that you can do it a more impractical way by fetching all devices and figuring out which one you are in…
Is the device class the wrong place to develop logic for how the device should operate? Do I need to put it all in (or initiated from) the app-class? I feel that if the feature was removed, it might be due to trying to lead devs to put logic somewhere else. I want to build the logic in line with what is intended.
I can’t remember the exact reason why they removed it, but it was discussed way back then. I seem to remember that the reason was to prevent developers from accessing Homey-core internals that may be subject to change. The id is still there I think, just hidden behind a Symbol().
Specifically regarding zones, I think it makes sense to keep the device instance oblivious about the zone it’s in. However, you would expect a ManagerZones be present in the SDK, but instead, it’s only available in the Web API (the division of certain information between the App SDK and the Web API seems rather arbitrary at some points).
In short: developers can’t be trusted, and API design isn’t Athom’s strong suit.
I agree in many types of devices. My experience is that it tends to be need for A LOT of flows and cards to get things to work the way you want, often including a lot of similar patterns that there should be possible to make reusable logic for. I feel it is a bit impractical to maintain the details of these flows, so I want to see if Homey Apps could be a way to standardize some of these repeated patterns. That makes a bit of a different device than lights, heaters and sensors, but it seems there is no other more logical place to create something like that. And this kind of device needs to be aware of its surroundings (especially other devices in the same zone) to be of practical use.
Fully agree, I was tinkering with a thermostat driver to get it to switch all heaters in the same room. Now I need to loop over all devices and check all temperatures instead of searching directly the heaters in the zone.
Devices should really be aware of their identity. At the moment the only option I found is creating a custom setting in the device that AGAIN holds the name of the zone!
