data change event in subscription doesn't work

[IA_10816220]

hi,

i am new to thingworx and I am using it for IOT app involves MQTT,

i am trying to create an mqtt parser thing, the parser will recive raw data from mqtt broker and in the same thing i want to extract the data from the message and save it in properties 
here is my raw data json :
{"deviceId" : "3102-0153-21", "Timestamp":"23/10/2024 11:18:52", "Digital Input":7}
my thing can get this message no problem and save it inside the Intrusion_raw_data property,
next i created a subscription to run on data change event for the Intrusion_raw_data property , here is the script:

me.Timestamp = me.Intrusion_raw_data["Timestamp"];
me.sn = me.Intrusion_raw_data["deviceId"];
me.Digital_Input = me.Intrusion_raw_data["Digital Input"];

when new data comes from the broker the Intrusion_raw_data property updates fine and get the new data and i can see it, but it looks like the subscription does not run , but when i try to change the Intrusion_raw_data manually inside the thing it self the subscription script runs fine and update the other properties without any problems,

in short , when the Intrusion_raw_data recive new data the script doesn't work but when i change the data inside the Intrusion_raw_data manually the script works,

thanks for your time 

[Constantine]

Hey,

New subscriptions are disabled by default. Make sure you check the corresponding checkbox.

Also, check "Data change type" on your Intrusion_raw_data property -- it controls how it fires DataChange events. If it's set to "Value" (default), then your subscription will only fire when data actually changes, not every time you received something. To troubleshoot you can try setting it to "Always".

/ Constantine

[IA_10816220]

can you explain more what you mean as i did enable all of these 

[Constantine]

I was referring to "Enabled" checkbox -- you have it. Also check this one, maybe try setting it to "Always" and see if it helps:

Finally, try to change its data type from JSON to STRING, see what happens.

One more thing you can try is replace your subscription code with something like logger.error('FIRED'); and check your logs.

[IA_10816220]

i really appreciate your support 

i tried this one too but still not working

[Constantine]

Did you try everything I suggested?

1. Change property base type from JSON to STRING
2. Replace subscription code with logger.error('FIRED');
3. Use "Always" change type

...and after that you don't see "FIRED" in the application log? Then I'm out of ideas, sorry. Well, four other random thoughts, might help to understand it better:

1. Try with AnyDataChange event
2. Try to play with your property attributes, i.e. make it (non)persistable, (non)logged, (non)indexed, remove bindings, if any.
3. Try to subscribe to your DataChange from another thing
4. Check if there's any relevant settings on the MQTT thing's Configuration (in addition to Mappings)

[Constantine]

Before you spend time on trying any of that, check what Javed wrote below, it makes more sense. I completely forgot about permissions, that must be it!

[javed_a · Accepted solution]

Additionally, you can try permission shown in attached image and code snippet as below:

           var params = {
                infoTableName: "UpdatePropertiesInfoTableTMP" /* STRING */,
                dataShapeName: "NamedVTQ" /* DATASHAPENAME */
            };
            var updateValues = Resources["InfoTableFunctions"].CreateInfoTableFromDataShape(params);
            var time = new Date();
            updateValues.AddRow({'time': time, 'name': propName, 'quality': 'GOOD', 'value': propValue});
            Things[thingName].UpdatePropertyValues({values: updateValues});

[IA_10816220]

sorry maybe I am a bit confused, is there a difference between the permissions section on the bottom far left of the menu and the permissions tab inside the thing itself ? 
as i tried to re-do it again from the permissions section inside the thing itself but set all properties to "checked" it also worked , so is there a difference between these two permissions section ether from the left menu or from inside the thing ?

[javed_a]

Yes, there is difference.

The step I suggested will be applied to all the Things available in platform, however if you do it at thing level you need to do it, every time for each applicable thing.

[Constantine]

Just my 2 cents.

Runtime permissions (not visibility!) for a given Thing are based on

1. Collection permissions (all Things),
2. Thing Template permissions (for things based on this template),
3. Thing's own permissions,
4. Thing's owner (user who created the thing).

Those create a surprisingly complex inheritance hierarchy, especially given that

1. Thing Template permissions are inherited "in parallel" with collection ones,
2. Permissions have three states -- allow, deny and inherit,
3. You can assign permissions to user groups and individual users,
4. You can assign permissions to all services and then override them on the individual service level,
5. When you execute services from other services, then you get the second security context called System.

With all that in mind, permissions don't always work as you'd naively expect. For instance, I wouldn't be able to say with certainty beforehand what would happen if you deny a user all services execution on the ThingTemplate level, and then grant it to System user on a specific service on the Thing level.

The best way to get a feeling of how it works is by doing a lot of trial and error.

/ Constantine