Deadly and not a function node to be seen!
@Farmer-Ed, @mstenta
Happy for feedback on this one if there’s steps I can take at an early stage to have the best outcome within Farmier. (Sorry for the long post…)
Since I already have a pig management application, I found little use for the animal module in FarmOS.
Now, I know better…
I don’t fancy adding my sows into the system or anything like that.
But some times it’s useful to have a diary of more general events or discrepancies.
So, in my calendar, I have all important events like mating, farrowing, weaning etc.
There are 3 groups of sows and 7 weeks between each groups farrowings.
Each event repeats itself every 22. weeks.
The most recent events are displayed as a list in my Node-Red dashbard.
(Activities, and days ago/ahead)
If a weaning event is present, I can click on the event, and a new animal asset is created, called “Weaned” + the weaing event date. The animal is also marked with the monitor flag.
I will usually have only one batch of weaners active at a time.
Everything that happens from weaning to sale, should be hooked on this animal. Except for the ordinary stuff I put into the other app.
I intend to put temperature and humidity readings in this animal too.
Not worked this out yet, maybe just one sensor asset, and create a log of averages and max/min.
Maybe also add warning-logs if readings are outside normal.
Ideally a diagram of the sensor readings during this period would be visible on the animal asset.
I also plan on tracking weight gain for a couple of pens pr batch too.
Weigh the pens one day every week.
This diagram should also be visible within the animal asset.
When the pigs are sold, I will archive the asset. That way it should be easy to select the right animal asset when adding manual logs. For example in the FieldKit.
I would also have to work out similar setup to follow each sow group/batch.
I guess the graphs would depends on the iFrame module being available in Farmier.
Also would have to do some Node-Red magic to periodize the sensor data.
One sensor-asset pr animal asset sounds wrong. Correct?
Is there some other things going on, that may be useful in this case?
For a start, it will work without graphics.
Is it physically one sensor per animal? or one per pen/area?
If it is one per pen/area then perhaps we need some new location assets to suit us Livestock farmers and associate environmental sensors with the area and then livestock with the area also?
perhaps if you are not doing horticulture, you could use beds in place of pens?
Although on a side note I was considering using some BLE tags to monitor Cows on a collar and calves attached to jackets. https://ruuvi.com/ruuvitag/?gclid=CjwKCAjw2OiaBhBSEiwAh2ZSP3EXKI_Ug_MwxsyivWveRqbH5SnRNuiZciY48z6hKAGp7nT413AQyhoCjeMQAvD_BwE maybe with some custom firmware using a network of ESP32’s as gateways.
I think graphs similar to V1 are part of @paul121’s plan too, but I hope to get back to the i-frames module shortly too, just a busy week or 2 on farm to sort out first.
If your other software has an API or export feature, that might not be a massive task.
I think you should just use observation logs for animal temperature readings - not sensors or data streams. Those are more intended for streaming data, not one-off observations from time to time (unless you are planning on leaving a probe on/in the animal with a wifi connection - I’m joking I do not condone that!).
As for weight gain and graphs… you might be interested in this: farmOS Animal Weight | Drupal.org
I’m sure @pat will put us straight, but I think it’s environmental readings, as for a permanent probe in an animal …it’s actually a thing.
Haha…
Well, I made my post to short then…
It’s actually the room’s temerature and humidity I want to measure.
Later on I may compare these graphs against average daily growth and feed consumption.
I have the database on my farm computer. It’s local and offline.
I have access to it tho… So my bet is that I may be able to use it, but maybe not so practical.
It’s a future task…
Yep. I’ve seen those briefly. Hope we see it in v2 too someday.
Oh haha! That makes more sense!
Well it sounds like just one sensor then, located somewhere, and the animals are also (sometimes? all of the time?) located there too. I don’t think you would relate the sensor directly to the animals, other than that they are in the same location, and because you know that you can then infer that they are related in whatever analysis you want to do later.
One thing I did want to mention though: data streams are associated with sensor assets, but they can also reference another asset as the thing(s) they are measuring. So you could have a sensor asset with a data stream that references a particular plant.
Not recommending that for this case, just wanted to mention it.
One sensor in a room. 7 batches of (around 400) pigs each during one year. One batch at a time.
I create one animal asset pr batch.
One sensor with 2 streams.
If the sensor asset is set as a location, I can move the animal asset in and out of the senor asset. Or, if the animal asset is a location, I can move the sensor in and out.
That way both asset holds data for the time period.
Or I can reference them, as you mention.
@paul121
So, if we generalize (with a future module in mind), an asset could display a graph of sensor data for the period the sensor was associated with the asset.
Pretty cool, If I may say so… I bet there are different scenarios where a sensor is moved to monitor different assets. It may wary if it’s the sensor or the monitored asset being moved tho.
Well, if that could work in general terms, I would say it’s best for me to move my room sensor into the animal asset.
I still don’t think the sensor needs to be directly related to the animals. It is indirectly related simply by virtue of being located in the same place as them.
Simple example from the ground up:
- Create a Structure asset named “Barn”.
- Create a Sensor asset named “Raspberry Pi”, with two data streams.
- “Move” the Sensor asset so it is located in the “Barn”.
- Create an Animal asset named “Piggy”.
- Move the Animal asset so it is located in the "Barn.
Now you have 2 assets located in the “Barn”: 1 sensor (with two data streams), and 1 animal.
You can infer that the sensor’s data is relevant to the animals because they are in the same location for the same period of time.
The reason I think it’s good to model it this way is it also accounts for unforeseen changes. What if you have 10 pigs, all directly related to the sensor somehow… but then 2 of them get sick, and you have to move them to another place. Do you then also have to disconnect their link from the sensor? There is no timestamp associated with WHEN you disconnected that relationship. But there IS a timestamp of when you MOVED them (from the movement log).
Maybe that helps to conceptualize? Or maybe it doesn’t …ha!
Ah… that makes sense.
Nah… There will be one batch of pigs in the barn. All the piggies goes into one single animal asset., and the batch size will vary each time. Some may be taken out of the barn. That does not matter. (Unless its the big bad wolf out on halloween )
What matters in this case, is the sensor data for the group of pigs that gets to be sold in the end.
Treatments, kills, daily growth, feed consumtion etc is beeing logged in another app.
Basically I need to check how the barn climate was during that specific period. (If a batch went bad, or very good) And preferably reference the animal asset to see this info.
Your example makes sense. It reflects more of what actually happens.
Trying put the animal in correct location upon creation, but it will not happen.
The json seems correct, and browsing the object in node-red also seems correct.
But is this even possible?
And if so, will I miss the movement log?
Possibly better to POST a movement log after creation.
@pat Location is set via “movement logs” that reference the asset. See Location | farmOS
The location
field in the API is a calculated field, so it is read-only.
So to update the location you need to create a new log in addition to the asset.
Sometimes I get stuff on email that need to be kept for a future revision of some kind.
If the mail itself is the only “document” it may not be so easy to find when the revisor ask for it.
So I came up with this idea:
The flow checks for unread mails in my Inbox\FarmOS folder. If so, it creates a log with the mail topic as the log’s name, and the mail body as the log’s note.
I also put an “Email” category to it, so it’s easy to verify them later.
I set up a mail alias and when I forward a mail to the alias, the mail is placed in the FarmOS folder.
When the flow is executed, the email node changes the mail read status.
Not too half-bad if I may say so…
Edit: Added the mail timestamp as timestamp for the log for better filtering.
[
{
"id": "9d8a923241677a34",
"type": "e-mail in",
"z": "1ca30f9571004237",
"name": "",
"protocol": "IMAP",
"server": "imap.fastmail.com",
"useSSL": true,
"autotls": "never",
"port": "993",
"box": "FarmOS",
"disposition": "Read",
"criteria": "UNSEEN",
"repeat": "3600",
"fetch": "auto",
"inputs": 0,
"x": 190,
"y": 1080,
"wires": [
[
"e0938f721fea4f15"
]
]
},
{
"id": "e0938f721fea4f15",
"type": "function",
"z": "1ca30f9571004237",
"name": "function 28",
"func": "\nvar maildate = Math.floor(new Date(msg.date).getTime() / 1000);\nvar mail=\n{\n \"data\": {\n \"type\": 'log--observation',\n \"attributes\": {\n \"name\": \"Epost - \" + msg.topic,\n \"status\": \"done\",\n \"notes\": \"\" + msg.payload,\n \"timestamp\": + maildate\n },\n \"relationships\": {\n \"category\": {\n \"data\": [\n {\n \"type\": \"taxonomy_term--log_category\",\n \"id\": \"dbb44cda-addb-4c5e-b41d-237691a3a71e\" //Epost-katoegori\n }\n ]\n }\n }\n }\n}\nmsg.payload = mail;\nreturn msg;",
"outputs": 1,
"noerr": 0,
"initialize": "",
"finalize": "",
"libs": [],
"x": 330,
"y": 1080,
"wires": [
[
"2894caf76e2466f5"
]
]
},
{
"id": "2894caf76e2466f5",
"type": "sf:949541c9b70110d5",
"z": "1ca30f9571004237",
"name": "",
"API": "log/observation",
"Method": "POST",
"x": 510,
"y": 1080,
"wires": [
[
"f8f6784bbb8f464c"
]
]
},
{
"id": "f8f6784bbb8f464c",
"type": "debug",
"z": "1ca30f9571004237",
"name": "debug 96",
"active": false,
"tosidebar": true,
"console": false,
"tostatus": false,
"complete": "true",
"targetType": "full",
"statusVal": "",
"statusType": "auto",
"x": 660,
"y": 1080,
"wires": []
}
]
Thinking about QR-codes today.
Some places around farm theres some stuff that needs documenting. A lot of this is boring stuff, just to keep the revisors happy.
My email → log flow in Node-Red could be used for this purpose.
If I let the flow filter for email subject, I can have different logs created.
Scan the code, and tap send. Actually quite easy.
And others on the farm can use them as well.
@Farmer-Ed, do you think of any alternatives to mail?
One alternative is to trigger log creation by a http endpoint.
Then the QR-code would take the user to a webpage. Once the page is accessed, the log creation flow is triggered.
The webpage can in turn, inform the user about what has happened.
That’s great.
But if the browser tab stay open, and if refreshed accidentally a new log will be created. Not so cool.
But maybe the best alternative so far.
I figured F-Droid should have an app for triggering url’s.
And, yes of course it had… Intended for door opening and such, but it triggered my node as well. It even briefly viewed the text in my template node once it was triggered.
I think this can work even better than qr-codes.
I can scan a qr-code with the app, and it adds a new menu item automatically.
Busy morning @pat?
perhaps this is no longer relevant, but you could build in logic to prevent duplicates by storing recent posts to farmOS and comparing.
There was some discussion with @Symbioquine on QR codes recently, don’t think it was here, maybe in chat and/or DEV call. There is a QR reader in Asset Link.
Hmm. Thats a good idea.