First, I'll point out that these are warnings, not errors. It's possible that rest980 may run fine without further action.
That said, to cover any potential issues arising from the "missing peer dependencies", I'd direct you to the "Updated Solution" from this stackoverflow link:
For each peer dependency,
npm install --save-dev xxxxx
One thing you could try, is to edit the namespace definition in the App and Driver to dkilgore90 -- then run a Match Up in HPM. I'm hoping that this will make HPM change the association to my registry and packageManifest, then it will pull existing and future updates from my repo.
So I haven't used my Raspberry Pi since I tried incorporating Wyze products into HE (and then gave the lot of their sensors away because the integration wasn't great)... Not sure if some of the issues I was having was from when I had worked on that project or not...so I did a factory reset of the pi and re-installed everything, etc., and then tried again. In general, it did go better, I think... I did run into a hiccup when I got to the step " * [SSH Window #1] Edit ../rest980/config/default.json" - I didn't realize I needed to change the "Edit .." - but read through the thread and saw the detailed steps @codyalanbryant posted and realized I wasn't typing the correct thing in. Once I switched what I was typing to "sudo nano ~/rest980/config/default.json", I was moving along again. I followed kind of a hybrid of @codyalanbryant's instructions and the ones on GitHub... Only ran into a few minor hiccups after that, but in the end managed to get it setup on HE. Hopefully sharing my experience/headache helps someone else troubleshoot their issues.
I have a feature request (may already exist). Is there a way to know if the robot is not on the dock and is not cleaning? Twice now, my i7 must have been bumped or something and it looks like it on the dock charging but it is not. When I go to use it, the darn thing is dead. I know there is an alert for when the battery dies, but is that anytime or just when it is cleaning?
I was curious if something could be exposed that alerted when robot was off dock but was not cleaning?
Hope I am making sense.
Thanks!
Reviewing the code -- looks like the alert for when the battery dies only triggers if it dies while in a "docking" action. I'll look at expanding this to other cases.
Beyond that, you could set up a rule in RM to trigger on certain cleanStatus states -- "idle" would be the primary one -- something like this:
The action could be a notification, or even to send a "dock" command to the roomba -- I'm thinking you set a "delay" of 10min or so, which is cancelled if the state becomes "charging". Entire rule:
Does anyone have this working when you do NOT specify default rooms? Whenever my scheduled time happens it never runs and it logs an error saying I should use start instead of cleanRooms. From what I can tell it's because the rooms variable is the string value "null" instead of actually being null.
Argh -- I see the problem, the first if in handleDevice, under case "cleanRoom" only checks for default rooms, but not whether the rooms are provided in the call stack -- will push a fix shortly...
Wait a tick... sorry, I think there is an issue there, but might not be your issue.
@dman2306 In your schedule, have you defined any rooms JSON, or is it empty? (Or do you not even have an i7/s9 that is capable of room-based cleaning?)
I do have an i7, and no I did not define any rooms. I just want it to clean everything.
Ok -- can you post (or DM me) the Application State roombaSchedule variable, and the Settings entry roombaOn? Would like to confirm these values to know which code path your schedule should be taking.
And roombaOn is set to start. The problem seems to be rooms is set to the string value null, not actual null
Strange... I agree that it seems that some non-null value is getting passed in, but I'm not sure yet how that might be occurring... with no rooms provided in the schedule on my hub, it properly selects the device.on() instead of cleanRoom. Will keep digging into this, and likely add some additional debug logging to collect data in the next release.
Any luck? I definitely determined that it is getting a string value of "null" I just haven't tracked down where that is happening.
Busy week at my real job 
- but I pushed a quick fix (untested 
) that should handle the specific case of 'null' as a string. Will try to add some more debug logging when I have more time.
Just an update, it didn’t seem to work for me.
Hi,
Is there a way to disable the schedule completely? In the options it's mandatory to select at least a day/hour
You can comment out lines 603 and 605 (// at the beginning of the line) in the App code, so that when the scheduled time is hit, it doesn't actually start the Roomba.
I logged a ticket in GitHub for a potential future enhancement to have a preference to fully disable the schedule: Preferences toggle to fully disable scheduling · Issue #18 · dkilgore90/iRobot · GitHub
Curious, what is your goal with disabling the scheduling?
This is a great App but just beyond what I needed.
So I actually customized a device driver for my own use, certainly not perfect but feel free to use and modify as you wish. My goal was to have a device I could automate via WebCore as part of other automations and monitor via dashboard (generates its own tile attribute). Still requires the rest980 server as above.
I have models 890 and 960, it works for both, not tested on any other models. Supports all basic commands (on, off, start, stop, dock, pause) and status (battery, bin, runtime, error, offline). It does not include any fancy scheduling, notifications, etc that the above app does but those can be customize by your favorite rule app (RM, WebCore, etc).
My need is to be able to start it manually. I need to organize the house so roomba/braava don't get stuck with some of the objects in my house. I guess your driver would be able to do just that. I'm going to take a look at it. Thanks!
Download the Hubitat app
