-
Notifications
You must be signed in to change notification settings - Fork 508
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Gateway cascade enhancements (and some more) #338
Conversation
Simple _Move to level_ for setting `action.bri` and _Step_ and _Stop_ as issued by Hue dimmer switch.
Send set remote group `action.on` to true (false) when local group `state.all_on` is false (true).
Only create ZHASwitch resources for _Analog Input_ (0x000c) and _Multistate Input_ (0x0012) clusters for the Xiaomi Smart Cube. See ebaauw/homebridge-hue#245 and ebaauw/homebridge-hue#203.
Expose ubisys dimmer inputs as two buttons (left and right), with SHORT_RELEASE, HOLD, and LONG_RELEASE, rather than separate buttons for On/Off, DimUp, and DimDown for both left and right.
In line with dresden-elektronik/deconz-rest-plugin#338 s/7d5a2c371adaecd649ec152d523747d5eb7d447b.
@@ -2694,13 +2694,17 @@ void DeRestPluginPrivate::addSensorNode(const deCONZ::Node *node) | |||
|
|||
case ANALOG_INPUT_CLUSTER_ID: | |||
{ | |||
fpSwitch.inClusters.push_back(ci->id()); | |||
if (modelId == QLatin1String("lumi.sensor_cube")) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We may need to extend this whitelist in future, I'm not sure but I think there were other sensors using the analog/multi-state clusters too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I double-checked that I introduced these clusters when adding support for the Smart Cube. Also, the handling of the attribute values is specific to the cube.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alternatively we could to blacklist the “funny” sensors (so far I’ve seen reports of lumi.sensor_ht and lumi.switch_86sw2 showing additional endpoints with these clusters).
Thanks a lot, I'll merge the PR now but can't test it currently (back in end of January). Maybe in future the support for proper external web hooks in rules replaces the cascades with a simpler general way to forward REST API requests to an arbitrary destination. See also #347 Luckily the implementation will be fairly simple due QNetworkManager. :) |
Maybe, maybe not. There’s something to say for webhooks, especially if they can be attached to rule actions. You’d be able to interact with any REST api, not just the deCONZ/Hue API. With cascade, you actually forward ZigBee commands as deCONZ/Hue REST API calls. I’m amazed how fast this works, when the commands are sent by ZigBee switches or sensors, compared to commands sent by the gateway (looks like the gateway only cascades these when it reads back the groupcasts). The translation of ZigBee commands to REST API calls is somewhat crude. I’d love someday to design a more consistent and complete API, with different endpoints for (write-only) commands, |
Agree, they both have their use cases. Setup for cascades is also easier since it's just a group a forward to group b mapping. |
Several enhancements for gateway cascade functionality, see #287:
action.on
andaction.bri
, with or withoutaction.transitiontime
from the REST API;Notes:
action.on
is set to true (false) when local groupstate.all_on
is false (true);bri_inc
(see state.bri_inc not yet implemented? #84).Todo:
action.ct
andaction.xy
from the REST API.Other changes: