MQTT Home Assitant autodiscovered things and channel data types

Add-ons Bindings
, , ,
1

Hello there!

I’m using zigbee2mqtt for quite some time now and worked with Generic MQTT things all that time, so I created every channel by hand.
After upgrading to OH 4.3.3, I decided to give the autodiscovery option a try. Things pop up in the inbox alright, but other than having the problem that every channel turns up twice (like in this thread: Problem with channels on mqtt things dicovered by homeassistant discovery since oh4.3), I wonder how to make linking to my existing items work.
E.g. the autodiscovered Thing offers a last_seen channel, which is of datatype “String”. My hand-created channel on the previous Thing is datatype “Datetime” (which makes a lot of sense for a timestamp). The linked, existing Item is also datatype Datetime, which means I can’t link it to the new last_seen channel because the datatypes don’t match.
I can’t even select the Item when linking and then decide on some transformation to make them match, because in the list of existing Items my Item isn’t listed in the first place (because of the non-matching datatype). Re-creating every single Item just because OH decides I’m not allowed to link String to Datetime is not going to happen, so using MQTT autodiscovery is impossible for me because of that - which is a pity.
Or am I getting it wrong?

2

Followup: I wonder even more why the autodiscovered Thing configures the last_seen Channel as datatype string - see this config MQTT message:

{"availability":
[{"topic":"z2m/bridge/state","value_template":"{{ value_json.state }}"},{"topic":"z2m/UG_DR_Steckdose_2/availability","value_template":"{{ value_json.state }}"}],
"availability_mode":"all","device":{"identifiers":["zigbee2mqtt_0x3425b4fffebe259a"],"manufacturer":"IKEA","model":"TRADFRI control outlet (E1603/E1702/E1708)","name":"UG_DR_Steckdose_2","sw_version":"2.3.089","via_device":"zigbee2mqtt_bridge_0x00124b001cdceb81"},
"device_class":"timestamp",
"enabled_by_default":false,
"entity_category":"diagnostic",
"icon":"mdi:clock",
"name":"Last seen",
"object_id":"ug_dr_steckdose_2_last_seen",
"origin":{"name":"Zigbee2MQTT","sw":"1.42.0-dev","url":"https://www.zigbee2mqtt.io"},"state_topic":"z2m/UG_DR_Steckdose_2","unique_id":"0x3425b4fffebe259a_last_seen_z2m","value_template":"{{ value_json.last_seen }}"}

device_class is “timestamp”, so I wonder why the auto-configuration decided it should be a String?

3

I do not know how the autodiscovery stuff works for MQTT. But you should be able to select any Item if you use a profile. But there might be some strangeness in the UI preventing this perhaps.

Is the timestamp in ISO8601 format? Maybe it’s not or not always guaranteed to be.

There is a recent issue filed realted to something similar but for linking Color channels to Dimmer and Switch Items (which is allowed but MainUI prevents).

I’d recommend filing an issue on openhab-webui to, maybe, add a “show all” option to the list of Items so the user can override that filter and select any arbitrary Item since with a profile, the data could be transformed to match any Item type.

In the mean time you could work around the issue using the REST API to set the link manually instead of going through the MainUI linking page. Another thing you can do is temporarily change the type of the Item to a String, link it, then convert the Item type back to a DateTime. That too should work.

I’m not recommending these as permament solutions, an issue still needs to be created. But it can get you by for now.

1 Like
4

Switching the Item to String and back to Datetime after linking worked - despite the scary warning that links would turn invalid.
I wouldn’t have thought that I could change the Item data type, since I can’t change a Channel data type either.
Thanks!
As for the issue, I’m going to file one. OH’s current approach that you can absolute configure all kinds of transformations on a link when you’re creating one, but only after you chose from datatype-curated Items is a bit weird, I think :wink:

5

That still leaves the question open why autodiscovery declares the Channel data type a String instead of Datetime, which would be more appropriate… I think I’m going to raise an issue with that, but where? At the MQTT binding?

6

Yes, the MQTT binding.