carteriii

I just cleared the cache, downloaded the latest start.jnlp from the link you provided, tried again, and still got the same result. Despite the confirmation dialog saying the upgrade will happen, it seems my polisy simply doesn't see it (or get the message to see it) and so it simply reboots to the same version. I put in a support ticket, but THANK YOU @Techman for taking your time to help!

I'm not entirely sure what you mean by "launcher", though that sounds like the IoX "Finder" as I know it. I'm not directly doing it from that, but I use the launcher/finder to open the admin console, then go to the config tab, then click "Upgrade Packages". This screenshot shows that sequence, from top to bottom. I did just remove the power entirely and don't see anything substantially different. I'll include the sysconfig.txt in the screenshot as well (after reboot). Sounds like a support ticket and just waiting for help may be my only alternative at this point since you say I'm missing a lot of information.

When I go to run the upgrade, I get the following message, which seems good . . . Within a few seconds of that, my Polisy reboots, and comes up running again within a minute or so, running the same old version. I did check the sysConfig.txt ahead of time, which produced the following output, showing that I am running at least the minimum version necessary for the upgrade, but the last line is interesting in that it says, "UDX_UPGRADE_STATUS="inactive". What does that mean? *** OS *** FreeBSD polisy 13.2-RELEASE-p11 FreeBSD 13.2-RELEASE-p11 releng/13.2-n254665-f5ac4e174fdd POLISY amd64 *** Package Information *** ************ UDX ************ ************ IoX ************ ************ libwebsockets ************ ************ tpm2-tools ************ ************ eisyui ************ ************ iox_matter_bridge ************ ************ mosquitto ************ ************ pg3x ************ *** Networking Information *** igb0: flags=8863<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=4e527bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6,NOMAP> ether 00:0d:b9:55:24:74 inet6 fe80::20d:b9ff:fe55:2474%igb0 prefixlen 64 scopeid 0x1 inet 192.168.1.14 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (1000baseT <full-duplex>) status: active nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL> igb1: flags=8822<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=4e527bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6,NOMAP> ether 00:0d:b9:55:24:75 media: Ethernet autoselect status: no carrier nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> igb2: flags=8822<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=4e527bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6,NOMAP> ether 00:0d:b9:55:24:76 media: Ethernet autoselect status: no carrier nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384 options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6> inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet 127.0.0.1 netmask 0xff000000 groups: lo nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> pflog0: flags=0<> metric 0 mtu 33160 groups: pflog pfsync0: flags=0<> metric 0 mtu 1500 syncpeer: 0.0.0.0 maxupd: 128 defer: off syncok: 1 groups: pfsync *** USB Devices *** ugen0.1: <AMD XHCI root HUB> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA) ugen1.1: <AMD EHCI root HUB> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen1.2: <vendor 0x0438 product 0x7900> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (100mA) *** Upgrade Status **** UDX_UPGRADE_STATUS="inactive" For what it's worth, my ISY Portal license is active. Is there anything else that would cause the upgrade status to be "inactive"? I downloaded the pg3 and System messages. When the polisy reboots, I do see these lines which seem like they might be relevant to the failed (or no-op) upgrade: 2025-10-04 14:45:18.490 [pg3] error: stderr: ld-elf.so.1: Shared object "libssl.so.30" not found, required by "pkg" 2025-10-04 14:45:18.515 [pg3] info: ***************************************** 2025-10-04 14:45:18.516 [pg3] info: Latest PG3x version available is undefined 2025-10-04 14:45:18.517 [pg3] info: ***************************************** In the system messasges.txt, I see a few errors immediately after the reboot, including one "REPORT THIS!" line: Oct 4 16:35:03 polisy daemon[4088]: 2025-10-04 14:35:03.454 [pg3] ^[[32minfo^[[39m: Auto Reinstalling completed Oct 4 16:35:03 polisy daemon[4088]: 2025-10-04 14:35:03.458 [pg3] ^[[33mwarn^[[39m: Logging to console is disabled. Log file is in /var/polyglot/pg3/logs/pg3-current.log Oct 4 16:43:49 polisy daemon[4088]: 2025-10-04 14:43:49.973 [pg3] ^[[31merror^[[39m: unhandledRejection REPORT THIS!: [object Promise], reason: Error: ENOENT: no such file or directory, access '/var/polyglot/pg3/logs/pg3-current.log' Oct 4 16:43:49 polisy daemon[4088]: 2025-10-04 14:43:49.977 [pg3] ^[[32minfo^[[39m: Failed to unwatch stream, this should be OK. Oct 4 16:43:49 polisy daemon[4088]: 2025-10-04 14:43:49.980 [pg3] ^[[31merror^[[39m: unhandledRejection REPORT THIS!: [object Promise], reason: Error: ENOENT: no such file or directory, access '/var/polyglot/pg3/logs/pg3-current.log' Oct 4 16:43:58 polisy shutdown[11505]: reboot by root: Oct 4 16:43:58 polisy daemon[4088]: 2025-10-04 14:43:58.200 [pg3] ^[[32minfo^[[39m: Caught SIGTERM/SIGINT Shutting down. Oct 4 16:43:58 polisy daemon[4088]: 2025-10-04 14:43:58.207 [pg3] ^[[32minfo^[[39m: Pushing notification {"title":"PG3 is stopping","body":"From PG3 (00:0d:b9:55:24:74)"} to UD Mobile Oct 4 16:43:58 polisy daemon[4088]: 2025-10-04 14:43:58.559 [pg3] ^[[32minfo^[[39m: Stopping running NodeServers... Oct 4 16:43:58 polisy daemon[4088]: 2025-10-04 14:43:58.574 [pg3] ^[[31merror^[[39m: stopNs: SqliteError: attempt to write a readonly database Oct 4 16:43:58 polisy daemon[4088]: at Object.update (/var/polyglot/node_modules/@universaldevices/pg3x/lib/models/nodeserver.js:322:6) Oct 4 16:43:58 polisy daemon[4088]: at process.processTicksAndRejections (node:internal/process/task_queues:95:5) Oct 4 16:43:58 polisy daemon[4088]: at async stopNs (/var/polyglot/node_modules/@universaldevices/pg3x/lib/services/nodeservers.js:823:7) Oct 4 16:43:58 polisy daemon[4088]: at async Promise.allSettled (index 0) Everything seems to run fine after this, but the upgrade simply never happens, and never appears to really get started. All this happens in about a minute (or two), rather than the 30 minutes warned by the dialog when starting the process.

@Jimbo.Automates I try not to tag people because I know it can be perceived as slightly obnoxious, and this is not urgent, but I'm assuming at this point you may have simply forgotten about this and hope you can get back to it whenever is convenient for you. Thank you!

My other thread was automatically closed, so I'm effectively re-opening it with this new thread. The history is here: Where we left of is, you posted this screenshot, implying you can both test & set the chime mode: Unfortunately I do not see the chime mode static settings (e.g. "off") as selections. In my second to last post, I showed a screenshot of what I see when trying to test the value, which I'll include again here. Given the screenshot of yours immediately above, shouldn't I see a potential value/selection for "Off" in my screenshot below, where instead I only see Unknown, Silent, Single Beep, etc.? Thanks in advance!

I have a thought for your consideration . . . I upgraded from an ISY994 to my Polisy. Part of the process for this was creating a backup from the ISY994 that I restored to the Polisy via the admin console. Could it be that I'm only seeing menu selections that would be available on the ISY994, even though I'm definitely now running on the Polisy with the latest version of everything? That is a wild guess on my part, but at a minimum the upgrade situation seems potentially relevant.

@Jimbo.Automates I hope you don't mind me tagging you directly, but since you posted above, I'm hoping you can perhaps share a screenshot from your admin console that would confirm whether (a) I'm being stupid, or (b) something is missing from my installation. For what it's worth, I notice in your screenshot above that you are testing and setting 'Alarm-Elk / Home' whereas instead I see only the area name without the pre-pended alarm name. The only places I see a similar concatenation is with the list of tasks or outputs (e.g. "ELK Controller / Output-001"). My area "Main Floor" shows at the same level as the controller itself: I thought it might help to also post a screenshot of what I see when testing the chime mode. My area ("Main Floor") does allow me to test the chime mode, but does not show a value of "Off" as yours does. Instead I have "Silent" and "Single Beep" as you can see below. Does this indicate a version difference? IoX v5.8.4 shows a date of 2024-06-27 (shown in my earlier screenshot) so at a minimum it doesn't seem old. Any thoughts, or is it time for a support ticket?

I do not believe that I have that option. This is using IoX 5.8.4 on Polisy. To make sure I'm thinking of this correctly, let me first show a screenshot of the ELK plugin, showing the nodes, showing that "Main Floor" is my 'Area 1' (similar to your 'Home'), also showing the Chime Mode as GV2 that I mentioned in my first post: Now let me show a picture of the dropdown selection list in the admin console: I feel like I must be missing something obvious, but I can't figure it out. Perhaps I'm just being an idiot (it's been known to happen). Could IoX not be showing all the options? I'll paste the "About" from the admin console here, and you can see my ELK version in the first screenshot above.

The chime mode is clearly visible through the area.GV2 variable, but can we set that variable directly? When I create a program, the only options in the drop-down for setting the area are Query, Bypass, Clear Bypass, Set Armed Status, Set Poll Voltages, and Set Additional Trigger. Is there another way, or would this be considered a feature request? If it matters, my use case is similar to my use of Alexa announcements for doors opening (e.g. "the front door just opened"), but we've also used the chime since the Alexa announcements can have such a delay. I disable the Alexa announcements when we really want things quiet, and I'd like to be able to similarly disable (& later re-enable) the chime.

You (@Jimbo.Automates) were exactly correct that there were Python installation issues that support helped me address. The ELK plugin came up as connected as soon as everything was restarted, without needing to do anything else. I now see all the nodes for my system, and I am seeing logs. Now I need to finish my ISY994 migration, but the basic install & function seems to be working well. Thank you!

Ah, duh! Sorry. I really did do a recursive "find", but that directory cannot be viewed by even admin without a sudo so it missed it. Sorry. So interestingly enough, it says pip3 (called from line2 of install.sh) cannot be found -------------------------------------------------- Installation date: Wed Sep 11 13:34:33 PDT 2024 ./install.sh: line 2: pip3: command not found -------------------------------------------------- Installation date: Sun Sep 15 12:23:08 PDT 2024 ./install.sh: line 2: pip3: command not found -------------------------------------------------- Installation date: Sun Sep 15 13:03:47 PDT 2024 ./install.sh: line 2: pip3: command not found -------------------------------------------------- Installation date: Sun Sep 15 16:12:50 PDT 2024 ./install.sh: line 2: pip3: command not found If it matters, the only command in install.sh is "pip3 install -r requirements.txt --user" That led me to find this post, in which someone mentioned the symbolic link from /usr/bin/pip3: That in turn points to /usr/local/bin/pip-3.11 (which does not exist). lrwxr-xr-x 1 root wheel 23 Sep 15 16:12 pip3 -> /usr/local/bin/pip-3.11 From the previous forum discussion, I tried the following, which did not create a new symbolic link or update anything. sudo unlink /usr/local/bin/pip3 sudo pkg upgrade udx I've also tried to "sudo pkg install pip311" and variants like pip3.11 but can't figure out the name of the package through the udi repository. I've searched all these forums and done some google searching, but can't figure it out. If anyone knows how to install pip3, that would seem to be the root cause of these current problems.

Thank you! Where in the install.log? I just looked in /var/log, /var/polyglot/log, and /var/polyglot/pg3/logs and do not see it anywhere. I should add that I've also restored a backup of my ISY994 to Polisy, and that obviously used the ELK module. Do I need to delete the module from IoX before trying to get the nodeserver running? I haven't seen any wiki doc or post suggesting that, and I'm obviously hoping not to have to re-do all my programs from the isy994 that currently reference elk zones & conditions. I ran the upgrade packages and according to that log, nothing had to be updated. I rebooted anyway and don't see any change. I did note that the logs include the question, "Is client running?" when it says that the log file doesn't exist. Below are the log lines from when I clicked to stop the ELK plugin and then start it again, and that "Is client running?" line is the last of this section that I've copied. 2024-09-15 14:44:06.234 [pg3] info: Received commands on topic udi/pg3/frontend/ns/admin: stopNs 2024-09-15 14:44:06.260 [pg3] info: [ELK(1)]: Stopping Nodeserver 2024-09-15 14:44:06.261 [pg3] info: call_udx: Making request to socket with url /rest/pg3.stop.ns 2024-09-15 14:44:06.574 [pg3] info: Received commands on topic udi/pg3/frontend/system/admin: getStoreEntry 2024-09-15 14:44:06.582 [pg3] info: Getting Node Server store entry for nsid c7297a6e-f1c6-4c12-8b66-532a6721431a from store Production 2024-09-15 14:44:19.062 [pg3] info: Received commands on topic udi/pg3/frontend/ns/admin: startNs 2024-09-15 14:44:19.073 [pg3] info: startNs:: ELK 2024-09-15 14:44:19.074 [pg3] info: startNs:: ELK is valid 2024-09-15 14:44:19.342 [pg3] info: checkLicense:: ELK Valid subscription license found. Expires: 2024-10-11T20:33:48.000Z 2024-09-15 14:44:19.356 [pg3] info: startNs:: ELK finished update check 2024-09-15 14:44:19.359 [pg3] info: startNs:: Starting ELK 2024-09-15 14:44:19.360 [pg3] info: call_udx: Making request to socket with url /rest/pg3.start.ns 2024-09-15 14:44:19.395 [pg3] info: Received commands on topic udi/pg3/frontend/system/admin: getStoreEntry 2024-09-15 14:44:19.402 [pg3] info: Getting Node Server store entry for nsid c7297a6e-f1c6-4c12-8b66-532a6721431a from store Production 2024-09-15 14:44:19.537 [pg3] info: startNs:: ELK starting polls 2024-09-15 14:44:19.543 [pg3] info: Starting ELK Expire Check timer 2024-09-15 14:44:19.545 [pg3] info: Checking if ELK has expired 2024-09-15 14:44:19.545 [pg3] info: Starting ELK Info timer 0 2024-09-15 14:44:19.558 [pg3] info: startNs:: ELK updating database (enabled, timestarted) 2024-09-15 14:44:19.559 [pg3] info: startNs:: ELK started. 2024-09-15 14:44:19.733 [pg3] info: Received commands on topic udi/pg3/frontend/system/admin: getStoreEntry 2024-09-15 14:44:19.740 [pg3] info: Getting Node Server store entry for nsid c7297a6e-f1c6-4c12-8b66-532a6721431a from store Production 2024-09-15 14:44:51.402 [pg3] info: Received commands on topic udi/pg3/frontend/ns/admin: startLogging 2024-09-15 14:44:51.409 [pg3] info: Is client running? /var/polyglot/pg3/ns/000db9552474_1/logs/debug.log does not exist.

Running PG3x 3.2.27 with a brand new install on Polisy. Added ELK trial plugin. I entered config information that has been running on ISY994 (so I know what the user code it and it's right, and host is 192.168.1.15:2101 and I know 2101 is right and it still works from the ISY994 module). I did not enter a value for "outputs" since I haven't been sure what that is. ELK 3.10.15 shows disconnected, so I want to debug. I click the button/tab for "Log" and always see the message, "Starting events log", but never see any things displayed to the screen. I switch the log level to "Debug", and I have rebooted everything, including the Polisy itself. When I click to, "Download Log Package", I get a message that /var/polyglot/pg3/ns/000db9552474_1/logs/debug.log does not exist. I ssh to Polisy and found that the "logs" folder doesn't even exist: I'm clearly missing something, but have no idea what to try next. Why don't I even get any logs? Any suggestions? Thanks in advance.

Update. This morning is two weeks after I posted here, and "magically" the announcements started working again. Based on another thread in these forums, I did call Amazon (2 weeks ago) and go through the pain of getting to a human and "filing a case", but I cannot know whether they finally got around to it or if something else on their end simply refreshed. I guess it's good confirmation that there was never a problem with the ISY Portal or my ISY, but it's also frustrating that this could happen at all. Thanks to everyone who helped me here, contributed to previous discussions, and even read this thread!

The java update and updated start.jnlp eliminated the "Not Found" error. My JRE install was only a few updates old, but my previous start.jnlp appears to be about 2 years old so I went through the full process you outlined. Thank you. I have not made any network changes in a long time, BUT I live in California where the recent rains caused MANY outages of my internet service provider (Cox, who gets their hardware & software from Comcast, so they don't even have experts to know what is happening, and whose support is even more useless than you'd expect). In the past month, I've had at least 5 or 6 extended outages, and at least twice last week which could coincide with when everything stopped. Unfortunately that didn't occur to me at the time I started debugging. It's still purely a guess on my part, but that likely caused the problems. As you pointed out, I have disabled & re-enabled the skill, re-created a few Alexa routines (not all), and I even defined an entirely new state variable with an entirely new Alexa routine, yet the routine does not fire even though the state of the contact sensor is clearly getting updated from/through ISY Portal. This now appears to be 100% an Amazon problem, and I fought through their support system to get a ticket logged because of course the phone support person wasn't able to do much more than help people. Maybe things will magically start working again in another week or two as it has for many some other users in the past. I did just check my Portal license and it's good now, but looks like I need to update in the next month. My licenses imply that I've had all this running very stable for about 4 years now. Nice! Now I just need to get un-lazy and upgrade off the ISY994.

My routines are still not triggering "when" the ISY "contact sensor" is opened. I even created an entirely new variable, new device contact sensor on the ISY Portal, and it all shows and updates properly according to the Alexa app. Ironically a Google search returned a link back to this forum which I missed when searching here. It seems others may have experienced a similar problem in the past with Amazon simply not properly triggering the "when" condition of a routine. I clearly cannot be certain, but it sure feels like this now. For future reference, I thought it would be useful to include a link to the previous discussion. https://forum.universal-devices.com/topic/38947-alexa-motion-sensors-not-triggering-routines/ https://forum.universal-devices.com/topic/42386-routines-not-working/

I just deleted a routine and re-created a routine from scratch, but it still doesn't play the announcement even when I open the door AND I do see the status change in the app. That seems to clearly imply it's now an Alexa problem. The announcement does work when I press the routine "play" icon in the app, but the routine doesn't seem to fire when the door itself opens, even when I am looking at the door contact status in the app and it shows the change. I'll now keep playing with Alexa, and maybe it needs some time for the routine to truly become active with it's "when" evaluation. At a minimum, I do feel whatever was previously NOT updating the device state in Alexa is now working. I'm assuming you saw or did something to get it going and would love to know what you saw. Thank you! I'll post an update after I keep playing with Alexa more and see why the routine isn't firing.

Yes! I now see the state change. Having said that, it seems to be new behavior. Did you change anything? I'll include a screenshot below that shows one door status had not been updated for 3 days (Feb 21 in the screenshot and it's now Feb 24), but when I just manually updated the state variable, it changed, and now when I open the door, it also changes (as it should). I'm still not hearing the announcement, but I'll try deleting the routines that do the announcements and re-create them again to see if things now work.

Thanks. For what it's worth, I did purchase and have a Polisy set up, but I have simply been a combination of scared to make the move and busy, wanting to make sure I had an entire weekend in case I had any problems.

Ooops. I'm sorry. I forgot to say that I did that. I deleted the routine for one (not all, if that makes a difference) of the contact sensor announcements, then created an entirely new one, and did not get any announcement. I also edited the one routine of the device I deleted to re-add the device (not entirely deleting the full routine) and it also did not result in the normal announcement.

I just disabled the skill again, then manually deleted one of the Alexa contact sensor devices, re-enabled/linked the skill, and the skill did discover the contact sensor again and re-add it. But still no announcement for a change in the state variable. Am I correct that there is no ISY Portal event log entry to show that state variables are properly being synchronized with ISY Portal (like the ELK events that I do see in the event log)? I am inclined to agree with you that it's likely something to do with Alexa, but it would also be nice just to completely rule out that possibility.

I am able to login to the 994 console just fine. Having said that, the launcher ("IoX Finder" window title) first shows two "Not Found" dialogs, while my ISY is shown, and once I click through the two alerts, everything runs fine. It feels like it's still looking for an old URL (???) so I've simply ignored the alerts. As for how I exposed things, everything is a Device/Contact Sensor to Alexa, using only using the state variables for announcements. Attached is an image of a page of my ISY Portal devices. I don't think it's relevant, but for full context, in the 994, all the ELK zones for doors set specific state variables when a door opens. I did that, rather than using the Elk zone directly, so that I could "silence" the announcements with a separate variable (effectively a boolean flag) within the 994. I can confirm that the state variables are definitely being set & unset properly within the 994. I think I'll try disabling the skill again and even removing the devices before re-enabling the skill so that it is equivalent to a fresh install and see what happens.

For years I have used Alexa to announce changes in state variables, but last week it simply stopped working. I'm assuming the problem is somewhere between my ISY and ISY Portal, or between ISY Portal and Amazon. I tried disabling and re-enabling the Alexa skill, but that didn't change anything. I will say that it didn't discover any new devices, but still showed the "devices" that were still there from years ago. When I login to ISY Portal, it shows my ISY994 online. I looked at the ISY Portal Error log and will paste below the contents from the past few days, since I don't know what the error messages mean. The -5011 and -140000 codes exist in the log for many times going back a long time, so at a minimum it doesn't seem like anything unusual. I looked at the ISY Portal Event log, and I see my ELK area & zone events coming through just fine, and although I expected to see state variables changes in the log, I don't see any, even going back days to when the announcements were working, implying ISY Portal doesn't log state variable changes. This seems like something that's just lacking in ISY Portal that would be beneficial. Maybe it's worth adding that to the ISY Portal event log???? At a minimum, since I'm getting events from my ELK alarm, it seems that the connection from my ISY to ISY Portal is working. So the problem would seem to be in the Alexa connection, and obviously there's an earlier thread here about that which suggests disabling and re-enabling the skill, but I tried that. What else can I try? How else can I debug this? I can't help but wonder if Amazon changed something about the integration that might break this for everyone, but at a minimum, I'm the first person posting here about this so perhaps it's just me. Any tips would be appreciated. Thanks in advance. 2024/02/21 23:57:53 System -140000 my.isy.io 2024/02/22 00:01:44 System -140000 my.isy.io 2024/02/22 00:51:45 System -5011 uuid:0 2024/02/22 02:51:45 System -5011 uuid:0 2024/02/22 04:51:47 System -5011 uuid:0 2024/02/22 05:05:38 System -100 [DHCP] state=RENEW 2024/02/22 06:51:46 System -5011 uuid:0 2024/02/22 07:52:04 System -5011 uuid:0 2024/02/22 09:51:50 System -5011 uuid:0 2024/02/22 11:51:49 System -5011 uuid:0 2024/02/22 13:51:50 System -5011 uuid:0 2024/02/22 15:51:52 System -5011 uuid:0 2024/02/22 17:52:37 System -5011 uuid:0 2024/02/22 18:51:58 System -5011 uuid:0 2024/02/22 20:51:47 System -5011 uuid:0 2024/02/22 22:36:31 System -5 Start 2024/02/22 22:36:32 System -110022 /CONF/INSTENG.OPT 2024/02/22 22:36:32 System -110012 /CONF/INSTENG.OPT 2024/02/22 22:36:36 System -110022 /DEF/F6/I1/NLS/EN_US.TXT 2024/02/22 22:36:43 System -170001 UDQ:Queue Full: IPOLLWAKEUP : Task[11] SOCK SOCK-PROC pty=27 2024/02/22 22:36:41 System -110022 /CONF/ELKXPRT.XML 2024/02/22 22:36:42 System -7123 ID 002F :err=0, tag='status', num=44, nest=4, o 2024/02/22 22:36:43 System -110022 /CONF/UZWNDKEY.TXT 2024/02/22 22:36:43 System -110012 /CONF/UZWNDKEY.TXT 2024/02/22 22:38:34 System -170001 UDQ: Queue(s) Full, message ignored 2024/02/22 22:38:34 System -170001 UDQ: Queue(s) Full, message ignored 2024/02/22 22:38:45 System -170001 UDQ: Queue(s) Full, message ignored 2024/02/22 22:38:55 System -170001 UDQ: Queue(s) Full, message ignored 2024/02/22 22:39:05 System -170001 UDQ: Queue(s) Full, message ignored 2024/02/22 22:39:05 System -170001 UDQ: Queue(s) Full, message ignored 2024/02/22 22:39:18 System -170001 UDQ: Queue(s) Full, message ignored 2024/02/22 22:39:28 System -170001 UDQ: Queue(s) Full, message ignored 2024/02/22 22:36:43 System -170001 [Network] Established 2024/02/22 22:39:08 System -10011 n/a 2024/02/22 22:51:44 System -5011 uuid:0 2024/02/23 00:51:43 System -5011 uuid:0 2024/02/23 01:00:08 System -170001 [TCP-Conn] -1/-140002, Net Module Rule: 6 2024/02/23 02:51:45 System -5011 uuid:0 2024/02/23 04:51:47 System -5011 uuid:0 2024/02/23 06:51:51 System -5011 uuid:0 2024/02/23 08:51:45 System -5011 uuid:0 2024/02/23 09:37:30 System -50001 -5 2024/02/23 09:42:47 System -140000 my.isy.io 2024/02/23 09:43:22 System -140000 my.isy.io 2024/02/23 10:36:45 System -100 [DHCP] state=RENEW 2024/02/23 10:43:57 System -140000 my.isy.io 2024/02/23 10:44:32 System -140000 my.isy.io 2024/02/23 10:51:34 System -140000 my.isy.io 2024/02/23 10:52:04 System -140000 my.isy.io 2024/02/23 10:52:39 System -140000 my.isy.io 2024/02/23 11:49:54 System -140000 my.isy.io 2024/02/23 11:50:24 System -140000 my.isy.io 2024/02/23 11:58:45 System -140000 my.isy.io 2024/02/23 11:59:39 System -140000 my.isy.io 2024/02/23 12:00:14 System -140000 my.isy.io 2024/02/23 12:00:49 System -140000 my.isy.io 2024/02/23 12:51:56 System -5011 uuid:0 2024/02/23 14:15:35 System -170001 [TCP-Conn] -1/-140002, Portal 2024/02/23 14:51:51 System -5011 uuid:0 2024/02/23 16:51:46 System -5011 uuid:0 2024/02/23 18:51:49 System -5011 uuid:0 2024/02/23 20:51:47 System -5011 uuid:0 2024/02/23 22:51:42 System -5011 uuid:0 2024/02/24 00:51:41 System -5011 uuid:0 2024/02/24 02:51:41 System -5011 uuid:0 2024/02/24 04:51:46 System -5011 uuid:0 2024/02/24 06:51:48 System -5011 uuid:0 2024/02/24 07:36:51 System -100 [DHCP] state=RENEW 2024/02/24 08:51:46 System -5011 uuid:0 2024/02/24 09:02:03 System -5011 uuid:0

That was it! Thank you so much! And yes, I'm now kicking myself for not seeing that in the edit window. I really was trying to do whatever I could (hence, my workaround comment) but now I'm a bit embarrassed that I missed that. Thank you for your patience with me.

Below are two screenshots (one of top of screen, second bottom of screen after scrolling down) of what I see in UD Mobile for this node. There is no charge port door or sentry mode anywhere on the screen. You did say, "If they are correctly linked in the node server", which leads me to think perhaps this is a Nodeserver problem or bug that the status is not showing up, despite the status properly showing in the ISY controller UI (image shown in my first post) ???? Regarding my comment on programs, I was only pointing out that I have a workaround, which is to use an ISY Program to test the "charge port door" status and set a simple ISY integer or state variable which can be viewed in UD Mobile just fine. Sorry that I made it sound like that was part of the problem. All programs and other status works fine. It's only these two values from the Tesla Nodeserver that don't appear.