[RE-RELEASE] iRobot Scheduler

So glad I stumbled upon this thread. I just bought an iRobot Roomba J7+ and this looks like the best way to get it integrated into my smart home. The Alexa integration is super lame constrained by the limitations of routines. Will give this a whirl and let you know if it works.

Make sure you add the ROBOT_CIPHERS for the J+ as outlined in this (or one of the following) post: [RE-RELEASE] iRobot Scheduler - #29 by dman2306

2 Likes

I had to reinstall my Braava Mop from scratch because I had a hardware problem. Thankfully iRobot just sent me a full replacement. After setting up successfully in the iRobot app, I wanted to reinstall this awesome app on my pi4 and HE.

Would it be correct to assume that I can start with the Rest980 configuration steps in these instructions? Since my rpi is unchanged from the prior Mop, I'm assuming I don't need to reinstall Dorita980 and Rest980. And the rpi already has a share drive and already has Node and GIT installed.

Despite all this, after pressing Dock/Spot on the mop and getting the tone 2 seconds later, when I pressed the "Press any key in the SSH Windows #2", I got the below error message, which I've never seen before. Any ideas? I do have the correct IP address and it is reserved. TIA...

Then press any key here...
Robot Data:
undefined
events.js:377
throw er; // Unhandled 'error' event
^

Error: connect EHOSTUNREACH 10.0.0.21:8883
at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1159:16)
Emitted 'error' event on TLSSocket instance at:
at emitErrorNT (internal/streams/destroy.js:106:8)
at emitErrorCloseNT (internal/streams/destroy.js:74:3)
at processTicksAndRejections (internal/process/task_queues.js:82:21) {
errno: -113,
code: 'EHOSTUNREACH',
syscall: 'connect',
address: '10.0.0.21',
port: 8883
}

Make sure you don't have your iRobot App open on your phone, as only one client is allowed to connect via your local LAN. If your phone is occupying that connection, then dorita980 cannot, and vice versa (of course your phone can fall back to the cloud connection)

If you want to manually test that the connection can be established from your Pi, you could try running command nc 10.0.0.21 8883 and hit enter a few times. If it can't connect it should return an error, otherwise it might print some garbage binary data or just blank lines. Can ctrl-C to exit the command and get your prompt back.

Sure enough I did have the iRobot app open on my phone. After I killed that (hard closed), I reran get-roomba-password and got the same error. Repeatedly. Grrr. My router definitely sees the Braava.

When I issue "nc 10.0.0.21 8883" and enter a few times from the command prompt, I just get the command prompt after a second or two, without any errors or anything else. FWIW my pi4 is headless--I am using SSH from MacOS via Terminal to control the pi. Maybe this has to be done physically from the pi?

EDIT: I ended up reading up on Dorita980 and trying some other diagnostics. I think my problem is actually with a flaky wifi connection. The mop shows shows up on the router then disappears. If I then open the iRobot iOS app, sure enough it says the robot is not connected to the network. Weird. I think I need to solve my robot connectivity issues first. BTW, when I did "nc -zv [IP address] 8883" instead of just "nc [IP address] 8883", I got the expected "No route to host response". After rebooting the robot and seeing it was connected to the network (and making sure the iOS app was closed), I did the nc command, and got a succeeded response. Thinking I was in great shape, I went back to get-roomba-password and still got the same error.

Hmm, so this is getting curiouser and curiouser. Here's what I can easily reproduce:
0. Make sure all ios iRobot apps are closed

  1. nc -zv [mop IP] 8883 from pi via terminal returns "Connection to .... port [tcp/*] succeeded!". And my router sees the mop with a reserved IP address. All good.
  2. get-roomba-password [mop IP], then go press & hold home/spot on mop for a couple seconds. The mop chimes and LED turns blue. Still looks okay.
  3. Back at the terminal, press any key generates the same error message. Crapola. At this point, my router no longer sees the robot and nc command on pi returns "No route to host".

Importantly, the mop never falls off wifi if I leave it alone or use it through the ios app. As soon as I issue the get-roomba-password, it's like poof. The router doesn't see it anymore and the ios app doesn't either.

FWIW, I can issue a get-roomba-password-cloud, and there's no error, I get the blid but not the password. Also this new braava (which is a new hardware replacement from irobot) is running 3.20.7. Dorita980 makes it sound like the robot firmware is newer than What has been thoroughly tested.

Anybody have any ideas?

Ah, the newer firmware may be the catch... Might need to read some of the above posts regarding the new j7+ vacuum. The newer firmware apparently doesn't allow local discovery once it's connected to WiFi - which my explain why your attempts to do so cause it to disconnect.

The get-roomba-password-cloud command should return both the blid and password from what I've read... From there, you may also need to set the ROBOT_CIPHERS (again, see the j7 posts)

1 Like

I suspect you're right. I completely rebuilt my pi from raspbian up today just in case. And I got the same error. I was able to get blid & pw from get-roomba-password-cloud, but it still didn't work. Will need to read the j7 posts and see what I can figure out. Thanks for all the help.

I have the J+ and had to do a few unique things to get it to work;

  1. Pull the creds from the cloud per this post: [RE-RELEASE] iRobot Scheduler - #19 by dkilgore90
  2. Needed to change the TLS ciphering setting (I did it via systemd) per this post: [RE-RELEASE] iRobot Scheduler - #31 by SoundersDude
2 Likes

Thx @SoundersDude for pulling the specific details...

1 Like

For anyone that follows me that has a robot with new-ish firmware (e.g., Braava at 3.X.X or above, J series Vacuum), the special instructions provided by @SoundersDude two posts up contain the incremental instructions that get everything to work. They saved me.

@dkilgore90, maybe you want to include this in your main instructions on the git readme?

Thanks both!

2 Likes

Question for the group, I use the official iRobot in-app scheduling for cleaning during the week - as the WAF is high as she can easily understand it, but I'd like to use this integration to turn that schedule OFF when we are on vacation so I don't trigger my house alarm.

I'm wondering if that is possible to turn a schedule off or if not is it just easier for me to 'stop' and 'dock' the robot via this integration device commands if it kicks off while we are in vacation mode?

Having a hard time between Dorita980 and Rest980 documentation figuring out if stoping an inapp schedule is supported.

Reading the dorita980 and rest980 docs, I think it should be possible, by updating the preferences cleanSchedule data... May need an enhancement on the HE side to be able to invoke this capability.

Wife is out of town, so nothing better to do than tinker with Hubitat!

@SoundersDude new releases -- app:1.6.0 and device:1.3.0, include features you have requested. Finally got around to adding the poll interval as a preferences setting, and added new device commands pauseAllSchedules and resumeAllSchedules -- these should take effect on both Hubitat and iRobot App schedules

1 Like

Amazing! Thank you!
Will give them a go soon when back from my work trip

Is there any documentation for iRobot Scheduler? I got it up and running and everything seems good. But, it's not clear what the controls on the device do. For example I would have thought turning the Roomba (my case Rosie) ON would start her up. And turning her OFF would return her to the Dock. Doesn't. The status is updated correctly in a Dashboard tile, and I can click on Dock and she'll dock, but other than that and the ability to clean based on presence - which is what got me here in the first place - I'm not sure what else I can do. Anyway, back to the first question, is there more documentation somewhere? Thanks for all the work that went into getting this integration going.

Others probably have more/better answers, but my understanding is the on/off is really just the ability for this to look like a 'switch' in automatons. So you can trigger things based on the on/off states. While the other device commands are more 'actions' you can take that leverage what's available in Rest980.

A few use-cases I have for the existing commands;

  1. When our roomba starts cleaning (manual or scheduled through the Roomba app), I have a rule that captures what lights are on/off, then sets a scene where most my lights turn on. When the roomba is done, I revert the lights to the previous state I captured.

  2. When we are in Vacation mode, I cancel all scheduled runs so it doesn't trigger our security alarm (also don't need it cleaning while we are on vacation).

What Roomba model do you have? Depending on your model, the switch capability can be configured for:

  • On: start / cleanRooms
  • Off: stop / dock

If it is not behaving the way you expect, the easiest way for folks to help is to post:

  • What actions/commands you ran
  • What behavior you expected
  • What behavior you observed
  • Logs from the app and device

It's an i4. No buttons work out of the gate. If I initiate "Vacuum Everywhere" with the iRobot app I can see the status/icon change. If I push the Off button it returns to the dock. I have it setup to vacuum when we are out of the house, but it doesn't work. Again, I'm glad to dive in, I was looking for just any documentation at all about how to configure it.

The README file in the GitHub repo has some documentation, but that's about it. I know there are a lot of configuration toggles in the App page, perhaps I could document them better.

From your description it sounds like 1 of these things is happening:

  • You have configured "on" to trigger "cleanRooms", but have not specified any default regions/rooms JSON
  • You have set up presence-based settings but no schedule (I would have to double-check, but I don't think presence is currently a trigger without a schedule trigger firing first
  • Some other condition, unexpected behavior, or bug - would need logs to investigate