Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [kura-dev] Kura to IBM IoT Foundation
Hi Ian,

Our aim is to provide a robust yet flexible framework, so certainly we won’t to be compatible with as many cloud services as possible. This is one reason for the layered transport services. We didn’t want to completely hide the underlying transport mechanisms in case developers needed fine grain control. The DataService is more flexible but lacks some of the features of the CloudService. Obviously, the more features Kura provides in its services, the more difficult it will be to remain cloud service agnostic. That said, suggestions such as yours are valid and appreciated.

Thanks,
--Dave

On Oct 26, 2015, at 12:10, Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx> wrote:

Hi Dave,

I did wonder about using the DataService directly, but the tutorials I was following didn't mention it.  I'll try it out, thanks.

Is the goal that a Kura application should be able to work with any cloud service without needing to be changed?  It seems to me that this would be a worthy aim, but is it in the Kura plan? 

Thanks

Ian

On 10/26/2015 03:29 PM, Woodard, David wrote:
Hi Ian,

There have been a few posts in the forums also suggesting the CloudService topic namespace is too restricive. We are currently reviewing a set of CloudService options to expose to the ConfigurationAdmin. I think your request sounds reasonable, I will add it to the list of items to review.

In the meantime, do you need all the functionality of the CloudService? If not, you can use the DataService directly, which would give you complete control of the topic name space. Benjamin Cabe’s greenhouse demo [1] uses this approach. I understand the CloudService offers many useful features, so we will review your requested change. The DataService, however, may get you going for proof of concept purposes. 


Thanks,
--Dave

On Oct 25, 2015, at 13:39, Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx> wrote:

Hi all,

as Benjamin recently did some work to get Kura connected to AWS IoT, I thought I'd better do the same for IBM's IoT Foundation :-)

I have got quite far.  Kura is connecting, and I am able to send event messages, but not quite in the format that IoTF is expecting.  An application has to use a client id of the form

a:orgid:app_id

and a provided username/password combination to authenticate.    This I can do by setting the clientid, username and password properties of MqttDataTransport.  So far so good.

Now we are expected to publish JSON formatted events on this topic:

    iot-2/type/$(device_type)/id/$(device_id)/evt/$(event_id)/fmt/$(format_string)

I can set topic.context.account-name to "iot-2".  But I don't want the client id to figure in the topic name.  I can get the application to publish on topic:

    iot-2/type/heater/id/pi-heater/evt/temperatures/fmt/JSON

but only by configuring the client id as "type" which won't allow me to connect to IoTF.  The appTopic I use is:

    "id/pi-heater/evt/temperatures/fmt/JSON"

What about allowing the message topic prefix to be configured in the same way as lwt.topic?  Or any other suggestions?

I haven't got to subscribing yet, but the topics are the same for receiving commands intended for a device:

    iot-2/type/$(device_type)/id/$(device_id)/cmd/$(command_id)/fmt/$(format_string)

where wildcards can be used for the substituted variables.

Thanks

-- 
Ian Craggs                          
icraggs@xxxxxxxxxx                 IBM United Kingdom
Paho Project Lead; Committer on Mosquitto
_______________________________________________
kura-dev mailing list
kura-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/kura-dev



_______________________________________________
kura-dev mailing list
kura-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/kura-dev

-- 
Ian Craggs                          
icraggs@xxxxxxxxxx                 IBM United Kingdom
Paho Project Lead; Committer on Mosquitto
_______________________________________________
kura-dev mailing list
kura-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/kura-dev

Back to the top