Reading Home Assistant Device Values into HomeSeer Devices

[BraveSirRobbin]

I recently installed Home Assistant on a virtual machine (using my HomeSeer computer's Windows 10 Pro system).

I created a Mosquitto broker on Home Assistant and with the help of your documentation managed to get HomeSeer to connect to this broker.

From the HS log file: MQTTClient is Connected to broker 1 at 192.168.1.248 (which is the IP address of my virtual machine running Home Assistant).

From here I'm running into difficulty as where to start. Do I create HS virtual devices and configure the plugin somehow to update these devices from individual Home Assistant devices? I thought there was a way to auto create HS devices.

Just looking for a starting push to go in the right direction.

Thanks,

BSR

[BraveSirRobbin]

Connection Screenshot

[Michael McSharry]

The two primary items from the user manual germane to your question are shown below. They are part of Inbound Management section of the General tab, MQTT page. The first is a preferred method because HomeAssistant Discovery contains information on how to create a device to achieve a certain behavior. For example, a light, thermostat, binary input, etc. I am not a HA user, but you want to configure HA to tell it to send information about its devices using HomeAssistant Discovery protocol. Don't confuse this setting with one in HA where it uses this protocol to create HA devices.

The second option targets a family of topics that will have a HS device created for every endpoint that is received. I do not know what HA uses for its MQTT topics that it publishes. If it is something like HomeAssistant/Sensor/MyDoorSensor then you would use HomeAssistant/# as the wildcard textbox entry.

By default, mcsMQTT will listen for all topics from all sources and show them in the Association table. This means that if HA is sending MQTT data using the same MQTT broker that is being used by mcsMQTT then all the data that has been sent to date will be in the table and allow you to observe the Topic pattern to setup a wildcard template. It is possible to use a template entry of just #. This should create a HS device for everything received from all sources. With such powerful command it is easy to get large effects in the HS device list so always be in a position to restore from backup or start over. Another powerful command in the same Inbound Management section is the "Obsolete" textbox template. Using # there will remove everything received and delete any HS devices that were created.

17.1.3.3 Enable Auto Device Creation"Specific topics including shellies/#, wled/#, and other devices will automatically create HS devices when received."
"Specific topics advertised by Tasmota.Discovery or Homeassistant/../config topic will automatically create HS devices when received."


17.1.3.4 Wildcard Plugin Auto Associate Template"Enter topic template for auto-association of plugin devices. When not blank and a topic that matches template is received then HS device(s) will be automatically created with publish topic set to the Default Topic Template and Default Payload Template (e.g. +/Tasmota/# for any topic that is Tasmota in the second position)."

[BraveSirRobbin]

Thanks for the information.

I've enabled discovery for the MQTT options in HA:
Discovery Prefix: homeassistant
Birth message topic: homeassistant/status
Birth message payload: online

I also enabled the Topic Discovery and Enabled Auto Device Creation in HS as shown below:

I can see traffic coming through with the associations tab as shown below:


I can't get the devices auto created in HS for some reason.

[Michael McSharry]

The MQTT topic is internal to mcsMQTT and used to report statistics. Change your display filter to not restrict what is shown in the table. (i.e. remove MQTT and Statistics)

The HomeAssistant/# entry is in the wrong location. It should be in the row "Wildcard Plugin Auto Associate Template", but likely it is not what you want to put there. You first need to see what HA is sending or look in the HA documentation if it tells you what it will use for its published topics. It could be that there is no convention being used and up to the author of each integration to use what he/she wants.

Following the following sequence:
1. To get some data for analysis, enable the debug checkbox at the top of the General tab, MQTT page. Among the data collected are all the messages received.
2. To get a clean start, on the General tab, "Remove Obsolete Topics" row textbox enter #
3. To try to induce HA to send Homeassistant Discovery Protocol topics, Restart mcsMQTT . Try to find a HA control to send its topics using the Discovery Protocol. What I see in your HA setup looks to be enabling its ability to receive this protocol and likely does not include the conditions on when it sends it. Sorry I cannot give specific direction for this, but I have never used HA.
4. Do something from HA to change the state of a HA device so that it will send MQTT message that reflects this change. I am assuming that HA has a capability similar to mcsMQTT to send MQTT messages as HS device state changes.
5. Look at unfiltered Association table on MQTT page, Association table and see what is visible. Note that your first post screenshot shows there were 272 MQTT messages received.
6. zip HS subfolder \data\mcsMQTT\mcsMQTT Debug.txt and post so I can observe what MQTT traffic is being received so I provide more informed guidance.

[BraveSirRobbin]

Thanks...let me digest this.

I did want to mention that in HA's MQTT documentation they do have the prefix for the discovery topic as 'homeassistant"

[Michael McSharry]

homeassistant/ is the default topic for Homeassistant Discovery Protocol and mcsMQTT is only looking for this topic to implement the discovery. This documentation is written from the perspective of HA being able to receive messages. It is silent about how HA sends messages using this protocol so HS or any other client is able to auto-configure the HA device. I suspect this comes from the viewpoint that if anybody is using HA then HA will collect everything and does not need to disclose anything.

In the end I think we will find that HA will not be sent any discovery messages. Let us look at the data that it does send using the procedure described above and then we can figure out the best way to have it auto-create HS devices.

[BraveSirRobbin]

I sent you the files requested in a PM.

I believe you are correct, HA isn't 'sending' anything on a device change.

There is a configuaration settings in HA that will let you manually send (publish) a packet and I did this as shown in the screen shot below:



Looking at your plugin's association page yielded the result below:



Those earlier ones were just more test publishes. We are close...now to just figure out how to get HA to transmit device changes via MQTT.

[Michael McSharry]

The debug shows:
1. mcsMQTT is connected to broker at 192.168.1.248
2. mcsMQTT is subscribed to # (all topics available at broker)
3. 5 minutes elapsed, and no messages delivered to the MQTT broker at 192.168.1.248
4. Internal messages for plugin monitoring and control as well as MQTT traffic statistics do exist in the mcsMQTT database.

The bottom line is that HomeAssistant is not communicating with broker at 192.168.1.248. This gets back to a HA setup issue.

MQTT Explorer MQTT Explorer | An all-round MQTT client that provides a structured topic overview (mqtt-explorer.com) is a good free tool to view MQTT traffic. It will tell you the same thing about message traffic as is available from mcsMQTT Debug.txt. It will make it easier for you to work with just HA and Mosquitto without dealing with anything in HS until you have HA talking to the broker.

I created a Mosquitto broker on Home Assistant

This may be semantics, but Mosquitto and Home Assistant are two different software packages. You likely meant that Mosquitto was installed on the same VM where Home Assistant was installed. If I am correct, then there should not firewall/network type issues if you can get from the VM to the physical HS network. If I am wrong, then firewall is another area to consider in the debug.

Mosquitto is a good choice for broker. A setup that has fewer parts is to use the internal MQTT broker that can exist in either HA or HS. The setup of the internal broker in HS is by leaving the Broker IP on the General tab blank or set to 127.0.0.1. The downside to using the internal broker is that when HS (or HA if using the HA internal broker) is not running then no MQTT traffic can exist.

MQTT is a very common protocol for HA so its setup should not be that difficult. The configuration file should have a place to enter 192.168.1.248 port 1883. No need for username or password unless you setup these in Mosquitto. No need for encryption (TLS 1.2) unless you set up Mosquitto to use it and installed its certificate. The setup I see in your first screenshot shows a broker that does not require username/password or encrypted communications and the debug data shows HS and Mosquitto agree on the security provisions.

[ksum]

If the Home Assistant OS is installed, which is the suggested method, then HAss OS has installs for things such as Mosquito, Node-Red, and other items. Was Mosquitto installed from the HAss Add-on Store?

[BraveSirRobbin]

Yes, the Mosquitto Broker is installed via Home Assistant add on store as shown below:

I can manually publish something in HA and it can be read on HS MQTT association tab as shown above. The problem seems to be that I most likely have to manually configure YAML code so the device's in Home Assistant can be published on a change of state.
I was hoping that device changes would automatically be published via the onboard broker in HA, but this doesn't seem to be the case.
To figure out how to do this in YAML code and setup for each of the 15 devices is not feasible.
Hopefully, there is a better way and I'm just missing something here

[Michael McSharry]

Somebody on the HA side did a HS integration that pulls HS data via JSON interface. Since it was a HA user I doubt if something was created for the other direction. Just like HA not publishing the Homeassistant Discovery even though they created the protocol.

15 devices does not seem that bad to me. Once you figure out one, then the same template can be applied to the others.

Since your essential problem is with HA not playing in the sandbox, it seems you will have a better chance for creative ways to use HA on the HA forums.

[Michael McSharry]

If your only reason to use HA is for ABODE then it may be easier to integrate ABODE into HS than add HA in the middle. A quick search finds hbeckeri/abode-api (github.com) . If you are interested, I can look into it to include it natively into mcsMQTT. What is available is nodejs implementation so there is some form of API available and integration could be by running the nodejs from GitHub or by implementing the equivalent in .NET.

[BraveSirRobbin]

Hi Michael:

Again, my thanks for your generous offers and spending time on this issue for me!

I could also post on the HA forums as I'm sure someone there could help me get the initial script working to have HA devices send their status to their Mosquitto broker on a change of state, and you are correct, it wouldn't take that long to duplicate that template.

There is a HS user that did integrate Abode with Python, but unfortunately, I don't know that scripting language and had difficulty getting that going.

If you could somehow get Abode to interface with mcsMQTT, and eventually get it to populate HS devices, that would be great. I'm sure others would benefit from this as well as Abode security systems seem to be gaining popularity (it's one of the few DIY, simple, cost effective security solutions that can actually be configured via a computer and not just a smartphone like so many others). It's a great alternative to the full blown DCS, Elk, Interlogix, etc... expensive systems.


I went with the HA/Virtual Machine route not only because they had a great Abode interface (it took 20 minutes to setup a virtual machine, download HA, and get that interface working with my Abode system), but as a learning experience to see what HA was all about (saw many posts on this and wanted to give it a try). I also wanted to learn how to get your plugin working as well.

In conclusion, I do believe mcsMQTT integration with Abode would be the most beneficial for others that use Home Assistant and want devices transferred to HomeSeer (Abode plugin for HA is used by 421 HA users). That would be the next best thing to a full blown dedicated Abode plugin!

Thanks,

BSR

[mterry63]

I used the HomeSeer HACS integration and eliminated MQTT complexity. It worked well for a year or more when I removed it as I shutdown HomeSeer.