Area Radius not using meters when HA system default is feet

[asucrews]

When I set the area to 10 meters (30 feet), areas farther than 10 feet away become unknown. When I set the area to 25 meters (75 feet), the unknown areas reappear.

My house is neither 25 meters nor even 10 meters long or wide, so I believe there might be an issue with the conversion from meters to feet.

HA Versions Core: 2024.5.4 Supervisor: 2024.05.1 Operating System: 12.3 Frontend: 20240501.1 Bermuda Version: 0.6.6

I'm not sure how to retrieve the logs for this issue.

[agittins]

Hmm that's odd. Can you post a screenshot of your config page (in bermuda configuration, global options)?

There might be something odd going on with the config option conversion. Internally, Bermuda uses metres for everything, and the sensors are exposed with a "native measurement" of metres, so the frontend will be doing the conversion to feet for you.

But I have a feeling it doesn't convert the config page, because I don't think I can (or have?) told HA the units for those settings. Or maybe it does and I don't realise it!

My expectation is that you need to enter metres on the config page, but HA will translate the units for sensors etc - but I might need to take a look at that specifically, by the sounds of it. A screenshot of your config just so I can see what it's reflecting would be good.

Also, could you post one of the "options" sections from calling the dump_devices service (Developer Tools, Services, bermuda.dump_devices). There will be one in every "block", it will look a bit like:

  options:
    attenuation: 3
    devtracker_nothome_timeout: 180
    max_area_radius: 72
    max_velocity: 3
    ref_power: -55
    smoothing_samples: 25
    update_interval: 10
    configured_devices:
      - C7:B8:C6:B0:27:11
      - EE:E8:37:9F:6B:54
      - CE12CBEB2DBE448BB057C1FE9804B45F_100_1
      - A4:C1:38:DC:19:36
      - FF:FF:10:F7:A4:B9
      - A4:C1:38:3E:4F:A4
      - 5A:B6:51:70:6C:3B

That plus the screenshot should show if anything is doing any conversion of units at the config end of things.

By the way, I set my radius to 70 metres or so (effectively infinite, since ble rarely travels that far) as I've found little benefit in having the sensors go to unknown, I'd rather they snap to the nearest sensor even if it's not "right". But that doesn't address the conversion issue you're seeing, of course...

[asucrews]

I totally agree with you on the very little benefit of a scanner going unknow, but to each there own. that why i wanted to set mine to 25 meters, that should about 75 feet. let me know if you need anything else.

      options:
        attenuation: 3
        devtracker_nothome_timeout: 30
        max_area_radius: 50
        max_velocity: 3
        ref_power: -51
        smoothing_samples: 20
        update_interval: 10

[asucrews]

I was looking through the dev docs at the example sensor. it shows the below properties for the sensor. I am wondering if not the config flow but the sensors don't have a native units set. but i could totally be wrong there seem to be many way to set native units

https://github.com/home-assistant/example-custom-config/blob/master/custom_components/example_sensor/sensor.py

    _attr_name = "Example Temperature"
    _attr_native_unit_of_measurement = UnitOfTemperature.CELSIUS
    _attr_device_class = SensorDeviceClass.TEMPERATURE
    _attr_state_class = SensorStateClass.MEASUREMENT

[asucrews]

Some infomation at when i set it to 10

  options:
    attenuation: 3
    devtracker_nothome_timeout: 30
    max_area_radius: 5
    max_velocity: 3
    ref_power: -60
    smoothing_samples: 10
    update_interval: 10

[agittins]

The sensors do define units of measurement, so that should be all good (and if they didn't HA wouldn't try to convert them for you, it would just present them as numbers, I believe). The units were added in v0.3.2 back in January.

The options block in your last post shows a bug, in that it is an incorrect copy of the options, but one that doesn't have any operational effect - what's happening is that the options block gets attached to each device / scanner entry, (mostly as a convenience to myself for when people send debugging info) and I save those scanner details into the config. When bermuda restarts or reloads, it pulls in those saved scanner entries without replacing the options block (it does replace them on all other devices) so it will be showing an out-of-date copy of the options. But they are not the options actually being used, which is confusing, but inert.

If you scroll through the devices in the dump_devices info, you'll notice that the entries for the proxies (they have is_scanner: True in them) will all have the radius set to 5, but all the other devices will have whatever the current actual config is. They are just copies of the config though, so aren't doing anything themselves.

I'll have that fixed in the next release.

That's just re the options block though, and is a non-issue.

Your screenshot of the sensor shows it reporting 17ft from the Family room scanner, which is inside the configured 10m radius, so it looks OK to me. If the units were getting messed up then I'd expect that a "measurement" of 17ft, being over 10ft, would result in that scanner also showing "Unknown". My assumption from the screenshot is that the Family Room proxy is "measuring" 17ft, while the others (dining, kitchen garage?) are either not seeing the device at all, or are measuring a distance of over 10m / 32ft so report Unknown.

It's important to note that "measurement" is not a very accurate term, so unless you have calibrated your proxy and device power/rssi levels, the absolute distance reported is not an actual distance, but but a super loose approximation - they should all be "relative" though, in that whichever proxy reports being the closest, regardless if that "measurement" is a few inches, or 50 metres, it is really "the closest", in relative terms.

Does that reflect what you're seeing, or am I missing something in my interpretation?

If it still doesn't seem right, can you call the dump_devices service, but use the address filter to limit the results to just your sensor above, and send it through? If you click the "Fill Example Data" button in the service it will give you a hint on how to specify one or more addresses to filter. If you send that, as well as a note (or another screenshot) about what distances are showing on the sensors at around the same time I should be able to take a deeper look into what's happening.

If you're concerned about sharing your MAC addresses online, you can do a search-and-replace on the file first, but if you can leave the first and last pair of digits on each mac so I can tell them apart that would be great (eg, replace nn:nn:nn:nn:nn:nn with nn:xx:xx:xx:xx:nn)

[asucrews]

I think I understand, let me do some more testing and get back to you.

On Thu, May 23, 2024, 11:22 PM Ashley Gittins @.***> wrote:

The sensors do define units of measurement, so that should be all good (and if they didn't HA wouldn't try to convert them for you, it would just present them as numbers, I believe). The units were added in v0.3.2 back in January.

The options block in your last post shows a bug, in that it is an incorrect copy of the options, but one that doesn't have any operational effect - what's happening is that the options block gets attached to each device / scanner entry, (mostly as a convenience to myself for when people send debugging info) and I save those scanner details into the config. When bermuda restarts or reloads, it pulls in those saved scanner entries without replacing the options block (it does replace them on all other devices) so it will be showing an out-of-date copy of the options. But they are not the options actually being used, which is confusing, but inert.

If you scroll through the devices in the dump_devices info, you'll notice that the entries for the proxies (they have is_scanner: True in them) will all have the radius set to 5, but all the other devices will have whatever the current actual config is. They are just copies of the config though, so aren't doing anything themselves.

I'll have that fixed in the next release.

That's just re the options block though, and is a non-issue.

Your screenshot of the sensor shows it reporting 17ft from the Family room scanner, which is inside the configured 10m radius, so it looks OK to me. If the units were getting messed up then I'd expect that a "measurement" of 17ft, being over 10ft, would result in that scanner also showing "Unknown". My assumption from the screenshot is that the Family Room proxy is "measuring" 17ft, while the others (dining, kitchen garage?) are either not seeing the device at all, or are measuring a distance of over 10m / 32ft so report Unknown.

It's important to note that "measurement" is not a very accurate term, so unless you have calibrated your proxy and device power/rssi levels, the absolute distance reported is not an actual distance, but but a super loose approximation - they should all be "relative" though, in that whichever proxy reports being the closest, regardless if that "measurement" is a few inches, or 50 metres, it is really "the closest", in relative terms.

Does that reflect what you're seeing, or am I missing something in my interpretation?

If it still doesn't seem right, can you call the dump_devices service, but use the address filter to limit the results to just your sensor above, and send it through? If you click the "Fill Example Data" button in the service it will give you a hint on how to specify one or more addresses to filter. If you send that, as well as a note (or another screenshot) about what distances are showing on the sensors at around the same time I should be able to take a deeper look into what's happening.

If you're concerned about sharing your MAC addresses online, you can do a search-and-replace on the file first, but if you can leave the first and last pair of digits on each mac so I can tell them apart that would be great (eg, replace nn:nn:nn:nn:nn:nn with nn:xx:xx:xx:xx:nn)

— Reply to this email directly, view it on GitHub https://github.com/agittins/bermuda/issues/201#issuecomment-2128644820, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABHMUNZNMWPGWFWWPQZGFM3ZD3MATAVCNFSM6AAAAABIAPLRYGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRYGY2DIOBSGA . You are receiving this because you authored the thread.Message ID: @.***>

[agittins]

I have a feeling this is resolved, but please feel free to reopen the issue if you find anything odd going on.