Dingtian Relay mcsMQTT setup steps

[zapdogster]

I had some issues as a newbie to MQTT with the setup of the Dingtain relay board. I made a short document outlining what I (finally!) got to work. Things are "obvious" after the fact 😄, so I thought it might help others in the same situation... Cleaned up the doc a bit and attached it...

Also.. open to suggestions if I did something "not to spec"...

[Michael McSharry]

Always good to document one's experience for the benefit of others.

First observation is that the Association table color is blue. This means the devices1119, 1123, 474 and 476 are not owned by mcsMQTT which means they were created as virtual devices or created by other plugins. The user has more control and options when a device is owned by mcsMQTT.

In the HS4 mcsMQTT Setup paragraph I believe there is an extraneous step performed to create HS Devices and Features. The standard way to do is from the Association Table and use the "a" checkbox on each relay subscribe topic (subscribe from mcsMQTT perspective). When done this way mcsMQTT will look at the payload and create the HS Control and Status UI that best seems to fit the data. For the relays, the OFF or ON payload will result in a VSP definition where 0=OFF and 1=ON. When the Pub Topic is entered the HS controls for ON and OFF will be created.

The above paragraph assumes that the Dingtain has been configured for MQTT use so that the subscribe endpoints of each relay are visible in the Association table. Until they are visible, the user cannot do much to make an association between MQTT endpoints and HS Device Features.

Second observation is that Dingtain has elected to use a null string as the first segment of the topic. While this is compliant with MQTT protocol, it is not practical. At some point in mcsMQTT evolution, the null subscribe topic was eliminated. This means that the T1 filter rather than the T2 filter is used to show only digntian information. Dingtian will still be sending /dingtian/... data, but mcsMQTT will discard the leading "/". For the Pub topics it will still send the leading "/" if specified so that Dingtian will be able to respond.

Third observation is in the Relay Control and Status Topics section that $$LABEL: is used. This is the payload that is sent with the /dingtian/relay4856/in/r2 topic. This is totally correct because the replacement variable resolves to what is setup in HS Device for the control buttons which will be labeled ON and OFF. The setup of these labels is automatic when one starts with using "a" to create a mcsMQTT-owned device after the pub topic has been specified. If the Device Ref that is being used was not created by mcsMQTT then the user needs to be certain that the case of ON and OFF are setup correctly. "On" and "on" payload will likely not work to control the relay.

As a bonus, the inputs are setup simply by clicking the "a" checkbox on the subscribe topic where each input status is reported. This will create HS Device Feature where the DeviceValue will contain a 0 or 1 and the DeviceStatus will be shown as the payload text of each of the two states are reported by Dingtian.

[zapdogster]

Thanks for the reply.
So i could never get the HS4 device to be "automatically" created, even though I understood from reading your doc that they should be. I could see the topics the Relay would publish, and clicked on the A in the Association Table, but nothing would happen. I had to manually create a HS Device and then use it's reference number to connect the two. So I must be doing something wrong, and don't fully understand how it is supposed to be set up...

You make the statement "The above paragraph assumes that the Dingtain has been configured for MQTT use.." so perhaps my relay is not set up correctly? However the only place I can see to set up MQTT on it is on the "Relay Connect" page and specifically:

Is there something else that needs to be set up that I'm missing?
Thanks

[zapdogster]

I should also mention that I'm running HS4 on an RPi...

[Michael McSharry]

I went through the process to confirm operation. I am using version 6.0.5.0 which is pending release from the Updater, but can be installed using the Updater Override process described at the bottom of https://forums.homeseer.com/forum/hs...ge-log-hs4-hs3 . The link to this version is also at the same place.

First is with Dingtian configured to MQTT such as shown in post 3 above. Note that my testing was done using the MQTT Broker built into mcsMQTT plugin and no username or password was used. Putting these credentials in Dingtian setup will not matter since mcsMQTT only looks for a match if username and password have been entered on the General Tab of the MQTT Page.

Navigate to the MQTT Page, Association Tab. Use filter to select the topic segments of relay100 and out. Note that the leading "/" is not shown by mcsMQTT and T2 and T3 filters are used to specify the desired info in the table. As mentioned in post 2 above the "/" will be present in earlier mcsMQTT versions.


The checkbox in the "a" column, row 0 was clicked. mcsMQTT refreshes the row to show device feature 6656 was created by mcsMQTT.


When looking at HS Devices in Room dingtian, the newly created device 6655 and feature 6656 is present with current status of OFF to match the payload in the Association table.



Back to the Association table on row 0, the pub textbox was completed to add the topic that should be used to command the relay ON and OFF. Note that the leading "/" was included because Dingtian is expecting it.




Looking back at Devices page, the ON and OFF controls are present after refreshing the page. The controls can be used to change the state of the relay, Digntian will respond on the .../out/... topic. mcsMQTT will refresh the payload text with the changed state and mcsMQTT will update HS feature 6656 which will be reflected on the HS Devices page.

[zapdogster]

Thanks very much - I will try that out if I can. One question first though - I get the impression that the updater override procedure is written for Windows? I'm using HS4 on a RPi, and my directory structure looks like the past below. So before I run amok on my system, would you be able to clarify if the same procedure works on the RPi, and what directory do I put the .zip file in, or if there is an alternate procedure?
Thanks again!

[Michael McSharry]

Same procedure and files for Linux and Windows. The zip goes in the HS folder. Extract the updater_override.json file to same location. I believe this is described in the referenced link.

It should be released via standard Updater channel next week so if you do not feel comfortable with the manual process then you can wait.

[zapdogster]

Hi - thanks you. I think I will wait for the official release, because...
Your suggestion on the latest version got me checking mine. My version was 5.20.1.3 and the latest in the latest version in the Plugins-Add menu is 5.26.5.4, which I then installed. After rebooting the RPi, the mcsMQQT plugin started working as you describe above (i.e. when I click on the A tick, a device is automatically created).

For some reason I assumed that HS4 would let me know when there are updates on plugins, but it appears that is not the case. So everything appears to be as it should be.

Thanks again for your help. Now onto uPython ESP33 MQTT connection issues

[Michael McSharry]

Likely what happened is that the MQTT Browser page went stale so clicks on the Association table were ignored. On earlier versions there was a timeout of about 15 minutes of inactivity and the page would disconnect so the plugin was not using CPU to update page that nobody was using. I think the timeout is now about a day. A refresh of the page will reset the timeout timer. A plugin restart should not be needed.