Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[TomG]

Quick explanation of the problem:
Is there a possibility the interface gets "overhelmed" somehow if too many instances of macros end up being started in a short amount of time? Does the design has a build in protection for this? E.g. if more then 100 macros are started ignore events etc.
The problem I have is that somehow after some time of working correctly the interface is acting up: I see the macro being triggered in the activity monitor but nothing inside the macros gets executed. If I reset is all good again.
If I can reset the interface on a timer I'm set.

Detailed explanation
I have 5 motion sensors that control the same light. Basically I want that as long as I'm in the range of ANY of the 5 sensors the light stays on. Obviously I cannot use the capability of the motion sensor itself since let's say I get out of the range of sensor1 and get into the range of just sensor2 the first one will turn off the light while I still want it on.
To solve that I have a system of macros - aprox 10 to be exact that call each other in various ways - but all is being triggered by only one house+unit code since I put all motion sensors on exactly same house+unit and I'm using just the ON part from the motion sensor ignoring the OFF.
In this setup if you are in the range of 3 of the motion sensors at the same time and moving they might fire 20-30 events (combined) per minute for a while. Those I think in turn do create as many instances of the macros. I could not come with any other explanation that somehow all of those instances of the macros cause an internal stack overflow that halts the interface (timers seem to continue work).
In my old days of embeded programming I use to pre-fill any unused memory with "goto 0" (something like FFCE) such if the code ends up in the weeds due to stack overflow it self resets itself.

Questions or suggestions?
(1) Can I reset the interface thru a timer?
(2) Is there some technique to write the macro such multiple instances are not overhelming the interface. I already used flags such the second time a macro gets "called" is a NOP.
(3) Is there some enhanced or verbose debugging way I can see better what is going on?

[Oldtimer]

gigi:  From reading your description I think you're already quite proficient with complex macros so consider this a suggestion to get your mind working in a new direction.

I think I see a different way of handling your macros that will solve the problem.  I had a similar but simpler problem when I added a second IR detector in my back yard.  Since I didn't care if the floodlights were off  for a few seconds I only used one macro. To adapt my solution to your situation I think you'll need three macros, but let's start by my explaining my single macro first.

Both IR detectors are set to the same house and unit code.  They only trigger if it's dark, yours of course would have to work all the time.  I do allow D/N sensing, you wouldn't.  The OFF signal is set for one minute.  The macro is set to the same house and unit code as the IR detectors.  The macro acts first if the common house and unit code is received from the IR detectors and then conditionally if flag 4 is OFF and if it's after 11:00pm and before dawn.  The first thing the macro does is set flag 4, then it activates all our outside lights, then it waits 8 minutes then it turns off all the outside lights then it clears flag 4.  While the macro is running all the signals received from the IR detectors are ignored. Once it's OFF the next IR signal received starts the macro again.  (Note that if you want to deactivate this set up because someone is coming home after 11:00 you just set flag 4 manually.)

Two of your three macros would be similar to mine except they'd be on separate flags, say 4 and 5. The other difference would be that after the appropriate delay time the flag would be turned off before the "OFF" step. The "OFF" step you'd use would be a dummy module on a separate house and unit code to start a third macro that would run conditionally if flags 4 & 5 were both off.  It would turn the lights off in the room.

I think I've got this right.   Hopefully if it works you'll never have more than one copy of each macro running and a maximum of two at once. Let us know what you think of this or how it works out if you try it.

ADDENDUM: On further thought I think your ON macros should also do the following:  Both macros should turn on flags 4 and 5 as their first step then delay 5.5 minutes and turn off the other macro's flag. Then after 4.5 minutes turn their own flag off and start the OFF macro.  The IR detectors should be set to a four minute off cycle to decrease the number of RF events being transmitted by your array.

[TomG]

Thank you for your response.

I have used a similar method - basically flags such the macro does not have to rerun except the first time.

But something strange is happening. Again it worked fine for exactly 2 days before acting up. It is exactly the same code that works well for a while then does not. I clear the interface memory and reload and it works.

It is some problem with the interface because for example I see the following: one of the macros has the following sequence:
D All Units Off then
D3
D Off.

 I had both in there just to be sure the light goes off (and it is the only one on D).
After the 2 days I can see in the log:

D All Units Off
and nothing else.

This is clearly not a programming error I could have made since once it got to the one and only macro that had D All Units Off it has to go thru all the instructions.

I'm trying now with the macros run on the PC rather then the interface.

Any other suggestions are appreciated.

[TomG]

I got to the bottom of the problem. I do not have yet a satisfactory solution, but there are some usefull observations I can share.

This is what I found out (I wish it was documented):
(1) Using flags to protect from not more then one instance of a macro to be started (e.g. run macro only if flag 5 is NOT set and in the macro the first thing to do is set flag 5)  DOES NOT ensure an "atomic lock" type of protection. For some reasons AHP software does not ensure macros run syncroniously such if events get fired quickly by the time the flag is set you will have multiple instances of the macro started already. This can mess things up quickly and very hard to debug.
(2) Considering above you can end up with many runaway macros AND if this is a large number it will lock up. The software is not resilient to it. In a matter of days the software will act up and it is because of this.
(3) If the macro starts with a delay (even a delay of 0) it becomes a bit more predictible. Somebody mentioned in another post that flags are not respected unless you start with an delay. It is actually a manifestation of #1 and a delay for some reasons forces the macro to run more syncronious.
(4) To halt runaway macros - or a poor man-s way of reseting the interface is to add to all of them an "else" on a flag you do not use and in the "else" do not do anything. Once per day you can set this flag for 1/2 hour (e.g. at 3am) and it will effectively make all macros to be skipped and basically kill them. It is a way to do a "purge all delayed macros" periodically before the runaway macros build up.