View Full Version : Insteon stops working
grog
January 20th, 2008, 11:02 PM
I've been having a problem lately where Insteon stops working and it's very difficult to get it going again. When I check in Component Manager it shows no connection to the PLC but reseting SDM doesn't usually help. Restarting Girder doesn't help either. Rebooting sometimes helps but even that takes a few tries. When I check the SDM logs I see the following error:
UIERR:OnConnectedAndReady:(disconnecting): Lua runtime error: ...ram Files\Promixis\Girder5\\luascript\compat-5.1.lua:187: loop or previous error loading module 'DeviceManager.Providers.Insteon'
stack traceback:
[C]: in function `error'
...ram Files\Promixis\Girder5\\luascript\compat-5.1.lua:187: in function `require'
.\Insteon.lua:78: in function <.\Insteon.lua:73>
.\Insteon.lua:6058: in function `PollingLoop'
.\Insteon.lua:5981: in function `SetPLCStatus'
.\Insteon.lua:5938: in function `SetupDMOptions'
.\Insteon.lua:5913: in function `DMConnectedandReady'
.\Insteon.lua:1027: in function <.\Insteon.lua:1025>
Any ideas on what the problem could be? I'm running build 523 in XP, BTW.
Rob H
January 21st, 2008, 03:01 AM
Hmm... that's strange I can't see any obvious reason for that to fail, at least not consistently.
I'm a bit concerned that SetPLCStatus directly calls PollingLoop and that PollingLoop in turn calls SetPLCStatus.
However, I wouldn't expect there to be a problem loading up the code for the Insteon provider unless there's a problem with the provider code - I assume that when you reset Girder there are no errors shown in the Lua console?
Unfortunately, Insteon hardware isn't available in the UK so I can't do much more than look at the code :(
grog
January 21st, 2008, 04:12 AM
I checked the LUA console and there were a whole bunch of errors there too (this is after a system reboot - Girder loads automatically). I've attached the log in a file since it is fairly long.
Rob H
January 21st, 2008, 05:30 AM
Ah, okay - it looks like one of the config files has got damaged and from the look of it I'd say it was DeviceManager.cfg - go to File|Settings|Configuration Files and press the explore directory button. Try comparing the DeviceManager.cfg file with the DeviceManager.c01 to c05 files (load them into a text editor). I suspect that DeviceManager.cfg is empty - hopefully one of the .c0N files will contain a backup so you can rename it as DeviceManager.cfg. Failing that you'll have to delete the DeviceManager.cfg file and set up any devices again.
quixote
January 21st, 2008, 07:07 AM
How do these files get damaged?
Rob H
January 21st, 2008, 11:08 AM
I wish I knew!
quixote
January 21st, 2008, 11:47 AM
Yeah, I kind of figured that if you knew exactly what the problem is, then it wouldn't be a problem anymore. I was just trying to see if you had any kind of leads or anything. I suspect that sometimes when my system gets bogged down, then certain things fail to load and possibly save. It probably ties in with my favorite mutex problem.
Rob H
January 21st, 2008, 02:39 PM
It looks likely that something is going wrong with the gir.WriteConfigTable() function in girconfig.lua
Having just looked at it again I'm not happy with the implementation. If something goes wrong with the table.save call at the end then it really should either undo the rename operations that it previously performed, or it should write to a temporary file first and only then perform the rename.
I'll see what I can do to implement the second of these (as it seems the simplest and most sensible).
grog
January 21st, 2008, 04:18 PM
Thanks Rob, you nailed it. That was exactly the problem - DeviceManager.cfg was 0 bytes. Luckily .c01, .c02, etc. were all fine so I replaced it with .c01 and Insteon loaded no problem.
quixote
January 21st, 2008, 11:22 PM
It looks likely that something is going wrong with the gir.WriteConfigTable() function in girconfig.lua
Having just looked at it again I'm not happy with the implementation. If something goes wrong with the table.save call at the end then it really should either undo the rename operations that it previously performed, or it should write to a temporary file first and only then perform the rename.
I'll see what I can do to implement the second of these (as it seems the simplest and most sensible).
This is great news. I've been having tons of problems with loading and saving my persistent variables using gir.WriteConfigTable() and gir.ReadConfigTable(), so this should help a lot.
Rob H
January 22nd, 2008, 02:15 AM
Can some of you who have been having problems with this (especially quixote) try these two files in the luascript directory please? But make a backup of the existing files first and also the contents of the config directory just in case.
Thanks.
quixote
January 22nd, 2008, 02:56 AM
So far, so good. It may take a while to definitively say that the problem has been resolved, since I couldn't reproduce the problem; it would just randomly occur. I'll keep you informed.
Thanks for the fix.
Rob H
January 22nd, 2008, 03:34 AM
Well, at least nothing bad has happened so far, which is a good start :)
Powered by vBulletin® Version 4.1.8 Copyright © 2012 vBulletin Solutions, Inc. All rights reserved.