Posts: 474
Threads: 61
Joined: May 2012
All,
Been working up my automation 'stuff', and ran across the complexity of automating light off/on.
I have about 5 lights that I automate for evening on and off, with an am check just to make sure we didn't override at night for more time.
I've run into the issue of timing; ie two triggers at sunset + 30 minutes often results in one not executing (or more accurately probably being processed correctely).
What I have is several sunset based on's - with variations on the time offset. As I continue to add functionality, I have to remember how many minutes I used on the previous ones so I don't create more timing issues. This also occurs for the 11:00 pm off.
Would it be better to continue with this process, or somehow write one macro for each activation/deactiviation time?
Just starting to look at CML and wanted to make sure I was choosing the most efficienct and simple route.
Thanks,
Russ
Flamin' Noobie...
Warp speed now and don't give me any of that dilythium crystal crap!
Posts: 40,483
Threads: 491
Joined: Aug 2002
I'm not sure I totally totally understand what you are trying to do. Can you elaborate a bit so that I can be sure I know what you are trying to achieve?
Dean Roddey
Explorans limites defectum
Posts: 474
Threads: 61
Joined: May 2012
Sorry, lazy Sunday and I guess I'm not typing clearly.
I've been adding a separate time event for each light I want to come on. Since I want them to come on at roughly the same time, I create sunset events with offsets of 30 minutes, 31 minutes, 32 minutes etc.
I think that having multiple events at sunset + 30 minutes is clogging the upb communications.
I quickly rewrote them by using the system.wait command with 5,000 milliseconds between each lighting signal. I'm assuming that the system.wait command will do just that, pause the action sequence until the wait is complete.
Russ
Flamin' Noobie...
Warp speed now and don't give me any of that dilythium crystal crap!
Posts: 40,483
Threads: 491
Joined: Aug 2002
Is it just one light in each minute offset group, or a set of lights in each group? I doubt that there actually being a minute between them would be a problem. But if you try to send multiple commands too fast in the same action the UPB network might clog up.
There isn't a System:Wait command, I don't think. But you can just use System:

ause to put a short delay between lighting commands in the same action. Of course if multiple actions ever did run at once, it would still be a problem. Ultimately the UPB driver should be throttling commands, but it apparently doesn't, from what I've read of other folk's comments.
Dean Roddey
Explorans limites defectum
Posts: 474
Threads: 61
Joined: May 2012
09-30-2012, 04:07 PM
(This post was last modified: 09-30-2012, 05:47 PM by rtarver.)
It was only one light per timed event, but multiple events at the same time. Thus, the small offsets of 1 minute, 2 minute, etc for the different timed events.
We'll see how it works in about 45 minutes
Russ
Update:
That didn't work so well. The second action kicked off, but the third didn't. I changed all the system::waittimers to system::pause, and the test worked fine with a limited delay fo 5 seconds. The sequence will have two 15 minute delays, so we'll see how it works tomorrow evening. I'm assuming the system::pause is only for the existing action sequence and doesn't put the whole system into a pause state.
Russ
Flamin' Noobie...
Warp speed now and don't give me any of that dilythium crystal crap!
Posts: 1,035
Threads: 97
Joined: Aug 2008
As you said, two UPB commands in a row usually works, three can be a problem. I typically put 600ms between UPB commands system::wait(600) and I think that works most but not everytime. 5 seconds is a bit of overkill, but the real time is probably somewhere between the two. In theory a UPB commands takes from around 250ms to 500ms, but that is just theory, and it can take a bit longer.
The way I do actions, several might trigger at once, so simple delays don't always work.