Insteonplm: Feature Request: Set ramp rate for device

[SwissKid]

For InteonPLM, when I send a command to it it updates immediately. However, in many cases I want to dim or brighten to that setting, not immediately switch.

First feature I'd like is being able to put the ramp rate in the insteonplm="" line.

Second feature would be having the ability to trigger it within a rule special. The "user story" I'm thinking of using this is:

As a person, I'd like to use my insteon light as a compliment to my alarm to wake me up in the morning. 
I'd like it to ramp up slowly over a period of at least 30 seconds, rather than immediately switch to full brightness.

This could be done by either having a second item for that same light that just had a different ramp rate, or by being able to specify the ramp rate in the rule action.

[steve-bate]

Have you tried doing this with a Dimmer item and rules?

[SwissKid]

Can i specify a specific ramp rate for the dimmer item anywhere? I don't see anywhere to specify anything except a max brightness.... I'd need to be able to do something like

Dimmer d1 "dimmer 1" {insteonplm="xx.xx.xx:F00.00.11#dimmer,ramprate=20"}

And that's not possible with current configs from what I can tell.
Currently, it's using the "on" command (though i feel as if it's using "fast on" when I set a specific level). From Insteon docs:
This command tells the device to turn its load ON to the specified On-Level at its Local Ramp Rate (Ramp
Rate only used for dimmable devices).

I'm asking to be able to use "Ramp Rate ON"

http://cache.insteon.com/developer/2672-222dev-052014-en.pdf
page 24

This would allow me to specifically slowly dim a room in some instances.

[steve-bate]

Maybe @berndpfrommer can comment, but I don't think that's currently possible directly with the binding although it would be an interesting feature (I have some of those bulbs too).

[berndpfrommer]

Should not be too hard to implement. This document is pretty good:

http://www.madreporite.com/insteon/ramprate.htm

I suggest to introduce a new feature, and map it to a switch. It really is a separate command, so tying it into the "dimmer" feature is probably not a good idea. How about this syntax:

Switch rampRateSwitch "dimmer 1 ramp" {insteonplm="xx.xx.xx:F00.00.11#ramponoff,ramptime=20,ramplevel=55"}

ramptime is in seconds, ramp level from 0-100. The binding should do the translation from time [sec] to ramp rate (and don't support 9min, just stop at 8min max, to work around the ramp rate = 0x00 hack).

This would involve making a new command handler, that translates an "ON" command from openhab to ramp rate on, and "OFF" to ramp rate off. Plus Message handlers that handle the reply messages from the device and send "ON" or "OFF" down the bus when the direct ack comes in from rr on/ rr off.

@SwissKid do you want to do it or want to wait until I get around to it? Not sure if I'll be able to do it in the next month, I will eventually though.

I actually just implemented ramp rate for the InsteonTerminal a few days ago. But there it's easier since I only have to deal with the Insteon half of it, not with OpenHab.

[steve-bate]

@berndpfrommer I've created an initial prototype of the ramponoff feature. The prototype is working, but I have a few questions. The ramptime only supports discrete, specific values. Were you thinking of a table lookup that would translate a requested ramp time to the nearest supported time?

The reply message is a direct ack. I see the MessageDispatcher converts the cmd1 value (0x34 or 0x35) to 0x19 and the comments say the cmd1 value is useless in this case. However, cmd1 seems to have the needed key for the handler lookup. From the debug logging...

2015-12-29 10:30:33 DEBUG o.o.b.i.i.d.MessageDispatcher[:134]- 2F.68.B4:RampOnOff DIRECT_ACK: q:QUERY_PENDING cmd: 80
2015-12-29 10:30:33 DEBUG o.o.b.i.i.d.MessageDispatcher[:139]- changing key to 0x19 for msg IN:Cmd:0x50|fromAddress:2F.68.B4|toAddress:39.56.52|messageFlags:0x2F=ACK_OF_DIRECT:3:3|command1:0x34|command2:0xFC|
2015-12-29 10:30:33 DEBUG o.o.b.i.i.d.MessageHandler[:302]- DefaultMsgHandler drop unimpl message 0x34: IN:Cmd:0x50|fromAddress:2F.68.B4|toAddress:39.56.52|messageFlags:0x2F=ACK_OF_DIRECT:3:3|command1:0x34|command2:0xFC|

The feature definition is...

<feature name="RampOnOff">
    <message-dispatcher>DefaultDispatcher</message-dispatcher>
    <message-handler cmd="0x34">RampOnSwitchHandler</message-handler>
    <message-handler cmd="0x35">RampOffSwitchHandler</message-handler>
    <command-handler command="OnOffType">RampOnOffCommandHandler</command-handler>
    <poll-handler>NoPollHandler</poll-handler>
</feature>

It would be nice if there was a way to control the ramp time using a rule rather than having it hard coded in the binding config. One possibility is to also support a StringItem that can represent a command string like "ON,5,80" (ramp=5 seconds, level=80).

[watou]

An alternative to a multi-valued string item could be an action bundle. An action call in a rule that triggered on an item receiving commands could be a clean solution.

[berndpfrommer]

@steve-bate , you are right that in this case the cmd1 key could be used to invoke the handler, but is overwritten by key=0x19. The majority of devices returns the (useless) database delta in cmd1, which is why the code is that way. I have yet to figure out what the database delta is good for.
Suggestion: write a message handler "RampOnOffSwitchHandler" and install it for key 0x19. Then inside the handler dig up the original cmd1 via:

byte cmd1 = msg.getByte("command1");

And take On/Off action based on that.

Yes, I was hoping for a lookup translation table that rounds to the nearest available ramp rate. Then just hope it doesn't change from device to device. But we can later move that code somewhere in the device_types.xml file if it does vary between devices.

Nothing against the idea of making a string command. Did you intend that to be in addition to the simple switch type trigger? I wouldn't know how to send a string from the GUI, and I suppose some people will want to do just that: flip a switch in the GUI and the lights come on slowly.

@watou I have never used actions, so couldn't comment on that one.

[robnielsen]

Good News, I grabbed Steve's PR branch and updated the my dimmer switch and it works! Here's how it looks now:

<device productKey="F00.00.11">
     <model>2466D</model>
     <description>To? ?ggleLinc Dimmer</description>
     <feature name="dimmer">GenericDimmer</feature>
     <feature name="manualchange">ManualChange</feature>
     <feature name="fastonoff">FastOnOff</feature>
     <feature name="ramponoff">RampOnOff</feature>
     <feature name="lastheardfrom">GenericLastTime</feature>
 </device>

Steve, can you add ramponoff for the 2466D to your PR? I'll try the KeypadLink's tomorrow, along with my LED bulb. The KeypadLink will require new features.

Rob

[robnielsen]

Hi @steve-bate, I'm unable to get my 2672-222 LED bulb to work with rampdimmer. I've tried two different devices and neither work. Here's what's in the log:

2016-01-01 16:19:54 INFO o.o.b.i.InsteonPLMActiveBinding[:125]- Item: mKitchenLampRamp got command ON
2016-01-01 16:19:54 DEBUG o.o.b.i.i.device.InsteonDevice[:168]- processing command ON features: 5
2016-01-01 16:19:54 DEBUG o.o.b.i.i.d.CommandHandler[:585]- ramp encoding: time 15.0 insert 4 d1 8.5 d2 4.0 ramp 11
2016-01-01 16:19:54 INFO o.o.b.i.i.d.CommandHandler[:233]- RampOnOffCommandHandler: sent ramp on to switch 21.F6.AF time 15.0 level 100 cmd1 52
2016-01-01 16:19:54 DEBUG o.o.b.i.i.device.InsteonDevice[:379]- qe taken off direct: RampDimmer_3435(1:2:1) OUT:Cmd:0x62|toAddress:21.F6.AF|messageFlags:0x0F=DIRECT:3:3|command1:0x34|command2:0xFB|
2016-01-01 16:19:54 DEBUG o.o.b.i.i.device.InsteonDevice[:399]- next request queue processed in 2000 msec, quiettime = 2000
2016-01-01 16:19:54 DEBUG o.o.b.i.internal.driver.Port[:382]- writing (500): OUT:Cmd:0x62|toAddress:21.F6.AF|messageFlags:0x0F=DIRECT:3:3|command1:0x34|command2:0xFB|
2016-01-01 16:19:54 DEBUG o.o.b.i.InsteonPLMActiveBinding[:581]- got msg: IN:Cmd:0x50|fromAddress:21.F6.AF|toAddress:24.11.9D|messageFlags:0x2B=ACK_OF_DIRECT:3:2|command1:0x34|command2:0xFB|
2016-01-01 16:19:54 DEBUG o.o.b.i.i.d.MessageDispatcher[:134]- 21.F6.AF:RampDimmer_3435 DIRECT_ACK: q:QUERY_PENDING cmd: 80
2016-01-01 16:19:54 DEBUG o.o.b.i.i.d.MessageDispatcher[:139]- changing key to 0x19 for msg IN:Cmd:0x50|fromAddress:21.F6.AF|toAddress:24.11.9D|messageFlags:0x2B=ACK_OF_DIRECT:3:2|command1:0x34|command2:0xFB|
2016-01-01 16:19:54 INFO o.o.b.i.i.d.MessageHandler[:414]- RampDimmerHandler: device 21.F6.AF was switched on using ramp to level 100.
2016-01-01 16:19:55 DEBUG o.o.b.i.i.device.DeviceFeature[:264]- 21.F6.AF:RampDimmer_3435 publishing: ON
2016-01-01 16:19:55 DEBUG o.o.b.i.i.d.MessageDispatcher[:159]- defdisp: 21.F6.AF:RampDimmer_3435 set status to: QUERY_ANSWERED
2016-01-01 16:19:55 DEBUG o.o.b.i.i.device.DeviceFeature[:264]- 21.F6.AF:GenericLastTime publishing: 2016-01-01T16:19:55
2016-01-01 16:19:56 DEBUG o.o.b.i.i.d.RequestQueueManager[:132]- device queue for 21.F6.AF is empty!

I checked with @berndpfrommer since he also has a 2672-222 LED bulb, and he tried using 0x2e and 0x2f instead of 0x34 and 0x35 with insteonterminal and ramp on/off worked. I then tried switching the feature for F00.00.13 to use RampDimmer instead of RampDimmer_3435 and rampdimmer worked. But when I did this, the normal on/off also used the same values as ramp dimmer when using OH to turn the device on/off. Once I use the dimmer switch to manually turn on/off the LED bulb, it starts to work normally again (without ramp). One thing I noticed is that the 2674-222 LED bulb (recessed) is configured to use RampDimmer which is different than the 2672-222 LED bulb.

[steve-bate]

That's strange. I'm using both my 2672-222 (with 0x34/0x35) and 2674-222 (with 0x2E/0x2F) and not having problems. The 0x34/0x35 is what's documented for the 2672-222 in the developer documentation (with 0x2E and 0x2F assigned to different requests). I didn't find any documentation specifically for the 2674-222, but 0x34/0x35 didn't work and 0x2E/0x2F did when I tried it.

It's interesting that the log shows the 0x34 command being acknowledged by the device. Is that normal if the command is not recognized?

I don't have any theories at this point. Do you have more than one item bound to the 2672-222 (like both a switch and a dimmer or a regular dimmer and a ramp dimmer)?

[robnielsen]

Mine and @berndpfrommer 2672-222 bulbs are about 2.5 years old. I know the age of @berndpfrommer also since i send one to him. Maybe it's an older rev of the firmware. In the bottom of the bulb, I have a sticker that says R2.5

[steve-bate]

That might be the issue. My bulb is a few months old. The sticker says R4.0. The documentation I'm using is for R3.0. Maybe something changed between R2.5 and R3.0?

[robnielsen]

It must be, I'm going to send a support request to Insteon and see what they say. It's really odd that your recessed light works with the old commands, maybe it also has older firmware?

[steve-bate]

The 2674-222 sticker says "R3.5S 3014" so the firmware does seem to be a bit older although I bought that bulb around the same time.

[robnielsen]

@steve-bate, I haven't heard back from Insteon, and I doubt I will. I wonder if we should add a feature for the 2672-222 that uses RampDimmer instead of RampDimmer_3435. @berndpfrommer what do you think? It's still odd that the 2674-222 is different from the documentation.

[berndpfrommer]

Will try to do some more experiments with the LED bulbs today, but not sure I'll get to it. If we do find the behavior to be different with firmware revision, then let's make two separate devices, maybe 2672-222 and 2672-222-R4.0+.

[berndpfrommer]

Experiments with my 2672-222 (not sure what revision, but same as Rob's) using Insteon Terminal:

1. with device off sent ramp rate on with 0x34, no reaction whatsoever.
2. with device on sent ramp rate off with 0x35, no response either.
3. using ramp rate on with command 0x2e worked, but as Rob said, it also sets the ramp up/down speeds for all future commands. So when I send a plain "off" 0x13 (no ramp), it dims down at the speed of the previously set ramp. If you accidentally set a very long ramp time (e.g. 9min) the device appears non-responsive. Can be very confusing for the user!
4. I discovered that the LED bulb actually has a command that does the instant on and off: 0x21, and also Fast On /Fast Off (0x12/0x14). They work as advertised.
5. tried it ramp rate on with my 2477D dimmer, SAME BEHAVIOR as the LED bulbs. Every subsequent On or Off command would ramp at the rate set earlier. But the first time you toggle manually, the ramp rate resets to instant. Go figure....
6. Turns out the 2477D also responds to the instant on/off commands. According to the insteon command tables document, the 0x21 command was only added in 4/20/2006, the 0x12/0x14 appear to be ancient though.

Steve and Rob, can you test how your target devices behave? Do they also remember the ramp rate? If they all behave like the two devices I tested then I would say we add the fast on/off as a separate feature to any device that has the ramprate feature and put a big fat warning on the wiki page about the differences between on/off (0x11/0x13) and 0x12/0x14, and how on/off are affected by using the rampdimmer feature. In fact the insteon command table docs say clearly that 0x11/0x13 obey the ramp rate, so we should document that anyways in the dimmer section.

I think we can ignore the 0x21 (instant on/off) for now, it just seems to be an even faster version of fast on/off. I saw something about it being sent on the first 0-level crossing (I guess where the AC sine wave goes through zero).

[steve-bate]

Steve and Rob, can you test how your target devices behave? Do they also remember the ramp rate? ... In fact the insteon command table docs say clearly that 0x11/0x13 obey the ramp rate, so we should document that anyways in the dimmer section.

@berndpfrommer, my 2672-222 has the same 0x11/0x13 and fast on/off behavior (using 0x34/0x35 for ramp) as you describe. I can't test the 2674-222 at this moment because someone is sleeping in that room, but my guess it that it will behave in a similar way (except for using 0x2e/0x2f for the ramping).

[robnielsen]

My 2334-232 and 2466D don't exhibit the problems you describe. They both turn on/off normally.

[robnielsen]

BTW, I have them set up as dimmers, not as a switch. I only am using a switch for ramp.

[SwissKid]

I also am running into the issue with it "setting" the ramp permanently. It says it's using 0x34 and 0x35 - but the ramp rates are being saved. Just realized this is different form bernd's issue... And might be something else wonky on my end. I will play around with insteon terminal later to see if I can send some commands that do it the "temporary" way.... Hopefully it's not something we're stuck with.

Edit: @berndpfrommer - is there an easy way for me to send raw hex commands via insteon-terminal? I didn't see an easy way from the docs.

[berndpfrommer]

@SwissKid ... sorry, I forgot to answer: no, you cannot send raw hex commands via insteon-terminal.

I'm starting to lose track of where we are with this issue. I think there was a PR submitted and merged, right? Can we close this one now?

[SwissKid]

I think this can be closed.
It wasn't fixed perfectly, but I've solved my issue by having multiple items that trigger in a special way....
Either way, my use case works :)