kclenden

Given that he refers to "small buttons" and then calls them button A and button B, I'd assume it's a six button kepad with the first two small middle buttons being used. Edit: But I do know what they say when you assume things.

That would be very strange. I can't even come up with a theory as to why that would happen. Now I'm gonna have to try it. ?

But couldn't you create a scene whose ON level for every device is 0% (or OFF)? Then when the scene is turned ON everything is turned OFF. And when the scene is turned OFF everything is turned OFF. So even though the scene is responding to both ON and OFF commands it's acting like it's receiving OFF commands.

Does the LED care about polarity? If so, do you have + and - wired correctly? Have you tried wiring the transformer directly to the LED?

Interesting. I would have sworn that I had opened the battery cover since linking my MS's. One of them is powered by USB, so I likely would have unplugged it before opening the battery cover, but the other one is battery powered. Maybe I haven't opened that one since linking it. I'll have to open it up and see what happens. ?

There are two things to consider about a program conditional: What triggers the IF to be evaluated What causes the IF to be TRUE (and run the then) or FALSE (and run the else) Whether the IF evaluates to TRUE or FALSE only matters if the program is triggered to evaluate the IF Let's consider what triggers the IF in your program to be evaluated: If it's 10:00PM Maybe if $Garage_Door changes to a value of 1 from some other value. I can't tell for sure because I can't tell whether $Garage_Door is a state variable or an integer variable. Only changes to state variables cause a program to trigger. A lot of people use a convention whereby they start a variable with an "s" if it is a state variable or an "i" if it is an integer variable. So depending on which type it is, your variable would either be $sGarage_Door or $iGarage_Door. You right-click on the program and choose "Run (If)" Now let's consider what causes the IF in your program to be TRUE: When it's 10:00PM AND when $Garage_Door is equal to 1 Based on all of the above, if we assume your variable, $Garage_Door is a state variable then the IF will trigger, and either the THEN or the ELSE will run and you should receive one of your two text messages under these to conditions: It's 10:00PM $Garage_Door changes to 1 from some other value If $Garage_Door is an integer variable (which is what I think you want), then the IF will trigger, and you should receive one of your two text messages, only once a day at 10:00PM. I'm unclear about whether you're saying that you tried the program and it didn't send a text message. If that's the case then I can think of the following possible causes: Your outbound communications are not working. You can check this by right-clicking on the program and choosing "Run (Else)". You have accidentally disabled the program. Disabled programs have a small red circle with a slash on their icon.

Yeah, I reported that in a different thread. The ISY gives priority to Insteon communication, so lower priority tasks queue up until the ISY has no more Insteon communication to handle. I don't think that there is simply a delay in recording them in the log, I think they don't actually execute until the time displayed in the log.

I don't think the MS II has a heartbeat. I'm assuming this is because you can query it for "Battery Level". I'm guessing you have the MS II set to "Report: On Only". Since the sensor never reports OFF, the ISY doesn't know when the sensor internally switches to OFF, and thus the ISY always reports the state as ON. Interesting. My MS II doesn't show any status for "Tamper". It's not ON or OFF, just blank. This is for the same reason the MS II always shows a status of ON. The TriggerLinc sends an ON every ~24 hours on the "Heartbeat" node. It never sends an OFF. So the ISY always reports the "Heartbeat" as ON. The only way to know if you're receiving heartbeats from the TriggerLincs is to setup a program that looks for the "Heartbeat" node to be "switched on". I have a program that looks for the heartbeat to be switched on and then starts a 25 hour WAIT. If another switched on is received with that 25 hours, the count starts again. If one isn't received, the line after the WAIT sends me a text message saying that a heartbeat has been missed. That's what my TriggerLinc shows as well. This would indicate that the ISY has never received any kind of signal on the node from the TriggerLinc so I'm not sure what it's used for. Edit: I take that back. I think the TriggerLinc is basically the same thing as the current Open/Closed Sensor. Given that, I think the "Closed" node is supposed to work in what is called a "Multi-Scene" mode. In the "Multi-Scene" mode what is supposed to happen is that when the door is opened, an ON is reported on the "Open" node and when the door is closed an ON is reported on the "Closed" node. This gives you more advanced control over what happens when the door is closed. In the "Default" mode, since the "Open" node changes immediately when the door is opened and closed, if you have a light linked to the sensor it will come ON and go OFF immediately with the door state. A lot of people want the light to come on immediately when the door is opened, but not go off immediately when the door is closed. The "Multi-Scene" mode allows this because you can link the light to the "Open" node, but not link it to the "Closed" node. In this case the light comes when the door is opened, but does not go off when the door is closed unless a controller, like the ISY, turns it off. The problem is that the "Multi-Scene" mode cannot be programmed by the ISY. There are questions about whether the mode is even still supported by the sensor. My TriggerLinc acts like your three. Your fourth one is interesting. I'd be interested in seeing the program the fourth is used in because I don't know how it can be reacting to an OFF if your ISY never sees an OFF.

As you reported in another thread, the changes show up in the Event Viewer. I can confirm that I don't see the variable changes in my log. One thing to keep in mind, though, is that only a change to the variable appears in the Event Viewer. So if the THEN merely did $sTemp = 1 and you ran the THEN three times in a row, you would only see the first variable assignment in the Event Viewer and not the following two. That is why when I use a state variable to track program execution, I assign a value that I'm tracking and then immediately assign 0 (i.e. $sTemp = 1 followed by $sTemp = 0).

I always look at them in the Event Viewer so not sure if they show up in the log. But even without looking at the Event Viewer, you can look in the "Variables" tab, at the "Last Changed" time.

If you're willing to go to the trouble of trying to wire in a solar charger, couldn't you just create a supersized battery? Take six batteries and wire them in parallel and wouldn't it last six times as long? You'd still have to change batteries, but not nearly as often.

The only way you're going to know is to test it with a program. Set one variable in the THEN and another variable in the ELSE. Then you can check the time those variables are changed. Still, as mwester says, there's no guarantee that behavior won't change in the future. Case in point - there is currently a bug using "Sunset + x". If "Sunset + x" is before midnight then it works as expected (i.e. it runs every day at Sunset +x). If "Sunset + x" goes past midnight then it only runs every other day at Sunset +x.

Even easier... you don't have to do anything. I just tested this on my battery operated MS II. The next time the MS II wakes up (heartbeat or motion), the ISY will complete the calibration on its own and the red exclamation will disappear.

Um, wouldn't that be 49 years?

There you go exaggerating again. More like 3.25 years or only 3 years if you're rounding. ?

Is this the post you mean?

Thanks. I've only been using v5 for about six months, and I keep forgetting about some of the new features. Capturing the "Seconds since start of day" when a device is turned on, and then subtracting it from "Seconds since start of day" when the device is turned off would give you the number of seconds the device was ON. You'd have to account for possibly going past midnight, but that wouldn't be too difficult.

It depends on what you mean by usage. If you mean power consumption, then no. If you mean keeping track of how many times something is turned on/off, or how long something remains on, then yes. Without changing anything at all, you could use a macro to pull the information out of the ISY log. If you want it to be more interactive, you could create some integer variables, and then use programming to increment those variables while a device is ON, and stop incrementing when the device is OFF. Depending on how often you setup the programs to increment, you could track device ON time to the minute. Edit: You could even come up with crude power usage by measuring the power usage once, and then using that as a multiplier.

Old links won't be a problem if you perform a factory reset. From the Smarthome Quick Start Guide: "To reset the Power Line Modem to its original factory settings, unplug it from the wall outlet and wait 10 seconds. Press and hold its SET button, plug it back in, continue holding the SET button for 3 seconds and release. After several seconds, the Status LED will turn on, indicating a reset is complete."

Thanks for the update. Others with similar problems will benefit from your follow-up.

My understanding of Ramp Rate is that it represents the time to go from 0% to 100%. So if the light is already at 30% and you then command it to go to 100%, I would expect it to take only about 6 seconds (70% of 8.5 seconds) to get to full brightness.

The null is associated with the log type of Start. It means that your ISY rebooted. The only times my ISY has rebooted was either when I commanded it to reboot, or as the result of a power failure. Since you weren't there, I'm going to guess your ISY rebooted because of a power failure. The following six lines in the log show your ISY querying devices for their status. It's not actually commanding them to do anything, but just finding out what state there currently in. That's what the Status Off means. The On Level 100% and Ramp Rate 8.5 seconds mean that the switch is configured to come on to 100% with a ramp rate of 8.5 seconds if you actually tap it. Your ISY queries all of the devices for their status after a reboot because you have Query at Restart checked within the System box on the Configuration tab. If you uncheck that box, then the ISY will not query devices for their status each time it reboots.

UDI is usually pretty economical with their programming technique, especially given all the effort they've been devoting to get v5 to a production state. So I wonder if there isn't an underlying reason why the "on level" adjustment for a scene is present. Maybe it's allowed with Zwave or Zigbee? If it's allowed by another protocol, I could see why they left it in for Insteon, as limiting options by protocol would probably be low on the list of things to implement when you're trying to get out your first production release of a new firmware version.

I'm not entirely sure what your goal is, so I'll answer two scenarios: First, let's say you have three lights in a scene, and you set the scene to turn them on to 100% brightness whenever a switch is tapped, and then you tap one of the switches to turn on the lights. Now, while the lights are ON, you want to adjust their brightness to 50% at 10:30pm (i.e. bring all three lights down to 50% brightness). You can't do that with the scene that you used originally. You'd either have to send a command to each device telling it to dim to 50%, or you'd have to have a second scene already setup to turn those devices on at 50% brightness, in which case all you'd have to do is turn on that second scene. Second, let's say between 10:30pm and sunrise you want the three lights in your hallway to only brighten to 10% instead of 100% whenever any of the switches is tapped. Since the ISY isn't involved when any of the switches communicates directly with the lights, you have to "adjust" the scene ahead of time. That you can do by using the "Adjust Scene" option. Essentially, at 10:30pm, you would individually adjust the desired scene brightness for each responder (i.e. light) per controller (i.e. switch). So if you had a 3-way switch configuration controlling three lights, you have to make 9 scene adjustments. Once that was done, whenever any of the switches was tapped, the lights would come on at 10% brightness. Then at sunrise (the ELSE of your program above), you have to make another 9 scene adjustments to return the programmed scene level to 100%. In the example above, your lights and switches are probably synonymous (assuming each switch directly control a load), but the end result is the same.

I think that's true for most of the things people might want to program. But when it comes to having a selection of programs that you want to enable/disable based on a common set of conditions (admittedly probably an uncommon need), I'll take the simplicity of a folder any day. Reminds me of having to program in LISP in college. If you needed to process a list of items, nothing could be simpler than a LISP program. If you needed to do anything else, LISP would lead you down a dark, dangerous path that would almost certainly lead to derangement.