| Author |
|
BeachBum
Super User
Joined: April 11 2007
Location: United States
Online Status: Offline
Posts: 1880
|
| Posted: April 26 2009 at 18:24 | IP Logged
|
|
|
I thought there was something fishy about the Stop Man Chg but couldnt put my finger on as I had never seen that come in with any of my testing.
Edited by BeachBum - April 26 2009 at 18:31
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
BeachBum
Super User
Joined: April 11 2007
Location: United States
Online Status: Offline
Posts: 1880
|
| Posted: April 26 2009 at 18:43 | IP Logged
|
|
|
Handman, You might try a Trigger with Macro - Insteon Group In - Any - Any - - Stop Man Chg (0x18). In the macro place a wait 1 and then issue a ph_insteonclearfailed("id of PLM"). That should clear any of the fails. Again, since I used Word, beware of forum quotes. Someone might know of a cleaner way.
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
Handman
Senior Member
Joined: February 02 2009
Location: United States
Online Status: Offline
Posts: 229
|
| Posted: April 26 2009 at 18:54 | IP Logged
|
|
|
Oh man, you guys got it! The PLM failed again and again I saw the Stop Man Chg. This time I duplicated it at will with ANY Icon or Switchlink. I was so excited to post my findings and then I see Dave H has already found it!! I didn't get any emails about the forum updates so I thought, "Eureka!" Oh well, four pages of problem solving and my status has changed from Newbie to Groupie, so I got that going for me, which is nice ("Gunga, gunga lunga . . . nice man the Lama, big hitter.")
Why do I know I'll be back. Pete, thanks for the clear failed suggestion. I'll do it. Now I just gotta figure out why I have lights turning on that I didn't turn on.
|
| Back to Top |
|
| |
BeachBum
Super User
Joined: April 11 2007
Location: United States
Online Status: Offline
Posts: 1880
|
| Posted: April 26 2009 at 19:03 | IP Logged
|
|
|
Noise 
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
cmhardwick
Senior Member
Joined: July 08 2006
Location: United States
Online Status: Offline
Posts: 290
|
| Posted: April 27 2009 at 16:44 | IP Logged
|
|
|
or lingering X10 addresses in those switches. If a factory reset wasn't done on them when you installed them, it's a distinc possibility. You can also set the insteon explorer to scan X10 settings when it's polling, then it will show up on the device info screens.
__________________
Cicero, Enjoying automation!
|
| Back to Top |
|
| |
Handman
Senior Member
Joined: February 02 2009
Location: United States
Online Status: Offline
Posts: 229
|
| Posted: April 27 2009 at 17:33 | IP Logged
|
|
|
I have polling enabled as well as level/ramp/x10 scan and none of my Insteon devices show an X10 address. I could perform the factory reset just to be sure. Last night I investigated the rogue light turning on. Basically I have a macro set to turn one light on (a fluorescent relay) and another to "dim" when triggered by an X10 motion sensor (by way of PH). The event log shows the macro firing and both devices responding, however, neither light activates, and what is worse, a third, unrelated, light turns on dim!! I have verified the addresses physically, and I am able to turn on/off/dim all lights normally from w/i PH. Interestingly, Device Stat does not show ANY of the lights turning on when this happens! If I send a status request (ph_getinsteonlevelrt)[Pete's suggestion] to the one light which did turn on (dim), it does show that it is on! I am able to reproduce this time and time again, so this doesn't seem to me like a noise issue unless noise is converting Insteon addresses perfectly to the exact same address.
As far as I can tell, the way to remove all X10 addresses from an Icon switch is to press the top of the paddle until it goes into linking mode. Then repress the top of the paddle until the LED flashes again. Then send any X10 house/unit code three times within four minutes and the X10 memory of the device should be cleared (the LED will flash again). Anyone disagree?
|
| Back to Top |
|
| |
BeachBum
Super User
Joined: April 11 2007
Location: United States
Online Status: Offline
Posts: 1880
|
| Posted: April 27 2009 at 17:40 | IP Logged
|
|
|
Handman, can you tell from the log if the dim level returned is the same each time? As I remember youve got the x10 reset correct.
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
Handman
Senior Member
Joined: February 02 2009
Location: United States
Online Status: Offline
Posts: 229
|
| Posted: April 27 2009 at 17:55 | IP Logged
|
|
|
The event log just says DIM and CMD1 of 22 every time. The raw log is below.
2009-04-27 01:00:17.015 RX &nbs p; SENTINSTEON=0F 44 B1 0F AC 43 0F 16 00 06
2009-04-27 01:00:17.328 RX &nbs p; RECEIVEINSTEONRAW=0F AC 43 0F 44 B1 2B 16 00
OF.44.B1 is the PLM and 0F.AC.43 is the device which says it is turning on dim, but is not actually turning on at all. In fact, a third light appears to dim, and there is no record of that in any log!
|
| Back to Top |
|
| |
BeachBum
Super User
Joined: April 11 2007
Location: United States
Online Status: Offline
Posts: 1880
|
| Posted: April 27 2009 at 18:09 | IP Logged
|
|
|
OK, to make sure I understand this right, you send a Direct Command to 0F.AC.43 and it ACKs but 0F.AC.43 in actuality does NOT turn on but another light does. Whats its address?
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
grif091
Super User
Joined: March 26 2008
Location: United States
Online Status: Offline
Posts: 1357
|
| Posted: April 27 2009 at 18:57 | IP Logged
|
|
|
A 0x16 (dec 22) Dim command does not tell a device to turn On Dim. It tells the device to drop down one level of intensity from its current level. If it was at intensity 21, it would drop to intensity level 20. If it is Off to begin with it remains Off. The command will be ACKed because the command was addressed to a valid device, was a valid command, and it was acted upon.
EDIT: can you post the Raw Log that shows the complete sequence for both the Relay device and the Dimmer. Several commands (in other words several seconds) on both sides of the sequence. The dimmer device that was Off would not visibly respond to a Dim but I assume you sent an ON to the Relay device and it should have reacted. The fact that the results are reproducible suggests there is another factor involved not yet understood.
Edited by grif091 - April 27 2009 at 19:07
__________________
Lee G
|
| Back to Top |
|
| |
Handman
Senior Member
Joined: February 02 2009
Location: United States
Online Status: Offline
Posts: 229
|
| Posted: April 27 2009 at 19:51 | IP Logged
|
|
|
OK, I'll post all the logs. I was a little pressed to get the kids at school on the last post. In the interest of full disclosure there are actually two things that happen when the motion sensor fires. One trigger turns on an X10 light (a wall wart RR501). This always comes on when it is supposed to. The other trigger fires the aforementioned macro. My bad on the DIM. I assumed it would be set to a "dim" level, not what Lee mentioned. Problem solved there since it would have been off anyway. The other issue is the relay not turning on the fluorescent lights. The third issue is the pantry light coming on when it is not supposed to. I just tested and it turns out the pantry light IS coming on (at a dim setting) with the X10 (C9 ON) command. I will try and remove the X10 setting from this device for a second time. Hopefully another reset will stop this errant behavior (why doesn't it show as an X10 device in PH?) As for the relay . . . here are the logs:
2009-04-27 00:58:09.250 RX &nbs p; RECEIVEX10RAW=BD 00
2009-04-27 00:58:09.875 RX &nbs p; RECEIVEX10RAW=B2 80
2009-04-27 01:00:05.859 RX &nbs p; RECEIVEX10RAW=B8 00
2009-04-27 01:00:06.484 RX &nbs p; RECEIVEX10RAW=B2 80
2009-04-27 01:00:06.765 TX &nbs p; 02 62 04 6D 29 0F 11 00
2009-04-27 01:00:06.781 RX &nbs p; SENTINSTEON=0F 44 B1 04 6D 29 0F 11 00 06
2009-04-27 01:00:07.078 RX &nbs p; RECEIVEINSTEONRAW=04 6D 29 0F 44 B1 2B 11 00
2009-04-27 01:00:07.312 TX &nbs p; 02 62 0F AC 43 0F 16 00
2009-04-27 01:00:07.328 RX &nbs p; SENTINSTEON=0F 44 B1 0F AC 43 0F 16 00 06
2009-04-27 01:00:07.640 RX &nbs p; RECEIVEINSTEONRAW=0F AC 43 0F 44 B1 2B 16 00
2009-04-27 01:00:07.875 TX &nbs p; 02 63 27 00
2009-04-27 01:00:07.890 RX &nbs p; SENTX10=27 00 06
2009-04-27 01:00:08.765 TX &nbs p; 02 63 22 80
2009-04-27 01:00:08.781 RX &nbs p; SENTX10=22 80 06
2009-04-27 01:00:15.562 RX &nbs p; RECEIVEX10RAW=B8 00
2009-04-27 01:00:16.203 RX &nbs p; RECEIVEX10RAW=B2 80
2009-04-27 01:00:16.468 TX &nbs p; 02 62 04 6D 29 0F 11 00
2009-04-27 01:00:16.484 RX &nbs p; SENTINSTEON=0F 44 B1 04 6D 29 0F 11 00 06
2009-04-27 01:00:16.796 RX &nbs p; RECEIVEINSTEONRAW=04 6D 29 0F 44 B1 2B 11 00
2009-04-27 01:00:17.000 TX &nbs p; 02 62 0F AC 43 0F 16 00
2009-04-27 01:00:17.015 RX &nbs p; SENTINSTEON=0F 44 B1 0F AC 43 0F 16 00 06
2009-04-27 01:00:17.328 RX &nbs p; RECEIVEINSTEONRAW=0F AC 43 0F 44 B1 2B 16 00
2009-04-27 01:00:17.546 TX &nbs p; 02 63 27 00
2009-04-27 01:00:17.562 RX &nbs p; SENTX10=27 00 06
2009-04-27 01:00:18.421 TX &nbs p; 02 63 22 80
2009-04-27 01:00:18.437 RX &nbs p; SENTX10=22 80 06
2009-04-27 01:00:42.828 RX &nbs p; RECEIVEX10RAW=B8 00
2009-04-27 01:00:43.468 RX &nbs p; RECEIVEX10RAW=B2 80
2009-04-27 01:00:43.734 TX &nbs p; 02 62 04 6D 29 0F 11 00
2009-04-27 01:00:43.750 RX &nbs p; SENTINSTEON=0F 44 B1 04 6D 29 0F 11 00 06
2009-04-27 01:00:44.062 RX &nbs p; RECEIVEINSTEONRAW=04 6D 29 0F 44 B1 2B 11 00
2009-04-27 01:00:44.296 TX &nbs p; 02 62 0F AC 43 0F 16 00
2009-04-27 01:00:44.312 RX &nbs p; SENTINSTEON=0F 44 B1 0F AC 43 0F 16 00 06
2009-04-27 01:00:44.625 RX &nbs p; RECEIVEINSTEONRAW=0F AC 43 0F 44 B1 2B 16 00
2009-04-27 01:00:44.843 TX &nbs p; 02 63 27 00
2009-04-27 01:00:44.843 RX &nbs p; SENTX10=27 00 06
2009-04-27 01:00:45.703 TX &nbs p; 02 63 22 80
2009-04-27 01:00:45.718 RX &nbs p; SENTX10=22 80 06
2009-04-27 01:00:48.750 RX &nbs p; RECEIVEX10RAW=BF 00
2009-04-27 01:00:49.390 RX &nbs p; RECEIVEX10RAW=B2 80
2009-04-27 01:00:49.640 TX &nbs p; 02 63 27 00
2009-04-27 01:00:49.656 RX &nbs p; SENTX10=27 00 06
2009-04-27 01:00:50.515 TX &nbs p; 02 63 22 80
2009-04-27 01:00:50.531 RX &nbs p; SENTX10=22 80 06
EDIT: The PANTRY LIGHT which turns on is 03.78.49. I renamed all my Insteon devices to make troubleshooting easier.
Edited by Handman - April 27 2009 at 20:04
|
| Back to Top |
|
| |
Handman
Senior Member
Joined: February 02 2009
Location: United States
Online Status: Offline
Posts: 229
|
| Posted: April 27 2009 at 19:55 | IP Logged
|
|
|
Here is the event log and copy of macro
|
| Back to Top |
|
| |
Handman
Senior Member
Joined: February 02 2009
Location: United States
Online Status: Offline
Posts: 229
|
| Posted: April 27 2009 at 20:38 | IP Logged
|
|
|
Wow. As for that Icon dimmer (pantry Light) that comes on with a C9 ON command, it turns out I actually have two Icons switches that are coming on (dimmed, 44 and dimmed, 47). The manual reset did nothing, and rebuilding the links in PH hasen't fixed this problem. Bit of a sticky wicket . . .
|
| Back to Top |
|
| |
grif091
Super User
Joined: March 26 2008
Location: United States
Online Status: Offline
Posts: 1357
|
| Posted: April 27 2009 at 20:53 | IP Logged
|
|
|
The ON command 0x11 (dec 17) to 04.6D.29 looks okay. The command was issued and the device ACKed the command. This sounds like a reproducible problem from your earlier post. Since the command itself is okay, then it could be the switch itself, the load it is controlling, or some other command (Insteon or X10) is having some interaction with the switch.
I would start a process of elimination. Check the Skip column for everything except the ON command itself, including the X10 C9 ON that is being issued from somewhere else. Be sure to Save (PF5) after making the changes. If the basic ON command works then add back individual items one at a time until it stops working. If the basic ON command does not work then you are looking at the switch itself or the type of load it is controlling.
The X10 address the device responds to is stored in an area of memory that is not directly accessible programmatically. That is why it is necessary to power cycle the device after an X10 change. On power up it transfers the information from low memory where PowerHome sets the information to the actual working location. Since PH sets/reads the intermediate location, if you will, you are not seeing the information the device is physically working with.
One way to be sure the factory reset actually worked is to try controlling the device you just factory reset with a Group command sequence where the link information is needed. Direct commands from PH do not use the link database so they cannot be used to verify the links are gone. Only if the links are gone, and the device no longer responds to Group commands that worked before the factory reset, are you sure the factory reset worked. There are other ways, you can pull the link database from the device into PH but that would eliminate the link record information that is currently stored in PH.
Edited by grif091 - April 27 2009 at 21:19
__________________
Lee G
|
| Back to Top |
|
| |
Handman
Senior Member
Joined: February 02 2009
Location: United States
Online Status: Offline
Posts: 229
|
| Posted: April 27 2009 at 21:43 | IP Logged
|
|
|
I checked SKIP for all but the ON command. The macro fired and the light acked, but it didn't turn on. I am baffled. I will rewrite the command using just a raw command with an trigger and see if that fixes it. I really don't like the way I always get a FORMULA ERROR when this macro is sent.
|
| Back to Top |
|
| |
grif091
Super User
Joined: March 26 2008
Location: United States
Online Status: Offline
Posts: 1357
|
| Posted: April 27 2009 at 21:46 | IP Logged
|
|
|
I'm checking with some actual tests but that Direct command to 04.6D.29 is wrong. A Direct command should have the bright level in cmd2. A bright level of 00 is unusual and will probably result in the equivalent to an OFF. Normally it would be 11 FF. I'll update this post in a few minutes.
EDIT: A Direct command 0x11 (dec 17) with a cmd2 value of 00 has the effect of turning the device Off. cmd2 has the bright level normally running from 1 - 255 decimal. With a Bright level of 00, the device is Off.
Edited by grif091 - April 27 2009 at 22:01
__________________
Lee G
|
| Back to Top |
|
| |
Handman
Senior Member
Joined: February 02 2009
Location: United States
Online Status: Offline
Posts: 229
|
| Posted: April 27 2009 at 21:49 | IP Logged
|
|
|
That works. I don't know why the macro doesn't work and the plain old trigger with a raw command does work, but I can work around it a this point.
I smell a bug alert . . .
Edited by Handman - April 27 2009 at 21:57
|
| Back to Top |
|
| |
grif091
Super User
Joined: March 26 2008
Location: United States
Online Status: Offline
Posts: 1357
|
| Posted: April 27 2009 at 21:56 | IP Logged
|
|
|
Put a value of 255 in the Send Keys field of the Insteon On macro line. That will put 0Xff into cmd2 and the device will turn on.
__________________
Lee G
|
| Back to Top |
|
| |
Handman
Senior Member
Joined: February 02 2009
Location: United States
Online Status: Offline
Posts: 229
|
| Posted: April 27 2009 at 22:00 | IP Logged
|
|
|
Genius! That did it! I had nothing in the SEND KEYS because I didn't know any better. I assumed "ON" would just set it on at 100%.
|
| Back to Top |
|
| |
grif091
Super User
Joined: March 26 2008
Location: United States
Online Status: Offline
Posts: 1357
|
| Posted: April 27 2009 at 22:06 | IP Logged
|
|
|
A Direct On command can set the device to any desired Bright level, from 255 (0xff) which is full on to anything down to 1. At 1 the bulb filament may not be bright enough to actually see.
Even though this is a relay device it must still make a differentiation between some positive Bright value and 0x00 being Off.
__________________
Lee G
|
| Back to Top |
|
| |
Active Topics 
Memberlist 
Search 
Help
Register 
Login
PowerHome Messageboard : PowerHome General
Topic: PLM clear failed, and more
