No, that isn’t your problem then. I can’t say I have much to offer. When ever something weird like this occurs the first thing to try is Clear the Cache.
Unfortunately that didn’t solve the problem. Maybe I have to focus on the BundleException?
Or try an openhab snapshot?
It’s always a good idea to try a snapshot. There might be a weird bug that got fixed. And my next solution would be to reinstall anyway so upgrading would kill two birds with one stone.
I don’t know what happened, but it is working now, without any repair action. I will just leave it that way for now, so I can continue with my interesting openhab project.
What I see in karaf is that the feature openhab-binding-mqtt1 is Uninstalled, but that there are two mqtt bundles that are installed (I don’t remember the exact osgi state, could be Active, I am not logged in at this very moment to verify) So that explains why it is working, but it does not explain why the feature is Uninstalled.
Anyway: thanks for your answers, it was a big support in the sense I didn’t feel being left alone with my problem!
Possibly the problem was that I could not install through Paper UI (mqtt is not listed there) and that I had not installed the compat1 binding.
I had lots of trouble with MQTT the last days. So when the MQTT binding unexpectedly stopped in my installation (which I observed at least three times, probably many times more), I always thought it might have been my fault.
But today it vanished without me changing something relevant. I’ll provide an excerpt from my log during startup:
2018-12-30 12:19:42.114 [WARN ] [r.internal.EmbeddedBrokerServiceImpl] - Embedded broker offline - Reason unknown
2018-12-30 12:19:42.250 [INFO ] [.transport.mqtt.MqttBrokerConnection] - Starting MQTT broker connection to '127.0.0.1' with clientid embedded-mqtt-broker and file store '/var/lib/openhab2/mqtt/127.0.0.1'
2018-12-30 12:19:42.318 [INFO ] [core.karaf.internal.FeatureInstaller] - Uninstalled 'openhab-binding-mqtt'
2018-12-30 12:19:42.461 [WARN ] [moquette.spi.impl.SessionsRepository] - Session does not exist. CId=embedded-mqtt-broker
2018-12-30 12:19:42.495 [WARN ] [moquette.spi.impl.SessionsRepository] - Session does not exist. CId=embedded-mqtt-broker
2018-12-30 12:19:43.053 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'LastMotion.rules'
2018-12-30 12:19:43.576 [WARN ] [mon.registry.AbstractManagedProvider] - Could not update element with key avmfritz:HAN_FUN_CONTACT:192_168_1_1:053330031905_1 in ManagedThingProvider, because it does not exists.
2018-12-30 12:19:46.519 [WARN ] [moquette.spi.impl.SessionsRepository] - Session does not exist. CId=sonoff-86DF27
2018-12-30 12:19:46.523 [WARN ] [moquette.spi.impl.SessionsRepository] - Session does not exist. CId=sonoff-86DF27
The broker is running fine all the time. It rarely made any problems for me. As opposed to the binding.
Cheers,
Michael
Just for the curios: The startup happended because I had OH down to make a backup, not because I changed something in the configuration.
And: The only thing needed to have everything running again is to re-install the binding in the paper ui. No need to change any config, restart/reboot/clear cache, restart broker or anything.
Do you by any chance have any modifications to addons.cfg? If so can you post the file here?
addons.cfg:
# The installation package of this openHAB instance
# Note: This is only regarded at the VERY FIRST START of openHAB
# Note: If you want to specify your add-ons yourself through entries below, set the package to "minimal"
# as otherwise your definition might be in conflict with what the installation package defines.
#
# Optional. If not set, the dashboard (https://<yourserver>:8080/) will ask you to choose a package.
#
# Valid options:
# - minimal : Installation only with dashboard, but no UIs or other add-ons. Use this for custom setups.
# - simple : Setup for using openHAB purely through UIs - you need to expect MANY constraints in functionality!
# - standard : Default setup for normal users, best for textual setup
# - expert : Setup for expert users, especially for people migrating from openHAB 1.x
# - demo : A demo setup which includes UIs, a few bindings, config files etc.
#
# See https://www.openhab.org/docs/configuration/packages.html for a detailed explanation of these packages.
#
package = minimal
# Access Remote Add-on Repository
# Defines whether the remote openHAB add-on repository should be used for browsing and installing add-ons.
# This not only makes latest snapshots of add-ons available, it is also required for the installation of
# any legacy 1.x add-on. (default is true)
#
#remote = true
# Include legacy 1.x bindings. If set to true, it also allows the installation of 1.x bindings for which there is
# already a 2.x version available (requires remote repo access, see above). (default is false)
#
legacy = true
# A comma-separated list of bindings to install (e.g. "binding = sonos,knx,zwave")
binding = amazonechocontrol,avmfritz,exec,expire1,fritzboxtr0641,homematic,lgwebos,netatmo,sonos,wol1
# A comma-separated list of UIs to install (e.g. "ui = basic,paper")
ui = basic,paper
# A comma-separated list of persistence services to install (e.g. "persistence = rrd4j,jpa")
persistence = mapdb
# A comma-separated list of actions to install (e.g. "action = mail,pushover")
action = pushover
# A comma-separated list of transformation services to install (e.g. "transformation = map,jsonpath")
transformation = map,regex
# A comma-separated list of voice services to install (e.g. "voice = marytts,freetts")
#voice =
# A comma-separated list of miscellaneous services to install (e.g. "misc = myopenhab")
#misc =
There are some things I’ve added, like mapdb.
Now that I look at it, it seems I’ve omitted the JSONPath transformation, which I enabled for Sonoff/Tasmota result mapping some days ago. Currently it is disabled. I hope that there are no inner workings of MQTT based on that.
BTW: I hope that it is ok to have some stuff (like MQTT-binding) enabled with paper ui, and some other stuff in the addons.cfg. Maybe with respect to MQTT I should have been a bit more consistent with my habit to use file based configuration and added that to the addons.cfg as well.
Cheers, Michael
Could you post which kind of broker and which version of mqtt binding you are using?
According the shown log you tried to start the embedded-mqtt-broker (which would come with the new mqtt2 binding), which failed, however you are stating “The broker is running fine all the time”, which sounds as if you are using a broker which is not emebedded.
I only use embedded broker and 2.4.0 binding. At least that is what I want to do. All the time the external components (Tasmota, iPhone, …) connect to the embedded broker just fine. When I deliberately change credentials of the embedded broker, the external connections fail (as expected), when I change it back again, everybody can connect again. This makes me quite sure that I am not using some other broken accidentally.
BTW: the last three days the whole system ran just fine, incl. the binding. But I didn’t change the binding or rebooted.
If you use addons.cfg to install any binding, you must use it to install ALL bindings. This file takes precedence over what you do in PaperUI. So append “mqtt” if you are trying to install the 2.4 version binding or “mqtt1” if you are trying to install the old 1.x version binding to the end of the list of the line that starts with "binding = ".
2 Likes
OK, that would explain the mess. Thank you for the clarification.
Cheers, Michael
So with the binding I am OK now. It is defined in addons.cfg and configured in thing files.
All seems to work fine and survive restart.
But with respect to the embedded broker I still miss something.
I now have the definition added to addons.cfg as well:
# A comma-separated list of miscellaneous services to install (e.g. "misc = myopenhab")
misc = mqttbroker
But the parameters are still defined in paper ui, e.g. Embedded broker username.
I understood that mqtt.cfg is not relevant anymore with the embedded broker.
Are there other means to configure the embedded broker? I want to isolate different users and introduce acl mechanisms. Any chance?
I don’t think the embedded broker exposes those sorts of parameters yet (if ever). For the short term at least you will want to use an external broker.
But I haven’t played much with the embedded broker. I could be wrong. Look in PaperUI for all the parameters that are available.
You may be right with the number of parameters exposed; I already configured those in paper ui.
But still there is the conflict that I have the broker service added in addons.cfg as well. I am not sure, if this “hurts”, as it did with the binding.
So is the embedded broker meant to be configured by file anyhow?
Or does it totally require paper ui?
Having it in addons.cfg only controls whether or not it gets installed. If you have it listed in addons.cfg then the broker will be installed. If you try to uninstall it from PaperUI, it will get reinstalled because it is listed in addons.cfg.
I don’t know whether or how to configure the broker using a cfg file. @David_Graeff, is it possible to configure the embedded broker using a cfg file? If so what should it be named and is there anything written anywhere listing the parameters? I couldn’t find and README in the docs for the embedded broker.
Hm. I know that half of the audience will have strong feelings after reading this response:
The embedded broker is configured via Paper UI in the Services section.
Every option listed in Paper UI can also be configured via .cfg file. That is how openHAB works.
But: I will not document those key/values in the service documentation, because they are implicitly documented in the service xml file.
There was the plan that those .cfg file sections are auto-generated for each service and binding.
I thought is was more than a plan as ever since 2.0 a stub for the cfg file used to be created when the binding gets installed. I think that may no longer be the case as I don’t remember a nest.cfg file being created when I installed the Nest 2.x version binding.
So where is the service.xml file? How do I as a user figure out the key/value pairs to put in the .cfg file since it won’t be documented anywhere else?