Version 3.2.x.x

[Michael McSharry]

This could be related to how you have the associations setup.

If you mapped a Topic received into an existing HS device then the plugin uses CAPI to try to control the device. The pluign that owns the device is then responsible for setting Devicevalue and DeviceString. Since mcsMQTT does not know how a plugin setup its CAPI interface it does a search using some criteria. There is debug output when debug is enabled to help understand the CAPI setup for the target plugin. It seems that two now are using the Zwave plugin with mcsMQTT. I do not have Zwave so need to work with somebody and that is the purpose of the debug.

If you mapped a Topic into a mcsMQTT device then mcsMQTT will set the DeviceValue if the Payload is a number or it will set the DeviceString with the payload. It has special cases of case-insensitive ON, OFF, OPEN, CLOSE that it maps into 1 and 0 and updates the DeviceValue.

[Michael McSharry]

In the Association tab nothing is listed.

With the database that was provided for analysis I observed that no Topic to Device Associations existed. This is why the Association tab was not showing anything. It is corrected in 3.2.6.0 which is in the updater.

On a related matter I also discovered that long Association table rendering times exist for large number of rows being displayed. The HTML for the table is constructed in just a second or two for even very large tables, but the time it takes for HS Server and the client Browser to perform the AJAX update is long. In cases of 1000's of rows the browser will usually error-out with a something went wrong message.

To address the situation the user needs to be careful to not render the entire database of Topics and Devices if either of these are large. Checkbox and Filter pulldowns are much more effective at selecting information of interest rather than scrolling a large table.

To provide a better user feedback the button used to Show the Association table is changed to text and updated to show how many rows are being provided. As a point of comparison it takes about 10 seconds for a Chrome browser on an Intel I7 (4790K 4 Ghz) to render 300 rows when being served by HS on an Odroid C1 (RPi-3 equivalent).

[Michael McSharry]

I'll get you the requested debug shortly.

In my investigation today I learned that the database fixup only works when going from 3.1.x.x to 3.2.0.0. Subsequent 3.2 releases will not update the database correctly because subsequent changes were made to the database structure in these later releases. I fixed this with 3.2.6.0. This version continues to have chatty debug so good to use for other analysis as well.

When you do the test you should used 3.2.6.0 or later to try to get your setup migrated from 3.1.4.0 to 3.2.x.x.

[ServiceXp]

This could be related to how you have the associations setup.

If you mapped a Topic received into an existing HS device then the plugin uses CAPI to try to control the device. The pluign that owns the device is then responsible for setting Devicevalue and DeviceString. Since mcsMQTT does not know how a plugin setup its CAPI interface it does a search using some criteria. There is debug output when debug is enabled to help understand the CAPI setup for the target plugin. It seems that two now are using the Zwave plugin with mcsMQTT. I do not have Zwave so need to work with somebody and that is the purpose of the debug.

If you mapped a Topic into a mcsMQTT device then mcsMQTT will set the DeviceValue if the Payload is a number or it will set the DeviceString with the payload. It has special cases of case-insensitive ON, OFF, OPEN, CLOSE that it maps into 1 and 0 and updates the DeviceValue.

All I did was tick the "(A) Accept" check box, and the PI created the devices. Is there something else I need to do in order to get the devices to trigger in HS?

Added logs for one MQTT update message, that did not trigger the HS3 device.

[Michael McSharry]

This debug seems to be a session where plugin was started at 6:14 AM and shutdown at 6:20 AM. During this time there were updates made to Device 2323 and 2274 with payloads of "Rail.gcode" and "updatedFiles". Both of these payloads are not numbers so I would expect the DeviceString of the two devices to have been updated to these values.

It looks to me as if your event's criteria is that DeviceValue changes and then some other criteria. If no number is in Payload then DeviceValue will never change. I am not an HS3 event expert, but I do not think HS triggers on DeviceString changes.

I think there is a supertrigger plugin that does triggering on DeviceString. mcsMQTT also has triggers based upon Payload, but at least at this time the trigger is based upon receipt of a specific topic that is qualified by its payload. I have three event trigger options and a change of the Payload content is not one of them. This could be provided if there is really a need.

[ServiceXp]

This debug seems to be a session where plugin was started at 6:14 AM and shutdown at 6:20 AM. During this time there were updates made to Device 2323 and 2274 with payloads of "Rail.gcode" and "updatedFiles". Both of these payloads are not numbers so I would expect the DeviceString of the two devices to have been updated to these values.

It looks to me as if your event's criteria is that DeviceValue changes and then some other criteria. If no number is in Payload then DeviceValue will never change. I am not an HS3 event expert, but I do not think HS triggers on DeviceString changes.

I think there is a supertrigger plugin that does triggering on DeviceString. mcsMQTT also has triggers based upon Payload, but at least at this time the trigger is based upon receipt of a specific topic that is qualified by its payload. I have three event trigger options and a change of the Payload content is not one of them. This could be provided if there is really a need.

That very well may be the issue, Hmmmm not sure how I'm going to do this..

I'm pretty sure the MQTT PI is updating DeviceValue, and that's why it worked...

[Michael McSharry]

Adding a string change trigger was easy and included in 3.2.7.0 in the updater. It is done by using the mcsMQTT Receive trigger and for the Payload use the word "change".

I also changed the behavior on how SetDeviceValue was being done. Previously it would only flag a trigger if the value changed. Now it triggers even if there is no change in value.

[ServiceXp]

Adding a string change trigger was easy and included in 3.2.7.0 in the updater. It is done by using the mcsMQTT Receive trigger and for the Payload use the word "change".

I also changed the behavior on how SetDeviceValue was being done. Previously it would only flag a trigger if the value changed. Now it triggers even if there is no change in value.

I've updated to 3.2.7.0 and I still can't get it to trigger.

I've tried every non-specific trigger type. I would have thought "just had its value set or changed" would have worked.

[Michael McSharry]

Can you post a screen shot of how you setup the MQTT Receive trigger. Having debug output posted would also help as it would show the payload and trigger logic execution.

[ServiceXp]

Can you post a screen shot of how you setup the MQTT Receive trigger. Having debug output posted would also help as it would show the payload and trigger logic execution.

..

Thanks for all your help, I full suspect I'm just not understanding how this is supposed to work, so please be patient with me..

[Michael McSharry]

The debug shows the same two topics being received to update DeviceString of Devices 2323 and 2274.

Your trigger is setup based upon a HS Device having the DeviceValue updated. I could, and maybe I should, use SetDeviceValueByRef and store back whatever is currently in the device even though it has nothing to do with the received payload. This would let the Device by used in standard HS triggers.

The provision that I just provided is with the MQTT Receive Trigger as shown in the attached. In this example the Topic test/string is being monitored and any change in the payload will cause a trigger. If you have other criteria you can augment with AND conditions such as you have done in what you posted.

[Michael McSharry]

I noticed that the \Data\mcsMQTT_Debug.txt was created as \DatamcsMQTT_Debug.txt in 3.2.7.0. I fixed it in 3.2.7.1.

The \Data files were also moved to \Data\mcsMQTT for better organization.

[ServiceXp]

Would it be possible to add something like the MQTT PI utilizes as an option?

I think this allows for different triggers on a device by device basis.

..

[Michael McSharry]

Such a setting can be added, but what I do not understand is the use case where it comes into play. In general one does not want to populate the String because when that is done it overrides the Status that is produced by HS based upon VSP and VGP. The only time one would want to use String is if the Payload is not a number.

If the Payload is a number then Value will be updated as that provides the best Event support by HS.

If the payload has a number embedded somewhere in a textual payload (e.g. 30 degrees) then RegEx would be used to strip out the number so Value could then be updated.

Let us say that Value is undated when a non-numeric Payload is received. This will either store 0 or restore the current Value. Likely the current Value will be 0 anyways. The Device Last Change property could be updated based upon the timestamp of when the Topic was received, but what Event trigger would be used to detect an unchanged Value?

[ServiceXp]

Unfortunately, the payload is mostly text in my case. Here is just a small section of my situation.

..