wmcneil

I have disabled schedules from the Roomba phone app for both my phone and my wife's phone. After several days of testing, I have found that I can connect reliably to the Roombas from ISY only if I first reboot the PG3 node server. So it seems likely that the Roomba phone app is connecting locally to the Roombas periodically even when no schedules are enabled in the Roomba app. For the purposes of testing, I guess I can try uninstalling the phone app from both our phones.

I submitted a ticket just now to ensure this does not get lost.

@JimboAutomates, I am able to display text on keypads, but have discovered the following bug: In the AC, my email customizations are using ID 1 through 13, and then id 18 through 26. (The ID value is not something the user controls, and the AC is not using ID 14 through 17 for whatever reason.) When specifying what customization I want displayed, the Content selection pulldown is showing me only the customizations corresponding to ID 1 through 13, and those for ID 18 through 26 are not displayed.

I also observed that when the AC was behaving as if frozen, that the node server was logging what appear to be updates from roomba. @bpwwer, can you comment here, if the node server is logging updates from roomba, that argues against the one-local-server slot being taken, do you agree?

I have also seen that a run that is initiated by a schedule event on the roomba app results in AC sometimes staying in communication with the rooma, and other times appears locked out from communication with roomba. It seems possible/likely that when the AC appears locked out, it is because the one local connection that roomba supports is in use by the roomba app. Continuing this speculation, it may be that sometimes the scheduled run happens without any interaction with the local roomba app (i.e. the roomba cloud server is in play), and other times the roomba app is involved (I have no idea what factors might cause these two different behaviors). When the roomba app is consuming the one local connection, the theory is that the node server is unable to communicate with roomba.

Was the roomba started from the roomba server, or from the node server?

Thinking some more about a use model to deal with the only-one-local-connection issue: Let's explore using only the node server for day-to-day scheduling/running of the roombas. (I am making the assumption here that if the phone app is not configured with any automatic schedules for the roomba, there is no possibility of the phone app consuming the local connection. A firmware update could use it, not sure how often that occurs, and will assume it is infrequent enough to be ignored for the purposes of this discussion.) What features/functions are missing from the node server? Here are ones that come to mind: For models with the Clean Base (charging base with integrated bag that allows roomba to self-empty its full bin by returning to clean base, and then potentially continue cleaning): node server does not have an "empty bin" command. Most of the time the Roomba will automatically empty its bin and continue cleaning without requiring an explicit independent empty bin command. Occasionally, when in doubt about whether the Roomba bin is really empty, I have used the "empty bin" command on the Roomba app, but that is very infrequent for me. For models that support mapping, and are capable of cleaning only a specific room, and also capable of avoiding areas using the mapping interface on the phone app: Clearly the setup for the mapping can only be done with the phone app, but that setup occurs quite infrequently. I virtually never use the "clean only one room" feature. Alexa interaction: I don't use this feature at all, so I can't comment here. So maybe for my use model, the "use only node server for day to day scheduling/running" will work. I should mention my primary motivation for wanting to use the node server: The roombas can set off my motion detectors on my alarm system. So I want IoP programs running that detect if any roomba starts while the alarm system is armed, and immediately stop the roomba(s). If the phone app/scheduling is used to start the roombas, the problem with this approach is that sometimes the node server can not communicate with the roombas (due to only-one-local-connection problem), so there is no way to achieve the goal.

I reran a test with 2.0.7 . Log file attached. I made sure all roombas were docked and charging, then restarted the roomba node server. Search in the log for "2022-05-02 09:40:01,306" for the restart of the node server. I started up just the i7+ roomba from the phone app. (It was also the case in the last test that I posted results for that only the i7+ roomba was running.) This time the IoP AC was reporting the status of the i7+ correctly. I suspect what @fahrer16 posted above about the roomba mqtt server consuming the one local connection, and precluding the node server from connecting, is happening sporadically, and causing the problems (sporadically) when the phone app is used locally. (Not clear why sometimes this happens, and other times I can initiate a run from the phone app and the AC does report correctly - Is the Roomba phone app sometimes not using the local connection for unknown reasons? It would be nice if the roomba app had an option to only use the cloud. ) There are lots of settings and controls that can be configured/used only with the phone app, so never using the phone app is not a good option currently. With regard to putting the roombas on a separate vlan, and modifying firewall rules so the node server can talk to them, maybe this is a possible workaround for me, BUT, it will cost a lot of time, of that I am sure. I have a pfSense router , which is highly configurable, but also quite complex, so it also always costs me a lot of time to change anything. (I have bi-directional OpenVPN running between my primary home and a vacation home, with different subnets at each location, and it took many weeks of work to get that configured and working properly.) Roomba_5-2-2022_94545_AM.zip

Paul, I did some more testing with my i7+ this morning and roomba node server 2.0.6 . With no roombas running, I opened the AC on IoP. It reported Running==off and State==Charging for all three vacuums, which is correct and as expected. I started my i7+ from the Roomba app on my phone. There was no change in the AC. I waited about 5 minutes, and the AC reporting had still not updated. I tried doing a query from the AC. After another 5 minutes the AC had still not shown any updates. Log attached. You can see the startup of the i7+ (which I did from the Roomba phone app) being reported by searching on 08:54:29,891 in the log file, and subsequent entries show that the roomba continues to make updates about its progress to the node server. So not clear why the AC is not updating, is there something about the fact that the roomba was started from the phone app that is related to why the AC is not updating? Roomba_4-30-2022_90456_AM.zip

I updated, and the symbol is now the same as the other two. Thanks!

I restarted the Node server, it updated to 2.0.5, and now the i7+ shows the same list of attributes in the AC as the 980. One little anomaly I noticed, the graphic symbol in the AC next to the i7+ (hRoomba1stFloor) is now a light bulb, as opposed to whatever you call the symbol next to the other two roombas:

I installed 2.0.4 and restarted the roomba node server. The node server status in the pg3 dashboard shows "disconnected." I tried rebooting polyglot, I tried rebooting IoP, nothing helped. I notice in the roomba node server page, it states the following "If you need to re-discover devices, use the "Discover" button in the UI to start the discovery process. This will clear any exising devices and start from an empty list." I'm not seeing a discovery button in either the PG3 gui or the AC gui? Roomba_4-26-2022_45539_PM.zip

I set debug mode and restarted the node server. Based on the values printed out in the log file, when the node server starts up and prints out the saved capabilities ( INFO roomba-poly:handleRobotData: Loading saved robots), interestingly, all three roombas have the exact same list, and exact same values which I have summarized below: 5ghz 1 area 1 binFullDetect 2 bleDevLoc 1 dockComm 1 eco 1 edge 0 hm 0 lang 2 langOta 0 log 2 maps 3 mc 1 multiPass 2 oMode 10 ota 2 pmaps 5 pp 0 prov 3 sched 2 svcConf 1 team 1 tileScan 1 tLine 2 wDevLoc 2 Then the node server apparently queries the vacuums, and some capabilities are now reported to be different (and have different names:) 2022-04-26 09:47:22,258 Thread-1 udi_interface DEBUG roomba-poly:addNodes: Getting capabilities from hRoomba2ndFloor 2022-04-26 09:47:22,259 Thread-1 udi_interface DEBUG roomba-poly:addNodes: Capabilities: Position: True, CarpetBoost: False, BinFullDetection: True 2022-04-26 09:47:27,910 Thread-1 udi_interface DEBUG roomba-poly:addNodes: Getting capabilities from hRoomba1stFloor 2022-04-26 09:47:27,911 Thread-1 udi_interface DEBUG roomba-poly:addNodes: Capabilities: Position: False, CarpetBoost: False, BinFullDetection: False 2022-04-26 09:47:37,283 Thread-1 udi_interface DEBUG roomba-poly:addNodes: Getting capabilities from hRoombaBsmnt 2022-04-26 09:47:37,284 Thread-1 udi_interface DEBUG roomba-poly:addNodes: Capabilities: Position: True, CarpetBoost: True, BinFullDetection: True I have attached the log file. Roomba_4-26-2022_94804_AM.zip

Bob, thank you. After thoroughly cleaning the pads on all three of my roombas and bases, and making sure the batteries were all charged up without question, I have done some testing and I now have consistent connectivity and response to commands from the AC. Also, whether the roomba is started from the phone app, or the AC, the status in the AC seems now to be tracking correctly. The only thing I notice that is a limitation is that the end of the node name for my i7+ roomba is "basic roomba", whereas my 960 node name ends in "series 900 roomba", and my 980 node name ends in "Roomba 980". So the i7+ is not having all its features recognized, for instance in the AC it does not have a "action on full bin", or "passes" variable. The lack of these features is not causing me any problems at present, just something to be aware of.

Murphy's law is enforcing itself on me in a big way today. I finally figured out that one of my vacuums was not getting sufficient connectivity with the charge pads on the base to obtain a proper battery charge. After I thoroughly cleaned the pads, and put the roomba back on the base, the roomba phone app is now reporting "battery charging, too low to start" for that roomba. I will have to wait until the battery charges up to do more testing, but for that one roomba I was definitely getting strange and inconsistent results due to the contacts being dirty and the battery being low, including what I now realize was connectivity problems with the wifi network. (Strange thing is that the clean light was turning on, and the vacuum seemed to behave as if it was rebooting when I forced a reboot, but it finally occurred to me to try cleaning the contacts - they were a little dirty. )

I tried sending a start command from the AC today, and that did not work (it was working when I tried it last week). I tried restarting the roomba node server, and now it appears stuck at the "initializing connection" to one of the roombas. There are error messages such as this in the log: 2022-04-25 15:25:00,831 Thread-1 udi_interface ERROR roomba:async_connect: Connection Error: timed out 2022-04-25 15:25:01,837 Thread-1 udi_interface ERROR roomba:async_connect: Attempting retry Connection# 0 One thing that I noticed last week when the roomba node server did appear to be communicating with my i7+ is that it labeled its node as something like a "basic" roomba, which does not seem correct. This seems as broken as it was when I last tried to get the roombas working a year or more ago. Not complaining, just stating that with my three roombas (960, 980, i7+) it continues to not work for me. I am wondering if there is a fundamental problem with trying to control the roombas both from the AC and from the roomba phone app? - this is just brainstorming, not clear if this is an issue or not.

When a vacuum is started from the Roomba app on my phone (in this case it was a scheduled start), in the ISY AC, the reported values are not updating (Running shows "Off", State shows "Charging", etc.) even though in the PG3 roomba node server log file I see updates happening consistent with the fact that the roomba is cleaning. Even after 10 minutes had gone by, the AC still did not report any changes. I tried a Query, and that had no effect.

Today the vacuums all started up due to scheduled starts coming from the roomba server (not from the ISY). In the ISY AC, the reported values are not updating (Running shows "Off", State shows "Charging", etc.) even though in the PG3 roomba node server log file I see updates happening from all three vacuums consistent with the fact that they are all currently cleaning. In the AC, I tried a Query, and that had no effect.

I installed 2.0.3 (on PG3 3.0.59), and was prompted to press the home button on my three roombas in turn, after which a message displayed about initializing connection to each of the three roombas in turn. There are now three nodes defined in the Roomba node server, and they are present in the IoP AC (5.4.3) as well. The displayed values in the AC appear correct. I did some testing of the start, stop, and dock commands from the AC, and things seem to be working correctly.

@bpwwer , any update on Roomba? I see that there is a 2.0.6 version in the non-production PG3 store, would it help if I tried this? Note: The roomba github link in the PG3 Node server store is broken.

I figured out what the problem was. I had mistakenly specified the wrong value for hue_port (I had mistakenly set it to the same value as isy_port). Everything is working correctly now.

That fixed it, cameras are now present in the AC, thanks!

I'm posting this here in the PG2 BlueIris topic, because there is no BlueIris topic for PG3. I have installed Blue Iris under PG3 3.0.59. While the Blue Iris Node server is present in the AC, the cameras are not present. (I am running IoP 5.4.3) I am able to successfully change the blue iris profile, so I know the node server is communicating with the Blue Iris server. I've attached the log file package to this post. BlueIris_4-20-2022_94453_AM.zip

I have installed the Hue Emulator on PG3 3.0.59 . The spoken table is not filling in, and ISY Connected field in the AC of IoP is "False". Looking in the log file I see it is saying isy_host and isy_password is not defined, but they are in fact defined. I have attached the log file package to this post. HueEmulator_4-20-2022_90830_AM.zip

@JimboAutomates, I updated PG3 to 3.0.45 and elk Node server to 3.1.4, and the CO alarm notification is now working correctly. I see the violated zone showing that it was violated in the admin console, and the area Alarm Status showed "Carbon Monoxide Alarm". Thanks for the Node server update!