Use Case: IoT Data Collection
Setup a MAE spoke on a Raspberry Pi or other SBC. Once setup, MAE's virtual file system can be configured to access files, sockets, pipes, etc on that spoke - or write a MAE component for that spoke. Once connected to MAE, all other MAE applications can access that data or simply store it in a connected database table.
You have a large number of distributed systems that collect data or perform operations that you would like to manage centrally. Data may be in a convenient form like a text/JSON/XML file or it may be only readable from a connected device in a proprietary format. You want to minimize the software you have to develop and push to each distributed system. Preferably, you only push software to the system once and all remaining application modifications happen on a more centrally located server.
MAE transparently supports software running on the central hub or one of many spokes (distributed systems); software running on one system seemlessly communicates with software on any of the other systems.
Further, MAE makes I/O resources available on one system seemlessly available on any of the other systems. It is not required, but you can organize those resources into a hierarchical virtual filesystem to make accessing them logical. Any node in that filesystem can be located on any MAE spoke.
By setting up a MAE spoke on each distributed system, software located more centrally can access all I/O resources across all those systems to collect data or connect to devices.
Does this solution look like a fit for your organization? Reach out to HanoverSoft at +1 (919) 270-6712 or info@hanoversoft.net to discuss.
Only a minimum of software is needed on a MAE spoke; you'll need the MAE commhub and iogw programs. See Spoke Run-Time Environment.
All MAE I/O resources are registered with MAE using tioreg, which allows you to register access to a file, directory, socket, (pseudo) tty, pipe to a program, udp service, tcp service, or serial device. Each resource is given a resource name; that name is its unique handle; an application uses the IOPort class open() method using that name. An example name could be "XyzData.xml"; no spaces are allowed; case sensitive.
The process of creating a virtual file system for MAE apps to access is a matter of registered resource naming. When resource names look like full filenames with paths, MAE automatically creates a virtual file system of them. Perhaps you have organized your data into two groups, red and blue; you can declare a resource (perhaps named ball) into one of the groups using the filename /red/ball. MAE allows you to query all resources in a particular directory, so querying /red would yield ball as one of the resources. Given a list of all resources in a particular directory, a MAE app can be aware about what to do with those resources.
If you need to develop a specific app for your specific MAE spokes, your MAE app does not need to know the spoke's hostname, address, or other communication particulars - only its channel name. Each MAE app communicates on its own unique channel. Your spoke-specific app will have its own channel, so other MAE software simply communicates with it via that channel. Note that channel communication is organized in a .mreg file, which genmae reads to generate interface files for the application and its API used by other applications.
You manage which spokes are allowed to connect to your root MAE hub via the commhub.ini configuration file. Create a [spokes] section with entries like this:
hostname=passcode
You manage which users are allowed to connect to your root MAE hub via the commhub.ini configuration file. Create a [users] section with entries like this:
username=ipaddresslist
where IPv4 addresses are separated by commas.