Best practice for DEVICE_COMMUNICATING and DATA_INITIALIZED?

PsyenceFact

I've been writing a NetLinx module for the Mode ColourStyle lighting controller which communicates over IP. I've got to the stage where the networking code is reasonably robust and am looking at ways of communicating the module status to other (UI) modules.

SNAPI defines channels 251 (DEVICE_COMMUNICATING) as being on whilst "Communication is established with device", and channel 252 (DATA_INITIALIZED) as being on whilst "Module data is synchronized with device".

At the moment I have 251 being set on and off in the device online and offline events. However if the device is offline, sending a command will bring it online (assuming there are no network issues) meaning that channel 251 is not a good inidicator of "communication readiness". For channel 252, I just set it on when the DEFINE_START activities have finished and don't touch it again.

I'd be interested to hear how other people use these channels, or indeed other ways of communicating the module state.


Andy

DHawthorne

My thought has always been that the DEVICE_COMMUNICATING channel is not to be confused with "ready to communicate" or any other in-between state like the connection is pending, etc. It's on if you are talking, it's off if you are not. If your module re-establishes comms when a command is sent, it makes it less than useful, but it is an API, and has to cover many devices. Many, you have to explicitly get the comms going before attempting to send anything out.

DATA_INITIALIZED is a bit murkier, but again, I would hold to the stricter from and say, it's on when your data fields match the device state after coming online. If it's off, you know what you have isn't reliable yet and needs to be queried.

HARMAN_icraigie

For IP devices that do not maintain a connection I set DEVICE_COMMUNICATING on when first connected and maintain it on through subsequent IP connection cycles. I will turn off DEVICE_COMMUNICATING after a third unsuccessful connection attempt. I turn on DATA_INITIALIZED after the last response is received from a data query set that provides all the information required to implement all module feedback. A full data query is triggered from asserting DEVICE_COMMUNICATING. I conditional module functionality based on the states of both DEVICE_COMMUNICATING and DATA_INITIALIZED.

PsyenceFact

Thanks for your thoughts so far. Obviously, opinion is divided on the matter!

ericmedley

I think a bit more '30,000 ft.' approach to the concept is:

the Device_Communicating is meant to tell the calling program that the module is able to and is in some state of contact with the device being controlled. The Data_Init is meant to tell the calling program that the module can query for data or that the module will now potentially be sending asyncronous data to/from the device being controlled.

The difference being that in a continuous communications scenario, the Device_Is_Commonuicating might indicate that the module is in the process of getting things going. In the other scenario where the device forces shut down of a socket once it sends its data, it might be considered a pilot light of communications.


I do think the concept is a bit fuzzy in practice though.

PsyenceFact

Thanks for your input, Eric. I've only been doing this for a few months, and everything's been a bit haphazard so far. I'm keen to settle on a more coherent, robust and extensible NetLinx scheme that utilises best practice whenever possible (for some arbitary and shifting value of "best").

Andy