MWareman

It must be a state variable, then it will trigger. Integer variables won't trigger automatically.

Currently, there is a single key per portal user account (I believe). Create a second Portal user account for secondary users.. that way there is a separate key. Michael.

Using a browser results in a 'GET' request. It requires a POST request to work with the key. I do this all the time from Tasker on Android.

@ has special meaning in the URI - going between the username:password combination and the host. It's a delimiter. So, when you need to use it in the username or password field, it must be url encoded. That being said - you shouldn't need to use the username and password when making api calls to the ISY Portal. Get your IFTTT key and generate URLs with the key embedded - works like a champ!

I didn't know the Audio Chromecast dongles did this.... Is this documented anywhere?

Requests have to be POSTed to the portal. Make sure you are not making GET requests (the default).

Very odd... Definitely reach out to UDI support.

That's a new one to me! I would probably reach out to UDI support... Double check (in help/about) that firmware and UI match, just in case....

Update, rather than re-hash this, here is a link to the instructions. Michael. http://wiki.universal-devices.com/index.php?title=ISY_Portal_IFTTT_Integration

First, do you have ISY Portal purchased and setup? This is needed for inbound triggers from IFTTT. Second, you will need to add the 'Master' channel to your IFTTT account. The IsY Portal can provide you the URLs you need to paste I to the Maker channel in the ''Then' elements of rules. Well go thru step by step once we've confirmed you have what's needed. Michael.

Yes - it's the LCD controller that makes the system incompatible with iolincs.

I believe if you have your subscription extended, then your network module becomes tied to your portal subscription. Stop subscribing, it goes away. If you don't get your subscription extended, then the network module remains yours to keep regardless of keeping the portal subscription. I may be wrong on the first point, but that's my belief.

All-Ons are not necessarily generated by a PLM - they can be mis-heard by devices as well (none actually transmitted, but a protocol collision cause the event to occur on some devices with no log entry present on the PLM). We can either adjust programs to work around the issue (explained on the Wiki article) or replace devices with ones that ignore all-ons. This may not be about the PLM at all. The wait is a good place to start. But analyze other programs that may be triggered from this program turning off scenes as well.

It's Alpha, not yet Beta. It's considered only appropriate for developers on their non-primary system. That being said - several appear to be running it fine. YMMV - but keep a good backup!

Try stretching the window.... it's there...

Also - PC time may be displaying correct - but the zone config may still be incorrect. On a Windows machine, please try: wmic path win32_utctime get /format:list | findstr "Hour" This will return your systems current UTC time. That (currently) should be 3 (3am) - no matter what timezone is selected. If it's not - your PCs system time zone is wrong.

No, not ignoring - just trying to help the OP. Just asking that you try enabling NTP, setting a known good NTP server name (this is the one I have set, and I've confirmed it working), syncing NTP (not computer time), and setting the ISY to the correct timezone with the correct daylight savings rule applies. This is all to remove several variables currently present in an effort to identify the problem.

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.