Javi

This is a bug in UDM for Android API 35 (maybe 34 also), will be fixed in the next release I'm not sure I follow, but I think the same can be done by removing the variable and program from the equation?/ If the color is associated with the temperature in the display node the use calculation in UD Mobile. see https://wiki.universal-devices.com/UD_Mobile#Comparison i.e Something like if status >= 0 degrees set color to blue, if status is >= 55 degrees set color to green, and if status is >=75 set color to red. Where >=75 is evaluated first, 55 second, and 0 third.

No. There is a content length limit for remote connections to Plugins, which may be the cause. If you have setup local connections in UDM, try when local, may require swiping app from recents to clear cache.

These are benign errors for the user, but useful for Node Server developers. The NLS file has a "ST" definition which could not be parsed. Appears the "NAME" is missing or is something other than "NAME" https://wiki.universal-devices.com/Polisy_Developers:ISY:API:NLS:Language_Support ST-<nodedef.nls>-<st.id>-NAME GEN-<nodedef.nls>-<st.id>-NAME ST-<st.id>-NAME e.g. ST-ST-NAME = Lamp ST-MYDRAPES-ST-NAME = Drapes

Ok, the error is consistent No network access or the Android OS is not allowing UDM to access the internet. UD Mobiles target version changed in August from 34 to 35 so this may be related. Along with a deprecated network check function. Although I don't see any of these issues on my Pixel, the deprecated function may be the cause. Added to our list, but may be a couple weeks before it makes it to production. Notes: Every time UDM encounters no internet it waits 30 seconds multiplied by the number of previous checks up to 6. However it looks like there is a feature(?) in the app which cause the command to be sent even without internet after the 450000 (6 loops) is reached. Looks like it is held in the network queue until the OS gives the app internet access, when the app is opened.

What is the message in the UDM Geofence log this time around?

I use a Pixel 9 Pro on 16 also, so should be similar. You described 3 different errors which are not necessarily related. 1) there are no specified commands for this geofence trigger” > The Geofence does not have commands for the Trigger Type (Enter Exist). Maybe this was fixed when you reentered the commands? 2) No network > The app did not have access to Internet when it tried to execute a network call, then says it will reattempt in 30 seconds. 3) Reattempt after 30 seconds did not happen, but the app did reattempt after it was opened. This is either due to the app crashing in the wait period or the Android operating system stopped the app (i.e. Battery Saver). The latter seems more probable unless you received a crash message. For issues 2 & 3 sometimes the phone needs to be restarted, not sure why but has worked for other users.

Makes sense. There are 2 issues, Property Value Formatting and Missing Property Values. We are still looking into the cause of both issues. Missing Property Values has been replicated on Portal Connections when going through EisyUi***, EisyUi local, and Admin Console Local on port 8443. ***Firmware 6.x and greater use EisyUi for portal connection and the Admin Console when Local on port 8443. Local connections on UD Mobile uses port 8080 so does not use Eisy UI, same with Admin console when using port 8080. If using UD Mobile on Portal clicking into the Device Dashboard will perform a new Property Value Query. While not ideal it is the current work around until fixed.

Did you change phones or have a phone firmware update in the recent past? This is usually caused by the Android operating system not allowing the app to use network or battery when the screen is off. Are the permissions correct? see https://wiki.universal-devices.com/UD_Mobile#Permissions_Android

UDM > Settings Tab > Geofence, Click on Geofence and verify Enter and Exit commands are correct.

Can you verify the geofence commands are set? It sounds like they may have been removed, maybe due to a failed synchronization.

I believe this is due to a bug in iOS Beta (test flight) version. Should be fixed in the next update.

Please open a ticket

Did you synchronize?

Currently there are no "tabs", but is on our list. There are "Folder" Favorite Types, which also support a display node. See: https://wiki.universal-devices.com/UD_Mobile#Type

I don't think they are errors which will cause issues. It is likely an invalid format in a human readable name for a node server. The next version will list the Family (i.e. Node-Server, Insteon, etc) and instance (i.e. node server slot). Please post the same screenshot when they Family and instance are displayed and we can investigate further. Same as:

I don't think they are errors which will cause issues. It is likely an invalid format in a human readable name for a node server. The next version will list the Family (i.e. Node-Server, Insteon, etc) and instance (i.e. node server slot). Please post the same screenshot when they Family and instance are displayed and we can investigate further.

See the custom toggle example. https://wiki.universal-devices.com/UD_Mobile#Favorite_Examples Basically you want the "Display node to show the sensor and the "Command" to be a program you create which triggers the door. Or if the door only supports toggle, you can trigger the door directly in "Command".

We have a couple of reports of the same issue. We are still investigating.

Saving to the controller is on our list. UDM was built starting with ISY994 which could not handle saving the UDM configuration.

Some of the synch changed so possible app error. However more likely the NOde Server in slot 5 is not configured correctly.

Should be fixed in the latest release.

I think it may just be unintuitive, #71A6FA is not the default (ios version tint color) it is an example. Try pressing the delete button at the top of the color edit dialog.

Ok thanks for trying. Please open a ticket. Title it "Formatted values not in subscription, exists in Admin Console" Include your UUID, firmware version, and link to this topic.

Nothing to report, time constraints on my side. I don't work with Python or Node Server Development frequently so would likely need a few days to figure it out. With that said, it is open source so it can be modified/copied by anyone willing.

eisy. Formatted Status values are published by eisy, so it's not app related. Anytime a node server is installed a reboot is required before eisy will publish formatted values (this is written in the alert prior to synchronization). This was required in 994 due to lower processing/memory. Sometimes a node server reinstall/update will trigger this requirement. This requirement should finally be removed in firmware 6.0.0 If reboot does not correct the issue then there is another problem. The app will do a formatted status values lookup in dropdowns, so if dropdowns have formatted values and status does not (after reboot), then you may to open a ticket.