Availability Sensor / Template Tracking

[tanishqmanuja]

Describe the solution you'd like

fan:
  # other stuff
  availability_sensor: sensor.ir_bridge_status

OR

fan:
  # other stuff
  availability_template: "{{ is_state('sensor.ir_bridge_status', 'available') }}"

Additional context
It would be nice if the fan would become unavailable as the IR bridge does down or loses power, because practically it wont be able to send signal anyways.

[litinoveweedle]

Hello,
thank you, this seems to be as nice idea, I will try to implement it in the next release.

[litinoveweedle]

Hello,
I got some time to do some analysis. I would not go for the template directly, but use boolean helper entity in the similar way, how the power sensor is integrated. Than you have all the possibilities offered by HA automation to set the given helper state to the one reflection supposed availability of the SmartIR entity. What do you think? Please let me know, thank you.

[tanishqmanuja]

Each way has its own pros and cons, I personally prefer templates because then we don't have to set up extra boolean helpers or automations. So all the code responsible for an entity remains in a single place.

But both solve the issue, you could go with whichever seems best.

[litinoveweedle]

Hello, I started with the implementation, but I have a dilemma. In case the device is on, even if controller will go down it will stay on anyway, So make it it unavailable means, that user will loose track of the device. In case that device is off, it makes full sense to make it unavailable. What do you think?

[tanishqmanuja]

That is a valid point, Can we make it such that it restores the last known good state after it's available again.

By good state i mean states excluding unavailable.

I mean the implementation could be .. when the template tracking callback changes to unavailable store the previous state in hass[domain].data[device-uid] and on available again, apply the previous state.

[litinoveweedle]

I am still not completely sure, if this is what user expect. I would propose following:

• when device is 'off' and availability sensors goes unavailable, unknown or off then make controller device unknown
• when device is 'on' and availability sensors goes unavailable, unknown or off then keep reporting controlled device as in on state, but raise HomeAssistantError and revert any user changed setting back immediately.

Additional question. My broadlink remore correctly reports state of the remote entity as either on or when unreachable as unknown. Is it same for your MQTT remote? (i.e. are you able to map MQTT topic to availability of the remote entity?)

[tanishqmanuja]

I dont know if there is a topic for the unavailability but all the entities go to unavailable state

[litinoveweedle]

Hello, thank you for this info. Is there one entity with attributes? Or your IR remote has multiple entities in HA? In the case of broadlink remote, there is only one entity - i.e. remote.my_remote

[tanishqmanuja]

Multiple entities are there by default in tasmota device. For example like this:

[litinoveweedle]

OK, last question. What if we use as a availability sensor directly availability of the entity set in configuration as controller_data attribute?

[tanishqmanuja]

I didn't understand that, can you give an example?

[litinoveweedle]

Ok, sure. I use Broadlink controller. My controller_data is entity therefore Broadlink controller entity remote.my_ac_remote

If this device goes off (I unplug it), the state of the HA entity remote remote.my_ac_remote changes from on to unknown. Therefore in my case it is enough to check for the state of the controller_data referred entity to see, if my controller is up and I can operate the device.

How is it with the MQTT / Zigbee devices?

[tanishqmanuja]

I don't own Zigbee, but for MQTT there is not a standardized entity/device. It will be up to the user to decide which sensor or entity to use for availability detection.

For MQTT the mechanism is as follows:

• MQTT integration enabled in home assistant which has my mqtt broker ip address
• Then Tasmota integration which uses MQTT integration and connects to the hardware (ESP device flashed with Tasmota firmware)
• Then SmartIR connects using MQTT topics provided by Tasmota device in HA

[litinoveweedle]

Hello,
I did initial implementation of this feature in this branch There are significant changes present, together with some configuration directives being renamed. I would welcome your help with testing. I you would like to install this version please update first to latest 1.19.0 and then manually override init.py and climate.py|fan.py|light.py|media_player.py by the version from the availability_sensor branch,

[tanishqmanuja]

Sure thing, will report back in a few hours ☺️

[tanishqmanuja]

Status not updating, also every time i restart HA the fan becomes unavailable and loses it's previous state.

platform: smartir
name: Tanishq Room Atomberg
unique_id: tanishq_room_atomberg
device_code: 1175
# availability_sensor: sensor.ir_bridge_ssid
availability_template: "{{ not is_state('sensor.ir_bridge_ssid', 'unavailable') }}"
controller_data:
  controller_type: MQTT
  mqtt_topic: cmnd/tasmota_irbridge01/IRsend