MWareman

So - Apache is failing to start with the new config in place. You'll need to figure our why - something is missing.... With the new config (the one that fails) - what does: apachectl configtest reveal? Also - anything in /var/log/syslog when you try to start Apache with the new config ? Michael.

Can you send me what your virtual host config was before? (You said that you had backed up the original). Basically, someone is throwing an error, causing Apache to fail completely. You'll need to find out why that's happening from the logs. Michael.

I also note that http://www.homeonthewater.com/ redirects to http://homeonthewater.com/ - but they resolve to different IP addresses. Is this expected? Michael.

If you're getting 'Connection Reset' to which URL? As an FYI - if the authorization line isn't correct - you will get double prompted for credentials. Since this isn't happening here - this isn't the (immediate) problem. If it's one that doesn't match the ProxyPass lines - it probably means there is a syntax error and Apache isn't listening on the port. Anything is the error files? What happens if you restart Apache - any errors? Michael.

Make sure you've removed the 'ServerName' line! I believe you're not doing name based virtual servers - and this may be messing things up. Apache is doing 'pre-auth' - separately authenticating you. This allows you to use a separate credential for your published site. However, in order to present the correct credential to the ISY - ISYs username and password are needed. That's what the header insertion is doing for you. Michael.

The 'Authorization' string shouldn't be simply the ISY username OR password. It's needed in a standardized 'Authorization' format ("username:password" then base64 encoded). See https://en.wikipedia.org/wiki/Basic_access_authentication Client side[edit] When the user agent wants to send the server authentication credentials it may use the Authorization field. The Authorization field is constructed as follows: The username and password are combined with a single colon. The resulting string is encoded using the RFC2045-MIME variant of Base64, except not limited to 76 char/line. The authorization method and a space i.e. "Basic " is then put before the encoded string. For example, if the user agent uses Aladdin as the username and OpenSesame as the password then the field is formed as follows: Authorization: Basic QWxhZGRpbjpPcGVuU2VzYW1l

Another thing to consider. If you are not using name based virtual hosts - please remove the 'Servername' line! You are issuing a redirect from 'www.homeonthewater.com' to 'homeonthewater.com' - but the 'ServerName' function will cause this configuration to be ignored - because the hostname does not match. Removing the 'Servername' line will allow the virtual to be used for all hostnames... Michael.

Also - have you created /etc/htpasswd-isy? Use: htpasswd -c /etc/htpasswd-isy user ..then set the password to protect your site... (change 'user' to your desired username).

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.