HomeAssistant Discovery

[Pete]

How do I install the new update zip file?

I copied it over to the update/zips directory. It's been a while since I have done this.

[Michael McSharry]

Some user updater_override.txt to emulate the updater install. I usually just copy the two updated files. Look at the first post at https://forums.homeseer.com/forum/li...6-wled-support where instructions are provided for both methods.

[Michael McSharry]

Dev: |homeassistant|config:availability_topic
Sub: homeassistant/sensor/omnilink/thermostat1temp/config:availability_topic
Pub: the following Topic on Device command

If I click on associate then I get a device creation but nothing automatic right now. All I see are my Omni Panel devices (> 400).

I do not see any Espurna / Tasmota devices that are in HA.

The intent of these messages is not to Associate with HS devices. The payload of each is a declaration that describes the device. This declaration is remembered by mcsMQTT and if it see a declared Topic it will use that and other information in the declaration to create a HS device automatically.

What I am interested in is the payload of these messages to understand the dialect or slang that it is used to described its devices. The HomeAssistant discovery convention provides a shell, but what is inside the shell is left to each device implementer. This means that examples are needed for each developer that implemented the convention so the plugin can learn the language of that firmware developer.

[Pete]

The payload of each is a declaration that describes the device. This declaration is remembered by mcsMQTT and if it see a declared Topic it will use that and other information in the declaration to create a HS device automatically.

So I do see a delaration of each of these topics. But there are no HS Devices being created for these.

[Michael McSharry]

As an example the following is the topic and payload for a Tasmota light. The subscribe topic that mcsMQTT will be looking for is Wemos/tele/STATE. Tasmota split the topic into a base "~" and suffix "~tele/STATE". ESPHome does not do this. This is what I mean by each firmware developer will do it their own way. I only have the Tasmota and ESPHome firmware evaluated. If you post your message then I can interpret it and update the plugin if necessary.

The plugin will create devices only for initial observance of something that has been advertised. If the topic was received by mcsMQTT before a discovery message then auto creation will not occur. To make it occur the topic needs to be declared as obsolete in mcsMQTT so that the next time it sees it it will be then recognized as the first time.

homeassistant/light/CFB4C6_LI_5/config

{"name":"",
"cmd_t":"~cmnd/POWER5",
"stat_t":"~tele/STATE",
"val_tpl":"{{value_json.POWER5}}",
"pl_off":"OFF","pl_on":"ON",
"avty_t":"~tele/LWT",
"pl_avail":"Online",
"pl_not_avail":"Offline",
"uniq_id":"CFB4C6_LI_5",
"device":{"identifiers":["CFB4C6"],"connections":[["mac","DC:4F:22:CF:B4:C6"]]},
"~":"Wemos/",
"bri_cmd_t":"~cmnd/Dimmer",
"bri_stat_t":"~tele/STATE",
"bri_scl":100,
"on_cmd_type":"brightness",
"bri_val_tpl":"{{value_json.Dimmer}}"}

[Pete]

Ahh.....

So best just to delete the DB maybe?

Here primarily use one plugin which works with HA, HS (mcsMQTT), Smartthings and connects to the OmniPro 2 panel. I have disabled the Smartthings devices as it was a PITA to tinker with it online. I also have been on and off tinkering with the Hubitat Elevation device.

Rest of MQTT connections to HA (and HS) are one Tasmota (garage door combo) and a few Espurna firmware updated devices. 1-Wire temperatures and Kitchen under counter LED lighting.

Using MQTT explorer to watch the traffic here.



Best to look at the source on git hub. The plugin is generic and the author is using it with Home Assistant.

hxxps://github.com/excaliburpartners/OmniLinkBridge

OmniLinkBridge ==> MQTT and SmartThings hub

Yeah everytime I would nano edit the updater.txt file for betas I would trash it so gave up. I do not mind waiting for update to be in updater.

[chapa]

I am about to expose some Motion and Cover zwave devices from HS to HA via MQTT. Would like to get all states, incl tamper, battery, moving up/down states, etc. and populate them via mqtt in HA. Think, some templating on HA side will be needed too.
Does someone did this, and what is the right way to do it via HA mqtt discovery using mcsMQTT?
I guess would have manually to configure once via /config topic, than tune mcsMQTT to handle right state and control messages? Is there some example I can refer to?
Thanks.

[Michael McSharry]

mcsMQTT will publish any devices selected from HS. It will also receive all MQTT messages from HA and can create HS devices for them. It will recognize the messages that use the HomeAssistant discovery template and will automatically create HS devices when messages using those templates are received. The discovery templates produced by Tasmota and ESPHome have been tested. I have not yet seen anything published by HA that uses HomeAssistant discovery, but am willing to implement whatever else is needed. I just need to see examples of payloads produced from the homeassistant/+/+/config topics from HA.

I have not implemented mcsMQTT publishing homeassistant/+/+/config topic. The stumbling block is knowing what to use to characterize a HS device. I am open to suggestions. What characterizes a HS sensor vs. a light vs. a switch vs. thermostat etc? There is a device type that has some of this but is not universally used within HS. Discussion on this is desired. Seeing what HA publishes for discovery will also help.

[Michael McSharry]

I did a first cut of HS publishing per homeassistant topic the discovery disclosure. It is at http://mcsSprinklers.com/mcsMQTT_5_1_4_0.zip. HSPI_MCSMQTT.exe goes into HS folder. mcsMQTT_2020.dll goes into \bin\mcsMQTT folder. It contains the state, command and availability topics with an example shown below. It is sent each time mcsMQTT starts. It is sent as a retain message so the broker will deliver it every time a client goes online.

Topic: homeassistant/switch/HomeSeer/HSDevice_2792/config
Payload: {"name":"NonPluginDevice","stat_t":"Dell-PC/mcsMQTT/Unknown/Unknown/NonPluginDevice","cmd_t":"Dell-PC/mcsMQTT/Unknown/Unknown/NonPluginDevice/command","avty_t":"Dell-PC/mcsMQTT/LWT","pl_avail":"Online","pl_not_avail":"Offline"}

I expect to add effect_val_payload items, but still need to think about how it should be done.

The mapping of the homeassistant components to the HS device types is not very good. Below arrComponents are the homeassistant one. Below this I mapped them into HS3 and HS4 device types. Since most of the HS devices will be "generic" or not defined the disclosure will be most switch or sensor as the type of component. Those lilsted as unmapped from HS are the HA components that will never be advertised by HS in the current implementation.

[code]
'Dim arrComponents As String() = {"Air_Quality", "Alarm_Control_Panel", "Binary_Sensor", "Climate", "Cover", "Fan", "Light", "Lock", "Media_Player", "Remote", "Sensor", "Switch", "Vacuum", "Water_Heater", "Weather"}
'unmapped from HS , "Air_Quality", "Alarm_Control_Panel", "Cover", "Media_Player", "Vacuum", "Water_Heater", "Weather"
'HS4 HomeSeer.PluginSdk.Devices.Identification.EDeviceType
' Generic 0: ..................... "Sensor" or "Switch"
' Door 1:........................... "Binary_Sensor"
' Fan 2: ............................ "Fan"
' Light 3: ........................... "Light"
' Lock 4: ............................"Lock"
' Outlet 5:.......................... "Switch"
' RemoteControl 6:........... "Remote"
' Switch 7:......................... "Switch",
' Thermostat 8:................ "Climate"
' Window 9:...................... "Binary_Sensor"
'HS3 Device.DeviceType.DeviceTypeInfo
' eDeviceType_GenericRoot ............"Sensor" or "Switch"
' eDeviceType_Media ......................."Media_Player"
' eDeviceType_Plugin ......................."Sensor" or "Switch"
' eDeviceType_Script ........................"Sensor" or "Switch"
' eDeviceType_Security ................... "Alarm_Control_Panel"
' eDeviceType_SourceSwitch ..........."Switch"
' eDeviceType_Thermostat .............."Climate"
' eDeviceType_Energy ....................."Sensor"
[./code]

[Pete]

Great stuff Michael.

Updated to Version 5.1.40 tonight. See many HA devices being created in Homeseer. Well see Espurna and OmniLinkPlugin but no Tasmota.

Everytime I look I see more devices. Bedtime here.

[chapa]

I did a first cut of HS publishing per homeassistant topic the discovery disclosure.

Great!

I will start playing with this release in the afternoon and coming days.
And provide my use case, if it will be in help.

As an idea, the mapping may be done between HS Root Device, and all child device report data as attributes to HA device/entity ?
After users start implementing mapping of particular devices, ideas will come, which topics should be matched and in what case.

Indeed, lack of device types in HS3 and HS4 is major issue. Zwave provide all necessary information to identify the device. But as far as I see, there is no internal Cover device type even in HS4, and I have 24 zwave covers in the house...

[chapa]

I played a bit and come with three proposals/feedback:

1. First about naming in /config topic.



Probably the name should include loc1 and loc2, as there is no way to identify the device in HA. So far in HA I can not find a way to see entity mqtt config data, so I can identify it without doubt at first glance. If loc1, loc2 are in the name, it will be much more convenient.

2. It seems like if the prefix of /config and /state topic differs, HA ignore the mqtt state

Example:

 
 {     "name": "WashingMachinePower",     "stat_t": "homeassistant/sensor/HomeSeer/HSDevice_2179/state",     "avty_t": "HomeTrollerS/mcsMQTT/LWT",     "pl_avail": "Online",     "pl_not_avail": "Offline" }

I had to change stat_t topic to start with "homeassistant/sensor/HomeSeer/HSDevice_2179" as in above example, and as exampled in HA docs. To do so, I manually edited the Association table. I restarted the plugin, so new /config take place with the changed stat_t. Only after that HA begin to change entity state. Before this it was "unavailable" even I see mqtt state topics. I don't know if availability topic will be the such a case too, but I guess so. HA can accept "~" for "stat_t" and other topic prefixing, so I guess /config should comply with it.

3. After associating new device in mcsMQTT, than after changing its state topic I had to stop/start the plugin. Did not found other way to let the plugin know about /config change.

[chapa]

And another proposal:

Create new dedicated Device Publishing Tab in the plugin, where a user can do its high-level device settings, /config /state, etc.
Current Association way is good, but in context of auto-discovery, stating and control, probably we will need new dedicated settings page.

As mqtt discovery is becoming widely used, more and more company and devices comply with it.
I think in near future more and more Home Automation software are going to integrate/implement it and may become universal way for communication between different home automation solutions. And what is for sure, there will be no one software to rule them all and satisfy every aspect of every user needs. Some are good at Zwave and Automation, as HS, other at compatibility and customization (HA), etc. Dashboards don't care, and should not, about zwave, automations, events, device integrations, etc.

So far, I have not found good integration between HS and HA. If anyone has, please let me know

But I imagine, how HomeSeer devices are exposed to Home Assistant and vice versa.
HS ZWave devices are shown and controlled in HA, and how much many other devices, not supported by HS, are imported from HA to HS.
One can choose where his automation will be, on HA or HS side, from where and how dashboards will get its data, etc.
As a user, it will solve many of mine current issues.

And Michael McSharry, you are my hope

[Michael McSharry]

chapa Thank you for the feedback. I will look at it more in detail later. I agree with then name being insufficient as a unique identifier and will include floor/room as was done for the topics. Today I have been in the HS4 world so did not get to your inputs until late in the day. In HS4 there is a clear distinction between Device and Features but in HS3 that is not the case. It is very common for HS3 devices to not be grouped under parent devices. Somethings they are, but sometimes not. In HS4 it is enforced.

I would like to have a good integration between HS and HA. I am not a HA user, but I know it has a broad community and many good contributions. HS has its strengths, but also has its shortcomings

Pete .Have you enabled Homeassistant discovery with "SetOption 19 1". Also this capability has not been in Tasmota forever and something like the Garage Door version may have branched before the capability was introduced. I am glad to see Espurna implementation was recognized. Are there any anomalies for Espurna discovery?

[Pete]

Michael McSharry

Have you enabled Homeassistant discovery with "SetOption 19 1"

I only have one Tasmota (your original design and firmware from way back). I do not see a set option 19 1 on the configuration of the Tasmota. Its been working fine now for quite a while.

I have not noticed any anomalies as far as I can tell except for the below HSTouch server log entries.

I do see the following and I recall seeing this before way long time ago. Have to look at my currently utilized touchscreen design.

Feb-20 7:32:32 PM HSTouch Server Warning Exception on Value Change callback: Object reference not set to an instance of an object
HSTouch Event Handler
Feb-20 7:32:53 PM HSTouch Server Warning Exception on Value Change callback: Object reference not set to an instance of an object
HSTouch Event Handler
Feb-20 7:32:53 PM HSTouch Server Warning Exception on Value Change callback: Object reference not set to an instance of an object
HSTouch Event Handler