IndyMike

Unless something has changed recently: The ISY will not request a group cleanup after turning a scene on/off. There are no retries associated with an ISY scene. The ISY reports what "it believes" the correct device status is based on the scene command it executed. While not as reliable, this is very fast and does not encounter issues when stringing multiple scene commands together. A device direct command from the ISY (clicking a device on/off from the device tree) will request a cleanup response and will retry failed communications. A button press (KPL button or switch button) will execute a scene command and request cleanup from each device in the scene.

Techman, I also have the 2009 developers guide. No help there. The best information that I've seen on the subject is Lee G's post that you referenced above. Just to be clear, it isn't just the "EA" record that will show as a record mismatch. Since the hop count can increment from 0 to 3, you have three values that can create a mismatch. Better to simply mask the bits out of the comparison 0 Hop: E2 1 Hop: EA 2 Hop: F2 3 Hop: FA By the way, thank you for bringing this up. I don't have many I2CS devices and had been restoring them (incorrectly) when I noticed these mismatches. I feel a lot better now that I understand that the devices are modifying themselves.

Hello Techman, It looks like you found the correct post from Lee G. As he documented I2CS controllers are capable of changing the cleanup hop count to "adapt" to their installed environment. The "EA" link record is the result of a I2CS device increasing the default cleanup hop count to 1 hop. Since the hardware device is modifying its cleanup count locally, the ISY should NOT consider this a record mismatch. I had missed this post originally an am learning along with you. To verify, I went through a series of tests with a "new" KPL. The KPL was setup to "turn off" my 1st floor scene (~ 30 devices) using a non-toggle button. As programmed by the ISY there were zero mismatches. By varying the location of the KPL (wired to a cord) I could observe how it modified the cleanup hop counts for various scene members. The KPL both increased and decreased the hop count depending on its location. 1) As programmed by the ISY - no mismatches 2) Location 1: 10 mismatches 3) Location 2: 11 mismatches 4) Location 3: 12 mismatches

Hello jgcharlotte, My information may be a bit dated - most of my devices are V1.1 2420M sensors (Old). The behavior you are looking for below is exactly what I get with the "sensing mode" unchecked. I've just verified this with my spare sensor. With the "sensing mode" unchecked: 1) sensor sends an "On" at first motion, then an off after 30 seconds if no additional motion is detected. 2) sensor sends an "On' at first motion, and recognizes additional motion but does not transmit. It re-starts the 30 sec motion timer at each event. After 30 sec with "no motion", it will send an off. If this is what you are looking for, I don't believe you need any program intervention.

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.