Output MOTOR #100
Output MOTOR #100
Conversation
fixed is_dimmable create Motor(output)
| @@ -803,6 +815,34 @@ def stop(self): | |||
| self._lutron.send(Lutron.OP_EXECUTE, Output._CMD_TYPE, self._integration_id, | |||
| Output._ACTION_STOP) | |||
|
|
|||
| class Motor(Output): | |||
There was a problem hiding this comment.
This won't support simple raise/lower.
My suggestion is to make this inherit from Shade, and move the enums out of Output into this class
There was a problem hiding this comment.
I cannot understand why this won't support raise/lower. Can you elaborate on this?
Regarding inherriting from Shade. I think this is wrong, as this is a Motor entity, which is different from a Lutron Shade, even though we will use the motor as a shade In HA.
|
Ok... you've duplicated an implementation. So now we have both the shade
and motor, implementing the same functionality, with different method names.
Functionally speaking, a motor is a shade with additional controls.
I'd like to remove the duplication of methods/implementation here. Not all
outputs support start/stop raise/lower which is why they were implemented
in the shade class.
…On Mon, May 27, 2024 at 6:41 AM Riccardo Zulian ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In pylutron/__init__.py
<#100 (comment)>:
> @@ -803,6 +815,34 @@ def stop(self):
self._lutron.send(Lutron.OP_EXECUTE, Output._CMD_TYPE, self._integration_id,
Output._ACTION_STOP)
+class Motor(Output):
I cannot understand why this won't support raise/lower. Can you elaborate
on this?
Regarding inherriting from Shade. I think this is wrong, as this is a
Motor entity, which is different from a Lutron Shade, even though we will
use the motor as a shade In HA.
—
Reply to this email directly, view it on GitHub
<#100 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACQARWVPWKTDUQV6IC3XCCLZEMZ2HAVCNFSM6AAAAABHYIWVSCVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDAOBQHE2TKMJTGE>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
QS Sivoia shades have additional controls (eg. tilt and lift) that are not currently implemented and that are not possible with a motor, at the same time motor is implementing jog raise, which is not in the shades. Do you want to differentiate the different types in HA? |
|
Ok... then there are 2 possible paths I could see taking:
1) We start overhauling the class structure here such that Output
implements all functionality for any output type, but cann't be used
directly. Classes that inherit from this end up having to specify which
parts of output functionality are supported.
2) Some interesting inheritance where Shades => Motor, but also Shades =>
QS shades
…On Thu, May 30, 2024 at 7:24 AM Riccardo Zulian ***@***.***> wrote:
Ok... you've duplicated an implementation. So now we have both the shade
and motor, implementing the same functionality, with different method
names. Functionally speaking, a motor is a shade with additional controls.
I'd like to remove the duplication of methods/implementation here. Not all
outputs support start/stop raise/lower which is why they were implemented
in the shade class.
QS Sivoia shades have additional controls (eg. tilt and lift) that are not
currently implemented and that are not possible with a motor, at the same
time motor is implementing jog raise, which is not in the shades.
—
Reply to this email directly, view it on GitHub
<#100 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACQARWWE4WHSP5VVWNNKKETZE4ZBZAVCNFSM6AAAAABHYIWVSCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZZGY4DANJSGA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
support outtup_type MOTOR
add output states