IndyMike

Hello GMD99, As others have correctly posted, dimmer switches generate heat that is a percentage of the power delivered to the load. The higher the power, the more waste heat generated by the dimmer. All (95%) dimmer switches generate waste heat in this manner. This is not something that is unique to Insteon devices. Since the hot faceplate appears to be new after the rewire, I am guessing that you had traditional (non-dimming) switches installed previously. If so, these would not have generated waste heat. With dimmers installed, the temperature of your faceplate will depend on many factors that affect the amount of heat generated, and how the heat is conducted away from the switch: 1) # of active dimmers/load power 2) J box type (plastic/metal) 3) Wall type (inside/outside; insulated/uninsulated). 4) Wall sheathiing (sheetrock/plaster/wood) 5) faceplate type (plastic/metal) I made some measurements on the heat generated by a KPL dimmer VS load some years back. That information is located here: http://forum.smarthome.com/topic.asp?TOPIC_ID=6969&FORUM_ID=9 The temperature vs load information should give you an idea of whether there is something "wrong" with your installation. My guess is that there is not, but I certainly do not want to minimize any concern on your part. If you believe your temps are running higher than what I am showing in the link, you should absolutely call your electrician. If you are concerned with the heat being generated at the switchbox and/or reliability concerns with the heat in the switches, post back - there are many ways to address this.

nil13, If you have the network module, you can use a program to log whatever data your heart desires (and variables support). http://forum.universal-devices.com/topic/10122-402-network-module-create-web-pages-using-programs/ I've been using this technique to log weather data for a couple of years now. Very nice.

Christopher, I agree that if your program ran, you should have received both a "Program" log entry as well as "System" log entries for each device in the Scene. I have a "recirculation pump" program that runs twice daily. I've been logging entries for this program daily even though the applicancelinc that is Scene uses was removed months ago. I don't have a good explanation for why your program indicated "run" but you have no log entries. This is probably a Michel question. My only observation would be that 12:59:59 may be a rather busy time for the ISY. You could try moving the trigger time a few minutes in either direction. I've never seen the ISY "miss" a program operation. Nonetheless, I do think this needs to be investigated.

Brian, I believe the 4826 had issues handling "Dim" commands from the X10 CM15a (firestorm event). Being that the 4826 is labeled as a "true X10 repeater", it should have been able to distinguish between X10 and Insteon transmissions. The Boosterlinc was a real time booster. It attempted to discriminate between Insteon/X10 by the start of the waveform in relation to the 60Hz zero crossing. It would invariably get fooled into thinking a low level Insteon transmission was X10 and would transmit on top of the Insteon.

Hello JSP0511, To be blunt - these are not the type of devices that I would trust to automation. Not just Insteon, but ZWave, UPB, X10, RadioRa - you name it. All of the automation protocols are subject to programming and communication errors. Think in terms of what would happen if your compressor or shop vac were to inadvertently turn on while you were away. This is not something we can answer for you - it's your application. Personally, I would not install such a system without a manual override. The problem is remembering to activate the override. If I were to vote, I would vote in favor of the "purpose built" current sensing switches that larryllix posted. I'm not sure if these are appropriate for you air compressor application - I'm unsure how you are using the compressor with your woodworking tools. My 0.02, IM

Like LeeG, your comment on this being an old Commercial building caught my attention: 1) Possible that you have "true 3-phase" power. Voltage across the mains (legs) would be 208 rms rather than 240. 2) Possible that your RF communication is being blocked by fire-breaks, metal, and other construction materials not commonly found in residential construction. As LeeG indicated, check your coupling between RF devices - make sure your phases are STILL coupled.

Hello smokegrub, It sounds like your program is turning off the individual switches themselves. This affects only the device addressed by the program. Try turning off the scene instead. This should turn off all devices in the scene.

Hello Michel, KSBN received .22" of rain yesterday according to NOAA. The HAM website recorded .2" of rain - 0.02" was "missed" due to the 1 hour time offset. The ISY recorded the 0.2" of rain yesterday, but did not reset to 0 after midnight. It is currently recording 0.2" for 10/5/2014 even though no rain has fallen. The table below shows rainfall totals reported by the HAM website. The plot below shows NOAA and ISY cumulative rain for 10/4 through 10/5. The red line (ISY) should reset to zero after midnight on 10/4. Unfortunately, I'm running out of calendar to track this issue. In November precipitation will become "fluffy" around here (the bad fluffy - not Gabriel Iglesias). We had an unofficial 110" of snow last year - unofficial because the NWS at KSBN decided to discontinue measuring snowfall after 74 years. We're doing our winter tuneups on Vehicles, furnaces, snowblowers and the like. Judging by the way my pines are dropping needles, we don't have much time left.

Hello Michel, I am having a bit of trouble interpreting HAM's response: It seems that they are implying that one hour delay on the KSBN website is an isolated case. I spot checked 3 other international airports aross the US (O'Hare, Atlanta, LAX). All showed a one hour time delay. Interesting, since a one hour delay from LAX would put you in the Pacific. They also seem to make the distinction that the website and the API are not the same. Unless I mis-understood, the API should be more accurate. I am currently tracking a minimum of 1.5 hours delay between the ISY reports and NOAA (10 minute update in my logging). I have been holding this back since I regarded it as unofficial vs the website (one issue at a time). I'm a bit concerned that HAM appears to be treating this as isolated rather than examing their "system". Also concerned that it is far more difficult to correct PWS stations since we do not have access to a "webiste" summary for them. Am I overcomplicating things? IM

Hello Mike, I haven't received any rain here to check the updates. I have noticed that HAM data is being presented 1 hour late VS NOAA. My airport station (KSBN) is in the eastern time zone. HAM appears to be presenting for central.

Hello Michel, Verified both firmware and UI at 4.2.8, Under 4.2.8: 1) KSBN received 0.06" of rain yesterday. The ISY reported 0.04" 2) No rain at KSBN after 16:00 yesterday and today. The ISY continued to report 0.04" until 4:50 PM when I loaded 4.2.15. 3) After loading 4.2.15 rain is at 0.0" No rain the the forcast for the forseeable future. Waiting on data on this end...

Hello Michel, I'm on 4.2.8 (RC3). There was nothing related to HAM/Climate noted in the 4.2.10 (RC4) release notes. Did I miss something?

That's correct Michel. I'm thinking that something was "stuck" after the changeover. Rain today was showing 0.05 again this morning. I manually switched stations and then came back to KSBN. Now correctly showing 0".

I'm showing 0.05" rain today. Last recorded rain at KSBN was 0.07" on 9/15 <climate enabled="true" locationId="KSBN" rss="http://wx.hamweather.com/?pands=KSBN" lastUpdatedTS="2014/09/18 16:42:23"> <Temperature>72 F</Temperature> <Temperature_High>72 F</Temperature_High> <Temperature_Low>43 F</Temperature_Low> <Feels_Like>72 F</Feels_Like> <Temperature_Average>52.7 F</Temperature_Average> <Humidity>41 %</Humidity> <Pressure>30.11 psi</Pressure> <Dew_Point>46 F</Dew_Point> <Wind_Speed>7 mph</Wind_Speed> <Wind_Direction>ENE</Wind_Direction> <Gust_Speed>17 mph</Gust_Speed> <Total_Rain_Today>0.05 inches</Total_Rain_Today> <Light>93 %</Light>

Thanks Michel, No rain in the forcast until the weekend. Will report back when I have some data.

The chart below is a comparison of Weatherunderground VS ISY/HAM reported rain for September. I can't even hazard a guess at how HAM is currently rolling up daily rain or when they implemented changes. I would normally try to offer some insight on where the errors might lie in this type of calculation. I have no explanation for the differences I see below.

Hello Michel, Things have definately changed on my end. Not for the better... KSBN is showing 1.09 inches yesterday and .05 inches since midnight. ISY is showing .07 inches yesterday and .04 inches since midnight. I suppose it's possible that HAM's updates were rolled out after the storm went through yesterday evening. I have no way of telling from this end.

Hello Michel, My appolgies for the tardy response. I am repairing a number of PC's after a previous storm event (family members). This is good news. I have a new storm front approaching this evening. Will hopefully be able to confirm the updates by monring. As a side note - I may have been a bit harsh in my appraisal of HAM's service. While they have had issues, the version history you provided indicates that they are working to resolve them. I had not seen this previously, and am encouraged by it. IM

Hello Michel, I understand that UDI chose HAM and is responsible for the climate module performance. I forgive HAM for the normal startup issues like station coverage, lags in reporting (delays), and such. Howver, the accuracy of the data should NOT have been an issue. I will begin re-checking after the Thursday updates. Please recognize that I need an afternoon rain event in order to check for rollover.

Hello Michel, Thank you for investigating this issue. Please understand that my frustration is not directed at UDI. Just to re-enforce the fact that this is not an isolated issue - I checked Chicago O'Hare. On October 31 HAM is showing rain of .26" for KORD at 5:51. NOAA, Weatherunderdround, etc. are showing no rain for the 31st. jmed999, That was exactly my question. I am unclear whether the "fix" was immediate, or was taking place in stages.

I am not sure where HAM stands on it's rollout for correcting the "Rain Today" issue. My understanding was that this was to be corrected weeks ago. From my standpoint - zero improvement. I am continuing to see a "roll-over" of rainfall from the previous day into the current day. With pop-up afternoon thunderstorms a regular occurance this time of year, the roll-over issue make's it impossible to use the HAM data for calculating ET. I am using the local airport station KSBN which is THE NWS/NOAA station for the area. HAM is currently showing 0.34" rain today whereas the NOAA, NWS, Weatherunderground, and Weatherbug are all showing 0.09". The following screenshots are from the NOAA site and HAM. These should be 1:1, but HAM is showing 0.34" in the "6 Hour" column at 6:54 AM. NOAA is showing 0.09" in the same column at 7:54 AM. I am using the NWS site because I thought is would be a standard data format and "easy" for HAM to roll up the data. Very disappointed that they cannot seem to get a handle on what seems to be a very basic issue.

CPUJohn, The light% does appear to work for my site (KSBN - northern Indiana). This is the local airport which is a NWS/NOAA site. I will say that I believe that the data is "calculated" based on the time of day and reported cloud conditions. Neither the NWS, NOAA, or WeatherUnderground report light% for this site. I have other PWS sites that report actual solar radiation - they are far less granular and indicate rapid transients with passing clouds. Using a different site may resolve the issue (it can work). Understand that a different site may not be the best for local climate data. My use of KSBN is purely for data collection as it is 15 miles away. Today KSBN has received .21" of rain where I have 0". Balancing climate needs for irrigation against light% needs for scheduling may prove to be difficult. IM

Unless something has changed, light% is not used in the ET calculation. Daytime sun exposure is based on your lat/lon and month/day.

I've been seeing similar things with my local airport station (official WBS/NOAA station). Seem's to be linked to the HAM "rain in the past 6 hours" which can roll into the next day. The following is a comparison of Weather Underground reports VS HAM (ISY). The second and third tables are HAM reports from 7-14 and 7-15. The discrepancy between Weatherunderground and HAM seems to be due to a HAM rollover of 0.46" from the previous day. No explanation for the discrepancy on 7-14

Hello Waketech, The amount of water "deducted" from the irrigation required depends on the values you specified for "absorption factor" and "water applied per irrigation" In the expample below I specified 80% for absorption and .42" for water applied. When I execute the "irrigation complete" command, the ISY subtracts 0.336" (.42" X 0. from the irrigation required value.