In openHAB 2.0 there is no openhab.cfg. That massive monolithic catch all file used to configure OH 1.x and all its bindings has been split up into separate cfg files for each binding. Assuming you didn’t create one (it would be located either in your root config folder or in the services folder) there isn’t one.
That error message comes from a 1.9 version binding so it assumes it is running on 1.x and therefore assumes there is an openhab.cfg.
Ok. nope didn’t create one. so another thing that just doesn’t work. GRRRRRRRRRRR
If you are on a Pi I really do strongly recommend trying another SD card. These inexplicable errors almost always point to a failing card. Symptoms others have seen:
When the SD card starts to go your machine enters bizzaro land.
And the card does not have to be old to fail like this.
I pasted your weather.cfg into mine, and it immediately worked.
I would lean towards SD card failing like Rich said…
I found the issue. another forum user had a similar issue and said that he found a file weather.config file in the cache folder. He deleted it and the weather worked. I didn’t find that file in the location he did but I did find it in <user_data>/config/org/openhab/weather.config I deleted the file and now the weather works.
Please be aware of a big potential gotcha:
If you define parameters in a .cfg file, but later change the key or comment out the key (to the left of the = sign), the old key and value remains in the configuration stored in the server. This can wreak havoc and lead to many otherwise inexplicable problems. Users expect, quite reasonably, that the old key no longer mentioned in the .cfg file disappears from the configuration, but it doesn’t. This is particularly irksome when you use a 1.x binding like MQTT or the Weather binding that allows dynamically named keys, like myhouse.url=.....
Under openHAB 1.x, every time you restarted the server, all old configuration data was wiped out and read fresh from openhab.cfg. That no longer happens in openHAB 2.
As Kai described here for HABPanel, the configurations that the server actually uses are inside the ${OPENHAB_USERDATA}/config directory tree. You can diagnose and even fix this gotcha by looking there.
This is in my books a flaw, which should be fixed…
It is impossible IMHO for any new user, in particular newbies to figure out.
There should be either a checksum trigger when a cfg files has changed, or at least re-reading configs when the server | service restarted.
I agree that it places a burden on the user to understand, and documenting it may be insufficient as a way to mitigate the problems it can cause.
I think it’s possible that, when it comes time to read a .cfg file, this method could be called to get the currently stored internal configuration, read the .cfg file, and any keys not present in the .cfg file could be deleted or emptied from the internal configuration, resulting in an internal configuration that matches the one in the .cfg file. Of course this is easier said than done and tested…
I actually think this problem is bigger than just config files. For example, if you add an item to a group and later remove the item from the group, the item remains a member of the group until the next reboot.
This is all from text files of course.
I agree with Max. If I make a change to a cfg file, additions or removals, I expect those changes to take effect, even removals. Is there an issue filed on this?
Not that I know of. Now would be a good time to lodge an issue on it. I’ve seen several cases where this unexpected behavior has led to frustration.
Each or OH2 for an issue like this? It isn’t charging to me where the dividing line is for something like this.
I don’t know, so many repos… Fire it at openhab-distro, and be prepared to copy/paste it to a different repo. 
An inadequate power supply can also cause strange errors on the RPi.
I’m working on some rules now. I have the following:
.items
Number Mode "Mode" <house>
Number Scene "Scene" <rgb>
.sitemap
Frame label="Mode/Scene" {
Switch item=Mode label="Mode" mappings=[0=Away, 1=Home]
Switch item=Scene label="Scene" mappings=[0=WakeUp, 1=Bedtime, 2=Movie, 3=General, 4=Nightlight]
}
.rules
rule "Whole House Mode"
when
Item Mode received command
then
logInfo('Mode', 'Mode received state:' + Mode.state)
switch (receivedCommand) {
//mappings=[0=Away, 1=Home, 2=, 3=Other]
case 0: { // Away
bathroom_light.sendCommand(0)
hall_light.sendCommand(0)
}
case 1: { // Home
//var HSBType light = new HSBType("60,91,70")
hall_light.sendCommand(100)
diningroom_light.sendCommand(100)
}
}
logInfo('Mode', 'Mode updated to: ' + Mode.state)
end
NOtice the screenshot of the Mode section. If I click Home or Away it stays pink for a bit then switches off. The scene keeps it’s state. If I refresh the page then the Mode.state returns. I’m not sure why… Any ideas?
Do you see Mode changing state in events.log or is it just the ui that appears to lose state?
the events.log doesn’t record anything for that item. the openhab.log does however.
openhab.log
2017-01-19 21:43:35.095 [INFO ] [.eclipse.smarthome.model.script.Mode] - Mode received state:1
2017-01-19 21:43:35.106 [INFO ] [.eclipse.smarthome.model.script.Mode] - Mode updated to: 1
2017-01-19 21:44:50.726 [WARN ] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve color item online for widget
The INFO line for the Mode is me clicking to set it.
And there is no line later on when it goes grey in the UI? That seems to point to something odd going on with the UI. Not sure I’m any closer to knowing what. …
I wonder if receivedcommand is a string. Try case “0”: and case “1”:
I don’t think that’s the case. The Scene is exactly the same just changed the names and it works right.
@rlkoshak Nope no further line. Weird.