Indigo Domotics

I would like to set the default level of a light that is linked to a sensor to be lower late at night. I figured I could create a scheduled event that would change the default level to 20% at 10 PM and at 100% at 7 AM. Is there a way to do this via Python?

Setting the default brightness of a module is hardware specific. What kind of dimmer modules is it (protocol and model)?

It is a SwitchLinc Dimmer with firmware 38 (i2 engine).

It should be possible to send the raw INSTEON commands to do this, but I don't recall what the byte sequence is for that command off the top of my head (and it varies based on module firmware version). I can try to put together some information, but first let me propose the low tech solution, which is the one I would use because it will work regardless of firmware version:

1) Set the default brightness to 20% for the module.
2) Create a Trigger in Indigo that upon INSTEON ON command received for that module does an Action to Set Brightness to 100%, and add a Conditional of "after 7 AM".

The only downside is there will be a slight delay as Indigo has to execute the additional command.

I tried that, and it takes almost 10 seconds before the trigger move the brightness up to 100%. That is why I like the linking. However, I understand how changing linking defaults could be problematic. Is that length of delay in a trigger common?

10 seconds is a really long time. Copy/paste what you see in the Event Log when you turn on the switch. It should take a fraction of that amount of time.

I would like to revisit this. I have a motion insteon sensor that links to a closet switch. During the day, I would like it to be at 100% brightness, and late at night I would like it to be at 30% brightness.

I have tried implementing what Matt calls "the low tech way", that is, having the default value be 30% and ramp it up to 100% during the day via a conditional trigger. The lag, though not long, is a little irritating. I have lived with it for a while, but I think I would like to go back to my original idea of setting the default brightness level.

Is there some plugin or extender that we can use to set the default level? What would the raw command sequence be to change a default brightness on an insteon switch? Is there a table where I can look that up based on my switchlink firmware and model number? How would I implement that using some kind of a python script that runs on a schedule or a trigger.

I can’t remember if I’ve mentioned this wishlist request of mine but I’ll stick it in here anyway as it’s relevant:

A user definable field in every dimmers device settings that can be populated with a 1-100% value and can be changed via action groups, and an option in action groups for “set to default brightness” Now I know this can be done with scripts and variables.. but honestly it’s a PITA and variables is such a quagmire.. I’ve got so many with similar names and scripts using ID numbers keeping a track of them is just frustrating.

You know me.. I like simplicity


Sent from my iPhone using Tapatalk

durosity wrote:

A user definable field in every dimmers device settings that can be populated with a 1-100% value and can be changed via action groups, and an option in action groups for “set to default brightness”

I assume you actually mean "device actions" where you're writing "action group", because there's lots of ways to invoke actions that don't involve an Action Group. Like Triggers, Schedules, and directly from a script.

If you're going that far, add in corresponding actions for a "default fade time".

durosity wrote:

I can’t remember if I’ve mentioned this wishlist request of mine but I’ll stick it in here anyway as it’s relevant:

A user definable field in every dimmers device settings that can be populated with a 1-100% value and can be changed via action groups, and an option in action groups for “set to default brightness” Now I know this can be done with scripts and variables.. but honestly it’s a PITA and variables is such a quagmire.. I’ve got so many with similar names and scripts using ID numbers keeping a track of them is just frustrating.

You know me.. I like simplicity

While this isn't exactly what this particular user is looking for, it is one alternative to what he's looking for.

I should note that an intrepid 3rd party developer could implement this if they wanted - using the Global Property Manager (or similar approach) you could add a default level property to any dimmer device. Then they could write a simple action that looks at that property and sets the brightness accordingly.

FlyingDiver wrote:

durosity wrote:

A user definable field in every dimmers device settings that can be populated with a 1-100% value and can be changed via action groups, and an option in action groups for “set to default brightness”

I assume you actually mean "device actions" where you're writing "action group", because there's lots of ways to invoke actions that don't involve an Action Group. Like Triggers, Schedules, and directly from a script.

If you're going that far, add in corresponding actions for a "default fade time".

Fade time?

jay (support) wrote:

Fade time?

How long it takes to ramp up/down the brightness. Maybe that’s mostly a Lutron concept.

Not to be too much of a dotard, how would I find what the raw insteon command would be to send a default brightness setting?

FlyingDiver wrote:

How long it takes to ramp up/down the brightness. Maybe that’s mostly a Lutron concept.

I thought that's what you meant. That's actually a huge challenge for several reasons: some devices don't support ramp rates at all (mostly X10, but a few really old Z-Wave). Other devices support ramp rates but they aren't adjustable (many older Z-Wave devices as well as the cheaper ones). Still others support ramp rates that are adjustable, but only as configuration parameters (Insteon devices when using direct control commands and newer Z-Wave switches). Finally, some allow ramp to be specified with the command to turn on/off (Insteon devices when used within an Insteon group, newer devices of other technologies with well thought-out APIs).

Given this wide range of potential ramping capability, it would be really difficult to implement a universal ramp behavior (because you'd really have to build ramp for devices that don't support it).