This has been addressed before, but not fixed.
I’ve been looking at creating a local version of the updated library and see if it solved the issue, if that works it would be nice to have this fix included.
What would be the way forward for this?
It seems that the problem is that the upstream library is more or less abandoned, nothing has happened there for a couple of years.
I tried to ping the owner just now, if we’re lucky, he’ll do something: Fix of !empty response introduced in RouterOS 7.18 by dangelcz · Pull Request #90 · GideonLeGrange/mikrotik-java · GitHub
But, as I understand it, for this to be fixed, the fix must be merged in the upstream library, a new version of the library must be release, the openHAB binding must update the version of the upstream library, and a new version of the openHAB binding must be released. In other words, not a quick process under any circumstances.
You haven’t posted an example of these stack traces, and I couldn’t find a complete one in the references post either. What is essential is the very start of the stack trace and the line immediately before it. It will show where in the code the stack trace is logged. It would then be possible to turn logging completely off (by setting the log level to OFF) for the coordinates of the logging class. That would obviously mean that you won’t see any other errors or problems from there either, but it sounds like that might be “worth it” for now.
One option could be to include the abandoned code into the binding directly; the lib is not that big.
I’ll do some testing the comming days.
The stacktrace is:
2026-07-21 17:56:10.788 [ERROR] [andler.MikrotikRouterosBridgeHandler] - RouterOS cache refresh failed in mikrotik:routeros:79be3eb146 due to Mikrotik API error
me.legrange.mikrotik.MikrotikApiException: Command timed out after 60000 ms
at me.legrange.mikrotik.impl.ApiConnectionImpl$SyncListener.getResults(ApiConnectionImpl.java:483)
at me.legrange.mikrotik.impl.ApiConnectionImpl$SyncListener.access$100(ApiConnectionImpl.java:437)
at me.legrange.mikrotik.impl.ApiConnectionImpl.execute(ApiConnectionImpl.java:118)
at me.legrange.mikrotik.impl.ApiConnectionImpl.execute(ApiConnectionImpl.java:76)
at org.openhab.binding.mikrotik.internal.model.RouterosDevice.updateResources(RouterosDevice.java:420)
at org.openhab.binding.mikrotik.internal.model.RouterosDevice.refresh(RouterosDevice.java:203)
at org.openhab.binding.mikrotik.internal.handler.MikrotikRouterosBridgeHandler.performRefresh(MikrotikRouterosBridgeHandler.java:220)
at org.openhab.binding.mikrotik.internal.handler.MikrotikRouterosBridgeHandler.scheduledRun(MikrotikRouterosBridgeHandler.java:208)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.base/java.util.concurrent.FutureTask.runAndReset(Unknown Source)
at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.base/java.lang.Thread.run(Unknown Source)
Caused by: me.legrange.mikrotik.ApiConnectionException: Command timed out after 60000 ms
at me.legrange.mikrotik.impl.ApiConnectionImpl$SyncListener.getResults(ApiConnectionImpl.java:475)
... 13 more
This is in line with issues referenced in the original post.
I’ve created a local 3.0.9 version of the mikrotik-java library and compiled an updated 5.2.0 version of the mikrotik binding. I used bundle:update to update the running OpenHAB instance with the local build. This solves the log messages, and the binding seems to work properly.
So it is safe to say that the fix works for the binding. The problem of the abandoned dependency remains. I’ll check if I can move the mikrotik-java code inside the binding.
I’ve created and issue:
It would help if people would chime in there 
I have MikroTik RouterOS 7.23.2 on a HAP AX3 and do not seem to be getting this issue. How do you re-produce it as you did not write that info in the bug report. What is your RouterOS version? and have you tried the latest, which is the one I just posted at this point in time.
I am currently on 7.21.4 LTS.
The problem occurs when I use the binding to do a presence check with mikrotik:wifiRegistration it will check connected stations and timeouts because the upstream library cannot handle the return from the newer routerOS (see issue above).
Then why do I not see this issue, what is the difference? I am using default packages that newer devices come with which do not include capsmann. I use the newer AX wifi 6 hardware which uses a different package called “wifi-qcom” so my guess is that the bug your mentioning is for older packages as I do see any such logs or errors. The library and binding changes how it works depending on the installed packages. I do not know if your able to use a newer package if if it is tied to the wifi hardware that you use. Either way try going to the latest version firmware which is always a good idea to do.
I always like to stay at the LTS version; granted, there is a newer version for LTS, but it doesn’t mention anything on the API.
Can you use the api.py to test the sequence mentioned in the issue here: support api 7.18 · Issue #89 · GideonLeGrange/mikrotik-java · GitHub
The current upstream library doesn’t support the newer API response; that is causing the issues I am experiencing.
You still have not given steps to reproduce this. The error you posted seems to indicate this happens during a refresh. Can you give the TRACE log output before this occurs as it will probably show the command that is getting sent and what package the binding is using. I can only guess that this is happening on older generation hardware simce the mikrotik hardware is cheap compared to other brands, is it worth upgrading? As mentioned I do not see any issues and have been doing some changes in the binding recently. If I can not reproduce it or know exactly where in the code it’s failing I can do do much and I have limited time to donate towards other people’s issues when I have lots of code changes needing to be done for my own home.
The issue is well documented, both in my issue at the OpenHAB GitHub and at the upstream library.
The fact that you don’t see the issue on your installation is no proof that I should not have the problem. (Absence of evidence is not evidence of absence)
I am not asking for any of your time to resolve the issue, since I’ve already tested the update that should resolve the problem. If you look at the discussion of the GitHub issue, you’ll see that I am willing to put in the time and effort to submit a PR.
I am fully aware of the limited time people have to investigate problems they cannot replicate, so in this case it is clear you cannot help, and I am totally fine with that.