Version 3.2.x.x

[ServiceXp]

I duplicated your test case. I sent the topic every two seconds with the payload being text, but changing.

test/string2 text1
test/string2 text2
test/string2 text3
test/string2 text1
test/string2 text2
etc

The event triggered every two seconds with the speak action. I observed the Device Value was incrementing.

I did the same thing without changing the payload

test/string2 text1
test/string2 text1
test/string2 text1
test/string2 text1

In this case the event did not trigger. The Device Value was not incrementing.


The debug file you provided showed the same payload being received twice. I would not expect the event to trigger until the payload changes.

I believe using "just had its value set or changed" should cause it to trigger. The only other option is "has a value that just changed" that doesn't require a variable entry.

Let me try "has a value that just changed" to see if that works.

[ServiceXp]

As expected "has a value that just changed", didn't work.

[Michael McSharry]

My event was the same as yours. The MQTT payload needs to change to trigger it. You will see the Device Value incrementing on each change of the MQTT payload from the prior received MQTT payload.

[ServiceXp]

My event was the same as yours. The MQTT payload needs to change to trigger it. You will see the Device Value incrementing on each change of the MQTT payload from the prior received MQTT payload.

I know this is irrelevant but It's got to be possible, the MQTT PI triggers.

I'll mess around to see if I can do this another way.

[Michael McSharry]

What I am doing now is building a list of VSP based upon received payloads for a device. That will allow a specific Value to be assigned to a specific payload text. Dont know, however, if changing only the Value and not updating the String (e.g. like the current On/Off button) will have any change in how your system is reacting to trigger conditions.

[Michael McSharry]

I'm thinking that it may be related to the VSP-related settings. Let me play with it to recreate what you have on the Advanced Tab.

[Michael McSharry]

I was not able to prevent my triggering of events on received messages. What I have done, but have run out of time today is for the plugin to keep track of list of payloads for a topic and map these into Device Values. It will be in 3.2.10.0 likely tomorrow. It provided pull-downs for control and explicit Device Value numbers when the specific text is received. In the sample, if the topic payload is C18 then SetDeviceValueByRef will store 4 in the DeviceValue.

In the attached is just a test where I was generating 15 different text values for a topic.

[ServiceXp]

Thanks for all your help.

[Steve Q]

[Michael McSharry]

I read through the manual (April 3 ver) for the plugin twice. And I read section 4 multiple times. But I was not able to get “accepted” devices to work. I found it extremely difficult to determine which message to check mark. After a lot of trial and error, I got the devices shown below working. I am able to control the sonoffs from the device utility page and from some test events I created.

Can you provide your through process as you were trying to use it. The intention was to make it as easy as possible to marry HS and MQTT.

The basic premise is that you can see what is available from your MQTT broker and select with only a checkbox in the "A" column to have a HS device created to show what is being published on that topic.

If you want to make this same HS device publish a topic based upon a change in the HS device then you specify the topic on the same row as the "A" checkbox.

In general the mcsMQTT Receive trigger will not be used, but triggers setup on Device Value changes. The timeout trigger is unique. The connect trigger could also be done on the Connect device if you have the Statistics echoed in HS status devices. On the Action side of the Events it is a user preference to have an action that publishes a MQTT message or changes a Device which then publishes the message on the topic that was associated with the device.

You seem to have much setup, but I do not understand what you tried and did not work to achieve your objectives.

[Steve Q]

[Michael McSharry]

I have posted 3.2.10.0 in the updater

On the surface what has changed is the new Status/Control UI option on the Manual Tab to include a List and changed the name of statusonly to Unspecified.

Under the hood the method of determining the appropriate HS status/control for an accepted device has totally change and become more generalized. There still is the On/Off/Open/Close special conditions, but they only come into play if payloads containing only one of the two states has been received. In this case the user operation has not changed.

This internal change simplified many special condition logic paths so it should make the operation more reliable, but with such simplifications there is the potential that a logic path that worked in the past no longer works. It also added an entry to the database table as well as created a new database table to keep track of the status-value relationships.

During testing I discovered some bugs with the HS implementation of a text enumeration control associated with a list of value-status-pairs. When both status and control are requested, HS will only provide control. If one mucks with this on the Device Management VSP tab then the control disappears. Also the SetIOMulti also has a bug when trying to use the status. It provides the wrong status for the value provided. I worked around this by using the status that the plugin keeps itself.

When non-numeric payloads are received mcsMQTT remembers them and makes a Device Status Pair relationship. The listing will appear on the Manual Tab under the VSP option. If a topic becomes accepted mcsMQTT will look at the Payloads that have been received and determine the the appropriate status UI control.

When a payload is received that matches one of the status/label conditions specified then the Device Value will be set to the associated Value. If the type is set to Text rather than List then Device String will be set rather than Device Valuee, but Device Value will be set to the existing value to support trigger conditions.

A text box is provided at the bottom to the VSP row of the Manual Tab. Entries here will be appended to the already discovered payloads. This allows one to define the expected payloads before they are actually received. For example if FanOn has been received, but FanOff has not, then FanOff can be added.

When using this new text box there are three options. One is add a new text status and the value will be assigned automatically. Jut put the new status in the box. Another is to use the syntax with "=" (e.g. FanOff=2) in the entry. This will assign a specific value to the new status. The third is to enter the status of an existing status and this will delete it from the list. The numeric value will not be reused unless done manually with x=y syntax.

The Config Link has also been added to allow hyperlink from the Plugin Page to the mcsMQTT page more easily.

[Steve Q]

Michael, mcsMQTT is running on my HS3 test computer. Can I run a second implementation on my production HS3 machine? This would allow me to make the transition from some of my xAP stuff to MQTT more easily.

[Pete]

@Steve here testing on my HS3 Lite and Pro machines (Linux). I do shut one instance off while testing the other instance.

Only testing 1-wire Red Node stuff with simple 1-wire networks. (here currently testing with Maxim 9097 serial devices to USB cables and OWFS)





Will post the flow for a temperature and humidity sensor. All you need to change is the 1-wire rom id.

Only issue here was learning how to utilize Red Node and relating to temperature conversions in Red Node.

Red Node 1-wire and MQTT is running on RPi's which have recently been upgraded to Stretch.

[Steve Q]