I migrated my server from OH 2.5.12 (which worked fine with the skill & alexa) over to OH3.1. Ever since, Alexa has broken and is unable to discover devices.
Allow Basic Authorisation under API security has been turned on. My skill uses OAUTH, I disabled and reanabled the skill, but the issue persits. There was no issues with account linking, it worked fine
There is nothing in the github readme to explain what’s required for this to work
There are a few threads about X-OPENHAB-AUTH-HEADER header to be set.
E.g. this is part of the documentation: Securing Communication and Access | openHAB .
The link directly jumps to the related section in the docs.
Thanks, so this is in the NGINX configuration on the openhab cloud server or end, openhab server?
I’ve added it to the end OH3.1 server and still I get the same issue with the configuration being in the NGINX for HTTPS, under the server and the location / block
I do not have NGINX setup on the cloud server, never needed it and therefore sites-enabled, doesnt exist at all
Im having this issue, was the fix made into the Alexa Skill itself for self hosted skills/private cloud servers with OH3.1?
What is required to be done, other than update the skill?
Further. the config.json asks to point it to your private OH3 server. If you’re using multiple openhabs, hows that work?? For example, I have 3 servers I want the skill to be available to
In terms of config.json for the Skill/Lamba, only the URL is required then yes?
When I use the companion app to authorise the skill, it redirects me to my server just fine, i allow the OAUTH but then I get the error ‘we were unable to link openhab at this time’ - for instructions please see this guide. That’s with API security, basic auth off
Any suggestions on where to look?
The Cloudwatch log indicates:
2021-09-17T18:10:12.738+10:00
2021-09-17T08:10:12.738Z 646e8623-ac2d-4f61-aa19-ddc016e958db INFO INFO: Response:
{
"event": {
"header": {
"namespace": "Alexa",
"name": "ErrorResponse",
"payloadVersion": "3",
"messageId": "a0fd7062-22b0-460a-97af-e08097713335"
},
"payload": {
"type": "BRIDGE_UNREACHABLE",
"message": "Server not accessible"
}
}
}
2021-09-17T08:10:12.738Z 646e8623-ac2d-4f61-aa19-ddc016e958db INFO INFO: Response: {"event":{"header":{"namespace":"Alexa","name":"ErrorResponse","payloadVersion":"3","messageId":"a0fd7062-22b0-460a-97af-e08097713335"},"payload":{"type":"BRIDGE_UNREACHABLE","message":"Server not accessible"}}}
If you are using the main branch version, there is no change than previously configured.
Your Lambda logs should provide the reason why the skill is not able to reach your server.
To be clear, there is no change in how the skill interacts with your OH server. This is most likely a configuration issue specific to your setup. So it will be hard to help if you don’t provide additional information.
If you have an issue with your OAuth2 setup, make sure to follow these guidelines.
Seems that was a very old log I gave you, the Lambda now (after recreating it many times) has no entries what so ever. There is not even a log file created for today.
So the problem is before reaching the skill. Can you access your OH server through your cloud connector instance and is it accessible from the outside?
So the issue is between your cloud connector OAuth2 connector configuration for Alexa and how you set it up with the skill or the REST API endpoint settings in your skill config file.
What happens when you enable the skill? Please post screenshots.
Also make sure that you only have one OH skill on your Alexa account.
There is more than 1 skill currently, I’ve asked AWS to remove them (because it’s not letting me do so). If this would cause an issue, ill wait till it’s removed to continue further troubleshooting
So the old skill was deleted. I’ve gone through and followed the instructions again. But the issue persists. I’m not sure now what to do. The account linking was done correctly, yet the error persists - ‘We were unable to link openHAB at this time’
When you go through the account linking, what url is your browser getting redirected to? If it’s your cloud connector url, then there is a problem with your cloud connector oauth2 setup or your skill account linking setup.
It redirects to my cloud url. In your documentation, you list alexa-skill as the client id, which matches mongo, as does whats in the secret. Auth scheme is HTTP-basic with scope being alexa, which is the scope defined in mongo
It’s all correct to my eyes.
Is there some kind of log that details WHY its failing?
One thing OH3 does, that OH2 never is this use of some kind of double domain. When you log into the cloud server and hit ‘CLICK HER TO ACCESS YOUR DASHBOARD’, it wants you to authenticate to another domain (home.domain.com) - is this normal?
