Javi

UD Mobile cannot restore eisy, this can only be done from admin or eisyui (web). This is an issue with Local synchronization on iOS only. iOS doesn't allow a http header that prevents a firmware bug. So other non-iOS clients are not affected. iOS devices synchronizing through portal are not affected.

The IP Address and WiFi SSID

The app should have prompted to backup before removal, if you did restore the backup. The issue does not require cell service, only that the syntonization is done through Portal. So temporarily removing the local connection from UD Mobile settings will fix, UDM will still uses your home Wifi. The alternate method is to do on cell service which forces a remote connection as not on WiFi. The cause: There were recent changes to iOS (OS) which caused significant hanging in remote sync, part of this was due to UDM trying to catch a firmware bug during synchronization which I thought was fixed years ago but the workaround remained so was no one noticed it was not fixed. When the catch was removed to fix the remote synchonization hang, We noticed the issue was never fixed in firmware. A fix will be in the next firmware version, however because most of our users use the remote sync, it is preferred to not revert the workaround in UDM as sync would hang for most users as they use remote.

No need for cell service, it just needs to go through portal. Delete the local IP Address until the next firmware update.

ISY994 is obsolete, so it is out of our support timeframe. However it is very likely the SD card has gone bad. If you have backup this may be the easiest/quickest repair.

Yes

Will be fixed in next firmware update 966b1b. This is a networking error/bug when requesting Node Server Profiles. Portal Server is catching the issue, app was also caching the issue in the past but this caused slow synchronizations due to iOS not allowing connection-close header.

We had another report, I could not replicate on the remote connection, but did replicate on my controller using the local connection. Looking into the issue now. Temporary solution is to remove the local connection settings or synchronize on cell connection.

"with success" or without? If without please open a ticket, I can't replicate and no other reports.

Update: To fix this issue synchronize over cell (not wifi) OR remove the UD Mobile Local Connection settings. Remove Local Connection Settings from Home Tab > Controller Settings. Disregard any requests to synchronize. Scroll down to Local Connection Settings then and Expand the Settings. Remove the Local IP Address and then remove any Local Networks from the System Network Relations section by pressing the trash icon next to the setting. Finally Save at the top right. The issue does not require cell service, only that the syntonization is done through Portal. So temporarily removing the local connection from UD Mobile settings will fix, UDM will still uses your home Wifi. The alternate method is to do synhronizaton on cell service which forces a remote connection as not on WiFi. The cause: There were recent changes to iOS (OS) which caused significant hanging in remote sync, part of this was due to UDM trying to catch a firmware bug during synchronization which I thought was fixed years ago but the workaround remained so was no one noticed it was not fixed. When the catch was removed to fix the remote synchronization hang, We noticed the issue was never fixed in firmware. A fix will be in the next firmware version, however because most of our users use the remote sync, it is preferred to not revert the workaround in UDM as sync would hang for most users as they use remote.

Go to the controller settings and enable programs at startup. https://wiki.universal-devices.com/UD_Mobile#Program_And_Variable_Settings

Check the admin console, it is likely out of sync also. If this is insteon it is likely line noise or plm going bad.

@SHM Please open a ticket, included your UUID. I have a few reports of synchronization hanging, but cannot replicate. Also let us know if this is Android or iOS.

Geofencing has logs saved to the phone. So if these have never been checked it is worth looking at, it could be a simple error. Always use maps (Android Auto/ Apple Car Play or whatever they are called now) when driving to force GPS lookup which will propagate to fences. All nodes have status change history saved in eisy as of 6.4.x. In UDM change the property type to charts. So if the device you add is a node you can see state change history with timestamps I think someone mentioned LoRa (e.g. yolink), should support much longer ranges than BLE. I would not use BLE for this situation.

No need to enter your WiFi credentials (given to the device by android OS). Bluetooth WiFi commissioning now happens entirely on the Mobile device instead of passing through to eisy, which had latency issues causing timeouts in the matter stack, so hopefully less WiFi commissioning failures.