Jump to content

Support Thread for IoX 5.7.0


Chris Jahn

Recommended Posts

Posted (edited)

Hi I show [Ticket #22965] Poloy dropped off line Oct 20, cannot get reconnected

 

The original ticket and 2 additional informations of my progress

Edited by Irakandjii
  • Like 1
Posted

My thanks to UD.  The system is back up and running!  It was not something I could have done, so no point in elaborating other that it is fixed in an exceptionally professional manner

  • Like 4
Posted
On 10/26/2023 at 9:09 PM, DSwallow said:

nothing seems to bring the IP back in the GUI or makes eisy.local work again

Try deleting the .state files from UDI. Also clear Java Cache (temporary internet files) and download a new start.jnlp file from the UDI site (click on "My ISY" on the top right). 

https://wiki.universal-devices.com/index.php?title=Main_Page#Admin_Console_Minimized/Invisible_and_Cannot_be_Restored

(not the same problem, but it's where stored information is kept)

The issue of reliably getting the friendly URL to display (I've found anyway) is a local network issue. Either router or device times out during the handshake and cannot get it to reliably show. I'm sure anybody with more network experience will contest this, but from personal experience I've seen some routers never auto find, sometimes auto find, or always auto find the URL. Because of the issues people have had over the last year I've tested with some "old" routers I had access to and the process was fairly inconsistent. Some of the worst offenders were "mesh" router systems. 

Also, some people have reported that IoX Finder window sometimes will report both the IP and the Friendly URL address. That's fine, and has been confirmed as "normal" by UDI. Both go to the same device and since they are discovered automatically are unable to be deleted. 

Once you have either/or in the IoX Finder window you can SAVE the list locally and then LOAD it should the list ever not populate. 

On 10/26/2023 at 9:09 PM, DSwallow said:

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.

I think the steps above might help this issue too. At least clearing the Java Cache and starting admin console fresh might help. 

One last question - are you experiencing any of this on a laptop that you sometimes use outside of the home/network or with VPN? I've found if I'm on my laptop and travel with it and try to log into the ISY my "local" addresses will drop off the list while I'm gone. Typically they will auto discover next time I'm in the home network. 

  • Like 1
Posted

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         ..............

 

Posted (edited)

I think you may be having trouble with a service called mDNS [multicast DNS], which uses port 5353 IN/OUT to create local records to simulate a DNS server on the local network. I found this was causing me trouble related to the eisy.local:8443 name resolution. If you have a local host firewall, it may be blocking these ports and services.

Windows svchost.exe is directly involved with this.

You can search for mDNS and find many articles, but here is a reasonable post:

https://stevessmarthomeguide.com/multicast-dns/

Rob

Edited by RRalston
added svchost.exe info
Posted (edited)
20 minutes ago, RRalston said:

I think you may be having trouble with a service called mDNS [multicast DNS], which uses port 5353 IN/OUT to create local records to simulate a DNS server on the local network. I found this was causing me trouble related to the eisy.local:8443 name resolution. If you have a local host firewall, it may be blocking these ports and services.

You can search for mDNS and find many articles, but here is a reasonable post:

https://stevessmarthomeguide.com/multicast-dns/

Rob

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                                             ..

 

Edited by DSwallow
Posted

@DSwallow seems like you've got more experience to try to troubleshoot stuff and digging deeper than most would go.

If this is an issue causing you not to be able to access the eisy then I would suggest you open a support ticket for specific help from UDI rather than user-to-user support mostly found here. Their troubleshooting process might be better suited to fixing what might be causing this for you. 

https://www.universal-devices.com/my-tickets

Posted
1 hour ago, Geddy said:

@DSwallow seems like you've got more experience to try to troubleshoot stuff and digging deeper than most would go.

If this is an issue causing you not to be able to access the eisy then I would suggest you open a support ticket for specific help from UDI rather than user-to-user support mostly found here. Their troubleshooting process might be better suited to fixing what might be causing this for you. 

https://www.universal-devices.com/my-tickets

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

Posted

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.

Posted (edited)

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


 

Edited by DSwallow
  • Like 3
Posted (edited)

Daylight Saving Time ended last night. Woke up this morning and none of the stuff that should have happened happened. Programs not running. Open admin console and find that all 300 programs are set to 'Not Enabled'.

Required manual intervention of 'Restart IoX' to correct.

Edited by Illusion
Posted
8 minutes ago, Illusion said:

Daylight Saving Time ended last night. Woke up this morning and none of the stuff that should have happened happened. Programs not running. Open admin console and find that all 300 programs are set to 'Not Enabled'.

Try power cycling your unit. IF that doesn't work, try restoring a backup.

Posted (edited)
6 minutes ago, btreinders said:

My Polisy has sunrise and sunset off by an hour this morning as well.

I would suggest power cycling Polisy. Mine was fine this morning.

Also, verify you are on the latest build, v5.7.0_5. 

You can run:

https://xxx.xxx.x.xxx:8443/WEB/sysconfig.txt

Substitute your IP address for "x". You may need to click through some warnings. You can use Ctrl + F to search for ISY to locate your version.

Edited by DennisC
Spelling + added info
Posted

Similar issues with my eisy after the time change.  Programs quit running and I had to manually trigger them and they had been running since 11/3 6:55 after I installed PG3 3.2.14 and rebooted.  I rebooted again this AM and what was interesting is that UD Mobile reported the update was complete, again.  But it appears the reboot after the time change fixed everything.

Posted
4 hours ago, btreinders said:

On the latest version for sure and just pulled power for a minute and then booted it back up.  No joy.  Still has both one hour off.  Has them both an hour early.

In response to your post I looked, and sure enough, my sunrise and sunset are both an hour early...

Posted
14 minutes ago, Illusion said:

In response to your post I looked, and sure enough, my sunrise and sunset are both an hour early...

I had a similar problem long time ago for my location in Albuquerque. UDI had to change the rules. 
 

The list of Locations shown when selecting the AC Change Location button is wrong for Albuquerque. It shows the Albuquerque Daylight Saving Rule is America/Phoenix, it should be America/Denver. Phoenix does not change to Daylight Saving. I wonder when that rule was changed. I've never had this problem before.

 

Posted

Yep, I just went & looked at mine and they are both an hour early too.  I'm looking at a photocell (actually the average of 2) for my exterior lighting control so this shouldn't hurt me as my system stands at the moment.

Posted

Hello all,

Apologies for the problems. The UI in the Admin Console is definitely incorrect. This said, the program should be fine. Does anyone have any example (screenshot) of programs having the wrong next runtime (ether sunset/sunrise or both)?

With kind regards,

Michel

  • Like 1
Posted

@Michel Kohanim  I didn't take a screen-shot  :(  What I encountered this AM is my exterior lights didn't go off, and when I dug into it all the last & next run times were blank.  I look at a photocell & turn the lights on and off.  Somewhat similar to the problem I had when programs flagged run at startup never ran that Chris took a look remoting in and saw enough to understand and it appeared to be fixed now in earlier updates.  But after I rebooted it fixed itself this time.  They all worked Fri. night & Sat. AM & PM without intervention but something to do with the time changed cleared all the last/next run times...  ???

Posted
9 hours ago, btreinders said:

My Polisy has sunrise and sunset off by an hour this morning as well.

Checked my Polisy, my display is off by 1 hour as well.

Guest
This topic is now closed to further replies.

×
×
  • Create New...