Package pt.unl.fct.di.tardis.babel.iot.demos

Class BabelAccelerometerLCDDemo

java.lang.Object

pt.unl.fct.di.novasys.babel.core.GenericProtocol

pt.unl.fct.di.tardis.babel.iot.demos.BabelAccelerometerLCDDemo

All Implemented Interfaces:

BabelDemo

public class BabelAccelerometerLCDDemo
extends pt.unl.fct.di.novasys.babel.core.GenericProtocol
implements BabelDemo

Demo that reads the Grove 3-axis accelerometer and mirrors every reading onto the Grove LCD, illustrating how a Babel application combines an input and an output IoT-control protocol in one app.

Two devices, two protocols:

• the accelerometer is read through I2CInputControlProtocol (id 2100), which here answers point-in-time GetAccelerometerDataRequests with an AccelerometerInputReply;
• the LCD is driven through I2COutputControlProtocol (id 2000) via ShowTextRequest.

Both are I²C peripherals, so RegisterIoTDeviceRequest carries no GPIO line — just a device type and an alias.

The recurring IoT pattern this demo teaches is the request/reply polling flow: the app periodically asks the input protocol for a fresh measurement and renders the reply, rather than waiting on a pushed notification. (For the push/notification style instead, see the gesture demos, which subscribe to GestureNotification.)

The application never touches Pi4J or the I²C bus directly: it only sends Babel requests and consumes Babel replies; the two control protocols do all of the hardware work.

Run with the Accel command-line name (see Main).

Nested Class Summary

Nested classes/interfaces inherited from class pt.unl.fct.di.novasys.babel.core.GenericProtocol

pt.unl.fct.di.novasys.babel.core.GenericProtocol.ProtocolMetricsBabelMetrics

Field Summary

Fields inherited from class pt.unl.fct.di.novasys.babel.core.GenericProtocol

babel, babelSecurity

Fields inherited from interface pt.unl.fct.di.tardis.babel.iot.demos.BabelDemo

PROTO_ID, PROTO_NAME

Constructor Summary

Constructors

Constructor	Description
BabelAccelerometerLCDDemo()	Wires up the protocol identity (name + id) that Babel uses to route events to this protocol.

Method Summary

Modifier and Type	Method	Description
void	execute()	Application bootstrap (the entry point Main calls for the Accel demo).
void	handleAccelerometerInputReply(pt.unl.fct.di.tardis.babel.iot.controlprotocols.replies.AccelerometerInputReply rep, short protocolId)	Reply handler that completes the polling flow: each GetAccelerometerDataRequest sent in handleDemoTimer(pt.unl.fct.di.tardis.babel.iot.demos.events.DemoTimer, long) comes back here as an AccelerometerInputReply.
void	handleDemoTimer(DemoTimer t, long time)	Periodic timer handler: polls the accelerometer for one reading mode per tick, round-robin.
void	handleRegisterIoTDeviceReply(pt.unl.fct.di.tardis.babel.iot.api.replies.RegisterIoTDeviceReply rep, short protocolId)	Reply handler for RegisterIoTDeviceRequest: receives the DeviceHandle for whichever device the control protocol just bound.
void	init(Properties props)	Babel lifecycle hook: register handlers, then request the two devices.

Methods inherited from class pt.unl.fct.di.novasys.babel.core.GenericProtocol

addSecret, addSecret, addSecret, addSecret, cancelTimer, closeConnection, closeConnection, closeConnection, closeConnection, closeConnection, closeConnection, createChannel, createSecureChannel, createSecureChannel, createSecureChannel, createSecureChannelWithAliases, createSecureChannelWithAliases, createSecureChannelWithIdentities, createSecureChannelWithIdentities, createSecureChannelWithProtoIdentities, enableGenericMetrics, generateIdentity, generateIdentity, generateIdentity, generateIdentity, generateIdentity, generateIdentity, generateIdentity, generateSecret, generateSecret, generateSecret, generateSecret, generateSecretFromPassword, generateSecretFromPassword, generateSecretFromPassword, generateSecretFromPassword, getChannelOrThrow, getDefaultChannel, getDefaultProtoIdentity, getDefaultProtoIdentityCrypt, getDefaultProtoSecret, getMillisSinceBabelStart, getOrGenerateDefaultProtoIdentity, getProtoId, getProtoName, hasProtocolThreadStarted, openConnection, openConnection, openConnection, openConnection, registerChannelEventHandler, registerMessageHandler, registerMessageHandler, registerMessageHandler, registerMessageHandler, registerMessageHandler, registerMessageHandler, registerMessageHandler, registerMessageHandler, registerMessageHandler, registerMessageHandler, registerMessageHandler, registerMessageHandler, registerMessageHandler, registerMessageHandler, registerMessageHandler, registerMessageHandler, registerMessageHandler, registerMessageHandler, registerMessageSerializer, registerMetric, registerReplyHandler, registerRequestHandler, registerSharedChannel, registerTimerHandler, sendMessage, sendMessage, sendMessage, sendMessage, sendMessage, sendMessage, sendMessage, sendMessage, sendMessage, sendMessage, sendMessage, sendMessage, sendMessage, sendMessage, sendReply, sendRequest, setDefaultChannel, setDefaultProtoIdentity, setDefaultProtoIdentity, setDefaultProtoSecret, setupPeriodicTimer, setupTimer, startEventThread, subscribeNotification, triggerNotification, unsubscribeNotification

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Constructor Details

BabelAccelerometerLCDDemo

public BabelAccelerometerLCDDemo()

Wires up the protocol identity (name + id) that Babel uses to route events to this protocol. Hardware registration happens later, in init(java.util.Properties).

Method Details

init

public void init(Properties props)
          throws pt.unl.fct.di.novasys.babel.exceptions.HandlerRegistrationException,
IOException

Babel lifecycle hook: register handlers, then request the two devices.

This is the canonical IoT bootstrap. Handlers MUST be registered before the requests that will eventually trigger them, otherwise the reply could arrive with no handler installed:

1. register the timer handler that will poll the accelerometer;
2. register the RegisterIoTDeviceReply handler that brings back the DeviceHandle for each device;
3. register the AccelerometerInputReply handler that carries the measurements;
4. only then send the two RegisterIoTDeviceRequests, each addressed to the control protocol that owns that device.

Both requests are fired up front; their replies are demultiplexed by device type inside handleRegisterIoTDeviceReply(pt.unl.fct.di.tardis.babel.iot.api.replies.RegisterIoTDeviceReply, short).

Specified by:

init in class pt.unl.fct.di.novasys.babel.core.GenericProtocol

Throws:

pt.unl.fct.di.novasys.babel.exceptions.HandlerRegistrationException

IOException

handleDemoTimer

public void handleDemoTimer(DemoTimer t,
 long time)

Periodic timer handler: polls the accelerometer for one reading mode per tick, round-robin. This is the request half of the request/reply polling flow — each GetAccelerometerDataRequest is answered asynchronously by handleAccelerometerInputReply(pt.unl.fct.di.tardis.babel.iot.controlprotocols.replies.AccelerometerInputReply, short).

handleRegisterIoTDeviceReply

public void handleRegisterIoTDeviceReply(pt.unl.fct.di.tardis.babel.iot.api.replies.RegisterIoTDeviceReply rep,
 short protocolId)

Reply handler for RegisterIoTDeviceRequest: receives the DeviceHandle for whichever device the control protocol just bound.

Because both the LCD and the accelerometer share this one reply id, the handler demultiplexes on RegisterIoTDeviceReply.getDeviceType() and stashes each handle in the matching field. The polling timer is only armed once the accelerometer (the device the timer reads) is ready.

handleAccelerometerInputReply

public void handleAccelerometerInputReply(pt.unl.fct.di.tardis.babel.iot.controlprotocols.replies.AccelerometerInputReply rep,
 short protocolId)

Reply handler that completes the polling flow: each GetAccelerometerDataRequest sent in handleDemoTimer(pt.unl.fct.di.tardis.babel.iot.demos.events.DemoTimer, long) comes back here as an AccelerometerInputReply. The reply's measurement type matches the requested mode, so we cast accordingly, log it, and forward a rendered string to the LCD with a ShowTextRequest. This is the read-then-display half of the input/output pairing.

execute

public void execute()
             throws Exception

Application bootstrap (the entry point Main calls for the Accel demo). Standard Babel start-up sequence:

1. grab the Babel singleton and load configuration;
2. instantiate the two control protocols this demo depends on — the I²C output protocol (LCD) and the I²C input protocol (accelerometer);
3. register all three protocols (the two controllers plus this demo) with Babel;
4. call init in dependency order — controllers before the demo, so they are ready to answer the demo's registration requests;
5. b.start() hands control to the Babel event loop.

Specified by:

execute in interface BabelDemo

Throws:

Exception