I believe that is only accessing via the REST API. If your rules hit the REST API then yes. If you are using something else you should be ok.
For all the rules posts, can you run “top” and see if your java process is running really high? Do you notice that your event bus is really laggy on actually updating?
1 Like
Same here. Problem with MergeList…
Latest Ubuntu Desktop
I wouldn’t say it’s really laggy, but it seems slower than 2.5. For example using hue emulation with Alexa, Alexa often complains that my lights are not responding, which happens when the item’s state doesn’t update quickly enough to keep Alexa happy. This happens a lot more with 3.0 compared with 2.5.
CPU usage doesn’t go above 12%
1 Like
Go to rules in MainUI and search for a substring of the rule name, it’ll list all to match, then spot yuor specific number
(@ysc Indeed it would help if the search included the -nnn strings so one could enter that directly)
Mea cupla - I have created a fix, so I’d suggest to move to the next snapshot instead, if this problem is permanent.
Trying to turn on all upstairs lights now just turns one on. @Kai is this related to the core change to use a threadpool for the rules?
Yes, it seems to be related to that, but actually the change now only provoked to bring this behavior to the surface as it existed before: The rule engine does not permit starting a rule that is already running. My assumption is that before the rules were triggered so quickly that the rule engine actually didn’t notice that they were running in parallel. Logging an error and not doing anything is probably the worst thing to do - let’s discuss on Rules fail to run with multiple triggers · Issue #1868 · openhab/openhab-core · GitHub how to best proceed.
FTR, the issue where @morph166955’s problem is analyzed is [OH3] 3.0.0M3 has substantial lag in processing and increased CPU · Issue #1852 · openhab/openhab-core · GitHub - so please better comment on that issue instead of here in the forum.
That I noticed as well. Often getting errors like the one below without really anything going on that would explain it. In M4 it became worse but that may be a misconception.
@kai could the threadpool change be related ?
2020-11-29 23:27:53.513 [WARN ] [ab.core.internal.events.EventHandler] - Dispatching event to subscriber 'org.openhab.core.thing.internal.CommunicationManager@132a993' takes more than 5000ms.
Unfortunately, that page is unusably slow when I load it (yes I should file a bug, I will attempt to do that this week). It can take close to a minute to scroll to a letter, and good luck click in the search bar. To be honest, even if the page did load, it isn’t the most elegant solution for those of us that are “CLI junkies”. It’s rare for me to pull the GUI up at all (my system is almost entirely voice controlled or triggered via inputs from motion sensors, remotes, etc). Also, I tend to do a bunch of work remotely (lunch breaks and things like that) and I only pull an SSH session back remotely which makes GUI access unavailable. Is it not “easily” remedied by adding the rule name to the error message that is thrown (in addition to the new rule identifier)?
You can use ssh port forwarding to access the web based GUI behind your firewall.
Normally yes, I would do that. Unfortunately it’s not as easy given that I’m pulling the SSH session back through guacamole. Either way, my point was that this was something we lost between 2.5 and 3.0 and the fix should be relatively trivial. I’ll file it as a feature request.
EDIT: I’ve posted this now: https://github.com/openhab/openhab-core/issues/1871
Never mind, it’s only in M4, not in the snapshot from the same day 
1 Like
Yep. I just wanted to report that again and tell sollution. Just open:
/var/lib/apt/lists/openhab.jfrog.io_openhab_openhab-linuxpkg_dists_testing_main_binary-i386_Packages
file for edition, go to almost end of the file and find:
Filename: pool/main/2.5.10/openhab2-addons_2.5.10-1_all.deb
SHA1: 1c171649fd4eb803db7fa04a21ec3feb21fa414d
SHA256: f7a240a166295b336afead20cc0af32aaeb2f1b1de425d0910ded9453d363ce6
Size: 199086412
as you can see this section is quite different from others, it does not contain Package at the beggining for example. When you remove this section from this file you will be able to perform update operation and upgrade your OH instance.
1 Like
I have an interesting one here - I have a Setpoint item in my sitemap - but it only works intermittently to change the temperature. I think this worked in M3.
I have two installations running M4 - both behave in a similar manner. When I click the up/down arrows nothing is registered in the openhab logs.
Also, the same behaviour whether the sitemap is loaded in Chrome or via the Openhab app.
1 Like
I remember laggy Setpoint items, I think they’re not updated unless the item was. If a change triggers a rule to run, that to finalize is being waited for. With those issues of multiple rules not running in parallel (easily triggered if you push the setpoint often) I’d think the cause is rather to be found over there so wouldn’t bother specifically looking after setpoints.
Is this a general recommendation to anyone having .rules files? I’m still on M3 and I don’t dare trying M4 if my rules won’t work 
1 Like
I cannot really judge whether the issues show up for everyone or just a few, but I’d consider it a bit risky to be honest. So if you want something quickly, I can confirm that the latest snapshot is fixed already. If you can wait, you might want to go for M5 next weekend. 
1 Like
I can confirm that my textual defined rules are back working with SNAPSHOT 2037.
Thanks @Kai for the superquick fix.