Version 3.2.x.x

[Michael McSharry]

I think you have two solutions presented. One is to use the Event Trigger provided by mcsMQTT based upon Topic and changed Payload. The other is with the Trigger plugin that can trigger events based upon Device String content.

Why will these not work for you?

The only other option I see is to use Value Status Pairs to enumerate the potential textual Payloads and then set the Device Value based upon a match to the VSP Status Text definition.

[ServiceXp]

I think you have two solutions presented. One is to use the Event Trigger provided by mcsMQTT based upon Topic and changed Payload. The other is with the Trigger plugin that can trigger events based upon Device String content.

Why will these not work for you?

The only other option I see is to use Value Status Pairs to enumerate the potential textual Payloads and then set the Device Value based upon a match to the VSP Status Text definition.

1) #1 is doable, but would require a huge amount of work. With hundreds of topics per printer it would be an undertaking to say the least.

2) #2 I'm assuming you are referring to Spud's Easy Trigger PI? I have and do use Spuds PI, but there seems to be 2 problems I have: There are cases where I don't know what the string will contain, and I'm pretty sure I tried to use "has a string that just changed" as the trigger but an update would still not cause the event to fire.

I need to confirm the last statement, as I've tried so many things in an effort to find a solution that I'm a little unsure.

3) I'm not sure I understand #3, but I have a feeling it would fall under #1 problem.

[Michael McSharry]

I think you are not understanding the Event trigger capability that is provided by mcsMQTT. It is not using the contents of a Device to generate a trigger, but is looking at the Topic and Payload to do it. When you setup an event the "IF" is followed by a pulldown selector. You are using "Device Value ..." for this selector. I am suggesting you use "Mqtt Topic Received" for the selector. I posted a screenshot in post #41 of this thread.

The event will trigger when anything changes in the payload from the printer. The action you take when you get a change from the printer may need to look into the Device String to see what the new status is.

[ServiceXp]

I think you are not understanding the Event trigger capability that is provided by mcsMQTT. It is not using the contents of a Device to generate a trigger, but is looking at the Topic and Payload to do it. When you setup an event the "IF" is followed by a pulldown selector. You are using "Device Value ..." for this selector. I am suggesting you use "Mqtt Topic Received" for the selector. I posted a screenshot in post #41 of this thread.

The event will trigger when anything changes in the payload from the printer. The action you take when you get a change from the printer may need to look into the Device String to see what the new status is.

Understood, I guess I was just hoping for an easier solution. Lot's of triggers to change.

I gotta say, the PI you have created is quite remarkable, and your attention to your creation is top notch. Were is your donation button?

Thank You!

[Michael McSharry]

I gotta say, the PI you have created is quite remarkable, and your attention to your creation is top notch. Were is your donation button?

Thank you, but not necessary.

[Michael McSharry]

The browser issues with large tables has been addressed in 3.2.8.0 by limiting the Association table size to 20 rows and providing buttons to scroll or select rows of interest if more than 20 are available per the filtering criteria used.

[ServiceXp]

Ok, So I'm probably not the sharpest tool in the shed, I'll admit that but I think there is something wrong (outside of the interface between the keyboard ).

I've tried several different triggers (spuds ET and mcsMQTT) and it still will not trigger the event. I know ET works because it fires just fine using the MQTT PI created devices.

When ET didn't work I thought Ok, let me try the mcsMQTT trigger.

I tried using just the "FileAddedath", no dice...
so I thought maybe it needs the entire "mpsmoctoprint/event/FileAddedath", no dice....
so I thought maybe it needs "mpsmoctoprint/event/FileAdded"... Nope.

The HS device string and date updates so that part is working, but no matter what I try I can't get a trigger to fire.

..

[Michael McSharry]

The mcsMQTT trigger is based upon MQTT topics so it does not include JSON decoding keys. You can trigger on Topic without the ath (as ath) is not in the actual Topic.

What I am thinking about now is just incrementing a counter in DeviceValue when DeviceString is updated. This would allow a change in DeviceValue be used. It could also be restricted to only increment when the content of the DeviceString changes.

Would either of these work for you?

What is it you are actually trying to do with the MQTT info from your printer?

[Michael McSharry]

I went ahead in 3.2.9.0 and incremented the DeviceValue if a DeviceString change was made. This will allow you to use DeviceValue changes value trigger condition when only text payload is received.

You should be able to go back to what you were originally trying to do in how you setup the event trigger.

[ServiceXp]

The mcsMQTT trigger is based upon MQTT topics so it does not include JSON decoding keys. You can trigger on Topic without the ath (as ath) is not in the actual Topic.

What I am thinking about now is just incrementing a counter in DeviceValue when DeviceString is updated. This would allow a change in DeviceValue be used. It could also be restricted to only increment when the content of the DeviceString changes.

Would either of these work for you?

What is it you are actually trying to do with the MQTT info from your printer?

Understood on the decoding key, but why will it not fire using "mpsmoctoprint/event/FileAdded"?

Or strangely enough using EasyTrigger?

I think there is an underlying problem as there doesn't appear to be a reason why this should not work?

The string in the HS device is changing, but yet it will not fire ET. I don't even understand how that is possible.. :-)

I use the information from the printers to interact with my HA system. At this time it's used as progress/status/HA control information. In other words the printers cannot receive any MQTT messages, they only publish the data. That may change in the future, but for now it's a one-way street.

I use this data to perform actions (ventilation/power control/notification/alerts, etc.) in my house.

Not knowing the limitations of DeviceValue, could you not just send the parsed string/number to it?

At this point, I'll take anything that will fire a trigger based on string OR update time..

[Michael McSharry]

look at the above post at 3.2.9.0 that is in the updater.

Not knowing the limitations of DeviceValue, could you not just send the parsed string/number to it?

DeviceValue has a data type of Double so it occupies probably 64 bits of memory space. Only numbers can be stored in it. Text needs to go into DeviceString that has a data type of String so can accommodate the memory needs of many characters.

but why will it not fire using "mpsmoctoprint/event/FileAdded"?

If you have debug enabled then \data\mcsMQTT\mcsMQTT_Debug.txt is available. If you post it then I call tell you what or why.

[ServiceXp]

look at the above post at 3.2.9.0 that is in the updater.



DeviceValue has a data type of Double so it occupies probably 64 bits of memory space. Only numbers can be stored in it. Text needs to go into DeviceString that has a data type of String so can accommodate the memory needs of many characters.


If you have debug enabled then \data\mcsMQTT\mcsMQTT_Debug.txt is available. If you post it then I call tell you what or why.

I've updated and sadly still not working.

I've "Accepted" a new topic (ClientOpened) just to make sure there wasn't something going on with all of the other devices..

Enabled logs (by the way there is a log (HomeSeer HS3DatamcsMQTTmcsMQTT Debug.txt) being created in the root Programs Files(x86) folder), had one of my printers publish the ClientOpened I did this a couple of times, Restarted HS, Tried again, all logged.

[Michael McSharry]

The good thing is that you have a simple test case and all relevant data. I can see in the debug that two messages were received that should have the DeviceString of Device 2342 set to "ClientOpened". These is a little more logic in the plugin between this and where the DeviceValue and DeviceString are actually set, but it is pretty simple. I will duplicate your test and see I discover anything.

The other thing that you should look at is Device 2342 that is expected to get the ClientOpened DeviceString and incrementing DeviceValue. If you go the Advanced Tab you can observe what HS actually has for Value and String.

[ServiceXp]

Thanks Michael,

I've checked a few of them, and they either have a 1 or 0


..

[Michael McSharry]

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.