just wondered if someone could clarify which parameter of the server side thing is used to bind to the remote thing's edge auto bind parameter. Is it the server side thing's name or its identifier that is used for the binding? In the past our server side things have had their identifier parameter and thing name set to the same value so it hasn't been an issue.
However, now we have a number of different types of remote thing that we wish to connect. Our plan is to have their edge server auto bind parameter use a prefix (AB.xxxxxx & CD.xxxxxx) so we can tell what kind of remote thing it is before we have to create the server side thing. We will use a different thing template depending on what type of remote thing it is.
Some of our remote things' edge servers use the out of box ems with the lua interface but the new ones will be using edge servers created with the C SDK.
Thanks in advance.
Shouldn't be hard to query for unbound remote things (Resources["DeviceFunctions"].GetUnboundRemoteThings(), and create the corresponding thing with the desired template based on the remote thing name. And if you want to have different cloud name vs edge name, you can use the SetIdentifier service on the newly created thing.
thanks for the quick reply. We do have a service looking for unbound things that runs on a timer event & all of that works fine. The question I'm trying to answer is what are the 2 parameters that have to match in order to make the remote thing binding work. Is it:
edge server auto_bind = server side thing name
edge server auto_bind = server side thing identifier
Currently the edge auto bind parameter has a prefix 'AB.xxxx' or 'CD.xxxx' depending on the remote thing's edge server. If we see an unbound thing with 'AB' as the prefix we use one template to create a thing, if we see 'CD' we use another. We set the identifier to be say 'AB.xxxx' but the server side thing name is 'xxxx'. I'd always assumed they bound using the identifier parameter.
I'm just trying to confirm whether it is the server side name or identifier that is used to create the binding to the remote thing.
The reason I ask is that I see the server side things being created, and I can see that they are connected. The problem is none of the remotely bound properties are being updated. I wondered if this might be because the binding to the remote thing is not correct.
You mean that?
Currently we have:
Thingname != Remote Identifier
Haven't tried it the other way yet. I was hoping to avoid having server side thing names with the prefix included.
So are you saying that the server side thingname should match the remote identifier in order to get the remotely bound properties to bind automatically? (Not a massive issue if we have to).
Presumably I could create the remote bindings via a script [SetRemotePropertybinding()] if I want to keep the remote identifier & server side thing name as different values?
I think remote bindings to local properties never get created, you should create by hand with the SetRemotePropertyBinding. Then I don't know which it's the problem you are having with the different naming between thingName and remote identifier, you have all the tools needed to make it work or I'm missing something?
Sorry, forgot to mention that the properties in question are defined as being remotely bound at the template level.
In the past we have defined the bindings there and had no issue. That said the server side thing had the same value for both its thingname & its identifier.
Hi Carles, thanks for all your help, very helpful (as always) & much appreciated.
Can I just confirm that normally you would expect the properties to automatically bind if the edge identifier & the server side thing name match?
Actually I never user this approach, on our use case we can't make any assumptions on the Edge side and always bind "manually". Imagine that you have different versions of the remote device (same hardware different software version) and you relay on the same ThingTemplate and have different amount of properties (and names, deprecated new ones and alike), maybe a better approach to not to have assumptions, but this is just my point of view.