wmcneil

I initially tried to connect the wires with the ZMatter board plugged into the mPCIe connector, and I struggled with this as well. I ended up removing the board from the connector, attaching the wires, and then plugging the board back into the connector.

It turns out that I actually experienced the (quite unlikely) occurrence of my zooz zwave dongle going bad at the same time that I updated PG3. I opened a ticket and worked with the UD folks to confirm that is in fact what happened....As Michel has stated elsewhere, there is a backup functionality for the zooz dongle that is going to be present in ISY code that is going to be released very soon.

Michel made this post on 5/22 (post in "how to update zooz zst10 700 stick" thread 1. We are working on a combined Z-Wave/Matter board that gets installed inside + antennas coming out from the sides:- It will be field upgradable (so you won't need Studio etc.)- Z-Wave will have many diagnostics features + S2 2. We will have a utility that will backup your Zooz dongle:3. You can restore the Zooz backup into the new dongle4. For those who purchased Zooz from us, the total cost of the Zooz dongle will be discounted from the new dongle

Thanks for the update....There have been many, many soft and hard reboots done as myself and the UD folks have tried to debug the problem. No luck so far. Current theory is that the Zooz 700 is corrupted in some way.

I already have the ZMatter board on pre-order, meanwhile I will have to replace the Zooz 700, and potentially rebuild my zwave network.

@bpwwer, AC was reporting IoP version 5.4.4 before I did the update packages. The IoP AC is reporting "zwave dongle not responding" when the Z-Wave menu pulldown is selected. The UD folks spent several hours debugging my polisy box remotely today. The current best theory is that the Zoos 700 stick is corrupted somehow, and yes the symptoms started concurrent with my upgrade to PG3 3.1.12, so if the theory turns out to be correct, then this is a very unlikely (but real) coincidence. I tried updating the Zoos 700 firmware using the Simplicity Studios software on my windows laptop. It seemed to update correctly per what Simplicity Studios reported, but made no difference in the polisy box behavior. I am going to continue to work with the UD folks to debug further.

@asbril, did you ever get resolution of your problem? I am experiencing a complete loss of ZWAVE communication after having upgraded to PG3 3.1.12 . I have tried power several soft reboots, and a power cycle reboot of the polisy box to no avail.

I updated to PG3 3.1.12 using the "Upgrade Packages" button in IoP. After the install completed, and the polisy box rebooted, the node servers seem fine, but I can not communicate with any of my existing zwave devices. I have tried additional reboots of polisy and IoP to no avail. For instance, when I attempt to query a zwave light switch, I get a pop up window which states "Could not open config file to read" [./FILES/CONF/INSTENG.OPT] and "Could not open file" [./FILES/CONF/INSTENG.OPT] On the face of it, it makes no sense that updating PG3 would cause a loss of communication with all the zwave devices, but that is what happened. I have opened a ticket. I'll post back once the issue is resolved.

@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.