Edit metadata results in spinning wheel while loading

OH 4.1.1

I have a simple Number:Temperature Item that I’m using as part of a group for a thermostat using Alexa. I created the Item and put it in the group as desired. I’ve added metadata, but when I go back and try to edit or view the metadata in the Main UI, I get a spinning wheel that never stops. I can see the correct metadata in the jsondb file, but I should be able to edit in the GUI. I tried restarting OH and that made no difference.

Any suggestions to resolve this? I have other Items with metadata that I can edit. This one in particular seems problematic. I think that all 3 Items that I have in the group seem to have trouble with this. Other Items not in the group can edit the metadata.

Group is:

label: Cabin Furnace
type: Group
category: ""
groupNames: []
tags: []
groupType: None
function: None

Item is:

label: Cabin Heat Setpoint
type: Number:Temperature
category: temperature
  - CabinThermostat
  - Point

Metadata has:

  "alexa:Pine_Lake_openHAB_Item_CabinHeatSetpoint": {
    "class": "org.openhab.core.items.Metadata",
    "value": {
      "key": {
        "segments": [
        "uid": "alexa:Pine_Lake_openHAB_Item_CabinHeatSetpoint"
      "value": "Thermostat.TargetTemperature",
      "configuration": {}

This is the forever spinning wheel:

Anything in the logs when this happens?

What does it do when you reload the browser?

Can you pull the JSON from the API Explorer or does it spin there too?

In the browser console do you see any errors?

I don’t see anything obviously wrong.

Nothing in the OH logs.

Reloading the browser doesn’t change behavior, still spinning.

The browser console does show the error below which is probably the cause, but I don’t know how to interpret this. Suggestions?

I haven’t tried the API Explorer yet - will try that and report back.

Using Chrome: Version 121.0.6167.161 (Official Build) (64-bit)


app.3456231afb83cd720478.js:7 TypeError: undefined is not iterable (cannot read property Symbol(Symbol.iterator))
    at H (14.app.3456231afb83cd720478.js:1:79732)
    at Z (14.app.3456231afb83cd720478.js:1:81051)
    at Le (14.app.3456231afb83cd720478.js:1:89003)
    at parameters (14.app.3456231afb83cd720478.js:1:100832)
    at 14.app.3456231afb83cd720478.js:1:119568
    at Array.map (<anonymous>)
    at 14.app.3456231afb83cd720478.js:1:119544
    at Array.reduce (<anonymous>)
    at r.parameters (14.app.3456231afb83cd720478.js:1:118825)
    at fn.get (app.3456231afb83cd720478.js:7:26678)

Thanks for reporting this issue. A bug has been found affecting all temperature related alexa metadata attributes in MainUI since OH 4.1. A fix has been submitted for the next OH release. Unfortunately, the only workaround is to use the code tab to configure the affected metadata attributes.


The fix is included in the 4.1.2 release.

1 Like

That’s good news, thanks for the update.

1 Like


I’m sorry to report that this is what I’m getting with a new installation of openHAB 4.1.2

(I’m trying to get the Velbus thermostats working fully with Alexa again, your help in 2020 was amazing.
I’ve tried to keep on top of the updates, but I’ve clearly missed something along the way)

For example

Creating a Text file based on this really doesn’t seem to be working

Group  Thermostat    "Bedroom"                                {alexa="Thermostat"}
Number Temperature   "Temperature [%.1f °F]"   (Thermostat)   {alexa="CurrentTemperature"}
Number CoolSetpoint  "Cool Setpoint [%.1f °F]" (Thermostat)   {alexa="CoolingSetpoint"}
Number HeatSetpoint  "Heat Setpoint [%.1f °F]" (Thermostat)   {alexa="HeatingSetpoint"}
Number Mode          "Mode [%s]"               (Thermostat)   {alexa="HeatingCoolingMode"}

All I get is a Thermostat device and a message saying “waiting for openHAB”

But this gets me a Thermostat with current Temp and Target Temp, with control for Heat or Cool mode (operating mode)

It would appear that the “preset target temperature” options can only be reached by voice

An utterance along these lines works
“Set the xxxx Thermostat preset to SAFE / Night / DAY / COMFORT”

		Group 		ELO_Blind_Thermostat								"ELO_Blind Thermostat"						<temperature>						{alexa="Endpoint.Thermostat"}
		Number 		ELO_Blind_CurrentTemperature 						"ELO_Blind Current Temperature" 			<heating>						( ELO_Blind_Thermostat ,WholeHouse_CurrentTemperature		) {channel="velbus:vmbelo:VelbusNetworkBridge:70:input#CH33"								,	alexa="TemperatureSensor.temperature" 					}
		Number 		ELO_Blind_CurrentTargetTemperature					"ELO_Blind Current Target Temperature"		<heating>						( ELO_Blind_Thermostat ,WholeHouse_CurrentTargetTemperature	) {channel="velbus:vmbelo:VelbusNetworkBridge:70:thermostat#currentTemperatureSetpoint"		,	alexa="ThermostatController.targetSetpoint"				}
		String 		ELO_Blind_ThermostatMode 							"ELO_Blind Thermostat mode"	  	 			<heating>						( ELO_Blind_Thermostat, WholeHouse_ThermostatMode			) {channel="velbus:vmbelo:VelbusNetworkBridge:70:thermostat#mode"							,	alexa="ModeController.mode" [friendlyNames="@Setting.Preset", supportedModes="SAFE=Safe,NIGHT=Night,DAY=Day,COMFORT=Comfort"]}
		String 		ELO_Blind_ThermostatOperatingMode 					"ELO_Blind Thermostat operating mode"		<heating>						( ELO_Blind_Thermostat, WholeHouse_ThermostatOperatingMode	) {channel="velbus:vmbelo:VelbusNetworkBridge:70:thermostat#operatingMode" 					,	alexa="ThermostatController.thermostatMode" [COOL="COOLING",HEAT="HEATING"]	}

Keep in mind that the metadata configured by text file may not be compatible with the UI integration. This is why it is recommended to either use textual file or UI-based configuration.

If you are seeing this message in your Alexa app, it means it is waiting to hear back from your server. So it could be a connectivity or performance issue with your server.

Assuming you are referring to how your Thermostat endpoint is represented in the Alexa app, this is a known issue and outside of our control. Unfortunately, Amazon decided not to display generic capabilities for the THERMOSTAT display category.

That screen grab was from the creation of a brand new item using the MAIN_UI.

Because of the sheer volume of repeat items to add, I tend to advise people to create the backbone items in text files, so that they can be simply copied, bulk edited and the new batch of items added.

Thermostats are a great example of this.

The last version I posted above seems to be working well.

Maybe, but as soon as I correct any mistakes, it seems to push through really quickly.


If that’s how it has to be, then that is how I shall tell people it is.

Most only use the voice side anyway, so telling them the utterances seems to be doing the trick.

As always, Thanks a million for your help and support.

1 Like

If you are still experiencing this issue, could you provide steps to replicate? My guess is that your UI lost connection to the server. This can sometimes happen if you restart your server while having your browser still connected. Usually refreshing your browser page fixes this.

1 Like


I’ve run out of time today, I’ll take another look tomorrow.

Better way would be to import the textual definition to create managed Items.
That’s what we provide for the semanticHomeMenu widgets.

Just to elaborate a bit, when you use the Developer Tools → Add Items from Textual Definition then you can paste in one or more lines of .items file definitions to create managed Items.

So you can indeed keep a template set of Item definitions but still use that to create managed Items using copy/paste/edit.

1 Like