[RE-RELEASE] iRobot Scheduler

Great catch, but luckily I did do this and that is how I got my passwords when following your steps, as the "hold" instruction would just kick off the vacuum bin, so I went to the dorita980 git readme to see if there was a workaround and found the cloud API.

Now, I have a suspicion that http://192.168.0.66:3000/api/local/info/state doesn't behave the same on the J. The next thing I'm going to do is see if I can get any of the /info/ states when the Roomba is in action, as on the dock I'm getting empty JSON returns.

Ok. Let me know... there was much discussion around the J7 in this issue: https://github.com/koalazak/dorita980/issues/142 - I think it was opened by @dman2306 - maybe he has some guidance?

1 Like

The only other item I can suggest would be to review /var/log/syslog on your pi for any errors or details that might provide insight into dorita980 and/or rest980.

1 Like

Yup. J7 is working fine for me. I went down the road of using a proxy on iOS (I used Charles, not Thor as described in that thread, but same principles apply). After grabbing the blid and password everything just worked as expected both on the dorita and Hubitat side. The state command is working fine for me.

1 Like

Interesting. I went the cloud API route to get those, I wonder if those are wrong or different enough? Would love to be in your state.

Two things. What version of nodejs do you have on the pi? And also did you change the TLS cipher setting?

Node: v12.18.2

I don't recall every having done that as I wasn't aware that was needed (or frankly don't know what that does), so probably not, are there instructions for that?

Cool that version of node should work. I’ll get the cipher variable later tonight. Not at home right now. It was “documented” as in it was mentioned in the GitHub issue thread but that’s all I saw.

ROBOT_CIPHERS=TLS_AES_256_GCM_SHA384 npm start --prefix=/home/pi/rest980-basement&

That's the command I have setup in my rc.local, it works for me. Without that ROBOT_CIPHERS though the app can't communicate with the roomba.

2 Likes

If you've set it up in systemd, you can add this line in your /etc/systemd/system/roomba.service file, under the [Service] section...

Environment="ROBOT_CIPHERS=TLS_AES_256_GCM_SHA384"

EDIT: added quotes above

Should accomplish the same end of having the ROBOT_CIPHERS set in the environment for the nodejs process(es)

2 Likes

Life savior. That did it for me!

I tried that before going the rc.local route, but it didn't work for me.

What I was really hoping to do is have this managed by PM2. But was struggling to get the startup environment right.

Thank you both, I'm not NOW sitting with a working HE + J7 Integration!! :raised_hands:

2 Likes

Hoping and guessing you meant now :upside_down_face:

Haven't ever tried PM2, but this page might help? PM2 - Environment Variables

1 Like

Loving this integration. Successfully have an automation capturing my current lights state before turning all of my lights on, then restoring the previous state after the Roomba is done cleaning.

One question I have for you @dkilgore90 - is how often does this app poll for status? This app is the most active app on my hub, and am interested in tweaking a bit if possible to reduce how often it's checking.

It polls every 30s - see the Cron expression here: https://github.com/dkilgore90/iRobot/blob/master/Roomba/Roomba-app.groovy#L1285

I can easily make this configurable - there is one catch... previous developers built in a dormancy check: https://github.com/dkilgore90/iRobot/blob/master/Roomba/Roomba-device.groovy#L134-L158 - to try to auto-recover if for some reason the App stops calling the driver - this checks once a minute, and triggers an App initialize if there is no action within 5 minutes. Obviously if the App polling rate is adjusted, this dormancy check would need to back off too.

Super helpful! I don't mind making the change in my own app code for now, as I do prefer to move the polling to every 60 seconds, which would probably mean I should change the dormancy check to every 1.5min or 2min.

If in the future you made this configurable in the UX, that would be awesome. But it might just be me looking to reduce the pull.

1 Like

60s you're probably ok, I was more thinking if it only polls every 2min or even 5min, then the cutoff to re-initialize the app needs to go from 5min to 10 or 15...

1 Like

Where are the png files for the dashboard? Thank you.

Ex: roomba-charge.png

Never mind. I found them,

Yep, that's the original repo - same images also in my forked repo here:

Ok. Thank you for responding.