Algorithm

Hello ergodic, If Kit Motion.Body.S1.Sub is enabled, then it should run either Then or Else (as 'Kitchen Island' is, or is not, less than 50%, respectively) as soon as Kit Motion.Body.S1 becomes true (which happens as soon as its Then is called--in this case from Kit Motion.Cond.S1). However, Kit Motion.Cond.S2 also becomes true as soon as Kit Motion.Body.S1 is true, and then calls Kit Motion.Body.S2 which will make Kit Motion.Body.S1 false. It is possible that this could create a race condition, though I doubt it (but Michel or Chris should be able to say for sure). However, it would be easy to test simply by removing the call. I also use a combination of INSTEON and X-10 motion sensors (though with a V572RF32 rather than an EZX10RF--what is your satisfaction level with that device?). I do agree that the smaller package is less obvious/distracting. And yes, you can sure buy a whole lot of them at extremely low prices if you grab the sales! The two do operate quite differently however, especially with regard to the resending of On/Off commands as mentioned above. As I've written elsewhere, I set my X-10 motions for the maximum timeout to reduce the sending of Off commands as much as possible, and then simply ignore incoming Off commands from them and program based on their repeated On commands. Unfortunately, there is no similar way to reduce the frequency of their On commands, which can clutter the power line especially when multiple motions are used. However, they also operate differently in that the X-10 motions send light/dark commands immediately, while the INSTEON motions wait for 3.5 minutes without light-level transitions before sending a light/dark command. So, I've been toying with the idea of using INSTEON sensors for motion, and modifying these cheap X-10 sensors to eliminate any motion transmissions at all and simply use them as quick-response light sensors. With the On/Off transmissions gone, there wouldn't be nearly as much power line clutter, and it should also extend their battery life. I haven't really done any testing in this vein though, and don't know how effectively they can be used as light monitors, since they don't have the light sensitivity adjustment that the INSTEON sensors have. The INSTEON sensor, with the ability to eliminate the Off command and to adjust the re-trigger time for the On command, would have eliminated much of the difficulty, if only Smarthome had seen fit (or would add to future firmware revisions), the ability given to some later devices, to send an Off command to a different group number than the On command. This would allow the sensor to be directly linked to a responder for the On command, while still not be linked for the Off command, thereby allowing the off programming/timing to be handled by the ISY or other controller, while still ensuring the fastest possible turn-on times of a direct link (no program latency). The new programs look good to me!

Hello ergodic, Thanks for the additional very good example. I really like your 'state machine' approach to developing ISY programs. That's a good question, but I'll need to defer to Chris for the answer . Yes, I have several conditions, tested in various places, for which I use the same technique. And I have many, many sub-program like this. It is currently the only way to nest conditions, aside from using folders with conditions. May I assume (always dangerous) that program Kit Motion.Body.S1.Sub is not enabled, since its If is being called from Kit Motion.Body.S1? In this particular case, if S1.Sub were enabled, the call from Body.S1 could be eliminated as the test would be automatic. But perhaps you've written it this way to keep the logic clear and the state machine consistent? Along the same lines, I'm not sure why Kit Motion.Body.S0 calls Kit Motion.IsNight (If), since the latter must surely be enabled? Also, I notice that your Kit Motion.Cond.S2 program tests for either of the motions sensors to be switched on in order to re-trigger the program timer. However, if motion is continuous, the motion sensors' internal timer will never time out, and therefore an additional On command will never be sent. This is one of the major weaknesses of the INSTEON motion sensors, and can be worked around by waiting for an Off command before starting the program timer.

ergodic! This is an excellent write-up! It is clear and complete, even to start-up conditions and error handling. A minor point on the Denon example; the requirements were: Accordingly, shouldn't the Denon.S1.Body program turn the amp off, and shouldn't Denon.S2.Body Set 'AMP' On, rather than Off? Thanks so very much for posting this, and would you permit us to place it on our wiki? We would be happy to do the formatting for you. And if you would like to draw out the diagrams on paper and scan them (or use a drawing program), and send the image files to us, we would be happy to include them in the wiki article as well--I'm sure they would be a great help to the reader.

Hello chram, that is an indication that the ISY is not communicating with your router: Status Display of ISY's LEDs.

sfhutchi, this is an excellent idea, and thanks for suggesting it. The only reason it has not already been done, is because our resources are so very limited. Everyone remember, however, that our wiki is actually a user-to-user resource, so anyone with a little time, who is so inclined, please do feel free to add examples to the wiki as you implement them, or as you come across them in the forums. The structure outlined above seems like a very good starting point, and of course additional suggestions are always welcome.

sfhutchi, in io_guy's program, simply remove the Wait line. The program will then be equivalent to what you now have, but in a single program. The If will be re-evaluated due to the change in the light status. But, both remaining lines in the Then will execute before it is re-evaluated, because they are an autonomous unit. It is the Wait (or Repeat) command which causes re-evaluation prior to completion of a Then or Else clause.

Both errors are DNS related, which makes sense if the network connection is lost. We have often had problems when an Ethernet switch is involved. If possible, could you connect ISY directly to the router and monitor for a few days?

Mike, that's good news. Thanks so much for keeping us updated; I will close the ticket.

Hello X, Try using the Java application (as opposed to the applet) via one of: http://isy/admin.jnlp http://your.isy.ip.address/admin.jnlp http://www.universal-devices.com/99i/2.7.7/admin.jnlp

Hello X, Using the above link will load the 2.7.6 console. Instead, use http://www.universal-devices.com/99i/2.7.7 to load the 2.7.7 console. This sounds like either a Java cache or firewall/anti-virus issue. When you cleared the Java cache, did you make sure all browsers were closed?

Hi Illusion, So it appears that some 1.0B sensors do give a low-battery warning while others do not. Still no reports of a revision 1.1 sensor giving an indication, though.

Hello apostolakisl, The functionality you desire does require two programs. There are various ways it could be done using two programs, but the way you have outlined is probably the best. Don't be too concerned though, as the ISY can handle many programs .

Hello wrj0, thanks for the input. Please do let us know when the battery needs replacing, whether or not a low-battery indication was sent.

Darrell: All mine are Rev 1.1. Three are in night-only mode and drain batteries within weeks. None have ever given a low battery signal to the ISY. (Using Duracell Coppertop Alkaline) CJVann, thanks for the additional information. You should certainly call Smarthome and have them replace those sensors which are draining batteries! So far, no one has reported reliable low-battery indications from rev. 1.1 sensors, then?

Hello Donald, In your first program, when the lamp is set to 50%, the Status 'Lamp' is On condition becomes false (On = 100%), and therefore as soon as the Wait line is reached, the If is re-evaluated and the program switches from running the Then to running the Else. To overcome this, change that line to Status 'Lamp' is Not Off. Also, in order to have program B's If evaluated when called from program A, change the line in program A's Then to run program B's If rather than its Then. Finally, the reason program B runs immediately is because as soon as the lamp is set to 50%, program B's If becomes true. To prevent program B from running automatically, clear its Enabled checkbox. Program B will then only run when called from another program. "Bedroom OFF" A: If Time Is 10:15:00pm And Status 'Lamp' is Not Off Then Set 'lamp' 50% Wait 10 seconds Run Program 'Bedroom B' (If) Else - No Actions "Bedroom B": (NOT Enabled) If Status 'Lamp' is 50% Then Set 'lamp' Off Else - No Actions

Hello ketchup, In your original programs, simply clear the Enabled checkbox for the Toggle Watch TV program, so that it only runs when called from another program. This should prevent the oscillation. However, Mike's approach will actually be a tab bit faster, since it doesn't have one program calling another program, which adds some latency. Whether the difference would be noticeable, would need to be tested. In Mike's Watch TV Off program, I would change the line: And Status 'TV Light' is On to: And Status 'TV Light' is Not Off in case the light happened to be between 99% and 1% (not On, and not Off).

An additional data point: just checked my log, which goes back to 2009/08/05; there was no 1941 at all. My NTP server is not set to pool.ntp.org. krenzk and IndyMike, is your server set to pool.ntp.org?

Indy, sorry if it caused any discomfort ! Just to add a bit of information; it was also documented in the beta version for the beta testers, of which I was one, and there was discussion about it in the beta forums as well. Right at the moment I can't seem to find said documentation, but if the documentation didn't exist, there is no way Michel would have incorporated the group 3 feature into ISY's firmware. If I do find it I will try to let you know.

Indy, thanks for reporting this. I think your analysis is correct. BUT, I do not buy into Smarthome's statement. The web page shows, and it always has been documented, that the two low-battery warning signals (ON to group 3, and double-flashing LED) are production features of equal weight. It would be nice to hear from Steve Lee about the group 3 command.

Illusion thanks so much for the additional data. Version 1.0B may not be beta, though some of them seem to have (or develop?) the sleep problem. It now seems also that some 1.0Bs issue the low battery warning, while others do not, even with the same battery type. We have yet to hear from someone with a rev. 1.1 that issued a low battery warning.

Nick, thanks so much for the additional data point. My 1.1 also was using the original GP super alkaline that came with it, yet didn't give a low battery warning. So from this it would seem that 1.0B does provide the warning and 1.1 does not, even with the same battery type. At least so far as this limited data set shows. We could still use some more data points.

Agreed, the battery type could make a difference. Especially if Illusion was not getting the warning previously with the alkaline batteries. On the other hand, version 1.0B seems to ring a bell; it might be the beta version, which did give the warning. The sleep mode problem would indicate this. So, Illusion, is it a beta motion sensor, and/or did you previously have/not have warnings with alkaline batteries?

Indy, thanks so much for all your testing as reported in this thread. I can now confirm the lack of a low-battery warning transmission. My first motion sensor low battery (Rev. 1.1--same as you reported) occurred last week. The battery lasted about six months. The sensor just stopped transmitting. There was no low-battery ON command issued. The beta units did send the low-battery ON command, but didn't go to sleep (drained battery within a week). It appears the production models go into too deep a sleep, and forget to send the low-battery warning . BTW, please do let us know the results, when available, of your experiment with reduced LED brightness level--does it extend the battery life? CJVann and Illusion, could you let us know the revision of your motion sensors (on the label in the battery compartment)? Thanks so much. Has anyone actually received a low-battery warning from a production motion sensor, and if so what version/revision?

Rich, change your first program to: If Control 'Motion: Bathroom Sensor' is switched On And Status 'Bathroom: Guest Light' is NOT On Then Set 'Bathroom: Guest Light' On Else - No Actions - (To add one, press 'Action')

Thanks to Chris Jahn for reminding me about slow-dim-to-off. When the above programs turn the bathroom light off, you may wish to have the light actually dim to off over a 30 second or one minute time period. This rate of change in light level is fast enough for the occupant to notice it, and to make some motion to retrigger the light, and is slow enough to give him plenty of time. This slow-dim-to-off is a technique I use widely where there are motion sensors/timers turning lights off. I have written it up as an edit to the original post.