From the Consumer, how do you get which adapter or tenant the message is originating from?

[pellmann]

You should know the tenant, because you have subscribed to it, or not? If you subscribed to all, there is no defined way to know this from the messages.

In case of the adapters the base idea was, that Hono abstracts this layer, so that it does not matter if the device talks to MQTT or HTTP or whatever.

It would be possible to add such information as meta data and I would like to understand your use case for such data. Could you describe it and do you think it is common?

In fact you could read the tenant_id from the message annotations in the moment - but we have not defined this in our APIs and we might remove this in the future. Also if we would add such meta data for the consumer, I think we would not use these annotations.

[zubairhamed]

1. Yes so from the perspective of an app serving a singular tenant, sure that's obvious. I'm asking from the 2nd part where Hono is used/built to build a Platform to serve further customer and tenants down the chain.

2. The point about being from which adapter. Imagine a machinery or product which has multi radio capabilities. This could be a vehicle which has data sending over LPWAN for certain data and another radio e.g. Bluetooth or Wifi sending different set or class of data. The Obvious solution would be to create different device IDs for each radio. But what if different radios send the same deviceIds (e..g Vehicle Serial) to identify the vehicle and not the radio?

SO over LPWAN we could be getting a few bytes of data and over Wifi a JSON document. The consumer knowing what's the source could decide how to handle the data. Metadata of the payload i think could suffice.

Z

[pellmann]

Hi Zubair,

thanks for your explanations to the use case. My comments:

1. Also in a platform you need to assign the messages to the tenants at the end. And if there is no tenant, who wants to consume the data, the adapter (or also the device, if possible by protocol) maybe should not send the telemetry in the network. So it might be a good solution to subscribe n times to Hono with each tenant of your platform? Then you would also know the tenant.

2. So you have different message data with different semantics, which could be send by the same device (same device_id). Is it not also possible, that this data could be send also over the same adapter? So I wonder if the adapter-type is the correct data to differentiate between this. For me it seems to be the best, that the device sends this with different content-type. You could do this with the REST adapter. Since we have no meta data at MQTT at the moment it is not possible there, but we already thought about "property-bags" to allow this also in MQTT. WDYT?

[sophokles73]

I think adding some meta data to the downstream message wouldn't hurt. We already include a content type, even though, as @pellmann pointed out, we have no proper way of having an MQTT client specify one yet. However, the content type usually has nothing to do with the transport protocol the message has been received via, does it? So I would not mind if we simply added a property to the downstream message indicating the type of protocol adapter over which the message had been received. We can then leave it up to the consumer to make use of that info or not. We might even find out that this kind of information eventually comes in handy for implementing command & control ...

@zubairhamed would you like to create a PR for this?

[zubairhamed]

Sounds like a plan.

[sophokles73]

In the context of #388 we already discuss the need for an adapter type which is used to identify the types of protocol adapters that a particular tenant is authorized/entitled to use, e.g. because the tenant has subscribed to a plan that is limited to certain protocols only.

IMHO we should therefore define a type name property to be configured for a protocol adapter and which we can then use for both the purpose described in this issue as well as for identifying the protocol adapter types a tenant supports.

[sophokles73]

I am currently working on this one and ran into two questions:

1. Does it make sense to make the type name configurable for an adapter? I do not think so, instead the type name should be considered an inherent property of the adapter (code) and thus it should not be possible to change it.
2. Should we allow an empty type name and then only include the type name in downstream messages if it is not null? I cannot really think of a case where it would not be possible to define a reasonable type name, though. Thus, I think we should require it to be non-null.

WDYT? @zubairhamed @ppatierno @dejanb @sysexcontrol

[sysexcontrol]

I agree to both points :+1: Protocol adapters are such a fundamental piece in the architecture that they should be forced to provide a non-null type that can be reliably used in consumer code.

[ppatierno]

@sophokles73 I'm with you about the type and that it should be non-null but I was wondering if the needed information should be the adapter type or the original protocol (or both ?). It seems to be 1-to-1 mapping but thinking about the current Kura adapter we have, the information should be adapter-type=kura or that the original used protocol was MQTT (used by Kura) ? In this case we have 2 adapters (Kura and Vert.x MQTT) handling the same raw protocol. Just asking ... In any case I agree on both points you described.

[sophokles73]

@ppatierno I was asking myself the same question regarding whether the name should indicate the protocol or not. There will most likely not be a 1:1 mapping between adapters and protocols (as you already pointed out), but I think that @zubairhamed 's original intention was not (only) to know the transport protocol that the message was received over, but indeed to know the exact (type of) protocol adapter. My understanding is that the consumer will need to have specific knowledge about the implementation of the particular adapter (type) in order to make use of this information anyway. So I think that the consumer will also know the transport in use if it knows (recognizes) the type of adapter. @zubairhamed is this a reasonable assumption?

[sysexcontrol]

BTW: While looking at the state of the Tenant API PR #402, the adapter type (which is not null and is unique per adapter, and not "only" per protocol) is a prerequisite, too.

[zubairhamed]

@sophokles73 Yes that's a reasonable assumption although i'd say knowing the transport isn't as useful as knowing the adapter itself. Knowing the adapter would typically infer knowing the transport.