larryllix

Indeed, you are not the first to miss this little detail. This is by design, as I understand insteon, and not unique to the ISY. The purpose of this is to allow multiple buttons to control the same scene, but have different responses. A scene might contain 10 lights, but you may want those 10 lights to be a different levels for, say, watching a movie, versus gathering around, or intermission, or snacks. You could assign four controller buttons to that same scene, but the levels could be set for four different purposes. Most consider this a valuable feature of insteon, I suspect. OK you have me confused. Is a group of devices and the pre-thought-out settings called by a trigger command/button not a scene? Can you define what a scene is?

Thank you. This clears up some confusion.

Scenario: If I have a lamp on and one programme will dim the device in say.. 5 minutes. Another programme is called and it decides to turn of the lamp in 10 minutes but leaves the dimming event active. Will both timers work? Will the latest timer cancel the previous timer? What will happen? Are timers dedicated to each device and only one can be running at any given point in time? or Are timers just freely allocated timers and control programme execution? If so, is there a quantity limit on timers running concurrently?

Sorry: Wrong system information This was just covered in another thread I believe. You need to cancel the timer event for the light first and then set the timer again. It seems the timers are not retriggerable. This means each time motion is detected the timer is reset. You can set your off delay to much shorter then and save the energy from a long off delay and lose the fear of it turning off while any fresh motion is detected. For a shower, dimming somewhat one minute before shutting off would be a good warning to move and retrigger or else you will be in the dark. EDIT: Reading again you would have to use the button to retrigger so the length may not want to be shortened but the dim warning would work well especially lengthen it to about 5 min. Each person would have to remember to give a fresh push before each shower though. In the off program use a timer cancel command.

Edit: Apologies. I misread the question I would think that should be fairly obvious just one being the negative condition of each other. The usual gotcha' on these logic conditions is the states in between on and off. If a lamp is dimmed to 0% it should be "not off" even though it looks off. I don't have an ISY yet so I cannot test this for you (and me).

You could try repetitively pinging the ISY from another computer on your LAN to se if the times change or are very long.

What happens if the mail daemon reports back an email failure / undeliverable notice?

Wow! I have run into this twice today. The top half of your post was not visible until I went to quote it. I assume you edited it after I loaded it. I realise your "else" workaround in Homeseer but they can be real clumsy. Here is a simple example I am working on: All motions trigger a routine called "House occupied". Very easy but determining the off state (=not home) gets more complex. Years ago I used this to run my furnace fan in a cyclic basis to save energy. - When the house was occupied run the furnace fan more often - When not home run it much less. - If the furnace fan runs from a thermostat heat call, reset the timer, it just ran. I had a "House occupied" reset routine at 7:00 AM absolute, to reset it, but didn't like it. Doesn't know you left the house until the next morning. Good for vacations but not for going to work of one-night stands. (I wish) I decided timed resets could be valuable but require different reset times based on time-of-day to be efficient. Motion detectors are going to see you move for 8-10 hours wile you sleep. Very simply put; each motion detector, or wireless remote, calls "House Occupied" "House Occupied" can set a testable flag and reset it after a delay time. But how long? Since there is no "else", at least two new programmes have to be created. One that tests for night-time, setting the time off for 10 hours, and one that test for day-time, setting the timer for say.. 2-4 hours. More efficient daily segments and pattern intuition create more programmes, if faster determination is to take place. I see this taking about five, six or more programmes, as subroutines to the main routine "House Occupied", just to work-around not having an "else" construct. Now I have an older version of HouseSeer, unless they have since added "else" to it. Pretty clumsy! Suggestions?

Assuming you are involved with insides of ISY software. This may be too technical but... are the "then" and "else" statements driven by events from a hardware device's job list (hardware timer or device ON/OFF event) or are they triggered by a continuous scan from an iterative real-time engine? Edit: The added link to the Wiki just answered that question, after I started responding. Is the speed of the iterations just as fast as they engine can go and has time, or based on a regular timed cyclic loop?

I would be interested to know how you would use Homeseer and ISY together? I am currently using Homeseer Pro, as a test, and I find it has lots of "gaps" also, just writing basic lamp timers and state flags, so far. Eg. there is no "else" in my version, but I have created a clumsy workaround that I really don't care for. I have no ISY yet and can't compare them. I have some fair experience with another event driven, real-time system for electrical grid control and ISY appears to be and have similar quirks to it, from my reading here. Perhaps if you posted one problem at a time people may help you resolve some of your "gaps". All programming languages have "gaps" that most of us don't like. Let's hear the beefs. On my X10 experience, in the end I concluded I should just write a driver for the CM11 module (I did) and just run VB code to do the rest. Since I like the programming language environment, why not just use it instead of a restrictive, pull-down, template type, environment, lacking "case" and "while-do" constructs?

Motion detectors do not detect motion going toward or away from them as well as across for logical reasons. -Try moving the motion detector so that it can see her rocking forward or backward in her chair. IOW from the side of her and keep it close to her chair as possible so it occupies more sensor elements. If she moves her hands to the keyboard or leans back or forward it should see that as bigger action/motion and do what you want it to do, mostly. It may not be seeing much movement from the back. -Rotate the desk? -Fasten the Motion detector to another inanimate object? -Lengthen the timer? -Make a timer algorithm that gets shorter at select times of the day? eg. when you know she should be leaving shorten the timer? Lengthen at key times when you know she may be still? -Dim the lights and back as a warning before shutting them off a few minutes later. Gives her a chance to "waive her hands" and reset the timing before pissing her off in the dark.

The serial port usage is one of the main items that concerns me. I would have to buy a 2413S with serial port to support the ISY. If I have problems with communications it is already pretty difficult to take the 2413S and hook it too a PC to test it isolated from the ISY. This will become more difficult as time goes by. We went through this problem at work with IED (intelligent End Devices). Laptops used to calibrate and interrogate them needed a cable dongle to be used and become even less supported as times goes on with an expected 30 year life expectancy device. I think you know what I was thinking with the RaspberryPi. It would be a natural. I don't like dependence on hardware that is already obsolete or unique in industry. Otherwise I would own some Apple products.

I see you have RaspberryPi. Is there any support for that with Insteon? The ISY purchase has me concerned with obsolescence. The use of disappearing hardware makes future support and component troubleshooting harder.

I have no experience with Insteon as yet but perhaps a signal bridge technique would work. If signal bridges via powerline or RF technique work between phases why not between similar phases on different systems? The powerline signal bridge should just be a capacitor circuit that passes high or a particular frequency band from line to line. The Rf method using repeating devices (dual band) wouldn't care about phase relationship between the load and line side of a UPS/inverter. Another thought in logic is knowing your power is dead and cannot report to you via email or SMS. The house needs attention anyway if it persists too long. How to get notified without power is another thing. Too bad the PLM couldn't be backed up with a DC battery system. It would take some hardware hacking to diode-in a backup DC supply and not interfere with the AC connection. It would be easy to do with the ISY since it has an external walwart anyway. Just thinking out loud but the PLM DC input hack would probably be cheapest and easiest and run the whole thing (ISY,PLM,router,modem) off the UPS system. Of course the PLM would have to be plugged into the main house grid and rely on phase coupling or RF to get the wet alarm. Anybody know what internal voltage the PLM runs on?

I own a few dozen X10 modules that will eventually be phased out mostly. I see a chart on the ISY page that gives differences between these two models s 300 vs. 1000 devices, and 300 vs.1000 programmes. I feel 300 devices would probably not be a problem for a home user, like me. Is there a significance to the 300 programme limit? Is there other significant differences? Hardware? Upgradebility? CPU speed? What about the X10 module? Is this included or required in either model? What is it needed for? Is there somewhere that explains this? Thanks in advance.