HABPanel: TypeError: [sprintf] expecting number but found string

  • Platform information:
    • OS: Debian 9
    • Java Runtime Environment: OpenJDK 1.8.0_232
    • openHAB version: 2.4.0 (looking forward to 2.5.0 :slight_smile: )

I’ve recently set up a screen running habpanel on chromium (FullyKioskBrowser app on Android kitkat).
I like habpanel, its easy to customize and looks good. BUT I’ve always had problems with slow response when pressing the screen, but lateley its gone downhill. HabPanel freezes and changes between the home screens can take 30s or more.
So I started logging and imediatly found a problem that occurs about once every second:

11-09 21:27:28.645 I/chromium( 1742): [INFO:CONSOLE(119)] "TypeError: [sprintf] expecting number but found string
11-09 21:27:28.645 I/chromium( 1742):     at b.format (http://192.168.20.111:8080/habpanel/vendor/vendor.js:365:1026)
11-09 21:27:28.645 I/chromium( 1742):     at b (http://192.168.20.111:8080/habpanel/vendor/vendor.js:365:117)
11-09 21:27:28.645 I/chromium( 1742):     at updateValue (http://192.168.20.111:8080/habpanel/app/widgets/dummy/dummy.widget.js:58:29)
11-09 21:27:28.645 I/chromium( 1742):     at http://192.168.20.111:8080/habpanel/app/widgets/dummy/dummy.widget.js:74:13
11-09 21:27:28.645 I/chromium( 1742):     at m.$emit (http://192.168.20.111:8080/habpanel/vendor/vendor.js:149:24)
11-09 21:27:28.645 I/chromium( 1742):     at http://192.168.20.111:8080/habpanel/app/services/openhab.service.js:182:52
11-09 21:27:28.645 I/chromium( 1742):     at m.$eval (http://192.168.20.111:8080/habpanel/vendor/vendor.js:147:69)
11-09 21:27:28.645 I/chromium( 1742):     at m.$apply (http://192.168.20.111:8080/habpanel/vendor/vendor.js:147:302)
11-09 21:27:28.645 I/chromium( 1742):     at e.source.onmessage (http://192.168.20.111:8080/habpanel/app/services/openhab.service.js:176:44)
11-09 21:27:28.645 I/chromium( 1742):     at F (http://192.168.20.111:8080/habpanel/vendor/vendor.js:696:6158)", source: http://192.168.20.111:8080/habpanel/vendor/vendor.js (119)

I have about 10-20 dummy windows and cant really understand the error about value being a string instead of a number. Doesn’t the dummy present whatever the item value is, regardless if it’s a string or number?

Help appreciated.

BR
Daniel

[sprintf] is referring to this kind of format [%.1f] [%s] etc.
You might get that kind of message with [%.xf] or something - the formatter looking for a numeric directive, nothing to do with Item type

EDIT: I take that back. I see I’ve done some formatting :expressionless:
I immediately found an item that had not beed set, and it looks as if that was the problem…
Thank you!

1 Like

Here’s some general advice on how to debug this when it occurs, if you feel like it:

  • open the developer tools with F12 (on a PC, Command+Option+C on macOS)
  • in the stack trace you can see the problem appears in the updateValue function of the dummy widget, specifically app/widgets/dummy/dummy.widget.js on line 58; so on the Sources tab, in the treeview expand app/widgets/dummy and open the dummy.widget.js file.
  • set a breakpoint by clicking on the line number (here, line 58)
  • refresh the page and your breakpoint should be hit, you’ll see the line is highlighted
  • hover the widget part of vm.widget.format and also value, you should have enough information, in this case if you have a format but the value is not a number it will fail - hit F8 a few times if you want to confirm, the breakpoint will be hit every time the item state is updated.
  • once you’re done unset the breakpoint by clicking on the line number again (or via the list on the right pane)

ps love the Ricky avatar :wink:

1 Like

Thanks for the logging advice :slight_smile:
Knock Knock! :stuck_out_tongue:

But shouldn’t this almost qualify as a bug report, or a possibility for improvement?
In this case I had set the formatter in the dummy frame to “%.1f”, and the number item hadn’t updated the value since the last restart of OH. It’s not an important item so I don’t have persistence active on it.
But that the formatter in the dummy frame interprets “NULL” as a string instead of an empty number value doesn’t sound so good to me?

It’s a reasonable point. In sitemap based UI’s, you’d get a dash “-” display for NULL or UNDEF Number state (and no error report). Maybe it’s more an invitation to improve the dummy widget than a ‘bug’.

I expect you can avoid this error by ticking “use server format”, but that’s not the point.

1 Like

Makes sense, yes. Those exceptions should be caught.

1 Like