giesen

That may be true south of the border, but its all metal boxes up here and there ain't no BX to be found (at least in resi)

I'm sure Michel will chime in here at some point but I couldn't agree more with Teken. The ZigBee solution on the ISY supports only the SEP profile and as such can't be used for anything but Smart Meters. Giving up Z-Wave for it is not worth it IMHO, as there are other solutions for power monitoring, and since Insteon is not exactly the most secure protocol, it's worth having just for the the locks alone. Out of curiosity, is the problem with your power utility a policy one (ie they won't let you connect to your meter), or a technical one? (they've been unable to figure how to make it work with your ISY). If it's the latter, I'm sure ISY could provide some assistance as I believe they've worked with customers and utilities in the past to make it work. If it's the former, I have little faith that will ever change (I certainly don't expect my local utility to offer it, even though I'm already on their Demand-Response program; they shut off my air conditioner during periods of peak demand). That being said, I believe at one point UDI was working on the ability to have multiple ISYs connected together so you can have both Z-Wave and ZigBee simultaneously. Not sure how far they got with that, as I know there are a lot of demands on their development resources to get the Z-Wave stack matured and get 5.0 out the door.

If you do get at it again, what you *should* see in the junction box are 2 black wires (hot), 1 white wire (neutral), and a white wire with tape on it (typically red or black - this is the "load" leg from the switch). The neutral wire (white) with no tape should go directly to the neutral on the fan. The two hot wires (black) should be tied together with a wire nut. (Should not go to fan) The last white wire (with tape - "load" wire) should be tied to the hot (black) wire from the fan. Note that it is not uncommon for the load leg and the hot leg from the switch to be reversed (ie the black wire from the switch goes to your fan, and the white wire from the switch (which should have tape on it) to be tied to the hot from the panel. Functionally it doesn't matter. If there's no tape on either of the white wires, the one that is either tied the hot black wire in the junction box, or tied to the fan hot, *should* be the one from the switch. To be able to tell for sure, turn off the breaker, disconnect and separate all the wires (so they don't touch), turn the breaker back on, and carefully check with a multimeter which pair is live. That is the pair from the breaker panel, and the other pair is your switch loop.

I myself just rewired the same thing (for a switched lamp outlet) in my 1950's house. Wasn't fun but I wanted a dual band insteon dimmer that supports LEDs (the RF-only 2-wire dimmer doesn't). Current construction now always pulls a neutral and caps it for this reason. And if they don't, they should be shot. I have at least 4 more of these to do in my house, most in far more inaccessible locations (this one *only* required 4 holes in the drywall - and it was the relatively easy one)

Yeah I didn't mean actually pull the API, but publish a notice in the release notes that's it has been deprecated and will be removed at some point in the future. Developers will have time to move their apps to the new APIs and new developers hopefully won't write something new using the deprecated API

Perhaps the release of 5.0 might be a good milestone to deprecate (at least officially) the SOAP API and encourage developers to move to websockets?

Yes, that and implementing something like fail2ban which watches your log files and will block any IPs that unsuccessfully attempt to authenticate a number of times. And change your default passwords.

Michel, The problem is I might run eKeypad, wait 4 seconds, then switch to another app, do something, then switch back and I have to wait another 4 seconds. Or the screen on my phone times out then I have to wait 4 seconds again. Not a great user experience. Now the blame is not entirely on UDI, since eKeypad doesn't support session persistence, but the result is the same. Is 5.0 expected to have a new API that is proxyable?

Michel, You yourself said it still takes 3-4 seconds for the initial connection (HTTP is instant), which is my main complaint. I haven't tested, but if the default 512 bit certificate is swapped out for a 2048 bit, does that still hold true?

Another option is we could figure out a way to proxy through Apache running on a Raspberry Pi, then logs could possibly be monitored and bad actors blocked. There's a few big concerns I see with security on the ISY: - SSL is so slow as to be almost unusable - Can't proxy SSL through another machine and still get live updates or Admin console - Doesn't support HTTP Digest authentication, so that even if HTTP (not HTTPS) is used to work around the above problems, at least your password is still mostly protected (though still vulnerable to MITM attacks) - Doesn't support multiple user accounts or an API key, so at least you could have throw-away passwords If any of these points could be addressed (particularly the first three) I think it would do a lot for the security of the ISY

Michel, It does seem to reuse the session if I keep the application in the foreground. Once it launches (and waits about 10-15 seconds to connect to the ISY), it takes about a second to turn on a device. The problem is, as soon as you switch to another app or the phone goes to sleep, it's takes another 10-15 seconds to connect again. Not sure if this is a poor implementation on the part of eKeypad or if it's a limitation of the iOS multitasking API (I suspect the latter), but with HTTP it's nearly instantaneous to load and then control. Hence my suggestion of implementing HTTP Digest authentication. It wouldn't require a rewrite of your access control model, just the implementation of the digest mechanism. Still not a trivial task I'm sure, but hopefully a lot easier than some of the other (worthy) suggestions. Another alternative would be to implement support for multiple users, so I could assign a different user for each device using the REST API, and at least if one is compromised I just reset the password for that one device. Kind of a backdoor way of implementing API keys.

Michel, While we're discussing authentication, would it be possible to implement HTTP Digest authentication (RFC 2617 - http://tools.ietf.org/html/rfc2617) instead of HTTP Basic Authentication? SSL is just too unacceptably slow (takes about 5-10 seconds to turn off a light switch from eKeypad vs almost instantaneous using plain HTTP) but I'd like to have more protection of my password than plain HTTP Basic Authentication provides (that is, none). Is this a possibility?