The binding has nothing to do with your problems. The connection openHAB device → Alexa (i.e. „Alexa, turn on my bedroom light“) is via the myopenhab cloud and the openHAB Alexa skill. The binding is for controlling Alexa devices from the openHAB side.
No idea. I never looked in either code. Since the lastVoiceCommand channel works, it seems it’s not an issue of your network connection in general and the fact that lastVoiceCommand contains the correct command indicates that Alexa understood what you said.
Maybe next time this happens you can try to login to myopenhab.org with a browser and see if you can access your dashboard. If you can control there and Alexa still does not work, you are at least sure that it’s not your connection to the cloud but the connection between cloud and skill.
Still fighting hard with myself to not restart openHAB to solve the problem, but trying to figure out what’s the current root cause.
Logged into myopenhab.org (“Your openHAB is not online.”), so definitely a myopenHAB Cloud-problem? The Alexa skill can work without the myopenhab.org cloud, correct? If so, how is it possible that the Alexa commands reach openHAB, but appear to not be executed correctly (with a restart solving all this)?
No, it’s working for me. So the issue is in your connection to the cloud.
There are two parts:
“Alexa controls openHAB”: this is done by exposing things with metadata to the cloud. The openHAB skill enables you to control these devices with your voice via Alexa
“openHAB controls Alexa”: this is done via the amazonechocontrol binding. Part of this is to listen for events from Alexa like “someone said something” or “the volume of the speaker changed”, the other part is to send commands to Alexa (like “say arbitrary text” or “play radio xy”).
Both parts are completely independent. So the binding will see that Alexa understood “Turn on light xy”. This would even work if you disable the openHAB skill and has nothing to do with what happens afterwards. It’s just the “log” of what Alexa recorded.
That’s actually not true. It’s not because the Alexa voice history shows the requested command that it indicates that it was processed as intended. This is why I mentioned before that you can’t use the Amazon Echo Control binding as a way to troubleshoot the Alexa skill.
So you actually have all the information you need to determine the root cause. You have to understand that the Amazon Echo Control binding connects from OH to Amazon, while the Alexa skill goes the opposite direction via myopenhab.org. If your connection to that cloud service is down, as you highlighted, then the Alexa skill will not work. As a matter a fact, the error returned specifically indicates the root cause in the troubleshooting guide.
In all, this is an issue between your OH server and the myopenhab.org cloud connector service. Once you resolve it, the Alexa skill will work again.
I didn’t state that Alexa is doing the correct thing after she understood something. I said “lastVoiceCommand contains the last thing you said, so the network connection is fine and Alexa in general is able to understand something”.
Thanks! I think you’re right. Just checked openhab.log. It contains frequent messages like this:
2022-01-11 08:15:32.957 [INFO ] [io.openhabcloud.internal.CloudClient] - Disconnected from the openHAB Cloud service (UUID = xxx, base URL = http://localhost:8080)
2022-01-11 08:17:40.587 [ERROR] [io.openhabcloud.internal.CloudClient] - Error connecting to the openHAB Cloud instance. Reconnecting.
2022-01-11 08:17:41.308 [INFO ] [io.openhabcloud.internal.CloudClient] - Connected to the openHAB Cloud service (UUID = xxx, base URL = http://localhost:8080)
Despite having several of these messages in the past x days, the function of Alexa was not affected (at least not noticeably, so maybe just good timing)
Despite the last log entry showing that the Cloud connection is there, myopenhab.org says it’s not.
Long story short: Problem seems to be like you said (" issue between your OH server and the myopenhab.org cloud connector service"). So I have to do some more research on this (or as a mitigation / no sustainable workaround) just do a restart.
Update: Problem might also be related to a recent DHCP problem which I’m having here, so closing this for now / have to observe further.