listner should be listener. Fix in all occurences, including file names.

Refactor where apps live, how they're named, how they're packaged.

The polling client is no longer needed as part of the sdk. Modify the javascript filter edge_app to use the unmodified java sdk.

This will require changing the PollingClient interface implementation in the listnr folder into a n IofogApiLIstener interface implementation.

It was misguided to place the protobuf defs in multiple package locations.

Package all protobuf defs in com.hashmapinc.tempus.edge.protos and update all edge app import statements to import from this package.

Given an iofog message containing tag and value, the opcClient should write the new value to the given tag space on the current opc connection.

The service should accept json objects from the iofog message stream, evaluate if the data passes a condition (work order bit is set), and send the data back to the iofog message stream if the condition passes.

Because the bit value may require some bit manipulation to evaluate, this service will not be implemented with the existing jsonFilter edge app. In the event that a suitable boolean operation can be configured for jsonFilter, then this task should be discarded in favor of reusing the existing functionality in the jsonFilter.

Move shared opc logic into the lib/jvm area and gut opc-client and opc-tag-filter so they use the shared opc logic in lib and only have app-specific logic.

This may be tricky.

See https://github.com/eclipse/milo/blob/41d594fae04538fb260186f0985e9ffd2115f472/opc-ua-stack/stack-core/src/main/java/org/eclipse/milo/opcua/stack/core/security/SecurityPolicy.java

It may be smart to split different security implementations into different cards.

The iofog java container sdk is currently only accessible by downloading a jar file from a github page and installing the JAR to a developer's local repository cache in .m2

This sucks. It would be dramatically better for these JARs to be accessible from maven central.

Find a way to get these jars into central. This likely involves contacting EdgeWorx and having them do it. Otherwise, get creative.

Lib will hold all reusable edge application code. It should have the following structure:

• lib/python
• lib/jvm
• lib/go

in another card, the edge applications will have to be refactored to contain only the necessary logic that is unique to that app.

Duplicate the existing java implementation of json filter for testing the python container sdk extension and for providing a python demo app.

go from com.hashmapinc.tempus to com.hashmapinc.tempus.edge

If the connection is disconnected for some reason, the opc-client should handle it.

The minimum implementation should send a tag list to the iofog message stream.

Additional features (on other cards) should implement regex matching from iofog configs to get matching tags from an opc instance and send the passing tags to the opc client through iofog messaging.

This obviously will only build JVM edge apps.

Maybe we should do something better? Automatic build / test server?

This will allow tempus to send configs through MQTT to the track. These configs will be treated the same as iofogConfigs. Eventually, most or all configs will make their way to the track through mqtt.

given a configuration map of regexPattern -> Device Name, create a device name for each passing tag in the filtered tag list. This list of (tag, device name)'s should be sent to the iofog message queue.

Also, make sure that the opcClient is modified at least enough to not fail when getting this new list format. Full use of the list will be implemented in the opcClient in another card.

The current README is a great tutorial for using iofog, but it is probably more appropriate to make a simpler / generally instructive README at the root of the project and move the current readme to another location in docs. The new README should still link to the current README.

Randy didn't think his naming through until after he started working on the service. Please clean up after him.

Input: Byte array that contains a json string
Output: Byte array -> [Protocol Byte, Message Type Bytes, protobuf containing the input]

As part of this, also create the JSON protobuf definition.

Don't add system tags to the recursion queue in OpcController.

Implement the functionality for opcClient to send a "getTagList" request message to iofog messaging that will be read and handled by the tagFilter service which will then send the latest tag list to iofog messaging for opcClient to consume.

The goal with this feature is to make opcClient slightly more stateless so that if it ever goes down and comes up unexpectedly, it can get the latest tag list without waiting for the tagFilter service to decide to send the latest list.

This card will require updating both the opcClient and the tagFilter services.

The test message generator project has huge potential to help developers test their edge apps locally.

Modify the project (https://github.com/iotracks/test-message-generator) to make it easy to import the test server as a test dependency in JVM projects.

The service should support acceptance of IoMessage types and send them to connected applications. It should also support acceptance of config JSON objects and send those configs to local running edge applications.

Those two requirements should be sufficient for an initial usage.

These should be standardized. Come up with a reasonable standardization and document it in the Applications README.

The protobuf definitions for the configs of each application should be consolidated into a single location. This could be in the applications directory or maybe in a separate config directory.

Each protobuf should be packaged to com.hashmapinc.tempus.edge.<application_name>.proto.config

While you're at it, also consolidate all MESSAGE TYPE constants into a single location. This will need to be done for Go, Python, and JVM applications. Make sure to use consistent naming and package these to com.hashmapinc.tempus.edge.message_types

Add readme's to:

• opc-client
• mqtt-client
• json-filter
• client-webapp
• timeseries-generator

All future applications shall have a README at creation time, or pull requests will be denied back into the DEV branch.

Make sure the package is com.hashmapinc.tempus.edge not com.hasmap.tempus.

use the iofog configuration to connect to an opc service and the tag list from an iofog message to subscribe to the tags in the list.

When changes are sent from the opc subscription, format the data in a tempus-friendly way and send the data to the iofog message stream.

This requires updating the code to respond to incoming messages from the track-manager. The element will need to be able to read track configs in protobuf format, extract the necessary components, and update local state.

Add a tag root field to the opcConfig protobuf def.

Add functionality to opc-tag-filter to use the provided tag root. If the root is not defined, default to the Identifiers.RootFolder NodeId currently in use.

Currently, the configuration from iofog for opcClient contains opc connection details (security policy and endpoint). This same configuration is separately sent to the tagFilter to be able to access an opc server.

This means the same configuration exists in 2 places. That doesn't feel right.

Would it be better to consolidate the configs to only one service? The config could be shared between the services by implementing a call/response for opcConfigs on the iofog message stream.

Until a decision is made on this, configs will be specified and delivered separately to each service.

Given an API endpoint, the track-manager should request an identification for the track from an external DB. This identification may then be used to request track-specific features in the future.

Document these in the applications README.

The format should include a description of messagetypes and messagesubtypes. These are int values that represent a type and subtype of messages. This allows for more efficient int comparisons at the edge for routing messages to the appropriate handlers.

Given a whitelist and blacklist (blacklist having highest priority) of regex patterns, query an opc service (hard coded is ok for this task) to get a list of tags.

Send the tags that match the whitelist regex AND do not match the blacklist to the iofog message stream.

The track manager service should accept configurations from ioFog Authoring and should make reflect these configurations in a sqlite db on a shared volume accessible by the whole track.

When new configs are accepted, track-manager will send a newConfig iofog message for dependent elements to respond to on their own.

This folder should be clean (no random test files) and ideally packaged as a hashmapinc python application.