One more issue that I need help with regarding my upgrade to 2022.11.5 and mqtt/Tasmota

Configuration
1

I have three lights that are configured in configuration.yaml instead of the Tasmota integration because of the way they work (was true back then). They are three way switches that uses rules and a virtual button to simulate the three way. Since the upgrade of either HA or Tasmota (they were at 8.5.2 and were upgraded to 12.2), it triggers errors in the homeassistant.log at startup.

This is how they are configured in configuration.yaml

mqtt:
  light:
    - name: "LumiereGarage"
      state_topic: "stat/LumiereGarage/POWER1"
      command_topic: "cmnd/LumiereGarage/EVENT"
      availability_topic: "tele/LumiereGarage/LWT"
      qos: 0
      payload_on: "ON"
      payload_off: "OFF"
      payload_available: "Online"
      payload_not_available: "Offline"
      retain: false
      unique_id: 500291B18117

This is what shows up in the homeassistant.log at startup.

2022-12-07 10:41:42.151 ERROR (MainThread) [homeassistant.util.logging] Exception in discovery_message_received when handling msg on 'tasmota/discovery/500291B18117/config': '{"ip":"192.168.2.176","dn":"LumiereGarage","fn":["LumiereGarage","LumiereGarage2",null,null,null,null,null,null],"hn":"LumiereGarage-0279","mac":"500291B18117","md":"Generic","ofln":"Offline","onln":"Online","state":["OFF","ON","TOGGLE","HOLD"],"sw":"8.5.1","t":"LumiereGarage","ft":"%prefix%/%topic%/","tp":["cmnd","stat","tele"],"rl":[1,1,0,0,0,0,0,0],"swc":[-1,-1,-1,-1,-1,-1,-1,-1],"btn":[0,0,0,0],"so":{"11":0,"13":1,"17":0,"20":0,"30":0,"68":0,"73":0,"80":0},"lk":1,"lt_st":0,"ver":1}'
Traceback (most recent call last):
  File "/usr/local/lib/python3.10/site-packages/hatasmota/discovery.py", line 213, in discovery_message_received
    payload = TasmotaDiscoveryMsg(json.loads(_payload))
  File "/usr/local/lib/python3.10/site-packages/hatasmota/discovery.py", line 163, in __init__
    config = TASMOTA_DISCOVERY_SCHEMA(config)
  File "/usr/local/lib/python3.10/site-packages/voluptuous/schema_builder.py", line 272, in __call__
    return self._compiled([], data)
  File "/usr/local/lib/python3.10/site-packages/voluptuous/schema_builder.py", line 595, in validate_dict
    return base_validate(path, iteritems(data), out)
  File "/usr/local/lib/python3.10/site-packages/voluptuous/schema_builder.py", line 433, in validate_mapping
    raise er.MultipleInvalid(errors)
voluptuous.error.MultipleInvalid: required key not provided @ data['so']['82']

From what I gather, ‘so’ here stands for SetOption and I’m puzzled why it needs to get SetOption82 which is “Reduce the CT range from 153..500 to 200..380 to accommodate with Alexa range”.

How can I stop there errors? Might be OCD from my part but I like to see my log clean :slight_smile:

Thanks again

2

HA Tasmota discovery requires an “83” key inside “so”. The only way to remove that error is to have it included in that discovery information.

3

Thanks, do you have a link or doc that explains how to do that?

4

:man_shrugging: I don’t know enough about tasmota to tell you why it’s happening. I just understand the error.

5

Ok, thanks. It gives me a path to look into.

6

That’s showing software 8.5.1

Have a look in mqtt Explorer for an old retained message.

7

Oh my mistake. Those lights are still at 8.5.1 as they were still working in HomeAssistant unlike all my other lights that were autodiscovered (SetOption19 1). So the message is not staled.

8

If they are auto discovered, you wouldn’t need the manual yaml config.

I’d probably be inclined to turn off setoption19, seeing as you have the yaml config.

Probably worth asking about the error on the tasmota discord though. They might have a better suggestion.

9

SetOption19 is already at 0 for those since they are configured in configuration.yaml. All the other lights were auto discovered.

I’m currently typing a message to the Tasmota Google group to see if if someone can help there too.

10

If so19 is off delete the discovery config message from mqtt-Explorer then. It shouldn’t be there.

11

Oh, that make sense. I’ll give it a try.

12

Although, looking at that again… If so19 is off, it will be trying to use the tasmota discovery I think. Which is where that error looks like it’s coming from.

So it would probably be published again by the device on restart. Hard to say on such an old version.

13

I’ll upgrade their firmware to 12.2. So far the lights I upgraded to it are working fine.

Edit: They are still at 8.5.1 and looking at MQTT Browser, they are still absent from tasmota/discovery.

Edit2: But after a reboot of the device, the device is back under tasmota/discovery. So let’s try a firmware upgrade.

Edit3: Yep, that fixed it. Option82 is sent part of the auto discovery now :slight_smile:

 "so": {
    "4": 0,
    "11": 0,
    "13": 1,
    "17": 0,
    "20": 0,
    "30": 0,
    "68": 0,
    "73": 0,
    "80": 0
    **"82": 0,**
    "114": 0,
    "117": 0
  },