MWareman

I really hate Tapatalk sometimes.... the quotes get really messed up! OK - lets try a different one.... you used the one that proxies everything except one path. You need to use proxy nothing except the needed paths, as follows (for you): <VirtualHost *:80> ServerName www.homeonthewater.com ServerAdmin webmaster@homeonthewater.com DocumentRoot /var/www/html ProxyRequests Off ProxyPreserveHost On KeepAlive On KeepAliveTimeout 5000 ProxyVia Off <Proxy *> AuthName "Authentication Required" AuthType Basic AuthUserFile /etc/htpasswd-isy AuthGroupFile /dev/null require valid-user Order deny,allow Allow from all </Proxy> RequestHeader set Authorization "Basic xxxxxxxxxxxxxxxxxxxx" ProxyPass "/rest/subscribe" "ws://192.168.0.171/rest/subscribe" retry=4 ProxyPassReverse "/rest/subscribe" "ws://192.168.0.171/rest/subscribe" retry=4 ProxyPass /rest http://192.168.0.171/rest ProxyPass /services http://192.168.0.171/services ProxyPass /WEB http://192.168.0.171/WEB ProxyPass /USER http://192.168.0.171/USER CustomLog ${APACHE_LOG_DIR}/access.log combined ErrorLog ${APACHE_LOG_DIR}/error.log </VirtualHost> You cannot change port 443 to port 80 without removing the SSL lines. You don't appear to have fixed this line: RequestHeader set Authorization "Basic xxxxxxxxxxxxxxxxxxxx" xxxxxxxxxxxxxxxxxxxx needs changing to the correct authorization header for your ISY! Otherwise - it won't be able to authenticate to your ISY. Be careful when reposting - you don't want to advertise your ISYs password! Place the socket.htm in /var/www/html. Access it with www.homeonthewater.com/socket.html Michael.

I would get this working without the certificate first..... I've updated the examples to not depend on working SSL, as this only deflects from the primary mission here.... There are novels that could be written about SSL...

I have completely flipped the example around - since I have realized that most people will want most content served from the local Apache - and only proxy specific functions to the ISY. So - the example now published the whole site thru Apache - and only proxies the /rest, /WEB and /USER virtuals, to allow rest API to work (including websockets), UDajax and HAD also work fine. This WILL NOT work for the admin console or Mobilinc - since they both perform SOAP subscriptions.

I've figured out the blank page - it was a typo in the link. Fixed now... sorry! Also - I figured out an error in my second example.... use this one instead... This will server the whole virtual locally - EXCEPT the /rest, /USER and /WEB roots - which will be proxied. This allows UDajax and the default HAD to still work thru the virtual... while also allowing you to have a fully customized root site. <VirtualHost *:80> ServerAdmin webmaster@lights.domain.com ServerName lights.domain.com DocumentRoot /var/www/lights ProxyRequests Off ProxyPreserveHost On KeepAlive On KeepAliveTimeout 5000 ProxyVia Off <Proxy *> AuthName "Authentication Required" AuthType Basic AuthUserFile /etc/htpasswd-isy AuthGroupFile /dev/null require valid-user Order deny,allow Allow from all </Proxy> RequestHeader set Authorization "Basic xxxxxxxxxxxxxxxxx" ProxyPass "/rest/subscribe" "ws://192.168.1.2/rest/subscribe" retry=4 ProxyPassReverse "/rest/subscribe" "ws://192.168.1.2/rest/subscribe" retry=4 ProxyPass /rest http://192.168.1.2/rest ProxyPass /WEB http://192.168.1.2/WEB ProxyPass /USER http://192.168.1.2/USER CustomLog ${APACHE_LOG_DIR}/access.log combined ErrorLog ${APACHE_LOG_DIR}/error.log </VirtualHost> I cannot comment on isyProxy - it may be that this is not needed at all once the Apache proxy is set correctly. Michael.

These examples are virtual host configs. On the Wiki, there is a .htaccess file as well as both are needed for a complete solution. The auth type and require are to authenticate access to the proxy - not the local content. It's important that both use the same auth source - otherwise it won't work. In my case, I want everything to proxy to the ISY - so I have a single subpath that I don't want to proxy - that's why I have it that way in the first example. The second switches it around - only proxy the /rest subpath and serve everything else from the local Apache. For your case, the second example is what you need. You'll still need the other elements as I describe on the Wiki though. When you say the Wiki is blank, what page do you mean? I tried it again, and the examples are there. Michael.

This is the example I put on the wiki (it proxies everything to ISY including the websocket subscription - except for the /custom path which is sent to the path /var/www/lights/custom for serving): <IfModule mod_ssl.c> <VirtualHost *:443> ServerAdmin webmaster@lights.domain.com ServerName lights.domain.com DocumentRoot /var/www/lights ProxyRequests Off ProxyPreserveHost On KeepAlive On KeepAliveTimeout 5000 ProxyVia Off <Proxy *> AuthName "Authentication Required" AuthType Basic AuthUserFile /etc/htpasswd-isy AuthGroupFile /dev/null require valid-user Order deny,allow Allow from all </Proxy> RequestHeader set Authorization "Basic xxxxxxxxxxxxxxxxxxxx" ProxyPass /custom ! ProxyPass "/rest/subscribe" "ws://192.168.1.2/rest/subscribe" retry=4 ProxyPassReverse "/rest/subscribe" "ws://192.168.1.2/rest/subscribe" retry=4 ProxyPass / http://192.168.1.2/ CustomLog ${APACHE_LOG_DIR}/access.log combined ErrorLog ${APACHE_LOG_DIR}/error.log SSLEngine on SSLCertificateFile /etc/ssl/certs/wc.domain.com.pem SSLCertificateKeyFile /etc/ssl/private/wc.domain.com.key SSLCertificateChainFile /etc/ssl/AlphaSSLchain.crt </VirtualHost> </IfModule> This example will serve everything from /var/www/lights - EXCEPT for /rest (which will be proxied to the ISY and handle the websocket subscription): <IfModule mod_ssl.c> <VirtualHost *:443> ServerAdmin webmaster@lights.domain.com ServerName lights.domain.com DocumentRoot /var/www/lights ProxyRequests Off ProxyPreserveHost On KeepAlive On KeepAliveTimeout 5000 ProxyVia Off <Proxy *> AuthName "Authentication Required" AuthType Basic AuthUserFile /etc/htpasswd-isy AuthGroupFile /dev/null require valid-user Order deny,allow Allow from all </Proxy> RequestHeader set Authorization "Basic xxxxxxxxxxxxxxxxxxxx" ProxyPass "/rest/subscribe" "ws://192.168.1.2/rest/subscribe" retry=4 ProxyPassReverse "/rest/subscribe" "ws://192.168.1.2/rest/subscribe" retry=4 ProxyPass /rest http://192.168.1.2/ CustomLog ${APACHE_LOG_DIR}/access.log combined ErrorLog ${APACHE_LOG_DIR}/error.log SSLEngine on SSLCertificateFile /etc/ssl/certs/wc.domain.com.pem SSLCertificateKeyFile /etc/ssl/private/wc.domain.com.key SSLCertificateChainFile /etc/ssl/AlphaSSLchain.crt </VirtualHost> </IfModule> As mentioned in the wiki, this requires the mod_proxy_wstunnel and mod_proxy Apache modules. You'll need to customize the Authorization header to be correct for your ISY. You'll need to create a password file (/etc/htpasswd-isy), and you'll need to customize all paths and addresses to be appropriate for your setup. Also, this is an SSL virtual. Change the port to 80, remove the SSL lines and remove the mod_ssl.c check.... Michael.

Hi Mark, After our PMs, I've put an example on the Wiki at http://wiki.universal-devices.com/index.php?title=Apache_Reverse_Proxy There is a name based virtual host config there that proxies everything except one path to the ISY, with the ability to host in that path anything (including a websocket emblazoned JavaScript page) - I have my test websocket page working successfully, served from Apache. You would have to change the names, directories, paths etc to have this work for your own system. I can certainly flip this as well - serve everything from Apache except the REST API (which would be proxied to the ISY). Authentication would be a challenge for this scenario though. Let me know if your interested in the changes for this. Michael.

This would be expected if the temperature at the time you issued the command was warmer than 76 - the algorithm currently turns on cooling mode and air-conditions down to the new setpoint. IMO - this will cause an issue when it's below zero outside, 78 inside (auto mode) and I ask to set the temperature to 76. Currently, ISY will turn on the chiller - potentially damaging it. Only solution is to not use auto mode currently.

Still not resolved for me this morning...

Benoit, I mainly use the IFTTT/Maker skill for programs - and havnt used the ISY skill for a while now. There is probably value though for those that don't use IFTTT. Michael.

@stusviews - I think you're using the web version - M y screenshot was the app (Android tablet). Point is - the old version is still discoverable - even though it's not supposed to be. Also, I thought the v2 API combines smarthome and skill APIs - meaning separate modules are not needed anymore. Should we be removing the skill? Or is that still needed for 'ask izzy'?

Benoit, Here is a screenshot within the Alexa app when I search for 'ISY'. The old version is still installable.... Michael.

Yeah, I habe wondered how long before a malicious skill makes it to the Alexa 'app store' - but the need to use the authenticated Alexa app kind of mitigated the risk somewhat. Now, anyone in vocal range of my Alexa can deploy any skill without needing any credential, meaning the risk is now higher.

I guess I'll switch to heat or cool instead of auto, and write some programs to replicate the auto logic....

Where I am (Chicago area), the transition between hot and cold lasts over a month (generally). 'Auto' allows me to not have to flip my stat often multiple times a week during the bi-annual transition. We heat to 68, but cool to 75. Hearing to 68 feels comfortable to me - but I never want to cool to 68 (far too cold) Cooling to 75 feels comfortable to be - but I never want to heat to 75 (feels far too warm!) Not sure why this is - so my stat has been in Auto mode for years now - quite often a hot day will require some a/C to keep temp from rising above 75, then a couple of days later needs some heat overnight to prevent falling below 68. Auto is the only mode that can handle this well. I am truly concerned about the possibility of damage to the compressor, since the algorithm allows the compressor to come on when it could be cold - I think that was unintended, but warrants rethinking that section of the algorithm. Maybe even not allowing the temp to be changed if the stat is in 'Auto' mode until Amazon can address the limitation. One other issue here is the automated switching between modes. It's done in the name of adjusting quickly (which I get), but unless ISY changes the mode back once the temperature is achieved then I can see problems ahead. Bottom line, if the stat is in Auto mode - it shouldn't be taken out of auto mode, and since we don't know which setpoint needs adjusting, perhaps an error should be thrown instead. Isn't feedback the point of a test?

Agreed. Maybe ISY simply needs to keep track of the last stat operation (when in Auto mode). Was it heating or cooling last time it was calling for anything? That's the setpoint to adjust.....

Benoit, You said: If mode is Auto - If current temp is above X, I set cool setpoint at X - else, I set heat setpoint to XWhat if it's cold outside, the stat is in 'Auto' currently 70 in the house (70 heat setpoint), and I want to reduce the heat setpoint to 68? Under this algorithm, the cool setpoint would be set to 68, and the A/C compressor would come on - likely damaging the compressor! This is a real problem that needs solving - or else if the stat is in 'Auto' mode an error should occur. There is risk of actual damage here. You probably shouldn't be trying to get to the target temp 'as quickly as possible'. If it's warm outside, and we want an increase - we simply need to cool less - not apply heat! If it's cold outside, and we are asking for less heat - we shouldn't be using the A/C - we should be heating less. Like I said - the algorithm needs recent external temperature to make a correct choice. Or - look at the last operation the stat was doing (was it last cooling or heating?). Michael.

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.