Author |
|
smarty Super User
Joined: May 21 2006 Location: United States
Online Status: Offline Posts: 728
|
Posted: September 22 2016 at 06:20 | IP Logged
|
|
|
I have recently been testing the addition of an Insteon outletlinc to my system.
Due to the way the secondary outlet is controlled (only by PLM groups), I have made one change to my Insteon controller to better sense the actual/confirmed outlet state (on/off). I have now checked the checkbox "PLC Group Cleanup" checkbox <=There may be better/other ways to do this, but this device will be located where I can't see it, and therefore I really need to know the true state of the device.
After I send a PLM group command to turn either the primary or secondary outlet of the outletlinc on/off, I receive a single group acknowledgement command letting me know there was positive confirmation of the change (I then trigger off this acknowledgment).
This all seems to work fine...but after switching the outlets on/off a couple of times, I eventually see the error below. Note the time stamp of this error.
+++++++++++++++++++++
A critical error occurred at 2016-09-21 22:06:14.424.
PowerHome Version: 2.1.5d
Critical Error Count: 1
Error Number: 2
Error Message: Null object reference at line 167 in function f_insteoncontrol of object uo_controller_insteon.
Window: uo_controller_insteon
Object: uo_controller_insteon
Event: f_insteoncontrol
Line: 167
++++++++++++++++++++
Notice the bottom of the picture (22:06:12) and (22:06:13) were the last two pieces of Insteon traffic before the controller crash 22:06:14.
It could be that by checking the "PLC Group Cleanup" box I am just creating a lot more Insteon traffic, stressing the system and causing the critical error.....
Lastly, if I move away from using the incoming Insteon group acknowledgment command as my positive confirmation trigger, what might be a better way to positively sense my outlet state?
Edited by smarty - September 22 2016 at 07:34
__________________ Elk - Insteon - BlueIris - DMC1 - PowerHome - XLobby - HA_Bridge w/Dots - Brultech
|
Back to Top |
|
|
dhoward Admin Group
Joined: June 29 2001 Location: United States
Online Status: Offline Posts: 4447
|
Posted: October 15 2016 at 22:05 | IP Logged
|
|
|
Steve,
Ive looked at your critical error and the code that it references and cant figure out why/how this would be happening. The error is a null object reference but there are no objects
in that particular line of code so Im thinking it's a false alarm. It's a real error that is most likely occurring somewhere else within the code and it's just the wrong location
being reported in the error...which is going to make it difficult to track down . Not sure if there is any additional testing you can do to try and isolate it but any
additional info you can provide will definite be a huge help. Since the error is repeatable, maybe you could first try turning off the "Group Cleanup" and see if we can get the
error. Next, maybe switch off some of the associated triggers. Anything we can do to try to isolate will be helpful.
I did some research on the dual outletlinc and have found how you can turn the bottom outlet on/off without having to do group commands. The top outlet can just be controlled as
normal by turning the outletlinc device shown in the Device status on or off. The bottom outlet can be turned on with this command:
ph_insteonwithretext1("OUTLETLINC",17,255,"02")
To turn the bottom outlet off use this command:
ph_insteonwithretext1("OUTLETLINC",19,0,"02")
You can issue this command to find out the actual state of both outlets:
ph_insteonwithret1("OUTLETLINC",25,1)
The return will be:
0 = both outlets off
1 = top outlet only on
2 = bottom outlet only on
3 = both outlets on
Let me know if you find out anymore info in the meantime and I'll see what I can do on this end.
Hope this helps,
Dave.
|
Back to Top |
|
|
|
|