Amazonechocontrol binding UnknownOperationException

This morning, I received the following error:

2021-11-12 07:00:02.527 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.handleCommand()' on 'org.openhab.binding.amazonechocontrol.internal.handler.EchoHandler@eeacfb': POST url '' failed: Internal Server Error

When that url is placed in a browser, it returns:


This is after these events:

2021-11-12 07:00:01.385 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'Echo_Group_Everywhere_RadioStationId' received command s258421
2021-11-12 07:00:01.391 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'Echo_Group_Everywhere_Player' received command PLAY
2021-11-12 07:00:01.408 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Echo_Group_Everywhere_RadioStationId' predicted to become s258421
2021-11-12 07:00:01.416 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Echo_Group_Everywhere_Player' predicted to become PLAY
2021-11-12 07:00:01.431 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Echo_Group_Everywhere_RadioStationId' changed from  to s258421
2021-11-12 07:00:01.431 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Echo_Group_Everywhere_Player' changed from PAUSE to PLAY
2021-11-12 07:00:06.170 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Echo_Group_Everywhere_RadioStationId' changed from s258421 to
2021-11-12 07:00:06.174 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Echo_Group_Everywhere_Player' changed from PLAY to PAUSE

My script (shown below) runs fine when I run it from the web interface:

val Number woyFall = 34    // Week of year school starts
val Number woySpring = 23  // Week of year school ends

val String BOB = "s35482"
val String FISH  = "s28844"
val String KLOVE = "s33828"
val String CHRISTMAS = "s258421"
val String CHRISTIANROCK = "s18622"
rule "Start music in the morning"
    Time cron "0 0 7 ? * MON-FRI"
    var Calendar cal = Calendar.getInstance()
    val Number woy = cal.get(Calendar.WEEK_OF_YEAR)
    if (woy < woySpring || woy >= woyFall) {
      var String station = FISH;
      val Number currentMonth = now.getMonthValue
      if (currentMonth >= 11)
        station = CHRISTMAS



Which channel is that item linked to?

Did either of them change from v2.5=>v3.1?



No, nothing has changed. But Amazon has disabled that channel in the past (only for a few days, but…). It’s probably better to switch to textCommand with something like “Play Radio Foo on TuneIn”.

Thank you. I’ll give textCommand a try and see if it is any more reliable.

1 Like

That didn’t work but using playMusicVoiceCommand channel did (at least in the openhab-cli console).

Spoke too soon. playMusicVoiceCommand works sporadically in spite of it being for amazon music and not tunein. startCommand (not textCommand which doesn’t exist) doesn’t work at all. I see the change in the log but it never does anything; verbally giving the command does.

2021-11-17 15:55:18.404 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'Echo_Office_StartCommand' received command play k-love christmas radio on tunein radio
2021-11-17 15:55:18.408 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Echo_Office_StartCommand' predicted to become play k-love christmas radio on tunein radio
2021-11-17 15:55:18.424 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Echo_Office_StartCommand' changed from  to play k-love christmas radio on tunein radio
2021-11-17 15:55:19.561 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Echo_Office_StartCommand' changed from play k-love christmas radio on tunein radio to

Things like things are really broken with the echo binding under 3.1. I’m hoping OH3.2 is released soon and that it fixes these issues. I wish amazon would stop breaking things for OH like this!

textCommand should be available. UI or textual thing Config?

This is all the channels the UI shows:

No, it is not, as you did not tick the “Show advanced” checkbox on the upper right.

My bad! Still not seeing textCommand, only startCommand.

Unfortunately you didn’t answer my question: Is the thing UI configured ox textually configured? Did you upgrade from a previous version of openHAB and re-used the configuration?

It was configure via the UI a long time ago. This is an upgrade from OH2.5 to OH3.1 and the configuration was reused with the binding being reinstalled via the OH3 interface. Mind you, it stopped working under OH2.5 which is why I decided to upgrade to OH3.1 to see if it was fixed.

The channel is missing because unfortunately openHAB allows no updates to thing types. You have to delete and re-add the thing (you need to configure again, but if you keep the thingUID the same, I guess that al links stay in place).

The “channel stopped working” is unrelated to that and probably caused by Amazon.

Is that all 20-25 echo groups, flash briefings, devices and account or only the account?

Does this apply to all 86 things (with 481 items) as well or only the amazon echo control binding?

Only the echos. If you used discovery, just delete and re-add, that’ll do all the work.

In general this applies to every thing, but it doesn’t matter if the thing structure (i.e. the channels) didn’t change. This is a long standing yet unresolved issue that dates back to ESH times: Things should automatically inherit channels from their (current) thing type · Issue #2555 · eclipse-archived/smarthome · GitHub

FYI: the documentation doesn’t say anything about the necessity for redefining anything. The most it says is:

If the install of openHAB 3 detects an existing openHAB 2 install, then it will copy the configurations across and update using those files. There are several major differences between openHAB 2 and 3 which may mean that this will cause issues, let us know if you experience anything strange.

Don’t shoot the messenger.

Why is this necessary? As a developer myself, I can’t imagine ever imposing this kind of burden on a user. If all goes well, it may only take 30 mins. However, if things end up being slightly different, I would then have hours of work redoing my entire system as it relates to echo. This kind of thing should at least be in the upgrade documentation as a very prominent warning. Had it been there, I may not have even bothered with an upgrade.

Again: Don’t shoot the messenger. I neither write the docs nor am I responsible for this situation or the lack of a solution.

I suggest you read what’s written on GitHub in the issue above (and also openhab-core#1924).