Rediscovery changes device type, history lost

[sciurius]

I monitor my heating with an EMS-ESP gateway. This works excellent.

Until recently this required a custom plugin but now it can use the new Domoticz MQTT autodectect. Great.

Unfortunately, many of the sensors that had an appropriate type (e.g. General/Percentage) are now General/Custom. As a consequence, I cannot replace the old device by the new one and I lose the historical data. Also, I've been told, a General/Custom device keeps lesss historical data than specific devices.

Is there a way to overrule the type detection, or change it afterwards?

[waltervl]

There is no possibility to change afterwards.
There could be a possibility to change the MQTT autodetect behavior but that depends on the configuration topic the gateway is sending.

I hope a developer will come by....

[sciurius]

Given that many devices are wrongly identified this would be more than welcome. Mandatory, even.

[waltervl]

Better create a new topic in the MQTT AutoDiscovery forum https://domoticz.com/forum/viewforum.php?f=82

For debugging share the following:
MQTT AD CONFIG Messages of incorrect devices
MQTT Status update messages for the devices

[jvdz]

Topic is moved.
We really need more details about the device CONFIG MQTT messages to comment on what is happening. Once the device is discovered and a value is received, the device/sensor type is determined on the first status update and will remain as is and not be recreated unless the discover unique info changes.

[sciurius]

How can I intercept the device CONFIG MQTT message?

[sciurius]

Okay, here is one.

Code: Select all

{"name":"Bulb01","stat_t":"tele/bulb01/STATE","avty_t":"tele/bulb01/LWT","pl_avail":"Online","pl_not_avail":"Offline","cmd_t":"cmnd/bulb01/POWER","pl_off":"OFF","pl_on":"ON","stat_val_tpl":"{{value_json.POWER}}","uniq_id":"F4FAA9_LI_1","dev":{"ids":["F4FAA9"]},"bri_cmd_t":"cmnd/bulb01/Dimmer","bri_stat_t":"tele/bulb01/STATE","bri_scl":100,"on_cmd_type":"brightness","bri_val_tpl":"{{value_json.Dimmer}}","hs_cmd_t":"cmnd/bulb01/HSBColor","hs_stat_t":"tele/bulb01/STATE","hs_val_tpl":"{{value_json.HSBColor.split(',')[0:2]|join(',')}}","fx_cmd_t":"cmnd/bulb01/Scheme","fx_stat_t":"tele/bulb01/STATE","fx_val_tpl":"{{value_json.Scheme}}","fx_list":["0","1","2","3","4"],"clr_temp_cmd_t":"cmnd/bulb01/CT","clr_temp_stat_t":"tele/bulb01/STATE","clr_temp_val_tpl":"{{value_json.CT}}","clrm_stat_t":"tele/bulb01/STATE","clrm_val_tpl":"{%if value_json.White%}color_temp{%else%}hs{%endif %}"}

This is a CALEX RGB CCT lamp, flashed with Tasmota 10.1.0. It is a Color Switch, RGBWW, Dimmer, but under MQTT autodiscovery it is identified as Light/Switch, Switch, Dimmer (i.e., no colour controls) even when the discovery is done while the lamp is set at colour.

[sciurius]

Another one:

Code: Select all

{"~":"ems-esp","uniq_id":"boiler_curburnpow","stat_t":"~/boiler_data","name":"Boiler burner current power","val_tpl":"{{value_json.curburnpow}}","unit_of_meas":"%","ic":"mdi:percent-outline","device_class":"power_factor","dev":{"ids":["ems-esp-boiler"]}}

Under MQTT autodiscovery it is identified as General, Custom Sensor while it should be General, Percentage.

[Hausautomatisierer]

I had a look at the code and the config message. The problem looks similar to the one I had with a Fibaro color dimmer. Your device is simply not yet fully supported by autodiscovery. One of the main problems is that the config message does not expose the supported color modes. For the Fibaro dimmer I implemented the missing code and submitted a pull request but it will not be appropriate for the CALEX RGB CCT lamp, since the lamp uses different keys in the messages.

Modifying the code to make it work is not that terribly difficult, if you have a device and you can program in C++. It takes a while to understand what is required, but once you understood it, things are quite straight forward.

[sciurius]

I'm not sufficiently familiar with MQTT autodiscovery so my first question would be: Is the config message sent by the lamp allright? If so, the discovery must be fixed in domoticz, otherwise it must (first) be fixed in Tasmota.

[jvdz]

I'm not sufficiently familiar with MQTT autodiscovery so my first question would be: Is the config message sent by the lamp allright? If so, the discovery must be fixed in domoticz, otherwise it must (first) be fixed in Tasmota.

The MQTT CONFIG and STATE updates are send by TASMOTA in this case, and you could be right that Domoticz needs "fixing", or rather an change, to cope with yet another type of MQTT message format.
I see you posted the CONFIG Payload, but what I need to be able to test is the MQTT TOPIC and PAYLOAD information of both the CONFIG and the STATE so I can manually send those in Debug to be able to test.

[sciurius]

I'll do my best .

Topic `homeassistant/light/F4FAA9_LI_1/config`

Code: Select all

{"name":"Bulb01","stat_t":"tele/bulb01/STATE","avty_t":"tele/bulb01/LWT","pl_avail":"Online","pl_not_avail":"Offline","cmd_t":"cmnd/bulb01/POWER","pl_off":"OFF","pl_on":"ON","stat_val_tpl":"{{value_json.POWER}}","uniq_id":"F4FAA9_LI_1","dev":{"ids":["F4FAA9"]},"bri_cmd_t":"cmnd/bulb01/Dimmer","bri_stat_t":"tele/bulb01/STATE","bri_scl":100,"on_cmd_type":"brightness","bri_val_tpl":"{{value_json.Dimmer}}","hs_cmd_t":"cmnd/bulb01/HSBColor","hs_stat_t":"tele/bulb01/STATE","hs_val_tpl":"{{value_json.HSBColor.split(',')[0:2]|join(',')}}","fx_cmd_t":"cmnd/bulb01/Scheme","fx_stat_t":"tele/bulb01/STATE","fx_val_tpl":"{{value_json.Scheme}}","fx_list":["0","1","2","3","4"],"clr_temp_cmd_t":"cmnd/bulb01/CT","clr_temp_stat_t":"tele/bulb01/STATE","clr_temp_val_tpl":"{{value_json.CT}}","clrm_stat_t":"tele/bulb01/STATE","clrm_val_tpl":"{%if value_json.White%}color_temp{%else%}hs{%endif %}"}

Topic `tele/bulb01/STATE`

Code: Select all

"Time":"2022-01-12T10:54:32","Uptime":"1T20:50:13","UptimeSec":161413,"Heap":26,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"POWER":"OFF","Dimmer":30,"Color":"76,0,0,0,76","HSBColor":"0,100,30","White":30,"CT":500,"Channel":[30,0,0,0,30],"Scheme":0,"Fade":"OFF","Speed":1,"LedTable":"ON","Wifi":{"AP":1,"SSId":"Oh Denneboom","BSSId":"xx:xx:xx:xx:xx:xx","Channel":11,"Mode":"11n","RSSI":52,"Signal":-74,"LinkCount":1,"Downtime":"0T00:00:03"}}

Topic `tele/bulb01/HASS_STATE`

Code: Select all

{"Version":"10.1.0(tasmota)","BuildDateTime":"2021-12-08T14:47:33","Module or Template":"Calex E27 RGB ","RestartReason":"Software/System restart","Uptime":"1T20:50:14","Hostname":"bulb01","IPAddress":"192.168.1.83","RSSI":"52","Signal (dBm)":"-74","WiFi LinkCount":1,"WiFi Downtime":"0T00:00:03","MqttCount":1,"LoadAvg":19}

[jvdz]

Thanks!
... and what exactly is going wrong when I use these? (sorry if you mentioned it already somewhere)

EDIT: It gets discovered as Switch in stead of Light ... and think we are current already working on a similar one with this PR: https://github.com/domoticz/domoticz/pull/5100
Could you post this info in a new Github Issue so we can reference to it and take that also into account while testing that PR?

[sciurius]

https://github.com/domoticz/domoticz/issues/5106
I hope that's what you wanted?

[gizmocuz]

Another one:

Code: Select all

{"~":"ems-esp","uniq_id":"boiler_curburnpow","stat_t":"~/boiler_data","name":"Boiler burner current power","val_tpl":"{{value_json.curburnpow}}","unit_of_meas":"%","ic":"mdi:percent-outline","device_class":"power_factor","dev":{"ids":["ems-esp-boiler"]}}

Under MQTT autodiscovery it is identified as General, Custom Sensor while it should be General, Percentage.

Thanks for spotting, fixed in upcoming beta (14047)