Help, I'm ready to give up

There is an /etc/openhab2/services/mqtt.cfg which is where you define your broker connection including URL and user names.

At a minimum I would expect to see:

mymosquitto.url=tcp://<host>:1883
mymosquitto.user=<user>
mymosquitto.pwd=<password>

where the stuff in < > gets replaced with your information.

See the mosquitto docs for how to set up the broker on Windows.

Additionally please check this and following comments: ITEAD Sonoff switches and sockets - cheap ESP8266 Wifi+MQTT hardware

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.

Good luck!

That did not fix it. Do I have to do some sort of rule to make it fetch the weather or is it supposed to do it automatically?

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]

The weather binding is a 1.9 version binding. Things only exist for 2.0 version bindings.

The binding is indeed installed if you are seeing that error so that wouldn’t be a problem.

It sure would be nice if it said what piece of information it things is missing…

Are there spaces in the config parameters? Typo in one of the parameters?

Not that I can see. SiteDesigner doesn’t give any errors. I’ve gone through each line and don’t see any extra spaces or misspellings.

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).

# location configuration, you can specify multiple locations
location.home.name=Home
location.home.latitude=35.0906884
location.home.longitude=-89.9451742
#location.home.woeid=
location.home.provider=Wunderground
location.home.language=en
location.home.updateInterval=10
Number   Temperature_F    "Temperature [%.2f °F]"  			<temperature>			(Weather, gTemperature)			{weather="locationId=home, type=temperature, property=current, unit=fahrenheit"}

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…

I switched to ForecastIo and same thing. Where is the openhab.cfg file stored? maybe there’s some residual info in there that’s causing some issue…

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.

1 Like

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:

  • 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 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.

2 Likes

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.

6 Likes

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.

1 Like

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?

1 Like