residualimages

I realize that I still, after years of plugging away on my own and lurking in the forums, have some gaps in my understanding. As far as Notifications and Variable Substitution: Recently I just learned for the first time about ${sys.program.#.name} and feel silly for not knowing that one (though it's mentioned here and there, including in Jimbo's Notification NS screenshots, it doesn't seem listed out in the actual Wiki). So maybe my long-standing complaint about UOM values not being always reliable or passed through in Notifications is simply a case of me not understanding .UOM.id or some other extension / syntax? Pain point: My Z-Wave locks (August Pro, 3rd gen) have an ALARM node that shows in Admin Console the last received state change's source (Manually unlocked, RF locked, Keypad unlocked, Auto-lock, Jammed, etc). (yes, I took the time to nn my node # in the screenshot above) I can even use those values in programs as a condition for my IFs: = But I have never found a variation of any substitution that ever returns anything other than the numeric value of the state (for 'Manual unlock', it'd be '2', as an example above and below) -- I'd like it to return the UOM type 25 string, instead. ${sys.node.ZY0nn_306} = "" ${sys.node.ZY0nn_306.ALARM} = 2 ${sys.node.ZY0nn_306.ALARM.RAW} = 2 ${sys.node.ZY0nn_306.ALARM.ST} = "" ${sys.node.ZY0nn_306.ALARMSTATE} = "ALARMSTATE" ${sys.node.ZY0nn_306.ALARMSTATE.ST} = "ALARMSTATE.ST" ${sys.node.ZY0nn_306.UOM} = "" ${sys.node.ZY0nn_306.ALARM.UOM} = "" ${sys.node.ZY0nn_306.ALARM.ST.RAW} = "" ${sys.node.ZY0nn_306.ALARM.ST.UOM} = "" Maybe this is more of a Product Request, if it's not something I'm overlooking? I can see the benefit of both nodes values and variables being able to be "typecast" into a UOM of choice as specified in a customized Notification. Edit: here are the node details, if it helps:

Ah, thank you. Overlooked that one. 🏆

I have a number of Notification Customizations that I want to make with the same content, except for a single dynamic element I'd like to include denoting which program triggered the Notify action. That is to say, instead of having 64x2 Notification Customizations, I'd rather have 1x2 , and have something equivalent to ${sys.node.#.name} in the Notification Customization which returned the name of which of the 64x2 programs that called the Notify action. Alternatively, I could see where a big 'or' list of variables <boolean> value in the "If" statement of a program could benefit from any Notify actions being able to distinguish which variable(s) values were logically true for the If statement that triggered the program to run the "Then" branch (somewhat like #, but for variables, rather than devices, in the "If" logic). Historically, I have used virtual devices (fake X10 or NS-defined virtual devices) to sort of achieve this in a roundabout way. A set of twelve programs is triggered based on various criteria to set one of twelve virtual devices to ON, wait 5 seconds, then turn its virtual device to OFF. Meanwhile, a single OR-based notification program listens for any of the twelve virtual devices to turn ON, and then sends a single Notification Customization which leverages ${sys.node.#.name} to say which of the twelve conditions were true. That sounds very painful to do for a new usage case where I have 64 things which can be one of two states (hence the 64x2 nomenclature above). Looking for alternatives, or a discussion of how others would approach this.

Thank you, @bpwwer! I will find courage to verify this weekend, but I trust you.

I have been working with some logic updates today (and offloading a couple things to a local computer that has a few more features than the corresponding Node Server). I am now at the place where I want to disable the Node Server (which has been fine, and is embedded as a component in many programs and notifications), and see if the local computer --> Polisy REST updates is stable enough to fully commit to that method. If not, I want to be able to quickly revert to the Node Server. Sure, I have Stopped the Node Server, but I want to make sure that even if I reboot Polisy or PG3, that the Node Server does not automatically start. I cannot remember for certain, but I'm 98% sure that all Node Servers start upon Polisy / PG3 boot up, even if they were Stopped as last known state. I don't want to fully Delete / remove the NS yet, in case I care, now or in the future, to return to using the NS, and want the programs and notifications to just be able to resume upon enabling. Am I remembering incorrectly, and in fact Stopped NS do not start automatically upon Polisy / PG3 boot? Or if that is correct, is there a method to disable a NS from starting?

@Michel Kohanim - Yes, I saw you mention that. I don't want a cloud-based API; from what I can tell, Vue doesn't have an official API but they say, cool, look at these projects people have made in the community (I'd consider the Vue NS in that same boat). From what code surfing I did, the reverse-engineered API all those projects are using is cloud-based authentication (and data). That's why I was hoping the ZMatter Polisy / eISY would directly bridge to Smart Meters as a HAN with its Zigbee radio, and keep all the data local.

Is this expected to lead to, eventually, HAN availability directly for those of us with the Zigbee (ZMatter) radios? As in, currently I use a Rainforest Eagle with Oncor (in Texas) via Zigbee HAN / Smart Meter provisioning, and have a local network IP "cloud provider" configured for the Eagle that integrates with Polisy variables (via the very old PowerEYE). Since the legacy ISY994xx ZSes were "Oncor certified", I am now considering that once the Zigbee side and Open ADR side get fully activated, then maybe my Polisy can replace the aging Rainforest Eagle...?? Edit: As I did even more forum searching to see if I had overlooked the answer, I do see some older threads where @Michel Kohanim mentions a bit of the differences between a HAN (Zigbee or otherwise) and the OpenADR aspects. If there is an opportunity to work with UD and Oncor (there's a great HAN engineer they have whom I talked with in May 2022) to explore options, count me in.

So, after *another* upgrade packages and manual reboot on IoX and another reboot on PG3, now everything seems to be populating correctly as far as NS Store and Purchases.

After IoX upgrade to 5.6.2 -- IoX seems to be working fine. PG3 seems to be working fine as far as NS interaction with IoX and devices. However: Not able to load Production nor Non-Production NS Store. Upon clicking Node Server Store, no dropdown is defaulted. Text at the top stuck at "Getting installable Node Server list from Polyglot Store. Standby....". Title says "PG3 Node Server Store ; Current Node Servers: 0" Using the dropdown to select either Production or Non-Production, green progress window bottom right loads, but the text at the top stuck at "Getting installable Node Server list from Polyglot Store. Standby....". Once a dropdown is selected and Refresh is clicked, empty table loads (just column headers visible) and the "Getting installable Node Server list from Polyglot Store. Standby...." text disappears. Not able to load any purchases from Purchases tab. Upon clicking Purchases tab, green progress window bottom right loads, but the text at the top stuck at "Getting list of purchases from UDI Portal. Standby....". Have rebooted IoX 2x and PG3 3x since 5.6.2 IoX upgrade. PG3 Version 3.1.21 Status: Connected Frontend Version: 3.1.21 IoX Version: 5.6.2 Connected PG3 log: 6/12/2023, 19:52:50 [pg3] warn: MQTTS: keepaliveTimeout: pg3frontend_xJKC0 6/12/2023, 19:52:50 [pg3] error: MQTTS: clientError: pg3frontend_xJKC0 keep alive timeout 6/12/2023, 19:52:50 [pg3] info: MQTTS: Client Disconnected: pg3frontend_xJKC0 6/12/2023, 19:52:55 [pg3] info: MQTTS: Client Connected: pg3frontend_xJKC0 6/12/2023, 19:52:56 [pg3] info: Requesting Portal authentication from frontend UI after 1 seconds 6/12/2023, 19:53:00 [pg3] info: Refreshing node server store data 6/12/2023, 19:53:01 [pg3] info: Checking for changes in Airscape 6/12/2023, 19:53:01 [pg3] info: Checking for changes in HusqvarnaMower 6/12/2023, 19:53:01 [pg3] info: Checking for changes in Timedata 6/12/2023, 19:53:01 [pg3] info: Checking for changes in YoLink 6/12/2023, 19:53:01 [pg3] info: Checking for changes in Sun 6/12/2023, 19:53:01 [pg3] info: Checking for changes in PurpleAir 6/12/2023, 19:53:01 [pg3] info: Checking for changes in UnifiProtect 6/12/2023, 19:53:01 [pg3] info: Checking for changes in WLED 6/12/2023, 19:53:01 [pg3] info: Checking for changes in AERISWeather 6/12/2023, 19:53:01 [pg3] info: Checking for changes in RYSE-shades 6/12/2023, 19:53:01 [pg3] info: Checking for changes in Flair 6/12/2023, 19:53:01 [pg3] info: Checking for changes in Airthings-C 6/12/2023, 19:53:01 [pg3] info: Checking for changes in August 6/12/2023, 19:53:01 [pg3] info: Checking for changes in HarmonyHub 6/12/2023, 19:53:01 [pg3] info: Checking for changes in Roku 6/12/2023, 19:53:01 [pg3] info: Checking for changes in MiLight 6/12/2023, 19:53:01 [pg3] info: Checking for changes in Sensibo 6/12/2023, 19:53:01 [pg3] info: Checking for changes in AVRemote 6/12/2023, 19:53:01 [pg3] info: Checking for changes in WeatherBit 6/12/2023, 19:53:01 [pg3] info: Checking for changes in Virtual 6/12/2023, 19:53:01 [pg3] info: Checking for changes in NanoLeaf 6/12/2023, 19:53:01 [pg3] info: Checking for changes in NOAA 6/12/2023, 19:53:01 [pg3] info: Checking for changes in OnkyoAVR 6/12/2023, 19:53:01 [pg3] info: Checking for changes in LiFX 6/12/2023, 19:53:01 [pg3] info: Checking for changes in VirtualButtons 6/12/2023, 19:53:01 [pg3] info: Checking for changes in ST-Inventory 6/12/2023, 19:53:01 [pg3] info: Checking for changes in ATest 6/12/2023, 19:53:01 [pg3] info: Checking for changes in eWeLink 6/12/2023, 19:53:01 [pg3] info: Checking for changes in AMINEM 6/12/2023, 19:53:01 [pg3] info: Checking for changes in Roomba 6/12/2023, 19:53:01 [pg3] info: Checking for changes in WeatherLink 6/12/2023, 19:53:01 [pg3] info: Checking for changes in Russound 6/12/2023, 19:53:01 [pg3] info: Checking for changes in TeslaPW 6/12/2023, 19:53:01 [pg3] info: Checking for changes in Rachio 6/12/2023, 19:53:01 [pg3] info: Checking for changes in ST-Nuheat 6/12/2023, 19:53:01 [pg3] info: Checking for changes in Hue 6/12/2023, 19:53:01 [pg3] info: Checking for changes in UnifiPresence 6/12/2023, 19:53:01 [pg3] info: Checking for changes in Holidays 6/12/2023, 19:53:01 [pg3] info: Checking for changes in Sonos 6/12/2023, 19:53:01 [pg3] info: Checking for changes in iAquaLink 6/12/2023, 19:53:01 [pg3] info: Checking for changes in Climacell 6/12/2023, 19:53:01 [pg3] info: Checking for changes in ST-Sonos 6/12/2023, 19:53:01 [pg3] info: Checking for changes in Notification 6/12/2023, 19:53:01 [pg3] info: Checking for changes in WirelessTag 6/12/2023, 19:53:01 [pg3] info: Checking for changes in Onkyo 6/12/2023, 19:53:01 [pg3] info: Checking for changes in Volumio 6/12/2023, 19:53:01 [pg3] info: Checking for changes in WeatherPoly 6/12/2023, 19:53:01 [pg3] info: Checking for changes in EnvisaLink-HW 6/12/2023, 19:53:01 [pg3] info: Checking for changes in Bond 6/12/2023, 19:53:01 [pg3] info: Checking for changes in BalboaSPA 6/12/2023, 19:53:01 [pg3] info: Checking for changes in HolidaysGoogle 6/12/2023, 19:53:01 [pg3] info: Checking for changes in OpenSprinkler 6/12/2023, 19:53:01 [pg3] info: Checking for changes in MessanaRadiant 6/12/2023, 19:53:01 [pg3] info: Checking for changes in DavisWeather 6/12/2023, 19:53:01 [pg3] info: Checking for changes in Twinkly 6/12/2023, 19:53:01 [pg3] info: Checking for changes in IFTTT-Webhooks 6/12/2023, 19:53:01 [pg3] info: Checking for changes in Wemo 6/12/2023, 19:53:01 [pg3] info: Checking for changes in WeatherFlow 6/12/2023, 19:53:01 [pg3] info: Checking for changes in Ping 6/12/2023, 19:53:01 [pg3] info: Checking for changes in eISYIR 6/12/2023, 19:53:01 [pg3] info: Checking for changes in TeslaEV 6/12/2023, 19:53:01 [pg3] info: Checking for changes in BASIRRIGATION 6/12/2023, 19:53:01 [pg3] info: Checking for changes in Backup 6/12/2023, 19:53:01 [pg3] info: Checking for changes in DysonPureCool 6/12/2023, 19:53:01 [pg3] info: Checking for changes in AVServer 6/12/2023, 19:53:01 [pg3] info: Checking for changes in EnvisaLink-DSC 6/12/2023, 19:53:01 [pg3] info: Checking for changes in Govee 6/12/2023, 19:53:01 [pg3] info: Checking for changes in OpenWeatherMap 6/12/2023, 19:53:01 [pg3] info: Checking for changes in BlueIris 6/12/2023, 19:53:01 [pg3] info: Checking for changes in MagicHome 6/12/2023, 19:53:01 [pg3] info: Checking for changes in RainMachine 6/12/2023, 19:53:01 [pg3] info: Checking for changes in MQTT 6/12/2023, 19:53:01 [pg3] info: Checking for changes in BASPOOL 6/12/2023, 19:53:01 [pg3] info: Checking for changes in Acurite 6/12/2023, 19:53:01 [pg3] info: Checking for changes in MyQ 6/12/2023, 19:53:01 [pg3] info: Checking for changes in VenstarCT 6/12/2023, 19:53:01 [pg3] info: Checking for changes in iTach-IR 6/12/2023, 19:53:01 [pg3] info: Checking for changes in Plex-WebHook 6/12/2023, 19:53:01 [pg3] info: Checking for changes in BASGARAGE 6/12/2023, 19:53:01 [pg3] info: Checking for changes in FlumeWater 6/12/2023, 19:53:01 [pg3] info: Checking for changes in VUE 6/12/2023, 19:53:01 [pg3] info: Checking for changes in BASPI6U6R 6/12/2023, 19:53:02 [pg3] info: Checking for changes in Caseta 6/12/2023, 19:53:02 [pg3] info: Checking for changes in ShellyRGBW2 6/12/2023, 19:53:02 [pg3] info: Checking for changes in ST-EcoWitt 6/12/2023, 19:53:02 [pg3] info: Checking for changes in Blink 6/12/2023, 19:53:02 [pg3] info: Checking for changes in Kasa 6/12/2023, 19:53:02 [pg3] info: Checking for changes in Kaiterra 6/12/2023, 19:53:02 [pg3] info: Checking for changes in Intesis 6/12/2023, 19:53:02 [pg3] info: Checking for changes in ELK 6/12/2023, 19:53:02 [pg3] info: Checking for changes in Sense 6/12/2023, 19:53:02 [pg3] info: Checking for changes in Somfy 6/12/2023, 19:53:02 [pg3] info: Checking for changes in Ring 6/12/2023, 19:53:02 [pg3] info: Checking for changes in Netatmo-WS 6/12/2023, 19:53:02 [pg3] info: Checking for changes in Ecobee 6/12/2023, 19:53:02 [pg3] info: Checking for changes in BASAO 6/12/2023, 19:53:02 [pg3] info: Checking for changes in Wake-On-Lan 6/12/2023, 19:53:02 [pg3] info: Checking for changes in LinkTap 6/12/2023, 19:53:02 [pg3] info: Checking for changes in Push 6/12/2023, 19:53:02 [pg3] info: Checking for changes in Camect 6/12/2023, 19:53:02 [pg3] info: Checking for changes in SolarEdge 6/12/2023, 19:53:02 [pg3] info: Checking for changes in Meteobridge 6/12/2023, 19:53:02 [pg3] info: Checking for changes in TotalConnect 6/12/2023, 19:53:02 [pg3] info: Checking for changes in MySmartBlinds 6/12/2023, 19:53:02 [pg3] info: Checking for changes in HueEmulator 6/12/2023, 19:53:02 [pg3] info: Checking for changes in Eagle-200 6/12/2023, 19:53:02 [pg3] info: Checking for changes in AmbientWeather 6/12/2023, 19:53:02 [pg3] info: Checking for changes in HoneywellHome 6/12/2023, 19:53:02 [pg3] info: Checking for changes in Noyito-Relay 6/12/2023, 19:53:02 [pg3] info: Checking for changes in DSDTech-Relay 6/12/2023, 19:53:03 [pg3] info: Checking for changes in DSC-IT100 6/12/2023, 19:53:03 [pg3] info: Checking for changes in Roku 6/12/2023, 19:53:03 [pg3] info: Checking for changes in PythonTemplate 6/12/2023, 19:53:03 [pg3] info: Checking for changes in Example-1 6/12/2023, 19:53:03 [pg3] info: Checking for changes in AVRemote 6/12/2023, 19:53:03 [pg3] info: Checking for changes in ATest 6/12/2023, 19:53:03 [pg3] info: Checking for changes in Roomba 6/12/2023, 19:53:03 [pg3] info: Checking for changes in TestTeslaEV 6/12/2023, 19:53:03 [pg3] info: Checking for changes in Example-2 6/12/2023, 19:53:03 [pg3] info: Checking for changes in Notification 6/12/2023, 19:53:03 [pg3] info: Checking for changes in Example-4 6/12/2023, 19:53:03 [pg3] info: Checking for changes in OpenSprinkler 6/12/2023, 19:53:03 [pg3] info: Checking for changes in Example-3 6/12/2023, 19:53:03 [pg3] info: Checking for changes in Hubitat 6/12/2023, 19:53:03 [pg3] info: Checking for changes in eISYIR 6/12/2023, 19:53:03 [pg3] info: Checking for changes in VueTest 6/12/2023, 19:53:03 [pg3] info: Checking for changes in MagicHome 6/12/2023, 19:53:03 [pg3] info: Checking for changes in solaredge_poly 6/12/2023, 19:53:03 [pg3] info: Checking for changes in iTach-IR 6/12/2023, 19:53:03 [pg3] info: Checking for changes in Ring-Beta 6/12/2023, 19:53:03 [pg3] info: Checking for changes in Kasa 6/12/2023, 19:53:03 [pg3] info: Checking for changes in ELK 6/12/2023, 19:53:03 [pg3] info: Checking for changes in Ring 6/12/2023, 19:53:03 [pg3] info: Checking for changes in Ecobee 6/12/2023, 19:53:03 [pg3] info: Checking for changes in Rheem_Tankless 6/12/2023, 19:53:03 [pg3] info: Checking for changes in TeslaEV_BETA ==================================================================== 6/12/2023, 20:00:05 [pg3] info: MQTTS: Client Connected: pg3frontend_cAQ4s 6/12/2023, 20:00:06 [pg3] info: Requesting Portal authentication from frontend UI after 1 seconds 6/12/2023, 20:00:17 [pg3] info: MQTTS: Client Disconnected: pg3frontend_cAQ4s 6/12/2023, 20:00:22 [pg3] info: Successful login by admin 6/12/2023, 20:00:22 [pg3] info: MQTTS: Client Connected: pg3frontend_41Ojr 6/12/2023, 20:00:23 [pg3] info: Requesting Portal authentication from frontend UI after 1 seconds 6/12/2023, 20:00:31 [pg3] error: Failed to get transaction report 6/12/2023, 20:00:31 [pg3] error: Error: Request failed with status code 400 6/12/2023, 20:00:31 [pg3] error: transactionReport: TypeError: Cannot read properties of undefined (reading 'data')

Great news! It has a little curve in the beginning for each of these things, and (aside a few edge cases like this one you needed), @Goose66's Nodeserver has a way of simplifying steps so most folks don't have to dig into the details. I'm happy you were curious and determined enough to get down into those extra details you needed, though. Some other people in the future may find this useful too. 🤓

You just take what you already made (you can even just copy the existing Network Resource you made, and rename it in ISY Admin Console) and leave everything as-is, just change "light":1 to "light":0. the "_m": 4 command in the body of an ISY Network Resource that is set to use the http PUT action turns the PUT action into a PATCH action -- so anywhere in the Bond API where it says to use a PATCH, you just translate that in your mind to "ISY Network Resource will require me to start my body with "_m": 4. The "body" part of any ISY Network Resource will only be the part that goes inside the {} when you call a cURL command. The -X PUT/PATCH/DELETE etc, as well as the leading -d, are not used in the ISY Network Resource, as ISY handles parts of that already natively.

Was because ISY Network Resources didn't give a PATCH action last I checked. So on the forums for the Bond devices, I had asked their developers for a way to send a PUT command but have it *act like* a PATCH command. As a favor to me, it seemed, they did provide the mechanism - but I believe it did NOT end up documented officially.

I have these in my Network Resources still, and they do appear to still work. The example here is to set the belief state of the light to "off" / 0; it could be modified to change the belief state to "on" / 1 with just a single modification of the integer in the Body:

At times, I get exhausted trying to help UD / NS authors / manufacturers troubleshoot their products interactively. I sometimes just want a break from it (to eat my cake) but still want my home to work as solidly as it did under my ISY+PG2 (and have my cake too). For me and my time, it's easier right now to restart a couple nodes when one or the other of them get out of whack. One of which has a known issue and the author already worked with me for weeks to identify an issue, and has a likely fix in the next version whenever it gets published. Since that NS is currently the first one that began exhibiting issues, I'd like to resolve that before bugging a different author about the separate NS, in case the first is part of the issue on PG3. However, from my perspective, it's completely within the realm of possibility and reasonable use cases to be able to programmatically start, stop, or restart Nodeservers. Something outside of a Nodeserver's control or knowledge, but within the capabilities of something else programmatically, could use the admittedly niche functionality to start, stop, or restart nodes. "Manufacturer knows best" isn't a look I'm super fond of encountering, but I know most of your post was an encouragement to address any perceived weaknesses of individual components to make it better for all. I'm just tired, right now, of everything being so fragile -- but don't have capacity this month to help address it. 😅

Would be nice if ISY gave us programmatic control / ability to reboot specific node servers (or if there was a REST or network-based method to do so). While continuing to struggle through various Polisy and PG3 updates, I have a couple Nodeservers that don't play nicely with the newer versions, and I need to reboot multiple times a day. Would be handy if I could do so via ISY programs (with or without monitoring checks to see if they need rebooted yet or not), or through specific IP calls.

Ah, I will say I rated the first one through the Store -> Details page, as I had not gone to the Purchases page and therefore had not seen the "Rate it!" column. Now I see I have no issues rating multiple NS from the Purchases page. You know, like the update post page says to do. 🤭

Is there a delay required between issuing ratings on a Node Server in the store? I rated one, but then seem unable to rate anything else so far.

I have the same ?visual only? issue, where PG3 shows 5.5.4, both with hard refresh and/or incognito mode. Admin Console shows as 5.5.5 successfully. Note: I have restarted PG3 a grand total of 3 times, if you count the initial Update Packages as #1. I have not restarted Polisy.

Hello. Here for the normal "Z-Wave Devices" check-in / report. After upgrade to 5.5.5, synchronize with interview and update took a little longer with the August Pro, but in the end I am still stuck with a single non-functional ZY node for August Pro locks (as with all the other "Z-Matter" board + Polisy firmwares), despite (re-)"Interview done". Creating a ticket now in case that's more appropriate than this forum. (Edit: Ticket # 20545)

As with the previous versions, on 5.5.4, the "Update with Interview" action does not change anything about the August Pro single ZY node (which itself is incomplete and non functional) with the "ZMatter" board. <nodeDefs> <nodedef nls="113" id="ZY007_1"> <sts> <st hide="T" editor="ZY_ERR" id="ERR"/> </sts> <cmds> <sends/> <accepts> <cmd id="QUERY"/> <cmd id="WDU"/> </accepts> </cmds> <links> <ctl/> <rsp> <link gid="ASSOC" linkdef="ASSOC"/> <link gid="ASSOC" linkdef="ASSOC_MC"/> <link gid="BASIC" linkdef="BASIC"/> <link gid="BASIC" linkdef="BASIC_MC"/> </rsp> </links> </nodedef> </nodeDefs>

I know you're speaking to the ZEN16/17 devices right now, but is there progress being made with Z-Wave locks? Is there anything I can do to help? The "Update with Interview" action does not change anything about the August single node (which itself is incomplete and non functional).

After update to 5.5.3 (from 5.5.2), Java clear / reset, updated Admin Console launch, then after a Z-wave exclude / include + Admin Console restart: Aeotec Gen 6 Repeater - now shows with the Z-wave nodes as expected - that's a win! Devices list: 6 Interview done August Smart Lock (Pro, 3rd generation) has a single node with no details in it. Still the case even after "Synchronize with Interview" Devices list: 7 Interview done X-Ray / Node definition of that device: <nodeDefs> <nodedef nls="113" id="ZY007_1"> <sts> <st hide="T" editor="ZY_ERR" id="ERR"/> </sts> <cmds> <sends/> <accepts> <cmd id="QUERY"/> <cmd id="WDU"/> </accepts> </cmds> <links> <ctl/> <rsp> <link gid="ASSOC" linkdef="ASSOC"/> <link gid="ASSOC" linkdef="ASSOC_MC"/> <link gid="BASIC" linkdef="BASIC"/> <link gid="BASIC" linkdef="BASIC_MC"/> </rsp> </links> </nodedef> </nodeDefs> Polisy with Z-Matter board (or whatever we're calling it) - no Zooz, no migration.

With some of the posts here, I felt hopeful about Z-Wave (via Z-Matter board or whatever we want to call it) on Polisy with 5.5.2 - but even after excluding and re-adding August Lock, there is still no node for it in Admin Console. Also applies to the Aeotec Z-Wave Repeater, for what it's worth. This is the same experience I have had since installing the board. Device count incremented (X-Ray shows Node 4 and 5 now instead of 2 and 3). Still available from /rest/zmatter/zwave/dh/node/4/cc/0 and /rest/zmatter/zwave/dh/node/5/cc/0. @Chris Jahn / @Michel Kohanim - is this still expected on a fresh Z-Wave (via Z-Matter board) setup (no migration, no Zooz ever set up)? If this is already known and being worked on, great, I will be patient. If this is unexpected, or if there are additional details I can provide to help y'all, please let me know.

This is similar to what I experienced; when I contacted UD through the ticket system, @Michel Kohanim gave me a link to the .img file to do an m2SATA flash via a USB <-> m2SATA converter I already had. Booted up like a charm after that.

I also had that thought as a likely explanation, but haven't found written proof of the hunch.