Converting "dim to"

Hello ! I have been converting successfully many AS to Python today, but this one resists !

I was setting up the dim value of this Qubino module to a values stored in a variable with AS like this:
# dim device "Qubino fil pilote zone nuit" to (value of variable "ValeurZone2") as integer

My Python code:
FPZoneNuit = indigo.devices[460418665] # Qubino fil pilote zone nuit
Zone2 = int(indigo.variables[1755266407].value) # "ValeurZone2"

FPZoneNuit.brighten = 85
indigo.dimmer.brighten(460418665, value=74)

I have tried all variation of brighten, set brightness, set brightnesslevel on both lines but nothing works.. what is the secret command ?

Try:

Code: Select all

indigo.dimmer.setBrightness(460418665, value=75)


https://wiki.indigodomo.com/doku.php?id=indigo_2023.1_documentation:device_class#set_brightness

Thank you ! I missed the capital B on setBrightness I think... I ma not yet used to these rules of capitalisation in Python, but it's coming

Understandable. In this instance it's not so much a rule of capitalization, but rather simply what Matt and Jay decided to call the command.

More specifically there are no capitalization rules in Python, but the language is case sensitive. Camel-case used to be the norm in Python but it’s out of favor now.


Sent from my iPhone using Tapatalk

[jay (support)]

More specifically there are no capitalization rules in Python, but the language is case sensitive. Camel-case used to be the norm in Python but it’s out of favor now.

To be perfectly honest, this one is on us (and perhaps more specifically me). We both came from programming language backgrounds that used camelCase extensively. And we were somewhat Python neophytes. I didn't spend enough time extensively researching Python style guides, best practices, etc., as I probably should have when we started designing the API, and we made a conscious decision to go with what we were most comfortable with (using the justification that some of the built-in Python stuff used it).

If we had to do it again, we would certainly have used snake_case instead. In the plugin API we've added snake_case versions of many (most?) Plugin object method names but we have yet to move the general API in that direction.