@devctrl/communicator

- Communicator builds list of device controls (control templates)
- Communicator syncs control list with messenger
- device controls are paired with application controls based on endpoint and device control name
- controls have default usertype, application panel controls may override this type

- device commands can be tied to multiple device controls

- Communicator receives a control update:
- communicator looks up command for control template
- device string is generated and sent

- Communicator receives a device string:
- device string is matched to command
- control templates are looked up for command
- command returns value for each control

- Control sync process:
- Communicator builds list of commands and a list of controls
- Controls are synced with server
- ncontrol requests list of server defined controls
- server controls are matched with ncontrol templates based on ctid
- "ctid" and _id are both key fields. _id is the mongo document id,
"ctid" is unique within the endpoint communicator instance and generated by the class definition
- ncontrol adds missing control templates and updates server control_templates which do not match class
definition
-

- CHanges from Devctrl-mysql:
- control_template table dropped, fields moved to control objects

- Control Updates:
- not stored in database
- value and source

--- TCPCommunicator/Endpoint status management ---

- Is endpoint enabled? (Endpoint.enabled)
- Is communicator connected to messenger? (Endpoint.communicatorConnected)
- In lieu of communicatorRunning, which is unknowable without communicator connection
- Is device reachable (ping)? (Endpoint.reachable)
- Is device connection established? (Endpoint.connectionEstablished)
- Can communicator log in to device? (Endpoint.loggedIn)
- Is device responsive? (Endpoint.responsive)
- Keep log of last communication, establish maximum time between communication