| Author |
|
TonyNo
Moderator Group
Joined: December 05 2001
Location: United States
Online Status: Offline
Posts: 2889
|
| Posted: July 06 2014 at 20:26 | IP Logged
|
|
|
Dave jumped on my server and found my main problem. Thanks Dave! 
I have at least one macro that came in empty, though. Any patterns discovered yet so I can check for others?
System Message Macro K DOOR CLOSE does not exist or has no detail.
|
| Back to Top |
|
| |
BeachBum
Super User
Joined: April 11 2007
Location: United States
Online Status: Offline
Posts: 1880
|
| Posted: July 07 2014 at 00:02 | IP Logged
|
|
|
The ones I have found are missing the underscore and any reference to it.
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
BeachBum
Super User
Joined: April 11 2007
Location: United States
Online Status: Offline
Posts: 1880
|
| Posted: July 07 2014 at 00:13 | IP Logged
|
|
|
BUG REPORT: The pull down of Global Variables "{" does not work in Formula Builder. The System Variables "[" do.
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
BeachBum
Super User
Joined: April 11 2007
Location: United States
Online Status: Offline
Posts: 1880
|
| Posted: July 07 2014 at 14:49 | IP Logged
|
|
|
dhoward wrote:
Pete,
I looked at your logs and I can see that PH says it lost comms with the PLM so it did a restart. I don't really see anything wrong with the Insteon portion of the log and would seem to correlate the events in the eventlog.
|
|
|
I found the culprit. I send an Insteon appliance module a pull down ON with 255 followed immediately by a ph_getinsteonlevelrt at the same module. By inserting a wait fixed the problem. The real problem is this a false PLM indicated failure and somehow should be not reported as a PLM failure. This macro was not changed from previous releases. As I said earlier the failure walks on the next events and you don't see them in the log. Hopefully this is enough documentation to get to the source.
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: July 07 2014 at 19:34 | IP Logged
|
|
|
BeachBum wrote:
| BUG REPORT: The pull down of Global Variables "{" does not work in Formula Builder. The System Variables "[" do. |
|
|
Pete,
Found and corrected this error. Thanks for reporting it  .
Dave.
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: July 07 2014 at 19:39 | IP Logged
|
|
|
BeachBum wrote:
I found the culprit. I send an Insteon appliance module a pull down ON with 255 followed immediately by a ph_getinsteonlevelrt at the same module. By inserting a wait fixed the problem. The real problem is this a false PLM indicated failure and somehow should be not reported as a PLM failure.
... |
|
|
Pete,
Not sure what you mean by "pull down ON with 255". Are you controlling an appliance module from the Device Status screen (this is the only place I can think that would have a pulldown)?
The ph_getinsteonlevelrt command...is that called from the boolean field of a trigger perhaps?
Let me know,
Dave.
|
| Back to Top |
|
| |
BeachBum
Super User
Joined: April 11 2007
Location: United States
Online Status: Offline
Posts: 1880
|
| Posted: July 07 2014 at 21:28 | IP Logged
|
|
|
Dave, sorry about the lack of detail. I'm use to you reading my mind. I am referring to a macro where I select Command = Insteon and ID = to my device with a Dim set to 255. The next line is a Formula with RT in it. Not in the Boolean field.
HTHs....
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
BeachBum
Super User
Joined: April 11 2007
Location: United States
Online Status: Offline
Posts: 1880
|
| Posted: July 07 2014 at 21:40 | IP Logged
|
|
|
Dave, I don't know where I going with this one yet but anything to do with 214 talking to 215 using Socket Server is running extremely slow on response. Like 30 seconds. For now I am converting over to filemonitor for faster triggering from slave systems. Hope you're reading my mind on terminology. I haven't done anything to Socket Server and maybe I should with the new release.
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
BeachBum
Super User
Joined: April 11 2007
Location: United States
Online Status: Offline
Posts: 1880
|
| Posted: July 07 2014 at 21:59 | IP Logged
|
|
|
Lee, if your out there. Got a hint what this is about?
2014-07-07_215856_EVENTLOG.TXT
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: July 07 2014 at 23:08 | IP Logged
|
|
|
BeachBum wrote:
Dave, sorry about the lack of detail. I'm use to you reading my mind. I am referring to a macro where I select Command = Insteon and ID = to my device with a Dim set to 255. The next line is a Formula with RT in it. Not in the Boolean field.
HTHs.... |
|
|
Pete,
I gotcha now. My next question would be how is the macro called? PowerHome should have no problem with this scenario (I tested on my system without issue) and I suspect some king of unforeseen interaction occurring.
Dave.
|
| Back to Top |
|
| |
BeachBum
Super User
Joined: April 11 2007
Location: United States
Online Status: Offline
Posts: 1880
|
| Posted: July 08 2014 at 11:06 | IP Logged
|
|
|
dhoward wrote:
| My next question would be how is the macro called? |
|
|
I think I'm going to get I told you so... Well anyway with further testing the results are in. With wait removed that fixed the problem the results are as follows:
Triggers are tripped by old Insteon desktop controller with button number 4 ON.
This works with triggers:
IN THE ACTION:
ph_postexequeue(2,2,'ph_macroparm "MBR_TV_ON",0,0,0,0,"ON")')
ph_macroparm("MBR_TV_ON",0,0,0,0,"ON")
If executed manually in Formula Builder Boolean with Verify:
ph_macroparm("MBR_TV_ON",0,0,0,0,"ON") + ph_macroparm("trigdisable",5,0,0,0,0) + 1
ph_macroparm("MBR_TV_ON",0,0,0,0,"ON")
*****************************************
This fails with triggers:
IN THE BOOLEAN:
ph_macroparm("MBR_TV_ON",0,0,0,0,"ON") + ph_macroparm("trigdisable",5,0,0,0,0) + 1
ph_macroparm("MBR_TV_ON",0,0,0,0,"ON")
But wait if I insert the WAIT in the macro everything in the Boolean works fine. Never the less I don't believe it should show up as a PLM error.
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: July 08 2014 at 12:31 | IP Logged
|
|
|
Pete,
Makes sense now and would definitely cause problems. Typically you would never want to execute anything in the boolean field that may in some way trigger actions on a controller. Ive looked into the code before to see how I can detect the error as a result of this type of code and an actual controller error and its pretty difficult since the controller object is event driven and unable to determine if an event originated internally vs externally. I'll look again and see if there is anyway I can prevent this as showing as a controller error.
In the meantime, based upon what I think you're trying to accomplish, try this:
In the boolean field:
ph_macroparm("trigdisable",5,0,0,0,0) + ph_postexequeue(2,2,'ph_macroparm("MBR_TV_ON",0,0,0,0,"ON")' ) + 1
This should be totally safe as long as the trigdisable macro in no way triggers controller communication. The ph_postexequeue will have your action occurring ahead of any other queued actions yet still follow good PH programming practices of routing everything through the execution queue (the Boolean field formula is never routed through the execution queue which is why its so dangerous to place certain code there).
Let me know if it works for you.
Dave.
|
| Back to Top |
|
| |
BeachBum
Super User
Joined: April 11 2007
Location: United States
Online Status: Offline
Posts: 1880
|
| Posted: July 08 2014 at 14:08 | IP Logged
|
|
|
dhoward wrote:
follow good PH programming practices of routing everything through the execution queue (the Boolean field formula is never routed through the execution queue which is why its so dangerous to place certain code there).
|
|
|
OK, I forgot.. No stupid me didn't even think of it until you asked where the macro was being called from then the big bright light that hangs over Ken's head  lit.
Interesting to disable the trigger first. While you're on the subject can a trigger be queued ahead of another identical trigger? Meaning the same action causes two different things to take place. Or is it best to cascade them in the same trigger?
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
GadgetGuy
Super User
Joined: June 01 2008
Location: United States
Online Status: Offline
Posts: 942
|
| Posted: July 08 2014 at 18:46 | IP Logged
|
|
|
Quote:
The big bright light that hangs over Ken's
head |
|
|
Peter- That's not a bright light you are seeing, it's my
bald spot! 
__________________
Ken B - Live every day like it's your last. Eventually, you'll get it right!
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: July 08 2014 at 19:09 | IP Logged
|
|
|
Pete,
No problem. Its easy to forget and with the new ph_postexequeue function allows you to get the same functionality safely.
You can have multiple triggers set to fire off the exact same conditions. You can control the order that they'll fire by their ID (if multiple triggers fire off of the same condition, they'll be checked in alphabetical order based upon their ID).
Its primarily based upon personal preference which method you use. A single trigger calling a macro with multiple actions, etc. vs multiple triggers with their own actions. There wouldnt be much difference in efficiency however the single trigger may be a little cleaner for some people.
Dave.
|
| Back to Top |
|
| |
BeachBum
Super User
Joined: April 11 2007
Location: United States
Online Status: Offline
Posts: 1880
|
| Posted: July 08 2014 at 20:59 | IP Logged
|
|
|
Ken, all this time I thought it was your brilliance showing.... Dave, thanks again for your elegance at explaining this terminology in layman's terms. But you know I'll bug you on PLM Error......
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: July 08 2014 at 22:35 | IP Logged
|
|
|
GadgetGuy wrote:
2.1.5 Bug Report
When the "Reinit" button in PH is used it does NOT fire
TRIGGER TYPE=System Process
TRIGGER ID=Startup
This trigger works OK when PH starts up by executing the
the .exe, but fails to Trigger on Reinits (which used to
fire the trigger OK)
|
|
|
Ken,
Ive verified this issue. However, I believe the current methodology is now correct where it was in error before. On a reinitialize, the System Process|Reinitialize trigger will fire. On a fresh startup you get the System Process|Startup trigger. In previous versions, I fired both the startup and reinitialize triggers (by mistake) on a reinit.
Let me know if you think the new functionality is correct or if I should re-enable the old functionality where both triggers will fire.
Dave.
|
| Back to Top |
|
| |
gg102
Senior Member
Joined: January 29 2013
Location: United States
Online Status: Offline
Posts: 245
|
| Posted: July 08 2014 at 23:15 | IP Logged
|
|
|
Well, THAT explains it!
I was just working on that one. I couldn't figure out why my app wasn't restarting on a reinit. I was searching all over. Now, I know.
I agree with Dave on this one also.
|
| Back to Top |
|
| |
GadgetGuy
Super User
Joined: June 01 2008
Location: United States
Online Status: Offline
Posts: 942
|
| Posted: July 09 2014 at 06:31 | IP Logged
|
|
|
Dave-
I think the old method was better (but that said see also
comments below). As "gg102" expressed, and in my case
where I re-establish the presence and position of windows
that were open, as well as fire a lot of initialization
macros to set default states.
Such actions are often very appropriate after
configuration/setup/macro work has been done with PH and
one wants to then re-start and establish known conditions
again.
Alternatively may I suggest a solution that solves the
problem. Add a new "System Trigger ID" of
"Startup|Reinit" that triggers on either event. Of
course, users could just create two separate Triggers,
one for Startup and another for Reinit.
I also suggest that whatever is done, this change should
be published in the Release notes so users are aware they
may need to change their code.
*** For now, I have done as the venerable BeachBum
suggests, and just entered two Triggering Events. One
for Startup and one for Initialization. 
Edited by GadgetGuy - July 09 2014 at 12:03
__________________
Ken B - Live every day like it's your last. Eventually, you'll get it right!
|
| Back to Top |
|
| |
GadgetGuy
Super User
Joined: June 01 2008
Location: United States
Online Status: Offline
Posts: 942
|
| Posted: July 09 2014 at 06:35 | IP Logged
|
|
|
This last issue, with the Triggers, leads me to a
Improvement Suggestion (especially after having to
construct a major trigger set to support my Thermostats).
The same Copy/Paste editing provided for the Macros (which
is WONDERFUL) should also be provided for the other Tables
such as Triggers. 
__________________
Ken B - Live every day like it's your last. Eventually, you'll get it right!
|
| Back to Top |
|
| |
Active Topics 
Memberlist 
Search 
Help
Register 
Login
PowerHome Messageboard : PowerHome General
Topic: PowerHome 2.1.5 Released!!
