shannong

Thanks for the quick and helpful replies. There are about 12 other devices in those scenes that are already off during that test captured in the log. Why aren't those devices sent 'Off' commands if the ISY always sends them regardless of device status? Is the inbound traffic from Device 25.6F.7D just repeated messages carried by the multitude other devices repeating the same 'Off' event? If not, what other traffic would it be? It is not a Controller for any scenes. I plan to upgrade tonight but the problem did not coincide with my upgrade to the 4.2.x train.

Oops.I added the log. Well, that helps clear up some of the confusion knowing scene requests aren't ACK'd. Seems like a bad protocol design choice to me. What about the ISY sending 'Off' commands to devices it sees are already off? I thought that didn't happen.

I'm have a reliability issue with a program turning off lights that is triggered by the switching off of a 2477D Dual-band dimmer. The targets are a variety of 2477D/S and a Fanlinc. The intent is that when this one particular switch is switched 'Off' a program fires that turns off all lights in the adjoining room and also a Sonos player via network resource. This has worked fine for the first 9 months it was setup. The switch is not in any scene with the other lights and is not used to turn them On, only Off. Recently it has become unreliable working perhaps only 50% of the time or less. The 'Off' event is always seen by ISY and the program fires. However, often the lights won't turn off although the network resource always works. The strange thing for me is that the ISY updates the status of those switches as 'Off' even though they are still on, which shouldn't happen in an Insteon environment due to ACKs, right? Another odd thing is that if I switch it 'Off' again and the program runs again the ISY turns them off on the second try about 50% of the time. I say "odd" because why would the ISY send an 'Off' command to a device it thinks is already 'Off'. It should do nothing, right? I feel confident that it's not a noise or other interference issue because if I turn these lights on/off from ISY it works 100% of the time. I'm not having any other reliability issues. As for adding delays, the issue is present even when there is only one device that needs to be turned off. Also, all the lights in question are in a scene together currently so adding a delay isn't possible. ISY 4.2.7. PLM is 2413S v9B. The ISY and all relevant devices are on the same panel together with numerous dual-band devices on both legs. No other issues at this time with about 130 Insteon devices of which about 80% are dual-band. Level 3 log attached that includes the first "missed" off and a second one that is run even though the ISY sees them as 'Off' already. I'd really like help dissecting the log to figure this out. Also, can anyone please comment on the situation of the devices showing 'Off' when they are in fact still on? 25.6F.7D Switch that triggers the event 28.F8.63 & 28.E6.DA Two devices to be turned off. ISY-Events-Log.v4.2.7__Sun 2014.10.05 11.04.14 AM.txt

Since fridges deal with water AND electricity there is definitely a risk presented by them where a GFCI would provide protection.

NEC in the USA does NOT require GFCI for all refrigerators in residential dwellings - only commercial. However, NEC does require GFCI for plugs in the garage. So he's stuck with it anyways. The freezer itself might have an issue that is causing the GFCI to trip.

Thanks for the suggestion, Michael. That's a good value yet functional option I haven't run across before.

If you use a residential grade internet router that supports dd-wrt then it can be scripted directly on the router for free. Many many residential routers support dd-wrt which is an open source replacement for the firmware of the device. It's a linux kernel so you can script pretty much anything you want. Several versions have a similar feature built in or you can create your own shell script to do that. Shell scrips are a foreign language for most folks but the typical things you'd want to do have been done already by others so the scripts are available and could be used with only minor changes. That would be my approach vs the smart power strip since you'll also get other useful features like secure remote VPN access and the ability to write other scripts to do anything like you such as sending you an email if the ISY quits responding for whatever reason. Or could could combine the smart power strip with the dd-wrt to solve a variety of problems together.

Here's my wish list for an Android HA app: Integrates with ISY and its modules including Z-wave, Weather, etc. Modern interface that isn't blocky or funky colors Interface for thermostats in ISY (current temp, set point up/down, mode, etc) Interface for Elk security (natively or through the ISY. Current state, arm/disarm, acknowledge alarm, etc) Interface for and support of ONVF IP-cameras.(view live feeds and review snapshots triggered by events) NVR support would be even better with BlueIris Does not require cloud based connection (uses local LAN only) though should probably have one for other useres Maintains state information of devices/scenes/programs in real time in the background so there isn't a sync delay when opening to use Allows customization of the status of devices, scenes, and programs per item (e.g. true=open=red, false=closed=green, etc) Support widgets for status and actions It would be neat to see an HA mobile app that has an agent that runs on a machine at home that actually talks to ISY, cameras, etc and the mobile devices all talk to it. Therefore, customization is done all in one place and reduces traffic to the HA controller/s.

Thanks for the update. Progress is desperately needed and I hope these enhancements you're referring to happen quickly.

I find Mobilinc almost unusable on my Android. Every time I open it it'll sync for 20-30 seconds. Unfortunately, I don't have another option. I've actually considered buying two iPod Touch's to run Mobilinc to have in the house as remotes. The other thing I'm considering is running HomeSeer and integrating it with ISY just so I can use their HSTouch app, which can be customized. It's an expensive and more complex route but would obviously provide some new options I don't have today.

How often does it occur? Can you leave the Admin console running on something? The information captured in the Event Viewer will provide more information that isn't captured in the logs such as programs being running, variables changing, etc. As an immediate troubleshooting step and security precaution, I would change the password while at home.

If you don't want the Insteon ones you'll need to use Wi-Fi, Zwave, or Zigbee. The latter two require upgrades for the ISY. I assume your home already has Wi-Fi. I'm using the Zwave 2Gig CT100's. They're digital and touch screen but your wife might still think they're ugly. Less ugly than the stark green of they Honeywell Zwave, IMO. They're decent although Zwave is still in beta with the ISY. The Venstar 58xx/59xx are pretty, touch screen, and Wi-Fi. But you'll need to run an external program called VenLink along with Network Resources for it to work. See here. http://forum.universal-devices.com/viewforum.php?f=103

Hmm... Interesting idea. I think I'll try that.

In my house, I don't think I was dealing with noise as much as "signal suckers". The experiments and testing done by ELA is very valuable knowledge when troubleshooting your own network even if you can't measure signal strength. http://forum.universal-devices.com/viewtopic.php?f=28&t=5923 It's a long thread but don't skip the middle parts like I did at first. There is a lot of great info about noise and signal suckers and the types of devices that contribute. Approximately 85% of my 130 Insteon devices are dual-band and no room is without at least two.Theoretically, I shouldn't need to rely upon the powerline at all. Despite that, I still had comm issues until I identified and filtered out the major signal suckers. I mention that because of you're hopes and plan to resolve issues by adding more dual-band devices. I'm not saying it won't help but don't expect Insteon magic to happen just because you think you'll have a complete full-mesh RF network that will allow you to ignore the powerline issues. I still have the flickering LEDs in my house lighting to deal with. Of the 3 major LED bulbs I've purchased, only one of them experiences it. Unfortunately, its the one I had purchased the most of before Insteon was in my home. There is a thread on here and at Smarthome that lists LEDs known to be the least problematic with Insteon.

I"m not currently dealing with an comm issues but this thread was very valuable to understand ISY Scene behavior vs Insteon scenes along with Group Broadcasts and retries.

Tstats seems to be a tough one in the ISY environment. I had the Insteon wired and wireless. If you search the forums, you'll see many issues with them. For the wired tstat, there are known issues with gas furnaces causing the tstats to change modes, set points, etc on their own due to line noise. For the wireless ones, there is a confirmed issue with Master mode not working reliably and has been that way for more than a year with no fix from Smarthome. I have two of the 2Gig CT100's. They're relatively cheap and working OK. The only thing is I have to poll them regularly as the updates aren't being reliably processed, although I can't tell you where the fault is. It definitely got better with the ISY v4.2.x. Another drawback is that Mobilinc does not support them on the Android version. Not sure about iOS. The Venstar T5900/T6900 are pretty and Wi-Fi. They have an API for control over the network. IO_Guy wrote a PC-based program that uses ISY Network module for monitoring and control called VenLink. See here. viewforum.php?f=103

The sensors must be added to the Elk as Loop 1. Loop 2 is for the magnetic closure contact. Of course, any time the cover is off of the sensor it will show "Violated" as the housing as a tamper sensor. You need to add them with the "Option 2" checked under Wireless Setup. By default, the Loop 1 wired contact is Normally Closed. Setting the Option 2 tells it that it should be Normally Open and contact with water will close the loop thus setting off the alarm. I added my sensors as "Definition 16- No Alarm" instead or burglar. I don't want a water sensor setting of the sirens and house alarm. My Elk also directly controls my water valve using an output on the system. So I created rules that say "When Zone 110 is Violated, Then Turn Output 192 On". Output 192 closes my water valve. In ISY, I have rules that send me alerts and other actions (such as turning off the On/Off module on my washing machine) when it sees Output 192 on.

Good catch. I wonder if the baud rate is configurable from it's web interface.

Based on your sleuthing and hacking skills to get here and ask the question I'm guessing you'll be able to work through these minor problems just fine.

Greetings. I noticed that Smartenit has their own PLM running the Insteon controller chip plus it includes a Zigbee radio with an RS-232 interface so it can replace an existing Smarthome PLM. Furthermore, it has a Wi-Fi interface with an IP API for remote access. They also have the iSmartenit app for iOS and Android to connect to it over the network to control Insteon devices. Does anyone know if this is compatible with the ISY? If so, are you using the iSmartenit app? It's interesting to think I could use this to add Zigbee components in my HA setup to fill in gaps where Zwave+Insteon with my ISY currently have. I'm using Mobilinc on my Android devices but I don't like it and would love a good replacement. Perhaps iSmartenit could be that. Any feedback is appreciated.

That's pretty cool.

Garage programs attached. Garage Programs.txt

This would be a straight forward program to create since you've already successfully have it working with an F button on your keypad. I use variables whenever possible as I like to abstract actions from devices to provide more flexibility and requires fewer changes if you change a device out for something different. You can read about my other adventures with garage door programs including using two sensors for more reliable detection of open and closed. I like to check to make sure the garage actually opens/closes after a request to do so and other nifty stuff. http://forum.universal-devices.com/viewtopic.php?f=27&t=13892 Garage Door Variable: s.GarageDoor.Status Elk Input for Garage Contact Closure: Zone 1 Scene for KPL buttons: Scene-GarageDoor-KPLs Elk Keypad F button to Open/Close Door: F1 KPL H Button Mode: Non-toggle Off Garage-Door-Status.OPEN ================== If Zone 1 is Violated Then Set Variable s.GarageDoor.Status = 1 Set Variable s.GarageDoor.Status Init 1 Garage-Door-Status.CLOSED ================== If Zone 1 is Normal Then Set Variable s.GarageDoor.Status = 0 Set Variable s.GarageDoor.Status Init 0 Garage-Status-KPL =================== If Variable S.GarageDoor.Status=1 Then Set Scene 'Scene-GarageDoor-KPLs' On Else Set Scene 'Scene-GarageDoor-KPLs' Off Garage-Door-Control ====================== If Control KPL-H-1 is Switched On or Control KPL-H-1 is Switched Off or Control KPL-H-2 is Switched On or Control KPL-H-2 is Switched Off or Control KPL-H-3 is Switched On or Control KPL-H-3 is Switched Off Then Set Elk Keypad Keypad1 Press F1

Sounds crafty. When I come home, the rooms are noticeably warm since I increase the set point for cooling up 6 degrees while I'm gone at work. The AC runs for an hour or so getting the temp down, although it's comfortable within 10 min or so. My concern with your approach would be that the paint would serve as an insulation on the metal disk that would need to radiate a lot of excess heat back into the room before the temp sensor would be reading the same as the ambient temp in the room. Have you tested having an separate temp sensor on the wall at the same location where you install these to test the delay? I'm thinking it could be 20+ minutes which in terms of controlling HVAC would have noticeable results.

I had one wired (2441TH) and one wireless (2441ZTH) tstat. The ZTH isn't really a thermostat since it doesn't directly control the HVAC. In reality it's a remote temp sensor that when is the "Master" tells the TH to turn on the furnace. And that's how I setup my programs. The ISY reads the temp and set point of the ZTH and when appropriate tells TH to turn on the HVAC. For example, I have a Sleep scene. When that scene is active, I have a program that looks at the set point on my ZTH and compares it to the TH. So when in Cool mode and the ZTH temp is greater than the TH and greater than the set point, then reduce the TH set point by one thus engaging more cooling. Since then, I have ditched them. Instead, I have two Z-wave tstats and use IOLinc controlled dampers instead to control the temp in the main rooms I'm concerned with such as the master bedroom.