I’m working on some new flows in Node-Red to analyze sensordata in the pig barn.
Goals:
Track several sensordata for the period of a pig batch (represented by an animal asset), and compare to other batches.
I also plan on sending sensordata/health records etc through AI for further analyzing, and saving the result to a log or directly on the asset. Sensordata are stored in an influx database.
Animal assets are created automatically and I have to somehow end the asset to make a complete batch period.
What is best practice to end the asset?
Just archive it? Then I have an archived date.
I remember there has been some talk about terminating assets too.
It adds the ability to mark any log as terminating referenced assets.
It uses a very similar approach to “movements”, where any log can be used to “terminate” the assets that it references. Thus, you have a true record (a log) of the event that ended the asset(s), along with all the other metadata that logs are capable of.
The pull request I linked above removes the status field from assets, and changes the archived field into a boolean. This is being proposed as a step towards disambiguating what it means for an asset to be “archived”, because there are many cases where “archived” DOES NOT mean “ended”. So we’re trying to make the definition of “archived” more explicitly “this asset is no longer relevant” so it won’t be shown in the UI by default. I think this will also encourage more conversation around developing and adopting better conventions for “terminating” assets too - and perhaps we’ll end up merging the Asset Termination logic into farmOS core in v5 (to be discussed).
Ok. Understood, and it makes sense.
Thanks for making it clear.
I’ll check out, and read up on the asset termination.
Today I was thinking about making the batch period into two phases.
So the asset’s phase one is from farrowing to weaning, and phase two from weaning to sale.
Maybe phase one could be from mating to farrowing too.
Perhaps it could be useful for other assets too.
Various activity logs could represent a phase change.
Any advise on best practice for that?
Would need to find these logs somehow.
But nothing is being worked on in that regard right now. Probably makes sense to just come up with your own convention for how to represent the phase changes, and use consistent log types/naming/categories so they are easy to filter.