Node-RED farmOS library

I’m starting to hack together a farmOS library for node-red! Not sure what all this might evolve into, but I think it would be great to create some “farmOS Auth” nodes to simplify connecting to a farmOS server, and create some nodes to read/create logs, assets, areas, and post to sensors. I think we could create a configuration node, too, that could hold farmOS credentials. I wanted to start a thread to get some ideas from others.

I’ve hacked together some flows that support Drupal Auth (cookie + csrf token) and support for farmOS OAuth which is in development. I added a couple dashboard elements that pull some basic info from the API. You should be able to import the JSON from my gist (you can click on these images to expand)

The next steps to create some custom nodes might be pretty straightforward. We could probably start a github repo for that.

2 Likes

@dornawcox might be interested in this!

did you ever do more work on this?

I would be interested in collaborating if you are still using node red - found your flow here interesting although I cannot seem to make it work for my deployment, although its definitely pointing me in the right direction

3 Likes

No, I never got much further with this. The Authentication flows might not be totally correct anymore - especially for OAuth. But I don’t imagine they would be too far off. One thing to change would be the OAuth URL from server/oauth2/authorize to server/oauth/authorize.

I’d be interested in revisiting it for farmOS 2.x though!

At first I was thinking about using NodeRED as
a “gateway” for sensor data. There’s already support for MQTT and other protocols, its just a matter of wiring them up to the farmOS API. Creating logs & assets seemed like a good thing to support too, but I didn’t have any real use cases…

But this would actually be a neat way to aggregate sensor data & create logs if they meet certain conditions @mbillion! I think you could create all of your logic from the UI and export to code. Maybe you’re already thinking about that…

3 Likes

Im having a hard time getting posts to go through; For all the NodeMCU Esp8266 I have connected to sensors, but I also have them connected to things like lights and pumps. I can use the node red dashboard to set timing schedules turning on and off certain devices, or manually control the devices like irrigation pumps using the internet.

So I already have MQTT and a functional mesh network connecting everything and working. Now what I am trying to do is get the mqtt messages that would normally just show up on my dashboard to convert into POST’s into logs or farm inputs etc.

Having trouble getting node-red to speak to FarmOS though through the API. Can get the Drupal CSRF tokens, cannot get Oauth to authenticate. Then using CSRF I am still getting 404 when I am trying to post. saying the url’s do not exist

Right now just trying to do the base example on the most simple log post.

It would be super nice if I could - as far as a use case goes, have the dashboard of node-red hooked up to different sensors and control mechanisms, hitting a button starts a “log” etc.

This goes in line with my general inquests recently of tracking start and end times as well as consolidated sensor values. I think you could find a ton of ways to use this - once I get it connected I will share some of the ways I intend on using it

2 Likes

i just got it 403 to deny me instead of 404 doesnt exist so I am moving down the list

1 Like

Just saw this - the 2.0 milestone release of Node-Red: Release 2.0.0: Milestone Release · node-red/node-red · GitHub

2 Likes

I know this is an old thread, but the topic is most relevant and the forum probably doesn’t require yet another Node-Red thread started by Farmer-Ed.

I started a Node-Red Library of Nodes earlier this year.

Currently consists of an Authentication Node and an API Node.
I’ve also started working on a few new nodes, including an updated Authentication Node and a Callback Node to add new authorization flows including ‘authorization code’ and ‘client credentials’

I’m open to any suggestions on additional node types that should be included.
I guess some simple sensor nodes for data streams could be included too.
@pat maybe you have some ideas?

1 Like

I guess we can take a hint if a “Hide Node-Red” - filter is introduced in the forum… :innocent:

Awesome work you do with this. Makes it easier for the rest.
I’ve been on hold due to harvest and pre winter work. So little time for tinkering.

I’ll give it some thought.

At the moment I’m a bit torn between using Farmier or selfhosting. I see the benefits of hosting FarmOS myself. Selfhosting may peraps open up for a bigger node library.

2 Likes

No panic, I’ll be chipping away it can always be added to later.

I couldn’t be encouraging people away from Farmier, I’m sure farmOS could do with all available income streams :wink:

But if it’s just Node-Red you are tinkering with then self-hosted wouldn’t have much advantage, different story though if you wanted to get deeper into custom modules. Or the idea of a local self-hosted instance synchronized to a hosted instance was discussed briefly here: Internet-accessible Local-first farmOS hosting - #6 by walt
You could probably achieve it with Node-Red too.

Of course a self-hosted instance for trying new things out is very useful too.

2 Likes

I’m happy with Farmier indeed. But I see I’m missing out some cool modules. I have not studied everything in detail but I guess some of it would give ideas of more/different useage of Node Red. And I can still keep my subscription to support the project :slight_smile:

I intend to setup a testing environment to check things out.
Some syncing between would be useful. I’ll check that out too.

I read about the notification module from the changelog of the latest FarmOS release. It was quite interesting. Not sure if it will be available on Farmier directly?
Notifications is something i’ve been thinking of in Node-Red.

Also I don’t know exactly how the Field Kit will work for me when it’s ready. My node-red usage may depend a bit on that.

2 Likes

It will, but currently there is only Data-stream Notifications, although it does pave the way for more notification modules in the future. I have been working on a notifications module too (another work in progresss… maybe some day I’ll get one finished :upside_down_face:)

It currently can send notifications/events from farmOS to Node-Red, ntfy or Telegram, needs a bit of work to integrate with the new core notifications module though.

Asset Link from @Symbioquine could be worth a look at too, I did a bit of testing recently and I’m really impressed.

3 Likes

That is cool. Task notification is very useful.
Also useful to be able to snooze the notification directly. Dont know if that would be possible but still very useful. Along as marking a task done, right from the notification.

Cool that Node-Red can make use of the notification. That also makes it easier for different users to change the levels to trigger flows in Node-Red.

I wasn’t aware of ntfy. It looked nice. Been looking for something like that to use with Node-Red.
We use Signal. Is it hard work to add support for that? I’ve seen support for it in Node-Red.

Yep. I also noticed Asset Link. Very interesting.

2 Likes

I was thinking… A FarmOS filter node?
For example, get all pending logs assigned to worker 1.
It could use the same filters as FarmOS.

Then you could list the result on a dashboard with no coding.

Perhaps a update node based on the filter node too? Could be dangerous tho…

2 Likes

Yea, obviously you can already filter using the API node, but granted that requires more knowledge of the API in the first place. I’m not sure hard coding every conceivable filter into a drop down list would be very practical though. I wonder if it could be achieved with a simple json file with a few example filters that could be expanded upon on the fly and stored at any time?

I guess any node that can update existing records like the existing API node could be considered dangerous. Some understanding of the API will still be a requirement for anyone wanting to use Node-Red regardless of how little code this can be reduced to.

Edit:
hmmm…
Might not be straightforward to create dynamic options for configuring filtering in a node.
But maybe simpler to pass filter choices to a dashboard dropdown node???

1 Like

@pat I mocked up a “filter” node

Technically a node to populate dropdown lists from Json.

{
  "filters":[ 
    {"Flag monitor":"filter[flag]=monitor"}, 
    {"Flag monitor & Female":"filter[flag]=monitor&filter[sex]=F"} 
  ]
}

image

Also modified the API node to accept the selection from a drop down node.

Could possibly expand it for API endpoint selection too.

1 Like

This flow contains mockups of some potential new nodes: Node-Red-4-farmOS/farmOS_New_Oauth2_GET.json at WIP · Farmer-Eds-Shed/Node-Red-4-farmOS · GitHub
2 new nodes for Authentication, farmOS Callback node handles Endpoint for Redirect URI with Authorization Code Grant.
image

farmOS GET new advanced version of the API Node, currently only GET but accepts endpoints and filters directly from msg.payload or a global/flow variable or defined in Node properties. Can also be connected before a Dropdown UI to populate all farmOS API endpoints or directly after to receive required endpoint and/or filter.


2 additional Nodes that are not particularly farmOS nodes but make using Dropdown Lists in the Dashboard UI Simpler.
Load Selection Loads UI Dropdown Nodes from a Json File
Save Selection Saves UI Dropdown Selection to a definable global or flow Variable.

example json file for Load Selection:

{
  "asset_filters":[ 
    {"No Filter":""},
    {"Flag monitor":"filter[flag]=monitor"}, 
    {"Flag monitor & Female":"filter[flag]=monitor&filter[sex]=F"},
	{"Active":"filter[status]=active"}
  ],
  "asset_enpoints":[ 
    {"asset--animals":"asset--animal"},
    {"asset--land":"asset--land"}, 
    {"asset--equipment":"asset--equipment"}
  ]
}

Or maybe This would make more sense to store a list of filters specific to the different API endpoints?

{
  "asset--animals":[ 
    {"No Filter":""},
    {"Flag monitor":"filter[flag]=monitor"}, 
    {"Flag monitor & Female":"filter[flag]=monitor&filter[sex]=F"},
	{"Active":"filter[status]=active"}
  ],
  "asset--land":[ 
    {"Active":"filter[status]=active"},
	{"No Filter":""}
  ],
  "log--activity":[ 
    {"Done":"filter[status]=done"},
	{"Pending":"filter[status]=pending"},
	{"No Filter":""}
  ]
}

This is all fairly rough and will probably need some further debugging and documenting, but if anyone wants to give it a go, feel free.

2 Likes

Nice. I’ll have a look at it soon. :+1:

1 Like

Oauth2v2 looks easy to use.
Could you elaborate around these fields, and how I should use then with Farmier:
Callback node: Dashboard, Endpoint
farmOS Oauth2V2 node: Redirect

1 Like

Yes of course, still a work in progress so documentation is lacking.
You don’t need to use all fields only those the grant method requires, hopefully this can be simplified a bit before I’m finished.

You need to select a grant type and scope from the dropdown menus for all grant methods
And also need to enter your farmOS URL (without any trailing slashes) and Client_id.

Authorization Code:

Node-Red farmOS Oauth2V2:

Requires a Redirect URL, this is the URL where the code will be sent by farmOS which will be a Node-Red endpoint created by the Callback Node. Authorization Code is the only grant type which requires a redirect.

Node-Red farmOS Callback

Creates an Endpoint for Redirect URL relative to your Node-Red address (farmos/callback will be http://Node-Red-Address:1880/farmos/callback)
Dashboard can be any address, it’s the address you’d like to be redirected to when the process is complete, most likely a Node-Red dashboard tab.

farmOS consumer:

Requires Client_id and Redirect URL (Your Node-Red endpoint) other credentials are entered on a redirected web page.
Returns and saves to global context an access token and refresh token

Client Credentials:

This is the simplest login type and probably going to be the recommended for Node-Red or any home brewed apps.

Node-Red farmOS Oauth2V2:

Just requires Client_id and Secret

farmOS consumer:

Requires Secret to be set and also User. If more than one user is required for this method then a separate client must be created per user.
Only returns an access token, a refresh token is not necessary as reauthentication is trivial.

Password grant:

Node-Red farmOS Oauth2V2:

Requires Client_id , Username and Password

farmOS consumer:

Default Settings:
Returns an access token and refresh token

Password grant has been marked as legacy in the Oath2 spec and may be removed in the future, so migrating away from its use is recommended.

This is still an early test and may be missing some features, for example I have not implemented a flow for the refresh token yet which will be important for Authorization Code grant, to save all the redirects on reauthentication.

2 Likes