Hi All,
We have come up with $subject for a client requirement. Basic mandate here
was to come up with mechanism where in once a policy is declared in the IoT
Framework against a device type or device, for that policy to be propagated
to target recipient devices, which are gateways or hubs listening to
subordinate devices/sensors attached to them.
For now we have done the implementation only against device types, we hope
to extend same for individual devices later on. The underlying architecture
of the implementation is as follows.
[image: Inline image 1]
Basically once a policy (which is essentially a siddhi query) is declared
in the IOT Framework against a device type, it will be pushed to a MQTT
topic specific to that user, and device type and the device, which in this
case we have called a FireAlarm (that will mimic a gateway/hub) equipped
with a Raspberry Pi, has a configurable agent running in it that will
subscribe to the earlier mentioned topic. Once a new policy/update to an
existing policy is detected the agent will go ahead and persist said policy
in the device. This policy in turn will be used by the agent to start the
siddhi engine that will listen for changes in sensory data and perform the
Edge Computing tasks ( If the sensory data exceeds a certain threshold
withing a certain amount of time, siddhi will go ahead and invoke a certain
action).
The code that will run on the device end (Raspberry Pi) that takes care of
receiving updated policies and executing the Siddhi Engine, can be found at
[1].
*Improvements*
- For the purpose of this demonstration, we have left the MQTT topics
open, ideally they need to be made secure.
- Since wild card based publishing of messages to topics is not
tolerated, we can write a program in such a way so that once message is
published to a topic like "
*/iot/devicemgt/control/FireAlarm/user1/Group1*" the IOT Framework being
aware of the hierarchy of topics at play, communicates same to all the
devices registered under that user, of that device type and in said group,
etc.
- On the contrary one may argue that if we push a messages that are
meant to all devices to a device type to a topic like "
*/iot/devicemgt/control/FireAlarm/*" and if the recipient set of devices
are subscribed to a wildcard topic like "
*/iot/devicemgt/control/FireAlarm/#*" the device should be able to
receive both device type broadcasts along with device specific
communications without hassle. In order to do this, we would require some
validation to be done at the agent side to filter out what messages are
"meant" to be received that particular device and process same, but that
would be a violation of privacy and a misuse of MQTT IMHO, as it is meant
to me a many to many protocol rather than a 1 to 1 mode of communication.
- Going forward we hope to do this implementation using XMPP, given the
more flexibility it will render us with the requirements.
1. We can register devices in the jabber servers as users then get to
know their active inactive states
2. We can push to individual devices/groups as required without the
need to have client side logic to determine which message should be
received by whom
Please feel free to weigh in your thoughts as to how we can improve same,
going forward.
[1] -
https://github.com/wso2-dev/device-cloud-appliances/tree/master/RaspberryCEPAgent/FireAlarm
Thanks and Regards,
Ruwan Yatawara
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
