[SOLVED] OpenHAB 2.5 RC 1 Critical Issues

Same to me, as well with Mosquitto.
all commandTopics works fine, but none of the stateTopics.

You can find the instructions on the GitHub issue youā€™ve linked:

Please update the ā€œopenHAB Core :: Bundles :: MQTT Transportā€ bundle with https://janessa.me/esh/org.openhab.core.io.transport.mqtt-2.5.0-fs.jar this one and report back. Instructions https://janessa.me/esh. option 2.

4 Likes

Somehow I have 2 MQTT transport bundles:

262 ā”‚ Active   ā”‚  80 ā”‚ 2.5.0.RC1                ā”‚ openHAB Core :: Bundles :: MQTT Transport
269 ā”‚ Active   ā”‚  80 ā”‚ 1.14.0.RC1               ā”‚ openHAB MQTT Transport Bundle

Iā€™ve deleted the 1.14 and upgraded the other one to 2.5.0.201912101757.

So far everything seems OK. Maybe this was the cause of my MQTT issues I experienced with M6.

MQTT: For me only topics that are retained do not work. But normal ones work fine.

It looks like you had MQTT21 & MQTTv2 both installed

What exactly is not working? Please provide debug logs (or better trace).

1 Like

@David_deMarco linked an issue that was already merged. Iā€™ll wait when next snapshot be out and will retest. For me only part of subscriptions were not working for some reason. No idea why.

This issue has been resolved by upgrading to the latest stable version.

Thanks @rkrisi I missed that bit (jetlag and system upgrade not good idea). Full steps in one place to help others given MQTT is used so much now. (updated with improved karaf command)

sudo systemctl stop openhab2
sudo sudo openhab-cli clean-cache
sudo systemctl start openhab2

Confirmed here that MQTT state updates now failing.

Open the Karaf console:

openhab-cli console
bundle:update org.openhab.core.io.transport.mqtt https://janessa.me/esh/org.openhab.core.io.transport.mqtt-2.5.0-fs.jar
logout

restart openhab - do not clear the cache

sudo systemctl restart openhab2

Confirmed that MQTT states are now working again - Canā€™t comment on retained messages. Note I also had some suspect issues with openhab-cli not stopping Openhab so playing it safe here.

thanks @J-N-K for prompt fix

Update: I had to reboot my rpi3 and the connection to the MQTT Broker failed with

OFFLINE - COMMUNICATION_ERROR io.netty.channel.AbstractChannel$AnnotatedNoRouteToHostException: No route to host: /10.88.87.180:1883

A manual stop and start of openhab resolved the issue.

1 Like

There is an issue with usb-serial devices on RC1 as reported by @Andrew_Rowe, @davorf and I experienced it on Windows 10 and Raspberry PI (using openhabian 1.5): the serial items (zwave controller and RFXcom for me) keeps reinitializing on openhab level, it is fine on the command line (using lsusb, dmesg etcā€¦). It was causing very high memory and cpu usage and even using swap, the pi was unusable after a few hours.

Switching to latest snapshot, for me it is 1774, fixes the issue

1 Like

Thatā€™s strange because 1774 doesnā€™t have any differences compared to RC1 regarding those bindings and the serial communications code AFAIK.

Thereā€™s a 1775 snapshot build now thatā€™s the same as RC1 plus the MQTT fix and some ScriptEngineFactory changes.

Maybe you can check if the issue is resolved after restarting openHAB without clearing the cache?

1 Like

This solves also my issue below!

To save some steps, you can specify the bundle by name rather than numberā€¦

bundle:update org.openhab.core.io.transport.mqtt https://janessa.me/esh/org.openhab.core.io.transport.mqtt-2.5.0-fs.jar
6 Likes

Cool

1 Like

solved the problem for me :ok_hand: thank you!

I created this thread in the community forum and i was told that is related to the getEvent() issue.

I was not brave enough to create an issue, as i didnā€™t want to create more work for the project members and i thought there was already one as i thought this is related to the getEvent() issue.

Of course not! I am absolutely sorry if this was the message of my post. I am very grateful for the work of cweitkamp and the others who are contributing to this project. I just read his post and suspected that he did some work in the hue binding and is not able to pursue the support of the plugin anymore:

2 Likes

Ok i am filing and issue on github on the missing dimmer switch events:

3 Likes

Not sure if this is new ā€œfeatureā€ or an unintended consequence of recent changes, but it seems that every time I use PaperUI to add or delete a Thing or Item, an OpenHAB System restart is initiated. This did not seem happen prior to 2.5.0M6. I am running OpenHAB in Docker. Did I miss something along the way?
UPDATE: This issues seems to have resolved. I rolled back to 2.5.0M5, deleted the cache and tmp directories, updated to 2.5.0RC1 and restarted the docker 2 twice. Since doing this I have not noticed any restarts when I add Things or Items using PaperUI. I believe this glitch is real, but was easily resolved at least for now.

UPDATE2: Since I now know this thread is not intended as an alternative to bug reporting on git, this update is more of an FYI. However the restarts when using PaperUI to add a new Thing or new Item are back. Itā€™s more of an annoyance for me and I may not have even have noticed except that I have a rule that triggers when ā€œsystem startedā€ and results in a notification being sent. However I wonder about the efficiency of this approach when adding a large number of Items or Things with PaperUi.

Before I do anything on git, can anyone confirm if this behavior Is by design or indeed a bug. As I said, I did not notice this before M6, and my rules have not changed.

1 Like

Iā€™m pretty sure this is not by designā€¦maybe. Are you certain that OH is actually restarting, or are you just seeing your System started Rules executing again? If the former, this is not expected behavior. If the latter, I think this is expected behavior.

ā€œSystem startedā€ is somewhat of a missnomer. It runs whenever the .rules file is reloaded which can occur in response to events besides a full openHAB restart. I am not seeing OH restarting when I create an Item through PaperUI.

Rick, thanks for the insight and I guess Iā€™m not sure which is occurring, but based on the fact that you are running docker and not seeing this I am inclined to believe that it is the latter. Also I misspoke. It occurs not with the creation of an Item per se, but linking a new item to a thing.

What is throwing me is that I did not notice this behavior before M6 and the Things and Items I was adding were not related to any of my current rules. Can you think of anything in the logs that I should pay particular attention to? I did notice that all of UI (Hapanel and BasicUi) do seem to get reloaded as well when this happens. I will dig a bit to see if I find the root cause. For me it is mostly an annoyance as my system is well developed and I would only occasionally add something new. For a new user however, if real, it could be more of an issue.

Well, what getā€™s printed to openhab.log should make it pretty apparent whether OH is completely restarting of the .rules files are just reloading. If restarting you will see a bunch of ā€œstopping service Xā€ type logs followed by ā€œstarted service xā€ type logs when OH comes back up.

Do you see any ā€œLoading moduleā€¦ā€ log statements when you link to an Item? Are all of your Rules in one .rules file or many .rules files? If many, do all of your system started Rules run or only some of them?

I created and linked an Item to a Channel through PaperUI that I did not previously have an Item linked to and again (new Item, new Link), I did not see anything unexpected. Neither my rules ran (Iā€™m using Scripted Automation so canā€™t say if .rules files would have run) nor openHAB restarted. So I donā€™t think itā€™s specifically Docker at play here.

Removing the Link and the Item also did not cause anything unusual to happen. Iā€™m running the latest SNAPSHOT, not RC1 (I got hit by the MQTT bug that was fixed yesterday).

You would see that behavior if OH decided it needed to reload your files for some reason.

1 Like