How to recover from Java Exceptions showing strings not included in config?

Setup, Configuration and Use Beginners
1
  • Platform information:
    • Hardware: powerful with enough RAM
    • OS: Windows 7
    • Java Runtime Environment: JDK 1.8.0-191
    • openHAB version: 2.3.0

I had a weird problem that OpenHAB Logs showed this warning after starting OpenHAB:
[WARN ] [ab.binding.http.internal.HttpBinding] - given config key '// switch redStatus { http' does not follow the expected pattern '<id>.<url|updateInterval>'

This string was nowhere in my configuration files - after many digging I found it in Expert Mode Settings of HTTP Binding configuration in PaperUI, but wasn’t able to delete it there.

After deleting cache as described in Clear the Cache I got this exception:
[ERROR] [org.apache.felix.configadmin ] - [org.osgi.service.cm.ManagedService, org.osgi.service.event.EventHandler, id=360, bundle=216/mvn:org.openhab.binding/org.openhab.binding.http/1.12.0]: Unexpected problem updating configuration org.openhab.http java.lang.NumberFormatException: For input string: "60000.0" at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) ~[?:?] at java.lang.Integer.parseInt(Integer.java:580) [?:?] at java.lang.Integer.valueOf(Integer.java:766) [?:?] at org.openhab.binding.http.internal.HttpBinding.updated(HttpBinding.java:507) [216:org.openhab.binding.http:1.12.0]

60000 ms was a HTTP cache refresh time, which worked before.
I wasn’t able to get rid of this error, so I reinstalled OpenHAB.

What should I do next time? How do I clean the various (not known to me) caches in OpenHAB?

2

add as a first line of your *.cfg the ConfigAdmin Persistent IDentifier like this:

pid:org.openhab.binding.xyz
or
pid:org.openhab.persistence.xyz
or
pid:org.openhab.action.xyz
etc
etc

this applies to config parameters mainly.
read more here: HowTo: Manage OpenHab 2 configurations - #19 by Dim

This error says the following: a parameter in your stored configs for the http binding is formatted wrongly

Most possibly, during a previous configuration attempt in the http.cfg, you entered:

<cacheItemName>.updateInterval=60000.0

instead of 60000. You then deleted tmp&cache somefile holding info on the redStatus Item was deleted and the second error appeared because now the wrong config parameter was stored and kept in a file as a ghost config.

Interesting to see that clearing tmp&cache triggered the second error… I will dig deeper to see what could have caused the error to appear after clearing tmp&cache…

3

Bitten by the dreaded shadow config files. One of the most unfriendly “features” of the system. :cry:

1 Like
4

I am afraid that this is a Karaf thing/design.
There is a flag to overwrite contents in *.cfg (when updating the ConfigAdmin via another method) but it seems that OH2 team has decided not to enable it (I will find the discussion somewhere… can’t track it now)

I think that the best way to deal with this is to implement code in the framework that does validation checks and prevents such situations.

…or migrate all legacy 1.x stuff to modern 2.x managed stuff so no more .cfg files to worry about :slight_smile:

5

Agree this is the next best solution to getting rid of it completely.

Alternatively, the default 1.x .cfg files could be updated to include the pid (which is what I’ve done with the 1.x .cfg files for the 1x bundles I use).

1 Like
6

I started to do this… [Pushbullet] Update pushbullet.cfg by AngelosF · Pull Request #5711 · openhab/openhab1-addons · GitHub but then I realized how many there are and I froze :slight_smile:
I will try to find time to create PRs for each 1.x *.cfg template

Anyway, this pid story feels like we are cutting corners (instead of validation code in the framework or another method)

1 Like
7

There is a potential bad side effect from having enabled all the time this pid story in the *.cfg files:

You may want to modify some parameter via PaperUI and/or console and/or REST and you will remain under the impression that your settings will persist a restart… but they won’t…

so it’s better to enable it only for a short period of troubleshooting and then disable it again.

8

True. But I never do this for any 1.x bindings.

Agree completely.

1 Like