Javi

It is a benign error, invalid parameter name mapping for i3Keypad. Will need to be fixed in the next firmware update.

Added summary view toggle to programs page in next release to show all. This already exists in nodes, click the IOX Home Group (or whatever name given to the controller) this shows all Node Status values.

Known Issues: Ampersands in Resource (Email/Notification/Network) may cause program load to fail. As a work around remove ampersands then save in Admin Console. Records will be sanitized in the next release.

understood

That is the idea.

The plugin is due for a rewrite. I upgraded my hardware to v3 recently so will take a look when I get some free time. Currently don't use any OS hardwired sensors, what type are you using?

Periodic backups is being considered as a portal feature.

While having a tablet unlocked would allow a user eventual access, you could make it difficult. Create your keypad. Map numbers to variables/programs. E.g have a var for key entered and a var for keys entered (requires some math). Then a program to do math and update keys entered var. Another program which does alarm functions when keys matches. Hide the alarm nodes, keypad programs and keypad vars in UDM.

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.

It may be possible if your vehicle had the BLE broadcasting device and the reader was at the gate, but due to latency, it may be easier/quicker just press a button or asking Android Auto's Google Assistant to open the gate/door. While BLE works great for some location tracking situations, like when there are a high number of receivers (iTags, everyones iPhone is a receiver), it would likely not work well when a phone, inside the vehicle, is trying to read signals outside the vehicle. The periodic phone wakes are too far apart when traveling. Ble works in line of sight, no obstructions, for 30 - 300ft (in my test even 30 ft was difficult to obtain). There is an old thread somewhere on the forum where I tested iBeacons for indoor location tracking, just facing away from the device with my body in between the phone an the BLE device in the same room caused the signal to disappear. I found that reading WiFi BSSIDs (on Android, blocked by iOS), worked the best but this was a huge drain on battery. The best custom Geofence solution is in our Android app, where you can force GPS poll at intervals, so the user creates multiple geofences and increases or decreases polling intervals based on which fence they have entered or exited. Because this is a GPS update the lack of cell towers and wifi access points is not as pronounced. This has been a solution for other users in rural areas. Also in both iOS and Android if are running maps in your car this is already getting GPS updates which the OS uses for Fencing, so this eliminates the need for custom polling. However if you have poor internet the fences can not send that trigger to eisy.