re introduice equipment

[LGO44]

Summary

Re introduce equipments that have been suppressed by the version 4.0.0 RC1, for plugs, heatingactuators, powertags.

Problem

Some users may use this

Changes

• create a sensor Equipment with all the attributes
• equipments are used by Schneider for the enery management

Validation

• OK on platforms

[andyblac]

I get a duplicate sensor with this,

why is this needed ?

[LGO44]

It was in the previous versions.
The state of the equipment is the power.
I'm preparing new features on notifications over-power and under-power.
This will allowed to follow the energy management (shedding ...)

[andyblac]

it should NOT have been..., it was a duplicate of Power...

[andyblac]

if you mean missing attributes.... I'm ok you adding them to power entity, but IMO we should not have duplicate sensors and recorded data...

[andyblac]

I agree that the equipment data should remain available, but I do not think we should restore WiserEquipmentSensor as another power entity.

For PowerTags, it is an exact duplicate because instantaneous_power already returns equipment.power.total_active_power. For smart plugs and heating actuators the API fields differ, but presenting both as general Power sensors is still confusing and may record effectively duplicate measurements.

I propose adding the equipment metadata to the existing Power entity:

@property
def extra_state_attributes(self):
    """Return equipment information when available."""
    equipment = getattr(self._device, "equipment", None)
    if self._lts_sensor_type != "Power" or equipment is None:
        return {}

    return {
        "equipment_id": equipment.id,
        "equipment_device_id": equipment.device_id,
        "equipment_uuid": equipment.uuid,
        "equipment_name": equipment.equipment_name,
        "device_type": equipment.device_type,
        "family": equipment.equipment_family,
        "installation_type": equipment.installation_type,
        "controllable": equipment.controllable,
        "cloud_managed": equipment.cloud_managed,
        "monitored": equipment.monitored,
        "smart_compatible": equipment.smart_compatible,
        "smart_supported": equipment.smart_supported,
        "can_be_scheduled": equipment.can_be_scheduled,
        "functional_control_mode": equipment.functional_control_mode,
        "current_control_mode": equipment.current_control_mode,
        "pcm_mode": equipment.pcm_mode,
        "pcm_supported": equipment.pcm_supported,
        "pcm_priority": equipment.pcm_priority,
        "load_state_status": equipment.load_state_status,
        "load_shedding_status": equipment.load_shedding_status,
        "operating_status": equipment.operating_status,
        "fault_status": equipment.fault_status,
    }

Values that users need to monitor independently, such as load shedding, faults, and over/under-power notifications, could later be exposed as properly typed entities. That would provide useful history and automation triggers without creating a second sensor for the same power measurement.

Also, this check:

if hasattr(power_tag, "equipment"):

does not confirm that equipment data exists because the property is always defined. It should be:

if power_tag.equipment is not None:

[asantaga]

@LGO44 in this case I agree with Andy, another sensor is duplication

[andyblac]

not required as #726 supersede it.