Can't change names of distance, latency, or sensitivity sensors

[Mike1082]

First of all, thank you for sharing this. Out of the box for one sensor it works amazingly well.

My issue is that I would like to run many of these. When I deploy the first one, my friendly name does not get used for the distance, latency, or sensitivity sensors. For instance, "distance" is just called "number.distance" as opposed to "number.sensor-name-distance". I tried updating the leapmmw_sensor.yml file by changing the names (while leaving the id as-is) but with the 3 mentioned sensors, once I change those names, they will no longer update in HA with values stored in the device. They just look empty, even after waiting a very long time.

I tested this by going back and one-by-one putting the original "names" back, and as I did that, the values started appearing in HA and working as expected.

I believe that the issue is the functions in the header file are referring to the Name, as opposed to the id.

For example from leapmmw_sensor.yml:

number:
  - platform: template
    name: ${device_name_pretty} Distance #original value: distance
    id: distance # do not change
    entity_category: config
    min_value: 0.15
    max_value: 9.45
    step: 0.15
    unit_of_measurement: M
    mode: box
    lambda: |-
      leapmmw(id(uart_bus)).getmmwConf("getRange");
      return {};
    set_action:
      - switch.turn_off: mmwave_sensor
      - delay: 2s
      - uart.write: !lambda
          std::string range = "setRange 0 " + str_sprintf("%.2f", x);
          return std::vector<unsigned char>(range.begin(), range.end());
      - delay: 3s
      - switch.turn_on: mmwave_sensor

and from leapmmw_sensor.h:

// leapMMW:/>getRange
          if (getline.substr(0, 18) == "leapMMW:/>getRange" || getline.substr(0, 8) == "getRange") {
            std::string getRange = line.substr(15, 4);
            if (getRange.empty()) {
              ESP_LOGD("custom", "Did not find a value for getRange");
            } else {
              ESP_LOGD("custom", "The value of getRange is: %f", parse_number<float>(getRange).value());
              publishNumber("distance", parse_number<float>(getRange).value());
            }
          }

Once I change the "name" in the yml file, the function publishNumber("distance", parse_number<float>(getRange).value()); no longer seems to work.

Is there a better way to have all of the entities associated with the device have names prefixed with the device name?

Thanks!

[igiannakas]

This has been fixed in the new version of the code I've uploaded today. In summary there was a change needed in the below two functions, to instead of checking for an exact match to the sensor name, to check for a partial match:

  void publishNumber (std::string sensor, float resp) {
    auto get_numbers = App.get_numbers();
    for(int i = 0; i < get_numbers.size(); i++) {
      std::string name = get_numbers[i]->get_name();
      if(name.size() > 6 && name.find(sensor) !=std::string::npos) {
        get_numbers[i]->publish_state(resp);
      }
    }
  };

  void publishSwitch(std::string sensor, int state) {
    auto sens = App.get_switches();
    for(int i = 0; i < sens.size(); i++) {
      std::string name = sens[i]->get_name();
      if(name.size() > 2 && name.find(sensor) !=std::string::npos) {
        sens[i]->publish_state(state);
      }
    }
  };

This allows for the sensor attributes to be named using the "pretty device name" prefix. For example:
name: "${device_name_pretty} distance"

Give the latest version a try and let me know if I can close this issue.

[Mike1082]

Wow, thank you for the quick response and the fix! Worked like a charm!

The only thing I changed for myself in this version was re-enabling logger (I kept the debug level logging off, but I do like to be able to see logging in general when I am deploying these).

Much appreciated! Please go ahead and close this, the issue has been resolved.

[igiannakas]

Excellent,
Glad it worked as well for you! I’ve also deployed it on my setup too :)

[Mike1082]

I was going to ask about adding additional sensors, then I realized you have another device with temp/humidity and another STL for a case... you f'in rock man. Is there any reason I couldn't do the same thing without going to an ESP32 version of the D1? I just bought a pack of D1 Minis with USB-C and 8266. They should be able to support one more sensor, and maybe a push button, right?

[igiannakas]

Hey! Yes you can do it with an esp8266 - the wiring is a bit more tight space wise but it works ok.

The only reason i went for an esp32 for the combo sensor is because I wanted to try an esp32!

The same code from the other repo should work if you replace the pins with the ones your 8266 uses.

[igiannakas]

Ps. If you try the other case with an 8266 you’ll need to enlarge the square cut out for the chip a bit as the d1 mini has it moved more to the left compared to the esp32 mini. I’ve included the step files on printables so it should be a very quick mod.