Maybe… if I was able to understand it form the start 
But catching up now. 
1 Like
Been working on a subrequest feature in farmOS.js to provide a slightly nicer interface from the Drupal API, if that’s of any use to you @pat. It’sstill buggy and unstable atm, so I wouldn’t use it anywhere mission critical yet, but all that should be resolved shortly.
It isn’t very well documented yet, on account of all that, but you can get the gist of it from the tests I think:
3 Likes
Tiny contribution to the toolbox…
I tend to setup notifications for saving stuff to farmOS in many flows, so finally made the step and boiled down a subflow. I even spiced it up with some documentation 
Just hook it up after the farmos-API node, and that’s it.
@Farmer-Ed, maybe we should melt it in with your subflows?
Would be a fine excuse for me to get more familiar with github.
1 Like
Oh very cool,
Have to admit I’ve been lacking in the documentation department to date. Definitely we can collaborate on this.
1 Like
One thing stands out to me on that subflow @pat, can you have more than one instance? Generally UI nodes don’t play nicely in subflows (unless of course they did something to fix it in V3, I know there was some talk about it in future releases).
Share it when you get a chance and I’ll have a look.
1 Like
Ah Ok that particular UI node (notification node) actually works like that in a subflow as it doesn’t require a group or tab to be specified in its config.
1 Like
It should just pop up right where you need it to…
Possible to display it only on the active browser window, or on all (if dashboard is used on several units)
1 Like
Exactly, most other UI nodes require a grid position to live in making them impossible to create multiple instances if included in a subflow.
1 Like
I’ve been playing with quantities.
I get it working, but it’s a bit troublesome.
A quantity subflow could perhaps be helpful.
Not quite sure how it should work yet. 
1 Like
Well…
It starts with the idea, so we can work from there 
1 Like
Maybe just a simple hardcoded node for the relevant quantities are ok.
A “kilo-node” with payload input of kilos and a label.
Not so easy to reuse on other farmOS instances tho. But once setup it would be effective.
A “quantity helper node” to present the relevant ID’s could make it easier to setup nodes like the “kilo-node”
A node that works everywhere out of the box would be slower. But could be useful.
Think I’ll start with the first alternative and see where it goes…
I generally just GET all unit terms, and store them as a context variable.
[
{
"id": "c583a4ed99fa4160",
"type": "sf:949541c9b70110d5",
"z": "c884171d9a258ae0",
"name": "Get Unit Terms",
"API": "taxonomy_term/unit",
"Method": "GET",
"credentials": {},
"x": 640,
"y": 180,
"wires": [
[
"638c3d5c2a2d259a"
]
]
},
{
"id": "638c3d5c2a2d259a",
"type": "function",
"z": "c884171d9a258ae0",
"name": "Store Unit terms",
"func": "var array = flow.get('unit_terms') || [];\nvar name;\nvar id;\n\nmsg.payload.data.forEach(data => {\nname = data.attributes.name;\nid = data.id;\narray.push({id:id,name:name});\n})\n\nflow.set(\"unit_terms\", array);\n\nreturn msg;",
"outputs": 1,
"noerr": 0,
"initialize": "",
"finalize": "",
"libs": [],
"x": 840,
"y": 180,
"wires": [
[]
]
}
]
For creating a new quantity, you could possibly make it slightly more efficient by generating the UUID in node-red rather than waiting for the response, would also be more useful for making flows that can run offline.
1 Like
Smart
My take on SubRequests:
Can be fed an array of requests in the form:
var req1 = {
"action": "create",
"body": {
"data": {
"type": "quantity--test",
"id": UUIDph,
"attributes": {
"value": {
"numerator": msg.payload.pH,
"denominator": 1,
"decimal": msg.payload.pH
},
"label": "pH"
}
}
}
}
msg.req.push(req1)
Code from Subrequest node:
var token = global.get("token");
msg.payload = [];
var i = 1;
var req = msg.req;
var sub;
req.forEach(data => {
let apiType = data.body.data.type;
let uri = apiType.replace(/--/g, "/");
if (data.waitFor === undefined){
sub = {
"requestId": "req-" + i,
"uri": "/api/" + uri,
"action": data.action,
"body": JSON.stringify(data.body),
"headers": {
"Accept": "application/vnd.api+json",
"Content-Type": "application/vnd.api+json",
"Authorization": "Bearer " + token
}
}
}
else {
sub = {
"requestId": "req-" + i,
"waitfor": data.waitFor,
"uri": "/api/" + uri,
"action": data.action,
"body": JSON.stringify(data.body),
"headers": {
"Accept": "application/vnd.api+json",
"Content-Type": "application/vnd.api+json",
"Authorization": "Bearer " + token
}
}
}
i++
msg.payload.push(sub);
})
msg.headers = {};
msg.headers['Authorization'] = "Bearer " + token;
msg.headers['Accept'] = "application/vnd.api+json";
msg.headers['content-type'] = 'application/vnd.api+json';
msg.url = global.get('farmOSurl').concat('/subrequests?_format=json')
msg.method = "POST";
return msg;
1 Like
Hey,
Hoping to maybe revive this thread. Trying to setup an access to the API for nodered and/or MQTT (saw that was also discussed in 2022).
It looks like @Farmer-Ed 's git repo may be missing some of the latest and greatest features developed here. I’d be happy to try and contribute.
3 Likes
I’ll be honest I’ve not looked at it in a while and I’ve not moved my own setup to V3 yet, but that is planned shortly.
As far as I know @pat has been working with V3 though so may be a little more up to speed on any issues.
I’m more than willing to collaborate on any of this, I’m busy on another project until mid May but was planning on getting back to this after.
2 Likes
Cool @piege86
V3 introduced an issue on GETting some users.
I use that for adding working hours for staff. Now I have to GET all users.
No big issue, but I have my vets as passive users, so no need to show them there.
Everything else seems to work fine.
2 Likes
Sounds great, is v3 accessible anywhere?
1 Like
Sorry we are talking about farmOS V3.
There “should” be no major differences in the API between V3 and V2 although @Pat may have encountered at least one.
The Oauth2 nodes should still work but…
If you are self hosting farmOS then there are a number of different Authentication methods that you may configure.
What Authentication method have you configured? and are you self hosted?
Have you tested the API with any other apps? Postman, Curl etc.
The Oath2v2 node supports:
- Password Authentication
- Client Credentials
- Authorization Code
The original Oauth2 Node Supports:
- Password Authentication
I’m not sure what farmOS V3 supports out of the box, Password Authentication has been depreciated from the Oauth2 specification but I know there was a decision to keep it in farmOS but it may need an additional module installed as it was not included in the latest Drupal Oauth2 module.
1 Like
Oh I see, I’m self-hosting Farmos v3.1.2, I’ve got the client credentials going using a Oauth2v2 and farmos Get and can see some basic stuff.
I was struggling at first, for some reason I needed to create a new client id rather than use the default farmos one.
My short term goal is to periodically poll the API for changes and publish any logs/asset creation/changes to MQTT as an event in my little UNS for further processing.
Working getting the Filter on JSON:API to filter dates correctly. Found out yesterday that on some dates it only works as timestamps.
2 Likes