Payload

[Michael McSharry]

Please post the \Data\mcsMQTT\mcsMQTT_Debug.txt after enabling the General Debug from General tab and doing an edit of your event with common topic.

V3.3.0.0 does not change the event logic. It only adds payload information in the debug output.

[frankis78]

Here is the log

I updated the plugin today , about 1 hour ago.
https://www.dropbox.com/s/p4pornekcn...Debug.txt?dl=0

[Eman]

Can you also assign the EVENT TYPE name to the first event and edit it alone to see if it affects the second event.
If doesn't then assign the same type name and see if the problem persists



Eman.

[Michael McSharry]

The debug shows that the same 9794 Unique ID for the event trigger is used with payloads being either ARMED or DISARMED. The UID is a parameter passed to the plugin by HS and is used by the plugin to get the specific event trigger information. Since there is only one record for UID=9794 then last entered data will show for it, but since HS3 is using this same UID for two events it affects both.

I do not have visibility into how HS3 assigns or manages the UIDs for events. If deleting and recreating both events does not solve the issue I see two options. One is to submit a ticket for HS3 bug. The other is to Accept this topic so its Payload is mapped into a HS3 device. Select List as the Control/Status type on the Manual tab so VSPs wil be created that assign numbers to ARMED and DISARMED. If there are only two states then you may want to select Button rather than List. In your event then trigger on the Device being ARMED or DISARMED rather than receipt of the MQTT message.

25/04/2018 15:20:04	109295	| ReceiveTriggerBuildUI ID=9794, Topic=verisure/armState/statusType, TrigInfoUID= 9794, Payload=ARMED

25/04/2018 15:20:11	115979	| ReceiveTriggerBuildUI ID=9794, Topic=verisure/armState/statusType, TrigInfoUID= 9794, Payload=DISARMED

25/04/2018 15:20:38	142990	| ReceiveTriggerBuildUI ID=9794, Topic=verisure/armState/statusType, TrigInfoUID= 9794, Payload=DISARMED

25/04/2018 15:21:02	167185	| ReceiveTriggerBuildUI ID=9794, Topic=verisure/armState/statusType, TrigInfoUID= 9794, Payload=ARMED

[uwerner]

"The other is to Accept this topic so its Payload is mapped into a HS3 device. Select List as the Control/Status type on the Manual tab so VSPs wil be created that assign numbers to ARMED and DISARMED. If there are only two states then you may want to select Button rather than List. In your event then trigger on the Device being ARMED or DISARMED rather than receipt of the MQTT message."



Just today I cam across the same issue. Michaels workaround will do the trick.

[frankis78]

I recreated both event, and actually now it seems to stick
https://www.screencast.com/t/6lY242OS3eU9

This time i didnt create one event , and copied it to the next event, but i created them from scratch. Not sure if this makes a difference though.

Anyway, i what i am missing in this plugin, is some manual how to use it for normal use.
Example, should we create virtual devices, that is on and off switches and event to turn these on and off based on payload, or should we use the device that is created by the plugin , and make this a real device which can be used later in event.
Right now, i created a virtual device called doorlock, and an event that turns this on and off based on the payload. , and then i will use this further on to send command to other stuff.
But maby i dont need this extra virtual device, and that i can use the payload device?
I hope to see more relevant instruction in the manual, how to use it for dayly normal use

[Michael McSharry]

It seems odd that HS would have a problem in this very common area so I looked at the SDK and find the following definition for the parameter passed between HS and the plugin. It is not clear who has responsibility for the UID in this definition.

strTrigActInfo
This is the prototype for the strTrigActInfo structure, which is used in many of the Trigger and Action related calls and callbacks from HomeSeer.
Structure strTrigActInfo
''' This is the unique event reference ID number for the event that this trigger is a part of.
Public evRef As Integer
''' This is the unique ID for this trigger or action. When the trigger is true, the plug‐in will pass this
''' to HomeSeer to trigger to cause HomeSeer to check the conditions and trigger the event if appropriate.
''' When the action needs to be carried out, HomeSeer will invoke the Handle procedure in the action, and
''' if there is action information stored by the plug‐in, this property can be used to retrieve it.
Public UID As Integer
''' This is for plug‐ins only since plug‐ins can support multiple types of different triggers or actions.
''' This identifies which, out of the triggers or actions offered by the plug‐in, that this trigger
''' or action is.
Public TANumber As Integer

''' When a trigger or action has sub‐types, this is used to identify which sub‐trigger or trigger subtype,
''' sub‐action or action sub‐type this trigger or action is set to. For example, in HomeSeer there is a
''' TIME trigger ‐ the sub‐ID might identify whether it is the type AT, BEFORE, or AFTER a time value.
Public SubTANumber As Integer
''' This is exclusively for plug‐ins. Using a serialization procedure, the data for this plug‐in
''' can be stored and managed within the HomeSeer database by the plug‐in storing the serialized
''' object here. When HomeSeer is calling into the plug‐in and wants to provide the trigger object
''' for the plug‐in to analyze, it provides the serialized object data here in this byte array which
''' the plug‐in can use to de‐serialize back into an object that holds the trigger info. Since
''' parameters cannot be passed through the interface ByRef, this is read‐only, but the plug‐in is
''' allowed to RETURN a structure that includes Data or DataOut, which is a byte array, and contains
''' the serialized object after the plug‐in updated it or made changes to it.
Public DataIn() As Byte
Public Instance As String
End Structure

I did my trigger processing based upon the example in the SDK. Don't have time right now, but when I return I will look back to see the logic flow with respect to how UID is initially created.

[frankis78]

"The other is to Accept this topic so its Payload is mapped into a HS3 device. Select List as the Control/Status type on the Manual tab so VSPs wil be created that assign numbers to ARMED and DISARMED. If there are only two states then you may want to select Button rather than List. In your event then trigger on the Device being ARMED or DISARMED rather than receipt of the MQTT message."



Just today I cam across the same issue. Michaels workaround will do the trick.

Problem is that there is no good instruction how to do it.
The manual takes care of many things, but it is a lack of relevant use.
Im missing the more "How to" convert a payload to a button etc.
Although im new to MQTT, i read the manual , but i have a problem to convert it into real life.

[Eman]

@frankis78 can you look again on how to send payload for you devices instructions, they may be even on/off (Armed/Disarmed) or even case sensitive. Because when I looked your at your events you seem to be doubling up on how to control the device. ====> If the devices are already sending their status to the plugin then their status is known so allow/activate them in the plugin settings thus creating virtual devices.

So IF say when you alive home ====> THEN send mqtt topic /Verisure/Doorlock/ "payload" ====> Payload being DISARMED

Tip : There is no need to query the status because it's already assumed! It doesn't even matter if armed or disarmed. ====> That status is only need in other events. It's the payload that matter.

Example =IF Verisure Doorlock is ARMED,
THEN "do something"


Does that help?



Eman.

[Eman]

"The other is to Accept this topic so its Payload is mapped into a HS3 device. Select List as the Control/Status type on the Manual tab so VSPs wil be created that assign numbers to ARMED and DISARMED. If there are only two states then you may want to select Button rather than List. In your event then trigger on the Device being ARMED or DISARMED rather than receipt of the MQTT message."



Just today I cam across the same issue. Michaels workaround will do the trick.

@uwerner,

Can you please be more specific in the steps to take herein your statement :
" If there are only two states then you may want to select Button rather than List. In your event then trigger on the Device being ARMED or DISARMED rather than receipt of the MQTT message."

I believe that's what he is look for how to control his devices.

"A picture can tell a thousand words"


Eman.

[Eman]

@frankis78,

Go over page 7 and 8 a few times including the images. You will start get the picture.
It's true the manual is not easy to understand (geared mostly towards advanced users). It's mostly how the plugin works. So take your time you will love it.

Tip : If you can read the manual from two screens say laptop and you computer so can compare what you reading on one screen and look at the images on the other (seems drastic ) because as you scroll through the pages you quick forget what you just seen.



Eman.

[Michael McSharry]

I welcome anybody who wants to add to the manual to make it more relevant to user needs. It is written n Microsoft Word 2007. Let me know so I can get the source document to you and synchronize our updates.

On the Association tab there is an A column to indicate that a MQTT Topic/JSON Item should be associated with a HS device. User entry of a check in the checkbox will make it happen. HS will assign a Device Reference and mcsMQTT will set the device properties based upon the payloads that it has received. There is no other user action needed. Each time the Topic/JSON item is received from the broker then the HS device will be updated.

If a user has special needs, or if a user wants to see what Device property assignments have been made by mcsMQTT then they can view the Manual tab. If they do this immediately after the A checkbox or after doing any edits on the same row then all the properties will be populated on the tab. They can also be populated by either clicking the Ref button on the Association tab or by entering the Device Ref or Topic:JSONItem on the top of the Manual tab. From the Manual tab all fields can be changed from the auto-assignments made by mcsMQTT.

If only two payload have been received such as ARMED and DISARMED then the Button Control/Status type should already be selected. If there are more then it should default to Text. The payloads that it has observed are listed on the VSP row and this row also shows the Value-Status pairing. This same pairing can be seen on the Device Management page provided by HS3. Editing of VSP, however, should be done in mcsMQTT and not Device Management for VSP because HS3 provides no mechanism for a plugin to read what a user has changed and this will result in the mcsMQTT not being in sync with HS3.

If Text was auto-selected by mcsMQTT then it can be change to either Button or List to have Status-Value relationships established. You want this because HS3 is DeviceValue-focused in event and does not provide triggers for DeviceString which is where Text is stored.

I also traced through HS3 calls to the plugin Trigger-related procedures. The first event-specific call is to asses if what the user has entered is valid. The first time the plugin will return false because the user has only selected the trigger type (MQTT Receive) and has not yet entered the Topic. When this call is made from HS3 to mcsMQTT the UID is passed by HS3 to mcsMQTT so this confirms that HS3 is the one who assigns UIDs to triggers. mcsMQTT does remember the assignment so later when the trigger conditions occurs it is able to tell HS3 which specific trigger occurred.

The bottom line is that I cannot do anything more about it as it looks to be something caused by HS3. Since it only occurs sometimes then the best that can be done by users is to try to identify what they do to cause HS3 to return the same UID for two different events. What sequence of steps confuses HS3?

A ticket can also be submitted. I cannot submit one because I do not have any data to provide HST that will reproduce the situation. If you submit one, then you have the debug data from mcsMQTT that shows two different events have the same UID.

[Eman]

Hi Michael,

@frankis78 mentioned something you must have missed. That UID fault is caused by when one copies the same event. Even though he had changed the names ====> Best practice is to close the first event after editing. So when you edit the copied event and close/save it, it's assigned a new UID number before you close the browser. Because if close the browser when the events are still in edit mode the first UID persist. He should have created one event at a time.
You indeed can copy events but you have to follow best practice!

On the user manual side of things it's the main set up drawings which need tool tips.
Although they appear in web page the text are too tiny and before you read them they disappear! It would have been nice if were in user manual itself. Example : Image





Eman

[Michael McSharry]

On the user manual side of things it's the main set up drawings which need tool tips.
Although they appear in web page the text are too tiny and before you read them they disappear! It would have been nice if were in user manual itself.

I put the tool tips as a reference Section 10 of the manual.

Anyway, i what i am missing in this plugin, is some manual how to use it for normal use.
Example, should we create virtual devices, that is on and off switches and event to turn these on and off based on payload, or should we use the device that is created by the plugin , and make this a real device which can be used later in event.
Right now, i created a virtual device called doorlock, and an event that turns this on and off based on the payload. , and then i will use this further on to send command to other stuff.
But maby i dont need this extra virtual device, and that i can use the payload device?
I hope to see more relevant instruction in the manual, how to use it for dayly normal use

I struggle with how to provide better user instructions. I never considered to create virtual devices for a plugin device. When I want to control a light that is interfaced through a Zwave, X10, UPB or whatever interface then I use the HS devices created by the interface plugin. If the behavior of the real device is not quite what I want then maybe I would create a virtual one, such as having a light that will only respond during nighttime.

Section 4 of the manual is intended to provide the typical use cases that would be applied for the plugin. I would think that "4.1.3 How do I setup a Command/Response Device so HS can control MQTT item and show its status" would cover the typical user need. In this section it intentionally does not go into various options that are available, but tries only to tell the first-time user the basic approach.

If there are other suggestions that you have to help others then please provide so I can include in the manual.

[Eman]

Thank you Michael,
For the generous work you have put into this plugin and provide it for all. A lot of us would not understand the long hours you stayed up to make this plugin make difference to one's system.

Thanks again.

Eman.