emontnemery/hatasmota

hatasmota's Issues

Transition is not working correctly for light.toggle

When light is transitioning from OFF to ON fade is enabled, but for ON to OFF is disabled.

Home assistant action:

    - entity_id: light.kitchen_table
      service: light.toggle
      data:
        brightness: 255
        color_temp: 500
        transition: 2

Tamsota logs:

16:35:01 MQT: stat/lohas_light10/POWER = OFF
16:35:07 MQT: stat/lohas_light10/RESULT = {"Fade":"ON"}
16:35:07 MQT: stat/lohas_light10/RESULT = {"Speed":4}
16:35:07 MQT: stat/lohas_light10/RESULT = {"POWER":"ON","Dimmer":100,"Color":"00000000FF","HSBColor":"294,100,0","White":100,"CT":500,"Channel":[0,0,0,0,100]}
16:35:07 MQT: stat/lohas_light10/RESULT = {"POWER":"ON","Dimmer":100,"Color":"00000000FF","HSBColor":"294,100,0","White":100,"CT":500,"Channel":[0,0,0,0,100]}
16:35:12 MQT: stat/lohas_light10/RESULT = {"Fade":"OFF"}
16:35:12 MQT: stat/lohas_light10/RESULT = {"POWER":"OFF"}
16:35:12 MQT: stat/lohas_light10/POWER = OFF

For some reason, FADE is OFF.

Also, tasmota supports relative fade now (SetOption117), so this is probably no longer needed:

hatasmota/hatasmota/light.py

Line 318 in 8138a50

if do_transition:

Virtual relays

tasmota32 added a feature to enable developers to add virtual relays that are above real relay list. Currently tasmota HA integration adds those as switch_n with n from relay number on tasmota. The functionality in HA is then limited to switch, but it should work as a relay as the driver that produced them expects them to be interactive.

v0.0.27 + Hass 0.117.4 + Tasmota 9.0.0.3 - Python error

1. Updates Hass to 0.117.4
2. Flashed a light to 9.0.0.3
3. Ran docker exec -ti homeassistant pip install -U hatasmota to update to v0.0.27.

I'm receiving this error:

2020-11-05 01:05:14 ERROR (MainThread) [homeassistant.util.logging] Exception in discovery_message_received when handling msg on 'tasmota/discovery/D8F15B0DC328/config': '{"ip":"192.168.1.152","dn":"Spot02","fn":["Spot02",null,null,null,null,null,null,null],"hn":"tasmota_0DC328-0808","mac":"D8F15B0DC328","md":"ZolderGU10","ty":0,"if":0,"ofln":"Offline","onln":"Online","state":["OFF","ON","TOGGLE","HOLD"],"sw":"9.0.0.3","t":"tasmota_0DC328","ft":"%prefix%/%topic%/","tp":["cmnd","stat","tele"],"rl":[2,0,0,0,0,0,0,0],"swc":[-1,-1,-1,-1,-1,-1,-1,-1],"swn":[null,null,null,null,null,null,null,null],"btn":[0,0,0,0],"so":{"4":0,"11":0,"13":0,"17":0,"20":0,"30":0,"68":0,"73":0,"82":0,"114":0},"lk":1,"lt_st":5,"ver":1}'
Traceback (most recent call last):
File "/usr/local/lib/python3.8/site-packages/hatasmota/discovery.py", line 158, in discovery_message_received
payload = TasmotaDiscoveryMsg(json.loads(payload))
File "/usr/local/lib/python3.8/site-packages/hatasmota/discovery.py", line 117, in __init__
config = TASMOTA_DISCOVERY_SCHEMA(config)
File "/usr/local/lib/python3.8/site-packages/voluptuous/schema_builder.py", line 272, in __call__
return self._compiled([], data)
File "/usr/local/lib/python3.8/site-packages/voluptuous/schema_builder.py", line 594, in validate_dict
return base_validate(path, iteritems(data), out)
File "/usr/local/lib/python3.8/site-packages/voluptuous/schema_builder.py", line 432, in validate_mapping
raise er.MultipleInvalid(errors)
voluptuous.error.MultipleInvalid: extra keys not allowed @ data['if']

Seems to be related to https://github.com/emontnemery/hatasmota/blob/master/hatasmota/discovery.py#L92

Feature Request: Start Tasmota Firmware Update via Homeassistant

Homeassistant has a cool new feature, where integrations can display if its device has a firmware update available.
https://www.home-assistant.io/integrations/update/

Would it be possible to implement this?
Would be quite nice, to have this update sensor and start firmware updates through Homeassistant.

arendst/Tasmota#15480

Tasmota integration crashes on unsupported, new SwitchMode code

Context

Home Assistant

Home Assistant 2023.1.4
Supervisor 2022.12.1
Frontend 20230110.0 - latest

Remote device

Tasmota 12.3.1
Shelly1 Plus (ESP32)

Symptom

Tasmota device (here, Shelly1 Plus) appears in the Tasmota devices with the usual bells and whistles, except that the Controls and Sensors pane are not shown. If a previous entity was tied to the control/sensor, it is reported in the Lovelace UI as "This entity is no longer being provided by the tasmota integration"

Log file

Traceback (most recent call last):
    File "/usr/local/lib/python3.10/site-packages/hatasmota/discovery.py", line 234, in discovery_message_received await device_discovered(payload, mac)
    File "/usr/src/homeassistant/homeassistant/components/tasmota/discovery.py", line 260, in async_device_discovered tasmota_triggers = tasmota_get_triggers(payload)
    File "/usr/local/lib/python3.10/site-packages/hatasmota/discovery.py", line 540, in get_triggers triggers.extend(get_switch_triggers(discovery_msg))
    File "/usr/local/lib/python3.10/site-packages/hatasmota/discovery.py", line 528, in get_switch_triggers trigger = TasmotaSwitchTriggerConfig.from_discovery_message(discovery_msg, idx)
    File "/usr/local/lib/python3.10/site-packages/hatasmota/switch.py", line 192, in from_discovery_message _, _, triggers = SWITCHMODE_MAP[switchmode] KeyError: 16

Root cause

New SwitchMode 16 is not supported. However Tasmota integration does not contain code to degrade gracefully on such condition, the configuration parser only raises an exception, which means that the controls and sensors are no longer available.

Patch

I'm not sure it is enough to address the new SwitchMode, but at least I can use my Shelly1 Plus device. I think a better fix would be to handle unmapped switch mode to report the actual error and keeps showing entities

diff --git a/hatasmota/const.py b/hatasmota/const.py
index 9a62ca3..79f974c 100644
--- a/hatasmota/const.py
+++ b/hatasmota/const.py
@@ -273,3 +273,5 @@ SWITCHMODE_PUSHHOLDMULTI_INV: Final = 12
 SWITCHMODE_PUSHON: Final = 13
 SWITCHMODE_PUSHON_INV: Final = 14
 SWITCHMODE_PUSH_IGNORE: Final = 15
+SWITCHMODE_PUSH_IGNORE_INV: Final = 16
+
diff --git a/hatasmota/switch.py b/hatasmota/switch.py
index c4abc8e..28357b5 100644
--- a/hatasmota/switch.py
+++ b/hatasmota/switch.py
@@ -31,6 +31,7 @@ from .const import (
     SWITCHMODE_PUSHON_INV,
     SWITCHMODE_TOGGLE,
     SWITCHMODE_TOGGLEMULTI,
+    SWITCHMODE_PUSH_IGNORE_INV,
 )
 from .entity import (
     TasmotaAvailability,
@@ -77,6 +78,7 @@ _LOGGER = logging.getLogger(__name__)
 # 13             PUSHON                YES (PIR)     NONE                          NONE                        NONE                        0,0
 # 14             PUSHON_INV            YES (PIR)     NONE                          NONE                        NONE                        0,0
 # 15             PUSH_IGNORE           YES           NONE                          NONE                        NONE                        0,0
+# 16             PUSH_IGNORE_INV       YES           NONE                          NONE                        NONE                        0,0
 # Please note: SwitchMode11 and 12 will register just TOGGLE (button_short_press)
 # Trigger types: "0 = none | 1 = button_short_press | 2 = button_long_press | 3 = button_double_press";
 # PIR: automatic off after 1 second
@@ -172,6 +174,11 @@ SWITCHMODE_MAP = {
         None,
         {STATE_TOGGLE: SW_TRIG_NONE, STATE_HOLD: SW_TRIG_NONE},
     ),
+    SWITCHMODE_PUSH_IGNORE_INV: (
+        True,
+        None,
+        {STATE_TOGGLE: SW_TRIG_NONE, STATE_HOLD: SW_TRIG_NONE},
+    ),
 }
 
 NO_POLL_SWITCHMODES = [SWITCHMODE_PUSHON, SWITCHMODE_PUSHON_INV]

2023.9.0 shows duplicate names on Tasmota devices

I just loaded 2023.9.0 and I'm seeing duplicate Tasmota device names. Didn't see then 2023.8.4.

Running tasmota 13.1 firmware, the latest.

Sensors with deep-sleep operations are mostly unavailable

Improvement-Request

I have a couple of Tasmota-based sensors that transmit values on MQTT every 5 minutes and are powered down otherwise.
The current integration recognizes these and detects them for home assistant, but any sensor entity does only display the value for 5-10 seconds. As soon as the device writes the LWT to offline, everything shows only "unavailable".

From the MQTT-side the Tasmota behaviour is correct, LWT tells listeners that the device will not respond. In HA otherwise it should be clear that the sensor is functioning normally, only if it does not update for more than 2*deep_sleep_time it could be considered really unavailable.

This is not only a problem for me but has been discussed on some forums:
The suggested workaround is, to configure a manual MQTT device and not use the Tasmota integration :-(

As the code in this project is generating the MQTT interactions and the status updates (available , unavailable) it should be addressed in this code.

Features:

• Deep sleep setup of sensors should be detected in Homeassistant
  (e.g. ESP last wakeup reason in /stat/$dev/STATUS1 or /tele/$dev/DEEPSLEEP)
• If deep sleep is detected, the availability should not go to unavailable on LWT=offline
• optional: there could be a timer triggered on LWT offline to mark the entities unavailable, if they are not alive for more than the usual deep-sleep period:
  ** this means HA must recognize the wakeup and deep-sleep and measure the usual sleep period
  ** the last wakeup is remembered
  ** the timer marks the device dead, after last-wakeup+deepsleep*safeftyfactor, if the device did not show up in between

Making this work for fans

I hope I'm posting this in the right place.

I have been experimenting with Tasmota 9.1.0 and the new Home Assistant Tasmota integration. I have noticed a limitation in the way these two pieces of software work together.

I have several fans in my home that are just box or floor fans connected to a smart plug. I also have a few ceiling fans that use Sonoff iFan02 fan controllers running Tasmota. When these devices present to Home Assistant they show up as switches. I know there is a Tasmota 'se toption30 1' that forces a switch to present itself as a light, but no such option for a fan. Could you make something like that for the a smart plug that should tell Tasmota that it is a fan?

Also, support for the iFan02 in any way would be awesome.

I have a few Wemos D1 mini devices that have random sensors and the like on them and they all work like a charm.

Keep up the good work!

[Feature request] Deduct `unit` from metric name and apply unit to value.

Current implementation of sensor.py is trying to match exact metric name to predefined list. If it matches a preconfigured unit is applied. All other metrics have no unit at all.

To keep the current JSON format compatible I vote for a naming pattern like "%%". This (or a similar) pattern could easily be provided in the JSON payload by SMI.

sensor.py would need to subtract "%%" from the metrics name and apply the according unit the value.

My Tasmota installation reads three meters and provides their readings like this:

{
  "Time": "2023-04-30T15:48:46",
  "Strom": {
    "P_in%%W": 998.34,
    "L1%%W": 4.29,
    "L2%%W": 645.19,
    "L3%%W": 348.86,
    "E_in%%kWh": 20687.329,
    "E_out%%kWh": 0
  },
  "SekHK": {
    "Temp_Outside%%°C": 13,
...

Split total energy sensors

Since Tasmota 9.5.0.9 there is a new SetOption129 to enable split total energy results.
see here: arendst/Tasmota@d3fc03d

When enabling SetOption129 this error will appear in the home assistant logs:

File "/usr/local/lib/python3.9/site-packages/hatasmota/sensor.py", line 291, in state_message_received
last_reset := state.get(last_reset_key)
AttributeError: 'list' object has no attribute 'get'
2021-10-16 20:42:00 ERROR (MainThread) [homeassistant.util.logging] Exception in state_message_received when handling msg on 'tele/tasmota_gardenshed/SENSOR': '{"Time":"2021-10-16T19:42:00","Switch1":"OFF","Switch2":"OFF","ANALOG":{"Temperature":40.3},"ENERGY":{"TotalStartTime":"2021-10-16T16:23:32","Total":[20.944,0.001],"Yesterday":[0.000,0.000],"Today":[0.030,0.001],"Period":[ 0, 0],"Power":[ 0, 0],"ApparentPower":[ 0, 8],"ReactivePower":[ 0, 8],"Factor":[0.00,0.03],"Frequency":50,"Voltage":235,"Current":[0.000,0.034]},"TempUnit":"C"}'

i think this change needs to be revised: #89

Deprecation Warning

Hey!
This is obviously not really an Issue, but just an Info for you if you haven't seen it already. On starting Home-Assistant you get this message:
/usr/local/lib/python3.8/site-packages/hatasmota/utils.py:165: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3, and in 3.9 it will stop working
So whenever 3.8 python is dropped for Homeassistant aswell it wont work anymore.

iFan03 shows boolean actions for light and fan with same name in visual editor

This is "just" a visual issue. Functional it all works.

As per tasmota instructions I added my iFan03 via TasmotaDiscovery (SetOption19 0) and used the Tasmota Integration.
The device is picked up correctly, and I see all entities.
Yet when making an automation and selection Action->Device->[the iFan] i get the options off/on/toggle twice: once for the fan and once for the light, with the exact same name:

The first triplet seems to be always for the fan, as i amused from the device overview:

It is obvious in the YAML editor only (see below). For someone using the visual editor not so much (refer to first image).

...
    sequence:
      - type: toggle
        device_id: 3ee2e1fa9c95a0bf51c0b18114430e99
        entity_id: light.ifan03
        domain: light
...

My 'Config -> Other' Setup on the iFan itself:

'Config -> MQTT'

Remove release pinning

At the moment the requirements are pinned.

attrs==19.3.0
voluptuous==0.12.1

This is an issue for distribution packages. E. g., the Fedora RPM of attrs package is already at 20.3.0. The voluptuous NixOS package is still at 0.12.0. This blocks the usage of the system-wide Python packages. It works for Home Assistant but it's still possible that there is a miss-match one say that will cause issues.

Could you please consider to soften the requirements? Thanks

Fade gets reset when controlling my light using the hatasmota entity.

Hey!

So whats happening is, that when I turn on Fade my light works all fine fading the light on and off. After then I try to control the light over Homeassistant and the fade option is reset.

The Commands I used to accomplish this were:

Fade On
SetOption91 1

~~Feature request:~~ Bug? Update of Dimmer/Color/CT without turning power on

Tasmota SetOption20 1 enables updating Dimmer/Color/CT values without turning the power on
(source: https://tasmota.github.io/docs/Commands/#setoptions)

I have a Tuya LED that defaults to white when sending boolean data to the light DpId, no matter the previous state. Hatasmota sending a command Backlog NoDelay;Power2 ON;NoDelay;HsbColor1 <H>;NoDelay;HsbColor2 <S> results in the color first visibly switching to white and eventually to the new color.

I suggest having hatasmota read the value of option20 and change the command accordingly.

Feature request: Add an attribute to identify entities as related to the tasmota integration

I would like to be able to write a template in HA to pick up the IP addresses of all tasmota devices. I have several other sensors that have states that are IP addresses on my local network as well. I need to be able to differentiate those that come from the tasmota integration from the others. As of right now, there's no way for me to tell a tasmota-integration-created light from my manual MQTT light hand-written in YAML, nor the IP address sensors from my manually-created ones.

I would suggest adding an attribute similar to, (or exactly :))

  integration: tasmota

to all the entities created by the integration so we can tell in a template that we're dealing with a tasmota-integration-created entity.

Frankly, I think all integration-created entities should have something like this.

Feature Request: Device Firmware version as a sensor

I would like to see the Device Firmware version reported as a sensor please. This would allow monitoring for outdated firmware versions by tracking sensors on homeassistant.

Temperature in history graph

I'm using new tasmota integration. On "entity card" temperature is shown correctly with unit of mesurment "°C" but in "history graph" unit of mesurment is "C", so if I have two temperatures on history graph, one from tasmota and second from other sensor, I'm geting two history graphs instead of one.
Tasmota 9.1.0.1, HA 0.118

Alexa losing iFan03 Light on home assistant reboot

Every time I restart home assistant, only the fan portion continues to work. The light becomes unresponsive through the Alexa app.
I have an iFan03 in my living room and dining room and both have the same issue.
HomeKit has no problems staying in sync with all entities.
I may have posted this in the wrong area.
Not sure how to delete

Support of Shutter Tilt in automation

Tasmota got better support of shutters and tilting and it is possible to specify position and tilt at once.

E.g. MQTT message cmnd/tasmota_48CEEC/ShutterPosition1 0,-45 will close blinds and then tilt to 45°.

With these single combined command there is no need to wait between ShutterPosition and ShutterTilt command.

I'm sure this would be very helpful to implement into automation as it's possible to set only position at the moment.

Looking for an example on how to invoke hatasmota

Looking for docs on how to interpret the new /tasmota/discovery/... messages I was pointed to this repository by @arendst . Would you mind creating or adding an Python example on how to invoke the code from hatasmota?!
Thx!

BTW: doc issue in Tasmota repo: arendst/Tasmota#18417

Sensor unit discovery for multi value sensor

I'm trying to use https://tasmota.github.io/docs/Smart-Meter-Interface for PV inverter and I have script that shows sensors in HA, but there is an issue is with unit and icons, which only work when name is exact as configured in SENSOR_UNIT_MAP (sensor.py). It means that I can have for example "Voltage" sensor only one, but in reality I have 5 voltage sensor 2 on DC site and 3 for AC site, so when I name "Voltage DC1" etc., standard sensor with unit ' ' is displayed.

The question is:
Is it possible to add support for unit discovery if any on standard matching doesn't works? Means if unit not selected check if quantity String contains any of key for SENSOR_UNIT_MAP, if yes, unit is selected. This will allow to have multiple name for example "DC1 Voltage" or "Voltage DC1" or "Voltage.DC1" in any of those case "Voltage" unit will be selected.

I tried to analyse code and it's look like it's only option (correct me if I'm wrong), because units are not passed in "Tasmota integration", there are units passed in "HA integration", but this will require change in Tasmota for HA integration and I assume it will become obsolete in future, so I prefer find a solution for "Tasmota integration".

Feature request: set default sensors for newly discovered devices

The TASMOTA integration brings with it a lot of sensors, which, most of the time I don't bother enabling. However I usually do want the RSSI sensor and the firmware version sensor, in addition to any sensors coming from humidity, temperature, light sensors, which is probably why the device was set up in the first place.

Would it be possible to configure a set of sensors for newly discovered devices that will be automatically enabled so that I don't have to go through and manually enable those sensors every time?