Javi

It's still on our list, but can be done from the Admin Console.  
Scenes in version 5.x are much more complex than Scenes in 4.x (see the 5.x fan example).  Also for insteon the Scene information is written to the Controllers/Responders so may take some time depending on the number of changes.
Each Scene-Controller-Settings has an on-level setting for each responder in the Scene.  The Scene-Settings also has an on-level setting for each responder in the Scene.  So changing the on-level for each Responder manually may not be intuitive or may not work as desired without changing many properties.
So, if you set the Scene-Settings on-levels' for each responder, it will only work if you trigger from eisy. Setting on-levels from a Scene-Controller-Settings will only work when triggered from that Controller.  
What are you trying to do?   There may be another way to accomplish the same without getting too deep into the settings every time a change is needed.

Should be fixed in the next version Android 1.2.28 and iOS 1.2.6.
From what I can tell this is only an issue with displaying the formatted value, the mapping should still work.

Understood, and yes the numerical IP is more reliable than eisy.local.  We have encountered home networks which stop routing to dot local and Mobile devices which stop routing to dot local.  Usually corrected by restarting the Router or the Mobile device. 
With regards to reset local credentials: They are managed by iOS keystore so loss of local creds should correlate to lost remote creds.  The app will use "admin" for local username or password if it cannot obtain a stored value from iOS keystore.  
iOS Keystore may (but not always) loose values or the app may lose the key if the app is uninstalled,  backup is imported (if the controller ID is not the same), or the controller is recreated (deleted then added) in UD Mobile.  Being as keystore is managed by iOS there are a few reasons (such as corruption or security related change on the device) that keystore may fail to return a value, but I think this a low probability.
So there are a few ways keys or values may be lost. My guess is one of these things happen and the app prompted to re-enter remote credentials (i.e. login) at some point in the last 2 months.  This is the only report I have for this issue without the user changing something, so I'll keep an eye out. Let me know if it happens again without an import or reinstall.

Found issue, fixed in next version.

Reference https://github.com/JavierRefuerzo/iTach_IR_Node_Server?tab=readme-ov-file#general
Only one configuration is needed per device (not per code). Please post the value input into the node server, it's possible they changed the format so the Node Server cannot parse.  Being as there is only a single value the delimiter between codes may not match, if I remember correctly it is a double space or maybe a double new line.

This should work assuming they are the same platform Android/iOS.
Are they the same platform Android/iOS?

Not changes, and I use android and it triggered this morning.  Have you tried restarting the Android Device?  
Also verify Location is enabled on Android Device. UD Mobile has location permission.  And the Geofence inside UD Mobile is enabled.
There is also a bug on some android devices/versions which requires the "(Experimental) Force Geofence updates.." to be turned on.  So you may want to turn this on to see if it starts working
 
This was never implemented on Android, still on my TODO list

Not in app, currently only at the top of Admin Console.  Is on our very long TODO List.

Was this resolved in the ticket?
Notes: Cancel any alerts/warnings/sync-request in controller settings. Scroll to the bottom and press clear UUID.  Be sure to update Remote and Local URLs to point to the new controller.

The UDM Synch error is fixed in the next app update.  It can be ignored until that time as it is only stating there are no matter devices.

UD Mobile > Notifications Tab > Menu > Mobile Devices/Groups > Groups > System Notifications.

If you already upgraded you don't need to press force upgrade.

http://ipaddress:8080  then the path i.e. /rest/history/etc

Check out the custom toggle example. A favorite which shows one node as status and executes a program (or node command) when pressed.  Search the forum, Others have posted about setup of the same the same.
https://wiki.universal-devices.com/index.php?title=UD_Mobile#Favorite_Custom_Toggle

Currently not possible, but similar requests have been made in the past.  i.e Tab Tiles.  
Tab Tiles are on the list but not sure when I'll have time to implement.

See the custom toggle example https://wiki.universal-devices.com/index.php?title=UD_Mobile#Favorite_Custom_Toggle
In short the Display Node and the Command do not need to be related, but the command should cause the Display Node to change.  The command should be a Program Run IF so it holds all logic related to the toggle.

It's due to how insteon processes scenes.  A command is not sent to individual devices it is sent to the Scene. A Scene has a predefined rampRate and onLevel (a preset). An Insteon Scene is more like a preset than a controlled group. For eisy to do this it would need to send a command to each device which would be out of sync (the same as sending a command to each device in a program).  Not only would be out of sync but would likely fail to trigger some devices due to traffic.
So to achieve what you are looking for you have two options.
1) (recommended) Create a new scene with all devices as responders, set the level to 10.  Then trigger the new scene from the program.  This will allow all devices to come to the specified level at the same time.
2) (not recommended, but this is how it would work if you physically held the switch to a desired on level) Trigger the Fade Up on the scene then Stop after some time.

The app error is a bug in the app.
We have submitted a new version to both app stores. Still awaiting approval from Google/Apple.

Thanks for testing,  Currently the chart automatically adjust to show the last few changes, however there is a bug and the time on the chart is not correct. In your case the time is likely closer to the current time.
Adding this to favorites is on my list. Along with other improvements.

There used to be, but it was inadvertently removed during a UI refresh.  Adding it back is close to the top of the list of To-Dos.
It was similar to Favorites Move to Folder. 

The Favorites page does not separate by controller, nodes from multiple controllers can be displayed on the same page. This is by design, in case users want to view status of multiple properties at the same time. 
Users can create Favorites Folders if there is a need for separate favorites pages.  This can be for seperate properties or any other reason.

As far as I know this should only happen after opening a Node's Dashboard.  If you swipe app from recents does the Home tab still show this error?  Does it only start showing the error after clicking a specific Node?
If both answers are true go to the node and find the status value which is set to a chart, then change it to "Default" or another type of view.  
If this does not correct the issue, or the answer to the questions above are false then please open a ticket and include a ZIPPED COPY of the UD Mobile Backup file so that we can investigate.

That look correct, RUN IF (Set RUN IF) should be triggered on geofence enter. 
The program itself needs to be disabled or it will run at the time in the IF condition.
This can be tested when the time is valid by pressing Trigger Enter Command.  Note that geofences may take a couple of minutes to trigger so the radius may need to be larger.

It appears move to folder was left out after the latest app refresh.  We will try to re-enable this feature in an upcoming version.

Action buttons will be shown above favorites in next update.  Bug introduced when we added transparent (scroll through) navigation and tab bars.