MQTT and Non-MQTT data refresh

[baraspatch]

Hey All,

Fairly new to thingworx but have a good grasp on OO and programming, need some help . Thingworx 8 runnning MQTT moquitto broker on a raspberry pi getting data from multiple arduino sensors.

so my design is using a single thing called MQTTGAteway which handles all properties (Pub and Sub) to the physical world ( arduino side).

on the thingworx side i use a data model similar to MVC.

so for example i have a ThingTemplate called WaterHeaterTT and then inherited from this i have Tank1WaterHeater , Tank2WaterHeater and etc. in the thing ( Tank1WaterHeater ) , i properties that are local bound to MQTT properties which are bound to topics.

for example Tank1WaterHeater has watertemp ( bound to MQTTGateway property ) and WaterHeater which is bound to (MQTTGateway waterheater1).

On the MQTTGateway properties are logged and always in regard to data change type.

My problem is that i build a mashup of WaterTank1 which has temp and waterheater on/off state. Now on the mashup i drop a couple of numeric entries to test display and refresh using refresh widget set to 5 second intervals

mashup

numeric entry ------> Thing(Tank1WaterHeater). water Heater state

numeric entry ---> Thing(Tank1WaterHeater).watertemp

numeric entry ---> MQTTGateway.water heater state

numeric entry ----> MQTTGateway.watertemp

so four fields , if i run this mashup what happens is that MQTT Gateway fields are constantly refreshed but the Thing fields ( which local bound the same fields as the MQTTGateway fields) not refreshed. The only way to go into the thing and hit refresh on the property screen of hit save on the object.

Hope this makes sense , hoping somebody can help with this.

Cheers

Paul B

[MarekP.Nowaczyk]

Paul, check if the issue you are facing is same as described in this article Article Viewer | PTC:

The AutoMapping functionality of the MQTT and MQTTSubscriber Thing Templates automatically establishes a subscription and a publish arrangement with the MQTT broker for all properties defined on the Thing.

• MQTT messages sent to the broker with topics corresponding to an auto-mapped property are automatically subscribed and will update the property values on the Thing when received.
• Property value changes on the Thing will be sent out as Publish messages to the MQTT broker, which then are sent back to ThingWorx as a subscribed topic update.
• A ThingWorx subscription that is configured to change a property value on an MQTT Thing in response to a data change on that same MQTT Thing can result in a blocked thread.

Article provides also possible workaround:

Define publish / subscribe subscriptions for properties manually on the Thing in question.

• For properties that must be updating from MQTT, make sure to set the subscribe flag on the mapping that is created.
• For properties that should not be sending out updates to MQTT, do not set the publish flag on the mapping.
• Avoid setting up mappings that do both publish and subscribe, especially where the property is likely to be modified during an MQTT triggered event.