johnnyt

I customized some phrases for the 'Say' feature but phrases 0-9 show up blank in the program action. It does work with the phrase if I run the program but it's going to hard to debug later when I have a bunch of these. Also, while it looks like I could have up to 49 phrases, only 9 can be configured. I tried adding a 10th but it does not stay. Goes back to only 9 on PG3 UI page and selecting 10 in a program after adding text did not work. (I thought maybe it saved it and simply just didn't display it but no, it's not saved either.) Edit: running ST-Sonos 1.0.10 and PG3x 3.2.2 on Polisy with IoX 5.6.4

I have to ask, why hasn't that Node Server menu been deleted if if doesn't do anything anymore (except cause people who don't know better to waste a lot of their time). Are there still old node servers around that maybe need to be retired? So I deleted NS in both PG3x and AC, as indicated and confirmed they were gone. Installed NS again but in different slot to avoid any remnants, should there be some. This time I pressed "Discover", which I didn't do last time. Last time I only started the NS, which was stopped. If this was important may I suggest it be added to the Configuration Help section. Lots more stuff got installed this time and nodes were added to AC, although I did have to restart AC to see them properly. All looks good now. Thanks.

I migrated to PG3x early yesterday, which got me to 3.2.1, then I upgraded to 3.2.2. While I encountered snags along the way, everything appeared normal and working fine when I finished in the afternoon. I noticed this morning, though, that my PG3 logs had no entries after about 7:30 PM last night (14+ hours ago). As a troubleshooting step I rebooted because I can't simply restart PG3 anymore (why is that? - it would have much less impact to just restart PG3) The reboot fixed the issue, but I'm missing 14 hours of log data, some of which I could have used as I troubleshoot a problem I'm having with the installation of a new NS. Maybe it's a glitch left over from the migration that won't happen again but wanted to mention it in case it's not. I will check periodically over the next few days to see if this happens again.

Hi @bpwwer, am hoping you can help. Tried again 12 hours later but am not seeing any devices. Began by restarting AC to see if nodes appeared and it was just an AC GUI issue. I should see devices starting with address "n002_" where the arrows are but there's nothing. So I tried adding my "Kitchen" node following these steps: 1) Node Servers -> ST-Sonos -> Add Node -> Sonos Player using the data from the Node info in PG3 UI shown below Got: Tried doing "Discover" on PG3 node server page. No joy. Tried Node Server -> Configure... ST-Sonos (Network) using appropriate userid, pw, and IP address (changed my ISY MAC address for the screenshot only) Also tried with the following data: As a last step I restarted AC in case of AC GUI issue - but still nothing Have attached the log at debug level that I just downloaded this morning. Can't think of much more to try or provide but if there's anything, please let me know. ST-Sonos_8-19-2023_91133-AM.zip

I've installed the NS but don't see any devices in ISY. I tried going to NodeServer -> ST-Sonos -> Add All Nodes, restarted AC in case it's an AC GUI issue, but not seeing anything. I can see the nodes in NS "Nodes" in PG3x. What am I missing to be able to use this NS? edit: running PG3x 3.2.2, IoX 5.6.4, St-Sonos 1.0.10

Thanks. Good to know. Sorry if I missed it in the documentation or release notes. I tried navigating to the folder but after 'ns' folder, I get permission denied. My concern is that I may need to go back a day or more. It hasn't been a day since I migrated but, based on past experience, the log entries are from midnight the day you're asking for them, not before. Assuming this is the case for PG3x too, please consider allowing access to the needed subfolders. I find it so much easier to use WinSCP to navigate the file system and copy files to my Windows machine for troubleshooting and/or reporting problems, but right now when I try to navigate to one of the Node Server subdirectory, I get WinSCP doesn't do 'sudo' (unless I just don't know how to set it up to do that with each double click.) While I can find the logs using putty/CLI by doing "sudo ls -l /var/polyglot/pg3/ns/<longrandomnodeserverID/logs" plus root password (multiple times at first to find the subdirectory), then use same long path to 'cp' it somewhere I can access, it should be much easier to get at these log files, IMO. Especially for people who don't eat linux for breakfast. Just a suggestion. Thanks for considering it.

None of my Node Servers are displaying logs after migration to PG3x. I changed log level to Debug for all of them and there should be stuff there by now. There are no problems seeing PG3 log entries. Am at 3.2.2. If someone can point me to where the NS log files are, using SSH I can go look there to see if there's anything there. Edit: for the record, yes, I did do "Reinstall all Node Servers" after migration

It turned out to be a browser cache issue. First time I've ever had that as an issue. Maybe it's a thing with PG3x so I'll definitely look for that as a first step from now. Hopefully this helps someone else.

Why are my all my node servers connected to ISY? Is there a rogue instance of PG3 still running that I can't access anymore? How do I fix this? I did try a reboot but that didn't help.

Followed the instructions at: https://wiki.universal-devices.com/index.php?title=Polisy:User_Guide#Upgrading_to_PG3x Upgrading to PG3x Enable PG3x: https://polisy.local:8443/rest/pg3x.enable Reboot and wait for a beep + 1. Migrating node servers from PG3 to PG3x might take up to 2 minutes per node server. So, please be patient Once all node servers show connected, reboot again Been 30 minutes since last entry in udx log and it appears to have gone through all 9 of my NS but PG3x is not even running. How long is this supposed to take? udx log entries from shutdown on attached (now 35 mins since last entry) PG3xMigrationLogEntries.txt

I have 3 Airthings NS instances running (using different hubs/API tokens). At 19:28:59 Eastern time, one of the three reported this error: 2023-08-17 19:28:59,098 Thread-1076 udi_interface.interface ERROR interface:send: MQTT Publish Error: [SSL: BAD_LENGTH] bad length (_ssl.c:2488) Traceback (most recent call last): File "/var/polyglot/.local/lib/python3.9/site-packages/udi_interface/interface.py", line 632, in send self._mqttc.publish(topic, json.dumps(message), retain=False) File "/var/polyglot/.local/lib/python3.9/site-packages/paho/mqtt/client.py", line 1257, in publish rc = self._send_publish( File "/var/polyglot/.local/lib/python3.9/site-packages/paho/mqtt/client.py", line 2693, in _send_publish return self._packet_queue(PUBLISH, packet, mid, qos, info) File "/var/polyglot/.local/lib/python3.9/site-packages/paho/mqtt/client.py", line 3016, in _packet_queue return self.loop_write() File "/var/polyglot/.local/lib/python3.9/site-packages/paho/mqtt/client.py", line 1577, in loop_write rc = self._packet_write() File "/var/polyglot/.local/lib/python3.9/site-packages/paho/mqtt/client.py", line 2464, in _packet_write write_length = self._sock_send( File "/var/polyglot/.local/lib/python3.9/site-packages/paho/mqtt/client.py", line 649, in _sock_send return self._sock.send(buf) File "/usr/local/lib/python3.9/ssl.py", line 1174, in send return self._sslobj.write(data) ssl.SSLError: [SSL: BAD_LENGTH] bad length (_ssl.c:2488) 2023-08-17 19:28:59,099 MQTT udi_interface.interface INFO interface:_disconnect: MQTT Unexpected disconnection. Trying to reconnect in 10 seconds. rc: 7 The two other instances did not report this or any other any issues around that time. Am on PG3 3.1.21 and IoX 5.6.4 on Polisy.

I noticed some unhandled errors in log for this NS today. Note sure what's failing because I do see data in IoX. Question I have when I see these errors: is the data I'm seeing correct? I've turned log level to Debug so If more detail is needed, let me know. Edit: running NS version 1.0.12 on PG3 ver. 3.1.21, and IoP 5.6.2 2023-07-26 15:22:45 warn: POLY: Received stop message 2023-07-26 15:32:03 info: NS: Starting Node Server 2023-07-26 15:32:03 info: POLY: Interface starting 2023-07-26 15:32:03 info: POLY: Getting config from environment 2023-07-26 15:32:04 info: POLY: MQTT client connected 2023-07-26 15:32:04 info: NS: MQTT Connection started 2023-07-26 15:32:05 error: POLY: Config has logLevel: WARNING 2023-07-26 15:32:05 warn: POLY: Loglevel: warn 2023-07-26 15:34:42 error: POLY: getInv() Error: http://192.168.100.249:8080/rest/programs?subfolders=true 2023-07-26 15:34:56 error: NS: Parsing Error: TypeError: Cannot read properties of undefined (reading 'toString') at exports.Parser.Parser.parseString (/var/polyglot/pg3/ns/<myISYMACaddr>_7/node_modules/xml2js/lib/parser.js:312:19) at Parser.parseString (/var/polyglot/pg3/ns/<myISYMACaddr>_7/node_modules/xml2js/lib/parser.js:5:59) at Controller.processPrograms (/var/polyglot/pg3/ns/<myISYMACaddr>_7/Nodes/ControllerNode.js:188:18) at Controller.onDiscover (/var/polyglot/pg3/ns/<myISYMACaddr>_7/Nodes/ControllerNode.js:82:12) 2023-07-26 15:34:58 error: NS: Parsing Error: TypeError: Cannot read properties of undefined (reading 'program') at /var/polyglot/pg3/ns/<myISYMACaddr>_7/Nodes/ControllerNode.js:192:35 at Parser.<anonymous> (/var/polyglot/pg3/ns/<myISYMACaddr>_7/node_modules/xml2js/lib/parser.js:304:18) at Parser.emit (node:events:525:35) at SAXParser.onclosetag (/var/polyglot/pg3/ns/<myISYMACaddr>_7/node_modules/xml2js/lib/parser.js:262:26) at emit (/var/polyglot/pg3/ns/<myISYMACaddr>_7/node_modules/sax/lib/sax.js:624:35) at emitNode (/var/polyglot/pg3/ns/<myISYMACaddr>_7/node_modules/sax/lib/sax.js:629:5) at closeTag (/var/polyglot/pg3/ns/<myISYMACaddr>_7/node_modules/sax/lib/sax.js:889:7) at SAXParser.write (/var/polyglot/pg3/ns/<myISYMACaddr>_7/node_modules/sax/lib/sax.js:1436:13) at exports.Parser.Parser.parseString (/var/polyglot/pg3/ns/<myISYMACaddr>_7/node_modules/xml2js/lib/parser.js:323:31) at Parser.parseString (/var/polyglot/pg3/ns/<myISYMACaddr>_7/node_modules/xml2js/lib/parser.js:5:59) 2023-07-26 15:52:03 error: POLY: getInv() Error: http://192.168.100.249:8080/rest/programs?subfolders=true 2023-07-26 15:52:16 error: NS: Parsing Error: TypeError: Cannot read properties of undefined (reading 'toString') at exports.Parser.Parser.parseString (/var/polyglot/pg3/ns/<myISYMACaddr>_7/node_modules/xml2js/lib/parser.js:312:19) at Parser.parseString (/var/polyglot/pg3/ns/<myISYMACaddr>_7/node_modules/xml2js/lib/parser.js:5:59) at Controller.processPrograms (/var/polyglot/pg3/ns/<myISYMACaddr>_7/Nodes/ControllerNode.js:188:18) at Controller.onDiscover (/var/polyglot/pg3/ns/<myISYMACaddr>_7/Nodes/ControllerNode.js:82:12) 2023-07-26 15:52:18 error: NS: Parsing Error: TypeError: Cannot read properties of undefined (reading 'program') at /var/polyglot/pg3/ns/<myISYMACaddr>_7/Nodes/ControllerNode.js:192:35 at Parser.<anonymous> (/var/polyglot/pg3/ns/<myISYMACaddr>_7/node_modules/xml2js/lib/parser.js:304:18) at Parser.emit (node:events:525:35) at SAXParser.onclosetag (/var/polyglot/pg3/ns/<myISYMACaddr>_7/node_modules/xml2js/lib/parser.js:262:26) at emit (/var/polyglot/pg3/ns/<myISYMACaddr>_7/node_modules/sax/lib/sax.js:624:35) at emitNode (/var/polyglot/pg3/ns/<myISYMACaddr>_7/node_modules/sax/lib/sax.js:629:5) at closeTag (/var/polyglot/pg3/ns/<myISYMACaddr>_7/node_modules/sax/lib/sax.js:889:7) at SAXParser.write (/var/polyglot/pg3/ns/<myISYMACaddr>_7/node_modules/sax/lib/sax.js:1436:13) at exports.Parser.Parser.parseString (/var/polyglot/pg3/ns/<myISYMACaddr>_7/node_modules/xml2js/lib/parser.js:323:31) at Parser.parseString (/var/polyglot/pg3/ns/<myISYMACaddr>_7/node_modules/xml2js/lib/parser.js:5:59) 2023-07-26 17:50:56 warn: POLY: Received stop message 2023-07-26 19:37:44 info: NS: Starting Node Server 2023-07-26 19:37:44 info: POLY: Interface starting 2023-07-26 19:37:44 info: POLY: Getting config from environment 2023-07-26 19:37:44 info: POLY: MQTT client connected 2023-07-26 19:37:44 info: NS: MQTT Connection started 2023-07-26 19:37:44 error: POLY: Config has logLevel: WARNING 2023-07-26 19:37:44 warn: POLY: Loglevel: warn 2023-07-26 21:01:29 info: POLY: Loglevel: info

Thanks for chiming in. Can I use this NS to play a short message I recorded? Some of the features I noticed were: say sayall saypreset Do you use any of these? What do they do? By the way, @bpwwer, may I suggest the list of features you provided that I linked to above be added to github readme page so it's there when one clicks "More Info" from Nodeserver store.

ok, can I un-purchase the NS trial until I've had a chance to migrate to PG3x? I'm holding off on doing that move for now for a few reasons (stability, lack of automated PG3x restore on eisy from Polisy, which is my backup hardware, etc.) I'm sure I'll do it at some point; just not in the next 6 days I have left in the trial version. I do like the features it offers, and only need them to work with the legacy Sonos S1 app so hopefully don't need much, if any, support going forward (which seems to be a little on the light side.) But given this NS is not free (and actually comparatively expensive), plus some recent bugs that, as of right now, may not get fixed (but might not be a problem for me) it's going to be important to try before I buy.

Does this NS work? I purchased free trial, installed it, and started it. It said it started successfully but it didn't really. I tried to look at the NS logs but it said 'file not found'. Here's what PG3 had to say about it in its log: 7/25/2023, 16:27:55 [pg3] info: startNs:: ST-Sonos 7/25/2023, 16:27:55 [pg3] info: startNs:: ST-Sonos is valid 7/25/2023, 16:27:55 [pg3] debug: checkLicense:: ST-Sonos Getting node server store entry 7/25/2023, 16:27:55 [pg3] debug: checkLicense:: ST-Sonos Getting node server purchase record 7/25/2023, 16:27:55 [pg3] debug: Getting status for ST-Sonos 00:0d:b9:53:c7:dc 82a81345-75e8-48c1-87fc-60e4cfd46860 7/25/2023, 16:27:57 [pg3] info: checkLicense:: ST-Sonos Valid subscription license found. Expires: 2023-07-31T18:20:13.000Z 7/25/2023, 16:27:57 [pg3] info: startNs:: ST-Sonos finished update check 7/25/2023, 16:27:57 [pg3] info: [ST-Sonos(10)] :: Starting NodeServer - Version 1.0.8 7/25/2023, 16:27:57 [pg3] info: startNs:: ST-Sonos updating database (enabled, timestarted) 7/25/2023, 16:27:57 [pg3] debug: [MESSAGE_PUBLISHED] Client pg3_client has published message on udi/pg3/frontend/clients/aef56f72-00cc-48c3-a122-fcdd3e3ac5fd to broker pg3_broker 7/25/2023, 16:27:57 [pg3] debug: [MESSAGE_PUBLISHED] Client pg3_client has published message on udi/pg3/frontend/clients/aef56f72-00cc-48c3-a122-fcdd3e3ac5fd to broker pg3_broker 7/25/2023, 16:27:58 [pg3] error: [ST-Sonos(10)] :: STDERR: node:internal/modules/cjs/loader:1042 throw err; ^ Error: Cannot find module '/var/polyglot/pg3/ns/000db953c7dc_10/st-sonos.js' at Module._resolveFilename (node:internal/modules/cjs/loader:1039:15) at Module._load (node:internal/modules/cjs/loader:885:27) at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12) at node:internal/main/run_main_module:23:47 { code: 'MODULE_NOT_FOUND', requireStack: [] } Node.js v18.13.0 7/25/2023, 16:27:58 [pg3] info: [ST-Sonos(10)] :: Exit cause code: 1 - signal: null 7/25/2023, 16:27:58 [pg3] debug: [MESSAGE_PUBLISHED] Client pg3_client has published message on udi/pg3/frontend/clients/aef56f72-00cc-48c3-a122-fcdd3e3ac5fd to broker pg3_broker 7/25/2023, 16:27:58 [pg3] info: startNs:: ST-Sonos starting polls 7/25/2023, 16:27:58 [pg3] info: Starting ST-Sonos Expire Check timer 7/25/2023, 16:27:58 [pg3] info: Checking if ST-Sonos has expired 7/25/2023, 16:27:58 [pg3] info: Starting ST-Sonos Info timer 0 7/25/2023, 16:27:58 [pg3] info: Starting ST-Sonos Version Check timer 7/25/2023, 16:27:58 [pg3] debug: MQTT Results: [frontend/ns/admin] :: {"startNs":{"success":true}} 7/25/2023, 16:27:58 [pg3] debug: [MESSAGE_PUBLISHED] Client pg3_client has published message on udi/pg3/frontend/clients/aef56f72-00cc-48c3-a122-fcdd3e3ac5fd to broker pg3_broker 7/25/2023, 16:28:02 [pg3] debug: Sending logfile to frontend :: /var/polyglot/pg3/ns/000db953c7dc_10/logs/debug.log am running PG3 3.1.21 and IoX 5.6.2 on Polisy

What if one's functioning Polisy stopped functioning? I don't think one can get a Polisy anymore so I think it should be viewed as important to help Polisy users be able to move to eisy. In fact, I bought an eisy when it came out in part to have backup hardware in case my Polisy fails. I was contemplating going to PG3x on my Polisy once 3.1.37 beta became stable release. From reading this thread I probably shouldn't move yet to preserve what's there in terms of migrating to eisy. While I'm okay to wait, as PG3x grows and PG3 falls behind, its likely going to have stuff I want, not to mention increasingly better support.

@landolfi, @Techman, @AKAPADIA, have you solved or made progress on your problems since upgrading to 5.6.3? For those looking to provide feedback about Zigbee or request device support, please consider using one of the separate threads for that so this thread can focus on the non-Zigbee related IoX 5.6.3 issues. Thanks for considering it.

IoX refuses to recognize Celsius temperature reports for my three Aeotec Multisensors and the two Aeotec aerQ sensors I tried. Read somewhere that this is a known issue on the UDI 'to do' list but this is second hand info. I suspect issues I had with aerQ and a Zooz ZSE44 - excessive battery-killing reporting - to be unique to Zmatter board (based on feedback from Aeotec and Zooz support) but did not open a support ticket to get UDI confirmation or troubleshooting advice. I simply returned the aerQ sensors while I still could and gave up on using the ZSE44. I will say that I do have another ZSE44 that works ok so, for that sensor, I suspect the sensor itself is the problem or part of it. (Yes, I upgraded to latest firmware and did factory reset, etc. etc.) I don't know if all the migration issues I reported (summarized briefly in my original post) were fixed and won't be able to tell as I only had one 994i and it's now fully migrated to IoP. The only net new Zwave devices I added after moving to IoP are the aerQ sensors I tried and returned, and a ZEN32 Scene Controller. The latter communicates fine but is clunky to work with (see this post and this post). It certainly isn't the replacement for a KeypadLinc that I had hoped it would be, although that appears to be related to IoX support for it based on what Home Assistant can do with it so maybe it will one day be better than a KeypadLinc thanks to its multi tap capability.

I don't want to overstate the problem but I also don't think it should be dismissed or minimized. For sure when everything is fine... well... everything is fine. What distinguishes a good product/solution/vendor from a bad one is how it deals with problems - and the need for upgrades when it comes to this kind of thing. Things should be as easy as possible to configure, fix, upgrade, and replace. Although they aren't "easy" by any means right now (i.e. don't try this if you don't have patience and determination), anything that moves things closer towards 'easy' and away from "holy-sh*t-what-a-hassle!" is valuable.

anytime I've excluded/re-included a device it's gotten a new zwave address. that's the issue. too bad there isn't a way to manually (re)assign an address to a zwave device and end up with all the program and other relationships intact.

Is the messing up of programs following an exclude/include only an issue with ISY? I thought it was a general zwave issue affecting all HA controllers.

I moved to IoP (IoX 5.6.0 on Polisy) over a month ago and it's fixed a whole bunch of problems I was having. Also allowed me to dust off automation ideas I had put on the back burner because: - I had reached the 1000 program limit (about a year ago) - now at 2000, I think. I was at 980 programs and if I wanted to add anything meaningful I needed to give something up - Simple automations were slow, even insteon triggered ones like motion turning on a light, which used to work flawlessly before I added a bunch of zwave devices. Everything is back to flawless... well 99% flawless... there are always the odd glitches with Insteon. - Nodeservers (5 of them) were retrying constantly and sometimes failing to communicate. That's no longer a problem. - Startups would exceed event queue capacity and there was no way to figure out what events were missed. To mitigate this I had developed a complex startup routine that only enabled programs and did device queries in chunks with regular delays in between. I must have spend 100's of hours building and refining that and, while it was better, it was far from perfect. - Admin Console loading and backups were exxxxtra suuuper sloooow. These are not quick things by any means, but, relatively speaking, they are notably better now. The migration wasn't flawless by any means but it was far less painful than I expected. The biggest issue was that about half a dozen zwave devices (out of an estimated 70) remained as "Placeholders" after migration. An "Update with Interview" would fix them temporarily but at next reboot they would come back as placeholders. A couple magically fixed themselves (some kind of sun and moon alignment thing is all I can think of) but many needed to be excluded/re-included, which messes up all the programs those devices are in. Support tickets about those placeholders remain unanswered to this day. There are also zwave devices for which I reported issues that weren't there with 994i and did not hear anything back so not hopeful they will be fixed. That said, overall zwave stuff is working light years better than it was. Moving of 994i was definitely worth it.

Just so it's clear on a few things: the wakeup interval I use is 14,400 (4 hours) I do have one of these that's working fine both worked fine on the 994i (and were hard to setup there too) before I had to exclude/re-include them when I moved to IoP/Zmatter

a worn battery always reports good to excellent on my battery tester after it's no longer working in my ZSE44. I don't have anything else to use with it but I bet it would still work in many other devices. Also battery level is not reliable. It goes all of the place. On one of them right now it's been at 0% for couple weeks but still reporting temp/humidity. Getting these buggers linked requires a lot of perseverance and repeated tries. Also had to set 'keep awake' time to 10-15 secs in order to make it through interview (or write changes after the interview didn't work). Also to help with configuration, and to allow time for "Update Neighbors" after I moved it from the "bench" (close to Polisy), where I have to bring it to configure it, to it's ultimate destination. And, initially, they wouldn't work in their ultimate destination until I put a repeater in the same room. Just outside in the hall wouldn't work. Don't forget to turn 'keep awake' off once it works unless you're okay with replacing the battery every couple weeks... For one of the two ZSE44s I have, I've had repeated emails with zooz support after moving recently to Polisy with ZMwatter from 994i because it constantly wakes up / goes to sleep Here's a tiny sample from a program I wrote to capture activity: 2023/05/20, 09:40:32 , Main bath sensor, ASLEEP 2023/05/20, 09:40:47 , Main bath sensor, AWAKE 2023/05/20, 09:40:53 , Main bath sensor, ASLEEP 2023/05/20, 09:40:54 , Main bath sensor, AWAKE 2023/05/20, 09:40:59 , Main bath sensor, ASLEEP 2023/05/20, 09:41:04 , Main bath sensor, AWAKE 2023/05/20, 09:41:16 , Main bath sensor, ASLEEP 2023/05/20, 09:41:20 , Main bath sensor, AWAKE Have gone through probably 3 batteries trying multiple things over several days until Zooz support finally relented and said "send it back". It's about a year old and, yes, I did update the firmware to latest version as part of the multiple things I tried. I really want to move off these and just tested some Aeotec aerQ's. I like the form factor and features but, interestingly, both sensors I just got way over report the temperature. Aeotec support can't figure out why. I'm starting to wonder if Zmatter dongle is the cause or part of the problem. Both ZSE44 and aerQ devices are overreporting situations, and both vendors are acting like this is the only time they've ever heard of this problem (which I normally doubt but this time it has me doubting my equipment). I may raise the issue with UDI but they would probably need to get those devices to do proper testing/troubleshooting - something I doubt they would do unless there was significant demand form the masses. I'm finding they're generally ignoring the zwave device problems I've reported since moving to Polisy. Maybe they're looking at them - maybe they're not. They're not telling me and, except for one device (ZEN17), they're not asking for more info so I can't tell.

I'd like several of my 'Favorite' tiles (or whatever they're called) to show a second sub-node (or whatever they're called) instead of the primary one. For example I have smart switches that show, in this order, Total Energy, Current Power, Current Voltage, and Current Current. I added the tile to my favorites and it shows the first number (Total Energy) but I want "Current Power" to show. See screenshot below. Of course, I'm referring to the favorites screen (back from this one.) This actually wasn't a problem when I was using 994i. Only after I moved to IoP 5.6.0. Sorry if this is explained somewhere already. I looked around, including wiki, and didn't find it.