tasmota beta - sonoff 4chpro unavailable

[S-Przybylski]

The problem

After upgrading my Sonoff 4CHProR2 to Tasmota 9.0.0.2 and switch Setoption19 0 tried to use the new tasmota integration without success. The integration includes four switches and one deactivated status binary sensor for the new device but they are all unavailable. The log doesn't show any warnings or errors related to that. I have deleted the integration and added it again (discovery topic: tasmota/discovery) My fulltopic follows not the tasmota default. Its turned around %topic%/%prefix%/ The hostname and the %topic% is default

I read the currently unpublished documentation: Perhaps it should be stated that setoption 19 should be disabled and the firmware should be newer that 9.0.x.x... (if not updated meanwhile)

Before i have used the existing method with setoption19 1 and MQTT discovery - it worked (without the tasmota integration).

Environment

• Home Assistant Core release with the issue: 0.118.0.dev20201025
• Last working Home Assistant Core release (if known): -
• Operating environment (OS/Container/Supervised/Core): HA Container - Docker on RASPI 4
• Integration causing this issue: tasmota
• Link to integration documentation on our website: - currently not visible / not published so far

Problem-relevant configuration.yaml

automatic discovery through integration tasmota used

Traceback/Error logs

MQTT:
tasmota/discovery/<mac>/config
{"ip":"10.10.x.y","dn":"Sonoff4CHProR2","fn":["Tasmota","Tasmota2","Tasmota3","Tasmota4",null,null,null,null],"hn":"tasmota_xxxxxx-zzzz","mac":"xxxxxx","md":"Sonoff 4CH Pro","ty":0,"ofln":"Offline","onln":"Online","state":["OFF","ON","TOGGLE","HOLD"],"sw":"9.0.0.2","t":"tasmota_xxxxxx","ft":"%prefix%/%topic%/","tp":["cmnd","stat","tele"],"rl":[1,1,1,1,0,0,0,0],"swc":[-1,-1,-1,-1,-1,-1,-1,-1],"btn":[0,0,0,0],"so":{"11":0,"13":0,"17":1,"20":0,"30":0,"68":0,"73":0,"80":0,"82":0},"lk":1,"lt_st":0,"ver":1}

tasmota/discovery/yyyyyyxxxxxx/sensors
{"sn":{"Time":"2020-10-25T12:45:58"},"ver":1}

tasmota_xxxxxx/tele/LWT
Online

tasmota_xxxxxx/tele/STATE
{"Time":"2020-10-25T13:25:01","Uptime":"0T00:39:27","UptimeSec":2367,"Heap":26,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"POWER1":"OFF","POWER2":"ON","POWER3":"ON","POWER4":"ON","Wifi":{"AP":1,"SSId":"ssid","BSSId":"xx:xx:xx:xx:xx:xx","Channel":1,"RSSI":100,"Signal":-50,"LinkCount":1,"Downtime":"0T00:00:21"}}

HA Log: nothing!

Additional information

Note: This is not relevant for the current problem! Before upgrading to 9.0.0.2 (running 8.5.1) and disabling setoption19 (to 0) i sometimes got an error message from this integration within HA. It seems that the integration doesn't filter (block) discoveries with an version less than 9.x.x.x. The integration doesn't show any device...:

2020-10-25 12:05:08 ERROR (MainThread) [homeassistant.util.logging] Exception in discovery_message_received when handling msg on 'tasmota/discovery/<mac>/config': '{"ip":"10.10.x.y","dn":"Sonoff4CHProR2","fn":["Tasmota","Tasmota2","Tasmota3","Tasmota4",null,null,null,null],"hn":"tasmota_xxxxxx-xxxx","mac":"<mac>","md":"Sonoff 4CH Pro","ofln":"Offline","onln":"Online","state":["OFF","ON","TOGGLE","HOLD"],"sw":"8.5.1","t":"tasmota_xxxxxx","ft":"%prefix%/%topic%/","tp":["cmnd","stat","tele"],"rl":[1,1,1,1,0,0,0,0],"swc":[-1,-1,-1,-1,-1,-1,-1,-1],"btn":[0,0,0,0],"so":{"11":0,"13":0,"17":1,"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.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: required key not provided @ data['so']['82']

[probot-home-assistant[bot]]

Hey there @emontnemery, mind taking a look at this issue as its been labeled with an integration (tasmota) you are listed as a codeowner for? Thanks! _{^{(message by CodeOwnersMention)}}

[emontnemery]

I'll try to reply to the issues one by one:

• Sonoff 4CHProR2 to Tasmota 9.0.0.2 shown as unavailable

  • I also think it's related to fulltopic not following the Tasmota default. You mention you have configured it as "%prefix%/%topic%/", and the Tasmota discovery messageals says: "%prefix%/%topic%/"
  • However, in your examples messages are received on tasmota_xxxxxx/tele/LWT which is the other way around: "%topic%/%prefix%/"
  • What is the result of command fulltopic on Tasmta console?
  • Can you collect a startup log with tasmota logs enabled please:

    logger:
    default: info
    logs:
    hatasmota: debug
    homeassistant.core: debug
    homeassistant.components.mqtt: debug
    homeassistant.components.tasmota: debug

• Perhaps it should be stated that setoption 19 should be disabled and the firmware should be newer that 9.0.x.x

  • I think this is covered by the documentation: https://rc.home-assistant.io/integrations/tasmota/

• Before upgrading to 9.0.0.2 (running 8.5.1) and disabling setoption19 (to 0) i sometimes got an error message from this integration within HA.

  • In Tasmota versions just before 9.0.0.2, the discovery format was under development so these errors are expected.

[S-Przybylski]

Hi @emontnemery thank you for your fast reaction and passion to work on that! Great!

• Sonoff4CHProR2 I just looked up the topic in the web interface of tasmota: %topic%/%prefix%/ I rechecked the MQTT discovery message: "ft":"%prefix%/%topic%/" - that's strange I just restarted the sonoff and again i got the message: tasmota/discovery//config: ... "ft":"%prefix%/%topic%/" ... I delete the retained message tasmota/discovery/macadr/config and checked with an reconnect of my mqtt client that its in no longer present. Then i restart the sonoff and again: "ft":"%prefix%/%topic%/"

  tasmota/discovery/macadr/config: {"ip":"10.10.x.y","dn":"Sonoff4CHProR2","fn":["Tasmota","Tasmota2","Tasmota3","Tasmota4",null,null,null,null],"hn":"tasmota_xxxxxx-yyyy","mac":"zzzzzzxxxxxx","md":"Sonoff 4CH Pro","ty":0,"ofln":"Offline","onln":"Online","state":["OFF","ON","TOGGLE","HOLD"],"sw":"9.0.0.2","t":"tasmota_xxxxxx","ft":"%prefix%/%topic%/","tp":["cmnd","stat","tele"],"rl":[1,1,1,1,0,0,0,0],"swc":[-1,-1,-1,-1,-1,-1,-1,-1],"btn":[0,0,0,0],"so":{"11":0,"13":0,"17":1,"20":0,"30":0,"68":0,"73":0,"80":0,"82":0},"lk":1,"lt_st":0,"ver":1}

  --> So I assume that the tasmota device send the wrong fulltopic for tasmota/discovery Do you have another idea? Should we close this issue then?

• Documentation - you are right - i found an older pull request i looked into ... - sorry

• Version 8.5.1 - Due to the fact that the current released (officially) version is 8.5.1 and not 9.x, i think i make sense to handle (block) this too (many people use the mqtt configuration manually -like i have done before). Perhaps it could come form enabling Setoption19 in 8.5.1 before.

[S-Przybylski]

As you can see i just raised an issue at tasmota

[effelle]

Fixed on my side Erik, you can close here.

[S-Przybylski]

Dear @emontnemery I just checked 9.0.0.3 - it worked! But i found out that it requires to setoption59. This integration seems to wait for tele messages as a response. Could you kindly recheck my result and perhaps add an notice to the docs to enable setoption59 (1)?

Setoption59 is set to on if you set option19 to on (but its not reseted) - see Tasmota docs. Therefore a fresh installation without setoption19 would fail i think.

[emontnemery]

@S-Przybylski Oops, you're right about setoption59, here's a PR to add it to the docs: https://github.com/home-assistant/home-assistant.io/pull/15417. Edit: And another one which makes setoption59 not necessary: https://github.com/home-assistant/core/pull/42394

[S-Przybylski]

Dear @emontnemery cool using the stat topic instead of the additional tele topic is definitly more straight forward for relay and lights! Now my mqtt group message "tasmotas/cmnd/power" grabs the current status of the relays again at startup (using an automation). I appreciate that! Today i upgraded a sonoff basic from 8.5.1 to 9.0.0.3. Before upgrading it uses setoption19. After the upgrade i switched it off and the integration took the configured switch and sensors over from mqtt discovery protocol without intervention. Really cool!

I have one recommendation. Perhaps its could be mentioned in the docs to disable setoption 59 (=0) to disable the telemetry messages, because this are no longer necessary.

[S-Przybylski]

Dear @emontnemery I just checked my sensors and found out that the naming convention differs from the mqtt discovery one. Example:

• Before - MQTT discovery: sensor.wohnzimmer_si7021_temperature
• After - Tasmota discovery: sensor.si7021_temperature Could you please check that too?

[emontnemery]

I just checked my sensors and found out that the naming convention differs from the mqtt discovery one. Before - MQTT discovery: sensor.wohnzimmer_si7021_temperature After - Tasmota discovery: sensor.si7021_temperature

Hmm, the idea was to not include the device name in the entity's friendly name since it's a bit redundant. Agreed the entity_id is not good though.

How about like this: Friendly name: "SI7021 Temperature" entity_id: sensor.wohnzimmer_si7021_temperature

[SirGoodenough]

When you have more than 1 device with a similar sensor, it is not good. Something is needed to tie the sensor to the device so you know what is what... In this picture you see what happens when I have devices with the same sensor in the system. I have a half dozen of these...

[effelle]

Damn you're right James. @emontnemery I think is better revert to the old name structure devicename_sensorname_subsensortype for the displayed name too...

[S-Przybylski]

Hi I opened a new issue in parallel to your discussion. Perhaps you could use that to process further...

42603

[blakadder]

sensors entity_id should definitely contain devicename so you can differentiate between devices.

[emontnemery]

Let's continue the discussion in #42603, instead of in this closed and fixed issue 👍