giesen

Another option since you have the Elk is an Aprilaire or HAI thermostat. I have the Aprilaire, and while it takes a few components to get it all hooked up, it's pretty robust and you can control it either from your Elk or the ISY (assuming you have the Elk module). It's connected via RS232/RS485 and is pretty robust, with zero cloud dependencies. Sent from my SM-N910W8 using Tapatalk

Would just buying a plug-in dual-band module be an acceptable solution? You could put it near the thermostats, and as long as it's on the same electrical phase as the PLM is, should extend your reach wherever you need it (within reason) Sent from my SM-N910W8 using Tapatalk

ISY integration brings the ability to use your security system as a trigger for home/away. I can tell you there's no way the Nest can compete with your alarm system explicitly know you are home/away. Sent from my SM-N910W8 using Tapatalk

Agave is quite good on Android and the developer is active on these forums. Mobilinc for Android is not in active development anymore and quite frankly, stinks. Sent from my SM-N910W8 using Tapatalk

eKeypad is quite nice too, especially if you have other devices (Elk, IP Cams, etc). Worth checking out Sent from my SM-N910W8 using Tapatalk

Editing the program seems to have solved the problem. Any way to definitively diagnose what caused it? For posterity: >SM -a Static = 262144 used, Heap = 1236992 free, Total = 1499136 Cur Cur High Size Tot Free Used Used 208: 1034 977 57 57 197: 4 2 2 2 106: 270 270 0 9 64: 255 235 20 38 132: 90 90 0 4 706: 530 530 0 319 28: 12000 10868 1132 1152 4096: 10 10 0 0 10240: 5 5 0 0 17408: 5 5 0 0 32: 300 294 6 15 1024: 35 31 4 19 8192: 14 14 0 6 32768: 12 12 0 3 131072: 2 2 0 1 38: 32 32 0 3 65728: 1 0 1 1 1306: 17 10 7 7 5214: 22 6 16 17

I just noticed today one of my programs was showing a yellow icon that I had never seen before. When I went to the summary page, it says under the Activity column "- Not Loaded -" and the Status is "Out of Memory" I only have about 152 programs, 19 Integer Variables, and 18 State Variables, so I shouldn't be hitting even the base unit's program limit, let alone the limits of the Pro unit (I have an ISY 994i/IR PRO). Is this just a memory leak in 5.0.7, or have I hit some sort of other limit?

I'm contemplating getting one of these Broan units: http://www.broan.com/products/product/cfb066ba-781b-43de-a3e3-1d5d58a4dc23 but I've only found one (archived) thread on the forums: http://forum.universal-devices.com/topic/10140-cant-add-broan-control-device/ Did UDI ever get this device to work with the ISY? The manual for the controller is here: http://www.broan.com/common/productDigitalAssethandler.ashx?id=1b5cda00-8528-47dd-8eb7-bfdb33a3e287 Note while it may be based on an ICON On/Off Switch 2876SB, it appears to be much more than that as it seems to have a built in timer for periodically ventilating the home; Vacation and Disable modes to disable the automatic ventilation; and Automatic-Off and Delayed-Off modes for automatically turning off the fan after a set period of time.

Yes but can use isylink with v4 Sent from my SM-N910W8 using Tapatalk

You could also use isylink/nodelink which gives you the sun's position in the sky... Sent from my SM-N910W8 using Tapatalk

Elk (www.elkproducts.com) supports 3 different types of wireless sensors... GE, Honeywell, and their own brand (depending on which receiver you get) . So you have lots of options to choose from. Elk supports up to 8 separate areas. Sent from my SM-N910W8 using Tapatalk

The reality is if you depend on the security system for the safety of your property and persons, you really need to go with something that is intended for that task. I highly recommend the Elk M1 (as will many others) for its excellent integration with the ISY. This isn't a knock against the ISY, but neither it nor Insteon in general were ever intended for that role, and just don't have the testing, certifications, security and reliability required for an effective security system. The Elk also doubles as an excellent way (once you get past the initial outlay of cash for the system itself) to be the "eyes and ears" of your ISY system, as you can add low-cost sensors and the ISY can use their status in just about everything. I'll give you a few basic examples... When someone rings my front doorbell, it turns on the porch light (if it's nighttime) and sends me a push notification. If I open my front door at night, it turns on both the inside and porch light. If I open my garage door (either the overhead door or the side door), the main lights turn on. All for the most part with $5 sensors. Now if you need to go wireless, obviously there's a bit more cost involved, but it's still cheaper than most Insteon sensors, and way more reliable. And the sensors serve a dual purpose for both security and home automation. I use Insteon exclusively for lighting control (no Insteon sensors whatsoever). The Elk is also a great way of providing the ISY with status or "intent". If I arm the Elk in night mode, it means I'm going to sleep so my ISY turns down the thermostat and turns off the lights (on a delay). If I arm in away mode, it does the same thing. If I arm in vacation mode, the setpoint on the thermostat goes to an even more energy-saving mode. In the end, using the proper tool for the task (though it will cost you more upfront) will provide a better user experience (and higher WAF) and be more reliable and flexible.

Did you also check "Run As Administrator" when you enabled compatibility mode? Sent from my SM-N910W8 using Tapatalk

No its pretty universal as long as you have the appropriate inputs/outputs. Sent from my SM-N910W8 using Tapatalk

Greenfield ASV: http://www.greenfielddirect.com/automatic-security-valves/ FYI Greenfield is the OEM for the Elk valves Sent from my SM-N910W8 using Tapatalk

It was an example to demonstrate the scale of the (non-)problem. Even if the packet was 4-5 times as large, it would still be a trivial amount of data.

And you didn't actually read what I said. The events are not stored in persistent storage in the portal. Just long enough to send the event. You think Google or Apple store all the push notifications that are sent to them? And the crux of your original argument for filtering was bandwidth usage. Which has clearly been debunked. You had not even brought up a security argument until 30 minutes ago. As to your argument about seeing the traffic on your firewall, unless you're doing SSL interception on your firewall, all you're likely to see are a bunch of packets with no indication of their contents save for the fact they're going to your ISY. Hardly something conclusive to unleash the hounds upon. Don't get me wrong, I agree security is important. I'm also not opposed to any sort of event filtering. I don't think things like the logs need to be (or should be) sent to the portal. They can be pulled on request. And if you want to filter out events for certain devices/scenes/etc, I'd support that. But let's keep arguments rational and consistent.

Data/bandwidth is relatively cheap. On the scales we're talking about, it's a rounding error on your cell phone data report. If you're concerned about your cell phone data usage, turn off push notifications for the app. On the other end (the ISY side), on the average home internet plan (let's say your cap is 100GB, which is pretty low these days), it's %0.03 of your cap. Even for those with cottages in the sticks where you might only get get 5GB, it's still only %0.6 of your cap. So let's keep the scale of this (non-)problem in perspective. No one is talking about having every level 3 debug log sent automatically to the portal (or at least I'm not). What we're talking about is sending device events; a light switch turned on, a motion sensor tripped, the thermostat calling for heat. That type of thing. Yes, it needs to be appropriately protected, but the reality is if the UDI portal is hacked (or your portal account is hijacked), everything on your ISY is available to the hacker anyways. They just have to poll the data from your ISY, instead of it being automatically uploaded. Push notifications changes nothing about that. The state information doesn't even have to be stored on the portal once the notifications are forwarded. What it does do is make it more efficient and provides a better user experience for mobile users.

I wholeheartedly agree that binary protocols are more difficult to work with, but SOAP swung the pendulum so entirely in the other direction. XML made the protocol so gratuitous that it's difficult to parse, uncompressed it takes up huge amounts of storage, and loses the advantage of ASCII protocols being human-readable. There's a reason no one writes any new implementations with SOAP/XML anymore. I have no issues with JSON and REST, in fact it's quite lovely to work with. In fact, I believe UDI intends to abandon SOAP/XML long term, and move entirely to REST. My point about binary protocols was more to show that subscriptions need not consume inordinate amounts of data. Of course JSON can be efficient, and likely more than efficient enough for this use case. However, I believe even one of GCM's modes uses a binary protocol. In any case, I don't really care what gets used, as long as some workable solution is implemented.

Anatomy of an example IP packet for this application: [iP Header - 20 bytes | TCP Header - 20 bytes | ISY ID - 6 Bytes | Device/Node/Scene ID - 6 Bytes | Subnode/Event ID - 6 Bytes | Value - 8 Bytes] By my count, that's 66 bytes, and supports pushing 64 bit values Even if you needed a few more fields for whatever reason, it's still a trivial amount of data.

The answer is simple, don't wrap everything in XML tags, when a simple, efficient binary protocol will do. Especially for mobile push.

Here's what I would envision as the ideal scenario (James feel free to disagree with me/correct me): 1. ISY sends updates to ISY Portal for each state change (devices, scenes, variables, programs to start). 2. ISY Portal has an API for mobile app developers to hook into to subscribe to events from a particular ISY for their user. This can either be a continuous subscription socket, or connection initiated from ISY Portal Server on each event (ie REST call). Each mobile app vendor would run their own server that would subscribe to events from the ISY Portal. 3. Mobile App Vendor server submits the updates/notifications to the appropriate cloud messaging service (GCM/FCM/APNS) depending on what platform the user is running their app on. 4. Cloud messaging server pushes updates/notifications to app running on user's mobile device. For those concerned about the volume of data transferred, if an efficient binary protocol is used (ie. not XML), 100 bytes per event would probably be more than generous. Assuming a very high 10000 events per day, that would be 1MB per day, or about 30 MB per month. Unless your ISY is connected to a 3G device in Iran without a roaming plan, that shouldn't be a concern for most people. On the mobile device side, I believe Agave currently maintains an open socket with a subscription, so it's already receiving all the updates from an ISY, but with a much less efficient protocol, and as such is sucking up much more data (and no one is complaining about how much data Agave is using). What people should be complaining about, is that running a background process and keeping a socket open is sucking up BATTERY. Moving updates to being push-based rather than keeping a socket open will give longer battery life on your mobile device, and use less data than Agave is currently using. On mobile, battery life is everything. Also, running background processes and keeping an open socket is not even really an option on IOS devices. So UDI implementing an API that mobile app developers solves the problems for all mobile app developers, regardless of whether they're developing on IOS, Android, Windows Mobile, Amazon Kindle Fire, Windows Desktop, Mac Desktop, etc. What James wants will make for a better user experience, may stimulate competition for better mobile apps, and in general make cranky people like me happy

Will it still say "That was easy!" when you push it? Sent from my SM-N910W8 using Tapatalk

If I can ask another question. If the only reason for closing door is so you can arm your alarm system (and not actually provide any security), why not just remove the zone from your security system?

I'm guessing a checkbox for program status as well? Sent from my SM-N910W8 using Tapatalk