MWareman

I think (when in Auto), you need to pay attention to the recent ambient outside temperature to decide if heat or cool setpoint needs adjusting. It was 82 outside when I did this - it made no sense to change to heat mode - but that's what the algorithm demands. The heat setpoint was 68. The cool setpoint was 74. The mode was auto. The ambient inside was 74. I asked for 75..... How about adding this logic? If increasing the heat setpoint to the requested temperature is higher than the current cool setpoint - then change the cool setpoint instead. Also, don't change the mode. Leave it auto.... What if it's currently 70 in the house (70 heat setpoint) and cold outside, and I want to reduce the heat setpoint to 68? The algorithm fails then as well... The AC would go on, possibly damaging the compressor. This needs another check... In mode 'Auto' - you need to factors both the current heat and cool setpoint - not just the cool one. Michael.

I think that's the problem. I wanted to increase the cooling setpoint above the current ambient temperature..... a pretty common operation in my house, in the never ending battle of the AC.

It was auto, setpoint 74, current temp 74. It's hot outside, so the system is either cooling or in standby at the moment. I wanted to increase the cooling setpoint to 75 - not the heat setpoint! I think by asking for 75, and 75 being greater than 74, it changed the mode to heat and set the heat setpoint. Not what was intended at all.... Michael.

We got it working across chrome, Firefox and IE, with Chrome on Android and Safari on IOS. I have not looked at others. It does require a recent build of ISY though - there were fixes made to make it work (detailed in the thread I referenced). A Websocket connection is far more network and battery efficient that polling... Michael.

Upgraded to v2 easily. Thanks! My stat was set to auto mode, currently cooling to 74F with the house measuring 74F. I asked Alexa to 'Set thermostat temperature to 75 degrees', and Alexa understood perfectly according to the history. The ISY changed the thermostat mode to 'HEAT' and the setpoint to 75 - causing the furnace to come on! Oops... Alexa metric is off. The thermostat is a Trane TZEMT400BB3NX.

I provided an example that's certainly on here somewhere, and may even be on the Wiki already.... Edit: see here: http://forum.universal-devices.com/index.php?/topic/15248-Problems-Creating-a-WebSocket-connection Michael.

If you truly have a 99i (rather than a 994i), it's likely that your ISP is now not accepting the older crypto that the 99i uses, leading to the TLS failure. If it is a 99i, do you have the PRO or standard one? If PRO, there are some additional steps we can try (in the Dashboard). Otherwise, there are two options: 1) Disable encryption Or 2) Take advantage of UDIs continuing generosity, and upgrade to the 994i, which supports modern crypto.

Insteon does not support any command to turn a scene on to anything other than 100% of the scene - or off to anything other than 0%. This is not an Alexa limitation - but an Insteon one.

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.