Ending Feed Inventory from Bin Sentry to Aeros LIVE
- Amanda Thomas
Introduction
Bin Sentry is an IoT Solution that reads Bin Inventory and availability and reports it to a central solution. This solution is exposed through an API. In Aeros LIVE, we record Feed Ending Inventories against flocks, which we use to determine how much feed was consumed from what was delivered. Are they on schedule? Is there more feed in the bin than we anticipate? These questions are answered now by manually checking bin volume and reporting these ending inventories in Aeros LIVE either through data entry or a data import. If we can reconcile the bins in Bin Sentry with Aeros LIVE we can call their API to get "Latest Readings" and turn them into ending feed records in Aeros LIVE.
Prerequisites
To Integrate Aeros LIVE Ending Feed with Bin Sentry Latest Readings, we will need:
Required:
Access to Aeros LIVE
Access to Aeros CONNECT
Recommended:
Access to Bin Sentry UI
Configuring Connect
Config Connect for LIVE Database
As a part of the initial setup, we'll need to add connection strings into the CONNECT_User.dbo.ConfigConnect table for LIVE. CONNECT will be writing to the LIVE_User database, but reading a stored procedure to check for available flocks that is in the LIVE_System database.
A LIVE_User database has an fkIntegrateSystem id of "1", and an fkIntegrateProduct id of "1", while a _User databases are "1" and "3".
Aeros PS: See Bin Sentry Integration to Aeros LIVE Ending Feed for scripts
Config Connect for Bin Sentry
Next, we'll need to add a connection string for Bin Sentry. An example insert statement is provided here:
This connection must have an fkIntegrateSystem id of "18", and an fkIntegrateProduct id of "29".
Aeros PS: See Bin Sentry Integration to Aeros LIVE Ending Feed for scripts
Configure Facility Integration
Power User → Tools → Configure Features
A user with admin or power user rights will need to enable the feature, It will be under the "Facility → Feed Ending Integration" node in the tree.
User Profiles
Settings → Security → User Profiles
For each user that can review these batches, we'll need to grant them security access. The security settings are under the same nodes as when we had enabled the feature.
Mapping Bins
Facility Integration → Feed Ending Inventory → Mappings
CONNECT will not process any bins that have not been mapped, so we'll need to do that first.
The mappings are made when we choose an option from the "Bin" lookup list for Aeros LIVE, and one from the "Bin" lookup list for Bin Sentry. When we make our selections, all of the read only fields on the screen are updated, so that we can see their organization structure without having to drill-down into the lookup once we have selected it. These columns are read-only.
As mentioned above, one way to skip importing a bin is to not add a mapping for it, another is to set the "Is Enabled" bit. If for any reason we have created a mapping for a bin, but we do not want to read it, we can uncheck this option and it will be skipped for multiple bins.
Some key fields on this screen:
Is Enabled: When unchecked, this bin will not be read from bin sentry when we create ending inventory batches.
Aeros Live Bin: A drop-down list of all bins in Aeros LIVE, with their organization hierarchy listed out
Bin Sentry Bin: A drop-down list of all bins in Aeros LIVE, with their organization hierarchy listed out
Bin & Organization ID: These are the unique identifiers that CONNECT will use to read the bin sentry API for bin volumes. if we ever need to work with Bin Sentry on a support issue, having these unique identifiers visible may come in handy.
The "Save" button must always be clicked after making changes. Changes will not be saved unless we do this!
The lookups for bin selections are made using a searchable lookup list, typing in entries at the top will search for those string values in any part of the strings in any column. This will come in handy when we are looking for a keyword or code that can be at any level of the organization structure, or if we do not know that a bin code is nested under other bins.
To that point, this screen supports aggregate bins. In Bin Sentry, bins can be nested under other bins to create aggregates- bins that will combine the totals of all bins at a group level but still allow users to drill down to the individual bins. When we map, we will map to the deepest nested, single bins, but regardless of what level they are at we should see them in this list.
LIVE bins use the same searchable lookup list. We can search for any value in any column and the list will filter accordingly.
There is no validation for how many times an LIVE bin can appear in the mappings, or a bin sentry bin for that matter. This is because one farm may be represented by several virtual farms in LIVE. The only condition of this relationship is that despite how many times a bin sentry bin is on this form we will only read it once. We'll check each mapping for an active flock and apply that reading to just one flock. We'll discuss this in more detail below.
The grid will allow us to multi select rows, and manage many rows from context menu options. Those options are:
Enable Selected: Checks "Is Enabled" for all selected rows.
Disable Selected: Unchecks "Is Enabled for all selected rows.
Clear Selected: Erases all LIVE mappings for the selected rows.
Edit Selected: Edits the values for multiple rows. We'll discuss this in detail next.
Delete Selected: Deletes all selected rows. These values will be restored during the next synchronization.
Changes, including deletions, will not take effect until the form is saved.
Rows can be multi selected in order with a shift+click, or out of order with a control+click.
There may be hundreds of bins to map, across hundreds of farms, and many organizations, so with that in mind, to speed up mapping, we added a dialog that will allow us to edit multiple mapping rows at once.
Let's say we have four virtual farms in LIVE that need to be mapped to one actual bin. We can add those four rows to the mapper and select those LIVE farms, then shift-click them, and chose the one Bin Sentry Bin, then click "Accept Changes". That bin sentry bin will be written to all four rows, and we only needed to look it up once!
Creating Ending Feed Batches
Facility Integration→ Feed Ending Inventory → Create New
When we are ready to manually create a batch We'll click "Create New". Clicking here will load a dialog window that will load information about the last batch that we processed.
Like other CONNECT batch creation screens, there is a field that let's us override the date we are processing this batch for. However, due to the nature of the Bin Sentry API, there is no way to back-date readings- it only provides the last available reading. This means, that if we want to take daily readings, we will run or schedule this every day and regardless of the times we pass it, we will always get back the last reading that it took. We'll have to keep this in mind when we run or schedule batches.
When we are ready to import bin readings, we'll click "Import / Create Batch".
This will bring us to our batch screen, where we can see all of the readings we are staging here.
We had four bins staged and mapped, all enabled, so we can see that CONNECT pulled the last readings for all four bins. Some bins are mapped several times, to virtual farms created in LIVE. These bins are still only read once. The records will have the following values to look out for:
idReferenceIn: This is the unique identifier for the bin sentry bin. The readings themselves do not have unique ids, so we save the bin.
Organization Code: This is the hierarchy of organizations. that the bin belongs to.
fkFeedEndingInventoryMap: If you recall, we use the list of bins that we mapped to pull last readings from BinSentry. This is the id of the map record that we used, for reference.
Bin Code: The BinSentry bin name.
Ending UOM: This is set to kilograms. We did not see a configuration of value for this in the api, so we assumed by bin capacities and readings that this value was in kg.
Ending Quantity: The ending reading from bin sentry.
Ending Quantity in Grams: LIVE stores feed deliveries and ending inventories in grams. This is the value that will be saved to LIVE. In the future, if we need to make any adjustments to ending values we can do it against this field, so as not to alter the value that was initially reported to us by BinSentry.
Ending Date: This is the date of the last reading. It will become the ending inventory date on the ending feed record.
Before we send any records to LIVE, we can perform a "Test Commit". This is handy while we are implementing or troubleshooting, because we can catch bad mappings before sending data down.
This will perform all validations against the database and find the matching identifiers for the flock and bin that we will use to create the ending feed record.
After clicking "Test Commit" for this batch, we can see that two of the four records are missing bin ids. However, it found active flocks. This could be because our mapping is incorrect, or the bin exists in Bin Sentry but has not been entered into LIVE.
Test Commit and Commit errors will be visible on the "Commit Results" Tab.
Checking the "Commit Results" tab shows us our messages. As we had identified, the bins are invalid.
We'll close the form and investigate.
When we validate, the software is looking for one flock to assign a bin reading to. Here are some possible validation outcomes:
If one flock is found (1): That flock is assigned the bin reading. It will become an ending feed inventory on that flock.
If no flocks are found (2): a warning message is displayed, and the record is unchecked, so it will not be committed again. This happens because it is likely that a bin reading may occur while there is no active flock in the house. if we believe this message is in error, however, we can resolve the issue with the flock in LIVE, check the record in the batch, and commit it again.
If more than one flock is found (3), either on the same LIVE farm or across multiple mappings, an error will be thrown. We can only record this ending inventory for one flock, so this will have to be resolved in Aeros LIVE.
Committing Ending Feed Batches
Facility Integration → Feed Ending Inventory → View Existing
To view batches that have already been created, we can click the "View Existing" tab. This will bring up a search form that will help us look for batches that have been created.
Once we find the batch we need to review, we can double-click it or select it and click "Load" at the bottom.
The batch is loaded. This is the batch from the previous example, that had invalid bins. Updating a missing bin code resolved one issue, while the other is in fact a missing bin in LIVE. We'll add that later, but for now, we can commit the rest of the records.
Clicking the "Commit" button will send the records to LIVE. When they are committed, a few fields will be updated:
idReferenceOut: This is the unique key for the ending feed record that was created in the database.
Commit Date: This is the date the records were committed to LIVE.
Viewing Ending Inventory in Aeros LIVE
We can view these ending feed records in LIVE. The quickest way to look them up is to find the GroupID column in the batch. This is the unique id of the flock that received the ending feed, and whose consumption will be impacted by it.
Aeros LIVE → Live Inventory Options → Ending Feed
From the flock lookup form, we can enter the id from the CONNECT stage screen here, this will filter our flock list to the flock in question. If we can't see the column we can add it via the "Column Chooser" grid context option.
We filter the grid for that flock, then open it's "Ending Feed" screen. We can see the ending inventory and the bin it has been attributed to.
In LIVE, ending feed times can only be expressed in hours, so the precise time of the reading in CONNECT has been truncated to the hour, and converted from UTC time into the local time of the web server.
Here's another example. We enter the next flock in and can confirm it's ending feed was imported.
How CONNECT Reconciles Aeros LIVE Flocks
CONNECT will handle messages for missing or multiple flocks, but what happens if it assigns ending records to the "wrong" flock- a flock that we did not expect the ending inventory to be reported for?
To assign flocks, CONNECT calls a stored procedure in LIVE called "spGetGroupDateSpan" This procedure returns the earliest placement date and the latest depopulation date for a flock/house combination.
The placement date will be the earliest placement or estimate record date, and the out date will be the latest estimated or actual sale, depopulation or transfer. If there are no out records it will use the current date and time, since this procedure is never used to assign records for projected flock dates. Each in and out record will have a code that tells us what record type it is.
If we are finding that ending inventory records are bein incorrectly attributed to a flock, we may need to investigate it's in and out dates and then correct them on the flock to guarantee accuracy of their assignments.
Scheduling Bin Integration Tasks
Settings → Other → Schedule Tasks
We'll add records to the schedule list if we want to schedule these batches
"FeedEndingInventoryMap": Create a schedule item of this type to automatically import and update bins in the mapper.
"FeedEndingInventoryCreate": Create a schedule item of this type to automatically create a batch of bin readings.
"FeedEndingInventoryCommit": Create a schedule item of this type to automatically send all uncommitted bin reading batches to Aeros LIVE as Ending Feed records.
