| Author |
|
gg102
Senior Member
Joined: January 29 2013
Location: United States
Online Status: Offline
Posts: 245
|
| Posted: January 12 2014 at 14:00 | IP Logged
|
|
|
Dave,
I have narrowed down a lingering issue that I have had, that the remote CC crashes. I have narrowed it down to the specific line in a macro that does:
set global STAT_TIMEDEVENTS if ( ph_timedeventsctrl( "status", 0 )=1,"On", "Off")
Now, if I 'edit" and "verify" this statement it runs fine and does not crash the remote CC, but if I make a one line macro with this line in it, immediately when I execute this one line macro, the remote CC will crash. (well, you have to click on something in the remote CC)
The crash message is:
Application terminated
Error: invalid DataWindow row/column specified at line 83 in function f_processudp of object w_main.
ok, I found another line that also seems to crash the remote CC
set global STAT_X10_CONTROLLER if (ph_ctlrsq("CM11A_1",20,"Z",102,0)>=0,"Connected","Discon nected")
Sorry, but today, I decided to solve this thing once and for all.....I'm going to keep looking....it's possible there are others.
I'm discovering more information:
The name of the global variable seems to makes a difference. It seems that if I use the global name of STAT_TIMEDEVENTS it will crash. If I use the name STAT_0TIMEDEVENTS it will not crash. Also, if I use a variable name of VAR1 it will not crash, but STAT_TIMEDEVENTS will always crash. It doesn't seem to be the length of the name as the issue because I used VAR45678901234567 and it did not crash. Maybe the construct of the name is a problem????
Last Edit for today:
It seems that the issue has to do only with Set Global. It doesn't seem to be related to any function. If I set global to "whatever" and that specific global is used on a page in the CC as display "Static Global Variable" it will crash the remote CC. It doesn't seem to matter what the name is, or what the value is. It only seems to be related to that global being displayed on a page in the CC page as a "Static Global Variable".
Edited by gg102 - January 12 2014 at 20:49
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: January 13 2014 at 12:02 | IP Logged
|
|
|
gg,
Excellent detective work  . With the info you've posted, I should be able to confirm and track this down and have it fixed in the 2.1.5 release.
I'll work this tonight and report back here once Ive located the issue.
Dave.
|
| Back to Top |
|
| |
gg102
Senior Member
Joined: January 29 2013
Location: United States
Online Status: Offline
Posts: 245
|
| Posted: January 13 2014 at 16:25 | IP Logged
|
|
|
I'm sorry Dave,
I tried all day to come up with a step-by-step procedure to guarantee a failure. I tried this:
1. Make a global var and stuff it with a value
2. Display that global on a page in the CC
3. make a one line macro that puts a new value in the global.
4. start the remote CC
5. play the one line macro.
I expected a crash, but it didn't. Bummer
I've been trying all different combinations of this, but I can not come up with a reliable procedure. It's just too random.
I DO know it's somehow related to displaying a global (maybe others) on a page in the CC and that value gets changed. The reason it was not crashing when I changed the name yesterday was because THAT name was not being displayed on the page in the CC. Thus it didn't crash. When THAT name is on the page in the CC, it seems to crash more often, but not predictably.
I wonder if it has anything to do with the "TYPE" of variable as the type changes depending on what data is in the variable. (Maybe tomorrow)
I wish I could give you a specific procedure, but that's the best I can do so far.......
Sorry to add more work to the list.
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: January 26 2014 at 21:18 | IP Logged
|
|
|
gg,
Found the problem and got it corrected for the next version. Sorry it took so long.
In the meantime, you may be able to fix it by moving the static global variables in your CC Details by moving them towards the top of the list. Not sure if it will work but worth a try.
Dave.
|
| Back to Top |
|
| |
gg102
Senior Member
Joined: January 29 2013
Location: United States
Online Status: Offline
Posts: 245
|
| Posted: January 27 2014 at 23:11 | IP Logged
|
|
|
Thank you again Dave,
It would make my hand written "page" in the CC pretty unreadable to move all the globals, (not to mention a ton of work) so I tried something else; based on your suggestion, I changed the "start" page to a page that didn't have any globals displayed. I can't explain it, but it doesn't crash anymore. It's been running all day with no crashes. I can access all the pages (even the ones with globals displayed) as long as I don't "start" on that page, and no crashes. Seems strange, but I'm sure it makes sense to you since you found the problem.
Now for something you don't want to hear.......
If I have both my backup system running AND my primary system running, it confuses the remote CC. It seems that even though the remote CC is set up (in the ini file) to communicate only with the primary system, somehow the secondary/backup system seems to be able to send information to the remote CC thus displaying strange results. I know I can change the ports to separate the systems, and have a different remote CC for each system. It just seemed strange that a system that was NOT configured to be "talking" to the remote CC was in fact sending information to it. I'll test this further, but that's what I see so far.
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: January 28 2014 at 14:10 | IP Logged
|
|
|
gg,
Glad to here you were able to work around the issue until the beta is out.
Concerning your other question...that behaviour is expected. When the Remote CC issues a command to PowerHome, it does so direct to the specified PowerHome server via the Socket Server. Its a one to one transmission. The reverse communication (PH to the Remote CC) is via a UDP broadcast. Since you can have many different "listening" clients, we don't want to use a mechanism where we communicate with each one individually. We instead want to communicate with all clients simultaneously. This is why the Remote CC responds to ANY properly formatted UDP broadcast that it heres (including the secondary PH machine).
You could eliminate this by changing the UDP broadcast ports like you say or setting the UDP broadcast address to only the IP of the Remote CC (however this would limit you to only a single Remote CC hearing the broadcasts).
I'll look into making a mod to the Remote CC so the user has an option to ONLY respond to UDP broadcasts originating from the IP of the PH machine that the Remote CC is linked to.
Dave.
|
| Back to Top |
|
| |
|
|
Active Topics 
Memberlist 
Search 
Help
Register 
Login
PowerHome Messageboard : PowerHome Programming
Topic: ph_timedeventsctrl crashes remote CC
