alx9r

My clocks just changed and, like clockwork the timers stopped again. FWIW I have a pretty reasonable workaround working for this: create a program call "Restart Timers" that invokes "Run Program" for each of the timer programs prone to stalling use a control condition from a rarely used insteon switch to invoke "Restart Timers" When the timers stall (which, in my case is three or four times per year), press the designated insteon switch. The timers should start again. Alex

ccclapp, You only need to devote two keypad buttons (volup/voldn) to get this working. Here is the overview of how I implemented this: keypress events are received by the ISY and increment or decrement any ISY state variable and limit the valid range of that state variable to, say, 0-9 create 10 network resources, each of which transmits a particular value of MVxx create 10 programs each of which has a condition that is true for exactly one valid value of the state variable, and each of which invokes the corresponding network resource. Example in Action Supposed the state variable is currently "2", and you have decided to map "2" to "MV20" and "3" to "MV30". Now suppose a user presses your "VOLUP" keypad button. One program senses the "VOLUP" keypress and increments the state variable from 2 to 3. Another program has a conditional that is true only when the state variable is 3, so that program executes its 'then' block which invokes a network resource that transmits "MV30". The net result is that pressing "VOLUP" just incremented the volume from "MV20" to "MV30". The same concept applies for all 9 other values of state variable and MVxx What I am Doing FWIW, I have this working in this way at my house. It works well for A/V zones where dynamic volume is enabled, since the user rarely (read: almost never in my house) has to change the volume manually in those zones. When those zones turn on, my ISY programming pre-selects a likely volume based on time-of-day, what caused the zone to turn on, and in the kitchen for example, whether the range hood is cranking. Without dynamic volume, no amount of automation will help you because the user will have to ride the volume constantly to maintain comfortable a volume. That's fine for the home theater, but impractical everywhere else. In summary: For the home theatre zone I disable dynamic volume and provide a delay-free IR path between an IR remote and the receiver. This works because you get the full dynamic range of volume and users like the responsiveness of the delay-free volume control. For other zones, I enable dynamic volume to almost eliminate the need for volume adjustments. Then I provide keypad volume controls à la the method I describe above. Because volume adjustments are rare in these zones, users are fine with the delay introduced by Insteon and ISY. For still other zones, I don't even provide keypad volume controls because the dynamic volume works well enough. Hope that helps, Alex

ccclapp, I can confirm that I have found no way to implement volume up/down commands in greater increments than 0.5dB. That increment is too small to be useful when dispatching user-invoked volume commands using the ISY because of the delay introduced by the ISY. As a workaround, I have a list of about 10 separate network resources each with its own volume level (eg. MV13, MV16, MV19, MV22, MV25, etc) that are invoked by ISY programs as the user selects different volume levels. The many-network-resources method works. But it is rather laborious to implement, and the ISY is slow to execute it. (I'm guessing it's slow because it evaluates all 10 'if' statements each time the volume is changed, but I don't have any way of proving that.) I think the correct way for ISY to implement this sort of control is to interpolate variable values into strings transmitted by network resources. IIRC there was once talk about a future firmware version supporting string interpolation in network resources, but I haven't kept up with that progress. Best Regards, Alex

Hi Michael, This bug just bit me again. Can you confirm whether bug #171 is resolved in any versions of firmware yet? Thanks for your help, Alex

MFBra, That sort of feedback mechanism is not crazy at all. If you implement that to compensate for an unreliable communications channel, you will need to implement what amounts to a custom state machine in the ISY to track the state of Roomba so that you can resend the signals in a sensible manner. I've got a bunch of such state machines in my ISY to compensate for various devices that just don't seem to get the message on the first try. These state machines are time-consuming and tricky to get right, and usually completely avoidable if your communications channels are reliable. The result is never as reliable as what you get with a good communications channel in the first place. If you're trying to save money by going the Insteon rather than TCP route, expect that money saved to result in much time spent programming your own retry logic. And expect your hourly rate to work out to much less than minimum wage in the end. Alex

Hi atomicbear, I haven't tried the IRLINC. I would not expect satisfactory results unless you have an extremely robust Insteon network. Insteon does not guarantee delivery. This is particularly problematic for sending toggle IR signals. Roomba's clean signal is a toggle signal. This means that when Roomba receives "toggleClean" it starts cleaning, and when it receives "toggleClean" again it stops. Because of the unreliable nature of Insteon, the ISY can never be sure how many (if any) "toggleClean" signal Roomba has received if you are sending them over the IRLINC. So ISY can't know whether the next "toggleClean" signal will start or stop Roomba. Contrast this with the Wifi2IR: The connection from the ISY to the Wifi2IR is TCP which guarantees delivery of packets by transparently retransmitting if they don't reach the destination on the first try. The result is that when the ISY sends "toggleClean" to Roomba, it is certain that Roomba receives it. My rule of thumb is, if you can choose between TCP and Insteon, choose TCP -- your system will be much more reliable. Alex

Scyto, I'm curious how your roowifi turns out in the end. Is there something specific you're planning to do that can't be done with a dock-mounted IR transmitter? My main concern with adding wifi to Roomba was that the modules were vulnerable to damage, increased Roomba's height, or required repeat time-consuming alterations to Roomba. Alex

Sometime yesterday, the red error LED on my ISY994i (v.4.2.28) began flashing. The wiki says the flash pattern indicates a "file system issue". I rebooted the ISY and it seemed to go back to normal. However, I expect that that this problem may well develop into a more frequent occurrence. 1. Is there some sort of utility I can run to check and fix whatever this "file system issue" was? 2. Is this a sign of something failing? If so, what? And how do I replace it? 3. Is it possible that backups taken when there is a "file system issue" are corrupt? Thanks for your help, Alex

Thanks for the update Michel.

larrylix, As far as I know all Roombas respond to the same IR commands. I believe the the sensor for the IR commands is the same as it uses for detecting IR beacons (eg. virtual wall, docking station). iRobot would have to go out of their way to cripple IR command reception. Many Roombas including the ones I bought are packaged without remotes, but you can buy the remote separately. I bought my remote separately just so I could capture the "Clean" command from it for automation. Alex

For roombas see "Integrating Roomba with ISY" above. I don't use Scoobas or gutter cleaners.

I came across this discussion about integrating Roombas. I've had three Roombas integrated with the ISY for about 2 years now. We don't even have any other vacuums at the house anymore. Our floors are way cleaner than if a human cleaned them. This should be no surprise. Three Roombas clean for an hour a day, every day. A human might clean the floors once every one or two weeks on a good month. Expectations I've seen many people who are disappointed with Roomba's efficacy. This usually boils down to having unrealistic expectations for the little robots. In my experience, the following are the most common barriers to Roombas pleasing their owners: too much dirt or dust per cleaning (they can't clean the whole house if you only run them for an hour a month) inappropriate timing of cleaning (they disturb people with noise and by being underfoot) too much area per Roomba (see the "numbers game" section) clutter on the floors (Roombas don't have arms and they can't move your junk on the floor to clean under it.) Effective Cleaning is a Numbers Game Roomba's cleaning pattern is random. This means that there is a mere probability, not a certainty, that any given spot on the floor will be cleaned on any given cleaning cycle. To maintain clean floors you want to keep this probability as high as possible. Here are the things you can do to meaningfully increase the probability: restrict each Roomba to a manageable sized area run Roombas at least once per day set yourself up to clean and repair Roombas How Much Area Can One Roomba Clean? I have no pets and a high-efficiency furnace filter. Windows are rarely open. Despite this, without vacuuming, a noticeable layer of dust forms on our floors in about 4 days. I started with one Roomba in my 1400 square foot floorplan, and quickly increased that to two and then three. Even in these most ideal conditions a single Roomba cannot effectively clean more than 700 square feet. I'd say you should budget between 300 and 500 square feet per Roomba depending on how dusty/dirty your space is and how frequently you'll be able to run them. Actually Running Roomba Regularly Roomba needs to run at least once per day in order to keep up. Because they are noisy they won't be welcome to run at night. Because they end up underfoot and in the way, they probably won't be welcome when people are going about their day at home. I have found that occupants cut Roomba's cleaning cycle short when they around during vacuuming. The only time you can be sure Roomba's cleaning won't be curtailed is when no one is home. The only reliable way to get Roomba to clean when no one is home is to start them automatically when everyone leaves. This is critical to getting Roomba's numbers up, and is therefore critical to having clean floors. I experimented with a few different criteria to trigger Roomba's cleaning. I finally settled on Roomba cleaning once per day starting when the house is vacated. I use the arming of the alarm as the event to trigger cleaning. Roombas take about an hour to finish their cleaning cycle, and I've found that it is rare that anyone returns home within that hour. If I had pets, I'd try to find second daily window for Roombas to run. Cleaning and Maintenance Roombas require regular cleaning and maintenance -- more if they're cleaning a backlog lot of hair or debris, less if they're just maintaining. At around 500 square feet per Roomba with no pets, emptying Roomba's bin and cleaning the filter about every two weeks is adequate. You also need to clean hair and string from the rollers about every six weeks. Roombas have many wear parts: Brushes, motors, batteries, rollers, etc. These wear parts don't last forever. Occasionally, non-wear parts like the charging station also fail. Failures are a matter of if, not when. I keep an inventory of parts so I can replace failed parts immediately. Integrating Roomba with ISY The only signal you need to send to Roomba from ISY is "Clean". Roombas natively respond to infrared commands and they return to their docks automatically. I experimented with a few different methods of sending the "Clean" command from the ISY. The only reliable method I found is mounting a Global Cache Wifi2IR and IR blaster to Roomba's dock. That setup looks like this: You "teach" the Wifi2IR with the Roomba remote and set up a Network Resource on the ISY to send the "Clean" signal. I have three such Network Resources: Once for each Roomba's Wifi2IR. Here's are the contents of one of my Network Resources: protocol: tcp Host: <the IP address of the Wifi2IR> Port: 4998 Timeout: 500 ms Mode: C Escaped Body: sendir,1:3,1,38343,1,1,111,39,36,113,35,113,35,113,108,39,36,113,35,113,35,783,111,39,36,113,35,113,35,113,108,39,36,113,35,113,35,783,111,39,36,113,35,113,35,113,108,39,36,113,35,113,35,783,111,39,36,113,35,113,35,113,108,39,36,113,35,113,35,793,111,39,36,113,35,113,35,113,108,39,36,113,35,113,35,783,111,39,36,113,35,113,35,113,108,39,36,113,35,113,35,783,111,39,36,113,35,113,35,113,108,39,36,113,35,113,35,783,111,39,36,113,35,113,35,113,108,39,36,113,35,113,35,4907\r\n I hope this helps others get on the right track with Roomba, Alex

Hi Michel, I just tested your suggestion to add a condition that always evaluates to true to the if statement. The program looks like this: 5-second timer - [ID 01BC][Parent 0013][Run At Startup] If $always_zero_v is 0 Then Repeat Every 5 seconds $Second_Ticker_5__s += 5 Else - No Actions - (To add one, press 'Action') I did the following: RunIf (it runs continually as expected) Changed clock back 1 hour (it stopped running) Here's what programs=>summary looks like after changing the clock: You can see that the if statement is evaluating correctly "state=true" but it stopped running "Activity=Idle". I ran this test using both an integer and a state variable. The results were the same. Is there any other workaround I should try? Alex

Last night's daylight savings time switch revealed a weakness when using "repeat every x minutes/seconds" programs. Summary Changing the clock on the "Configuration=>System" tab causes programs of the following style to stop running: If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Repeat Every 1 minute $Minute_Ticker_s += 1 $Minute_Ticker_v = $Minute_Ticker_s Else - No Actions - (To add one, press 'Action') Reproduction To reproduce the problem, do the following: set up a program like the program above Run the program. programs=>summary should look like something like this: on the "Settings=>System" tab change the clock back 1 hour programs=>summary should show the same program as stopped: Impact Wherever a timer program of this style is used to periodically increment a variable whose value drives other programs, that timer program and all programs that depend on the incrementing value stop working when the ISY's clock is adjusted. The stoppage seems to occur whether the clock is adjusted manually or using NTP as long as the adjustment is large enough. That means that such programs will most likely halt during a daylight savings time switch. They will probably also halt if the ISY's clock is abruptly adjusted using NTP if, for example, the NTP server could not be contacted for an extended period of time, or the ISY's real-time clock drifts enough between regular updates. Workaround? I've been trying to find a workaround that allows me to create a periodically-incrementing variable that continues to increment even after an abrupt clock adjustment. I have not found a solution yet. Is there a way to achieve this? Thanks for your help, Alex

I am having the same issue with one of four of my Venstar 2491T1E v.95. The isy994 is able to link, query, etc. Everything seems to work fine except it cannot change the 2491T's settings. The settings change in the ISY admin console, but they do not change on the Tstat's LCD. And, when I select device=>query in the admin console, the admin console reverts back to the original settings. Here is the strange part: - I have swapped the problematic thermostat with another identical known working thermostat. - The problem stayed with the location, i.e. it did not follow the thermostat specimen, the non-working location remained non-working, and the working location remained working. I suspect this might be an issue (or complex interactive problem) with one of the dual-band devices nearby, but I have not been able to confirm this.