You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.:
Remote turns on light
Light receives signal from remote, turns on device
Homey receives signal from remote, turns on device
Homey sees that device is turned on, sends signal to turn on
Light receives signal to turn on again, when it's already on, potentially triggering a "choose dim level mode", or similar
Luckily, a Device implemented using the App SDK doesn't have this problem of recursing back to its capability listener when calling setCapabilityValue:
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! 🤞🏻
The text was updated successfully, but these errors were encountered:
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.
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! 🤞🏻The text was updated successfully, but these errors were encountered: