larryllix

I use many different brands of LED bulbs and have experienced no problems with them so far. I do find most of them will not illuminate below about 12-18% and their brightness curve is quite different. Between about 40% and 100% the brightness does not change that much as an incandescent would. Most of the dimming curve is at the bottom of the curve. I prefer the LED colour when dimed as it doesn't yellow. I try to avoid the 2700K colour. Who ever wanted a bulb that yellow anyway? 3000k-4100K is a much better colour for general soft usage. I use them on LampLinc plug-ins and SwitchLinc dimmers without any problems I have found. However, I have some bedroom lamps with a half brightness switch using a half wave rectifier in the base, and the LEDs flicker some in them and even worse when dimmed on Insteon Plug-in dimmers. I just avoid the built in half brightness setting on the lamp switch. I have experienced slight problems controlling them when my when my co-gen inverter is running and they are behind arc-fault detector breakers in the panel. I depend on the X10 MS units to turn it off occasionally as it is inside the same electrical circuit behind the Arc Fault breakers.

As I understand it Insteon devices/responders must respond with an "Ack" message to the controller in order for the retry logic to work. That being said, with scenes with multiple devices involved it would next to impossible to sustain the logic to invoke a retry communication technique. Each and every device would have to respond with an "Ack", arbitrate who would send their "Ack" or "Nack" first, second, third...umpteenth. This could bog down Insteon communications for quite some time, especially with retries and possibly retries on detected collisions for the "Ack/Nack" process. I think I can now understand why scenes would not support retries.

Something to try would be to disconnect the garage door mechanism and see if the signals are reliable to the Insteon unit only. Noise be coming from the motor or contactors. Using CFL lamps in it?

I have several scenes in my Gathering Room based on the SwitchLinc press style for one set of lights. These scenes control five SwitchLinc dimmers controlling seven potlights. I set the basic ramp speed of each device from ISY to 4.5-8.5 seconds. My scenes using about the same or slower ramp speeds all appear to override the ramp speed set in the devices. The scenes are all controlled by one wall switch When I press the button "On" I get that scene with no initial full on or flash. Pressing "On" again the scene toggles between "TV Watching" and "Reading" scenes. If the switch is already On or Off and I press the toggle down and hold it for a second or longer (Dim) I set my Movie Watching scene with no initial bright cycle. If I initiate "Fast On" I initiate all lights on full and of course local effects of it's own load are again not apparent to the user. In short I think a solution may be to just inject a ramp delay into your devices that gets "beaten" or "taken over" by your scene levels. Rereading your second post: Turning you bathroom lights off. If your hall lights are on dim then wait 45 seconds and turn them off. Turning your hall lights on. If not wee hours use scene with fast on that overrides basic on dim setting in device. Note: I use this method for bedroom lamps with MS in each room. During the day a Fast Off beats the ramp on time and users never see any light but the Fast Off has to be in the entrance program to beat the timing consistently. If Control 'Evening Bedroom / Motion.Evening BR' is switched On And From Sunset - 30 minutes To Sunrise + 30 minutes (next day) Then Run Program 'EveBR Lamp Nightime' (If) Else Set 'Evening Bedroom / EveBR Table Lamp' Fast Off

All variables have default power up values controllable by the programmer. Any states that need to continue, as they were, are easy to set up.

But the ISY could use the data it already has to be used in a variable. ISY could also implement the functions already supplied in the pulldown menus for the 2441ZTH unit. More controls are in the menus but not functional for programs, only manual operation. Probably a overlooked spillover from when it would be wirelessly connected as a slave to a wired unit.

You have all that complex condition logic in an enabled programme. Every time the status of one/any of the parameters changes you will get a notification from the "Then" or the "Else Each and every time any parameter you are checking changes the whole logic statement will be tested for true or false and the appropriate Then or Else will run. Break the programme into two statements with the first triggering events and the second full of conditions that you do not want to trigger events AND DISABLED. For instance; It appears you would not want a notification every time the pond temperature or outside temperature changes one degree up or down. With the programme enabled these will be trigger events that will evaluate the whole complex logic test and execute True or False, based on that outcome. Turning your pump on when it is already on is never noticed but the notification will be.

Having owned a 2441ZTH unit for about a month now I would also like to see more support in the ISY for this thermostat/sensor. Many of the control features such as "SetPoint Up/Down 1" are available in the pulldown selection but do not function with this unit. If the ISY knows what the current temperature settings are and can set them when manually asked to then the programs should be capable of doing it also. Setpoint temperature (Heat/Cool) settings should also be settable and assignable from/to variable values as well as the current temperature should be available to save into variables for data manipulation or transmission to remote readouts etc. These are all features available to other devices inside ISY and should not be asking the supplied UPI to do anything more than what has already been implemented. The information is already inside the ISY. Currently there is no way to do any calculations from the current temperature making the 2441ZTH useless as a cheaper and commonly available sensor. Oh I can manually test for each and every temperature but it would take 100 repetitive programs and never be able to resolve the 0.5 degree resolution available in the communication events. More support for the information already communicated to/from the 2441ZTH to the ISY would be appreciated in the next release, if possible. This device seems to be not supported with a finished interface as other devices are.

Rogers still pulling that garbage? Another reason I dumped them. Try Virgin Mobile. They are all open usage AFAIK. xxxxxxxxxx@vmobile.ca or here is another list http://www.emailtextmessages.com/

Are you looking for email addresses to convert to SMS? http://martinfitzpatrick.name/list-of-email-to-sms-gateways/

Quick interjection question: Do program state changes cause triggers in conditions testing their state dynamically (like a state variable)?

I don't want to mess you up as I really don't do my programs that way and don't understand some of your style. I have to assume you do not have variables in your version. Anyway, I just see some recursive loops in you else statements calling themselves without any function I can see. Once you call the else part of the program it should test as false without needing to loop on it. A few tight recursive loops running like that should probably lock up the ISY CPU so that all other functions grind to a halt. I would just leave them blank and try it.

I haven't taken a lot of time to digest what your programs are doing yet but... You have several programs with recursive loops that could eat up your ISY CPU time and at first glance I don't see any other useful function. Here's one of them. Program 'A:Russound Off' ---------------------------- Else - Run Program 'A:Russound Off' (Else Path)

Ask the neighbour to plugin a couple of Insteon dual-band modules or Access Points somewhere on a duplex receptacle you install by his panel to repeat the signals to/from your out-building. Take him out to lunch once a year. I have seen Wi-Fi advertised up to about 20+ miles with the proper beaming antenna. Do AP units have a replacible antenna that could be made into a beaming arrangement? Two old Sat TV dishes with some weatherproofed APs mounted on them?

I have found it to hang and the only way out was the Task Manager, yesterday after the netbook (Win 7 x32) went into hibernation and shut down. It came back up and all the windows were there but completely hung with no response to anything. Task Manager was necessary to kill the app. Java 8 installed. I can't remember it doing this only after sleeping with Java 8 though.

Just as aside, I always try to avoid house code "A" and in particular code "A1". Almost all units, when new, were shipped with A1 as the default device code. Any neighbour buying some X10 devices online may be interfering with your "A1" addressed device.

I have the X10 module and have defined a phoney unit called "Vacation Mode" which I turn On and Off from inside the ISY. Mobilinc can see it as a device in My Favourites.

That's what I was thinking but after reading the statement I got overthinking it and started doubting what I thought I knew. Thanks!

Lee, for my own clarity. While what you stated would be true when only the time frame trigger is installed in the "If" but when the time frame is used as a condition (used with another trigger) would the time constraint not be evaluated each time that other trigger even was incurred? So as an example: If Control from Motion Sensor is Switched On and From 10:00PM to 6:00AM Then Do It Else - Would the time parameters not also be examined for true or false (inside/outside the frame ) each time 'Control from Motion Sensor is Switched On' is triggered?

Twofold. The from-to construct acts as triggers at each time node as well as it can act as a condition filter for other triggers. If . Control from Motion Sensor is Switched On and . From 10:00PM . to 6:00AM Then . Turn Driveway Lights on . Wait 1 hour . Turn Driveway Lights off Else . - It is generally a good policy to avoid the else with multiple triggers/conditions as every false result of the complex logic will trigger it. Many don't like this aspect of the 'if' section conditions and would like an option in future versions that could eliminate the trigger from any conditional line of code.

Programme needs to be split into two as all the negatives will trigger the else code. Namely .4:00 PM or .Program 'IsSabbathOrHoliday' is NOT True or .Program 'IsOnVacation' is NOT False or 10:00 AM and another status is false. Two programmes, one disabled, can separate statuses conditions and stop them from initiating triggers.

I have the v.0D firmware version in use for the last few weeks now and it appears to work fine. - The Humidity updates every 60 seconds regularly. - Temperature (current) and reports by exception ie. every change - Heat and Cool (soft contacts) calls report by exception. - ISY contains actions that do not (and possibly cannot) work with 2441WTH version alone. ie. Synchronise Time, Setpoint Up/Down 1 deg. - I tried the unit with a 5.7vdc and 5.0vdc adapters and can detect no reporting or feature/frequency of reporting difference. - Wireless (only) range is really good even through a shop, in a separate building, completely covered by metal roof and foil coated insulation (joints foil taped). Commercial radio reception is almost impossible there. Three windows need to be near line-of-site. I have since added a LampLinc as a powerline repeater for the flakey MS communications that have a worse wireless range. - Local temperature only displays integer degrees with no Celsius option despite sending 0.5 F resolution. Peeve: temperature reporting exceptions are not always on 0.5 degree change. **ISY Feature request: temperature store into variables and setpoint(s) set from variables **

This may give you some help with this. Read down to Xathros posts He has a good grip on this stuff. viewtopic.php?f=27&t=13564 Do a search. You will many discussions on this basic motion to light control usage.

This sounds like more arguments for more system variable user access in programmes. There must be something in the internal system flags to indicate a failure to communicate with the PLM. Users could easily write programmes to send notifications based on that flag and/or reboot the ISY several times in attempts to recover without human intervention, especially in the case of remote systems.

The short timeframe of the Java updates has to tell us something. I noticed flakey operation ever since I updated to v4.1.2. I noticed other areas operating a bit weird so I figured it was the new Java7u55 I had to install with the ISY update. I found the Java 8u5 version and installed on one PC but when I went back to update another PC the next day Java 8u5 version didn't exist. I wondered if bugs were found and it was pulled temporarily as it is back again. I believe Java 8u5 is the first 64 bit version also, something they originally reported they wouldn't support. Seems to be sudden new market drive from Oracle lately.