I believe everything is nicely discussed there. If you go a bit up, you’ll see, that I promissed to write a tutorial soon. I’ve ordered a dozen new Sonoffs.
It will fetch the weather data automatically. What does your log show for the weather binding (weather data is updated each time you save the weather.cfg file). Also, I assume your binding is installed correctly and not showing any errors?
One other thing with Wunderground - I don’t what its like where you are, but Wunderground has recently been flaky for both myself and another user here in London, frequently giving missing api key errors etc. It may be worth trying another provider such as forcastio.
Looks like it’s giving an error. Incomplete location config for location ID.
My understanding after reading the docs…to install the weather binding you just add weather1 to the bindings list in the addons.cfg file. It doesnt’ show up in the paperui under bindings. The docs don’t say anything about adding anything to the .things file like you do with other bindings.
2017-01-18 15:37:42.553 [WARN ] [eather.internal.common.WeatherConfig] - Incomplete location config for locationId 'Home'. Check openhab.cfg.
2017-01-18 15:37:42.560 [ERROR] [org.apache.felix.configadmin ] - [org.osgi.service.cm.ManagedService, org.osgi.service.event.EventHandler, id=300, bundle=185/mvn:org.openhab.bin$
org.osgi.service.cm.ConfigurationException: weather : Incomplete location config for locationId 'Home'. Check openhab.cfg.
at org.openhab.binding.weather.internal.common.WeatherConfig.parse(WeatherConfig.java:97)[185:org.openhab.binding.weather:1.9.0.201701160210]
at org.openhab.binding.weather.internal.bus.WeatherBinding.updated(WeatherBinding.java:82)[185:org.openhab.binding.weather:1.9.0.201701160210]
at org.apache.felix.cm.impl.helper.ManagedServiceTracker.updated(ManagedServiceTracker.java:189)[3:org.apache.felix.configadmin:1.8.12]
at org.apache.felix.cm.impl.helper.ManagedServiceTracker.updateService(ManagedServiceTracker.java:152)[3:org.apache.felix.configadmin:1.8.12]
at org.apache.felix.cm.impl.helper.ManagedServiceTracker.provideConfiguration(ManagedServiceTracker.java:85)[3:org.apache.felix.configadmin:1.8.12]
at org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.provide(ConfigurationManager.java:1461)[3:org.apache.felix.configadmin:1.8.12]
at org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.run(ConfigurationManager.java:1417)[3:org.apache.felix.configadmin:1.8.12]
at org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:141)[3:org.apache.felix.configadmin:1.8.12]
at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:109)[3:org.apache.felix.configadmin:1.8.12]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_111]
I don’t know how carefully Designer checks cfg files. For example, if you have location.home.latitude=12.345678 and location.Home.longitude=-123.456789 Designer would be fine with that but it would be an error (case matters).
There is nothing I can see wrong with that config.
Given the myriad of problems you have had (I praise you for your perseverance) I’m wondering if there isn’t something more fundamental going on. Are you running this on a Raspberry Pi? Perhaps the SD card is failing…
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.
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:
saved files reverting to the previous version
correct files being parsed incorrectly
changed files not being updated
unexplained errors in the logs
bindings not installing
bindings installing then disappearing
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 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.
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?