Indigo Domotics

With Insteon that can be a concern. With Z-Wave, however, it's really not. It's much higher-speed than Insteon and handles collisions a whole lot better.

Ah. Good to know. Thanks.

Is the max ramp time still 8 min ?
Is there a way to increase that to say 30 min or 60 min?

I have my bedroom lights ramp up over 30 min to simulate sunrise in the winter but it's a lot of hard coded scheduled events. A 30 min ramp rate would be better.

Thanks

Philip

Hi Philip.

The ramp times are defined by SmartLabs and are hard coded into each INSTEON dimmer module. Dimmer Extender simply tells the dimmer to change brightness and which of it's built in rates to use when changing. There's no way to customize the dimming times.

This does not work on all i2CS devices... I think maybe only on the earliest of them. Im not sure when but Insteon changed the command for Brightness/Ramp somewhere around i2CS version 41 (internal version 65) from command byte 0x2E to 0x34. I don't think it is documented as far as I have seen but I saw some chatter online about it. Im using the following modification that seems to work on the 100+ devices I have. More devices need to be tested to complete the elif possibilities (Im not sure how versions 66-68 work - I didn't have any).

Code: Select all

         theCommand = 0
         if theRampRate:
            if self.theIndigoDevice.version >= 69:
               #later model  i2cs engine uses command 0x34
               theCommand = 0x34
            elif self.theIndigoDevice.version <= 65:
               # i2 engine uses command 0x2E
               theCommand = 0x2E
            else:
               mmLib_Log.logWarning("### Unknown insteon version " + + " for device " + self.deviceName + " while attempting BrightenWithRamp. Defaulting to standard Brighten ")

         if theCommand:
            self.sendRawInsteonCommandLow([theCommand,self.makeRampCmdModifier(theValue, theRampRate)], 0, 0)
         else:
            # use traditional set command
            indigo.dimmer.setBrightness(self.devIndigoID, value=theValue)

Thanks and I love your plugin!

Oh and the other thing I did was to send a request for status when the ramp timing should be complete, that way the indigo UI doesn't show the "New" value until it is actually completed brightening - it was a personal preference.

Sorry for the fowled up indentation above - I don't know how to post formatted text as it turns out.

dduff617 wrote:

indigo/insteon allows one to create a group and then send on/off commands to that group (but not dim).

i realize the dimmer extender works by sending "direct" commands to indigo devices, but i'm curious if there might be any way to extend the dimmer extender so that the start/stop brighten/dim and the dim/bright by 1 step commands could be sent to a group (aka "scene", aka a PowerLink link).

I was interested in getting the extended dim commands to work for Insteon scenes, so I am reviving this >3yr old topic....

I did a bit of digging, it appears that Indigo docs refer to the commands sent to groups of devices as "All Link" commands. They are documented on p. 152 of Insteon Developer's Guide, 2nd http://cache.insteon.com/pdf/INSTEON_De ... 70816a.pdf

I infer that Indigo must already be able to send these "SA" commands and that they underly the IOM indigo.insteon.sendSceneOn/Off, and sendSceneFastOn/Off commands.

AFAIK, there are no corresponding commands in IOM for the "Start Manual Change", "Brighten by One Step", "Dim by One Step", or "Stop Manual Change". It would seem rather straightforward to add these, since they are documented and would be invoked essentially identically to the way the existing sendScene* commands are.

I can't use indigo.insteon.sendRaw for these, since AFAIK, that method only supports direct messages. All Link commands require sending the group # as the to address rather than a 24-bit Insteon address that direct messages take. The also set the All Link bit in message flags. So a different varant of sendRaw would be needed.

I'll put in a feature request for these, though I gather that there is generally little enthusiasm these days for adding Insteon-specific features to Indigo.

Although adding actions with UI for those scene ("All Link") commands probably won't happen, I will add our request list to add some python APIs for sending them. You can then at least experiment around with them.

I know you already know, but for others: Indigo 7.3 (and 7.3.1) are now available and have several new options in the INSTEON Execute Scene action UI including Scene Increase by 3%, Scene Decrease by 3%, Scene Start Increase, Scene Start Decrease, and Scene Stop Increase/Decrease.

Love the plugin.

A big frustration of mine right now is the low reliability of Insteon commands for turning on keypad LED's and would love it if there were extra parameters to specify a number of times to retry if a command doesn't succeed.

Any chance to add additional Insteon actions to the plugin? Perhaps starting with functions to turn LED's on/off?

Hi.

I'm glad the plugin has been helpful for you. Thanks for the suggestion.

I googled for information on changing KeypadLinc LEDs and found developer documentation on the INSTEON commands required. As Jay and Matt have noted in other forum threads, changing LED status on the KeypadLincs seems to be a pretty inefficient process. You have to send an extended direct command which consists of 2 command bytes and 14 data bytes, where each of the 8 bits in data byte 3 represents the on-state of each of the 8 LEDs in a KeypadLinc. Bytes 4 through 14 are all zeros. The extended command must then end with a valid checksum byte. To complicate things a bit more, since all KeypadLinc dimmers/relays have 8 LEDs (event the 6-button models), the application (or plugin in this case) has to know whether the KeypadLinc to which the message is being sent is in 6-button or 8-button mode.

So while it's technically possible to add the ability to send LED change messages and add a high retry thresholds option, I don't think I'll have time to add that functionality myself. Sorry I couldn't help more.

Note that the Insteon protocol already has retries built-in. Adding more retries would most likely just cause more failures because Insteon is terrible at collision detection. I'd recommend that for any regular failures that you experience that you add some delays between what's triggering your logic to try to change button state and the actual command to change the button state using the delay on the button change action. Also recall that button changes are generally more reliable when called as part of an Insteon scene - so rather than using the built-in button change actions, instead call an Insteon scene that sets the button state. Those, by the nature of how they work under the hood, will likely be a bit faster and slightly more reliably.