wmcneil

I am running ZMatter with 5.5.3 and have restored a migration backup that was created with Zooz zst10. My Aeotec Multisensor 6 does not appear to be recognizing the parameter decimal 64 value. This parameter is supposed to control whether temperature units are Celsius or Fahrenheit. Value 1 is supposed to be Celsius, value 2 is supposed to be Fahrenheit. Temperature is displaying as Celsius in the AC, regardless of whether I set this value to 1 or 2. I am able to confirm the write value is being accepted, because if I do a query after the write, it is returning the value I am writing. So it appears that the Multisensor 6 is accepting the parameter write, but it is not affecting the units displayed in the AC. Some additional info: I have successfully used parameter 64 to control the displayed units in the past when I was using zooz zst10. I have a different polisy in another location that is running 5.5.0 with Zooz zst10. This system also has a Multisensor 6, and it has been reporting in Fahrenheit for at least a couple years (When I first installed it I wrote parameter 64 to a 2). Today I tried changing parameter 64 to 1, and the reporting changed to Celsius. BUT, I have changed the value back to 2, and now the reporting will not change back to Fahrenheit. I have tried rebooting IoX to no avail. So now it is not clear where the problem(s) are. Edit: Now that some time has passed, my 5.5.0/zooz system is now reporting in Farenheit, so it is behaving as if there is a time lag between the parameter being written and the AC updating (I had previously tried many queries, and that had not caused a change, so strange behavior for sure.)...My 5.5.3/ZMatter system continues to report in celsius. I'll post back if this changes after more time passes.

I've been waiting for Michel or someone else at UD to respond and answer my question. I know they are busy with IoX 5.5.0 migration plans, but I am asking something that I think is something important that others would like clarification on, so In the interest of potentially helping others, I will comment with some further information while we wait for the official word. The Zooz ZST10 700 has never had a backup/restore capability provided by the Admin Console (AC). An AC backup/restore feature was present up to and including the 500 Zwave option, so this is a feature that was lost when moving to Polisy and the Zooz stick. There is Windows software that Silicon Labs provides called Simplicity Studio which has a backup and restore function for the Zooz. This is the method brians is referring to above. Simplicity Studio is a large software package that has a lot of functionality in addition to the backup and restore. It is neither lightweight nor simple to use, but with a little persistence it can be installed and learned. Once UD has the ZMatter migration software perfected, it will be possible to directly backup from Zooz and restore to ZMatter. My previously stated question was asking if there will also be a backup from Zooz and restore to Zooz available. My guess is that the answer is no. That being the case, if you want the protection of having a Zooz backup you have to use Simplicity Studio. The reason you would want a Zooz backup is to protect against either the Zooz stick failing before you attempt migration to ZMatter, or a worst case scenario of something going wrong with the migration process that corrupts the Zooz stick (before you unplug it for the final time). I had a Zooz stick fail after only 7 months, and from what I read elsewhere, I'm not the only one that has had an early life failure.

@brians , I understand that the current v5.5.0 release is not working as intended with ZMatter. I also understand that one of the things that is not currently working is migration from Zooz to ZMatter. I have read everything that anyone has posted with regard to ZMatter in the last several days, and my questions are still valid. I want to know what UD intends when things are working, and I want to know for certain. I have had to rebuild my Zwave network from scratch once in the past month, and I do not intend to have to do it again, so I want to know exactly how UD intends that backup is going to work. I will attempt to further clarify what I originally asked: @Michel KohanimDoes UD intend to provide a backup and restore capability for Zooz ZST10 700, independent of the migration path from Zooz to ZMatter? If YES, in what version of IoX is this capability planned to first be present? If NO, that implies that only a 1 way migration path from Zooz ZST10 700 to ZMatter will be supported, correct?

For IoX 5.4.5, does backup/restore include Zooz ZST10 700? (Please do not answer unless you are certain of your reply. "I think so", "I hope so", etc. are not useful. Ideally someone from UD can reply with 100% certainty.) This part of the "IoX Release v5.5.0 Is Now Available" directions implies that ZWave is included, but I want to be absolutely certain: When IoX restarts, all existing Z-Wave nodes from the old installation are removed Note: The only way to go back is to restore a backup that was made prior to moving to ZMatter Z-Wave+ OR Does the snippet above imply that ZWave backup/restore for Zooz ZST10 700 is present only starting with IoX 5.5.0, BUT will be available only prior to pressing the Move to ZMatter Z-Wave button?

Are you looking at the directions in the Polisy User Guide under "Migrating from 994 to Polisy" ? If so, the zwave backup utility that those directions refer to apply only to the 994.

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?