Thank you - that answered my question and did a nice job of framing the DDS capabilities within OpenICE and the broader set of patterns of responses to data.

I'm in the thick of it now. Related OpenICE classes are InstanceModelListener<DeviceIdentity, DeviceIdentityDataReader>, EventLoop, DeviceIdentityInstanceModelImpl, and DeviceConnectivityInstanceModelImpl. TimeManager plays an important part, but is not part of the base OpenICE library, so I'm looking to understand how to create that capability in an application rather than a Device Adapter. I see there are some fundamentals I don't yet know about DDS Subscribers vs. DataReaders, which should clear things up a bit.

Thanks for the answer. As to expanding Time_t to contain a 64-bit number of seconds, now that I've thought about it a bit it's probably better to leave it as a range that will remain compatible with C++ and with DDS.

Now that I've read a bit of DeviceListModelImpl and related classes, I think I'm missing something fundamental about classes to support liveness detection via InstanceModelImpl. Right now, I've written my own timer that checks a local cache of HeartBeat data every ~3 seconds to synthesize liveness; from reading the OpenICE code, it sounds like there's a component I should be using instead to automatically detect "ALIVE".

Can you say anything about how to detect "ALIVE" state of a Device's HeartBeat from an application? I'm unclear on which classes that DeviceListModelImpl depends on are part of the base OpenICE library vs. parts that are intended only for Device Adapters, or parts that were written solely for the OpenICE Supervisor. For example, I see TimeManager isn't part of the library available to HelloICE, but DeviceConnectivityInstanceModel is.

Peeling the onion,
Brad

As a practical matter, I think detecting Connected state is sufficient for our needs: we want to know when a device is (roughly) ready to use vs. being asleep/off while the Device Adapter is on.

Thanks for the pointer to DeviceListModelImpl - I'll have a read. It's good to hear we're in the ballpark of the right way to detect what we want.

Thanks again,
Brad

After digging into detection of device on/off state a bit more, I think we still don't know how to properly infer/calculate whether a given Medical Device (not just its Device Adapter) is on or off. The Topics HeartBeat, DeviceIdentity, and DeviceConnectivity seem closely related to it, but not the whole answer. I've posted a question about it in another thread.

On a more practical note: HelloICE.java doesn't have the problem, because it doesn't Subscribe to the DeviceIdentity Topic. I think the right thing would be to write an app that detects what devices are on or off. ...but as I mentioned here, I'm not sure we really know how to do that yet.

P.S., and what is an MDSConnectivity data type used for? It seems related, yet when I wrote a listener for it, the Pulse Ox Simulator didn't seem to generate it.

Now we've really come to the basic question of How to infer/calculate whether a device is on or off.

Thanks,
Brad

FOUND THE PROBLEM. Reading through the mdpnp git repo, I find that when a (simulated at least) device is Constructed, it writes a blank DeviceIdentity followed by the filled in DeviceIdentity. Internal timing of DDS can cause one to arrive before the other sometimes.

The workaround is to ignore received DeviceIdentity objects whose .model field is blank (not null; length == 0).

The bug is that the AbstractSimulatedConnectedDevice constructor calls writeDeviceIdentity() before the subclass has a chance to fill in that DeviceIdentity. Then the subclass constructor, for example SimPulseOximeter(), eventually gets control, fills in the fields of the DeviceIdentity, then (appropriately) calls writeDeviceIdentity().

Naively, it looks like the fix would be to remove the call to writeDeviceIdentity() from the constructor for AbstractSimulatedConnectedDevice. That's assuming that all of its subclasses' constructors call writeDeviceIdentity once they've filled in the DeviceIdentity fields.

P.S, I'm using OpenICE library 0.6.3 (via Gradle), java version "1.8.0_45", Java(TM) SE Runtime Environment (build 1.8.0_45-b33, 64-bit Eclipse Mars on a 64-bit Windows 8 Pro system with Intel Core i5-4300U CPU @ 1.90GHz 2.49GHz and 4GB ram. So it's all 64bit x86.