DSwallow

I noticed I was back to the delayed visibility of the current state and checked the latest log and found no BPUP_Listener thread again. I've been downloading logs mostly regularly and did discover I apparently captured the log where it stopped. The relevant items look pretty straightforward, at least as to why the thread apparently died... after that error line, there's no sign of the thread again. 2023-11-15 14:34:16,692 Thread-2137 udi_interface.node DEBUG node:setDriver: 5d7253e6_lt:Theatre Fan Light No change in ST's value 2023-11-15 14:34:20,230 BPUP_Listener udi_interface DEBUG bondapi:_BPUP_keepAlive: Sending keep alive message to Bond Bridge... 2023-11-15 14:34:22,241 BPUP_Listener udi_interface ERROR bondapi:_BPUP_keepAlive: Bond Bridge did not respond to keep-alive message - connection closed. 2023-11-15 14:34:45,906 MQTT udi_interface.interface DEBUG interface:_message: QUEUING incoming message shortPoll 2023-11-15 14:34:45,907 Command udi_interface.interface DEBUG interface:_parseInput: DEQUEING shortPoll 2023-11-15 14:34:45,907 Thread-2138 udi_interface DEBUG bondns:shortPoll: In shortPoll()... 2023-11-15 14:34:45,907 Thread-2138 udi_interface INFO nodes:updateNodeStates: Updating node states for bridge zzdf73384... 2023-11-15 14:34:45,907 Thread-2138 udi_interface DEBUG bondapi:_call_api: HTTP GET /v2/sys/version data: {} 2023-11-15 14:34:46,279 Thread-2138 udi_interface DEBUG bondapi:_call_api: HTTP response code: 200 data: {"target":"zermatt","fw_ver":"v2.14.5","fw_date":"Mon Aug 24 21:40:36 UTC 2020","uptime_s":93191,"boot_patch":"not outdated","make":"Olibra","model":"BD-1000","branding_profile":"OLIBRA_BD1000","bondid":"ZZDF73384","upgrade_http":true,"api":2,"_":"86d859b4"} I've uploaded the full log package if that has anything you need, though I don't have a log from when the service initialized this time, I could provide one from restarting it now if that'd offer anything you need. https://dswallow-my.sharepoint.com/:u:/g/personal/dswallow_2150_com/ERPLnR10CxFGgTZBxiuIGdMBbewwx0G7QtUzmqBW8yBZrA?e=0NGMff

After doing the Restart it seems to be working. I went back down to just Info and notice now I see a log entry for "BPUP_Listener" corresponding to each command turning the fan on or off, which I did not see before. So I suppose there's nothing to follow up here at the moment and things are working. Looking at the logs, I see a time when after a command there was a similar log line, the last being: 2023-11-08 10:49:25,620 Command udi_interface INFO nodes:cmd_dof: Turn off light in cmd_dof: {'address': '3c8f19f5_dl', 'cmd': 'DOF', 'query': {}} 2023-11-08 10:49:25,693 BPUP_Listener udi_interface INFO nodes:_BPUP_statusUpdate: Device status update received for device 3c8f19f5 on bridge zzdf73384. And then the next commands have nothing: 2023-11-08 16:46:29,468 Command udi_interface INFO nodes:cmd_don: Turn on fan in cmd_don: {'address': '3f071c36', 'cmd': 'DON', 'query': {}} 2023-11-08 16:46:29,543 Command udi_interface INFO nodes:cmd_don: Turn on light in cmd_don: {'address': '3f071c36_dl', 'cmd': 'DON', 'query': {}} 2023-11-08 16:46:52,932 Thread-3101 udi_interface INFO nodes:updateNodeStates: Updating node states for bridge zzdf73384... I will restart it with debug selected and leave it running; maybe after 6 hours or more it stops; looks like I'd last restarted it about 25 hours ago.

I was playing around today with an idea of hitting a ceiling fan with on commands for a short time to start it moving, then sending an off command and waiting a short time and doing the sequence again. This lets me gently spin the fan instead of being stuck at the lowest possible speed always-on. It's actually working out rather well in the sense I'm getting the gentle air movement I sometimes want. Right now I'm going 5 seconds on then 8 seconds off and repeating. Though I'll likely experiment with different patterns. However, viewing the state of the fan in the UI, I rarely see the on/off state changing, so I looked at the Bond node server logs and see that the node server appears to query the state every 30 seconds and send that as an update. So, the state only matches up if it happens to do a query right after sending a command. Would there be a chance of either triggering the query of the specific device commanded immediately after processing a command, or similarly just sending the state as if the command executed? I don't really need the current state to match exactly, but it might be useful in the future if it did, rather than only updating every 30 seconds, out of sync with commands. Make sense?

It would be nice to be rid of the constant prompting (well, "constant" maybe is a bit overstating it, but it's something that happens often enough to be noted and annoying) for accessing an "unsecure site" because of the self-signed certificate used by Polyglot. I also noticed a different certificate is used for the /WEB query like /WEB/sysconfig.txt vs what the Polyglot URLs use, not sure if/when it may change. As I understand it, if you could at least use a certificate chain when creating the self-signed certificates, we'd have the option of trusting the self-signed root/parent used to generate the PG3 certificate each time it starts, thus avoiding having to go through the exercise of clicking through security warnings, which just feels tacky. Any chance this could be done? From what I was able to find online, there's plenty of examples to follow using openssl; not sure what Universal Devices currently is doing. This had a healthy discussion on the subject: https://superuser.com/questions/126121/how-to-create-my-own-certificate-chain

After waiting about 20 minutes for what Michel said should take about 5, I went to the node server details page in Polyglot and pressed "Restart". Everything started up and it shows my 27 nodes again. During the 20 minutes of waiting I hunted but didn't see any sign of where the system was initiating anything like compiling. I did see the timeout after 2 minutes when it initially was doing the re-install of the Kasa node server, but nothing I saw around that log entry really indicated anything special happening/triggered. And I suppose when it finished whatever it may have been doing, perhaps it could've immediately triggered the node server being started up? Presuming it wasn't at that time; is there some health check that occurs regularly which would've started it up had I waited longer?

I just began encountering this, I think it began after upgrading from Trial to a paid version, though since I wasn't really looking before I'm not sure. I was a little uncertain about the process of going from a trial to a paid license, since it's not really discussed anywhere I found, and everything I see on the purchase page makes it look like two different things. Anyway, tried deleting it, rebooting the EISY and installing again, with no luck. I then found this thread and will give it a go. Annoyingly, the turn-off-autoscroll checkbox on the log display now seems to not work. I'd have sworn it did just a few minutes ago. Well, it's not scrolling per-se, instead it's apparently updating the view from wherever I position the log file, as the log file scrolls under me -- in other words, not locking me at the tail, but still scrolling happily away.

I had an online session with UD support a little while ago, and ultimately the issue was caused by a delayed response to the DHCP request when the EISY boots up. The EISY has a 10 second timeout and then continues its startup/initialization, and at that time there's no IP address assigned, so it just works off the 0.0.0.0 address. The DHCP request did ultimately complete, but nothing in the EISY sees that as an event to trigger any operation to reconfigure itself appropriately. I'm told that when the lease is renewed (or if the Ethernet cable is unplugged/reconnected or the device switches over to WiFi, if configured) that the EISY would see the event triggered and go through the same process of initializing, though may still encounter the DHCP delay and continue having the same IP address issue, and not resolving eisy.local. We moved the EISY to connect through the built-in switch in my router (a UDM-SE) and went through the reboot process and now saw the DHCP request get responded to immediately, the IP address was properly configured, it showed up in the UI and eisy.local resolved. Now on my side the DHCP delay was caused because my EISY was connected to a Dell PowerConnect 2848 switch, and apparently there's an issue in the way the Spanning Tree operations configure on a port when the port connects, which it does when rebooting the EISY (i.e., the ethernet port goes dark during the reboot). It then is in a learning mode on the port and blocking at least some of the packets, perhaps the broadcast ones. The solution is to enable the "Fast Link" option on the port on the switch. This leads to the port coming up in Forwarding mode immediately while the port is then monitored to ensure it isn't in a looped connection. A couple articles I discovered doing a search: https://serverfault.com/questions/305788/dell-powerconnect-2824-dhcp-takes-30-40-seconds-to-respond https://www.mcbsys.com/blog/2010/02/gigabit-switch-spanning-tree-causes-slow-logon/ The documentation from the switch about the "Fast Link" option: Fast Link — When selected, enables Fast Link mode for the port. If Fast Link mode is enabled for a port, the Port State is automatically placed in the Forwarding state when the port link is up. Fast Link mode optimizes the time it takes for the STP protocol to converge. STP convergence can take 30-60 seconds in large networks. So, I will monitor it more closely for a while, but it does seem to be consistent and behaving now. And I'm not sure what other devices I may have that are using DHCP on that switch but I've turned on Fast Link on all the ports except those connected to other switches, so I may end up cleaning up some other odd delays in reboots/initializations. A few of you folks previously mentioned having a 0.0.0.0 IP address showing in the UI and eisy.local not resolving, so here's a few things you might try to investigate... One of the EISY services can be restarted which will re-initialize parts of the network operation so if there was an initialization delay getting an IP, once it is configured, this would configure things again. After restarting this service, I did get eisy.local resolving (though we didn't look at the UI specifically to see if the IP was there now, it probably was). sudo service ud_net_detect onerestart You can also look at the logs to see if there are entries referencing the IP address not be available: sudo vi /var/udx/logs/log Look for items like this: Wed Nov 1 19:21:46 EDT 2023|/usr/local/etc/udx.d/static/eth.ops: error, no ip address for re0 ... Wed Nov 1 19:21:47 EDT 2023|/usr/local/etc/udx.d/static/eth.ops: error, no ip address for re0 ... Wed Nov 1 19:21:48 EDT 2023|/usr/local/etc/udx.d/static/eth.ops: error, no ip address for re0 ... Wed Nov 1 19:21:49 EDT 2023|/usr/local/etc/udx.d/static/eth.ops: error, no ip address for re0 ... Side effects... when I reboot the EISY I usually have a command prompt doing a ping to watch when it is back up, and with the fixed DHCP, the operation is noticeably quicker. Without Fast Link enabled on the switch for the connected port: Reply from 192.168.3.41: bytes=32 time<1ms TTL=64 Reply from 192.168.3.41: bytes=32 time<1ms TTL=64 Request timed out. Request timed out. Request timed out. Request timed out. Request timed out. Request timed out. Reply from 192.168.3.200: Destination host unreachable. Reply from 192.168.3.200: Destination host unreachable. Reply from 192.168.3.200: Destination host unreachable. Reply from 192.168.3.200: Destination host unreachable. Reply from 192.168.3.200: Destination host unreachable. Reply from 192.168.3.200: Destination host unreachable. Reply from 192.168.3.200: Destination host unreachable. Reply from 192.168.3.41: bytes=32 time=1529ms TTL=64 Reply from 192.168.3.41: bytes=32 time<1ms TTL=64 Reply from 192.168.3.41: bytes=32 time<1ms TTL=64 With Fast Link enabled: Reply from 192.168.3.41: bytes=32 time<1ms TTL=64 Reply from 192.168.3.41: bytes=32 time<1ms TTL=64 Request timed out. Request timed out. Request timed out. Request timed out. Reply from 192.168.3.41: bytes=32 time<1ms TTL=64 Reply from 192.168.3.41: bytes=32 time<1ms TTL=64

SO, I looked through some logs on the EISY and found a clue about what's likely leading to the issue of the IP not being available by whatever code needs it to respond to things like displaying in the Java UI or replying to network queries to resolve eisy.local. From /var/udx/logs/debug.log, the latest boot includes these messages with regard to nics/network operations: 2023-10-31 12:49:03 - Warn| NetMgr [T:35250049024] couldn't find any wlan devices (../src/Device/Net/UDXNetworkManager.cpp@254:addWiFiDevices()) 2023-10-31 12:49:03 - Info| NetMgr [T:35250049024] re0 is a hardware link/Ethernet. checking to see if WiFi (../src/Device/Net/UDXNetworkManager.cpp@180:addInterface()) 2023-10-31 12:49:03 - Info| Config [T:35250049024] OID = net.re.0.%parent (../src/Config/UDXConfigRecords.cpp@101:getWlanParent()) 2023-10-31 12:49:03 - Error|SysCall [T:35250049024] [1]: command failed sysctl net.re.0.%parent (../src/Kernel/SystemCall.cpp@185:execWithOutput()) 2023-10-31 12:49:03 - Info| NetMgr [T:35250049024] re0 is not a WiFi device (../src/Device/Net/UDXNetworkManager.cpp@211:addInterface()) 2023-10-31 12:49:03 - Info| NetMgr [T:35250049024] setting IPV4 inet for re0 (../src/Device/Net/UDXNetworkManager.cpp@110:addInterface()) 2023-10-31 12:49:03 - Warn| NetMgr [T:35250049024] lo0 is loopback. ignoring (../src/Device/Net/UDXNetworkManager.cpp@147:addInterface()) 2023-10-31 12:49:03 - Warn| NetMgr [T:35250049024] ignoring lo0 (loopback, tap/tun/wifibox (../src/Device/Net/UDXNetworkManager.cpp@97:addInterface()) 2023-10-31 12:49:03 - Warn| NetMgr [T:35250049024] ignoring lo0 (loopback, tap/tun/wifibox (../src/Device/Net/UDXNetworkManager.cpp@97:addInterface()) 2023-10-31 12:49:03 - Warn| NetMgr [T:35250049024] ignoring lo0 (loopback, tap/tun/wifibox (../src/Device/Net/UDXNetworkManager.cpp@97:addInterface()) 2023-10-31 12:49:03 - Info| NetMgr [T:35250049024] setting interface state information if any (../src/Device/Net/UDXNetworkManager.cpp@425:registerAllDevices()) 2023-10-31 12:49:03 - Info| Config [T:35250049024] getting network configuration for ifconfig_re0_ipv6 ... (../src/Config/UDXRCConfig.cpp@48:getNetworkConfig()) 2023-10-31 12:49:03 - Info| Config [T:35250049024] getting network configuration for ifconfig_re0 ... (../src/Config/UDXRCConfig.cpp@48:getNetworkConfig()) 2023-10-31 12:49:03 - Warn|Network [T:35250049024] re0 is disabled. Ignoring (../src/Device/Net/UDXNetworkInterface.cpp@321:refresh()) 2023-10-31 12:49:03 - Info| Config [T:35250049024] getting network configuration for ifconfig_re0 ... (../src/Config/UDXRCConfig.cpp@48:getNetworkConfig()) 2023-10-31 12:49:03 - Info| Config [T:35250049024] getting network configuration for ifconfig_re0_ipv6 ... (../src/Config/UDXRCConfig.cpp@48:getNetworkConfig()) 2023-10-31 12:49:03 - Warn| NetMgr [T:35250049024] re0 is not running (../src/Device/Net/UDXNetworkManager.cpp@448:registerAllDevices()) 2023-10-31 12:49:03 - Info| Serial [T:35250049024] starting to look for serial devices (../src/Device/Serial/UDXSerialPortManager.cpp@42:registerAllDevices()) 2023-10-31 12:49:05 - Info| NetMgr [T:35250057984] refreshing IPV4 inet for re0 (../src/Device/Net/UDXNetworkManager.cpp@342:refreshInterface()) 2023-10-31 12:49:05 - Info| NetMgr [T:35250057984] refreshing IPV4 inet for lo0 - Loopback. Ignoring (../src/Device/Net/UDXNetworkManager.cpp@354:refreshInterface()) 2023-10-31 12:49:05 - Info| NetMgr [T:35250057984] refreshing IPV4 inet for lo0 - Loopback. Ignoring (../src/Device/Net/UDXNetworkManager.cpp@354:refreshInterface()) 2023-10-31 12:49:05 - Warn| NetMgr [T:35250057984] refreshing IPV4 inet for lo0 - Loopback. Ignoring (../src/Device/Net/UDXNetworkManager.cpp@339:refreshInterface()) 2023-10-31 12:49:05 - Info| Config [T:35250057984] getting network configuration for ifconfig_re0_ipv6 ... (../src/Config/UDXRCConfig.cpp@48:getNetworkConfig()) 2023-10-31 12:49:05 - Info| Config [T:35250057984] getting network configuration for ifconfig_re0 ... (../src/Config/UDXRCConfig.cpp@48:getNetworkConfig()) 2023-10-31 12:49:05 - Warn|Network [T:35250057984] re0 is disabled. Ignoring (../src/Device/Net/UDXNetworkInterface.cpp@321:refresh()) 2023-10-31 12:49:05 - Info| Config [T:35250057984] getting network configuration for ifconfig_re0 ... (../src/Config/UDXRCConfig.cpp@48:getNetworkConfig()) 2023-10-31 12:49:05 - Info| Config [T:35250057984] getting network configuration for ifconfig_re0_ipv6 ... (../src/Config/UDXRCConfig.cpp@48:getNetworkConfig()) 2023-10-31 12:49:05 - Info| Config [T:35250057984] starting to parse file /var/udx/.env, delim = = (../src/Config/UDXConfig.cpp@20:parse()) 2023-10-31 12:49:05 - Info|SysConfig [T:35250057984] publish to topic = sconfig/network/nics. msg = {"NICs":[{"name":"re0","logicalName":"re0","mac":"00:21:ffffffb9:02:65:ffffffbf","isEnabledIPv4":false,"isEnabledIPv6":false,"isRunning":false,"isDHCP":false,"isRTADV":false,"isWiFi":false,"IPInfo":{"ip":"0.0.0.0","ipV6":"::","mask":"255.0.0.0","gateway":"0.0.0.0","gatewayV6":"::"}}],"root":{"uuid":"00:21:b9:02:65:bf","serial":"92144837862847"}} (../src/mqtt/UDXSysConfig.cpp@770:udxPublishMessage()) 2023-10-31 12:49:05 - DBG3| MQTTc [T:35250057984] MQTTLogEvent level=16, desc=Client null sending PUBLISH (d0, q0, r0, m12, 'sconfig/network/nics', ... (347 bytes)) (../src/System/UDXMQTTc.cpp@618:on_log()) 2023-10-31 12:49:05 - Info| MQTTc [T:35250057984] published 11 (../src/System/UDXMQTTc.cpp@575:on_publish()) 2023-10-31 12:49:05 - Info| MQTTc [T:35250057984] published 12 (../src/System/UDXMQTTc.cpp@575:on_publish()) What's interesting here is earlier in the log file is a record of where there was a real IP address on that publish-to-topic entry: 2023-10-26 17:58:36 - Warn| NetMgr [T:35266076672] couldn't find any wlan devices (../src/Device/Net/UDXNetworkManager.cpp@254:addWiFiDevices()) 2023-10-26 17:58:36 - Info| NetMgr [T:35266076672] re0 is a hardware link/Ethernet. checking to see if WiFi (../src/Device/Net/UDXNetworkManager.cpp@180:addInterface()) 2023-10-26 17:58:36 - Info| Config [T:35266076672] OID = net.re.0.%parent (../src/Config/UDXConfigRecords.cpp@101:getWlanParent()) 2023-10-26 17:58:36 - Error|SysCall [T:35266076672] [1]: command failed sysctl net.re.0.%parent (../src/Kernel/SystemCall.cpp@185:execWithOutput()) 2023-10-26 17:58:36 - Info| NetMgr [T:35266076672] re0 is not a WiFi device (../src/Device/Net/UDXNetworkManager.cpp@211:addInterface()) 2023-10-26 17:58:36 - Info| NetMgr [T:35266076672] setting IPV4 inet for re0 (../src/Device/Net/UDXNetworkManager.cpp@110:addInterface()) 2023-10-26 17:58:36 - Warn| NetMgr [T:35266076672] lo0 is loopback. ignoring (../src/Device/Net/UDXNetworkManager.cpp@147:addInterface()) 2023-10-26 17:58:36 - Warn| NetMgr [T:35266076672] ignoring lo0 (loopback, tap/tun/wifibox (../src/Device/Net/UDXNetworkManager.cpp@97:addInterface()) 2023-10-26 17:58:36 - Warn| NetMgr [T:35266076672] ignoring lo0 (loopback, tap/tun/wifibox (../src/Device/Net/UDXNetworkManager.cpp@97:addInterface()) 2023-10-26 17:58:36 - Warn| NetMgr [T:35266076672] ignoring lo0 (loopback, tap/tun/wifibox (../src/Device/Net/UDXNetworkManager.cpp@97:addInterface()) 2023-10-26 17:58:36 - Info| NetMgr [T:35266076672] setting interface state information if any (../src/Device/Net/UDXNetworkManager.cpp@425:registerAllDevices()) 2023-10-26 17:58:36 - Info| Config [T:35266076672] getting network configuration for ifconfig_re0_ipv6 ... (../src/Config/UDXRCConfig.cpp@48:getNetworkConfig()) 2023-10-26 17:58:36 - Info| Config [T:35266076672] getting network configuration for ifconfig_re0 ... (../src/Config/UDXRCConfig.cpp@48:getNetworkConfig()) 2023-10-26 17:58:36 - Warn|Network [T:35266076672] re0 is disabled. Ignoring (../src/Device/Net/UDXNetworkInterface.cpp@321:refresh()) 2023-10-26 17:58:36 - Info| Config [T:35266076672] getting network configuration for ifconfig_re0 ... (../src/Config/UDXRCConfig.cpp@48:getNetworkConfig()) 2023-10-26 17:58:36 - Info| Config [T:35266076672] getting network configuration for ifconfig_re0_ipv6 ... (../src/Config/UDXRCConfig.cpp@48:getNetworkConfig()) 2023-10-26 17:58:36 - Warn| NetMgr [T:35266076672] re0 is not running (../src/Device/Net/UDXNetworkManager.cpp@448:registerAllDevices()) 2023-10-26 17:58:36 - Info| Serial [T:35266076672] starting to look for serial devices (../src/Device/Serial/UDXSerialPortManager.cpp@42:registerAllDevices()) 2023-10-26 17:58:43 - Info| NetMgr [T:35266085632] refreshing IPV4 inet for re0 (../src/Device/Net/UDXNetworkManager.cpp@342:refreshInterface()) 2023-10-26 17:58:43 - Info| NetMgr [T:35266085632] refreshing IPV4 inet for lo0 - Loopback. Ignoring (../src/Device/Net/UDXNetworkManager.cpp@354:refreshInterface()) 2023-10-26 17:58:43 - Info| NetMgr [T:35266085632] refreshing IPV4 inet for lo0 - Loopback. Ignoring (../src/Device/Net/UDXNetworkManager.cpp@354:refreshInterface()) 2023-10-26 17:58:43 - Warn| NetMgr [T:35266085632] refreshing IPV4 inet for lo0 - Loopback. Ignoring (../src/Device/Net/UDXNetworkManager.cpp@339:refreshInterface()) 2023-10-26 17:58:43 - Info| Config [T:35266085632] getting network configuration for ifconfig_re0_ipv6 ... (../src/Config/UDXRCConfig.cpp@48:getNetworkConfig()) 2023-10-26 17:58:43 - Info| Config [T:35266085632] getting network configuration for ifconfig_re0 ... (../src/Config/UDXRCConfig.cpp@48:getNetworkConfig()) 2023-10-26 17:58:43 - Warn|Network [T:35266085632] re0 is disabled. Ignoring (../src/Device/Net/UDXNetworkInterface.cpp@321:refresh()) 2023-10-26 17:58:43 - Info| Config [T:35266085632] getting network configuration for ifconfig_re0 ... (../src/Config/UDXRCConfig.cpp@48:getNetworkConfig()) 2023-10-26 17:58:43 - Info| Config [T:35266085632] getting network configuration for ifconfig_re0_ipv6 ... (../src/Config/UDXRCConfig.cpp@48:getNetworkConfig()) 2023-10-26 17:58:43 - Info| Config [T:35266085632] starting to parse file /var/udx/.env, delim = = (../src/Config/UDXConfig.cpp@20:parse()) 2023-10-26 17:58:43 - Info|SysConfig [T:35266085632] publish to topic = sconfig/network/nics. msg = {"NICs":[{"name":"re0","logicalName":"re0","mac":"00:21:ffffffb9:02:65:ffffffbf","isEnabledIPv4":false,"isEnabledIPv6":false,"isRunning":false,"isDHCP":false,"isRTADV":false,"isWiFi":false,"IPInfo":{"ip":"192.168.3.172","ipV6":"::","mask":"255.255.255.0","gateway":"0.0.0.0","gatewayV6":"::"}}],"root":{"uuid":"00:21:b9:02:65:bf","serial":"92144837862847","activeIP":"\"192.168.3.172\"","activeNic":"\"re0\""}} (../src/mqtt/UDXSysConfig.cpp@770:udxPublishMessage()) 2023-10-26 17:58:43 - DBG3| MQTTc [T:35266085632] MQTTLogEvent level=16, desc=Client null sending PUBLISH (d0, q0, r0, m12, 'sconfig/network/nics', ... (410 bytes)) (../src/System/UDXMQTTc.cpp@618:on_log()) 2023-10-26 17:58:43 - Info| MQTTc [T:35266085632] published 11 (../src/System/UDXMQTTc.cpp@575:on_publish()) 2023-10-26 17:58:43 - Info| MQTTc [T:35266085632] published 12 (../src/System/UDXMQTTc.cpp@575:on_publish()) I would sort of guess here is that there's some sort of disconnect between whatever triggers this program to be querying IP settings from the re0 interface and how they may not yet be current, like if the DHCP request just got processed and some signal is sent and then a query made and those settings received aren't quite yet wherever the program is querying them, then it just spews out an update to the MQTT service storing those settings that it read, even though they're bad. And likely anything else wanting to use or display some of those settings is querying that published topic from MQTT and using it. Might even be more plausible considering the timestamp on /var/db/dhclient.leases.re0 where a record of the dhcp client leases is kept is one second after the log output above where the bad info is reported in the log file. [admin@eisy /var/db]$ sudo stat -F /var/db/dhclient.leases.re0 ---------- 1 root wheel 1141 Oct 31 12:49:06 2023 /var/db/dhclient.leases.re0 Anyway, I then tried seeing if I could force it to update, maybe by disconnecting/reconnecting the ethernet connection. All that did was make it go unresponsive on the network; Insteon stuff was still behaving, but I could no longer connect to the IP. I had to restart the EISY to get IP connectivity back. When I then went back to the debug.log file, I saw an interesting addition to the end... it now had an IP address in the logged line sending the update to MQTT 2023-10-31 20:16:48 - Info|SysConfig [T:35277861632] publish to topic = sconfig/network/nics. msg = {"NICs":[{"name":"re0","logicalName":"re0","mac":"00:21:ffffffb9:02:65:ffffffbf","isEnabledIPv4":false,"isEnabledIPv6":false,"isRunning":false,"isDHCP":false,"isRTADV":false,"isWiFi":false,"IPInfo":{"ip":"192.168.3.41","ipV6":"::","mask":"255.255.255.0","gateway":"0.0.0.0","gatewayV6":"::"}}],"root":{"uuid":"00:21:b9:02:65:bf","serial":"92144837862847"}} (../src/mqtt/UDXSysConfig.cpp@770:udxPublishMessage()) Though looking at the earlier entry where it was also sending an IP, there are some entries that are still missing here, specifically the activeIP and activeNIC keys in that message, so I do think this is somehow part of the problem: "activeIP":"\"192.168.3.172\"","activeNic":"\"re0\"" Now, on to opening a ticket and pointing them to this info.

Yeah, I know. I'll get there and open a ticket soon. But one more little investigative nugget to follow...

Exploring mDNS was among the many things I went through today; the EISY isn't using mDNS or at least if they think they are, their service is dead and they aren't listening on the port. It's listening via UDP and responding to requests that the IoX Finder is sending out; I captured the whole exchange in Wireshark and examined it. Now IoX Finder is also making a variety of other sorts of queries, and I see all sorts of devices on my network responding, including mDNS and NETBIOS name queries. But the only thing coming from the EISY is the UDP packet data I posted above. I can interact from my desktop using mDNS with all sorts of devices on my same network. Nothing is getting blocked there. Here's all the mDNS related packets that occurred during my test: 192.168.3.200 is my desktop 192.168.3.41 is the EISY 192.168.3.1 is my gateway/router 192.168.3.7 is my DNS No. Time Source Destination Protocol Length Info 1287 4.953985 192.168.3.200 224.0.0.251 MDNS 70 Standard query 0x0000 A eisy.local, "QM" question 1288 4.954681 fe80::10c6:6196:1ef5:1575 ff02::fb MDNS 90 Standard query 0x0000 A eisy.local, "QM" question 1289 4.955198 192.168.3.200 224.0.0.251 MDNS 70 Standard query 0x0000 AAAA eisy.local, "QM" question 1290 4.955599 fe80::10c6:6196:1ef5:1575 ff02::fb MDNS 90 Standard query 0x0000 AAAA eisy.local, "QM" question 1291 4.956055 192.168.3.193 224.0.0.251 MDNS 70 Standard query response 0x0000 A eisy.local, "QM" question 1292 4.956230 192.168.3.194 224.0.0.251 MDNS 70 Standard query response 0x0000 A eisy.local, "QM" question 1293 4.956484 fe80::218:ddff:fe04:a59f ff02::fb MDNS 90 Standard query response 0x0000 A eisy.local, "QM" question 1294 4.956484 fe80::218:ddff:fe04:accc ff02::fb MDNS 90 Standard query response 0x0000 A eisy.local, "QM" question 1295 4.956645 192.168.3.193 224.0.0.251 MDNS 70 Standard query response 0x0000 AAAA eisy.local, "QM" question 1296 4.956849 192.168.3.194 224.0.0.251 MDNS 70 Standard query response 0x0000 AAAA eisy.local, "QM" question 1297 4.956849 fe80::218:ddff:fe04:a59f ff02::fb MDNS 90 Standard query response 0x0000 AAAA eisy.local, "QM" question 1298 4.957047 fe80::218:ddff:fe04:accc ff02::fb MDNS 90 Standard query response 0x0000 AAAA eisy.local, "QM" question 1303 4.971808 192.168.3.200 224.0.0.251 MDNS 70 Standard query 0x0000 A eisy.local, "QM" question 1304 4.972317 fe80::10c6:6196:1ef5:1575 ff02::fb MDNS 90 Standard query 0x0000 A eisy.local, "QM" question 1305 4.972670 192.168.3.193 224.0.0.251 MDNS 70 Standard query response 0x0000 A eisy.local, "QM" question 1306 4.972670 192.168.3.194 224.0.0.251 MDNS 70 Standard query response 0x0000 A eisy.local, "QM" question 1307 4.972834 192.168.3.200 224.0.0.251 MDNS 70 Standard query 0x0000 AAAA eisy.local, "QM" question 1308 4.973143 fe80::218:ddff:fe04:a59f ff02::fb MDNS 90 Standard query response 0x0000 A eisy.local, "QM" question 1309 4.973252 fe80::218:ddff:fe04:accc ff02::fb MDNS 90 Standard query response 0x0000 A eisy.local, "QM" question 1310 4.973287 fe80::10c6:6196:1ef5:1575 ff02::fb MDNS 90 Standard query 0x0000 AAAA eisy.local, "QM" question 1311 4.973718 192.168.3.194 224.0.0.251 MDNS 70 Standard query response 0x0000 AAAA eisy.local, "QM" question 1312 4.973718 192.168.3.193 224.0.0.251 MDNS 70 Standard query response 0x0000 AAAA eisy.local, "QM" question 1313 4.974039 fe80::218:ddff:fe04:a59f ff02::fb MDNS 90 Standard query response 0x0000 AAAA eisy.local, "QM" question 1314 4.974215 fe80::218:ddff:fe04:accc ff02::fb MDNS 90 Standard query response 0x0000 AAAA eisy.local, "QM" question 1315 5.122854 192.168.3.149 224.0.0.251 MDNS 89 Standard query response 0x0000 A, cache flush 192.168.3.149 1318 5.173124 192.168.3.149 224.0.0.251 MDNS 89 Standard query response 0x0000 A, cache flush 192.168.3.149 1346 5.960090 192.168.3.200 224.0.0.251 MDNS 70 Standard query 0x0000 A eisy.local, "QM" question 1347 5.960611 fe80::10c6:6196:1ef5:1575 ff02::fb MDNS 90 Standard query 0x0000 A eisy.local, "QM" question 1348 5.960990 192.168.3.200 224.0.0.251 MDNS 70 Standard query 0x0000 AAAA eisy.local, "QM" question 1349 5.961018 192.168.3.193 224.0.0.251 MDNS 70 Standard query response 0x0000 A eisy.local, "QM" question 1350 5.961018 192.168.3.194 224.0.0.251 MDNS 70 Standard query response 0x0000 A eisy.local, "QM" question 1351 5.961399 fe80::10c6:6196:1ef5:1575 ff02::fb MDNS 90 Standard query 0x0000 AAAA eisy.local, "QM" question 1352 5.961518 fe80::218:ddff:fe04:a59f ff02::fb MDNS 90 Standard query response 0x0000 A eisy.local, "QM" question 1353 5.961605 fe80::218:ddff:fe04:accc ff02::fb MDNS 90 Standard query response 0x0000 A eisy.local, "QM" question 1354 5.961832 192.168.3.193 224.0.0.251 MDNS 70 Standard query response 0x0000 AAAA eisy.local, "QM" question 1355 5.961943 192.168.3.194 224.0.0.251 MDNS 70 Standard query response 0x0000 AAAA eisy.local, "QM" question 1356 5.962350 fe80::218:ddff:fe04:accc ff02::fb MDNS 90 Standard query response 0x0000 AAAA eisy.local, "QM" question 1357 5.962440 fe80::218:ddff:fe04:a59f ff02::fb MDNS 90 Standard query response 0x0000 AAAA eisy.local, "QM" question 1358 5.975741 192.168.3.200 224.0.0.251 MDNS 70 Standard query 0x0000 A eisy.local, "QM" question 1359 5.976209 fe80::10c6:6196:1ef5:1575 ff02::fb MDNS 90 Standard query 0x0000 A eisy.local, "QM" question 1360 5.976592 192.168.3.200 224.0.0.251 MDNS 70 Standard query 0x0000 AAAA eisy.local, "QM" question 1361 5.976656 fe80::218:ddff:fe04:accc ff02::fb MDNS 90 Standard query response 0x0000 A eisy.local, "QM" question 1362 5.976752 fe80::218:ddff:fe04:a59f ff02::fb MDNS 90 Standard query response 0x0000 A eisy.local, "QM" question 1363 5.977016 fe80::10c6:6196:1ef5:1575 ff02::fb MDNS 90 Standard query 0x0000 AAAA eisy.local, "QM" question 1364 5.977054 192.168.3.194 224.0.0.251 MDNS 70 Standard query response 0x0000 A eisy.local, "QM" question 1365 5.977054 192.168.3.193 224.0.0.251 MDNS 70 Standard query response 0x0000 A eisy.local, "QM" question 1366 5.977383 192.168.3.194 224.0.0.251 MDNS 70 Standard query response 0x0000 AAAA eisy.local, "QM" question 1367 5.977500 192.168.3.193 224.0.0.251 MDNS 70 Standard query response 0x0000 AAAA eisy.local, "QM" question 1368 5.977786 fe80::218:ddff:fe04:accc ff02::fb MDNS 90 Standard query response 0x0000 AAAA eisy.local, "QM" question 1369 5.977958 fe80::218:ddff:fe04:a59f ff02::fb MDNS 90 Standard query response 0x0000 AAAA eisy.local, "QM" question 1545 6.033822 192.168.3.149 224.0.0.251 MDNS 89 Standard query response 0x0000 A, cache flush 192.168.3.149 1546 6.047189 192.168.3.149 224.0.0.251 MDNS 89 Standard query response 0x0000 A, cache flush 192.168.3.149 2156 9.815478 192.168.3.200 224.0.0.251 MDNS 72 Standard query 0x0000 A polisy.local, "QM" question 2157 9.816010 fe80::10c6:6196:1ef5:1575 ff02::fb MDNS 92 Standard query 0x0000 A polisy.local, "QM" question 2159 9.816461 192.168.3.193 224.0.0.251 MDNS 72 Standard query response 0x0000 A polisy.local, "QM" question 2160 9.816461 192.168.3.194 224.0.0.251 MDNS 72 Standard query response 0x0000 A polisy.local, "QM" question 2161 9.816473 192.168.3.200 224.0.0.251 MDNS 72 Standard query 0x0000 AAAA polisy.local, "QM" question 2162 9.816866 fe80::10c6:6196:1ef5:1575 ff02::fb MDNS 92 Standard query 0x0000 AAAA polisy.local, "QM" question 2163 9.817130 fe80::218:ddff:fe04:accc ff02::fb MDNS 92 Standard query response 0x0000 A polisy.local, "QM" question 2164 9.817130 fe80::218:ddff:fe04:a59f ff02::fb MDNS 92 Standard query response 0x0000 A polisy.local, "QM" question 2165 9.817403 192.168.3.193 224.0.0.251 MDNS 72 Standard query response 0x0000 AAAA polisy.local, "QM" question 2166 9.817403 192.168.3.194 224.0.0.251 MDNS 72 Standard query response 0x0000 AAAA polisy.local, "QM" question 2167 9.817735 fe80::218:ddff:fe04:accc ff02::fb MDNS 92 Standard query response 0x0000 AAAA polisy.local, "QM" question 2168 9.817735 fe80::218:ddff:fe04:a59f ff02::fb MDNS 92 Standard query response 0x0000 AAAA polisy.local, "QM" question 2170 9.818937 192.168.3.200 224.0.0.251 MDNS 72 Standard query 0x0000 A polisy.local, "QM" question 2171 9.819306 fe80::10c6:6196:1ef5:1575 ff02::fb MDNS 92 Standard query 0x0000 A polisy.local, "QM" question 2172 9.819703 192.168.3.200 224.0.0.251 MDNS 72 Standard query 0x0000 AAAA polisy.local, "QM" question 2173 9.819847 fe80::218:ddff:fe04:a59f ff02::fb MDNS 92 Standard query response 0x0000 A polisy.local, "QM" question 2174 9.819847 fe80::218:ddff:fe04:accc ff02::fb MDNS 92 Standard query response 0x0000 A polisy.local, "QM" question 2175 9.820039 192.168.3.193 224.0.0.251 MDNS 72 Standard query response 0x0000 A polisy.local, "QM" question 2176 9.820039 192.168.3.194 224.0.0.251 MDNS 72 Standard query response 0x0000 A polisy.local, "QM" question 2177 9.820054 fe80::10c6:6196:1ef5:1575 ff02::fb MDNS 92 Standard query 0x0000 AAAA polisy.local, "QM" question 2178 9.820741 192.168.3.193 224.0.0.251 MDNS 72 Standard query response 0x0000 AAAA polisy.local, "QM" question 2179 9.820741 192.168.3.194 224.0.0.251 MDNS 72 Standard query response 0x0000 AAAA polisy.local, "QM" question 2180 9.820979 fe80::218:ddff:fe04:a59f ff02::fb MDNS 92 Standard query response 0x0000 AAAA polisy.local, "QM" question 2181 9.820979 fe80::218:ddff:fe04:accc ff02::fb MDNS 92 Standard query response 0x0000 AAAA polisy.local, "QM" question 2185 10.004862 192.168.3.149 224.0.0.251 MDNS 89 Standard query response 0x0000 A, cache flush 192.168.3.149 2186 10.041436 192.168.3.149 224.0.0.251 MDNS 89 Standard query response 0x0000 A, cache flush 192.168.3.149 2383 10.827370 192.168.3.200 224.0.0.251 MDNS 72 Standard query 0x0000 A polisy.local, "QM" question 2384 10.827868 fe80::10c6:6196:1ef5:1575 ff02::fb MDNS 92 Standard query 0x0000 A polisy.local, "QM" question 2385 10.828243 192.168.3.200 224.0.0.251 MDNS 72 Standard query 0x0000 A polisy.local, "QM" question 2386 10.828278 192.168.3.194 224.0.0.251 MDNS 72 Standard query response 0x0000 A polisy.local, "QM" question 2387 10.828660 fe80::10c6:6196:1ef5:1575 ff02::fb MDNS 92 Standard query 0x0000 A polisy.local, "QM" question 2388 10.828791 fe80::218:ddff:fe04:accc ff02::fb MDNS 92 Standard query response 0x0000 A polisy.local, "QM" question 2389 10.829030 192.168.3.200 224.0.0.251 MDNS 72 Standard query 0x0000 AAAA polisy.local, "QM" question 2390 10.829078 192.168.3.194 224.0.0.251 MDNS 72 Standard query response 0x0000 A polisy.local, "QM" question 2391 10.829431 192.168.3.193 224.0.0.251 MDNS 72 Standard query response 0x0000 A polisy.local, "QM" question 2392 10.829451 fe80::10c6:6196:1ef5:1575 ff02::fb MDNS 92 Standard query 0x0000 AAAA polisy.local, "QM" question 2393 10.829557 fe80::218:ddff:fe04:accc ff02::fb MDNS 92 Standard query response 0x0000 A polisy.local, "QM" question 2394 10.829761 fe80::218:ddff:fe04:a59f ff02::fb MDNS 92 Standard query response 0x0000 A polisy.local, "QM" question 2395 10.829830 192.168.3.194 224.0.0.251 MDNS 72 Standard query response 0x0000 AAAA polisy.local, "QM" question 2396 10.829861 192.168.3.200 224.0.0.251 MDNS 72 Standard query 0x0000 AAAA polisy.local, "QM" question 2397 10.830241 fe80::10c6:6196:1ef5:1575 ff02::fb MDNS 92 Standard query 0x0000 AAAA polisy.local, "QM" question 2398 10.830284 fe80::218:ddff:fe04:a59f ff02::fb MDNS 92 Standard query response 0x0000 A polisy.local, "QM" question 2399 10.830501 fe80::218:ddff:fe04:accc ff02::fb MDNS 92 Standard query response 0x0000 AAAA polisy.local, "QM" question 2400 10.830629 192.168.3.193 224.0.0.251 MDNS 72 Standard query response 0x0000 A polisy.local, "QM" question 2401 10.830802 192.168.3.194 224.0.0.251 MDNS 72 Standard query response 0x0000 AAAA polisy.local, "QM" question 2402 10.830802 192.168.3.193 224.0.0.251 MDNS 72 Standard query response 0x0000 AAAA polisy.local, "QM" question 2403 10.831326 fe80::218:ddff:fe04:accc ff02::fb MDNS 92 Standard query response 0x0000 AAAA polisy.local, "QM" question 2404 10.831511 fe80::218:ddff:fe04:a59f ff02::fb MDNS 92 Standard query response 0x0000 AAAA polisy.local, "QM" question 2405 10.831951 192.168.3.193 224.0.0.251 MDNS 72 Standard query response 0x0000 AAAA polisy.local, "QM" question 2406 10.832119 fe80::218:ddff:fe04:a59f ff02::fb MDNS 92 Standard query response 0x0000 AAAA polisy.local, "QM" question 2409 10.960505 192.168.3.149 224.0.0.251 MDNS 89 Standard query response 0x0000 A, cache flush 192.168.3.149 2410 10.960887 192.168.3.149 224.0.0.251 MDNS 89 Standard query response 0x0000 A, cache flush 192.168.3.149 In fact, during the entire test, there was only one single packet on the network from the EISY -- its response to the UDP query that also went out when the IoX Finder was launched: No. Time Source Destination Protocol Length Info 1317 5.143901 192.168.3.41 192.168.3.200 UDP 1230 20036 → 20036 Len=1188 In any event, whether the EISY is supposed to support responding to mDNS queries or not, it probably would respond exactly the same way it's responding to this UDP query... with the IP address it thinks it knows -- 0.0.0.0 -- so that really does need some attention from UD I think; then we'll probably see this function reliably. Here's the UDP query that the EISY is responding to, BTW: Frame 1316: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) on interface \Device\NPF_{3EDCBF5C-B1CB-405D-A067-D90E0C99C4C2}, id 0 Section number: 1 Interface id: 0 (\Device\NPF_{3EDCBF5C-B1CB-405D-A067-D90E0C99C4C2}) Encapsulation type: Ethernet (1) Arrival Time: Oct 31, 2023 13:59:23.776860000 Eastern Daylight Time [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1698775163.776860000 seconds [Time delta from previous captured frame: 0.020832000 seconds] [Time delta from previous displayed frame: 0.020832000 seconds] [Time since reference or first frame: 5.143686000 seconds] Frame Number: 1316 Frame Length: 66 bytes (528 bits) Capture Length: 66 bytes (528 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:ethertype:ip:udp:data] [Coloring Rule Name: UDP] [Coloring Rule String: udp] Ethernet II, Src: Dell_d9:16:b9 (a4:bb:6d:d9:16:b9), Dst: Broadcast (ff:ff:ff:ff:ff:ff) Destination: Broadcast (ff:ff:ff:ff:ff:ff) Source: Dell_d9:16:b9 (a4:bb:6d:d9:16:b9) Type: IPv4 (0x0800) Internet Protocol Version 4, Src: 192.168.3.200, Dst: 192.168.3.255 0100 .... = Version: 4 .... 0101 = Header Length: 20 bytes (5) Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT) Total Length: 52 Identification: 0xd949 (55625) 000. .... = Flags: 0x0 ...0 0000 0000 0000 = Fragment Offset: 0 Time to Live: 128 Protocol: UDP (17) Header Checksum: 0x0000 [validation disabled] [Header checksum status: Unverified] Source Address: 192.168.3.200 Destination Address: 192.168.3.255 User Datagram Protocol, Src Port: 20036, Dst Port: 20036 Source Port: 20036 Destination Port: 20036 Length: 32 Checksum: 0xf369 [unverified] [Checksum Status: Unverified] [Stream index: 45] [Timestamps] UDP payload (24 bytes) Data (24 bytes) Data: 4255524e5200000000000000000000000000000000000000 [Length: 24] 0000 ff ff ff ff ff ff a4 bb 6d d9 16 b9 08 00 45 00 ........m.....E. 0010 00 34 d9 49 00 00 80 11 00 00 c0 a8 03 c8 c0 a8 .4.I............ 0020 03 ff 4e 44 4e 44 00 20 f3 69 42 55 52 4e 52 00 ..NDND. .iBURNR. 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0040 00 00 ..

So I fiddled some today determined to see what's going on. When the IoX launcher starts up, the EISY is responding to a broadcast UDP query. But it's responding with the address that I see in the UI... https://0.0.0.0:8443, which is most likely being ignored by the IoX Launcher client so nothing gets displayed. If UD can get the reason behind 0.0.0.0 instead of the real IP of the EISY appearing in that field in the UI fixed, we'll probably see resolution of eisy.local by the IoX Finder app fixed, too. 0000 a4 bb 6d d9 16 b9 00 21 b9 02 65 bf 08 00 45 00 ..m....!..e...E. 0010 04 c0 18 df 00 00 40 11 d5 0c c0 a8 03 29 c0 a8 ......@......).. 0020 03 c8 4e 44 4e 44 04 ac 35 ee 4e 45 54 42 04 00 ..NDND..5.NETB.. 0030 00 00 1f 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0090 00 00 00 00 00 00 00 00 00 00 00 21 b9 02 65 bf ...........!..e. 00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00c0 00 00 00 00 00 00 00 00 00 00 00 00 65 69 73 79 ............eisy 00d0 3a 3d 68 74 74 70 73 3a 2f 2f 30 2e 30 2e 30 2e :=https://0.0.0. 00e0 30 3a 38 34 34 33 2f 64 65 73 63 00 00 00 00 00 0:8443/desc..... 00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 01a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 01b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 01c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 01d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 01e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 01f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0220 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0230 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0240 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0250 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0260 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0270 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0280 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0290 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 02a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 02b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 02c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 02d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 02e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 02f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0300 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0310 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0320 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0330 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0340 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0350 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0360 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0370 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0380 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0390 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 03a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 03b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 03c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 03d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 03e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 03f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0400 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0410 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0420 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0430 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0440 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0450 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0460 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0470 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0480 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0490 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 04a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 04b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 04c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..............

I received my EISY today and upgraded from an ISY-994. In general things went fine. But one thing that's getting a bit annoying is the lack of eisy.local functioning reliably, and how the EISY itself rarely shows its DHCP-obtained IP address in the Configuration / System page. In the middle of me installing various things, suddenly I found IoX Finder showing both my saved IP-based URL and the eisy.local address for the same EISY. And my initial work with configuring the Polyglot server was using the eisy.local:3000 address. Then, in the process of finding several node servers wanting some of my devices to have persistent IPs I was configuring that in the DHCP server of my router and rebooting them. And then I remembered it was my intent to move the EISY to the original IP I used for the ISY-994, so I updated that in the DHCP configuration and rebooted the EISY. The EISY comes up at the new IP, but now eisy.local doesn't resolve to anything, IoX finder doesn't see anything but the entry I manually entered/saved, and nothing helps. While I wasn't paying close attention, there was a time the IP address showed up on the Configuration / System page, and that I believe correlated to when eisy.local also was working. When I first began the migration, including pre- and post- updating packages of the EISY it was showing 0.0.0.0 on the Configuration / System page. Reading through this thread I see an earlier version seemed to have some similar problems with regard to showing 0.0.0.0 as the IP. Worth noting is the Help / About page shows the correct IP and when eisy.local was working, Help / About showed that address in "My URL". My first thought is wherever Configuration / System gets its info to display, perhaps the IP during initialization hasn't been received from the DHCP server (someone who posted logs has log lines showing a 0.0.0.0 IP initially). Anyway, I'd love to have the eisy.local address be reliably functional, but even if not, the IP should certainly show up in the admin console properly on that page (and all the other network configuration items like subnet, gateway and DNS which always show up blank). I have rebooted and also gone through shutdown/ power resets and nothing seems to bring the IP back in the GUI or makes eisy.local work again. The DHCP server shows the device getting the correct IP. Not sure what else I might look at to try to diagnose this. But otherwise everything in my setup as far as Insteon devices and programs goes, which is all I'd had before, is functional after the migration. isy-5.7.0_5 Name : isy Version : 5.7.0_5 Installed on : Thu Oct 26 16:51:50 2023 EDT Origin : misc/isy Architecture : FreeBSD:13:amd64 Prefix : /usr/local