Items and things and MQTT April 2017

Hi Gents

Thanks in advance for any suggestions!

The problem is a Sonoff switch. Works fine using MQTT. OH2 appears to be bound to MQTT.

Then it gets messy! : (

mqtt.cfg looks like this:



sitemap demo label="Demo House"
	Switch item=FrontLoungeMedia { mqtt=">[mqtt-loc:cmnd/FrontLoungeMedia/power:command:*:default], mqtt="<[mqtt-loc:stat/FrontLoungeMedia/POWER:state:default]" }

Items file:

Group All
/* active groups */
Group:Switch:OR(ON, OFF)
Switch FrontLoungeMedia 	"Front Lounge Media" <light> (LR,gLight)	{ mqtt=">[mqtt-loc:cmnd/FrontLoungeMedia/power:command:*:default], <[mqtt-loc:stat/FrontLoungeMedia/POWER:state:default]" }
Switch LivingRoom_Light 	"Living Room Light"  <light> (LR,gLight)    { mqtt=">[mqtt-loc:cmnd/FrontLoungeMedia/power:command:*:default], <[mqtt-loc:stat/FrontLoungeMedia/POWER:state:default]" }
/* Locations */
Location DemoLocation			"Perth, Western Australia"

Habmin shows two sitemaps: Demo House and Home.

  • Demo House shows “FrontLoungeMedia” but not “LivingRoom_Light”
  • Home shows “FrontLoungeMedia” but only as a network binding item

OpenHAB log shows:

2017-04-30 14:15:48.344 [DEBUG] [t.mqtt.internal.MqttBrokerConnection] - Starting message consumer for broker 'mqtt-loc' on topic 'stat/FrontLoungeMedia/POWER'
2017-04-30 14:15:48.494 [DEBUG] [ng.mqtt.internal.MqttEventBusBinding] - MQTT: Activating event bus binding.
2017-04-30 14:15:48.517 [DEBUG] [org.openhab.binding.mqtt            ] - ServiceEvent REGISTERED - {org.osgi.service.event.EventHandler,}={event.topics=openhab/*,,,,, service.bundleid=197, service.scope=bundle} - org.openhab.binding.mqtt
2017-04-30 14:15:48.521 [DEBUG] [       ] - ServiceEvent REGISTERED - {,}={, Connection Service,,, service.bundleid=199, service.scope=bundle} -
2017-04-30 14:15:48.527 [DEBUG] [       ] - BundleEvent STARTED -
2017-04-30 14:15:49.429 [INFO ] [ui.habmin.internal.servlet.HABminApp] - Started HABmin servlet at /habmin
2017-04-30 14:15:53.853 [WARN ] [] - Dispatching event to subscriber '' takes more than 5000ms.
2017-04-30 14:15:54.135 [WARN ] [] - Dispatching event to subscriber '' takes more than 5000ms.
2017-04-30 14:15:59.082 [WARN ] [] - Dispatching event to subscriber '' takes more than 5000ms.
2017-04-30 14:15:59.137 [WARN ] [] - Dispatching event to subscriber '' takes more than 5000ms.

mqtt-eventbus.cfg has all lines commented out

So . . .questions:

  1. Why isn’t the switch in the Demo Home sitemap working?
  2. Why is the MQTT event bus starting? Is that a problem? How do I stop it?
  3. Why do I have two sitemaps in Habmin even though there is only one *.sitemap file
  4. Why isn’t “LivingRoom_Light” showing up even though it is in the demo.items file?
  5. Why doesn’t flicking the switch using either Habmin or the iOS app result in any result?

Again, any assistance / education appreciated.

Hey, did you have a look at the tutorial I’ve posted over at:

Contains everything you need. Pay special attention to the referenced “sub-tutorial”:

Regarding your posted configuration: Why do you define an Item inside your sitemaps file? Thats simply not allowed. Your items file looks okay at first sight but please check out the tutorial!

If any of your five questions still need answering after going through the tutorial, please let us know :wink:

Hello Thom and thanks for your attention.

Any answers to questions are appreciated. I am sure you are a busy person with a life so anything you can offer is likely to improve my understanding. Don’t feel you have to answer everything : )

I have indeed read your tutorials and found them to be pretty good as far as they go. I am a complete noob trying to learn a little more and hence I tend to ask questions rather than just go for a complete re-install even though there is nothing actually working on my setup.

Unfortunately, not all tutorials are up to your standards or indeed applicable to current versions of OH or MQTT or Habmin or Designer or Paper UI or . . . . (hopefully you get the idea)

First thing to note from your tutorial is:

“simply set up items for all Sonoff-Tasmota MQTT topics . . .”


Q1: What tools do I use to set that up?
Q2: In which environment would I see the analogue of that image?
Q3: Assuming that this is in the *.items file, where is the documentation that explains the options?
Q4: Where do the images on that screenshot come from (folder structure)?

Any who . . . based on your comment about the sitemaps file, that is where I am going to start.

Cheers for now

A New Day! Help please.

I blew away the old and started brand new and openHAB STILL does not publish!



From Karaf console:

openhab> config:edit org.openhab.mqtt
openhab> config:property-list
   mqtt-loc.clientId = openhab2
   mqtt-loc.url = tcp://localhost:1883 = org.openhab.mqtt

From mosquito.log:

1493853649: mosquitto version 1.4.11 (build date Mon, 20 Feb 2017 22:47:27 +0000) starting
1493853649: Config loaded from /etc/mosquitto/mosquitto.conf.
1493853649: Opening ipv4 listen socket on port 1883.
1493853649: Opening ipv6 listen socket on port 1883.
1493853650: New connection from on port 1883.
1493853650: New client connected from as lens_TQAaHgI9xsw2GxfDhNtLlJphhzB (c1, k120).
1493853652: New connection from on port 1883.
1493853652: New client connected from as DVES_1C2405 (c1, k15, u'DVES_USER').
1493853697: New connection from on port 1883.
1493853697: New client connected from as openhab2 (c1, k60).
1493854278: Client openhab2 disconnected.
1493854339: New connection from on port 1883.


  1. Client on *.200 is MQTTLens running on my mac

  2. Clent on *.50 is a sonoff device

  3. Client on is openhab. It connects, then immediately disconnects and then tries again and no client is created.

From openhab.log:

2017-05-04 07:32:06.001 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'Test.items'
2017-05-04 07:32:13.804 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'Test.sitemap'
2017-05-04 07:32:17.982 [INFO ] [.dashboard.internal.DashboardService] - Started dashboard at /start
2017-05-04 07:32:19.195 [DEBUG] [       ] - ServiceEvent REGISTERED - {,}={, Connection Service,,, service.bundleid=209, service.scope=bundle} -
2017-05-04 07:32:19.202 [DEBUG] [       ] - BundleEvent STARTING -
2017-05-04 07:32:19.207 [DEBUG] [       ] - BundleEvent STARTED -
2017-05-04 07:32:19.228 [DEBUG] [] - Starting MQTT Service...
2017-05-04 07:32:19.259 [INFO ] [] - MQTT Service initialization completed.
2017-05-04 07:32:19.264 [INFO ] [t.mqtt.internal.MqttBrokerConnection] - Starting MQTT broker connection 'mqtt-loc'
2017-05-04 07:32:19.280 [DEBUG] [t.mqtt.internal.MqttBrokerConnection] - Creating new client for 'tcp://localhost:1883' using id 'openhab2' and file store '/var/lib/openhab2/tmp/mqtt-loc'

<snippy boring stuff here>


2017-05-04 07:32:22.000 [DEBUG] [org.openhab.binding.mqtt            ] - BundleEvent STARTING - org.openhab.binding.mqtt
2017-05-04 07:32:22.010 [DEBUG] [.binding.mqtt.internal.MqttActivator] - MQTT binding has been started.
2017-05-04 07:32:22.091 [DEBUG] [binding.mqtt.internal.MqttItemConfig] - Loaded MQTT config for item 'mySwitch' : 0 subscribers, 2 publishers
2017-05-04 07:32:22.107 [DEBUG] [org.openhab.binding.mqtt            ] - ServiceEvent REGISTERED - {org.openhab.model.item.binding.BindingConfigReader, org.openhab.binding.mqtt.MqttBindingProvider}={,,, service.bundleid=208, service.scope=bundle} - org.openhab.binding.mqtt
2017-05-04 07:32:22.128 [DEBUG] [org.openhab.binding.mqtt            ] - ServiceEvent REGISTERED - {org.osgi.service.event.EventHandler,}={event.topics=openhab/*,,,,, service.bundleid=208, service.scope=bundle} - org.openhab.binding.mqtt
2017-05-04 07:32:22.156 [DEBUG] [ng.mqtt.internal.MqttEventBusBinding] - MQTT: Activating event bus binding.
2017-05-04 07:32:22.183 [DEBUG] [org.openhab.binding.mqtt            ] - ServiceEvent REGISTERED - {org.osgi.service.event.EventHandler}={event.topics=openhab/*,,,, service.bundleid=208, service.scope=bundle} - org.openhab.binding.mqtt
2017-05-04 07:32:22.201 [DEBUG] [org.openhab.binding.mqtt            ] - BundleEvent STARTED - org.openhab.binding.mqtt

Try the following approach:

If you have installed MQTT Action Add-On, remove it. Sometimes it creates problems with the OH2->Broker connection.
Change the name of the MQTT broker in your OH2 configs. Do not use “-” in the broker name (instead of “mqtt-loc” try “mqttloc”.

After you change your mqtt.cfg, delete old config enties from Karaf and let OH2 re-read your fresh mqtt.cfg file.

config:delete org.openhab.mqtt

Hi Dim.

Thanks for the ideas.

This is what I did:

  1. MQTT actions is not installed (I did listen the first time : )
  2. Edited mqtt.cfg as you suggested.
  3. Entered the Karaf console to delete old config.

Mosquito log shows closing old connection and trying to make a new one every 2 seconds or so:

1493878457: Client openhab2 already connected, closing old connection.
1493878457: Client openhab2 disconnected.
1493878457: New client connected from as openhab2 (c1, k60).
1493878467: New connection from on port 1883.

OpenHAB log shows the same from OpenHAB’s perspective:

2017-05-04 14:13:47.065 [INFO ] [t.mqtt.internal.MqttBrokerConnection] - Starting MQTT broker connection 'mqttloc'
2017-05-04 14:13:47.093 [ERROR] [t.mqtt.internal.MqttBrokerConnection] - MQTT connection to broker was lost
Connection lost (32109) -
Caused by:
	at org.eclipse.paho.client.mqttv3.internal.wire.MqttInputStream.readMqttWireMessage([]
	... 1 more

So I stopped OpenHAB and then Mosquitto.

OpenHAB reported:

2017-05-04 14:25:17.475 [DEBUG] [t.mqtt.internal.MqttBrokerConnection] - Closing connection to broker 'mqttloc'

Then restarted both:

Mosquito said:

1493879250: mosquitto version 1.4.11 (build date Mon, 20 Feb 2017 22:47:27 +0000) starting

OpenHAB said:

2017-05-04 14:29:12.478 [DEBUG] [       ] - BundleEvent [unknown:512] -
2017-05-04 14:29:16.353 [WARN ] [g.dispatch.internal.ConfigDispatcher] - Could not parse line 'Mac OS X        	2��ATTR(��xThis resource fork intentionally left blank   ��'
2017-05-04 14:29:26.753 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'Test.items'
2017-05-04 14:29:27.117 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model '._Test.items'
2017-05-04 14:29:34.055 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'Test.sitemap'
2017-05-04 14:29:38.146 [INFO ] [.dashboard.internal.DashboardService] - Started dashboard at /start
2017-05-04 14:29:38.957 [DEBUG] [       ] - BundleEvent STARTING -
2017-05-04 14:29:38.962 [DEBUG] [       ] - BundleEvent STARTED -
2017-05-04 14:29:39.012 [DEBUG] [] - Starting MQTT Service...
2017-05-04 14:29:39.066 [DEBUG] [       ] - ServiceEvent REGISTERED - {,}={, Connection Service,,, service.bundleid=209, service.scope=bundle} -
2017-05-04 14:29:39.096 [INFO ] [] - MQTT Service initialization completed.
2017-05-04 14:29:39.129 [INFO ] [t.mqtt.internal.MqttBrokerConnection] - Starting MQTT broker connection 'mqttloc'
2017-05-04 14:29:39.164 [DEBUG] [t.mqtt.internal.MqttBrokerConnection] - Creating new client for 'tcp://' using id 'openhab2' and file store '/var/lib/openhab2/tmp/mqttloc'
2017-05-04 14:29:40.356 [INFO ] [basic.internal.servlet.WebAppServlet] - Started Basic UI at /basicui/app
2017-05-04 14:29:40.745 [INFO ] [assic.internal.servlet.WebAppServlet] - Started Classic UI at /classicui/app
2017-05-04 14:29:41.228 [INFO ] [arthome.ui.paper.internal.PaperUIApp] - Started Paper UI at /paperui
2017-05-04 14:29:41.665 [INFO ] [ui.habmin.internal.servlet.HABminApp] - Started HABmin servlet at /habmin
2017-05-04 14:29:41.861 [INFO ] [panel.internal.HABPanelDashboardTile] - Started HABPanel at /habpanel
2017-05-04 14:29:41.902 [DEBUG] [org.openhab.binding.mqtt            ] - BundleEvent STARTING - org.openhab.binding.mqtt
2017-05-04 14:29:41.909 [DEBUG] [.binding.mqtt.internal.MqttActivator] - MQTT binding has been started.
2017-05-04 14:29:41.911 [DEBUG] [org.openhab.binding.mqtt            ] - BundleEvent STARTED - org.openhab.binding.mqtt
2017-05-04 14:29:41.961 [DEBUG] [org.openhab.binding.mqtt            ] - ServiceEvent REGISTERED - {org.openhab.model.item.binding.BindingConfigReader, org.openhab.binding.mqtt.MqttBindingProvider}={,,, service.bundleid=208, service.scope=bundle} - org.openhab.binding.mqtt
2017-05-04 14:29:42.000 [DEBUG] [binding.mqtt.internal.MqttItemConfig] - Loaded MQTT config for item 'mySwitch' : 0 subscribers, 2 publishers
2017-05-04 14:29:42.040 [DEBUG] [ng.mqtt.internal.MqttEventBusBinding] - MQTT: Activating event bus binding.
2017-05-04 14:29:42.045 [DEBUG] [org.openhab.binding.mqtt            ] - ServiceEvent REGISTERED - {org.osgi.service.event.EventHandler,}={event.topics=openhab/*,,,,, service.bundleid=208, service.scope=bundle} - org.openhab.binding.mqtt
2017-05-04 14:29:42.070 [DEBUG] [org.openhab.binding.mqtt            ] - ServiceEvent REGISTERED - {org.osgi.service.event.EventHandler}={event.topics=openhab/*,,,, service.bundleid=208, service.scope=bundle} - org.openhab.binding.mqtt

So that all looks quite promising.

I then tried pointing the chrome browser at the openhanded server and went into the habmin interface, navigating to SiteMaps so I could see the switch.

And . . .


Next idea? Thanks in advance : )

Hmmm…“Mac OS”…
check this out (maybe…just maybe it will help :slight_smile: ):

Does the sitemap work when you access it from BasicUI?
I don’t use HABmin for my sitemaps

Note: You shouldn’t define any binding configurations within your sitemap file. This should be done in the *.items file.

Your *.sitemap should look like:

sitemap demo label="Demo House"
	Switch item=FrontLoungeMedia

Your *.items should have the binding config:

Switch FrontLoungeMedia 	"Front Lounge Media" <light> (LR,gLight)	{ mqtt=">[mqttloc:cmnd/FrontLoungeMedia/power:command:*:default], <[mqtt-loc:stat/FrontLoungeMedia/POWER:state:default]" }
Switch LivingRoom_Light 	"Living Room Light"  <light> (LR,gLight)    { mqtt=">[mqttloc:cmnd/FrontLoungeMedia/power:command:*:default], <[mqtt-loc:stat/FrontLoungeMedia/POWER:state:default]" }

Yes, it looks good. In theory, your OH2->MQTT broker connection is up and running correctly now…

MacOS - I have no idea what file that first line is looking at : (
I have been known to go to /etc/openhab2 and run “sudo rm -R ._*” to try and clean up the resource forks.

Now on to the BasicUI - it’s a blank : (
So is the classic UI.

The iOS app allows me to select the sitemap so I can see the switch.
Choosing Habmin and then Sitemaps also lets me see and click on switches as well.

News Flash!

It works!

V2 of test.sitemap:

sitemap Test label="My Home Automation Testing" 
        Switch item=mySwitch
        Switch item=FLM

V2 of Test.items

Switch mySwitch {mqtt=">[mqttloc:myhouse/office/light:command:ON:1],>[mqttloc:myhouse/office/light:command:OFF:0]"}
Switch FLM { mqtt=">[mqttloc:cmnd/FrontLoungeMedia/power:command:*:default], <[mqtt-loc:stat/FrontLoungeMedia/POWER:state:default]" }

I can see both switches in the iOS app!
Switch FLM works as advertised, turning the sonoff device on and off. Switch mySwitch sends commands to the configured topics.

So, we call that a win, I think.

So a non-alphanumeric character in the broker alias breaks the binding???

Many thanks for your help, Dim.

1 Like

Excellent ! :sunny:

I was “aiming” for that… I think that I have seen this problem before, but I was not sure…
We may have to open up an issue against this to save some other people from the hassle :slight_smile:

To set the default sitemap for the BasicUI (and the ClassicUI), navigate to:
PaperUI->Configuration->Services->UI->Basic UI->Configure and set the default sitemap (change from “default” to “Test” in your case)

Hiya Dim

In the spirit of feedback, NOT complaining : )

A couple of other “issues” it may be worth opening:

  1. The way OpenHAB reports a problem with *.items - it’s buried in a huge amount of verbiage when Java throws an exception in the logs, Perhaps some clever soul could catch that exception and turn the report into a simple “Could not parse Test.items due to an error in item . . .” Once the broker was running and I found those comments, it was easy to troubleshoot *.items but until then . . .

  2. Documentation: As great as everyone’s efforts are, I remain confused about the use of the various UI’s. They are also internally inconsistent e.g. Habmin lets me choose a sitemap and displays the switches, but the switches don’t work. The iOS app lets me choose a sitemap and the switches work. BasicUI and ClassicUI don’t display a non-default sitemap at all. (Thanks for the note on how to edit that behaviour). I get that each UI was created by different folks for different reasons and are at different levels of completion, but for a UI that is installed as part of the package, some things should be set in stone (or at least self documented by the UI itself IMHO.

Hope those comments are useful.

Many thanks again!

1 Like

Hey @GlidingFool, I was occupied for a few days, didn’t see your reply. Great you got it working, thanks @Dim :wink: Happy to see you active again.

I’d be happy to still look into your suggestions and questions from before. Are Q1 to Q4 still relevant for you? I’m not sure if I should make these clearer in the Tasmota wiki as these are mostly generic openHAB questions one should be able to answer by reading What do you think?

Regarding the new issues: The logging should be improved indeed. I had a similar discussion with @martinvw the other day, maybe he has an idea?

Looking at the documentation issue, I’m not sure what to do here. openHAB offers multiple UIs with different aspects of functionality. I do not see a problem with this, just use what you prefer :wink: I for example only use the BasicUI… An overview on a few of these can be found here:

Best! Thomas

1 Like

It helps me to see that when catching really specific exceptions it does make sense sense to leave out the stacktrace, like catching an unknowhostexception. But I was already more or less convinced about that. When catching more specific exception you still need more than the message, most NPE have a message being null. I once ran into when getting NPE’s in a filter which was filtering the logging strings :wink:

For this case I don not know what exception was thrown from where and where it was catched. But we could or should open an issue about it, if someone has the information feel free to mention me there as well. I do have time to pick up small refactorings and my focus is on these code quality things.

That was my impression. :wink: I think @GlidingFool already summarized the user story quite good. The typical end user should not be left alone with the often incomprehensible exception and stack trace and without any interpretation or context.

Stack Trace: I’ve mentioned somewhere else that imho the trace should be logged to TRACE log level only and not presented to the normal end user on a default openHAB setup. The stack trace doesn’t tell anything to the non-developer and otherwise helpful log lines are obfuscated and easily overlooked.

Exception Summary: By itself can still be useful to the end user, cases in which it is not (e.g. null) should be improved.

Classification: In addition I’d support the wish by @GlidingFool: If an exception is logged, the origin of it’s cause (file parsing, rule engine, etc.) should be distinctive.

@martinvw I believe you’ve got a great deal of experience in this matter. How do you want to continue from here on forward? I’d suggest to open an issue after the goal is clear.

I personally still do not see this as a general rule of thumb, but in a lot of specific but common cases there should be no exception but a clear error instead. I expect the most exception to occur when exceptional things happen :wink: and imho those still require stacktraces on the log level of the rest of the logging.

For user errors I expect the specific exception to be caught on a place close to where it is coming from and if applicable they should change the thing status. My suggestion about code changes was actually about the stacktrace being thrown and shown if you misconfigure an item in a certain way.

Hi Gents

I’m still in the vertical part of the learning curve for openHAB. My use case is currently involving a RPi and MQTT as I’m loving ESP8266 and Arduino devices.

Personally, I am a user of computing rather than a programmer with experience over 30 years of just about every OS and productivity app class out there. Hence not a noob, but by no means comfortable in this environment.

I had to find/learn:

  • Some (many?) contributors are using old systems and hence giving out of date advice
  • MQTTLens
  • how to use tail to monitor logs
  • how to use syscontrol to stop and start processes
  • that I need to use several UI’s to get the job done (textual, paperUI to install bindings, ClassicUI for usage and testing.)
  • NOT to include non-alphanumeric characters in the MQTT broker alias
  • NOT to install MQTT Actions despite documentation that seems to indicate that this is required
  • openHAB can hold onto old configs and so one must be able to find and delete those files
  • how to configure BasicUI and/or classicUI to look at my custom sitemap
  • where the word “broker” means leave the word “broker” there and where it means replace it with the name of my broker.

I went through an emotional journey to get to the point where I had a system that actually worked as advertised: excitement, confusion, frustration, anger, triumph! (Better than watching Game of Thrones : ).

Deleting or editing incorrect posts would help.

I am including a PDF of my notes for installing a working system. Perhaps flesh that out with screenshots, more thorough explanations on how to use the various tools (and which tools to use for which tasks) and a more inclusive use case (more bindings?) and that may solve some issues for other noobs.Installing openHAB and MQTT.pdf (75.0 KB)

(Oh, and keep it up to date : )

Again, many thanks for the help.



Hi Thom

Relevant Q for me?

I am thinking that the issue here is about user entry points. Perhaps you are starting to get an idea of how little I knew about linux and mqtt, let alone openHAB when I started this project.

I get the feeling that most people writing tutorials here are accomplished in at least two out of three of the above topics and hence (understandably) don’t want to waste their time documenting everything.

However, for the target audience for openhabian (for example), you need a more complete “from beginning to functioning” tutorial to prevent the whole Game of Thrones experience.

Cheers for now

Hey @GlidingFool,

I very much like your positive attitude :wink: Stay at it!

Cleaning out the forum is an unmanageable task and I’m not convinced it’s easy to decide which thread has turned old/incorrect posts. From time to time I leave a message at the end of a thread and close it to mark it as superseded, but even this is not always easy. I personally never had an issue with this though. If a thread is incorrect or not helpful, you should be able to grasp this from the comments, if it is outdated, you should be able to get that from the date or from the facts mentioned.

To have a reliable syntax completion you should use the Designer. Yes it has it’s flaws but it’s still pretty damn useful to get things done.

I got the idea and will try to improve the Tasmota page to not leave a big gap. However consider the following: The article is oriented at including the Sonoff into an openHAB system. Therefore I’d not explain how to install or use openHAB, how to build a sitemap or how to look at it in BasicUI - all of these should be known to the end user prior to working through this article. The same would I guess be true for the MQTT binding. Prior to working with the MQTT binding I’d expect a user to read up on MQTT, install a broker and a PC client and understand the principles.
How do you feel about this reasoning?

I’d go as far as to say it’s wrong to document everything. An article about Integrating Sonoff into openHAB should only include exactly this and references to related and needed resources (I’ll look into this).

Could you tell me where in this documentation you’d see the need for that? I’d be happy to add whatever is missing to prevent the killing (Although I love Game of Thrones :sob:)

Best! Thomas

Hi Thom

In reverse order:

  • I found the openhabian experience to be pretty much as advertised (although there were a couple of issues with updates from an older version that left some annoying artefacts around - starting fresh gave me a quite different experience to what I was having with a system I started several months ago ).

  • Using Sonoff: The Ahrendts-Tasmota wiki is really pretty good. I had no trouble getting to the point of pointing a browser at the device, toggling it and configuring it to point at the Pi for MQTT.

  • It all starts to go pear shaped at integration (always the way, right?) I had confirmed that the Sonoff was working. I had learnt how to configure MQTT and had proved that I could use either MQTTLens or mosquitto_pub / _sub to monitor MQTT actions AND to switch the Sonoff device on or off.

So yes, the documentation here is a problem. I had two errors:

  1. I was using a non-alphanumeric character in the OpenHAB MQTT config.
  2. Because of the above error, I did not believe that the documentation I could find in either your tutorial or Ahrendts GITHub wiki and hence messed up *.items and *.sitemap. As mentioned earlier, it is possible to get confused as to whether

should be left alone or should be replaced with my broker name.

Now: How is an Openhabian level “User” to work out what the hell is going on? Learn Karaf console, learn “Tail” commands, learn which parts of the logs to ignore and which parts are significant while maintaining confidence that OpenHAB is working as is the Sonoff device. So again, many thanks to everyone who contributed. This is part of the reason why I included my notes as a PDF.

  • Now to the forum: No. “If a thread is incorrect or not helpful, you should be able to grasp this from the comments, if it is outdated, you should be able to get that from the date or from the facts mentioned.” For the newbie, this is NOT obvious at all. May I also remind you that at least two users lead me astray with recent answers to my questions: one suggesting the use of non-alphanumeric character in the MQTT.conf file and another suggesting instructions for the old style openHAB.conf file.

Of course I agree that cleaning the forum ain’t realistic, however until the official user documentation is up to speed it’s going to remain a problem for the Noobs! I think it is one of those “wicked problems”. The only way to get the documentation for “Users” up to speed is to lock down functionality (and probably limit it) while putting in an unrealistic amount of effort for the programmers.

Good news

I flashed and installed a new sonoff device into my instance of OpenHAB. It took 5 minutes : )

(Easy when you know how)


Wonderful, so let’s define some action items :wink:

One clear issue here seems to be the non-alphanumeric problem. This could be either solved in software or in documentation. From what you discussed above @GlidingFool and @Dim how would you like to address this? Adding a line to the documentation is definitely the easiest solution and would make sense even if a check was implemented at a later point. Who wants to get at it? :wink:

1 Like

I haven’t validated this yet. I want to run some tests to see if I can replicate it.
I think that if you use a non-alphanumeric character (something like "-") in the mqtt broker name, the binding doesn’t work properly (OH2 connects, then disconnects… rinse and repeat)

Agreed. After I run my tests, I will make a PR against