@dkilgore90 thanks for the updates - got back around to trying to fix this. Still getting the same type of behavior.
Here is a screenshot of one of my test schedules - it's setup for just a specific time (when I was testing) and presence is off. It never fires. nothing in the logs just the trace data every poll.
When I go to the device and manually control it - works fine. If I pause schedules and re-enable them here is the log:
It's like it just does not have a schedule at all.
Interesting... I'm unable to reproduce the error you see in the logs, but have line of sight on a potential fix, reworking the logic a little. Out of curiosity, are you running an older Hubitat SW version? Wondering if there's some groovy difference that causes your hub to evaluate differently 
On the scheduling problem, need to dig a bit deeper... I think I know why it's not working, but not yet sure how to fix.
Thanks for digging! I'm on:
Platform Version
2.3.3.140
Hardware Version
Rev C-7
I think I sorted it out -- a little coffee in the morning helps 
. Likely this has been broken for a while, since 1.6.0 I think -- but only exposed in new installs or if someone changes their App settings.
App version 1.6.8 contains the latest fixes -- some spot checking on my hub, it seems to work, but as always LMK if something comes up wrong on your end 
I have been successfully using this app for a while now and wanted to add my second iRobot, Braava Jet m6. I followed the procedure for multiple Roomba devices from my RPi by creating and changing the folder name to Rest980-1 as well as the port number. I started a new roomba1.service, then tested the connectivity in a browser and got the proper response {"documentation":"https://github.com/koalazak/rest980","pong":"2022-11-17T22:40:19.549Z"}
When I created a new iRobot Scheduler app using the server ip address and the other port (4500), I get " Rest980 Server cannot be reached - check IP Address
The log indicates a Internal Server error.
Did I miss something? Thanks for any thoughts on that.
Hmm, interesting. Seems that we are getting a response from the new rest980 server, but it is an error response. Would suggest to look in /var/log/syslog on your rPi - and correlate timestamps with the errors seen in your Hubitat logs, for additional context. Happy to review what you find if you post it here.
I did some more testing today to no avail. However, I did manage to change the ./rest980-1config/default.json file to include the blip, password, and IP address of the Braava, and also changed the port just for testing purposes. The connectivity in the browser tested fine. When I changed the port # in the HE iRobot Scheduler app to match the one in the rPi default.json, it created the new device and I was able to get it going no problem.
So, it looks like the app doesn't accept the same IP address to use the other rest980-1 server. As soon as I go into Add User App and click on iRobot Scheduler, I get the message Rest980 Server cannot be reached - check IP Address even before I enter the IP address and port #. When I enter the IP address and the new port #, then the log on the rPi and HE show what I posted yesterday.
I'm curious to know if anybody has been able to manage a second iRobot with this app. I'm still wondering if I missed something.
Yes, i have both my Roomba i7+ and my braava m6 mop managed, via 2 rest980 installs on the same rPi - 2 instances of the app, each with their own device in HE.
My original thought was that something may be corrupt in your rest980-1 install, and to try reinstalling this instance. But you threw that out the window, since your initial iRobot App on HE is able to communicate with it?
Can you double-check in your browser,
http://ip:port/api/local/info/state
This should return a lot of JSON with various details about your braava mop, and is the same API that the HE app is calling to discover and poll for states...
Thank you for your help on this one. The fact that you have both devices working suggests to me that something is wrong in my install.
I double-checked the .../api/local/state in the browser and did get an "TypeError: myRobot[source][method] is not a function" which is the same error reported in the /var/log file on te rPi. If I do the same for the first instance of Rest980, it reports a lot of JSON details as expected.
So, unless you think there is something else I should try, I'm going to start from scratch again. Just to make sure I'm doing the second install correctly, this is what I did once the first Rest980 is installed and operating:
I take that I don't have to install Dorita980 a second time. If wrong, what directory?
Yes, the above looks right. Dorita980 should be installed globally, from the -g option, so don't expect you need to reinstall - but maybe retry the following before you completely start over:
sudo systemctl stop rest980-1
sudo npm install -g dorita980 --save
sudo npm -g install dorita980
cd rest980-1
npm install
sudo systemctl start rest980-1
If starting the second install from scratch, I would suggest to either wipe out the existing rest980-1 dir, or install into a new rest980-2 dir. Make sure if setting up a systemd service file to use a unique service name and reference the correct working directory.
This is getting weird. I completely wiped out traces of existing any rest980 and rest980-1 on my rPi, as well as removed codes for the iRobot Scheduler app and driver on both of my HE hubs.
Then, I re-installed Doria980 and Rest980, following precisely the steps you recommended. I double-checked with the browser that both services for the Rest980 and Rest980b were reporting as expected, and they did.
However, upon re-installing the app and the driver codes, I got the app going and to my amazement saw Rest980 Server cannot be reached - check IP Address right off the bat!!! I hadn't even entered the ip address yet, which was still blank! It was as if the app and/or the hub had that error still active in memory. I did the same procedure with my other HE hub and got the same results (I had rebooted both HE hubs prior to re-installations).
As I do the http://ip:port/api/local/info/state in the browser, I get the same error TypeError: myRobot[source][method] is not a function, which is also reported in the rPi /var/log/syslog.
Needless to say, I'm at a lost here. I'm also wondering whether my router is interfering in this communication somehow. Does that "TypeError: myRobot[source][method] is not a function" mean anything to you?
This isn't any caching or memory, the app just isn't intelligent enough to realize the reason that it cannot reach the server is because the IP hasn't been entered. I should look into masking this at least during the initial install.
This is internal to the rest980 endpoint mappings to dorita980 functions - seems somehow the mapping for /api/local/info/state is not lining up as expected... See rest980/routes/api.js at master · koalazak/rest980 · GitHub for these definitions.. could try a couple other local endpoints in your browser just to check, e.g. /api/local/info/sku or /api/local/info/mission -- to see if these throw a similar error.
Bottom line, it seems like the issue is in your rPi setup/install/runtime, not on the Hubitat side. Maybe an npm compatibility issue? (I vaguely recall needing to update some dependencies when I installed, but it was several years ago.
Well, here is a good news and a bad news! The good news is I finally was able to get it going. The bad news is I have no idea how I did it, other than keep trying!
So, sorry for taking your time on this issue. I'm still curious as to why this was so much trouble and I'll dig into it to see if there is any lesson learned here.
Hello and Happy New Year!
Currently using iRobot Scheduler v1.6.8 (app) and Roomba v1.3.0 (driver). Using a rasberry pi as the server. I wanted to note an issue I spotted. If you have anything entered in "First rooms:" AND the mapping has not been run and the cleaning map shows completely blank. Assuming you've got notifications enabled the scheduled run will notify that cleaning has started and then a few minutes later it will notify that the roomba is charging. Roomba doesn't move off the dock or make a noise.
I was racking my brain trying to figure out why everything was working besides scheduled runs. I figured an update might solve the problem so I waited. Since the updates have not solved my problem I started poking it again. About a week ago I noticed I had a "1" in the "First rooms:" option column. Once I removed that "1" and tested scheduling. It now works flawlessly. I forgot I added the "1" at some point in the past tinkering with it trying to get scheduling to work. It never crossed my mind to go back and remove it. I suspect that scheduled run was failing as it wasn't able to pull anything labeled "1" from the room data and the scheduled run timed out. However this is just a casual user speculating on what is happening so I'm probably wrong.
Highly recommend the user not put anything in the "First rooms:" column without a complete install. I imagine an over eager first time user may accidentally put something in that column before they bothered to complete mapping thus triggering scheduled runs to fail. Hopefully someone finds this info helpful in debugging if they can't find any other reason why scheduled runs aren't working.
Has anyone had any success with the cleaning map option? Everytime I mess with it, it's just blank. If anyone else has used this or got it working would love to compare notes!
I'm guessing it's in there somewhere but I can't find it. When my roomba turns it it cleans everywhere. What I would like it to do is to clean a favorite I created with the iOS app called "Most of Basement" which excludes the workshop where she always gets stuck. How do I tell it to do that when it's turned on instead of everywhere?
@wafox w.r.t. the live mapping feature, it's more of a rest980/dorita980 question than the Hubitat integration. I did this issue on GitHub which implies that the position reporting from the robot which was parsed for this feature is not reported after a certain iRobot firmware update... Folks still trying to pick it apart in that thread.
@wiegout I'm not aware of a way to pull favorites from the app, but assuming there are equivalent "rooms" built in the map, you can use the cleanRooms function to trigger cleaning of only those specific "rooms". There is a bit of manual effort to identify the room IDs of interest via manual triggers in the app and query of the rest980 server, to set up...
Would it be possible to add an option to skip the cleaning if the Hubitat Safety Monitor (HSM) is armed?
Download the Hubitat app
