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?
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
Cool
solved the problem for me 
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:
Ok i am filing and issue on github on the missing dimmer switch events:
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.
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.
Now that an issue has been entered and @cweitkamp is looking into it, it might be a perfect time to point you to Bountysource, where users actually CAN post a bounty on issues that they wish to have solved - and no: No bounty is too low since it can always be regarded as a kind gratitude to the developer, who picks it up, even if he isn’t impacted by the issue himself.
Thanks again Rich for taking time to respond. Based on what I can see in the logs, it does NOT look like OpenHAB is doing a full system restart. My Rules are in several different files as I’ve tried to organize them based on function and hardware interaction. I only have a single rule in “My Presence Detection” .rules file that is called when “system started”, and nowhere else. This rule sets the groupPresence to off when triggered and then notifications are sent when we arrive home and groupPresence is set to on… This happens when our phones pass through a geofence(GPSTracker) or are reconnected to our LAN or iCloud. If I create a new item and link it to a new or existing thing, then this rule is being triggered. I’ve randomly tried a number of different Things and same behavior results. Just very peculiar “New Behavior”. Don’t waste anymore of your time this as it seems to be limited to me. I’ll keep digging and if I can pin this down I will report back as down the road it afflict others.
Thanks again for your help.
It’s no waste of time.
The fact that the behavior changed is interesting. Back when I used Rules DSL I think I recall this happening, but I use .items files. When I would update a file that defines an Item all of the .rules files that reference the Items defined in that file would reload too, triggering all the System started rules in the process. This makes some sense because important things like Member of triggers could require a reload of the .rules files when Group membership changes. I’ve no experience with REST API created Items though so don’t know what to expect with that.
I do agree though, unless a lot of people see the same behavior it probably not something critical but it’s probably worth filing an issue. I would guess it would go on the openhab-core repo. See How to file an Issue. It may be nothing, it may be a regression, it may be working as designed.
Rich. Your post gave me an idea since you are running the latest Snapshot. I did not see this problem until M6/RC1 when the MQTT bug was introduced. I currently do not run MQTT with my setup, but i do have it installed to tinker and learn. So I updated to the latest Snapshot and the problem behavior disappeared. Now at least I know the root cause even if I don’t understand the details of the interactions and it looks as though it will be dealt with in future releases.
Thanks again.
didn’t fully follow this issue so my answer might be off-target but just wanted to let you know that a file reload/reparse also takes places after you manually edited .things, .items or .rules files (and “system started” in that case triggers, too).
When did your issue start? I am also facing a rule reloading issue under M6, but I think I saw you write that your issue only started on RC1.
It started with M6 and has persisted through RC1. I did not see it in M5 and prior milestone releases. As noted, it seems to be fixed in the latest snapshot. I think it has something to do with MQTT bug which was introduced in M6 and is now fixed in the latest snapshot.
Anyone else having issues with Homekit in OH 2.5 RC1? No issue with 2.5 M6, but I can’t get Homekit working with RC1. I have removed the addon, cleared cach/tmp, restarted 2 times, re-added, restarted and still cannot see any of my Homekit items on my iPhone.
The following error is in the log:
2019-12-12 20:17:31.568 [ERROR] [org.openhab.io.homekit ] - bundle org.openhab.io.homekit:2.5.0.RC1 (293)[org.openhab.io.homekit.internal.HomekitImpl(318)] : The modified method has thrown an exception
java.lang.RuntimeException: HomekitHttpServer can only be started once
at io.github.hapjava.impl.http.impl.HomekitHttpServer.start(HomekitHttpServer.java:34) ~[?:?]
at io.github.hapjava.HomekitRoot.start(HomekitRoot.java:112) ~[?:?]
at org.openhab.io.homekit.internal.HomekitImpl.startBridge(HomekitImpl.java:120) ~[?:?]
at org.openhab.io.homekit.internal.HomekitImpl.modified(HomekitImpl.java:97) ~[?:?]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_232]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_232]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_232]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_232]
at org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod.java:228) ~[bundleFile:?]
at org.apache.felix.scr.impl.inject.methods.BaseMethod.access$500(BaseMethod.java:41) ~[bundleFile:?]
at org.apache.felix.scr.impl.inject.methods.BaseMethod$Resolved.invoke(BaseMethod.java:664) ~[bundleFile:?]
at org.apache.felix.scr.impl.inject.methods.BaseMethod.invoke(BaseMethod.java:510) [bundleFile:?]
at org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:317) [bundleFile:?]
at org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:307) [bundleFile:?]
at org.apache.felix.scr.impl.manager.SingleComponentManager.invokeModifiedMethod(SingleComponentManager.java:836) [bundleFile:?]
at org.apache.felix.scr.impl.manager.SingleComponentManager.modify(SingleComponentManager.java:791) [bundleFile:?]
at org.apache.felix.scr.impl.manager.SingleComponentManager.reconfigure(SingleComponentManager.java:709) [bundleFile:?]
at org.apache.felix.scr.impl.manager.SingleComponentManager.reconfigure(SingleComponentManager.java:673) [bundleFile:?]
at org.apache.felix.scr.impl.manager.ConfigurableComponentHolder.configurationUpdated(ConfigurableComponentHolder.java:435) [bundleFile:?]
at org.apache.felix.scr.impl.manager.RegionConfigurationSupport.configurationEvent(RegionConfigurationSupport.java:316) [bundleFile:?]
at org.apache.felix.scr.impl.manager.RegionConfigurationSupport$2.configurationEvent(RegionConfigurationSupport.java:118) [bundleFile:?]
at org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:1709) [bundleFile:?]
at org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:1651) [bundleFile:?]
at org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:138) [bundleFile:?]
at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:105) [bundleFile:?]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_232]
Please show your bundle:list. It seems that HomeKit ist starting two times. Do you have HomeKit installed and another version in your addons-directory?