| Author |
|
jeffw_00
Super User
Joined: June 30 2007
Online Status: Offline
Posts: 929
|
| Posted: December 04 2007 at 23:33 | IP Logged
|
|
|
it may not...
so tonight I noticed some lamps on an INSTEON module didn't turn off at the proper time. I look in the log and see that the signal went out...
979 12/4/07 22:50:01.972 31 &nbs p; Insteon DM Controller POWERLINC transmission of Address:[04.DE.AC] Flags:[15] Cmd1:[20] Cmd2:[0]. Decode: Direct. ID: LIVINGROOMLAMPS, Fast Off
978 12/4/07 22:50:01.925 ; 8 ; ; Macro LIVRMLITESOFF executed.
977 12/4/07 22:50:01.925 ; 9 ; ; Timed Event processed for timestamp 2007-12-04 22:50:00, type 2, action ph_macroparm("LIVRMLITESOFF",0,0,0,0,0)
But when I looked at Device Status - it showed the LIVINGROOMLAMPS as "on". which was correct.
I have all the scans disabled. so I'm puzzled, it looks like PH thinks it turned the lamps off successfully, but also knew they were on (there were no events in the log related to the lamps after the one shown above).
any thoughts?
thanks!
/j
Edited by jeffw_00 - December 04 2007 at 23:38
|
| Back to Top |
|
| |
AllanMar
Groupie
Joined: April 02 2007
Online Status: Offline
Posts: 45
|
| Posted: December 06 2007 at 10:33 | IP Logged
|
|
|
You have no log entry for the ACK, which I would think means the command never made it to the lamp (kinda obvious I suppose) Check the SDM log and see if that shows the outgoing command (Could be the SDM screwed up). If not, then you likely have signal issues with that lamp. Since the device status screen stayed on, and you dont have status scan enabled you must have "Update on ACK" enabled?
|
| Back to Top |
|
| |
jeffw_00
Super User
Joined: June 30 2007
Online Status: Offline
Posts: 929
|
| Posted: December 06 2007 at 10:40 | IP Logged
|
|
|
Update on ACK -is- enabled. Hmmm, I will look through my log and see if other INSTEONs have an ACK entry. (if it didn't Ack, shouldn't I see some re-tries?). Unfortunately, it happened Tuesday, so I'm not sure the SDM log will go back that far, but I'll look. (and now I know where to look next time).
thanks - good advice from a "newbie" 8-}
/j
|
| Back to Top |
|
| |
AllanMar
Groupie
Joined: April 02 2007
Online Status: Offline
Posts: 45
|
| Posted: December 06 2007 at 13:13 | IP Logged
|
|
|
You won't see retries in the PowerHome log..I never have anyway. I don't recall if NAK's show either. The retry part of the protocol is done by the device, not powerhome. Atleast that is my understanding.
Update on ACK is why powerhome dosn't think it turned the light off (which is good, because it hasn't) If you had Update on ACK disabled, it would have shown the light as turned off, even though it wasnt.
If this only occurs sparaticly it is most likely a SDM/noise problem. I have never experienced many SDM problems, but plenty of others have. I would think it could be noise.
It may be a good idea to turn Status scan on, wait a little while and check the Insteon Reports. Turning status scan on will generate consistant traffic to help give you better stats in the reports. See if it shows alot of failed comm's for that specific device or if it takes alot of repeats to communicate with it.
|
| Back to Top |
|
| |
jeffw_00
Super User
Joined: June 30 2007
Online Status: Offline
Posts: 929
|
| Posted: December 06 2007 at 13:18 | IP Logged
|
|
|
thanks AM. It's a rare occurance, and could be due to noise. I'm in the process of funnelling all my INSTEON calls through a single macro, where I intend to detect when the macro is called by a timed event, and in that case, try it twice 30 sec apart.
PH rocks
/j
|
| Back to Top |
|
| |
AllanMar
Groupie
Joined: April 02 2007
Online Status: Offline
Posts: 45
|
| Posted: December 06 2007 at 14:26 | IP Logged
|
|
|
My recommendation would be to try and track down the noise/actual issue rather than trying twice. Since it will probably crop up with other problems down the road
However, I would just put a Wait 30sec in your current macro (after it turns the light on) then have it check if PH still has the light as being on or not. If it's still on, try again. This way you will only have the second command if you need it (less uncessary traffic). You could really have it try as many times as you want..careful not to create an infinte loop however (if something else is wrong and the light will never turn off)
Insteon Ctl LIVINGROOMLAMPS Fast Off
Wait 30
Jump if(ph_getinsteonstat("LIVINGROOMLAMPS")=2,1,2)
Insteon Ctl LIVINGROOMLAMPS Fast Off
(either go back to wait 30 here (possible infinite loop) or give up)
Edited by AllanMar - December 06 2007 at 14:28
|
| Back to Top |
|
| |
jeffw_00
Super User
Joined: June 30 2007
Online Status: Offline
Posts: 929
|
| Posted: December 06 2007 at 15:04 | IP Logged
|
|
|
track down the noise source? Doh! why didn't I think of that 8-}.
Seriously, in this case the problem is so rare (happened 2x in 3 months I think), that the simple wait and retry (or the more elegant "try again only if you need it"), is probably all the thought I want to give to it. Whatever the noise source is, it would have to be a bit more obvious to lend itself to being found...
Thanks for the coding trick though.
/j
|
| Back to Top |
|
| |
BeachBum
Super User
Joined: April 11 2007
Location: United States
Online Status: Offline
Posts: 1880
|
| Posted: December 06 2007 at 16:55 | IP Logged
|
|
|
Jeff, what I do to handle noise is to place the level I am sending in a variable. Then when an Insteon change occurs I have a macro that triggers and checks all variables against what the corresponding devices think they are set at. If they don’t match I resend the command to the device. Since I have a lot of noise this works perfectly for me. I remember you may have some traffic coming from an outside source and this may be colliding with the Insteon traffic. I don’t think the PLC has collision detection but I could be wrong.
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
jeffw_00
Super User
Joined: June 30 2007
Online Status: Offline
Posts: 929
|
| Posted: December 06 2007 at 17:00 | IP Logged
|
|
|
thanks BB - I think i solved my main noise problem but that's a good scheme.
/j
|
| Back to Top |
|
| |
bhlonewolf
Senior Member
Joined: March 29 2007
Online Status: Offline
Posts: 198
|
| Posted: December 06 2007 at 18:25 | IP Logged
|
|
|
Very likely, you're getting a NAK. (This is why I'm hoping Dave implements the NAK trigger idea ;))
If you can, try to save the log files. I think you can send a command to the SDM directly to zip up/export the log files (not sure if you can do that directly in PH).
|
| Back to Top |
|
| |
jeffw_00
Super User
Joined: June 30 2007
Online Status: Offline
Posts: 929
|
| Posted: December 06 2007 at 21:45 | IP Logged
|
|
|
looked at my PH log - only one insteon entry per event - no ack/nack recorded.
is this a feature request? 8-}
/j
Edited by jeffw_00 - December 06 2007 at 21:46
|
| Back to Top |
|
| |
bhlonewolf
Senior Member
Joined: March 29 2007
Online Status: Offline
Posts: 198
|
| Posted: December 06 2007 at 21:52 | IP Logged
|
|
|
Just to clarify I was thinking of the Insteon log, not the PH log... if you look on the device tab, and scroll over to the comm count / event 03 / nak columns, are there any NAKs for this device?
|
| Back to Top |
|
| |
jeffw_00
Super User
Joined: June 30 2007
Online Status: Offline
Posts: 929
|
| Posted: December 06 2007 at 22:25 | IP Logged
|
|
|
I'm sorry - don't mean to be dense - where is the insteon log? I just now opened the insteon explorer and all the windows were empty. where should I be looking?
/j
|
| Back to Top |
|
| |
bhlonewolf
Senior Member
Joined: March 29 2007
Online Status: Offline
Posts: 198
|
| Posted: December 06 2007 at 23:45 | IP Logged
|
|
|
Oh, no worries Jeff.
So in the insteon log is basically everything that's going on with the PLC. If you open the SDM (Smarthome Device Manager -- the little "T" icon in the systray) you'll see everything there.
PH echoes this in the Insteon Explorer window, as it talks to the PLC via the SDM.
It's a great debugging tool if you want a little more of a raw look at what's going on. Due to the volume of traffic, though, the SDM truncates itself pretty regularly and I don't believe there's any "auto-save" feature.
I've actually written a little app that talks to the SDM for my own log files, but since PH does 95% of what I need for debugging, I don't really use it. I just really like to figure out some random NAK issues. (very stupidly I realized one by accident -- a device plugged into a filterlinc. Doh!)
|
| Back to Top |
|
| |
jeffw_00
Super User
Joined: June 30 2007
Online Status: Offline
Posts: 929
|
| Posted: December 07 2007 at 00:02 | IP Logged
|
|
|
i know of that, but it never has more than the last tens of minutes in it..
thanks
/j
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: December 09 2007 at 12:22 | IP Logged
|
|
|
Yep,
What happened is that the command was sent, it didnt get acknowledged (could have been NAKed or not heard at all) and PowerHome did not update status because you're got "Update on ACK" checked. With "Update on ACK" checked, PowerHome will *only* update status when it receives an ACK. Some people prefer to turn this off and then PowerHome will update status whenever it sends a command. Either way, there is the possibility of problems. With "Update on ACK" checked, you can still get out of sync because it's possible that the ACK communication is lost. So everything works, PowerHome turns on a light, the light responds with an ACK, but the ACK was lost in traffic. PowerHome out of sync. Of course, with "Update on ACK" off, the transmitting command can be lost and the result is PowerHome out of sync.
Retries are handled internally by the Insteon devices themselves, but if communications arent 100%, then failures do occur. I'll look into adding a NAK trigger.
Dave.
|
| Back to Top |
|
| |
jeffw_00
Super User
Joined: June 30 2007
Online Status: Offline
Posts: 929
|
| Posted: December 09 2007 at 12:28 | IP Logged
|
|
|
Well, I have directed all my INSTEON traffic through a single macro, and I use ph_getinsteonstat to decide whether to retry (either immediately, or delayed). I think that will make things sufficient reliable?
/j
|
| Back to Top |
|
| |
mustangcoupe
Super User
Joined: August 08 2003
Location: United States
Online Status: Offline
Posts: 308
|
| Posted: December 11 2007 at 16:37 | IP Logged
|
|
|
Jeff,
I am rebuilding my entire PH setup (crashed without a backup) would you mind sharing this macro and how it works with us?
Thanks
__________________
Todd Hannemann
HA newbie 
 PowerHome - UPB - ELK
|
| Back to Top |
|
| |
jeffw_00
Super User
Joined: June 30 2007
Online Status: Offline
Posts: 929
|
| Posted: December 11 2007 at 16:49 | IP Logged
|
|
|
No problem - I can publish the code tonight, but it's really not much more than this:
Instead of sending an on or off, I have a macro SEND_INSTEON that has 3 parameters
1) device name
2) ion or ioff
3) 1 = came from trigger, 0 = came from timed event.
then, the actual macro does
1) sends the insteon command
2) waits a few seconds (still mucking to pick a good number, probably 3-4 sec, and I'm still debating whether this should be a WAIT or DELAY - pros/cons each way)
3) does a ph_getinsteonstat and compares the returnvalue to the ion/ioff parameter (ion/ioff)+1 should = the return value)
4) if it matches, we're done, exit,
if not, and the command source was a trigger, try again and exit,
if not, and the command source was a timed event, wait a minute and try 1-3 a couple more times.
If you still fail, increment a global (so you see it in the log) and exit.
the idea is - if the command came from a button press, you only want to retry for a few seconds (because after that the person will re-press the button), if the command came from a timed command (which is more important because it's unsupervised) you want to keep trying, but you can wait a bit before the retry.
I'll try to post the code tonight
/j
BTW: you might want to consider a backup scheme 8-}
I created a CC button that
1) backs up my database
2) calls a small external perl script that renames the backup to a unique name
So I backup frequently, and save all my backups so I can go back. If anyone wants, I can post the perl script (I also have one that converts the SQL output to one-line-per-entry for improved readability)
Edited by jeffw_00 - December 11 2007 at 16:49
|
| Back to Top |
|
| |
jeffw_00
Super User
Joined: June 30 2007
Online Status: Offline
Posts: 929
|
| Posted: December 11 2007 at 19:19 | IP Logged
|
|
|
INSERT INTO macrodetail.sql VALUES ( 'SEND_INSTEON', 1, 38, '', 0, 'if([LOCAL2] = 0, ph_insteon( "[LOCAL1]", ifastoff, 0), ph_insteon( "[LOCAL1]", ifaston, 0))', 0, '');
INSERT INTO macrodetail.sql VALUES ( 'SEND_INSTEON', 2, 31, '', NULL, '5', 0, ''); [THIS IS A WAIT]
INSERT INTO macrodetail.sql VALUES ( 'SEND_INSTEON', 3, 16, '', NULL, 'if(ph_getinsteonstat("[LOCAL1]") = ph_addtovar(1,2,1),999,1)', 0, '');
INSERT INTO macrodetail.sql VALUES ( 'SEND_INSTEON', 4, 38, '', 0, 'if([LOCAL2] = 0, ph_insteon( "[LOCAL1]", ifastoff, 0), ph_insteon( "[LOCAL1]", ifaston, 0))', 0, '');
INSERT INTO macrodetail.sql VALUES ( 'SEND_INSTEON', 5, 16, '', NULL, 'if((ph_getvar_n(1,3)) = 1,4,1)', 0, '');
INSERT INTO macrodetail.sql VALUES ( 'SEND_INSTEON', 6, 16, '', NULL, 'if(ph_getinsteonstat("[LOCAL1]") = ph_addtovar(1,2,1),999,1)', 0, '');
INSERT INTO macrodetail.sql VALUES ( 'SEND_INSTEON', 7, 31, '', NULL, '60', 0, ''); [THIS IS A WAIT]
INSERT INTO macrodetail.sql VALUES ( 'SEND_INSTEON', 8, 38, '', 0, 'if([LOCAL2] = 0, ph_insteon( "[LOCAL1]", ifastoff, 0), ph_insteon( "[LOCAL1]", ifaston, 0))', 0, '');
INSERT INTO macrodetail.sql VALUES ( 'SEND_INSTEON', 9, 31, '', NULL, '5', 0, ''); [THIS IS A WAIT]
INSERT INTO macrodetail.sql VALUES ( 'SEND_INSTEON', 10, 16, '', NULL, 'if(ph_getinsteonstat("[LOCAL1]") = ph_addtovar(1,2,1),999,1)', 0, '');
INSERT INTO macrodetail.sql VALUES ( 'SEND_INSTEON', 11, 38, '', 0, 'ph_addtoglobal("IERROR",1)', 0, '');
|
| Back to Top |
|
| |
|
|
Active Topics 
Memberlist 
Search 
Help
Register 
Login
PowerHome Messageboard : PowerHome General
Topic: does this make any sense?
