wmcneil

@Jimbo.Automates,the behavior needed is that each single press/release of a F* key causes a trigger that can be seen in a program. Currently, a program which has an If "Status 'area / keypad' Last Keypress is F*" will have the IF statement triggered when a keypad F* key is pressed/released only if the F* key is also NOT the last key that was pressed previously. On a somewhat related note, the only Last Function Key values are None and chime. This does not match the github documentation. I am running Elk Node server version 3.5.5

@Jimbo.Automates, I see that the issue associated with being able to trigger a program based on an elk keypad F* key being pressed has been closed (https://github.com/UniversalDevicesInc-PG3/udi-poly-ELK/issues/69). I see that a program has access to the value of Last Keypress via Condition / Status / ElkArea* / Keypad* / Last Keypress, but there is not a corresponding value defined for Condition / Control / ElkArea* / Keypad* / Last Keypress, so I still don't see a way to trigger a program?

I did Upgrade Packages in the AC again. The four beeps occurred within a couple minutes, but I waited 30 minutes anyway. I restarted the HoneywellHome node server in PG3. I am still getting the same errors listed above in the HoneywellHome log, and the HoneywellHome node server remains disconnected.

2022-08-23 09:05:25,442 MainThread udi_interface INFO polylogger:set_basic_config: set_basic_config: enable=True level=30 2022-08-23 09:05:27,990 MainThread udi_interface INFO __init__:<module>: UDI Python Interface for Polyglot version 3 3.0.47 Starting... 2022-08-23 09:05:28,097 MainThread udi_interface ERROR udi_interface:write: Traceback (most recent call last): 2022-08-23 09:05:28,098 MainThread udi_interface ERROR udi_interface:write: File "/var/polyglot/pg3/ns/00:0d:b9:53:c6:f0_1/./honeywellhome-poly.py", line 9, in <module> 2022-08-23 09:05:28,099 MainThread udi_interface ERROR udi_interface:write: from api_helper import ApiHelper 2022-08-23 09:05:28,099 MainThread udi_interface ERROR udi_interface:write: File "/var/polyglot/pg3/ns/00:0d:b9:53:c6:f0_1/api_helper.py", line 5, in <module> 2022-08-23 09:05:28,100 MainThread udi_interface ERROR udi_interface:write: from oauthlib.openid.connect.core.exceptions import InvalidTokenError 2022-08-23 09:05:28,101 MainThread udi_interface ERROR udi_interface:write: ModuleNotFoundError 2022-08-23 09:05:28,101 MainThread udi_interface ERROR udi_interface:write: : 2022-08-23 09:05:28,101 MainThread udi_interface ERROR udi_interface:write: No module named 'oauthlib'

I pressed the "Upgrade Packages" button in the AC, and waited until it appeared changes were complete. (I never got 4 beeps, but waited until only the far left LED on the polisy box was illuminated. ) I then restarted PG3, and many things seem to be now working correctly once again, including Elk Node server 3.4.9

I have opened a ticket. I'll post back here when I am able to make progress.

I updated to elk Node server 3.4.9 The elk Node server status in PG3 shows disconnected. When I try and access the log file using the PG3 GUI, I get a 404 not found error. I have tried to delete and recreate the elk Node server. I have rebooted my polisy box. I have tried all these things repeatedly. Now all of my node servers (not just elk) are showing disconnected status in the PG3 GUI. I am running PG3 3.0.63, and IoP 5.4.4 I have made sure there were no pending updates on my polisy box as shown below. Something is seriously wrong here but I don't know how to proceed: [admin@polisy ~]$ sudo pkg update Password: Updating FreeBSD-base repository catalogue... FreeBSD-base repository is up to date. Updating udi repository catalogue... udi repository is up to date. All repositories are up to date. [admin@polisy ~]$ sudo pkg upgrade Updating FreeBSD-base repository catalogue... FreeBSD-base repository is up to date. Updating udi repository catalogue... udi repository is up to date. All repositories are up to date. Checking for upgrades (0 candidates): 100% Processing candidates (0 candidates): 100% Checking integrity... done (0 conflicting) Your packages are up to date. [admin@polisy ~]$ sudo service udx status udx is running as pid 1148. [admin@polisy ~]$ sudo service isy status isy is running as pid 1216. [admin@polisy ~]$ sudo service pg3 status pg3 is running as pid 794.

I tried changing elk to armed stay using a elk keypad. The elk Node server Armed Status in AC remained Armed Away. I then changed elk to disarmed using a elk keypad. The elk Node server Armed Status in AC remained Armed Away. I then closed the AC, and re-opened it. The elk Node server Armed Status in AC was now Disarmed. (The elk Node server was up and running throughout the test)

My elk Node server is reporting my Elk Armed Status as "Armed Away" in the IoP AC (and IoP programs are seeing value "Armed Away"), when in fact the actual status is "disarmed". I have tried restarting elk Node server. Attached is a log file with debug+modules turned on. The restart of the elk Node server with debug+modules is at time 13:47:46 in debug.log elk Node server is 3.3.5, IoP is 5.4.4 ELK_7-11-2022_14824_PM.zip

Clicking the button seems to have no affect on anything.

I've uninstalled the Roomba app from both my phone and my wife's phone (so there is no Roomba phone app installed anywhere). I am still seeing the Roombas not stay connected to the node server. I can connect reliably to the Roombas from ISY only if I first reboot the PG3 node server.

After updating to v5.4.4, on the Configuration / System page, I pressed the "enable TPM" button, a dialog appeared which asked for a password, which I entered. The enabling of the TPM functionality seemed to work. The button label has now changed to "Disable TPM". With regard to to this "Important Note" in the v5.4.4 release announcement: "Please go to Admin Console | Configuration tab. If Upgrade BIOS is not grayed out, please click it so that your BIOS is upgraded to UEFI. You need UEFI TPM and security." My Upgrade BIOS button is not grayed out, but hovering over it does not cause it to be outlined in blue, which for the other buttons, indicates that an action is taken if the button is clicked. Does this confirm that I do have UEFI BIOS?

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