Modifying device attributes fails with 401 and HTTPS for client app fails with Windows WAP

Hi Florian,

First I want to say thank you for your work. It's inspiring, and I love that you've stepped up to fill a huge need for an offline assistant in home automation.

To my problem. Admittedly, I'm reasonably new to SEPIA. I've tried to follow much of the documentation on setting it up, and I'm hitting a few brick walls. I have SEPIA installed and connected to my OH 3.3 hub. Both are running on the same Raspberry Pi. I'm able to see the devices, but when I attempt to edit any of the attributes, I get a 401. The sepia-assist-server/log.out file shows the following response: {"code":401,"error":"{\"error\":{\"message\":\"Authentication required\",\"http-code\":401}}","HTTP_REST_SUCCESS":false}

I understand what this means, I just don't know how to fix it. I noticed smarthome_hub_auth_type and smarthome_hub_auth_data in the core settings and cannot help but think these fields might solve my problem. I just don't know how to use them properly. Can you point me to any documentation on how to authenticate to my OpenHab hub through SEPIA? Hopefully this can be acheived with an API token/key.

Also does Sepia not create it's own internal database of these devices for it's own reference that it can map back to the hub devices? It would make vanity names for the devices much easier (not that I can't just configure this in the OH hub).

Second issue is that I didn't want to run a nginx as a reverse proxy because I already have a Windows WAP running in my lab that I can use. So I've successfully published endpoints using a LetsEncrypt SSL certificate with a host of smarthome SANs for all of the apps running on my Raspberry Pi. I've published URLs for assist-server, teach, and chat, but when I authenticate to the web client (/app/index.html), it shows that SEPIA is offline. Again, can you point me to some documentation that outlines the process of setting this up. I skimmed over something that talked about setting up nginx with DuckDNS and a LetsEncrypt cert, but that was for external availability. I'm not even to the point where I'm making it externally available. I just want to host it securely internally first before I consider opening it up to my phone when I'm away from home.

Again, thanks for the great work! Looking forward to more. And I appreciate any advice/pointers/docs.

Cheers,

John

Hi there, im also relatively new to this but try to help. In my case it works:

OH: Generate a token Disable basic auth Item-Definition with metadata for sepia for example: Switch dLedStrpBedRoom_Swt (dDevLeavFct_GrpSwt) ["sepia-name=LED", "sepia-type=light", "sepia-room=bedroom"]

Sepia Control Hub Core-Settings: (logged in as admin) smarthome_hub_host = http://YOURIPFOROPENHAB:8080 smarthome_hub_name = openhab smarthome_hub_auth_type = Bearer smarthome_hub_auth_data = YOURTOKENFORSEPIA

Now you should find all the devices in Sepia Control Hub > Smart Home > Load Hub info > GetDevices: All

I had the same journey and now afterwards everything makes sense to me ;-)

First I want to say thank you for your work. It's inspiring, and I love that you've stepped up to fill a huge need for an offline assistant in home automation.

Ty, hope you'll like SEPIA :smiley:

Can you point me to any documentation on how to authenticate to my OpenHab hub through SEPIA? Hopefully this can be acheived with an API token/key.

It can. There was a longer discussion a few weeks ago, maybe it can clarify things: https://github.com/SEPIA-Framework/sepia-docs/issues/44 I've also updated the official docs section a while ago to be a bit more precise. @SHU-red tips should get you started as well.

Also does Sepia not create it's own internal database of these devices for it's own reference that it can map back to the hub devices? It would make vanity names for the devices much easier (not that I can't just configure this in the OH hub).

This is possible via the so called internal HUB. The drawback is that devices are not automatically detected but must be created by hand with the information about your HUB (openHAB), device URL etc.. The advantage is that you can mix a lot of different "HUBs" ore barebone MQTT etc..

I didn't want to run a nginx as a reverse proxy because I already have a Windows WAP running in my lab that I can use [...] can you point me to some documentation that outlines the process of setting this up. I skimmed over something that talked about setting up nginx with DuckDNS and a LetsEncrypt cert, but that was for external availability.

There is some info about other proxies here, but I think it makes sense to still run the Nginx on your Raspberry-Pi with SEPIA server. This way you can close most of the other ports and just use 20726 and/or 20727 (depending on your Nginx setup). I'm not sure how well Windows WAP works as a reverse proxy, but what the Nginx does is it "unifies" the SEPIA server and micro-services into one path, usually being http[s]://[hostname].localhost:20726/sepia/... and makes it easier to handle self-signed SSL (or Letsencrypt if you want to go public etc.). If you run no proxy at all and the Raspberry Pi Ports 20721, 20722 and 20723 are open you can still access the SEPIA server from your App by assigning the server IP as "hostname" (just the IP, no ports no protocol etc.) or define proper URLs via the app's "server connections" setting. The Android App will work just fine with this setup, but you will most likely run into troubles when using the web-app, because you want HTTPS for the microphone to work, but can't access the server due to mixed-content (non-HTTPS) URLs. What some people do is use their NAS or router etc. as central point to assign SSL certificates and then just reverse proxy from there to http:[server-IP]:20721, http:[server-IP]:20722, ... , maybe WAP can do the same?

Sepia Control Hub Core-Settings: (logged in as admin) smarthome_hub_host = http://YOURIPFOROPENHAB:8080 smarthome_hub_name = openhab smarthome_hub_auth_type = Bearer smarthome_hub_auth_data = YOURTOKENFORSEPIA

This worked perfectly. Thank you so much @SHU-red for the assist!

@fquirin Thanks so much for the input. I'm enjoying learning SEPIA, and I've been able to get it to talk to my hub now.

I did finally give in and put the nginx proxy on the box and dug into the .conf file to see how you were doing it. What I noticed was that you're redirecting certain paths to their respective host applications and ports. When I attempted to do this in Windows Web Application Proxy, it required that the external path match the internal path. So I was unable to setup the WAP in the same way nginx was configured. If there was no path specified, then the site could be published to the WAP without fail. (e.g. https://sepia.mydomain.com >> http://r-pi.mydomain.com:20721; https://sepia-teach.mydomain.com >> http://r-pi.mydomain.com:20722; https://sepia-chat.mydomain.com >> http://r-pi.mydomain.com:20723; and https://sepia-speech.mydomain.com >>http://r-pi.mydomain.com:20741

I configured the proxy this way because I don't like running HTTPS off of a non-standard port. That's just a personal preference, though. I'm still not sure why using the WAP would make the client think it was offline even though I configured all of those hosts in the server settings. The client itself works when connecting to https://sepia.mydomain.com/app/index.html. It just doesn't make the connections to assist, teach, and chat servers.

One other thing I noticed was that the client automatically filled in all the correct servers for assist, teach, chat, and even stt when I accessed the site at https://sepia.mydomain.com/sepia/assist/app/index.html (using the path defined in nginx). It's very interesting that it knew to add the paths to the other server fields which makes me wonder if there isn't something hard coded that expects those paths when running in https. This is all speculation, though. More than anything, I just wanted to pass on my experiences with Windows WAP so that you and anyone else can benefit from my findings.

Cheers!

Modified subject to better articulate the issue with the client app using HTTPS through a Windows Web Application Proxy.

Hey,

sorry I was a bit busy the last days, but let's see if I can clarify some things.

What I noticed was that you're redirecting certain paths to their respective host applications and ports. When I attempted to do this in Windows Web Application Proxy, it required that the external path match the internal path

Yes, the Nginx works as a central proxy in front of all the "microservices", mainly "Assist", "Teach" and "Chat" server (usually all on the same machine) and optionally STT and TTS servers which can be somewhere else in your network to distribute resources better (e.g. 2 Raspberry Pis etc.). I have no experience with 'Windows Web Application Proxy' but usually proxies have something like a "path rewrite" option. The default Nginx configuration is made in a way so that you have one path to everything on the machine: [hostname/IP]:20726/sepia/... and don't have to care about the microservices.

The client itself works when connecting to https://sepia.mydomain.com/app/index.html. It just doesn't make the connections to assist, teach, and chat servers

If you check the browser console (F12) do you see any error messages? Maybe some 404s or mixed-content stuff. The most common problem is either that the self-signed SSL is not accepted or that the client is running on HTTPS but the server host is pointing to the non-HTTPS URLs. Your main server will by default answer to the URLs https://[hostname/IP]:PORT/sepia/assist/ping or http://[hostname/IP]:20721/ping. If you remapped the paths /sepia/assist/.. -> IP:20721/.., /sepia/assist/.. -> IP:20722 etc. you have to use the URL that fits for you. Every URL can be changed individually in the settings if required.

One other thing I noticed was that the client automatically filled in all the correct servers for assist, teach, chat, and even stt when I accessed the site at https://sepia.mydomain.com/sepia/assist/app/index.html (using the path defined in nginx). It's very interesting that it knew to add the paths to the other server fields which makes me wonder if there isn't something hard coded that expects those paths when running in https

Because users often had problems entering the right "hostname" I've implemented some extensive automatic identification :sweat_smile: . The logic is as follows:

If the hostname is just the server IP (without protocol) the client assumes http://IP:20721, http://IP:20722` etc.
Same applies for "localhost"
If you add the protocol https://... or http://... this will be respected
If your hostname ends with /sepia like example.com/sepia or https:/example.com:20726/sepia the client will assume that the proxy reroutes the paths and applies .../sepia/assist, .../sepia/teach etc.

As said above all this is just the default setting and can be changed individually for every path in the settings if required ;-).

Hope that helps? :-)

SEPIA-Framework / sepia-docs

Modifying device attributes fails with 401 and HTTPS for client app fails with Windows WAP #183