Alexa app "Waiting for openHAB..."

Platform information:

  • Hardware: Raspberry Pi 4 Model B Rev 1.2
  • OS: Raspbian GNU/Linux 10 (buster)
  • Java Runtime Environment: openjdk version “1.8.0_252”
  • openHAB version: 2.5.6-2

Hi folks,

I had a Schlage Connect lock added as a device to my Alexa app (Android). It was working correctly in the Alexa app and I could lock it from my phone. I deleted it from Alexa accidentally, so then added it back. Alexa reported that the lock was added successfully and ready to use. However, when I go to access the lock in Alexa it only reports “Waiting for openHAB…” and doesn’t do anything. Other OpenHAB devices already added to Alexa continue to behave normally. Not sure what I need to do here, but I guess I’m overlooking something. Thanks to anyone who might know what’s going on.

Items entry:

Switch 		Lock_Backdoor			"Back door lock"					{ channel="zwave:device:a5f14603:node12:lock_door", alexa="LockController.lockState", autoupdate="false"}
String 		Lock_Backdoor_Alarm_Raw						(gLockRaw)		{ channel="zwave:device:a5f14603:node12:alarm_raw" }

So it looks like there is a bug with the LockController interface on the Alexa app side where it is trying to retrieve a state on an item that was marked as not retrievable by the skill. The app should have been giving the ability to send a lock command without providing the current state. I have opened a support case with the Alexa developer support team.

Basically, since you setup autoupdate="false", the skill automatically defines your item state as not retrievable because, as of now, the skill cannot wait until the updated state is available.

The workaround at this point would be to either remove the autoupdate parameter or use a proxy item that would interact with your original item.

Jeremy, thanks for doing that! I’ll try again without autoupdate=“false”.

Thanks again Jeremy, that was the solution.

Great to hear. Keep in mind that this is just a workaround. Removing the autoupdate metadata parameter from your item will cause its state to be updated based on the command received even though your lock may not actually succeeded in processing the request.

Hopefully Amazon will fix this bug on their end based on the support ticket I opened.