Javi

Hi, this is very high on our list, with a new firmware implementation in 6.x. Until that time it can still be done with the following urls. // Deletes a door lock user code e.g. /zwave/node/ZW002_1/security/user/<userNum>/delete // Sets a door lock user code e.g. /zwave/node/ZW002_1/security/user/<userNum>/set/code/3511 Although these locks do not validate the user id was saved or changed, so still requires manual check.

I believe you have already opened a ticket, if not please open one for diagnostic.

@Techman , I think it is fixed in UDM for Android 1.5.3. Not yet released, likely next week. please let me know if issue persists in that version.

Unless you intended to have 2 instances, the one not linked to any of your programs should be removed.

If on the latest versions please open a ticket. Not sure, aside from missing status values does a screenshot show the issue? If you have multiple controllers have all been synchronized?

The message is due to NO node definitions found for the Plugin Slot Number (instance). Synchronization changed in the last few versions, So possible there is a bug somewhere. new Synchronization should be much faster. Requires at least 6.0.3 if on Firmware 6.0.x. If there is a functioning plug-in that slot, and synchronized on 6.0.3 or greater please open a ticket so we can investigate.

Do you get synchronization errors? Any other errors? Have you synchronized? There should have been a message about synchronization being required in one of the last few versions.

There is an issue with The node server in slot number one. Is it being used? Is it running?

I have these locks also These locks do not conform to the Z-Wave Standard. Any lockup of the physical device would not be caused by eisy, so the device may be starting to malfunction in addition to compatibility issues. See the following to "fix" the compatibility issue: https://wiki.universal-devices.com/UD_Mobile#Schlage_Locks

Ok, thanks. Responded to your ticket.

If is -1 then it can be reused, if not then it cannot. if none are -1 then no others can subscribe which will cause issues. They should clear themselves but could take some time. See page 10. https://docs.universal-devices.com/developers/docs/3.1.1/ISY-WS-SDK-Manual.pdf Edit: Forgot to answer the question; if you have an SID and for any disconnect reason (self or forced) try to unsubscribe. Obtain a new SID on subscribe.

Thanks, That helps. Will review.

0.8.8 is still in staging. 0.8.5 is latest release. @dbwarner5 , I want test something, to narrow the issue to initial value and/or value change. If the value changes (i.e. from ON to OFF, not query by opening dashboard) 1) Does the app show the value change without a query (i.e. without changing the screen)? 2) If #1 is true, is the value shown the next time the app is opened, or is the value null again?

The process has changed as the automatic change to Favorites causes issues in some processes if the user leaves or the app directs user to a webpage. New process is listed here: https://wiki.universal-devices.com/index.php?title=UD_Mobile#Show_Favorites_at_launch

Just tested and Groups work, are you sure the program was saved prior to testing? You can also test from the UD Mobile Node directly. Setup: https://youtu.be/KSmx-XIquAw Sending to a specific Group or Device: https://youtu.be/z4pquLcI2Es Creating your own notification content: https://youtu.be/KSmx-XIquAw?t=165

The OP has another issue, status is incorrect not related to missing status. Missing Status: https://forum.universal-devices.com/topic/45881-elk-node-issues-recently/#comment-400691

Great! Be sure to unsubscribe if you have logic to reconnect. There is an Subscription ID published on initial connection, this ID is needed to unsubscribe. While a hanging subscription may be cleaned up by eisy, we have had instances where a client subscribe too many times without unsubscribing before cleanup which can prevent other clients (udm, porta, admin, pg3) from obtaining a subscription.

Hi @dbwarner5 , Is this the only issue which persists? i.e. clicking dashboard before status population. Does this only happen with ELK? Does anyone else see the same? Is eisy UI at version 0.8.8? /system/upgrade to view versions, and available versions for your configuration.

Please try synchronization, The most recent app update should have alerted all users on first open to synchronize....should also be much faster

Fixed in the next app release for both iOS and Android.

Have you tried reboot? Socket timeout sounds like the event subscription in not working. As for the other question regarding Mac Permissions: https://wiki.universal-devices.com/Main_Page#MAC_Users

UD Mobile is not yet fully compatible with eisyUI, so local creds must be legacy credentials and port 8080 until further notice.

@everyone firmware should be released this week.

rest/query queries the device, this is more resource intensive than a retained status lookup. Use /rest/status/address or rest/node/address instead. If you can subscribe then you just need to parse the events. Basically any <control> which does not start with "_" is a Device Property Status Event where the control is the Property ID. //<?xml version="1.0" encoding="UTF-8"?> //<Event seqnum=\"113\" sid=\"uuid:90\"> // <control>ST</control> // <action uom=\"2\" prec=\"0\">1</action> // <node>n003_po_pushover</node> // <eventInfo> // </eventInfo> // <fmtAct>True</fmtAct> // <fmtName>Last Status</fmtName> //</Event>

Ok, then it is not the app. If you swiped from recents the app will no longer have any status values, they are all cleared. When the app starts again the values are observed (Subscription Event), so the values you now see are those that have been saved in eisy. Sending query, queries the device which then reports to eisy, eisy then forwards this message (Subscription Event) to the app (in the same way it received the initial status). So if the status is updated on query and shown in the app then the app is working as intended. My guess is the error is likely the Insteon Modem or the Device not reporting status updates. To be sure you should check if rest/nodes/nodeAddress shows the status correctly. P.S. If you updated firmware to 6.0.0 there are reported event issues. please try again after the next firmware update coming in a few days.