MWareman

I currently proxy access to the REST and SOAP interfaces, and this works well. However, SOAP subscriptions fail due to the nature of the protocol. This means the admin console and apps like Mobilinc don't work well at all thru the proxy. Finally, I don't yet have websocket subscriptions working thru the proxy, but that's due to lack of time... I know its possible.

Interesting. With software, this could also enable a Rpi to represent any number of virtual devices and any type of device - each with a link to a physical PLM, and be a first class citizen in the ISY device/scene tree.

Google's authentication is relatively trivial to implement in a disconnected system - I've done it myself in tcl (F5 iRule). The only impediment would be allowing products like Mobilinc to continue connecting. Separate accounts would be one answer - but API keys would be FANTASTIC for things like the IFTTT Maker channel so we don't have to give away privileged credentials or deal with authorization headers at all.

I run an Asterisk PBX at home - and I used to get brute force attacks against the SIP stack weekly. I've had enormous success using fail2ban to shut this stuff down pronto. Make sure you whitelist your own machines though!

Good summary! Thanks. Been considering this myself, and think I'll end up going with the Davis, mostly because I'm a weather geek.... Following though to see if others have great ideas!

I've done that at one location. I disconnected the load from the switch and used a micro module to control the load. The decoupling allowed me to do this.

38W seems enough for loads connected to a switch with a neutral. I have many LEDs at 7w working without issue. I may have missed it - but are your switches three wire (with neutral) or two wire (without neutral)?

I've seen others images of the output of an Insteon dimmer at 100% - the waveform was clipped slightly. I just recently got my own digital storage scope, so I'll see if I can capture a waveform for myself when I get a chance.

I wonder if it's model specific then. I ended up buying another remote and soldering wires to its button. These wires (and a mag switch) are wired to my Elk - and the Elk reports to my ISY. Works well enough for me.

Thank you sir! That's pretty much what I thought. I would really like to get the native data GEM => ISY using the power module, but I have 32 CTs so it seems to be a non-starter currently. The DB is working well within its limitations - but I do notice the delay when trying to program laundry notification and fridge monitoring programs. I'd like to get rid of the delay and dependency if possible. I wonder if there are any plans UDI wise to expand the capability of the power module, since Brultech seem to have done their part?

Insteon dimmers are triac based dimmers (waveform clipping) rather than resistive. There are *some* loads that have problems with triac dimmers, since even at 100% the waveform is still slightly clipped. I have some LED non-dimmable bulbs that I have on relay based switches for this reason. On a dimmable switch at 100% they buzzed terribly...

So, I don't currently have the power module on ISY. I currently use the Dashbox to push power data to ISY variables. However, I can't help feeling I'll get better utility with the power module and being better able to correlate device status with power response. That being said - I don't even know if it will work. I don't have a Zigbee ISY - but my question is about sending over WiFi from GEM using protocol 11 (labeled as 'Universal Device ISY Format' - attached) Question: Can ISY with the power module receive the data from the GEM over the IP network (NO Zigbee) via protocol 11 from GEM into the power module on ISY? If so - do all 32 power channels show up? http://wiki.universal-devices.com/index.php?title=ISY-99i_Series_INSTEON:Electricityseems to suggest that ONLY the ECM-1220 is supported by the module (ECM-1240 is the current version from Brultech - indicating that the documentation is old...), unless you have Zigbee in which case the GEM is supported. I don't know if this is a documentation oversight - or real limitation. If the latter - are there any plans to support (natively) GEM data over the network - since Brultech seem to have done their part with the protocol implementation on GEM. I know - there is probably little to be gained as opposed to the Dashbox sending data as ISY variables. However - if I can reduce the number of variables I have it would be worth the $49 to me - and it's a way I can give back (more) to the cause! Michael.

I think you may be missing one or all of the following (I'm not sure which is your scene controller - if all of them are you'll need all three lines): In Scene 'Rooms / 6. GBR, Guest Bed Room / Devices / GBR-Bath-T1-A-Light-Load' Set 'Rooms / 6. GBR, Guest Bed Room / Devices / GBR-Bath-T1-A-Light-Load' 35% (On Level) In Scene 'Rooms / 6. GBR, Guest Bed Room / Devices / GBR-Bath-T1-C-Light-Load' Set 'Rooms / 6. GBR, Guest Bed Room / Devices / GBR-Bath-T1-C-Light-Load' 35% (On Level) In Scene 'Rooms / 6. GBR, Guest Bed Room / Devices / GBR-Bath-T2-A-Light-Load' Set 'Rooms / 6. GBR, Guest Bed Room / Devices / GBR-Bath-T2-A-Light-Load' 35% (On Level) It's a little confusing - you select the device in the 'In Scene' pick list - and then set the same device in the 'Set' portion and the local on level will be adjusted. As I show I set it back to 100% in the 'Else' section. You appear to only be adjusting the one level for the device in a scene (which is why it works for controlling the scene from ISY) - but not the 'Local' on level for the device. So - when you control the scene from the load device it's local 'on' level controls over the scene 'on' level - and the device will go to the current setting (default 100% if you have not changed it).

Can you post your program? This is mine for my bathroom... 'SC - Master Bathroom Light' is the scene - and 'Master Bath Light' is the controlling switch itself. I have a single switch - but I had to do two 'In Scene..... Set' commands. One for the scene - and one for the device. I suspect you only have this set on the scene and not the device(s). Michael. Dim at night - [ID 0055][Parent 0054] If From 10:00:00PM To 6:30:00AM (next day) Then In Scene 'Upstairs / SC - Master Bathroom Light' Set 'Upstairs / Master Bathroom / Master Bath Light' 49% (On Level) In Scene 'Upstairs / Master Bathroom / Master Bath Light' Set 'Upstairs / Master Bathroom / Master Bath Light' 49% (On Level) Else In Scene 'Upstairs / SC - Master Bathroom Light' Set 'Upstairs / Master Bathroom / Master Bath Light' 100% (On Level) In Scene 'Upstairs / Master Bathroom / Master Bath Light' Set 'Upstairs / Master Bathroom / Master Bath Light' 100% (On Level)

That does not work when you have the fancy door buttons - the GDO stops responding to shorts and the button loses power - meaning its clock gets reset. If you switch out the fancy button for a regular one, the GDO falls back to conventional operation.

I believe I've been pretty evangelical about NOT using Insteon for access control or life safety systems because I myself have been able to 'hack' my own system. All that's needed to take it to the next level is a SDR, listen for wireless Insteon signals, learn the addresses in a given installation and then start messing with link tables, turning devices on and off etc. No authentication at all. I'm sure you've all noticed that you can add a wired device to the plm link table without pressing any button on the device.... How do you think that works? By sniffing, its easy to learn the plm address and then send signals that 'appear' to be from the plm to any device to control it. Smarthome could have extreme liability for selling the iolinc as a garage door solution. Zwave does not have this issue because you must have physical access to the device.

Yes. Notepad++ is a different tool than Notepad. https://notepad-plus-plus.org

Watch out - I'd avoid the Estimote beacons until they sort out their security model..... http://makezine.com/2015/08/04/beware-hackable-google-beacons-made-by-estimote/

You don't have to use Excel - the export is a .CSV file - you can open it in many programs. I use Notepad++

Just cannot be Windows RT (so make sure its Surface 1 Pro, 2 Pro and either 3 Pro or Standard) and it will work fine.

Integer variables won't trigger programs. In your first, try sTemp_Backyard instead of iTemp_Backyard and adjust the threshold accordingly.

Once things are fleshed out and stable, these things often end up being copied to the wiki.... Easier to find that way.

Sorry - wrong thread!

To add to this, my three range extenders did not help my locks at all. I replaced then with the sirens (same locations), and I now have 100% reliable communication with my locks. Now, maybe I didn't include my range extenders when they were close to my ISY then move them. That could explain it (too far to be able to exchange keys). However, I also didn't do that with the sirens.

Differing technology though - modern garage door openers use rolling codes, and even newer ones have actual encryption in use. Older openers used a static code - and those are worse than Insteon from a security perspective. I think the older 'random' openings are with the static code openers - many of them are (unfortunately) still in use today. I saw a modified kids toy a while ago able to open these static code doors within seconds and on demand. It's scary that so many people still use them! When I say 'designed for security' I'm referring to the latest generation of openers. All of what you say though otherwise is true - security is a set of choices and compromises. To make those choices though people need to know that Insteon is not a secure protocol - and they can make their choices from there. Insteon can be monitored and spoofed. And it's not too difficult.