MWareman

I also notice that NTP is disabled. If 'Sync the clock with computers time's was pressed with a zone or DST mismatch, this could cause an offset to UTC to be present, resulting in the wrong time being displayed. So, enable NTP, change it to 'pool.ntp.org', select the 'US, MI, Detroit' zone, ensure 'US-Canada' is selected for the daylight saving rule and then 'Synchronize Now'. What happens?

The screenshot shows Seattle selected.... Either way, the box is greyed out as long as you have a 'Daylight Saving Rule' selected (which you do - 'US-Canada'). Change this to 'Off' to turn off daylight saving rules altogether to test. This could also indicate the the date is wrong. Have you confirmed this? Do your sunrise/sunset times make sense?

What if you toggle on DST? Central time (where I am) is -5 now, but -6 in the winter. I suspect you have this setting incorrect, as east cost should be -4 at this time of year. Darn daylight saving!

GMT-4 is what's displayed with any east coast location and DST selected - sunset enabling DST adds one during the summer the the -5 that applies in the winter.

I think you may be selecting the incorrect action. The action you specified actually adjusts the membership of a scene (it's under 'Adjust Scene' - this is not what you want to simply turn a scene on or off). To simply turn a scene on or off select 'Your Device' then 'Set' <scene name> On. Create a scene with ONLY your KPL button in it. Give it a name. Turn it on (or off) as above.

Any device in a scene as a controller is also a responder to the scene. Putting a device in as a responder means it's only a responder.

Multiple login prompts are usually the result of ISYs address not being trusted by Java, or an Antivirus program, or both.

When you set scene on levels, you are setting only that controller - the ISY by default. You will need to copy the on levels to other scene controllers. I'm away from my system currently, and am currently unable to remember the specifics though. I think you would select your KPL within the scene.

Don't put a wait into a then clause with momentary if clauses. It won't wait! Once the if changes back, the wait is cancelled. Create programs with the If to set a state variable to '1' based on your various lock state triggers. Have a second program triggering of the state variable being '1', wait 30 seconds and turn it back to '0'. Mark this program to run at startup. Have a third program that looks for the needed combination of state variables to do what you want to do. For the KPL button, create a new scene and add the KPL button to it. If the KPL button is now a controller of another scene, I believe it will add automatically as a controller. That's OK. You should be able to have the program turn that scene on or off (changing the button state) quite easily.

Likely, yes. Even with static assignments, there is a lease time after which the lease must be renewed, requiring the original DHCP service that initially granted the lease to be available to renew it. Sometime during the lifetime of a DHCP lease, clients send a packet to to the original DHCP service that gave the now expiring lease to ask 'is it OK I keep using this address?'. If it gets no answer, it tries again (3 times I believe). If still no answer, or the original DHCP service is no longer available, the client does a full DHCP acquire again. With no static assignment, there is no assurance of getting the same address at all. Could you have two DHCP services on your LAN? Might you have reserved the address in only one of them? I'd confirm you only have one by looking at all your dhcp clients and checking to see the address of the DHCP server they got their address from, to be sure.

That can happen if the DHCP service is not available during the ISYs boot or address renewal (which will normally happen 2/3 of the way thru the address lease, configured on your DHCP server).

I have this. It wires in like an additional sensor, but triggers a dry contact. It's designed to trigger a strobe for the hard of hearing. You can connect this to an io-link to have 'ISY act on it, though this is against fire code in some parts of the world. So, check with your local code officer if you are unsure. Edit: This is it.. http://m.homedepot.com/p/First-Alert-Smoke-and-Carbon-Monoxide-Alarm-Relay-Module-RM4/204357245

Also worth noting, in case you have not discovered this yet - you need to make sure that emails have both a subject line and a message body. If either are blank, you'll get an error. Sent from my Nexus 6P using Tapatalk

I repeat the above, upgrade to the latest 4.x, it has adjustable font size. I'll add that UDI is also working on a HTML5 admin facility.... so hang in there!

http://wiki.universal-devices.com/index.php?title=ISY_Portal_MobiLinc_Configuration

Basically - I found that the API was changed. You used to be able to call /api/isys and get the description of the portal account. Now, you have to get the ID from a different call first, then pass that ID with your /api/isys call... as follows: GET https://my.isy.io/api/domains/lookup with basic authentication (Portal username/password). Get the _id value... GET https://my.isy.io/api/isys?domain={_id}&subaccounts=false (replacing the {_id} with the received _id from the first request).

I started getting that with my app, and recently updated it with the fix. When I get to a real keyboard I'll let you know what it was....

I think that right there captures the distinction between subscribing to a Portal, and rolling your own. What correct for each person depends mostly on their wheel making skills.

Also, hopefully this is a secondary photo sensor, since not having one dedicated to the GDO safety circuit would be illegal in most parts of the country.

You can also configure the Mobilinc app to work against the ISY portal, without needing the ddns or port forwarding. It's a little bit of FUD from Mobilinc I'm afraid. They are really meaning that it's unsupported. They shouldn't be saying it won't work (because it does work) - and certainly shouldn't be pressuring people into spending $5 more per year making this claim for a Portal product that (in my opinion) is less secure. They require you to give your Mobilinc password to IFTTT if you want to integrate there, rather than the token method that UDI has implemented (which is way more secure). Also, Mobilinc only have an Alexa skill - while ISY Portal gives you a Skill as well as native Connected Home functionality - and the bonus network module for local IP control.

Not once have I said cloud is free.... Cloud has costs. In many cases, vendors have alternate income streams such that they can absorb the cost of the service, making it appear free to the consumer. Amazon do this (to run the cloud services behind Alexa). Smarthome do this (to run the cloud service behind the Hub). Wink also do this... thru their logo program manufacturers pay them. IFTTT is a 'free' (to consumers) cloud service, that costs vendors $1000's per year to be on. My concern it with buying a device that won't run without its associated cloud service. ISY is *not* in that category. That being said - I also want to integrate with some cloud-only services that I simply cannot do directly, but I can easily do via the Portal (and it's IFTTT capability thru the Maker channel). I can tweet a command to my home and have my home react to it - via IFTTT (maker channel) and the portal for instance. I can send a text message to my Twilio number and have my ISY respond to it - again via the Portal. I couldn't do this before the Portal was available. Now, these integrations can also be put together 'for free' using mostly open source software and hardware. However, ID rather pay $25/yr for this to just work than invest the many hours that would otherwise be required.

If you were to invest hundreds of man hours coding a solution, paying for EC2 compute to run it on, EBS to store it, and a CDN and load balancer to make it highly available - wouldn't you charge your customer for access to it if it brought them value? For most of us, the portal brings way more value than the $25/yr cost of entry. Well beyond simply speaking at Alexa and having her control lights. The IFTTT allows interaction with other (in many cases) cloud only services. The network module that you get with the Portal subscription allows you to control arbitrary local resources, like Sonos for example. You will be able to send push notifications with Pushover, Pushbullet (and others). The possibilities are endless.

Did you hear of Rovolv? The product got killed a few weeks ago. If you bought it (nearly $300) you now will soon have a brick. No refunds. Because the cloud service is being shut down. That's the cost of 'free'. It's often unsustainable. Because it costs... every.single.month to run the necessary server infrastructure. There is no 'cloud' - only some else's computer that you are renting. Personally, I don't want my (significant) investment to become obsolete - so I'm willing to pay for it to be a sustainable business model.

That $70 is three years of subscription. If you switched to the Hub, your ISY would mostly gather dust. It's *not recommended* to mix two Insteon controllers. It's either ISY or the Hub (unless your pretty advanced in device link management). An Insteon device is only generally linked on one controller.

Yep. This works for many as well - but it does require some Linux tinkering - if you're up for that. Also likely requires buying a Rpi (or similar) to run it. There is also Mobilinc Connect - they have an Echo integration as well for $29.99/yr - but it's only a Skill whereas the ISY Portal offer both a skill and the native Connected Home API. Honestly, my feeling is the $25/year for the ISY Portal is worth it in time saving compared with rolling your own. The ISY Portal subscription also gives you the ISY Network Module included for free, and IFTTT integration.