Irobot Roomba Max 705 - Communication error

Add-ons Bindings
1

I’m running openHAB version 5.1.1 and I would like to add my Roomba® Max 705 Combo Robot to it.
The binding is able to detect it and I can add it as a thing.
I have also entered the password.
After that, I get a configuration pending status and a robot authentication successful message, but then I receive a communication_error – timeout.

Does anyone have an idea how I can solve this?

2

I have exactly the same problem..

3

Also here. Seems to be related to MQTT connection to Roomba:

2026-02-08 22:37:53.127 [INFO ] [.transport.mqtt.MqttBrokerConnection] - Starting MQTT broker connection to 'Roomba-[ID-here]' with clientid [ID-here]
2026-02-08 22:37:53.183 [WARN ] [rnal.handler.IRobotConnectionHandler] - MQTT connection failed: Timeout

Same issue persists after rebooting Roomba. Not sure this appears since binding of openHAB release 5.1 or 5.1.1?
Posted a bug report: [irobot] Persistent Connection timeout issue · Issue #20199 · openhab/openhab-addons · GitHub

4

… same problem here since switching from 5.1.0 (working) to 5.1.2 (communication error). Seems to be SSL related?!

javax.net.ssl.SSLProtocolException: (unexpected_message) Received close_notify during handshake

Hope this can be fixed!

5

It’s also happening on 3.4. Not related to the OH version, therefore.

I suspect something changed at the Roomba end.

Rebooting the robot enables it to connect again, but when OH reboots it often (but not always) loses the ability to connect and you get the timeout error. Rebooting OH again doesn’t seem to help. Once it’s disconnected, that’s it until you manually reboot the robot.

6

I’ve solved the problem by uninstalling the iRobot app, which I had on my phone and tablet. I read somewhere that MQTT only allowed one connection at a time; either previously I didn’t have the app installed at all, or the app has changed and now kicks off other connections to establish its own. At one point the robot got completely disconnected from openHab and I couldn’t reconnect it, so I had to install the app to reset it and get it connected again, and from then on it would disconnect from openHab with a timeout after a few hours. Rebooting the robot by pressing Clean for 20 seconds and then uninstalling the apps solved the problem.

7

I have a roomba S960 which worked well in openhab 4.3 but after upgrading to 5.1 i had the same issue.

I could detect and resolve it:
Several problems:
first, roomba uses an expired TLS ceritficate (expired end 2025), this needs to be accepted in openssl.cnf
then, rooma uses old SHA1 alorithms, these need to be accepted in java21 (java 17 from OH 4.3 was relaxed on these).

so, here’s what i did:
sudo nano /etc/ssl/openssl.cnf
==> add a new policy:
[openssl_init]
ssl_conf = ssl_sect

with
[ssl_sect]
system_default = system_default_sect

[system_default_sect]
Options = UnsafeLegacyRenegotiation
CipherString = DEFAULT@SECLEVEL=0

to accept the weak sha1 cipher

in java21:

sudo nano /etc/java-21-openjdk/security/java.security
to remove TLS_RSA_* from the jdk.tls.disabledAlgorithms section, because java 21 seems to block rsa-ciphers without forward secrecy, but my roomba needs TLS_RSA_WITH_AES_256_CBC_SHA

then it worked. So, I believe this can’t be fixed in the irobot binding, only in the underlying ssl and java frameworks.

8

I don’t think this is an issue. The binding uses TrustAllTrustManager, so I believe it’s forgiving about expired certificate:

I just wanted to reproduce the problem in my 5.2 snapshot instance, but the binding went immediately online without any issues. So it seems that under some circumstances it can work with Java 21. I’m wondering if the reason it works on this machine is that it’s running Windows 10.

9

Reproduced now after upgrading to JDK 21.0.10.

10

old devices with old algorithms that don’t get updates any more

plus

new backend software that tightens security policies with every release cycle

==> a recipe for nightmares…

I am still not sure that my modification of the openssl-config was absolutely necessary (or whether the binding does everything through java), i just used openssl to test the connection to my roomba using

openssl s_client -connect 192.168.8.17:8883 -legacy_renegotiation -cipher "DEFAULT@SECLEVEL=0" -provider legacy -provider default

and it complained about expired certificates and weak ciphers. After defining and using more relaxed policies (like above), the connections could be established, so i kept this config without rigorously testing the limits of the absolutely necessary.

11

The minimal change that got it working for me again was to update jdk.tls.disabledAlgorithms and replace TLS_RSA_* with TLS_RSA_WITH_AES_128_*, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_RSA_WITH_AES_256_GCM_SHA384, so that only TLS_RSA_WITH_AES_256_CBC_SHA is whitelisted.

I also found this announcement: Critical Java Security Update: TLS_RSA Deprecation in JDK-21.0.10 and JDK-25 Can Cause MQTT Connection Failures

This configuration property can be read by the binding, so it’s possible e.g. to provide a better Thing status description and prevent infinite retries with INFO logging per connection attempt. I’ll have a look at that. It looks very hard or impossible to fix this in openHAB.