fix: fix multiple parameters for hass Discovery

[varet80]

This pull request applies two changes:

• Binary Sensor discovery was not working, fixing it by changing the SensorTypeName source
• Add ability to use PropertyName in case Label is not sent by driver
• Adds unit_of_measurement on Battery level devices by default.
• Replace valueId.units with valueId.unit
• add README.md on prettierignore list. As some linting standards cannot be followed.

** Binary Sensor discovery**
discovery was not working, as the sensorTypeName was a number and not the name of sensor
changed the value used for this from Translated to just valueId.property

Missing Label
There are cases where the Label is missing from a Property. We can use the PropertyName in that cases.

I have create a small change in code to make this happen. Because my code was based on hassDiscovery branch, I am also making a pull request with that branch as target.

I have tested a container and I do see only Undefined labels changing to Property Name.
Any property having labels is not impacted.

Batery Level
Battery level unit was not discovered. Added a percentage under the payload of this parameter

valueId.unit
valueId.units is non existing, fixing the typo with valueId.unit

[AlCalzone]

Ok I guess @robertsLando has to chime in here. I don't know the specifics how things are handled on this side.

[robertsLando]

@AlCalzone could the label be undefined or is this caused by an error on zwavejs? If it's the second case I would remove this so we can detect undefined labels and fix them on zwavejs

[AlCalzone]

The Label can be undefined if we don't set it in zwave-js. Your code should be prepared for that possibility.
But as I wrote in slack, we should find those locations and eliminate them.

[robertsLando]

Ok so in poor words should I keep this change or remove this so we can detect undefined labels?

I think it's a good fix but we would never see the undefined labels if I keep this

[varet80]

we could have a suffix/prefix Property and help us still know what is, but not let it undifined
something like

label: zwaveValueMeta.label || ("%s - property", zwaveValue.propertyName),

[robertsLando]

This could be another valid solution

[varet80]

i think more beautifull would be:

label: zwaveValueMeta.label || ("%s (property)", zwaveValue.propertyName),

pushing this as change. If you prefer different approach. please comment here

[robertsLando]

@billiaz There are some lint issues

[varet80]

my mac has some issues with lint-fix/linting

this issue can probably be solved

        if (valueId.property) {
          let sensorTypeName = valueId.property
        }
        // unsued discovery line. for historical reasons
        // let sensorTypeId = BinarySensorType[valueId.property]
        if (sensorTypeName) {
          sensorTypeName = this.mqtt.cleanName(
            sensorTypeName.toLocaleLowerCase()
          )
        }
        // TODO: Implement all BinarySensorTypes
        cfg = hassCfg['binary_sensor_' + sensorTypeName]

by making it:

        if (valueId.property) {
          let sensorTypeName = this.mqtt.cleanName(
            valueId.property.toLocaleLowerCase()
          )
          // TODO: Implement all BinarySensorTypes
          cfg = hassCfg['binary_sensor_' + sensorTypeName]
        }

[robertsLando]

@billiaz Seems thre are still some lint issues?

[varet80]

@billiaz Seems thre are still some lint issues?
@robertsLando
this is an issue also seen in hasDiscovery. Prettierlint fails with readme. as we need to have some double quotes there.
I suggest to add a .prettierignore for README.md (I am adding it to test if this is the same failure here too! but this is what investigation showed on my laptop)