Jump to content


c4Forums Member
  • Content count

  • Joined

  • Last visited

  1. Timing of C4 code execution

    That makes sense, thanks. I will give it a shot.
  2. Timing of C4 code execution

    Thanks, @Cyknight. This is really helpful. Let me provide a bit more background on the specific problem, the revised solution that I based on the discussion from this thread, and one remaining issue that is puzzling me. I am writing a script to lock all the doors in my house and then arm the security system. Crucially, if there are any errors in the process of locking the doors, I want the script to stop, without arming the system. I already have a macro that locks doors, checks for errors (e.g., jammed deadbolts), and alerts the user if needed. As you guessed, I sometimes use this macro on its own, but I also want to use it in conjunction with arming the alarm in some cases. What I ended up doing was adding the alarm arming macros to the end of the house lock macro, but they are called only if a "security system arming timer" is running. This timer tells me whether or not I am in the process of arming the system, or just locking the doors without doing anything else. This part works efficiently and reliably -- thanks to the advice here. Here is my remaining problem. I have Yale Real Living door locks. I use the "lock status" device variable on the Yale driver to check for errors. This variable takes on the values of 0 (unlocked), 1 (locked), and 2 (jammed, faulted, etc). After I issue the lock command, I check to make sure the lock status variables are all equal to 1 before proceeding with the script to arm the security system. However, when a lock command is issued, the driver immediately switches the "lock status" variable to 1 -- before it's actually fully locked. If an error is detected, it then switches the value (again) to "2." Consequently, even after observing the lock status variable change to "1," I have no way of knowing in advance whether or not the script should be stopped. My workaround is to issue the lock command, delay for 7 seconds, and then check to make sure the lock status still has a value of 1. Based on empirical testing, this seems to be enough time for the fault to register, but I don't like this solution very much. For one thing, it's inefficient. For another, I'm skeptical that the timing is going to be identical in all cases. I have been banging my head on this last issue, and I can't see a cleaner solution. If the lock status variable changed states once at most, I could use the solution proposed by @msgreenf. But I don't see how to do that here, since the variable might (or might not) change its value twice in the process of trying to lock. Any ideas? Thanks a lot.
  3. Timing of C4 code execution

    Of course! That is genius. Thanks!
  4. Timing of C4 code execution

    Thanks, @Cyknight and @mikeryder. That makes total sense. I want my macro to finish running before the script continues. To do this, I added a delay after the macro. As further insurance in case the macro happens to run slow, I added a final line to the macro that sets a "macro finished" variable equal to true. I then added a series of nested if statements after the macro that check if the macro has finished. If it hasn't, it delays a few seconds, and then checks again, and so on. It's a super clunky solution, for sure. Any other thoughts on a more elegant approach -- short of pasting the macro code directly into the script?
  5. I've been wondering about the timing of C4 code execution in two related contexts. Macros When I call a macro, does C4 execute the entire macro before going on to the next line of code, or does it do something else? E.g., suppose I have code like 1. Lock Door A 2. Execute Awesome Macro 3. Lock Door B Will the entire Awesome Macro be executed before the command to lock Door B is issued? Changes in variable values A slightly different but related question concerns variables. Suppose I have a variable called "Cool Variable." Also suppose I program a trigger that is tied to changes in the value of this variable -- something like: When Cool Variable value changes: If Cool = True, then Play Sound If Cool = False, then Stop Now, suppose that the starting value of Cool is false, but I have code elsewhere that looks like: 1. Set Cool = True 2. Flash Foyer Lights What is the order of operations here? Will the sound always play before the lights flash? Will the order vary from one time to the next? Thanks very much for any insight.
  6. Holy Cow! That was easy, and a much better solution too. Thanks a lot, @alanchow.
  7. I figured I'd provide a postscript on this after a weekend spent working on this problem. I came across the Chowmain Variable Manipulator Driver, which is pretty cool. In fact, this driver -- along with a lot of sweat equity and chewed pencils -- allowed me to write code that converts the Unix timestamp into a date that we ordinary humans would understand. Unfortunately, however, I ended up running into a frustrating roadblock that stopped me in my tracks: I was unable to figure out how to get the current date into a Control4 variable. After banging my head on that problem unsuccessfully for a while, I gave up and went for a simpler solution that I think will get the job done -- I take a temperature reading at 7pm, and then a follow-up reading at midnight. If the two temperatures are different, I conclude the driver is not retrieving forecasts from Wunderground. Not as direct a solution, but will probably work pretty well.
  8. I use the Wunderground driver connected to my personal weather station; when the temperature exceeds a certain threshold, we run a Rachio zone to cool off some of our plants. From time to time, Wunderground experiences an outage for one reason or another. When that happens, the Wunderground driver remains "stuck" on the last downloaded temperature, and this can sometimes cause problems with the programming. I'd like to recover from this situation. I know that the Wunderground driver has a device variable called "Updated" that records the time of the last update. What I'd like to do is periodically check whether the update is recent, and if it isn't, pause the automatic sprinkler routine until the driver starts working on. My problem is that the "Updated" variable seems to be formatted in terms of a Unix timestamp code, and I don't know how to convert this to a human date in C4, or even use it in C4 programming. (E.g., when the driver is last updated on October 22, 3:39:25 PM Pacific, the variable reads 1508711965.) I feel like I must be missing something simple -- any advice on how to convert the timestamp code to an actual date/time that I can use in programming? Thanks a lot.
  9. Cool LED and backlight ideas -- Maybe I will steal some of those as well! Thanks a lot for the advice. I will try adding the "backup command," and if that doesn't help, I'll investigate a ZigBee extender. I am thinking/hoping that it's not the ZigBee network, as this is literally the only situation in which my switches don't respond quickly and flawlessly. Now that I am thinking harder about this, I believe the errors only occur when we disarm the system from armed away after dark; that happens to be the case in which the system is processing the largest number of commands. Maybe it is just an issue of overloading the C4 system, and giving it a few extra seconds to sort everything out might help. Maybe that's wishful thinking, in which case I have a good backup plan! Thanks again.
  10. I use the LED Wizard Driver to change the LEDs on my light switches to reflect the status of the security system. When the system is disarmed, all the LEDs turn to blue. When armed, the LEDs turn to red. For the most part, this works well. However, about 10% of the time, the LED change is incomplete. In those cases, about 5-10 switches have unchanged LEDs. (There are about 75 or so switches in total.) They are not always the same switches, so the problem doesn't seem to be specific to a set of switches. To address the issue, I'm thinking about adding a second, identical LED wizard command, 5 seconds after the first. Is this a good idea? Are there other approaches that might work better? In case it matters, I am still on OS 2.9.1. Thanks
  11. Thanks to everyone for sharing experiences and suggestions. I'll see if we can replace this with an actual dimmer switch. We have one of those in an outdoor location, inside a weatherproof box, and it works perfectly. Maybe that is the path of least resistance.
  12. We have a C4 wireless outlet dimmer that runs some outdoor lights. This outlet keeps going offline. It is housed in a plastic weatherproof box, and is located about 18-20 feet from the nearest bank of (indoor) C4 light switches -- there is one exterior (wood and stucco) wall separating them. (While it is located under a covered porch, the area does get water during heavy rains, so some type of weatherproof enclosure is necessary.) This dimmer regularly goes offline. My dealer will re-identify it, which always works on the first try. After the initial re-identification, the Zigbee signal strength initially shows 3 out of 4 bars. And then a few days later, it's back to being offline. My questions are: 1. Are the range problems to be expected in this situation, or is there something wrong with the outlet? 2. If the range problems are typical, are there steps we can take to improve things? Thanks very much.
  13. Matching 5-gang faceplate

    Thanks for all the suggestions. I had not heard of the Legrand Radiant before and look forward to checking it out.
  14. Hi, We have switched almost all the faceplates in our home to the screwless C4 variety. However, we have two pesky 5-gang faceplates, and our dealer informed us that C4 does not make faceplates in that size. Does anybody have suggestions for a screwless third-party faceplate that might look at least passable when placed near the C4 faceplates? Thanks for the help.