Number Item blank in Setpoint

Using PaperUI, I created a new Number Item.

I add it to a sitemap using Setpoint.

I initialise it using a change event on a separate switch item. Looking at the logs, I see that the item value is behaving as expected when I use the setpoint up and down controls, but in the UI it is always blank. I can’t get the number to show.

How can I make the UI show the number?

It is really hard to help debug problems like this without your Item definitions and sitemap entry.

A screenshot or transcription of the fields in PaperUI will suffice.

Of course, my apologies. A rule to ensure the number is initialised every time the switch is toggled.

rule "Auto Warm State Change"
  Item auto_warm_switch received command
  if (auto_warm_threshold.state == NULL) {

Sitemap snippet.

Frame label="Auto Warm" {
    Switch item=auto_warm_switch
    Setpoint item=auto_warm_threshold minValue=2 maxValue=18 step=1 icon="temperature"

The number in PaperUI:

Persist line:
auto_warm_threshold: strategy = everyChange, everyMinute, restoreOnStartup

Logging snippets:
21:33:58.519 [INFO ] [marthome.event.ItemStateChangedEvent] - auto_warm_threshold changed from 14 to 13
21:34:18.136 [INFO ] [smarthome.event.ItemCommandEvent ] - Item ‘auto_warm_threshold’ received command 14
21:34:18.149 [INFO ] [marthome.event.ItemStateChangedEvent] - auto_warm_threshold changed from 13 to 14
21:35:42.701 [INFO ] [smarthome.event.ItemCommandEvent ] - Item ‘auto_warm_switch’ received command ON
21:35:42.717 [INFO ] [marthome.event.ItemStateChangedEvent] - auto_warm_switch changed from OFF to ON
21:40:40.735 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘auto_warm.persist’
21:40:40.878 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model ‘auto_warm.persist’
21:40:51.638 [INFO ] [smarthome.event.ItemCommandEvent ] - Item ‘auto_warm_threshold’ received command 15
21:40:51.656 [INFO ] [marthome.event.ItemStateChangedEvent] - auto_warm_threshold changed from 14 to 15
21:41:22.752 [INFO ] [smarthome.event.ItemCommandEvent ] - Item ‘auto_warm_threshold’ received command 14
21:41:22.765 [INFO ] [marthome.event.ItemStateChangedEvent] - auto_warm_threshold changed from 15 to 14
21:45:14.144 [INFO ] [smarthome.event.ItemUpdatedEvent ] - Item ‘auto_warm_threshold’ has been updated.

I just tested with the demo sitemap and the field “Temperature” in frame “Discrete Widgets” of page “Widget Overview” and the value is correctly displayed in Basic UI.
Are you using a recent version of openHAB ?

The demo case is very similar to yours except that the item is defined in a text file and the pattern in the label is different. But it should make no difference.

How are you viewing your sitemap? Web browser or phone app? Classic UI or BasicUI?

Lolodomo, I tried both of those workarounds and neither worked.

Rich, I see the problem in Android app, classic UI, and basic UI. Also, I’m
running Openhab 2.0 from ~ late January. It’s the version that comes from
the Raspbian Repositories.

The only think that looks a little different from my setup is the order of the arguments in the sitemap.

From the docs:

Setpoint item=<itemname> [label="<labelname>"] [icon="<iconname>"] minValue="<min value>" maxValue="<max value>" step="<step value>"

Try putting the arguments in this order.

I doubt that is the problem but I’ve a setpoint that is otherwise the same and it works:


Number aNest_TargetTemp "Furnace Target Temp [%.1f °F]"


Setpoint item=aNest_TargetTemp minValue=50 maxValue=75 step=1

Tried changing the order of the arguments to match yours but still the same

Could it have something to do with the fact that the item is defined in

Please try with the demo. If you have the same issue, it is due to your old version of OH. if not, we will know that it is specific to your case.
You have no display in any UI ?!

Ok, to close the loop here, I defined the Number manually in a .items file
and it is now working just fine.

So the problem appears to be related to item creation in PaperUI in my
version of OpenHAB. I’ll just stick with manually defining them for now
since that seems to work a treat.