Due to an influx of spam, we have had to impose restrictions on new accounts. Please see this wiki page for instructions on how to get full permissions. Sorry for the inconvenience.
The migration is almost done, at least the rest should happen in the background. There are still a few technical difference between the old cluster and the new ones, and they are summarized in this issue. Please pay attention to the TL:DR at the end of the comment.
When claiming a sensor via DBus, there are two possible options:
The sensor is not active, and the client is the first one to claim the sensor. In that case iio-sensor-proxy will initialize the sensor and notify the property on dbus once a first measurement has been done.
The sensor already is active, the client is not the first one to claim the sensor. In that case iio-sensor-proxy will not really do anything.
In case 2), the client can read the sensor property (so eg. ProximityNear) over DBus immediately and the result will be correct. Meanwhile in case 1), the client will read an outdated result (potentially from the last time the sensor was active, or just the default).
Clients have no way of knowing whether they're the first ones to claim a sensor though, so they can only trust iio-sensor-proxy that the DBus properties are always up-to-date. In case 1), this requirement is not met.
To deliver on that promise without drastically changing the API of iio-sensor-proxy, we have to delay with returning the DBus call on the first Claim() of a sensor until we receive a measurement from the sensor, so that the client has a valid measurement to work with right after Claim() returns.
Same thing goes for the case where a sensor is already claimed, but the actual sensor-hardware is not there yet. In this case we need to delay notifying the HasAccelerometer/HasAmbientLight/... DBus properties until the first measurement is received.