X10 Community Forum
🖥️ActiveHome Pro => ActiveHome Pro General => Software Problems & Bugs => Topic started by: LAF on August 31, 2017, 01:48:45 PM
-
I don't know if this has been fixed as a search for "looping macros" only turns up old, previous AHP versions, posts.
Anyhow, I have run a macro experiment and am getting poor results. My program consists only of two simple macros each of which delays for 2 seconds and then triggers the other via an appliance On command. So, it cycles back and forth between the 2 macros and seems to continue indefinitely. Until however, a command is received from a remote controller, either via power line or RF, not matter what HC the remote is set to. When that happens, the macros stop (but not always if only one command is received, sometimes two or three are required i.e. it seems kind of random in that respect).
Now, I see no logical reason why any of that should happen so I'm wondering if the past admonishments against using looping macros are still valid? If only a single macro which triggers itself after some delay was being used, I can see why that might cause problems as the macro would be re-entered repeatedly without ever exiting and causing a stack overflow or some-such thing but the two macros triggering each other do not do that so I don't see why it shouldn't work.
-
Update: Tried it with only one macro triggering itself (after 2 sec delay). It's now gone over 1200 iterations w/o stopping (but also will halt if a remote command is executed as the two macro case).
-
OK, I think I've answered the question why other commands are stopping the macros. The macro trigger commands are on the power line and the remote commands are stepping on them. This even happens with an RF remote command as the resultant command is also put on the power line(??).
This, if the case, is IMO bad news as it implies that anything triggering a macro, a remote command or a command from another macro, can be randomly defeated. :( B:(
It looks like X10 does not handle "party line" communication very gracefully.
-
There are situations where one would wish looping macros.
But you must create an exit like using a flag, time, module condition
If you only have polite transmitters you shouldn't have signals stepping on each other
-
What's a polite transmitter?
I still don't see why an exit is a necessity - my test macro(s) seem to run w/o problems (other than the signal collisions but that could occur with looping macros or not).
-
Polite Transmitters. Are modules that hold power line transmitting if there is a X10 power line transgression in progress.
The RR501 and PAT01 are polite transceivers. TM751 and PAT02 with no power line receivers in them are not. They will stomp on a power line signal in progress.
I believe the CM15A and security consoles also are polite
-
Polite Transmitter Protocol
When a transmitter has a message it wishes to transmit, it must wait for access to the powerline for either 8, 9, or 10 half mains cycles - during which the line must have been continuously clear of data '1' bits. If a '1'bit is detected, it must restart it's access timing and wait for another 8, 9, or 10 cycles.
After line access has been achieved, the transmitter must check the line during the transmission of a '0' bit (no carrier) to see that no other transmitter is transmitting. If a collision occurs, the transmitter must abort its transmission immediately and again go though the line access procedure.
The choice of 8, 9, or 10 half cycles is chosen randomly for each line access attempt.
The CM11A, CM15A, RR501, PAT01 and most, if not all, security consoles are polite. The TM751/PAT02 are not polite as they do not listen to the powerline.
The PL513/TW523 (and PSC04/PSC05) are not polite and third party controllers that use them cannot be polite, nor detect/avoid collisions, as their report of powerline activity is delayed for 11 cycles of the powerline.
-
stevenR posted an example of a looping macro and how to exit it here:
http://forums.x10.com/index.php?topic=14912.0
-
I still don't see why an exit is a necessity -
Exit stops the looping, otherwise the loop continues and the powerline is flooded with non stop PLC. In your first post you create a 2 second window between macros which is the only time an X10 command can get back to the CM15A to stop the loop. The reason yours does not stop reliably "(but not always if only one command is received, sometimes two or three are required i.e. it seems kind of random in that respect)."
The "randomness" is because if the X10 command does not hit that 2 second window, it does not get received and only corrupts the PLC being transmitted.
-
Dave et al, thank you for the info re impolite devices transmitting on the power line. I see now what the problem is.
In any case, what if you want the loop to go continuously (there are programming instances where you might want to do that)? And, the fast looping I set up as a test was only done that way to try to see if there was a max number of iterations the loop could make without breaking something (I ran it up to about 3,000 iterations without a stoppage in one try). In real life, I would expect the looping to maybe take place much more slowly, so the power-line isn't burdened unduly, but I would want it to run non-stop. Even so, AHP needs a way of internally triggering a macro by another macro (or by itself) so the power-line is not involved (or so it seems to me).
-
In any case, what if you want the loop to go continuously (there are programming instances where you might want to do that)? In real life, I would expect the looping to maybe take place much more slowly, so the power-line isn't burdened unduly, but I would want it to run non-stop.
The problem I see, is putting unneeded PLC signals on the powerline, which means, on a very regular basis the macro will be sending out PLC, busying out the power line rendering your CM15A receiver deaf to any other X10 commands for a second or so (length of a command). I could foresee many times when you wanted to turn on a lamp with a remote, or a motion sensor sending an ON signal, and nothing happens due to signal collisions. Don't know what your goal is, but if you are trying to turn something on and off at short intervals 24/7, then X10 is a good way to start and stop the flashing cycle, but not a good way to make the cycle (if that makes sense...been a long day for the ole geezer).
This is interesting.