mcsMQTT Plugin

[qwiksilver96]

Your database has no subscribed messages. Only non-plugin devices. Good that backup databases are created. I would expect that in the HS Log or Debug Log that there is something that indicates why the database lost its data and may help understand your CPU use.

Something odd about this is that mcsMQTT does not delete rows from the table. It only updates contents of existing rows and add new rows. It is more like the database was deleted from the folder somehow and a new database was created.

I restored my .db file and all is well.

Thank you Michael. Your contribution to the HS community is greatly appreciated.

Best,
Frank

[rgerrans]

Lag Time?

I'm trying to replace the mqtt plugin with this one. In testing I'm seeing about 20-30 seconds lag on a device where I have both Subscribe and Publish topics set when I push a command from mqtt to HS. Any help debugging would be appreciated. I turned on logging but don't see any commands on the History tab.

[taylormia]

Hey Michael,
Just a suggestion on the appearance of the plugin setup tabs. Can you make the tabs and items within each tab left justified/aligned instead of being centered on the page. This would make it look much better.
Thanks for the great work in putting together this plugin. Although it takes a bit of effort to understand how it works, there are now so many HA possibilities with this.

[Michael McSharry]

I'm trying to replace the mqtt plugin with this one. In testing I'm seeing about 20-30 seconds lag on a device where I have both Subscribe and Publish topics set when I push a command from mqtt to HS. Any help debugging would be appreciated. I turned on logging but don't see any commands on the History tab.

I understand you have an external node that publishes a topic and you do not see the HS device updated for 20 or 30 seconds. This transaction only involves the subscription part of mcsMQTT. Any publish topics you may have setup have no bearing of this.

The debug should reflect the incoming topic. The debug file in at \Data\mcsMQTT\mcsMQTT_Debug.txt. It cannot be viewed with browser via mcsMQTT. If General tab is setup to collect Accepted Subscribed messages for at least one day then it should show in the history. It should also show on Statistics tab independent of the History setup.

The pieces of the puzzle most useful are \Data\mcsMQTT\mcsMQTT.db, and \Data\mcsMQTT\mcsMQTT_Debug.txt. If you post these then it will be easier to help.

Just a suggestion on the appearance of the plugin setup tabs. Can you make the tabs and items within each tab left justified/aligned instead of being centered on the page. This would make it look much better.
Thanks for the great work in putting together this plugin. Although it takes a bit of effort to understand how it works, there are now so many HA possibilities with this.

Version 3.3.8.0 improves the HTML alignment.

[taylormia]

Thanks Michael. The tabs look better since they are now aligned left on the page. But the HTML elements in each tab are still centered. Is it possible to align these left within the tab?

Also, the MQTT Doc link does not work when launched from a browser that is not on the HS3 PC.

[Michael McSharry]

I believe the matter of alignment is personal preference. I can see where the floating of content within the tab canvas based upon browser window width was not good. I do not like having everything left aligned with a very jagged right border. I also tried making all tables fixed width such as I did no General tab, but then the smaller ones looked very stretched which also was not pleasing.

Take a look at post 58 at https://forums.homeseer.com/showthre...=195418&page=3 with respect to the doc viewing in the browser. Popup blocker and download vs. viewing behaviors may be what you are seeing. The browser will see the local URL as safe, but will block the remote ones unless you whitelist it.

[rgerrans]

I understand you have an external node that publishes a topic and you do not see the HS device updated for 20 or 30 seconds. This transaction only involves the subscription part of mcsMQTT. Any publish topics you may have setup have no bearing of this.

Correct. I just didn't know if the round trip nature of a combined subscribe/publish might create issues. Just to confirm, I will test with a virtual device as well for the subscribe to mirror the setup on the mqtt plugin.

The debug should reflect the incoming topic. The debug file in at \Data\mcsMQTT\mcsMQTT_Debug.txt. It cannot be viewed with browser via mcsMQTT. If General tab is setup to collect Accepted Subscribed messages for at least one day then it should show in the history. It should also show on Statistics tab independent of the History setup.

The pieces of the puzzle most useful are \Data\mcsMQTT\mcsMQTT.db, and \Data\mcsMQTT\mcsMQTT_Debug.txt. If you post these then it will be easier to help.

Thanks. I'll figure out how to get CLA on my pi to pull those. I have confirmed by switching back and forth between this and the MQTT plugin that the delay only happens on this plugin.

[Michael McSharry]

I will test with a virtual device as well for the subscribe to mirror the setup on the mqtt plugin.

I don't understand how you could do this. I suspect you may be trying to use mcsMQTT in a different way than it was designed to be used. Can you describe explicitly what you are trying to do and how you are trying to do it?

[Michael McSharry]

I'll figure out how to get CLA on my pi to pull those.

I use WinSCP https://winscp.net/eng/download.php on my PC to transfer files between Linux and Windows. Also allows me to edit on Linux machine from Windows.

[rgerrans]

I don't understand how you could do this. I suspect you may be trying to use mcsMQTT in a different way than it was designed to be used. Can you describe explicitly what you are trying to do and how you are trying to do it?

No problem. My setup is that I only use HomeSeer as an interface to my ZWave devices. I then communicate to another pi which has a mqtt broker connected to Node-Red for all my automation logic. So in this specific situation, I have a ZWave dimmer switch that when it turns on sends that to mqtt/Node-Red which then determines what dim level the switch should be at and sends that back to HomeSeer.

With the old mqtt plugin, they didn't create the ability to have the same device subscribe / publish so I have the physical device publish to mqtt, created a virtual device tied to mqtt subscribe, and then use the LInked Device function for the virtual device to control the physical device in HomeSeer.

Since I have everyone home today, I won't be able to test further and pull logs until tomorrow.

Thanks for the help.

Ron

[Michael McSharry]

I'm here to help whenever you have time.

My setup is that I only use HomeSeer as an interface to my ZWave devices. I then communicate to another pi which has a mqtt broker connected to Node-Red for all my automation logic. So in this specific situation, I have a ZWave dimmer switch that when it turns on sends that to mqtt/Node-Red which then determines what dim level the switch should be at and sends that back to HomeSeer.

Switch --Zwave-->HS (e.g. Device 123)
mcsMQTT Device 123 has Publish (status) topic HS/Dimmer/, Subscribe (status) topic setup for NR/Dimmer

1. Switch turns ON -> HS Device 123 Value = 100
2. HS Event Device 123 changed to 100 -> msMQTT
3. mcsMQTT Publishes HS/Dimmer with payload 100
4. Broker sends HS/Dimmer=100 to NR
5. NR publishes NR/Dimmer=40 (set to 40% DIM)
6. Broker sends NR/Dimmer=40 to mcsMQTT
7. mcsMQTT sets Device 123 to 40

mcsMQTT debug will time-stamp steps 2, 6 and 7 which are its interface boundaries. The debug checkbox on the General tab needs to be set to get this visibility.
Step 2 will be "HSEvent Do= "
Step 6 will be "ActoOnMessageFor Trigger Topic "
Step 7 will be "Update Accepted "
Wireshark or similar can measure the network traffic timing

If my seven step flow is correct then I actually expect step 8 to generate another HS Event call to mcsMQTT to reflect a change to 40 and the flow would repeat again. It may be that my interpretation is not totally correct, but at least it should show intent and method to understand timing debug available.

In the above there are no user events setup within HS to manage MQTT traffic. It is all done through devices. There are no virtual devices setup as everything is managed through the one real device.

[rgerrans]

If my seven step flow is correct then I actually expect step 8 to generate another HS Event call to mcsMQTT to reflect a change to 40 and the flow would repeat again. It may be that my interpretation is not totally correct, but at least it should show intent and method to understand timing debug available.

In the above there are no user events setup within HS to manage MQTT traffic. It is all done through devices. There are no virtual devices setup as everything is managed through the one real device.

Correct on the flow. There is no step 8 since I do an exception trap on Node-Red to keep it from publishing back to MQTT/HomeSeer when the new dim level is published from HomeSeer after the switch changes. I should have time this afternoon to run a test and pull the related logs.

Thanks for the help!!

[rgerrans]

[QUOTE=Michael McSharry;1366650]The pieces of the puzzle most useful are \Data\mcsMQTT\mcsMQTT.db, and \Data\mcsMQTT\mcsMQTT_Debug.txt. If you post these then it will be easier to help.

What is the absolute path to that directory. I'm ssh'd in to my pi but can't find the /Data home directory.

Thanks.

EDIT - Nevermind, found it. If other's end up looking it's in /usr/local/Homeseer/Data

[Michael McSharry]

I do not know where you have HomeSeer installed. I believe on the Z it is /usr/local/HomeSeer. This would make the path /usr/local/HomeSeer/Data/mcsMQTT/mcsMQTT.db for the database.

[rgerrans]

Thanks Michael, that is where I found it.

Unfortunately I did an apt-get upgrade and my pi has been upgrading for the last 11 hours and still going at it so wasn't able to test today. Hopefully I didn't break any dependencies and it finishes up overnight so I can test tomorrow.