MWareman

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.

Wireless garage door openers are, mostly, designed for security. Insteon is not (in fact it transmits without encryption, and devices don't authenticate incoming messages - so messages can be spoofed). There is a big difference between them, from a security perspective. Other than that, I fully agree with you @oberkc. It's somewhat nuanced, but given I've been able to observe and decode Insteon traffic, deduce important IDs and can (technically) issue commands without any kind of authentication required means any access control in my house is now either Elk managed or zwave (secure profile), where things are either hard wired or encrypted, meaning third parties cannot (easily) manipulate what's going on. To me, using Insteon for access control is rather like closing your front door but not locking it. Passers by will think your secure, but anyone trying the door is able to do bad things. Now, I hasten to add, this is my view. Personally, I automatically dismiss any Insteon access control from consideration now that I better understand the protocol.

To me, if an insteon command can open a door, then there is a security problem.... But that's just me.

The ISY is event based. The 'If' is evaluated on triggers contained within it (the KPL switched on or off locally, the beginning and end of the window in your case). If the 'If' evaluates to true the 'Then' is run. Otherwise 'Else' is run. This results in what you see. At the beginning and end of the window, the If is evaluated - but the KPL buttons are not true. So, Else is executed. The other ways to solve it are move the window to a folder condition and remove from the 'If'. This will restrict the KPL button from triggering evaluation outside of the window. Or have a separate program update an integer variable based on time of day (these don't trigger 'If' evaluation on change) and then use the variable as a condition in your 'If'.

When you hit the wait, the If will be reevaluated on any condition change. Closing the door within the wait period cancels the Then path and changes to executing Else, and the light won't get turned off. Either split it to two programs. One with your current Then (and no If) and change this program to 'RunThen' the new program. That way it won't get interrupted on the wait. Or, add a command to turn off the light in the Else, and it will get turned off as soon as the door is closed. Or, as above, use Control....

It does - yes. I have no delay in mine and the task runs perfectly every time. I have a Nexus 5 on AT&T if that makes any difference.

'Unknown host' means whatever you have for xxxxx.dyndns.org is not resolving in DNS on the network you are connected to after your WiFi disconnects. So - this could mean android has disconnected from wiFi (triggering the rule) but the phone has not re-established to the cell network. You could try adding a delay before the attempt to see if this is the reason. You should also ensure that your xxxxx.dyndns.org name is actually resolving to your external IP address. Michael.

As mentioned, deleting the PLM is a big no-no. It will remove all link records, rendering scenes useless. You are probable going to have to either restore a backup and then restore each device, or re-add each device individually.

Echo talks directly to the pseudo hue bridge, so I see no reason it cannot be done for ISY as well.... eventually.