Announcement

**Michael McSharry** · August 14, 2020, 12:05 PM

Based upon the homeassistant topic below I expected the following devices to be created for topic as a /light/ type:

Based upon avty_t key: tele/LightSmall/LWT with VGP of Online and Offline
Based upon stat_t key: tele/LightSmall/STATE with VGP of OFF and ON using pub topic c mnd/LightSmall/POWER for control
Based upon bri_stat key: tele/LightSmall/STATE with slider range of 100 using pub topic cmnd/LightSmall/Dimmer for control
Based upon clr_temp_stat_t key: tele/LightSmall/STATE with numeric text using pub topic cmnd/LightSmall/CT for control

Code:

2:00:06 MQT: homeassistant/light/B16680_LI_1/config =
{"name":"Light small (dn) Light small (fn)",
"stat_t":"tele/LightSmall/STATE",
"avty_t":"tele/LightSmall/LWT",
"pl_avail":"Online",
"pl_not_avail":"Offline",
"cmd_t":"c mnd/LightSmall/POWER",
"val_tpl":"{{value_json.POWER}}",
"pl_off":"OFF",
"pl_o n":"ON",
"uniq_id":"B16680_LI_1",
"dev":{"ids":["B16680"]},
"bri_cmd_t":"cmnd/LightSmall/Dimmer",
"bri_stat_t":"tele/LightSmall/STATE",
"bri_scl":100,
"on_cmd_type":"brightness",
"bri_val_tpl ":"{{value_json.Dimmer}}",
"clr_temp_cmd_t":"cmnd/LightSmall/CT",
"clr_temp_stat_t":"tele/LightSmall/STATE",
"clr_temp_val_tpl":"{{value_json.CT}}"} (retained)

I had not seen the clr... key before so mcsMQTT does not have that implemented
I expected to see OFF and ON buttons as a device along with the slider. Need to investigate why you do not have them on your devices. I suspect the plugin logic does not handle the shared topic for the JSON payload case.
I expected to see the LWT device. Need to investigate why you do not have that device.
The parent devices are added for HS4 compatibility. All controls need to have a parent devices.
The discovery for Light large is not shown. I do not expect an autocreation of a RSSI device as it is not one of the homeassistant discovery keys that have been defined.

I will also look into the HS4 plugin. There should be no difference in behavior between the two.

In the hubitat and knx plugins the dimmer and the on/off devices are combined. In autodiscovery mcsMQTT should recognize that this should be the setup rather than two separate devices.

You did well with the manual setup. I do not use the RESULT topic from Tasmota as this is just an acknowledge and it is not reporting the state. The STATE topic gets reported periodically.

The homeassistant discovery protocol is a newer feature of mcsMQTT and it will have some growing pains. It also needs to deal with different liberties taken by the devices providing their discovery. The intent is that the autodiscovery work in a manner that provides the user what is natural with minimum setup. Just work with me and we can get this as close to the objective as possible.

**stefxx** · August 14, 2020, 12:33 PM

Hi, thanks for the swift response! Happy to work with you to enhance the auto configuration. For now, I stick with the manual setup, at least for the production machine. Gives me much more control over the result, even if it requires much more manual work.

Thanks for the tip for using the STATE instead of RESULT. I'll try that later tonight.

And as a HS3 and HS4 developer, I feel your pain on the requirement of a root device. Just a suggestion, why not a single root device per physical device? That would be much more intuitive (to me) instead of the multiple root devices (stat, tele, etc etc).

Thanks again!

**Michael McSharry** · August 14, 2020, 01:15 PM

What module type do you have in the Tasmota configuration? I can flash a ESP8266 with the same for testing.

**stefxx** · August 14, 2020, 01:24 PM

This is the lamp I use: https://templates.blakadder.com/lsc_...nnect_A60.html

**Michael McSharry** · August 14, 2020, 03:34 PM

The RSSI device was created based upon the homeassistant discovery topic shown below as a "sensor" vs. the other topic is a "light"

Code:

21:02:03 MQT: homeassistant/sensor/3B6A6C_status/config =
{"name":"Tasmota status",
"stat_t":"~HASS_STATE",
"avty_t":"~LWT",
"frc_upd":true,
"pl_avail":"Online",
"pl_not_avail":"Offline",
"json_attributes_topic":"~HASS_STATE",
"unit_of_meas":" ",
"val_tpl":"{{value_json['RSSI']}}",
"ic":"mdi:information-outline",
"uniq_id":"3B6A6C_status",
"device":{"identifiers":["3B6A6C"],
"connections":[["mac","2C:3A:E8:3B:6A:6C"]],
"name":"Tasmota",
"model":"LSC Filam E27",
"sw_version":"8.1.0(tasmota)",
"manufacturer":"Tasmota"},
"~":"AILight/tele/"}

I did add the CT. It has already existed for zigbee2mqtt flavor of homeassistant discovery, but not for the tasmota flavor. I set it up to be a slider. I did not have issues with multiple parent devices being created, but it appeared that way because the discovery topic for the light and for the the sensor had different 3B6A6C_status vs. 3B6A6C_LI_1 as the topics so it looked to mcsMQTT that they were different devices. I would consider this a shortcoming of tasmota's flavor of discovery.

I will do some more testing and address the HS4 issues you pointed out before posting.

**stefxx** · August 14, 2020, 03:48 PM

Great, looks good! But shouldn't there be an on/off device as well?

**Michael McSharry** · August 14, 2020, 06:24 PM

The on/off device is a matter of interpretation. In the discovery disclosure the following is given:

Code:

"on_cmd_type":"brightness",

The definition for on_cmd_type is:

Defines when on the payload_on is sent. Using last (the default) will send any style (brightness, color, etc) topics first and then a payload_on to the command_topic. Using first will send the payload_on and then any style topics. Using brightness will only send brightness commands instead of the payload_on to turn the light on.

This could mean the brightness command implicitly controls the on/off state. I will need to test to confirm this is the case since the definition was mute about OFF. Even if it is then it still may desirable to have a device that has both on/off buttons and a slider.

**Michael McSharry** · August 15, 2020, 12:42 AM

Tasmota does do auto-on on a brightness change, but does not seem to do auto-off when brightness goes to 0. The three controls now show up in HS under the parent device. The only anomaly I saw was the % suffix was on CT, but not on dimmer in HS4. Same routine to create both features so there is something hidden that makes the status display differently.

Updates at http://mcsSprinklers.com/mcsMQTT_5_5_1_0.zip for HS3 and http://mcsSprinklers.com/HSPI_mcsMQTT_5_5_1_0.zip for HS4.

**stefxx** · August 15, 2020, 02:19 AM

Hi,

Thanks again. Here is the result of the auto configuration on my small light bulb:

Few observations:
- Missing % on dimmer as you already indicated
- Missing status graphics on the ColorTemp (only defined for 0, see below)
- On/Off device, thanks!!
- Dim to 0 does actually turn off the device status
- RSSI still being created

**stefxx** · August 15, 2020, 06:37 AM

I just noticed another root device (without any features) has been created:

Attached Files

**Michael McSharry** · August 15, 2020, 11:21 AM

The HASS_STATE and the RSSI device were discussed before and are a result of the Tasmota advertisement of that device. While it may be useful for HA, it is not for HS so I excluded it from mcsMQTT auto device creation.

I fixed the CT icon and made it toggle between the warm and cool icons based upon being over or under 50% on the CT scale.

I now get consistent behaviors between CT and Dimmer %, but HS3 plugin shows % and HS4 plugin does not. Looking at DeviceUtility between the two the StatusGraphics are the same. I do not know what to do in HS4 to make it show. Maybe you do?

I did confirm the OFF/brightness relationship. You are correct, but I still left the POWER on/off status device as it is likely useful to keep brightness at same level and just toggle off and on.

Updates at http://mcsSprinklers.com/mcsMQTT_5_5_1_1.zip and http://mcsSprinklers.com/HSPI_mcsMQTT_5_5_1_1.zip

**stefxx** · August 15, 2020, 12:49 PM

Great. We are nearing perfection

I did had another issue with the "Auto Device Creation". I was sure I enabled it, but is was disabled again after updating the plugin. Turns out that every plugin restart disables it again. The .ini file has this: EnableAutoDeviceCreation="true". Changing that to "1" fixed it. Probably removing it will work as well as I think it is on by default.

These are my created devices now. Notice I also have an "Availability group" as well. Which I think is great, but I didn't notice it before.

I looked into the missing % prefix. Not sure what is going on here. As you see in the above picture, it is now missing for both dimmer and CT. Looking into the device ranges, you are clearly missing the "Prefix" value. However, I can't set it manually, it simply doesn't save. Now this might be a separate issue, but maybe it has something to do with it.

I looked into some of my own code of my plugins, and this is how I set the prefix for similar devices. This is a battery device:

Code:

Dim BatteryState As String() = {"battery_0.png", "battery_25.png", "battery_50.png", "battery_75.png", "battery_100.png"}
For i = 0 To BatteryState.Count - 1
    StatusGraphic = New StatusGraphic("/images/" & PI_Id & "/" & BatteryState(i), i) With {
      .IsRange = True,
      .RangeMin = i * 20,
      .RangeMax = (i + 1) * 20 - If(i < BatteryState.Count - 1, 0.01, 0)
   }
   StatusGraphic.TargetRange.Suffix = "%"
   hs.AddStatusGraphicToFeature(dvf.Ref, StatusGraphic)
Next

Maybe it helps.

Thanks again for all your fixes, improvements and quick responses!!

**stefxx** · August 15, 2020, 12:58 PM

Mmm... I just noticed that the LWT feature is empty. Is has a value of 1 (I assume that means Online) but the device itself lacks value/status/graphics pairs.

**Michael McSharry** · August 15, 2020, 02:02 PM

I added the graphics to the availability devices. Looking at your code I see I was updating the control rather than the graphic. After fixing this it is now back to prior state where dimmer has % but CT does not. I also fixed the ini file setting. You are an excellent detective.

http://mcsSprinklers.com/HSPI_mcsMQTT_5_5_1_2.zip and http://mcsSprinklers.com/mcsMQTT_5_5_1_2.zip

Announcement

WiFi, Tasmota, MQTT…

WiFi, Tasmota, MQTT…

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment