Javi

Scenes do not have status, they are more like a preset. The trigger would need to be the status of a device or state variable. A variable can be used as status, then a program with a wait can be used. I.e. if var_x = 1 turn on light, then wait 5 min, run the same program. If the variable changes during wait the program will stop, and else will be run, so else should turn off the device.

What Favorite Type has this behaviour? This has been reported before but I could not replicate, but it was possible I was using "Default".

Factory reset = reset eisy to same state as it arrived from factory. The same configuration tab will show if Z-Wave and/or Z-Matter is enabled. For anyone else reading this both must be enabled for Z-Matter, if not using automatic detection settings.

As far as I know it is supported, but will not get any more updates. It must be enabled in Admin Console Configuration Tab, ZMatter must not be enabled, if it is or ever was then factory reset is required.

Login must have happen at least once to receive notifications, if not Portal would not know your device's ID and could not send push notifications. If the user opened the Notifications Tab during the same session as login it may have caused the Device ID to be added twice.

Issue is caused when a mobile device is added to the user's Portal account twice within milliseconds. I believe the cause is a double refresh on the UDM iOS Notifications tab which races to add the Mobile Device to Portal. If the user logged into portal then opened the notification tab in the same session (without leaving app) the double refresh may have caused the Mobile Device to be added twice. If the user left the app, upon return then there is a single notification refresh which adds the Mobile Device to Portal, thus preventing the issue on double refresh when the user enters the Notification Tab. The next version of of UDM for iOS will fix this race condition. We have also made a correction to Portal to try to fix the issue for other users, although the correction may not happen until after the saved notifications have expired (If I remember it is ~3 months).

Issue found and corrected. This may require delete all notifications as some users had duplicates.

Is the "big number" always 100? Are all notifications acknowledged (no circular indicator next to the notification icon)?

I can't replicate, please open a ticket and include the eisy's UUID so we can check your account.

Do you have, or have you ever had multiple ISY Portal Accounts?

Please upgrade.

Sort/search is on our list, but no time frame. What is your firmware? If not the latest please update, as earlier versions had a bug causing missing status on remote connections.

UD Mobile has edit locks which should/could prevent users from accessing some items in UD Mobile, such as edits (show/hide), Admin Tab, and Settings Tab. The basic concept is to hide nodes, status, and/or commands you do not want shown to the user then lock edits with a pin. Now the user will not see hidden items and cannot get into edit mode without the pin. See https://wiki.universal-devices.com/index.php?title=UD_Mobile#Edit_Locks We are in the process of updating the App's User Interface so it's possible some items may not be locked due to the updates. If something in found please let me know and I'll try to fix soon. I removed the ability to hide the entire system on the Home Tab as too many users hid the system from themselves causing many tickets.

This Log should correspond to A program (IF) Schedule is being evaluated. If this program is not triggering the device and there is nothing else in the log, then off is likely not triggered by eisy. What is the Make/Model of switch?

This shows that an event happened which set the status to 0 (off). More logs before this event are needed.

Thanks but I do have one. The issue is time as the flex device I have is connected to a serial cable and would take time to reset then reconfigure for serial connections after testing. I the new version does not work please attach the Node Server's Log.

Added iTach Flex definitions, although I can not test. Please reinstall, I did not update version as this change should not affect existing users. If there are any errors please attach log.

Try factory resetting the bulb from the hue app first.

While I cannot replicate, I'll keep this in mind. The Custom Configurations are being migrated to improve performance so I don't want too much time with something that will change in the next few weeks. I'll try to post here when completed.

The local network option in UD Mobile may not work well in this situation, the original implementation used the WiFi network's BSSID but it only worked on Android, iOS does not expose the BSSID to apps so we are limited to the SSID. We understood that there was a possibility for conflict, but it would be rare. My suggestion, is to remove the SSID in UD Mobile for the location where you spend less time. The Local Connection are not required and override default settings.

That is possible, and is easy to test. Swipe app from recents and reopen.

Ok, great.

I cannot replicate this behavior, but located a bug yesterday which may cause the issue if you have multiple node servers with nodes containing the same status ID. Do you have multiple weather Nodes Installed?

No, it appears the issue started late Friday or early Saturday and was isolated to ISY994 and the Portal "event subscription" (status updates). The issue was caused by updated security rules which prevented the older hardware's ability to send status updates.

Adding new customizations to fill in the ID gaps will fix the UI issue in Admin Console.