Open torarnv opened 1 year ago
One possible implementation would be the following two commits:
homey-core
homey-apps-sdk-v3
The functionality builds on the existing machinery inside home-core
for updating capability values, which takes care of updating the UI, running flows, etc. – i.e. all the things you want to happen in reaction to a device changing its state in the eyes of Homey. Except, importantly, when hitting the app device's _onUpdateCapabilityValue
in the homey-apps-sdk-v3
, the app only updates its local state, and doesn't trigger capability listeners like _onSetCapabilityValue
would have.
The latter would have resulted in the app trying to set the state of the external device to match the new capability value, but the whole reason we've updated the capability value is because we know it has already changed externally. And letting the app change the state of the external device (again) would be treated by the device as "go into dim level setting".
In my case I use this new API to update the Homey state when I detect that a secondary controller button has changed the state of the external device directly, and then reflect that in Homey:
With the HomeyScript just posting to the Web API's '/device/:deviceId/capability/:capabilityId/update'
endpoint.
The plumbing all the way to the Homey Web API JS SDK porcelain has been left out for now.
Bump! I have the exact same issue as mentioned above, and I would really benefit from this implementation :)
the same here with many KAKU wall switches directly linked to KAKU relays for light control. It would be even easier for users (me) if KAKU end devices would support setting its on/off state without triggering it in the flows interface directly :)
Some devices do not have the ability to report their state, for example the Nexa series of "dumb" 433 sockets/dimmers. To reflect the device's state in Homey, we rely on the remote control signal, which is used both to listen for changes, as well as control the device.
A common practice in this case is that the remote control and device are directly paired, outside of Homey, so that if Homey is down, or has issues receiving 433 signal, the lights still work. This would potentially result in the device receiving duplicate state changes, e.g.:
Luckily, a
Device
implemented using the App SDK doesn't have this problem of recursing back to its capability listener when callingsetCapabilityValue
:Because it only results in updating locale state, and emitting
updateCapabilityValue
so that Homey can react to the state change. All good so far 😃Now, consider a scenario where a device is controlled by two remotes, both directly paired to the device outside of Homey. In that case, the Homey device is only set up to "mirror" one of the remote controls. The other remote control is paired to Homey as a plain remote control, without being tied to anything. To tie the remote control to the light, we need to use Flows/HomeyScript. But unlike the case above with the App SDK, the Web SDK
setCapabilityValue
function recurses back into the light device's capability listener, resulting in duplicated "turn on" signals, as in point 5 above.This is where a
updateCapabilityValue
in the Web SDK would be useful, so it can be used in HomeyScript automations. Hope this can be added! 🤞🏻