OpenHAB 2.4 MQTT beginner experience principal conclusions from a post-newbie

leif · June 24, 2019, 5:37am

Please forgive the topic, I could not resist barrowing the phrase for something constructive.

Having started using MQTT from scratch just yesterday morning, and now having gotten everything to work, I figured I’d write it up make it a bit easier for the next guy while it’s fresh in my mind.

These notes are written at 2019-06-24 and my experience is based on openHAB 2.4. It is current as of now but may not apply to newer versions!

Many, many tutorials and notes on this forum are about MQTT binding in openHAB 1.x and do not apply – it has changed completely.

First of all, to understand MQTT, watch this video. It’s clear, consise, and will show you the basics. Don’t try to follow along – just watch it first. Not every part will apply to you (for example I have no use for Node-RED) but it’s still a good example. It’s actually a good thing that it’s not an openHAB tutorial, because it sticks to the basics.

MQTT.fx and MQTT explorer are both excellent tools. I use both.
You’ll need your own MQTT broker, which is the hub that interconnects all the devices, and routes messages through. I run “mosquitto” on the same Raspberry Pi that runs my openHAB, and I installed it through openhabian-config.
I made sure I was able to post and subscribe to (and receive) messages before I did anything MQTT-related in openHAB! I’m glad I did, because the openHAB part ended up taking much longer than the previous parts, partly because of all the misleading information around.
Once I had mosquitto set up, I was able to post and subscribe to messages with MQTT.fx and I was able to monitor everything through MQTT explorer. In MQTT.fx, when publishing, the big white empty window below the “topic” field is NOT as I first thought a graphics bug… it is an edit box where you enter the payload. Tripped me up for a while.
The next step for me was to publish MQTT messages from an ESP8266 (NodeMCU). I did so using the PubSubClient library, and it worked great for me.
WARNING: openHAB is not designed to subscribe to wildcard topics because inside a rule it will NOT reveal the topic a message came from, only the payload itself. Keep this in mind when you decide how to lay out your messages. You will have a much easier time if you stick to ONE topic for related things (such as different buttons and actions on a remote control) and separate things by payload. If you, like I did, start by separating buttons as topic, you will end up down the rabbit hole of workarounds. Don’t do it. Once I saw how deep it went, I dug myself back out and re-structured my MQTT messages around openHAB’s limitations.

NOT recommended:

topic: home/mcu/LivingRoomMCU/433mhz/CeilingFanRemoteBtn1   payload: pushed
topic: home/mcu/LivingRoomMCU/433mhz/CeilingFanRemoteBtn2   payload: pushed

Recommended:

topic: home/mcu/LivingRoomMCU/433mhz/CeilingFanRemote   payload: btn1_pushed
topic: home/mcu/LivingRoomMCU/433mhz/CeilingFanRemote   payload: btn2_pushed

This lets you easily get all button actions into ONE openHAB rule.
The topic hierarchy obviously doesn’t need to be this deep but I figured better too deep now than messy later.

Once I was able to push the buttons on my remote and see the actions end up in both MQTT.fx (subscribed to topic # which is the mqtt wildcard that means everything from this level down) and MQTT Explorer (which always shows everything as a tree), I decided to tackle openHAB.
MQTT in openHAB is a binding, and you’ll find it under Add-ons - Bindings in PaperUI.
Then go Configuration - Things, hit +, MQTT Binding, Add Manually. Choose MQTT Broker.
Now pay attention to the Thing ID. You will have to type this thing ID throughout the life of your openHAB setup so make it descriptive. It’s how openHAB keeps MQTT brokers apart because of course it supports more than one! It doesn’t have to be hexadecimal. I called mine local because it is. Obviously the first time I left it to the default dc12ba34 and had to start over, just trying to save you the pain.
WARNING WARNING WARNING
There is a BUG in OpenHAB 2.4 which makes the openHAB MQTT Broker Thing not function until you’ve restarted OpenHAB! So, head to your linux terminal and sudo service openhab2 restart. I wasted hours trying different syntaxes in rules and getting a (to me) cryptic error message before I thought to google the error message, and found the explanation. You have to restart openHAB whenever you make ANY change to the MQTT Broker binding. Once it’s up and running it’s fine though, and you can add things at will.
To make an MQTT subscription, you have to add another Thing – a “Generic MQTT Thing” to be exact. At this point let me reiterate, openHAB will NOT reveal the topic a message came from this way, only the payload itself, so you better not use a wildcard subscription.
On the Generic MQTT Thing (which you should name more descriptively than that, and write your own alphanumeric thing ID) you also select the Bridge (the MQTT broker) you just selected. This is where you see its thing ID: in my case mqtt:broker:local.
Each channel you add is its own MQTT subscription, and multiple items can be linked to each, in the normal openHAB fashion.
Now, if you DO need to use a wildcard subscription, it can be done, but it is a workaround. You do it by adding a channel to the MQTT Broker Thing itself. The channel type is “Publish Trigger”. The channel gets updated every time something is published, and that something contains both the topic and payload separated by a hash sign (#) provided you entered hash as the separator. After that, the rest is up to scripting logic. It is when I saw this that I backed out of my approach and made my remote buttons publish to the same topic, but I include it here for posterity.
Forget about subscribing to MQTT topics per item, it’s not happening – that’s an openHAB 1.x thing and is unfortunately not available with the openHAB 2.x MQTT binding!
Finally, if you need to publish MQTT from a JSR223/Jython script, here is how you do it. Please note that “local” is the “Thing ID” of the MQTT Broker Thing which we entered earlier.

actions.get("mqtt", "mqtt:broker:local").publishMQTT(topic, payload)

That’s all I can think of at the moment. Questions below. Corrections welcome!

JGKK · June 24, 2019, 6:29am

One note. I would highly recommend updating to the Openhab 2.5 M1 release if possible. Many of the more severe bugs in the Mqtt binding are fixed there and outgoing transformation were added.
Thank you for the nice write up of your experience.
Johannes

leif · June 24, 2019, 12:18pm

That scares me a bit, I’ve only been using openHAB for a couple of weeks and feel I may not be ready yet. Then again, 2.5.0M1 looks like it has been out for almost half a year now, and maybe i’m worrying for nothing. Is there a guide you can point me to, so I can read through and see what the update process involves?

Bruce_Osborne · June 24, 2019, 1:18pm

(Questions from another newbie)
What installation method did you choose? OpenHABian or some other method?

rlkoshak · June 24, 2019, 8:16pm

First let me thank you for posting this. We need more MQTT 2.x tutorials and topics.

But I can tell that much of this is driven by frustration and part of that frustration is driven by soem inexperience with OH and how OH works and a bit of subjective dislike for how event Channels in the MQTT 2.x binding work.

This is true of all bindings really. The change from 1.x to 2.x requires essentially a complete rewrite. Because MQTT is one of the more heavily used bindings, there are s disproportionate number of posts about it. And the MQTT 1.x binding has been around for a very long time so there are a lot of really old posts.

When OH 2 came out, there was a similar challenge figuring out Astro, Exec and many of the other heavily used bindings. In some cases setup and use became simplified (e.g. zwave) and in others the setup became much more complicated, but we got new features as a result.

It’s worth mentioning that OH comes with an embedded simplified MQTT broker. It can be installed from the Misc tab in PaperUI. It could be good if you just want something simple and don’t want to worry about security or extra features. For “production” I’d still recommend a stand alone MQTT broker like Mosquitto. But it’s worth mentioning this other option.

This is not correct.

You can create a Channel on the Broker Thing which will create an event type Channel. Event type Channels can trigger Rules directly. In the Rule there is an implicit variable called receivedEvent that, in the case of MQTT, contain <topic>#<message>.

It’s not a work around. It is the designed and expected way it’s designed to work.

Because a button press is an event, using event type Channels on the Broker is probably a more appropriate choice. And keep in mind that the one topic approach is not incompatible with this. You would still need the one Rule, but you do not need any Items.

Though, I can’t remember if event topic Channels were implemented in OH 2.4. It might be an OH 2.5 M1 feature.

If you use PaperUI to create your Things, the Broker Thing is selected from a drop down list so it isn’t as important to use something more human friendly. But I’d still recommend using something descriptive instead of the randomly generated ID.

This is fixed in 2.5 M1.

There are cases where a wildcard subscription could make sense. For example, what if you combined the MQTT topic structure from your original approach with the messages in your second approach?

And, as discussed above, if you need to know the topic, you should use a Channel on the Broker Thing and a Channel Rule trigger. Then the topic will be carried along with the message in the receivedEvent implicit variable.

A Channel can also be just a publisher or you can have a Channel that is both a subscription and a publish which can be good, for example, when one has a light switch that has a separate status and command topic.

It’t not a work around. I’ll repeat my explanation from the other thread.

The “normal” approach is that you have a Thing. The Thing represents a device. That device has one or more controls or sensor readings. Each is represented by a Channel. Channels get linked to Items. By the time you get to the Item, the Item shouldn’t know the MQTT topic. All other things being equal, it shouldn’t even know that it is linked to an MQTT Channel in the first place. So there shouldn’t be any information about the MQTT topic in the Item. One of the main points of Items is to normalize out all the differences between all the different technologies.

It’s not arbitrary. It is a well thought out and intentional design decision.

The so called “work around” is the expected way one would try to do what you are trying to do. A button press is an event. It doesn’t have a persistent state. So it shouldn’t be assigned to an Item. This is exactly what Channel Rule triggers were created for.

I don’t really see how this

rule "Process button press"
when 
    Item MyButtonItem received command
then
    switch(receivedCommand.toString) {
        case "btn1_pushed": // do stuff
        case "btn2_pushed": // do stuff
        ...
    }
end

is any better than

rule "Process button press"
when
    Channel 'mqtt:local:button' triggered
then
    val rootTopic = "home/mcu/LivingRoomMCU/433mhz/"
    switch(receivedEvent.split('#').get(0)) {
        case rootTopic+"CeilingFanRemoteBtn1": // do stuff
        case rootTopic+"CeilingFanRemoteBtn2": // do stuff
        ...
    }
end

The mqtt:broker:local:button Channel would use a wild card subscription to all the button topics.

The latter has just a bit more logic but it doesn’t require defining an Item. And except for the split, the extra logic is logic you would have to use anyway if Items carried the Topic that a message came from.

I don’t understand the statement. But essentially you are correct. One of the differences between 1.x bindings and 2.x bindings is 2.x bindings define Things with Channels and the Channels link to the Items. 1.x bindings put all the binding config on the Item itself and it is unsuitable for automatic discovery of devices.

But if you want to have one or more MQTT topics assigned to a single Item, all you need to do is link one or more Channels to that same Item. You can even configure how those multiple Channels interact using profiles (e.g. when a command is received on one Channel the follow profile will forward the command to all the other Channels linked to on that one Item.

First it is important to realize that openHAB works on a rolling release. Only if a really really bad bug is found would it be back ported to a previous release. For the record, this has never happened. The only difference between OH 2.4 release and 2.5M1 is that 2.5M1 has received about a month’s worth of bug fixes and changes that didn’t make it into OH 2.4, and to a very minor extent, it has received a tad less testing. Honestly, I recommend all users of OH to be using at least OH 2.5 M1. Based on helping people, it is more stable than 2.4 and there were tons of bugs fixed and new features added to the MQTT binding in particular in that month.

You are using openHABian. So it’s a simple matter of running openhabian-config and selecting 40 | openHAB related and selecting 41 openHAB testing. I think you might then need to run 02 | Upgrade System, but it might do it on it’s own.

If you are running on a Debian based Linux then openHABian is recommended approach, particularly for newer users.

leif · June 25, 2019, 12:39am

@Bruce_Osborne

leif · June 25, 2019, 1:16am

I can’t argue with that :). The subjective dislike came from frustration, I’m sure it will go away eventually. Thank you so much for taking the time to reply.

I really wasn’t complaining, I was just making an observation to let future visitors be aware in a way that I wasn’t when I started. I have no doubt that 2.x is a huge improvement. I am aware that it’s possible to use 1.x bindings in 2.x, but I would guess that now is not the time to start using a legacy binding considering support will likely (and understandably) only dwindle… and this is from a guy who used Visual Studio 6.0 as my main productivity tool until 2015. It first came out in 1998 and that’s when I started using it. I stuck with it until 2015 and it worked for me but I wouldn’t have recommended anyone else to start on that platform in 2014.

I didn’t know this, but I will say that installing mosqitto was the easiest part of the whole experience.

AHA! That explains it. I believe you’re right. Here is the long and exhaustive list of available channel types in OpenHAB 2.4:

You’re right.
I think the sticking point for me is because I’m a programmer. Note that I didn’t say “i work as a programmer”, it’s totally who I am. I will admit that I am not the target openHAB user, if there is such a thing. For this particular task, I think I just wanted openHAB to host and run my script, let me get the MQTT messages and get out of the way, because for what I was trying to do, there was no functionality to be added by having channels and items defined – it just added another layer of complexity. If I could have subscribed from my Jython script, believe me, I would have! That would have taken much less time, because I knew I would have to script it to get the desired behavior anyway.
In my particular case: a 3-button remote control to control 3 fans… but not one button per fan, because I wanted one button to control all the fans equally, so that I could just push one button to turn on all the fans, while letting others in my household who like turning on just one fan to still do that. All buttons should bump the speed of its particular fan(s) in a 0-1-2-3-0-1-2-3 sequence (7 button pushes depicted just then) but the ALL-button is special because what if the fans are not all set to the same speed? They should be synchronized in a sensible way first.

Also, long-pressing any button should turn off the applicable fan(s).

Here’s how I did it:

	def __call__(self, event):
		splitevent =  event.itemState.toString().split("*")
		button = splitevent[0]
		payload = splitevent[1]

		fanstate = [ir.getItem("KitchenFan1").getState().intValue(),ir.getItem("KitchenFan2").getState().intValue(),ir.getItem("KitchenFan3").getState().intValue()]

		#control just one of the three fans
		if button == "KitchenFan1" or button=="KitchenFan3":
			fanidx=0 if button == "KitchenFan3" else 1
			if payload == "long":
				fanstate[fanidx] = 0
			else:
				fanstate[fanidx] += 1
				fanstate[fanidx] %= 4

			events.sendCommand(ir.getItem("KitchenFan"+str(fanidx+1)),fanstate[fanidx])

			return

		#control ALL fans
		if (button == "KitchenFan2" and payload == "push"):

			mymin=min(fanstate)

			for i in range(3):
				if fanstate[i] == mymin:
					fanstate[i] += 1
					fanstate[i] %= 4
					events.sendCommand(ir.getItem("KitchenFan"+str(i+1)),fanstate[i])

			return


		if (button == "KitchenFan2" and payload == "long"):
			
			for i in range(3):
				fanstate[i] = 0
				events.sendCommand(ir.getItem("KitchenFan"+str(i+1)),fanstate[i])
			return

Notice how the “control ALL fans” action will first find out which fan is currently running slowest, and then run through and bump all the ones that are at that speed. That’s all it took to handle this button in code – I don’t know any better way.
This is obviously very specific to my situation, but it goes to the motivation for why I wanted to “just script the whole thing”, and then it would have been nice to just subscribe in code.

It isn’t! Well, #1 is fewer characters but not enough to make a meaningful difference.

The one thing that for performance reasons it matters where things are filtered.

For example, if we were to subscribe to “#”, our Jython script is going to be called OFTEN for no reason.
It is much better design to subscribe to the most narrow topic that encompasses all the topics we want, rather than to subscribe to everything and filter later. That is what I was trying to accomplish, in as easy a manner as possible, and this is why I don’t like the Publish trigger – this is why it felt like a clunky workaround, especially since adding one requires restarting openHAB 2.4 before things work again. It’s possible that I would have had a better experience if I had started on 2.5, and I’m starting to feel like I need to upgrade.

I meant I thought I could because I saw all these other community posts that did this, and it fit what I was trying to do, so I spent some hours trying to do it until I realized that I the openHAB 2.x binding simply doesn’t support that method of operation. Trying to save future visitor time.

Okay! I’m convinced. I will do it. But hey, marketing is everything. If it had been called openHAB 2.4 R2 rather than openHAB 2.5 M1 I would not have hesitated to install it from the get-go. If it had been the officially recommended release on the download page, I would also have started with it.

Hang on – I’m actually running raspbian. I’m using openhabian-config now but I did not start that way, I installed openHAB through apt-get (because openHABian setup did not complete for me, tried several times, and I did not know about openhabian-config – I followed the linux installation guide and that worked). I only just installed openhabian-config to be able to install “frontail” and then later “mosquitto”. Can I still use openhabian-config to upgrade openHAB even though I originally installed openHAB with apt-get?

I followed this guide. It lists three options.

the openHABian project. I downloaded the openHABian image, etched it to an SD card and let the raspi start and do its thing. Failed after a long time of downloading things. Tried again twice, with different SD cards and a different raspi. Failed again. So I gave up and went to option 2:
a package repository (apt, yum). I installed raspbian (worked fine) and then tried apt-get, it worked.
manually from file. I never got there because option 2 worked.

Note that the documentation did not mention that “you can also run openhabian-config on top of your existing linux-installation” and I was completely new to openHAB so I had no way of knowing. I didn’t find out about that until after several days on the forum.

rlkoshak · June 25, 2019, 4:02am

I was going from memory. The Publish trigger is what I’m talking about.

I don’t think they’re is anything that would prevent this. You’d need to download the Paho library and you should be able to subscribe. Managing the event loop might be a pain though. Luckily there really isn’t a need to.

Don’t subscribe to #. That’s wasteful as you rightly point out. Subscribe to home/mcu/LivingRoomMCU/433mhz/#

There is nothing about the publish trigger that forces you to only subscribe to everything. You can subscribe to a single topic or as broad or narrow as desired so long as it’s valid from the MQTT perspective. See the event but tutorial I payed earlier today for more examples.

It’s really hard to make any recommendation except the official releases in the docs. The milestones are supposed to occur once a month, but after the release sometimes problems are found where one binding is really really broken and another has must have bug fixes. Whether or not a specific release is a good idea is going to be highly context dependent. In this context, if you are using mqtt 2.x, 2.5 m1 is the better version.

openhabian-config is just the GUI to drive the set up of openHABian. If you use it, you are using openHABian. openHABian is just a bunch of configuration scripts that work on Raspbian or any other Debian based Linux distro. For openHAB, it just runs the apt commands so of course you can use it to change the version of openHAB you are running.

leif · June 25, 2019, 11:14am

Okay, I installed 2.5.0M1. It did not go without incident.

I did it through openhabian-config. I updated openhabian-config, upgraded the system, rebooted (to make sure it still worked) and then did installed openHAB-testing.

A whole bunch of new errors in the log such as:

bundle org.eclipse.smarthome.core:0.11.0.oh250M1 (102)[org.eclipse.smarthome.core.internal.scheduler.PeriodicSchedulerImpl(123)] : doFindMethod: Suitable but non-accessible method found in class org.eclipse.smarthome.core.internal.scheduler.PeriodicSchedulerImpl

A quick google search told me they were normal.

At first the Z-Wave snapshot binding (from last week, to get one of my devices working) wouldn’t load because of the same stupid serial bundle related error I fought for so long last week… but deleting /var/lib/openhab2/tmp and /var/lib/openhab2/cache actually took care of that, and z-wave suddenly worked again. Yay! Time to uncork the champagne.

Well, not so fast.

None of my Jython scripts were working.
Turns out the installer trampled /etc/default/openhab2 without warning. Funny, because it did warn about trampling another file (org.ops4j.pax.logging.cfg) which I had also modified manually, so that gave me the chance to back it up first. That was nice.

So, I put the following back into /etc/default/openhab2 as per the JSR223 Jython config guide:

EXTRA_JAVA_OPTS=-Xbootclasspath/a:/home/pi/jython2.7.0/jython.jar \
  -Dpython.home=/home/pi/jython2.7.0 \
  -Dpython.path=/etc/openhab2/lib/python

Restarted openHAB. Still the same problem. No jython joy.

Then I checked the /home/pi/jython2.7.0 folder and it wasn’t there. My first reaction was openhabian-config deleted jython! wtf!

So I re-installed jython (to that folder) and then at least it activated scripting support for python on startup… but then I got an error for every script: “ImportError: No module named core in at line number 11”

Took me a good couple of hours of chasing my tail, and I was about to restore a backup, when I thought to sudo find / -name “*jython*”.
And of course… I never installed jython to /home/pi/jython in the first place. I installed it to /usr/local/lib/jython2.7.0/… well, s__t. I didn’t remember that… that was a lifetime ago! I’m sure I didn’t pick the location myself, I followed a guide, but I couldn’t say what guide at this point.

So that explained why jython magically went missing… but still, none of the scripts would load – no module named core in .

As a last resort, I restored the clonezilla backup from this morning to another SSD and booted it on another raspi, and looked at /etc/default/openhab2

…and what do you know.

EXTRA_JAVA_OPTS="-Dgnu.io.rxtxOC.SerialPorts=/dev/ttyUSB0"
EXTRA_JAVA_OPTS=-Xbootclasspath/a:/usr/local/lib/jython2.7.0/jython.jar \
  -Dpython.home=/usr/local/lib/jython2.7.0 \
  -Dpython.path=/etc/openhab2/automation/lib/python

So, the python libs weren’t even in /etc/openhab2/lib/python as recommended here… they were actually in /etc/openhab2/automation/lib/python as recommended here.

Okay, so, concluding recommendations:

Please make path recommendations consistent.

…and the big one:

For the love of god, please modify openhabian-config not to trample configuration files that have necessarily been edited by the user without warning. The modification is part of the jsr223/jython installation process, and please note that this file is outside of the normal openhab configuration directories so it’s not part of the default amanda backup. In short, I’m glad I used clonezilla.

Anyway… it’s finally up and running now.

And, I’ll be damned if my z-wave network doesn’t seem faster. Even the wallmote seems to respond nearly instantly now. I could be imagining things, but still. I think back to my fibaro HC2-days when it took a second for the lights to turn on after touching the wallmote… almost like X10. heh, those were the days.

So anyway. Thank you everyone for openHAB. If I sound frustrated occasionally, that’s because I am (openHAB is not an easy animal to tame), but believe me when I say I do love openHAB and I do appreciate all the developers hard work, and all the great help in the forum. openHAB is miles ahead of anything else, alone in its class in my opinion.

A couple of days ago, just for the heck of it, I logged back into the fibaro forum and searched for MQTT. Found several threads asking for MQTT, lamenting about how the company doesn’t care, and the company being blissfully silent, and people complaining. It would be wrong for me to try to steer people away there, and would certainly get me banned, plus most of them certainly wouldn’t be able to handle openHAB… but at least I can vent here. Good riddance, fibaro. Glad to be here and not there.

rlkoshak · June 25, 2019, 2:36pm

That’s a new one to me. The error does look somewhat benign though.

There is an option to openhab-cli that can do that. See Clear the Cache. It’s a little important to make sure to stop openHAB before clearing the cache.

@Benjy, is this an oversight in the apt package? Should I file an issue? It seems like it should warn before overwriting /etc/default/openhab2 just like it does the other config files. Maybe there is a reason it doesn’t?

No is the time for me to make my Ansible pitch. I no longer install nor configure anything by hand any longer. I do it all through Ansible. Why? Because once it works I have my system configuration captured in code and rebuilding or repairing a system is a simple matter of running my scripts again. I frequently need to go back to them to remember where I put things or how I’ve configured things and the like. The short amount of time I spent up front to learn it have been more than recovered.

In fact, I don’t take full machine backups anymore. I backup the data and if I ever need to recover from a disaster I can just start from scratch and run the Ansible playbooks and I’ll be back up and running, usually in minutes.

Over the past few months there have been a huge amount of changes to JSR223 and the helper libraries. The docs have not been kept up. We are waiting for a number of significant changes to be merged before we recreate the docs. But I was unaware that the OH Docs right now still uses /etc/openhab2/lib and not /etc/openhab2/automation/lib. automation has been the right place to put them for quite some time.

This is a good candidate for a first PR. Click the link at the bottom of the page and it will take you to the file in github where you can make the changes in the browser. You will need a github account. See How to file an Issue for details.

At a higher level, to address your recommendations, any recommendations made here on the forum are unlikely to be acted upon. They need to be filed as an issue on github.

Chris has been hard at work improving Zwave for sure.

Lack of MQTT support in a hub in this day and age is a huge oversight. MQTT has become the lingua franka of IoT. At least among those of us who are cheap and possess just a little bit of skills.

leif · June 25, 2019, 3:39pm

Since you hadn’t seen it before, here’s the complete version:

2019-06-25 19:22:07.851 [INFO ] [.internal.GenericScriptEngineFactory] - Activated scripting support for ECMAScript

2019-06-25 19:22:07.875 [INFO ] [.internal.GenericScriptEngineFactory] - Activated scripting support for python

2019-06-25 19:22:09.745 [INFO ] [panel.internal.HABPanelDashboardTile] - Started HABPanel at /habpanel

2019-06-25 19:22:10.662 [ERROR] [org.eclipse.smarthome.core          ] - bundle org.eclipse.smarthome.core:0.11.0.oh250M1 (102)[org.eclipse.smarthome.core.internal.scheduler.PeriodicSchedulerImpl(123)] : doFindMethod: Suitable but non-accessible method found in class org.eclipse.smarthome.core.internal.scheduler.PeriodicSchedulerImpl
2019-06-25 19:22:10.665 [ERROR] [org.eclipse.smarthome.core          ] - bundle org.eclipse.smarthome.core:0.11.0.oh250M1 (102)[org.eclipse.smarthome.core.internal.scheduler.PeriodicSchedulerImpl(123)] : findMethod: Suitable but non-accessible method setScheduler found in class org.eclipse.smarthome.core.internal.scheduler.PeriodicSchedulerImpl, subclass of org.eclipse.smarthome.core.internal.scheduler.PeriodicSchedulerImpl
2019-06-25 19:22:10.670 [ERROR] [org.eclipse.smarthome.core          ] - bundle org.eclipse.smarthome.core:0.11.0.oh250M1 (102)[org.eclipse.smarthome.core.internal.scheduler.PeriodicSchedulerImpl(123)] : bind method [setScheduler] not found; Component will fail
2019-06-25 19:22:10.673 [ERROR] [org.eclipse.smarthome.core          ] - bundle org.eclipse.smarthome.core:0.11.0.oh250M1 (102)[org.eclipse.smarthome.core.internal.scheduler.PeriodicSchedulerImpl(123)] : bind method [setScheduler] not found
2019-06-25 19:22:10.678 [ERROR] [org.eclipse.smarthome.core          ] - bundle org.eclipse.smarthome.core:0.11.0.oh250M1 (102)[org.eclipse.smarthome.core.internal.scheduler.PeriodicSchedulerImpl(123)] : doFindMethod: Suitable but non-accessible method found in class org.eclipse.smarthome.core.internal.scheduler.PeriodicSchedulerImpl
2019-06-25 19:22:10.681 [ERROR] [org.eclipse.smarthome.core          ] - bundle org.eclipse.smarthome.core:0.11.0.oh250M1 (102)[org.eclipse.smarthome.core.internal.scheduler.PeriodicSchedulerImpl(123)] : findMethod: Suitable but non-accessible method unsetScheduler found in class org.eclipse.smarthome.core.internal.scheduler.PeriodicSchedulerImpl, subclass of org.eclipse.smarthome.core.internal.scheduler.PeriodicSchedulerImpl
2019-06-25 19:22:10.684 [ERROR] [org.eclipse.smarthome.core          ] - bundle org.eclipse.smarthome.core:0.11.0.oh250M1 (102)[org.eclipse.smarthome.core.internal.scheduler.PeriodicSchedulerImpl(123)] : unbind method [unsetScheduler] not found; Component will fail
2019-06-25 19:22:10.687 [ERROR] [org.eclipse.smarthome.core          ] - bundle org.eclipse.smarthome.core:0.11.0.oh250M1 (102)[org.eclipse.smarthome.core.internal.scheduler.PeriodicSchedulerImpl(123)] : unbind method [unsetScheduler] not found

I did indeed do that, wouldn’t expect it to have any desirable effect otherwise.

I will look into it! It may be too early in my linux career for me, but I’ll check it out.

Okay, I did! Tried, anyway. I have used git locally for years but never before worked on github (other than cloning repositories).

So, I branched, made the change in my branch, and then tried to make the pull request.
Got stuck on DCO - Action required. Developer certificate of origin, basically a EULA in reverse. Okay, fine, installed it. Then I got this message:

DCO

Action Required

You only have one commit incorrectly signed off! To fix, head to your local branch and run:

git commit --amend --signoff

How nice that I only have one unsolvable problem, but what local branch? I’m on a freaking web site. What command line?

So, I cloned the repository to my local drive, to give me a command line.
But guess what… there are no pending commits in my local repository. That’s on a web site with a command line I have no access to.

So, that’s where I’m stuck.

MQTT is just one of the many things they lack. It seems to me that the only way they can have a product so ill thought through and with so many arbitrary restrictions is if they don’t have any full-time programmers using the product themselves. They probably just hire consultants when it’s time to add a new feature or support for a new device, but there’s no actual maintenance, nobody working to try to make it better. Nothing to do with being cheap either, HC2 is $600. That’s just the controller, no devices. That would buy a lot of ESP8266’s indeed.

rlkoshak · June 25, 2019, 5:19pm

Hmmmm.

What it’s complaining about has to do with the signed off. Typically this can be handled by adding “Signed off by <Name> <email>” in the comment in the commit message. I think I ran into something like this myself not too long ago.

See the discussion here Change description of System started description by rkoshak · Pull Request #979 · openhab/openhab-docs · GitHub

This DCO check is relatively new.

Depending on the nature of your PR, it might be accepted as a small change. Otherwise I bet one of the maintainers can help out. Can you send the link to the PR and I’ll watch the comment thread and help out where I can.

When you clicked on the edit icon, what should of happened is it asked you to make a fork of the repo. Assuming your github account is “lief” then you can find your fork at https://github.com/lief/openhab-docs. The branch and your edits live in your fork. When you create the PR, you are submitting your changes to the main repo where it will be reviewed and merged with the baseline.

So when it talks about your local branch, it’s talking about your fork.

Now the big question is how to edit a commit message inside the web browser. But like I said, if the change is minor then there is an exemption to the signing off requirement.

I’ve updated my How to file an Issue tutorial because I think I had the part about adding the Sign off in the wrong place.

This is not unusual in any of the commercial home automation hubs. Wink, Vera, and even SmartThings all have only native support for a number of technologies and APIs you can count without taking off your shoes. If you want simple and relatively easy they are great products. But if you want more, you need open source.

marcel_erkel · June 25, 2019, 7:16pm

@leif
Don’t worry too much about the DCO check, it’s not a blocking issue. @Confectrician will be able to merge it anyway.

I must say that I enjoy reading your topics. I like your style of writing and your sense of humor has put a smile on my face more than once.
openHAB has a steep learning curve but you seem to master it pretty quickly. I appreciate you feeding back the things you run into and that you provide the solutions at the same time.

Welcome to the community!

Confectrician · June 25, 2019, 8:14pm

I haven’t had a look at GitHub now, but just for clarification for every interested reader.

DCO Check is just an automated check which helps us do our work a bit better/faster.
As every automated check or mechanism it can cause problems or fail.
If a maintainer checks those cases manually he/she has access to Override such failing check.

The check causes some confusion especially in the docs area since I would guess that we have a higher amount of contributor’s who use the GitHub website editor and this editor unfortunately doesn’t support signing off natively.

rlkoshak · June 25, 2019, 10:01pm

leif · June 26, 2019, 3:57am

Thanks, guys! I appreciate the kind words and the warm welcome.

Here’s the link.

Looks like @5iver is already on it.

Benjy · June 27, 2019, 8:28am

I don’t think so, /etc/default/openhab2 is marked as a configuration file so shouldn’t be replaced without the user being prompted.

I’ll have a look into it though, definitely can make debugging tricky if it gets replaced without a prompt!

leif · June 27, 2019, 9:55am

@Benjy I have a clonezilla image of my system with 2.4.0 from the morning before I did the upgrade. Between the image and the 2.5.0M1 upgrade I also upgraded a bunch of packages (through openhabian-config) and installed amanda, but I think that’s all I did.

So, it may be possible to repeat and reproduce the issue this way. Let me know if you need me to help, or if you want access to the image.

leif · July 2, 2019, 2:14am

@Benjy, I just updated to 2.5.0~S1627-1 today by running openhabian-config. It happened again.

/etc/default/openhab2 was clobbered without warning. This again broke Jython!

I only got one overwrite warning.

Also, it correctly noticed that openHAB was not running and shouldn’t start after upgrade… but then it went ahead and started it anyway.

Console output:

Configuration file '/var/lib/openhab2/etc/org.ops4j.pax.logging.cfg'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** org.ops4j.pax.logging.cfg (Y/I/N/O/D/Z) [default=N] ? y
Installing new version of config file /var/lib/openhab2/etc/org.ops4j.pax.logging.cfg ...
Installing new version of config file /var/lib/openhab2/etc/keys.properties ...

[openHAB] Listing important changes for version 2.5.0:
  Warning:  senseBox Binding: The senseBox binding is now using Units of Measurements, and the channel name for Illuminance has changed. The Items must be reconfigured.
  Warning:  Vitotronic Binding: The following channels have been renamed: 'outsite_temp' to 'outside_temp', 'pelletburner:power' to 'pelletburner:powerlevel', 'party_temp' to 'party_temp_setpoint' and 'save_temp' to 'save_temp_setpoint'
  Warning:  OneWire Binding: Some thing types have changed and need to be updated in textual configurations. See documentation for further information.
  Warning:  REST Docs: This add-on is now part of the UIs. When installing it using textual configuration, update 'services/addons.cfg' by removing 'restdocs' from 'misc' and add it to 'ui' instead.
  Warning:  EnOcean Binding: Channel 'receivingState' has been removed, because this was a string containing many information. For this, there are three new channels: 'rssi', 'repeatCount' and 'lastReceived'.
  Warning:  Mail Action: The mail action has been replaced by a new mail binding.
  Warning:  Homekit: Some tags have been renamed. Old names will not be supported in future versions. Please check documentation.

[openHAB] openHAB was not running so will not start after upgrade.
[openHAB] Please use the command:
            sudo /bin/systemctl start openhab2.service

Processing triggers for systemd (232-25+deb9u11) ...
Updating FireMotD available updates count ...

$ adduser openhab gpio
The user `openhab' is already a member of `gpio'.

$ systemctl daemon-reload

$ systemctl enable openhab2.service
Synchronizing state of openhab2.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable openhab2
OK

$ systemctl restart openhab2.service
Optimizing Java to run on low memory single board computers...
2019-07-02_09:09:48_+07 [openHABian] Adding an openHAB dashboard tile for 'openhabiandocs'... Replacing... OK
2019-07-02_09:09:52_+07 [openHABian] Checking for default openHABian username:password combination... OK
2019-07-02_09:09:52_+07 [openHABian] We hope you got what you came for! See you again soon ;)

Benjy · July 4, 2019, 8:42am

Okay, thanks for the info. There must be a step in openHABian that’s overwriting this, so I’ll take a look when I can (Coming back from Holiday on Sunday).

OpenHAB 2.4 MQTT beginner experience *principal conclusions* from a post-newbie

DCO

OpenHAB 2.4 MQTT beginner experience principal conclusions from a post-newbie