Javi

@SHM Please open a ticket, included your UUID. I have a few reports of synchronization hanging, but cannot replicate. Also let us know if this is Android or iOS.

Geofencing has logs saved to the phone. So if these have never been checked it is worth looking at, it could be a simple error. Always use maps (Android Auto/ Apple Car Play or whatever they are called now) when driving to force GPS lookup which will propagate to fences. All nodes have status change history saved in eisy as of 6.4.x. In UDM change the property type to charts. So if the device you add is a node you can see state change history with timestamps I think someone mentioned LoRa (e.g. yolink), should support much longer ranges than BLE. I would not use BLE for this situation.

No need to enter your WiFi credentials (given to the device by android OS). Bluetooth WiFi commissioning now happens entirely on the Mobile device instead of passing through to eisy, which had latency issues causing timeouts in the matter stack, so hopefully less WiFi commissioning failures.

It may be possible if your vehicle had the BLE broadcasting device and the reader was at the gate, but due to latency, it may be easier/quicker just press a button or asking Android Auto's Google Assistant to open the gate/door. While BLE works great for some location tracking situations, like when there are a high number of receivers (iTags, everyones iPhone is a receiver), it would likely not work well when a phone, inside the vehicle, is trying to read signals outside the vehicle. The periodic phone wakes are too far apart when traveling. Ble works in line of sight, no obstructions, for 30 - 300ft (in my test even 30 ft was difficult to obtain). There is an old thread somewhere on the forum where I tested iBeacons for indoor location tracking, just facing away from the device with my body in between the phone an the BLE device in the same room caused the signal to disappear. I found that reading WiFi BSSIDs (on Android, blocked by iOS), worked the best but this was a huge drain on battery. The best custom Geofence solution is in our Android app, where you can force GPS poll at intervals, so the user creates multiple geofences and increases or decreases polling intervals based on which fence they have entered or exited. Because this is a GPS update the lack of cell towers and wifi access points is not as pronounced. This has been a solution for other users in rural areas. Also in both iOS and Android if are running maps in your car this is already getting GPS updates which the OS uses for Fencing, so this eliminates the need for custom polling. However if you have poor internet the fences can not send that trigger to eisy.

The short answer is if you do not have good cell service geofencing will not work, and/or will require a wider fence. Wifi Range in not a good indicator for the various reasons listed above (faux mac addresses (iOS), wifi sleeping, or a dead spot in the corer of the room). Ble has it's own issues even worse than WiFi for this sort of situation. If your router supports, you can trigger something when your phone connects, but you will have the same issues. There are vehicle gps systems that can send geofence triggers, this is likely the best in your case, although for most of us a city with high concentrations of WiFi access points and cell towers geofencing works good enough without the extra fee of the vehicle gps system. While UDM, and any other app, can read an SSID it can only do so in a foreground request. Apple does not allow apps to read SSIDs in the background (without it being a special category of HotSpot, we have asked apple and have been denied, the app must be for a HotSpot). Also many background request are queued so the request and the response may be minutes or hours apart. Geofencing uses a number of indicators, like GPS, WiFi access points, and cell towers. GPS is not always on or your battery would die in a few hours. Wifi is not always on for the same reason, although it would last a few more hours. So your phone periodically wakes, connects to Wifi, then check may things or allows apps to do a queued background update. This wake may check fences, I say may as there are other indicators as is more complicated than my simple explanation, you don't want your phone checking GPS ever X-num of minutes or the battery would die.

It looks like it last triggered at 3:13 PM as an exit, so it is working. The app's geofence logs will show all entries and exists along with any communication errors. https://wiki.universal-devices.com/UD_Mobile#Geofencing I say usually as the fence notification is handled by the OS, not the app. How the OS does things differs depending on may variables such as platform (iOS/Android), OS version, battery level, privacy settings, location settings, and MFG (in the case of Android). The Android App can do things to change this behavior (UD Mobile Location Services Section in Wiki), but on iOS it is mostly controlled by Apple. The most important thing is setting, both the OS Global and App Location Settings must all be enabled or fences may not work.

I recommend using UD Mobile Geofencing. Geofences use WiFi (including access points which do not belong to you) along with GPS. If using Wifi only it may change the variable when the when the screen is off for long periods, which will cause the variable to change even when in range. Geofence lookup is usually triggered when the device connects to a WiFi access point.

I think we have your ticket, if not please open one.

Fixed in 1.5.10

Replicated, working on a fix. The issue is the app fails to synchronize after name change. Synchronizing should update.

The icons are gray in the screenshots so the connection is lost, attempting anything in the AC when the icons are gray may have unexpected behavior.

As with every protocol, there are advantages and disadvantages, and in this case there are a few Wifi, ipv6, and Matter. There are network hardwired matter devices which likely will not have the same issue, same as the tread matter devices. Being as you have multiple devices with the same symptoms, my guess is the root cause is the WiFi device and WiFi router do not play well together sometimes. When issues like this were encountered with some testers it was usually solved by disabling all bands except the 2.4Ghz (not ideal), or replacing the router. Both seemed to solve the issues.

I'm not sure, I can not replicate. If not on 6.0.5, it is possible there was a bug which was fixed in 6.0.5. Is there an error message?

6.0.4 has an issue on large installations where some initial status values are dropped. Not every time, not always the same status values. What were the issues in 6.0.5?

Great