| Author |
|
judetf
Senior Member
Joined: January 23 2008
Online Status: Offline
Posts: 234
|
| Posted: March 27 2008 at 20:58 | IP Logged
|
|
|
Following Dave's instructions, I created a PLC group with a slow ramprate for the linked devices, and call it with ph_insteongroupcu in a macro where I want to dim a particular light slowly (it's the only instance where, so far, I have played with ramprates).
What I've just noticed is that, after turning the light off using the insteongroupcu command, that ramprate appears to "stick" to the device. Trying to control the device directly in PH, or even using ph_insteon/ion turns it on at the slow ramprate. I can use faston without a problem, but ideally I want the slow ramp just when that macro calls for it, and no other time.
I'm sure there is a logical reason for why this is happening. I'm looking for the simplest way to "undo" it. Do I need to create another PLC group with a normal ramprate and turn the light on with that?
Again, it's probably easily understood, and I just don't get it, but after that ramprate gets stuck, I don't see anyplace that even shows me that is the case. The device properties still show the desired local ramprate as being 31...
So, once again, any support will be much appreciated.
jtf
|
| Back to Top |
|
| |
judetf
Senior Member
Joined: January 23 2008
Online Status: Offline
Posts: 234
|
| Posted: March 29 2008 at 08:00 | IP Logged
|
|
|
Here is a little more info, in case it can help someone guide me to a solution:
Once the ramp rate gets "stuck", if I physically hit the KPL button that I have linked to control the light, it comes full on and gets unstuck. I have it configured as a virtual 3-way (two different KPLs controlling one light), and the links all work. When I press that button, I get the following in the SDM:
PLC:receiveinsteonraw=02 0A E3 CF 00 00 02 CB 11 00
PLC:eventraw=02
PLC:eventraw=03
PLC:receiveinsteonraw=02 0C AC CE 08 AC CE 45 11 02
PLC:eventraw=02
PLC:eventraw=03
PLC:receiveinsteonraw=02 09 98 0C 7E E3 CF 65 11 02
So, my basic question is: how do I translate what I'm seeing right there into PH code, so that I can replicate the effect. I've never learned what the "raw" codes mean. I assume that I can create a ph_insteonraw command to reproduce those commands, which will in turn cause the slow ramprate to get unstuck, and life will be good.
Can someone explain how to interpret those receiveinsteonraw commands and guide me to turning it into a raw formula for the macro i'll run after I run the macro with the slow ramprate?
Thanks
jtf
|
| Back to Top |
|
| |
BeachBum
Super User
Joined: April 11 2007
Location: United States
Online Status: Offline
Posts: 1880
|
| Posted: March 29 2008 at 11:50 | IP Logged
|
|
|
The only thing I see from the trace is a Group from the KPL then a group number 2 (button) with finally a Status command button # 2. Don’t know where this applies to your problem though. I wonder if from the virtual switch that is comes on full is because of the virtual switch’s local ramprate.
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
grif091
Super User
Joined: March 26 2008
Location: United States
Online Status: Offline
Posts: 1357
|
| Posted: March 29 2008 at 12:58 | IP Logged
|
|
|
I’m not an expert but I can fill in some of the blanks.
02 0A E3 CF 00 00 02 CB 11 00 Group Broadcast Message
0A E3 CF = from address = KPL address
00 00 02 = to address = KPL button 2 pressed = group number
Cx = message type = group broadcast message
11 = insteon ON command
02 0C AC CE 08 AC CE 45 11 02 Group Cleanup Direct Message
4x = message type = group cleanup direct message
02 09 98 0C 7E E3 CF 65 11 02 ACK of Group Cleanup Direct Message
6x = message type = ACK of group cleanup direct message
The Group Broadcast message is not directed at any specific device. Devices in the "Group" will have a Responder link entry that matches the Group Broadcast information (from address, group number). In this case the responder device will react to an Insteon ON (11) command. Normally things like ramp rate, brightness are defined/controlled by the values in the Responder link entry in the controlled device matching the Group Broadcast message. That allows for different reactions at each of the devices being controlled by the Group Broadcast. I'm assuming (bad thing to do) the Responder link entry that matches the Group Broadcast message has a fast ramp rate and full brightness.
The device is remembering the last ramp rate it was explicitly told to use, using that ramp rate until it is told explicitly to use some other ramp rate. This probably makes sense to the person that designed the device, knowing the ways the device would normally be asked to respond. Things get a little messy when we folks start sending command sequences the device designer did not or may be could not anticipate.
Edited by grif091 - March 29 2008 at 13:39
__________________
Lee G
|
| Back to Top |
|
| |
grif091
Super User
Joined: March 26 2008
Location: United States
Online Status: Offline
Posts: 1357
|
| Posted: March 29 2008 at 14:21 | IP Logged
|
|
|
Would you identify the Insteon device you are trying to control. Perhaps knowing the specific device would generate some ideas of how to change the ramp rate without affecting the actual state of the device. You might be able to follow up the slow dimming to OFF operation with a Group Broadcast OFF using a Responder link containing a fast ramp rate. That, in theory, would cause the device to do another OFF sequence using the Responder link entry with a fast ramp rate. If the device will actually do an OFF sequence when it is already OFF, it may remember the last ramp rate used, that being a fast ramp rate.
__________________
Lee G
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: March 29 2008 at 17:43 | IP Logged
|
|
|
jtf,
The problem you're describing is what I like to call one of Insteon's flaws. They must have made firmware changes though because on older switches, the slow ramprate was also stuck even with local control of the switch.
A faston/fastoff is exactly that. Full on or full off at the fastest ramprate. A regular on or off (direct command) will go at whatever was the last ramprate used by a group type of command. You should be able to work around it however.
You've already guessed at the way to fix it. You need to create a group with all your switches at the full ramprate. I havent actually tested this, but what I would try is creating a trigger that fires when you control the device using a ph_insteongroupcu command at the slow ramprate. Depending upon the speed of the ramprate, I would have a delay that takes place and once the switch has achieved the appropriate level, I would send another ph_insteongroupcu command using the full ramprate group and make the command a single bright statement. A single bright probably won't make any noticeable change in the output of the light and should correct the slow ramprate problem.
Let us know how it works out.
Dave.
|
| Back to Top |
|
| |
judetf
Senior Member
Joined: January 23 2008
Online Status: Offline
Posts: 234
|
| Posted: March 29 2008 at 22:22 | IP Logged
|
|
|
Yeah, that does it. Terrible solution (but nothing to do for it).
The light being controlled is a Switchlinc.
It would be nice if there was a way to do this without wasting a group just to get a full-speed ramp-rate back. Based on Dave's description I understand the need, but what a stinker to have to create a group just to "reset" the ramprate on a single Switchlinc.
But in any event, it works just fine. Since the dim is part of a larger "leaving the house" macro, and since that macro also creates a timed event for 5 minutes later to do a few other things, I just tacked the ph_insteongroupcu into that timed event, so I don't have to use an actual macro delay.
Thanks to all for the thoughts and assist.
jtf
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: April 02 2008 at 14:06 | IP Logged
|
|
|
jtf,
You wouldnt necessarily need to waste a group per device. You could create one massive group with ALL devices in it whose ramprate you want to reset and then just call individual devices using ph_insteongroupcu commands. The entire group would ONLY respond with a ph_insteongroup command and individual units can be addressed with a group cleanup. This will get alot more mileage out of your limited groups.
HTH,
Dave.
|
| Back to Top |
|
| |
judetf
Senior Member
Joined: January 23 2008
Online Status: Offline
Posts: 234
|
| Posted: April 02 2008 at 20:43 | IP Logged
|
|
|
Understood, and you misunderstood my complaint. I do have them all in one giant group, and it's working fine. I was just bemoaning the state of the technology (Insteon; not PH). It's not like I have more than 10 groups at this point anyway... It's just an unfortunate reality demanding the workaround solution.
But it does work, and work well, so until I add some 244 additional groups, I won't be complaining.
jtf
|
| Back to Top |
|
| |
Active Topics 
Memberlist 
Search 
Help
Register 
Login
PowerHome Messageboard : PowerHome General
Topic: PLC ramprate get stuck?
