-
Notifications
You must be signed in to change notification settings - Fork 506
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
Tint remote control by Müller Light; Refactor setting light state #2849
Conversation
Skip the _On_ command in between _Move to Level (with On/Off)_ and _Move to Level_, see #2824.
Don't remove `/groups/0`.
Add Tint remote control by Müller Light, see #1209.
Add Tint remote control by Müller Light
Add `previousCt`.
- Handle `state.xy` (for Tint remote control by Müller Light); - Don't attach `/groups/0` to sensors.
Add Tint remote control by Müller Light, see #1209.
de_web_plugin.cpp
Outdated
{ | ||
sensorNode.addItem(DataTypeUInt16, RStateX); | ||
sensorNode.addItem(DataTypeUInt16, RStateY); | ||
sensorNode.addItem(DataTypeUInt16, RStateTiltAngle); |
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.
Shouldn't this be RStateAngle
instead of RStateTiltAngle
? From my testing so far it shows "tiltangle":null
in the REST API instead of the angle.
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.
Indeed, thanks for noticing!
It's correct in database.cpp
. If you restart deCONZ, you should see state.angle
instead.
Hello @ebaauw, when will this branch be part of an official build? Regards |
Use values by latest Hue bridge gen-2 firmware, to re-enable Hue app, see #2837.
- Add a global variable for the `DeRestPluginPrivate` instance, to enable calling `enqeueuEvent()` (amongs others) from `LightNode` (amongst others) methods.
- Add manufacturer-specific attribute for Müller Light special scene; - Add more _Color Control_ attributes.
- Add methods to update `ResourceItem` value, including issuing event, updating `etag`, and saving to database.
- Remove `state.alert` for _Window Covering Device_; - Make `state.effect` a true `ResourceItem`; - Add `setValue` methods to set `ResourceItem` value, issue `Event`, update `etag`, and save database.
- Use true `ResourceItem` for `state.effect`; - Add `Resource::toVariant()`.
- Use true `ResourceItem` for `state.effect`; - Add `Resource::toVariant()`.
Refactor handling PUT of `/lights` `state`, see #1209.
Add bindings for Mueller Light.
- Fix name `RAttrLastAnnounced`; - Fix format of UTC date/time attributes: - `null` when invalid; - End with `Z` when in UTC; - Return `RStateEffect` as string.
- Add optional `forceUpdate` parameter to `LightNode::setValue()`; - Remove `LightNode::setColorXY()`, `LightNode::colorMode()`, and `LightNode::setColorMode()` in favour of `LightNode::setValue()` and `Resource::toString()`.
- Websocket notifications for `lastseen` and `lastannounced`; - Restore `lastseen` and `lastannounced` from database; - Add optional `forceUpdate` parameter to `LightNode::setValue()`; - Remove `LightNode::setColorXY()`, `LightNode::colorMode()`, and `LightNode::setColorMode()` in favour of `LightNode::setValue()` and `Resource::toString()`.
- Leverage `LightNode::setValue()`; - Collect attributes in one web socket notification.
Leverage `LightNode::setValue()`.
Leverage `LightNode::setValue()`
Leverage `LightNode::setValue()`.
@manup, could you please have a look at this PR? Running it on my production for a day and haven't encountered any issues, but it's turned into a bigger one. |
- Limit #events for `lastseen` (of same resource) to 1/sec; - Keep `lastseen` and `lastannounced` in sec resolution.
- Keep `lastseen` and `lastannounced` in sec resolution.
Support rule condition for `dx` `attr/lastannounced`, see #2590
Hello @ebaauw , I have a problem after rebooting, because the Tint remote is forgotten. Pressing some buttons on the tint does not result in a reachable = true. Regards |
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.
Just added some minor comments, the PR runs in my setup fine.
I'm doing some more tests with color loop now.
@@ -2881,7 +2895,7 @@ void DeRestPluginPrivate::checkOldSensorGroups(Sensor *sensor) | |||
i->removeDeviceMembership(sensor->id()); | |||
} | |||
|
|||
if (i->state() == Group::StateNormal && !i->hasDeviceMembers()) | |||
if (i->address() != 0 && i->state() == Group::StateNormal && !i->hasDeviceMembers()) |
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->address() != 0
may we should use some constants here to get more meaning and make it easier to search for places where group 0x0000 is used.
GROUP_0
/ GROUP_ZERO
or something similar.
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.
There's several things going wrong with /groups/0
. Events are issued on /groups/65520
instead of on /groups/0
. A GET of /groups/65520
returns the same as a GET of /groups/0
. The entire code handling this should be reviewed. I think we might need to decouple the REST resource ID from the group address for all groups, similar to the Hue bridge.
@@ -343,6 +345,8 @@ QString ApiRequest::apikey() const | |||
DeRestPluginPrivate::DeRestPluginPrivate(QObject *parent) : | |||
QObject(parent) | |||
{ | |||
plugin = this; |
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.
In v2 we should inject this as dependency in the constructor instead a global variable. Makes writing tests easier.
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.
Yeah, using a global variable definitely doesn't deserve a beauty prize. I tried to add a variable to the constructors at first, but couldn't get that to work. Got lost in wanting to put that into RestNodeBase
but needing to pass it to the LightNode
and SensorNode
classes. I'm afraid my C++ is a bit rusty here, and Qt doesn't help.
} | ||
} | ||
} | ||
else if (param == "xy" && taskRef.lightNode->item(RStateX) && taskRef.lightNode->item(RStateY) && | ||
taskRef.lightNode->modelId() != QLatin1String("FLS-PP")) | ||
{ | ||
// @manup: is check for FLS-PP needed, or is this already handled by check for state.xy? | ||
// @manup: is check for FLS-PP needed, or is this already handled by check for state.x and state.y? |
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.
Hmm good question: The check refers to the very old "FLS-PP" wireless ballast from 2012 which didn't support xy color mode there are less than 200 deployed but still active. When they are configured we'd need to strip the xy ResourceItems (the ballast wrongly claims it supports this color mode).
The newer ones with model id "FLS-PP3" support xy and don't fall into this check.
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.
You make devices of too high quality, now you never get rid of old stuff ;-)
Another argument for capabilities...
state[key] = item->toVariant(); | ||
if (rid.suffix == RStateEffect) | ||
{ | ||
state[key] = RStateEffectValuesMueller[item->toNumber()]; |
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.
Is a guard here for Müller Licht needed?
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.
No, but better naming is. Should probably have used RStateEffectAllValues
vs RStateEffectDefaultValues
. No clue how to expand this to other lights with similar capabilities, but implemented differently.
What are you rebooting? How do you start deCONZ after reboot? Are you sure it starts with your self-compiled REST API plugin? What do you mean by “ forgotten”? Does it still show in the GUI? Does the
Resetting the remote would only be needed if it has lost the association to the Zigbee network. That cannot be caused by restarting deCONZ.
Is that before or after reboot? Before or after reset and re-pair? Does |
I am rebooting my "host" - a Raspberry Pi 3 B.
I am using deconz headless so I can't
Hm okay - strange behavier within my network.
Usually I do the following:
With |
For Phoscon: it doesn't (yet ?) support the remote.
That's unfortunate. I wouldn't know how to troubleshoot without access to the GUI.
This actually suggest that the resource no longer exists. Is it included if you do a GET of
Very strange. How long after pairing the remote do you stop deCONZ? It would seem that the newly paired sensor resource hasn't been written to the database. Do you see the same for other devices? I don't see how this could be related to this PR; best open an separate issue for it. |
Thank you for clearification.
It is not included. Thank you for that hint. Thanks a lot! |
state.effect
, see [Request Device Support] Tint remote control by Müller-Licht #1209.ct
totrue
, or settingct
to an integer value < 0 or > 0xFFFF). Coerce the value if of the correct type, but invalid;ctmax
>ctmin
. Change defaultctmax
to 65279 (0xFEFF).state.alert
for Window Covering Device./lights
resourcelastannounced
andlastseen
, see Proposal: deprecatereachable
attributes #2590:Z
);dx
condition onlastannounced
(e.g. to turn off a light on power on, in case it doesn't support PowerOn On/Off).ResourceItem
values for/lights
resources./lights
resource top-level attributes. Not all events are generated yet, though.