Javi

Not sure, is there sibling node with the battery level? The time is one of the reasons it's still beta, we had a formatting issue in the database. I think it should be fixed in the next firmware release, but not my specialty so I could be wrong . We also still need to implement a database purging as the database could become very large very quickly for some users.

It does: see Admin Console Please open a ticket

Likely not, ISY994 did not support Z-Wave secure communication. This is one of the reasons the device needs to be re-added.

These locks are a pain, I documented it somewhere but don't recall if I published. Basically the lock requires you to follow setup instructions exactly, the biggest step missed my most users was after factory reset you need to manually enter one of the default codes so the lock goes into the locked position then again so it unlocks. Only after doing this will the lock add into eisy. Also the range during interview needed to be very close, like a few feet.

Yeah, it is a pain if already released. There is no great way to identify a toggle, these assumptions worked the best for most devices of all types. The first version of UDM calculated this differently, If the command with ID="DON" existed and had an init equal to the Primary Property (ST if exists, if not the first listed) UDM would show a toggle. However cmd init requires a range, so devices without a range did not show a toggle in UDM. With that said, I am in the process of a major revamp of the app to replace deprecated APIs and simplify/enhance/speed-up some things. The new app APIs removed the toggle calculation from lower level and is now done at the UI level. So it could change easily when the new APIs are implemented into the Home Tab. I'm hoping to allow users to change the Primary Property on the Home Tab (like favorites). So it may be better to use the original calculation first if DON has an init value, and use the existing calculation if DON does not have an init value.

The UOM should not affect this calculation. If there are command IDs DON and DOF and a property id "ST", then the app assumes this is a device which supports toggle. If the ST property has a value greater than zero it assumes on, else assues off. Based on the screenshots if "Outlet State" has the id "ST", then value 0 is off an 1 is on. So the toggle should work. Maybe the value was not published quickly enough and user did not see change?

Hard to say, I need the first screenshot for both on and off. If the toggle indicator (circle on the top left) is filled UDM believes the device to be ON, if empty it believes the device to be off. UDM's calculation of on/off status may be imperfect as not all nodes are the same. While there are a few exceptions UDM will show the status indicator (empty/filled circle) and allow toggle if there is a Property with the id="ST" and the node supports commands on (id =DON) and off (id=DOF) commands UDM assumes the Property with the id = "ST" correlates to these commands.

That is a real pita. Sounds possible, but would be low on our already long to-do list. Some apps have intents which allow deep linking into the app, but I've only seen a handful that publish their intents. Also a possibility to open another app from a UDM tile. Have you tried Google Assistant/home broadcast feature? I use it when I need the wife or kids to answer their phones when I'm out of the house 🙂 I think you can broadcast to specific devices, but the above is my only use case so have not looked into it.

When I get some free time I'll see if we can convert edit lock into favorite lock.

Replicated, will push version 1.2.13. Thanks.

Thanks. Reporting here works better. I can search the apple crash reports, but don't usually start there. There are major changes in versions > 1.2.8 in preparation for removing synchronization requirements with firmware 5.9.x. So possible there are other bugs. I could not replicate but my commit history show something similar on the July 9th so likely did not make it into the last release. I'll push version 1.2.12 to beta now, but may be a few days until live.

Great, Please open a ticket for the device without control so it can be forwarded to the correct location.

Usually a couple of weeks, this build happens to include major changes in preparation to remove synchronization requirement with 5.9.x firmware. So may be slightly longer than usual so we can verify any bugs are corrected.

Thanks

I have a similar "Access Control" node and have verified (1) the status mappings are incorrect and (2) formatted values are not being displayed in UDM (subscription formatted). I'll submit a bug report, however it is at firmware level so may be some time before a fix makes it to production. I also think the Node may not have installed correctly or may require a compatibility mode. The Binary Door/Window Sensor has a status on my end and is the Node I use to verify status. If unsure how to do this please open a ticket as it's not my specialty. If you open a ticket, let me know the number and I'll attach notes.

Polisy is likely the cause.

Also Polisy, may not be supported. There were networking changes required. Please open a ticket if using Polisy and wanting matter support.

Yes QR Code was the only way prior to the latest Android and iOS (iOS still in beta) versions of UD Mobile. It's possible we don't yet recognize the device type, but basic on/off should work. I've only tested with this https://www.amazon.com/dp/B0BZBGD87V?ref_=ppx_hzsearch_conn_dt_b_fed_asin_title_1. Was/Is there an error message?

A little hard to follow, but I don't think "Access Control" is an open closed property. If I remember correctly this is something like how it was controlled manual/keypad/etc.. My guess is there are multiple nodes for this device and the Favorite is using the wrong node.

Great, for reference in case anyone else finds this topic. On Android the Notification Channels must be set to App Provided Sound. -

I think it's a generic warning, but it is valid. As long as you crate a UD Mobile backup it can be restored but you may need to re enter credentials depending on if iOS keychain associates the new install to the old install. There is a caveat, If there is a database upgrade in the app you cannot install a backup created on a newer UDM version on an older UDM version.. but that is usually the reverse situation going from Beta back to production. Also Database upgrades are not that common.

I'm not sure, the sounds are included in the app's package so should work unless the user has changed setting on Android OS. Did you happen to customize the sounds on Android? Maybe the file no longer exists? https://wiki.universal-devices.com/index.php?title=UD_Mobile#Android_2

For Matter over Thread a Thread Border router is required. The device can be added to the border router first, i.e. a Nest Hub Max, then share the device with eisy using the sharing QR Code or Pairing Code from the Border Router's app. Eisy will communicate with the Thread Border Router to control the device. Note that Pairing Code entry still in UD Mobile beta for iOS.

I'm not familiar with ratgdo, so you may want to ask in that sub forum.

Bug discovered in version 1.2.9 - 1.2.10. Causes failure on back navigation from folders on home tab and automations tab. Fixed in 1.2.11