Thanks Patrick, I will give it a try. On Fri, Jun 12, 2015 at 11:48 AM, Lankswert, Patrick < patrick.lankswert at intel.com> wrote:
> Cesar, > > > > Walking the code, it looks like IoTClientResource::resource is bound to a > fully qualified resource which means that the message is going out unicast. > I **think** what you need to do is create a resource using the resource > factory (I **think** it is called constructResourceObject (?)) with the > multicast address. > > > > NOTE: Unless you want to know who is out there, you will not need to do a > resource discovery. All resources that match the URI should receive the > message. > > > > Pat > > > > *From:* Cesar Meira [mailto:cesarsulteste1 at gmail.com] > *Sent:* Thursday, June 11, 2015 8:45 AM > *To:* ???(Uze Choi) > *Cc:* Lankswert, Patrick; iotivity-dev at lists.iotivity.org > > *Subject:* Re: [dev] Broadcast messages > > > > @Patrick > > Short answer: its in the main.cpp of the client, when I call > redLed->put(1) and redLed->put(0). > > Long answer: I tried to code in a way that it should be easy to add or > change resources like leds, buttons, buzzers and so on. > > > > In the client, the IoTClient object will initialize the IoTivity as client > and will call IoTClientResourceManager::initialize(). This manager will > basically call the IoTClientResource::initialize() from all resources > present in list. The RedLed resource object inherits from > IoTClientResource. I did this way so the resource objects, like RedLed, > will only need to implement the put(), post(), get() and the replies, > leaving the IoTivity specific routines to IoTClientResource. > > The "easyness" is that, if I want to implement another resource, like > "GreenLed", all I have to do is inherit it from IoTClientResource, > implement the virtual methods (initialize and put/get/post replies) and the > resource specific put/get/post methods, and add an instance of this object > in the IoTClientResourceManager list. > > The server side works in a similar way. The class names are a little > different because I coded them first and forgot to update them later. > > It might not be really a broadcast message. The client is sending a > message to the "/red_led" endpoint, and I expected that all servers that > registered this endpoint would receive this message, but that was not the > case. > > @Uze > > I think the second case is more like I want to accomplish. Using your > example of the fire alarm, what is in my mind is this: > > There are smoke sensors, sirens and flash lights in this fire alarm > system, all in the IoTivity network. If one of the smoke sensors detect > smoke, it would send a message to the network, pretty much like "I have > detected smoke". The sirens and the flash lights would receive this message > from the network and go off. > > I guessed using the endpoint would be the way to do this. The sirens and > flash light would all try to register the endpoint "/alarm", and the smoke > sensor, knowing that, would send a message to this endpoint. > > > > On Thu, Jun 11, 2015 at 5:09 AM, ???(Uze Choi) <uzchoi at samsung.com> wrote: > > ?sending message into n device? could be interpreted into two cases. > > > > One is the after finding the devices and send to them. > > e.g) find the ?notification alarm? resource and send the > message to them as single shot. > > ? This need to be handled from the Group concept. > > The other is broadcasting the message in to the network. > > e.g) fire alarm message need to be sent as a single messaging. > > ? We can think about the new special resource which receives > the broadcast(multicast) message except the advertisement presence message. > > > > Cesar, what is yours? > > > > BR, Uze Choi > > *From:* iotivity-dev-bounces at lists.iotivity.org [mailto: > iotivity-dev-bounces at lists.iotivity.org] *On Behalf Of *Lankswert, Patrick > *Sent:* Wednesday, June 10, 2015 11:59 PM > *To:* Cesar Meira > > > *Cc:* iotivity-dev at lists.iotivity.org > *Subject:* Re: [dev] Broadcast messages > > > > Cesar, > > > > It was not obvious to me where you were attempting to send a broadcast. > > > > Pat > > > > *From:* Cesar Meira [mailto:cesarsulteste1 at gmail.com] > *Sent:* Wednesday, June 10, 2015 7:45 AM > *To:* Lankswert, Patrick > *Cc:* iotivity-dev at lists.iotivity.org > *Subject:* Re: [dev] Broadcast messages > > > > Sure, I have attached the client and server codes. > > Any questions please let me know, and thanks for your time! > > > > On Tue, Jun 9, 2015 at 12:02 PM, Lankswert, Patrick < > patrick.lankswert at intel.com> wrote: > > Cesar, > > > > It should work with caveats. Can you share the code that you are using to > broadcast the message? > > > > Here are the caveats: > > ? Broadcast message cannot be confirmed since you do not know who > will receive it in advance > > ? UDP and the broadcast (multicast) methods are best effort and > therefore packets may be lost although very unlikely on a local network > with a modern switch > > > > Pat > > > > *From:* iotivity-dev-bounces at lists.iotivity.org [mailto: > iotivity-dev-bounces at lists.iotivity.org] *On Behalf Of *Cesar Meira > *Sent:* Tuesday, June 09, 2015 9:21 AM > *To:* iotivity-dev at lists.iotivity.org > *Subject:* [dev] Broadcast messages > > > > Hello all, > > > > I did a little 'hello world' application using IoTivity, sending a command > to a device to turn a led on and off. The server runs in a Raspberry Pi and > the client in a Linux notebook. > > The application did okay with this configuration. But then I tried to push > a little forward and added another Raspberry Pi, with the exactly same code > as the previous one. The objective was to test if the client could send > "broadcast messages", and if similar devices could receive them. > > I set both RPis to register the endpoint "/red_led". My idea was that when > the client sends a command "turn on" to endpoint "/red_led", both RPis > would receive this command, but in the end only one of them received the > message. > > So, is there a way to send a single broadcast message to "n" devices? Did > I just misinterpreted the idea of the endpoint? > > Thanks in advance! > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150618/274e6e41/attachment.html>
