Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Home Assistant Discovery Names Not Correct #8462

Closed
15 tasks done
Cerothen opened this issue May 17, 2020 · 12 comments · Fixed by #8470
Closed
15 tasks done

Home Assistant Discovery Names Not Correct #8462

Cerothen opened this issue May 17, 2020 · 12 comments · Fixed by #8470
Labels
enhancement Type - Enhancement that will be worked on fixed Result - The work on the issue has ended

Comments

@Cerothen
Copy link

PROBLEM DESCRIPTION

Using the latest Tasmota release build (v8.3.0) self compiled using the guide from the WIKI for platformIO the name supplied as well as the tasmota.bin.gz build supplied in the releases on the github project. When SetOption19 1 is set the NAME sent for the sensors is the firmware default Friendly Name and not the system's current friendly name but the firmware default friendly name.

REQUESTED INFORMATION

Make sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!

  • Read the Contributing Guide and Policy and the Code of Conduct
  • Searched the problem in issues
  • Searched the problem in the docs
  • Searched the problem in the forum
  • Searched the problem in the chat
  • Device used (e.g., Sonoff Basic): Teckin SP20
  • Tasmota binary firmware version number used: Version 8.3.0
    • Pre-compiled
    • Self-compiled
      • IDE / Compiler used: PlatformIO CLI
  • Flashing tools used: WebGUI (original method Tuya Convert)
  • Provide the output of command: Backlog Template; Module; GPIO 255:
03:13:31 MQT: stat/sp20_E64956/RESULT = {"NAME":"Generic","GPIO":[255,255,255,255,255,255,255,255,255,255,255,255,255],"FLAG":15,"BASE":18}
03:13:31 MQT: stat/sp20_E64956/RESULT = {"Module":{"59":"Teckin US"}}
03:13:32 MQT: stat/sp20_E64956/RESULT = {"GPIO0":{"56":"Led1i"},"GPIO1":{"0":"None"},"GPIO2":{"158":"LedLinki"},"GPIO3":{"0":"None"},"GPIO4":{"21":"Relay1"},"GPIO5":{"134":"BL0937 CF"},"GPIO9":{"0":"None"},"GPIO10":{"0":"None"},"GPIO12":{"131":"HLWBL SELi"},"GPIO13":{"17":"Button1"},"GPIO14":{"132":"HLWBL CF1"},"GPIO15":{"0":"None"},"GPIO16":{"0":"None"}}
  • If using rules, provide the output of this command: Backlog Rule1; Rule2; Rule3:
 NO RULES
  • Provide the output of this command: Status 0:
03:14:44 MQT: stat/sp20_E64956/STATUS = {"Status":{"Module":59,"FriendlyName":["sp20_E64956"],"Topic":"sp20_E64956","ButtonTopic":"0","Power":0,"PowerOnState":3,"LedState":1,"LedMask":"FFFF","SaveData":1,"SaveState":1,"SwitchTopic":"0","SwitchMode":[0,0,0,0,0,0,0,0],"ButtonRetain":0,"SwitchRetain":0,"SensorRetain":0,"PowerRetain":0}}
03:14:44 MQT: stat/sp20_E64956/STATUS1 = {"StatusPRM":{"Baudrate":115200,"SerialConfig":"8N1","GroupTopic":"tasmotas","OtaUrl":"http://thehackbox.org/tasmota/release/tasmota.bin","RestartReason":"Software/System restart","Uptime":"0T00:06:15","StartupUTC":"2020-05-17T02:08:29","Sleep":50,"CfgHolder":4617,"BootCount":5,"BCResetTime":"2020-05-17T03:04:37","SaveCount":12,"SaveAddress":"F8000"}}
03:14:45 MQT: stat/sp20_E64956/STATUS2 = {"StatusFWR":{"Version":"8.3.0(tasmota)","BuildDateTime":"2020-05-14T16:17:08","Boot":31,"Core":"2_7_1","SDK":"2.2.2-dev(38a443e)","Hardware":"ESP8266EX","CR":"376/699"}}
03:14:45 MQT: stat/sp20_E64956/STATUS3 = {"StatusLOG":{"SerialLog":2,"WebLog":2,"MqttLog":0,"SysLog":0,"LogHost":"","LogPort":514,"SSId":["Athens",""],"TelePeriod":300,"Resolution":"558180C0","SetOption":["000A8009","2805C8000100060000005A00000000000000","00000200","00000000"]}}
03:14:45 MQT: stat/sp20_E64956/STATUS4 = {"StatusMEM":{"ProgramSize":588,"Free":412,"Heap":25,"ProgramFlashSize":1024,"FlashSize":1024,"FlashChipId":"144068","FlashMode":3,"Features":["00000809","8FDAE797","043683A0","000000CD","010013C0","C000F981","00000024"],"Drivers":"1,2,3,4,5,6,7,8,9,10,12,16,18,19,20,21,22,24,26,27,29,30,35,37","Sensors":"1,2,3,4,5,6"}}
03:14:45 MQT: stat/sp20_E64956/STATUS5 = {"StatusNET":{"Hostname":"sp20_E64956-2390","IPAddress":"192.168.11.234","Gateway":"192.168.10.1","Subnetmask":"255.255.254.0","DNSServer":"192.168.10.3","Mac":"68:C6:3A:E6:49:56","Webserver":2,"WifiConfig":4,"WifiPower":17.0}}
03:14:45 MQT: stat/sp20_E64956/STATUS6 = {"StatusMQT":{"MqttHost":"mqtt.urech.ca","MqttPort":1883,"MqttClientMask":"DVES_%06X","MqttClient":"DVES_E64956","MqttUser":"mosq_device","MqttCount":1,"MAX_PACKET_SIZE":1200,"KEEPALIVE":30}}
03:14:45 MQT: stat/sp20_E64956/STATUS7 = {"StatusTIM":{"UTC":"2020-05-17T02:14:45","Local":"2020-05-17T03:14:45","StartDST":"2020-03-29T02:00:00","EndDST":"2020-10-25T03:00:00","Timezone":"+01:00","Sunrise":"05:05","Sunset":"20:27"}}
03:14:45 MQT: stat/sp20_E64956/STATUS9 = {"StatusPTH":{"PowerDelta":0,"PowerLow":0,"PowerHigh":0,"VoltageLow":0,"VoltageHigh":0,"CurrentLow":0,"CurrentHigh":0}}
03:14:45 MQT: stat/sp20_E64956/STATUS10 = {"StatusSNS":{"Time":"2020-05-17T03:14:45","ENERGY":{"TotalStartTime":"2020-05-17T03:04:37","Total":0.000,"Yesterday":0.000,"Today":0.000,"Power":0,"ApparentPower":0,"ReactivePower":0,"Factor":0.00,"Voltage":0,"Current":0.000}}}
03:14:45 MQT: stat/sp20_E64956/STATUS11 = {"StatusSTS":{"Time":"2020-05-17T03:14:45","Uptime":"0T00:06:16","UptimeSec":376,"Heap":25,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"POWER":"OFF","Wifi":{"AP":1,"SSId":"Athens","BSSId":"80:2A:A8:94:8F:ED","Channel":6,"RSSI":90,"Signal":-55,"LinkCount":1,"Downtime":"0T00:00:03"}}}
  • Provide the output of the Console log output when you experience your issue; if applicable:
    (Please use weblog 4 for more debug information)
03:15:34 CFG: Saved to flash at F7, Count 13, Bytes 4096

TO REPRODUCE

Steps to reproduce the behavior:
Device Teckin SP20
Module Teckin US (59)

  1. Flash Firmware
  2. Reset Config (clear anything latent)
  3. Set Wifi
  4. Set MQTT
  5. Set Friendly Name
  6. Set Set Module
  7. Run SetOption19 1

EXPECTED BEHAVIOUR

Name of sensors use currently configured friendly name as indicated here:
https://github.com/arendst/Tasmota/blob/development/tasmota/xdrv_12_home_assistant.ino#L697

SCREENSHOTS

If applicable, add screenshots to help explain your problem.
image

ADDITIONAL CONTEXT

Add any other context about the problem here.

(Please, remember to close the issue when the problem has been addressed)

@dedors
Copy link

dedors commented May 17, 2020

I just encountered this problem, it started to happen as soon as I upgraded to 8.3.0.
The device was listed as "Sonoff Basic", with on entity (switch) working correctly (and correct name) and one entity (sensor) with also "Sonoff Basic" name that stayed unavailable. I tried with deleting the entity and different mqtt and friendly name settings for over an hour, which all seem to fail with 2 Sonoff Basics.
I reverted back to 8.2.0 and everything is fine again.

@Cerothen
Copy link
Author

I also noticed on V8.2.0 that it worked. However the status sensor has the same issue in that version (instead of all of the sensors)

@Jason2866
Copy link
Collaborator

Jason2866 commented May 17, 2020

With 8.3.0 friendly name is not used anymore for HA AD.
The template name of the device is used instead.
See https://tasmota.github.io/docs/

@Cerothen
Copy link
Author

Cerothen commented May 17, 2020

That seems like a strange decision, is there a particular reason?

Given that the module name is not directly configurable it makes it hard to differentiate between devices that use the same module within Home Assistant. Home assistant will add an index to each plug "_#" if there are more than one but that is assigned based on the order they come in. Additionally it makes it harder to identify the devices when setting things up in Home Assistant since a person would always have to identify the correct device and related sensors instead of them being named intuitively from the friendly name.

Also, the template/module name per the documentation linked is used only for the sensors not the actual relay name (see screenshot from my original message)

@Cerothen
Copy link
Author

To further the comments above, and re-reading the updated documentation, It is indicated that "the device name in Home Assistant integrations which can be easily changed directly in the Home Assistant UI after the discovery is complete" which is true, but for devices that have a lot of values (the SP20 has 11 reported sensors) I would have to open up 11 sensors and the actual switch/relay entity for all 22 of my plugs and set the name AND entity ID for each device thats 528 fields to manage AFTER the discovery by hand PLUS the friendly name in the device itself. The alternative of which was to just set the friendly name on the device then SetOption19 1. Additionally it makes changing the device's name (say if it was moved) more cumbersome since that's 24 fields in home assistant that need to be updated and 1 tasmota. Meanwhile by using the friendly name a person could just Set the friendly name in tasmota then toggle SetOption19 to zero(0) and back to one(1).

@Jason2866
Copy link
Collaborator

Jason2866 commented May 17, 2020

Template name is free configurable. Template name can be different from module name.
Anyway this was a request from HA users. It was done this way not wasting the rare flash space.
Tasmota is not designed to statisfy only HA wishes. It is designed to be a general mqtt solution.
The actual behaviour will not be changed.

@Cerothen
Copy link
Author

So to confirm the change was done not to improve home assistant integration but rather to free up flash space for other purposes?

Additionally is it a bug that the relay is named using the friendly name and the sensors are named using the module name? Shouldn't all these be using the same name?

Anyways, I can respect that the project is not directed toward HA specifically and will not press, I will however request some assistance identifying the appropriate commit that made this change. I can revert it and compile myself to achieve the desired result.

Thanks for your clarification

@Jason2866
Copy link
Collaborator

Jason2866 commented May 17, 2020

Done with #8242 see #8298 too

@effelle effelle added the Requires more research (devs) Action - Issue requires more research label May 17, 2020
@effelle
Copy link
Contributor

effelle commented May 17, 2020

Hold on. I will investigate on it. #8298 reopened.

@effelle effelle linked a pull request May 17, 2020 that will close this issue
6 tasks
@Jason2866
Copy link
Collaborator

@Cerothen I tnink you are happy now 😀

@Cerothen
Copy link
Author

Just built the latest in the repository and it looks good, Should make the device management more straight forward! Thanks @effelle

@effelle effelle added fixed Result - The work on the issue has ended and removed Requires more research (devs) Action - Issue requires more research labels May 17, 2020
@effelle
Copy link
Contributor

effelle commented May 17, 2020

You're welcome, I hope all is fine now.

@ascillato2 ascillato2 added the enhancement Type - Enhancement that will be worked on label May 18, 2020
@mk-81 mk-81 mentioned this issue Jul 29, 2020
15 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Type - Enhancement that will be worked on fixed Result - The work on the issue has ended
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants