MWareman

I hope the upcoming year holds success and happiness for all.

Most devices are working fine it seems. I have one switch that I was previously triggering an action by triggering a program on 'Hail'. That's not working anymore though. I tried the 'Update' that @Chris Jahn suggested above - but it has not resolved it. Tailing the ZWAY.LOG file I see this when turning the device ON then 'OFF': [2022-12-31 21:44:09.820] [D] [...] RECEIVED: ( 01 0B 00 04 00 18 02 82 01 BC 00 00 D5 ) [2022-12-31 21:44:09.820] [D] [...] SENT ACK [2022-12-31 21:44:09.820] [D] [...] SETDATA devices.24.data.lastReceived = 0 (0x00000000) [2022-12-31 21:44:09.820] [W] [...] Report received, but command class is not supported by the device [2022-12-31 21:44:09.820] [E] [...] Error returned from _zway_cc_call_handler(zway, device->default_instance, controller->id, 0, data[4 + L], &data[5 + L]): Function class not supported by the hardware (-4) [2022-12-31 21:44:13.562] [D] [...] RECEIVED: ( 01 0B 00 04 00 18 02 82 01 B9 00 00 D0 ) [2022-12-31 21:44:13.562] [D] [...] SENT ACK [2022-12-31 21:44:13.562] [D] [...] SETDATA devices.24.data.lastReceived = 0 (0x00000000) [2022-12-31 21:44:13.562] [W] [...] Report received, but command class is not supported by the device [2022-12-31 21:44:13.562] [E] [...] Error returned from _zway_cc_call_handler(zway, device->default_instance, controller->id, 0, data[4 + L], &data[5 + L]): Function class not supported by the hardware (-4) I have tried adding the new "Scene Responder" node into a scene with the original "Dimmer Switch" node but the scene is not triggering. The scene also contains a LIFX group - and 'manually' turning the scene on or off correctly controls the scene. It's just the zwave switch is not. I must be missing something obvious - the 'Hail' previously was a hack I know but it was satisfactory. Would love to get this back. Not sure what "Function class not supported by the hardware" means in this context - a function the zmatter does not support?

I wondered where the 'Weather Sensor' came from. Makes sense... 😕

Well - I bit the bullet and did the migration. I verified I don't have rapidly reporting devices fgirst (due to the reported bug in this area). Appears to have worked well. Some comments: There really should be an event logged saying when processing is complete. Otherwise, it's just waiting until it stops logging. Far from ideal. Starting without the ZMatter installed - I got the the point where it told me to power off and install it - along with disconnecting the zooz dongle. It was not clear if I clicked 'OK' first then powered down - or powered down with the console open and the 'OK' prompt. After reboot - and after processing - I gained a lot of new zwave nodes. "Assoc Only", "Scene Responder", "Access Control Alarm", "Weather Sensor" and "Multilevel Sensor" nodes. I assume this is normal. However - all were put in the root folder instead of next to where the other nodes for the device are. Not a big deal - but something to be aware of. "Insteon Support" got turned off in the console. Not sure why. I turned it back on afterwards. Still having to go thru and ensure all my programs and scenes survuved the migration - so so far so good!

For me, it's all about connecting different systems without the need for active Internet connectivity. The more this can be enabled, the better. Yes - I know google Home, Alexa (and others) all depend on cloud for voice parsing. However, currently when you ask a light to change the Google Assistant cloud sends the command to the UDI cloud service - which sends the command down to Polisy/eisy. I would love for this to change (Google/Amazon device sends Matter command to Polisy/eisy directly). No more needing to configure devices one by one in my.isy.io. Setting up schedules in Home or Alexa should then not depend on cloud connectivity at all. Of course - this somewhat depends on Google/Amazon and Apple doing the right thing here as well... Beyond that - being able to 'natively' use any of the new class of devices coming out - not having to await or code a new poly for a new API etc etc..

I'm with you - extremely keen to get switched over and start messing with Matter. However - a migration is a must for me. I'll await the more detailed instructions..

Got an email about 5.5.1 being available (30 mins ago) - fixing the routing migration challenge. However, link goes to a forum post that does not exist anymore. Authored by @Chris Jahn I upgraded in the admin console - I now have 5.5.2 (but no forum announcement about this one either). The instructions say "Migrate to ZMatter Z-Wave" then "Do not unplug or install any Z-Wave boards / dongles until instructed to do so during migration". Currently, my Zooz dongle is connected - and I'm running 5.5.2. My zmatter board is disconnected (since zwave did not work at all with it connected before). So - do I install zmatter again and reboot prior to clicking 'Move to ZMatter"? Or - will the post button-push process prompt me to shut down and install the board? The instructions are not clear. Thank you! Michael.

Fantastic! Not being a chip firmware issue is huge! Sounds like it was a 'fun' detective job..

At the risk of 'me too' - this worked for me. After a couple of hours of no progress, no beeps and no automation I had to update the pkg package manually before using the admin console to update the rest.

Thank you! Fixed it for me as well...

Update appears to be failing. Spinning up many, (pages of them!). polyglot 2233 0.0 1.1 84736 44796 - I 23:24 0:11.20 python3 ./elk-poly.py (python3.9) root 2919 0.0 0.2 22308 9152 - I 23:26 0:00.02 pkg upgrade -y root 2921 0.0 0.2 22308 9152 - I 23:26 0:00.02 pkg upgrade -y root 2923 0.0 0.2 22308 9152 - I 23:26 0:00.03 pkg upgrade -y root 2925 0.0 0.2 22308 9152 - I 23:26 0:00.02 pkg upgrade -y root 2928 0.0 0.2 22308 9152 - I 23:26 0:00.03 pkg upgrade -y root 2930 0.0 0.2 22308 9152 - I 23:26 0:00.02 pkg upgrade -y root 2932 0.0 0.2 22308 9152 - I 23:26 0:00.02 pkg upgrade -y root 2982 0.0 0.2 22308 9152 - I 23:26 0:00.02 pkg upgrade -y root 2984 0.0 0.2 22308 9152 - I 23:26 0:00.02 pkg upgrade -y root 2986 0.0 0.2 22308 9152 - I 23:26 0:00.02 pkg upgrade -y root 2988 0.0 0.2 22308 9152 - I 23:26 0:00.02 pkg upgrade -y root 2990 0.0 0.2 22308 9152 - I 23:26 0:00.02 pkg upgrade -y root 3032 0.0 0.2 22308 9152 - I 23:26 0:00.03 pkg upgrade -y root 3054 0.0 0.2 22308 9152 - I 23:26 0:00.02 pkg upgrade -y root 3056 0.0 0.2 22308 9152 - I 23:26 0:00.02 pkg upgrade -y root 3058 0.0 0.2 22308 9152 - I 23:26 0:00.02 pkg upgrade -y root 3060 0.0 0.2 22308 9152 - I 23:26 0:00.03 pkg upgrade -y root 3062 0.0 0.2 22308 9152 - I 23:26 0:00.02 pkg upgrade -y root 3064 0.0 0.2 22308 9152 - I 23:26 0:00.02 pkg upgrade -y root 3066 0.0 0.2 22308 9152 - I 23:26 0:00.02 pkg upgrade -y root 3068 0.0 0.2 22308 9152 - I 23:26 0:00.02 pkg upgrade -y root 3070 0.0 0.2 22308 9152 - I 23:26 0:00.02 pkg upgrade -y root 3072 0.0 0.2 22308 9152 - I 23:26 0:00.02 pkg upgrade -y root 3074 0.0 0.2 22308 9152 - I 23:26 0:00.02 pkg upgrade -y root 3076 0.0 0.2 22308 9152 - I 23:26 0:00.02 pkg upgrade -y root 3078 0.0 0.2 22308 9152 - I 23:26 0:00.02 pkg upgrade -y root 3080 0.0 0.2 22308 9152 - I 23:26 0:00.03 pkg upgrade -y root 3082 0.0 0.2 22308 9152 - I 23:26 0:00.03 pkg upgrade -y root 3084 0.0 0.2 22308 9152 - I 23:26 0:00.02 pkg upgrade -y root 3086 0.0 0.2 22308 9152 - I 23:26 0:00.02 pkg upgrade -y root 3088 0.0 0.2 22308 9152 - I 23:26 0:00.03 pkg upgrade -y root 3090 0.0 0.2 22308 9152 - I 23:26 0:00.02 pkg upgrade -y root 3092 0.0 0.2 22308 9152 - I 23:26 0:00.02 pkg upgrade -y root 3094 0.0 0.2 22308 9152 - I 23:26 0:00.02 pkg upgrade -y root 3096 0.0 0.2 22308 9152 - I 23:26 0:00.02 pkg upgrade -y root 3098 0.0 0.2 22308 9152 - I 23:26 0:00.03 pkg upgrade -y root 3100 0.0 0.2 22308 9152 - I 23:26 0:00.02 pkg upgrade -y root 3103 0.0 0.2 22308 9152 - I 23:27 0:00.03 pkg upgrade -y root 3106 0.0 0.2 22308 9152 - I 23:27 0:00.03 pkg upgrade -y root 3109 0.0 0.2 22308 9152 - I 23:27 0:00.02 pkg upgrade -y root 3112 0.0 0.2 22308 9152 - I 23:27 0:00.02 pkg upgrade -y root 3115 0.0 0.2 22308 9152 - I 23:27 0:00.02 pkg upgrade -y root 3118 0.0 0.2 22308 9152 - I 23:27 0:00.02 pkg upgrade -y root 3120 0.0 0.2 22308 9152 - I 23:27 0:00.02 pkg upgrade -y root 3122 0.0 0.2 22308 9152 - I 23:27 0:00.02 pkg upgrade -y root 3124 0.0 0.2 22308 9152 - I 23:27 0:00.02 pkg upgrade -y root 3126 0.0 0.2 22308 9152 - I 23:27 0:00.02 pkg upgrade -y root 3128 0.0 0.2 22308 9152 - I 23:27 0:00.02 pkg upgrade -y root 3130 0.0 0.2 22308 9152 - I 23:27 0:00.02 pkg upgrade -y root 3132 0.0 0.2 22308 9152 - I 23:27 0:00.02 pkg upgrade -y root 3134 0.0 0.2 22308 9152 - I 23:27 0:00.02 pkg upgrade -y root 3136 0.0 0.2 22308 9152 - I 23:27 0:00.02 pkg upgrade -y root 3138 0.0 0.2 22308 9152 - I 23:27 0:00.02 pkg upgrade -y Finding the log - appears to not be able to update anything because pkg needs updating first - but it's not updating pkg first. (!) New version of pkg detected; it needs to be installed first. Checking integrity... done (0 conflicting) Your packages are up to date. Updating FreeBSD repository catalogue... FreeBSD repository is up to date. 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. New version of pkg detected; it needs to be installed first. Checking integrity... done (0 conflicting) Your packages are up to date. Updating FreeBSD repository catalogue... FreeBSD repository is up to date. 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. New version of pkg detected; it needs to be installed first. Checking integrity... done (0 conflicting) Your packages are up to date. Updating FreeBSD repository catalogue... FreeBSD repository is up to date. 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.

Thank you!

I believe Polisy is based on FreeBSD. As such, the recently revealed vulnerability in 'ping' may well affect it. Is this on the UDI teams radar to test for and mitigate? https://thehackernews.com/2022/12/critical-ping-vulnerability-allows.html Thank you!

Ticket opened. Thank you!

Assigning the location permission manually resolved the issue having it detect being on the wifi network. So, I think the main issue is the app does not appear to be properly asking for the permission if it does not have it.

Ahh, location permission. I checked the app, it was not assigned. Strange thing is I was never prompted to grant location permission. I clicked to add my home Wifi network and it discovered it without having location permission and without prompting for the permission so maybe there is something wrong with detecting when the permission has not been granted and prompting the user for it. I have granted the permission now and will test when I get home.

Hello, This thread highlighted the issue for me: There are two situations here. 1) When portal is down, but I'm on the local network to Polisy - I cannot connect 2) When Polisy is up and I am on the local network - UD Mobile is ignoring the local wifi and still connecting to and depending on the Portal. This manifests in settings as well. If I click 'Test Local Connection' then I get an error: "There is no local network associated or the Android Device is not on an associated local network...." ..except I am.... The SSID and network name were read from the device and associated with the Polisy. I have confirmed my local connection settings work. If I select "Only use Local Connection" it connects fine - but won't work when I leave the house (I had to do this last night when the portal was down) Possible to find out why local network detection is not working on Android? Thank you!

My UD Mobile app is not responding either - seems it is persisting in trying to connect to the portal. Likely needs some logic update I think.

Guess I should have looked at the other thread first.... please ignore this one.

Getting errors from Google home - and this when trying to logon:

I love that definition - but in this context it's "Trusted Platform Module" - https://en.wikipedia.org/wiki/Trusted_Platform_Module

I also just noticed - after the backup fails - control returns to the admin console. However, the .zip file is still locked open for write access. I cannot delete the invalid backup file until after I exit the admin console. Michael.

Just confirming - udx definitely running:

I have this error on 5.4.5 a few hours after restart - with udx running. Just tried again now - 2 days later - and still getting exactly the same errors. udx is most definitely running.

Seems my theory is incorrect.... oh well. Will have to wait and see what the UDI team determines after the holiday.