Is it possible to pass variable from gateway scope to client scope?

My first reply in this topic presented the solution as a choice between a gateway tag and some kind of explicit messaging. I wasn’t just speculating. Those are your only two choices.

Yep, you’re right, I am merging two independent but related issues that I am trying to solve:

  1. use the dictionary within tags and,
  2. use the same dictionary within the client (as this topic was created for)

I was still trying to figure out (1) with scoping and it didn’t register that I would be seeing the same scoping issues for both problems. My reply above however was related more to (1) rather than (2), but I see now that I still have my (2) issue to solve which, considering option “gateway tag” is out due to json size, it appears that my only remaining option will be to use messaging.

At this point, I would normally point you at system.util.getGlobals(), as that is the dictionary you would use to share items across the gateway, and persist them through script restarts. By you tagged this topic with v8.0, and that function is broken in v8.0. You really need to upgrade to v8.1 for a solid solution. (Search for me and getGlobals here on the forum.)

Whoops, I didn't realise there was a tag for 8.1; we're using 8.1.0, but I did try using getGlobals() initially, but it didn't appear to carry the value across different scopes.. maybe it was fixed later than 8.1.0?

It should work across the gateway. Not from gateway to client or designer.

Now I’ll have to test that. /:

getGlobals() is not synced across scopes and it’s also not synced to the backup in redundant pair.

So messaging it is I guess

Well, shoot. I guess I’ll be bringing my LifeCycle module to v8.1 after all.

Say again? What does (did?) this module do?

Are you using a database that supports JSON columns? If so, utilize that. On your gateway timer, update the db with your new values and have your clients poll it.

One of the datatypes somewhere in the structure you're passing into jsonEncode is more than likely not a real dict/list type and jsonEncode barfs on them. There was a recent forum discussion about this failure symptom.

This is a problem with duck-typing languages in general. As I put it to my colleague, something in the structure can walk like a duck and quack like a duck, and has been passing as a duck for a very long time, but when I asked it to lay an egg it fell over and died.

1 Like

Interesting! I’ll see if I have any foxes amongst my ducks and I’ll put a ducksuit on them :slight_smile: I’m betting it could be, as Paul mentioned in that post, maybe a QualifiedValue got in there… Cheers

In my case, it was a bit more hard to spot, as some values that had come through Perspective properties at some point had been turned into PropertyTreeScriptWrapper$ObjectWrapper and PropertyTreeScriptWrapper$ArrayWrapper elements that were very good at imitating dicts and lists until they got into jsonEncode.

It’s got barely minutes of testing on it, but this snippet of code helped me spot my bad elements:

[EDIT: Removed this snippet as I put a more robust one over on this post.]

might have been a boy duck.... :innocent:

/me runs away

4 Likes

and there it is…

label 			<type 'unicode'>
displayPath 	<type 'str'>
source 			<type 'com.inductiveautomation.ignition.common.QualifiedPath'>
tagProvider 	<type 'str'>
tagPath 		<type 'str'>
name 			<type 'unicode'>
eventTime 		<type 'java.util.Date'>
state 			<type 'str'>

1 Like

A better/more idiomatic way to do this is to duck-type via hasattr; see the author's solution in this SO post:

1 Like

This is one of the best threads I have read. Entertaining, light (from one viewpoint), very deep (from another), and full of really good information. Thanks!

Hopefully not wandering too far off topic here, but how does hasattr(xxx, '__getitem__') return false on a PropertyTreeScriptWrapper$ObjectWrapper? It has a keys() method and you can get sub-items using xxx[key]! It's like a duck missing a foot but still able to swim and walk somehow...

Jython’s a little bit weird.
image