| [20:36:25] | * JustTB has quit (Quit: Leaving.) |
| [03:29:49] | * JustTB has joined #farmos |
| [04:44:04] | * JustTB has quit (Ping timeout: 244 seconds) |
| [05:08:12] | * JustTB has joined #farmos |
| [11:16:23] | * mbconsultinguk[m has joined #farmos |
| [11:20:35] | <mbconsultinguk[m> | Hey folks, only just discovered farmos but it looks amazing. I run a rural IoT company so I'm particularly interested in being able to stream data from our platform into FarmOS, but for now I'm going to lurk here and on Github to learn more about how it all hangs together! |
| [11:54:12] | <mstenta[m]> | Hi mbconsultinguk ! Welcome! |
| [11:58:33] | <mbconsultinguk[m> | Thanks! :) |
| [11:58:51] | <mstenta[m]> | Have you seen this page? |
| [11:59:07] | <mstenta[m]> | https://farmos.org/guide/assets/sensors/ |
| [11:59:55] | <mstenta[m]> | farmOS provides a basic "Sensor" asset type out-of-the-box, which can accept data posted to it over HTTP |
| [12:00:11] | <mstenta[m]> | It's also possible to build more complex sensor integrations by writing your own module |
| [12:00:37] | <mstenta[m]> | (each sensor asset has a "type" - the type that farmOS provides for listening to HTTP data is called the "Listener" type) |
| [12:00:59] | <mstenta[m]> | it's pretty simple... but useful for a lot of basic streaming data |
| [12:01:15] | <mstenta[m]> | and if you need something more complex, you can study that module to figure out how to implement your own, potentially |
| [12:02:12] | <mbconsultinguk[m> | Oh, that's fantastic, thanks. We use LoRaWAN which has a range of about 10 - 15 miles depending on terrain etc, but the server that the sensors report the data to can easily send to an HTTP backend, or we can write something to pull the data direct from the stats backend/message queue to send it in. |
| [12:02:47] | <mstenta[m]> | Great! Yea donblair is working with Lora also - sending it to a gateway device that can post HTTP |
| [12:02:51] | <mbconsultinguk[m> | I'll take a look over the next couple of days and see what I need to do - this isn't top of our list to be honest, I just happened to find FarmOS and thought it would be something that would be quite cool to integrate with |
| [12:02:54] | <mstenta[m]> | He's also got a cool custom board called the Quahog that can do everything |
| [12:03:06] | <mstenta[m]> | http://edgecollective.io/quahog.html |
| [12:03:09] | <mbconsultinguk[m> | oooooh, sounds shiny! :D |
| [12:03:36] | <mstenta[m]> | Yea! Fun stuff! :-) |
| [12:05:56] | <mstenta[m]> | Whereabouts are you? US? |
| [12:06:21] | <mstenta[m]> | (I'm northeast US - and so is donblair ) |
| [12:20:36] | <paul121[m]> | (That Quahog looks neat.....) |
| [12:25:53] | <mbconsultinguk[m> | Nope, UK, but one of our customers is in the Koonwarra region of Australia, so we're not restricted to country |
| [12:59:18] | <jgaehring[m]> | ACTION sent a long message: < https://matrix.org/_matrix/media/v1/download/matrix.org/jIbmOIGBHKAqglnS... > |
| [13:05:49] | <paul121[m]> | jgaehring: great! |
| [14:28:30] | <jgaehring[m]> | mstenta: I've been thinking more again about what we discussed on the train, extending the farmOS API libraries with corresponding "sync" libraries in each language. To recap, it would be a way of propagating the farmOS data and its overall schema to local machines, along with mechanisms for tracking changes/discrepencies from the farmOS server... I think it could have a LOT of utilty, although I'm still scratching my |
| [14:28:30] | <jgaehring[m]> | head a bit to think of how to implement it in JS, let alone how to generalize it to libraries that could be implemented in any language, potentially |
| [14:29:30] | <mstenta[m]> | jgaehring: Awesome! I had a call earlier today with paul121 and mentioned the ideas briefly. |
| [14:29:47] | <mstenta[m]> | In the Aggregator project, we're going to need something similar (in Python) |
| [14:30:42] | <mstenta[m]> | I think we'd essentially just want to define the schema in a cross-platform way, somehow (eg: YAML?) |
| [14:31:12] | <mstenta[m]> | And then translate that into SQLAlchemy models (python), IndexDB models (JS browser), and something else for node.js... |
| [14:31:25] | <mstenta[m]> | (IndexDB is not available in node.js, correct? Or is it?) |
| [14:31:54] | <mstenta[m]> | (I know node.js can also do sqlite3, so that's an option too) |
| [14:32:17] | <jgaehring[m]> | correct, IDB is not available in node.js |
| [14:32:25] | <mstenta[m]> | (i wonder if node.js has something like sqlalchemy (generalized ORM library that can be used with different db backends like sqlite3, postgresql, etc0 |
| [14:33:25] | <jgaehring[m]> | > (i wonder if node.js has something like sqlalchemy (generalized ORM library that can be used with different db backends like sqlite3, postgresql, etc0 |
| [14:33:25] | <jgaehring[m]> | huh, i'm not sure |
| [14:34:56] | <jgaehring[m]> | see what I've been thinking about is how something like a sync library could be applied to pulling the schema into something like Vuex or Redux, which are JS stores for keeping state in memory |
| [14:36:23] | <jgaehring[m]> | and then whether it's possible to make a library generic enough to work in BOTH Vuex and Redux, or whether you'd need a specific implementation for each, or whether it would just make sense to implement our own store (which wouldn't be too hard, but would result in sacrificing some of the tools and middleware that already come with Vuex/Redux) |
| [14:36:59] | <mstenta[m]> | oh yea, good thoughts... those are two other potential use-cases |
| [14:37:39] | <mstenta[m]> | so we've got: python, browser storage, JS memory, node.js (server) |
| [14:37:43] | <jgaehring[m]> | or maybe we only publish a schema? |
| [14:38:07] | <mstenta[m]> | and JS memory can be split into Vuex, Redux (and maybe more?) |
| [14:38:16] | <mstenta[m]> | yea... i think just publishing a schema is the most realistic... and leave it to libraries to stick to it |
| [14:38:22] | <mstenta[m]> | similar to the API libs |
| [14:38:25] | <jgaehring[m]> | yea, possibly |
| [14:38:27] | <mstenta[m]> | versioned |
| [14:39:56] | <jgaehring[m]> | perhaps publish a schema, and then also extract a Vuex library, which Field Kit can consume, as an example of how to implement the schema |
| [14:40:54] | <mstenta[m]> | mm yea |
| [14:41:33] | <mstenta[m]> | i wonder if it would make sense to include any of that in the farmOS.js/farmOS.py libraries themselves |
| [14:41:40] | <mstenta[m]> | as an optional local store |
| [14:41:49] | <mstenta[m]> | or if it should be kept separate |
| [14:42:17] | <jgaehring[m]> | that way, if there is a community which grows to find it useful to have a specific Redux or React Context implementation available, then that community can roll its own, but with some guidance |
| [14:43:02] | <mstenta[m]> | yea |
| [14:43:18] | <jgaehring[m]> | > i wonder if it would make sense to include any of that in the farmOS.js/farmOS.py libraries themselves |
| [14:43:19] | <jgaehring[m]> | > as an optional local store |
| [14:43:20] | <jgaehring[m]> | > or if it should be kept separate |
| [14:43:21] | <jgaehring[m]> | that could be useful |
| [14:43:35] | <mstenta[m]> | it could certainly be helpful in Python |
| [14:43:57] | <mstenta[m]> | but JS might be vue/react specific, like you said... which farmOS.js is currently agnostic of |
| [14:44:14] | <jgaehring[m]> | right |
| [14:49:37] | <paul121[m]> | I'm following... I think. We decide on a schema and follow that design in our APIs |
| [14:49:59] | <paul121[m]> | It looks like there are schema validators which could help enforce this |
| [14:50:30] | <paul121[m]> | BUT the prob is JS might need different schemas depending on the library? |
| [14:51:21] | <mstenta[m]> | yea, or rather: slightly different implementations... the schema itself would be the same |
| [14:51:48] | <jgaehring[m]> | > yea, or rather: slightly different implementations... the schema itself would be the same |
| [14:51:49] | <jgaehring[m]> | exactly |
| [14:52:10] | <mstenta[m]> | (by "schema" i mean the tables/fields) |
| [14:52:11] | <jgaehring[m]> | > It looks like there are schema validators which could help enforce this |
| [14:52:12] | <jgaehring[m]> | i like that idea, "schema validators", a lot |
| [14:52:16] | <mstenta[m]> | and by "tables/fields" i mean whatever that translates to in a non-SQL db ;-) |
| [14:52:27] | <jgaehring[m]> | haha |
| [14:52:32] | <mstenta[m]> | objects and properties |
| [14:53:08] | <jgaehring[m]> | for more background, I thought of "tables/fields" as the concept of a "state tree" in Redux |
| [14:53:17] | <mstenta[m]> | i gotta run... but wanted to share this also (unrelated but thought you might like it): https://www.drupal.org/project/farm/issues/3046929 |
| [14:53:26] | <mstenta[m]> | added a `data` field to all assets and logs |
| [14:53:29] | <mstenta[m]> | hidden in the farmOS UI |
| [14:53:41] | <mstenta[m]> | which can be used to store arbitrary JSON/XML/YAML/etc |
| [14:54:03] | <mstenta[m]> | it should allow for some interesting possibilities :-) |
| [14:54:50] | <mstenta[m]> | (imagine third-party apps storing extra data in there, for it's own specific needs... stuff that doesn't necessarily fit somewhere else in farmOS) |
| [14:55:10] | <paul121[m]> | > added a `data` field to all assets and logs |
| [14:55:11] | <paul121[m]> | Neat! |
| [14:55:34] | <mstenta[m]> | (at least as a testing ground and place to experiment... then if it makes sense, create more fields in farmOS) |
| [14:55:49] | <jgaehring[m]> | oh neat indeed! |
| [15:08:31] | <paul121[m]> | Related, would be a schema for our API. I came across https://github.com/OAI/OpenAPI-Specification |
| [15:08:32] | <paul121[m]> | Swagger became openAPI with v3.0. Didn't know much about any of this, but soaking it up now! |
| [15:13:29] | <jgaehring[m]> | oh cool! |
| [15:17:31] | <mbconsultinguk[m> | Swagger is great, it's got libraries for pretty much every language and gives you a really nice set of documentation without much effort |
| [15:45:37] | <mstenta[m]> | Sounds promising! |
| [15:48:29] | <mbconsultinguk[m> | See https://console.ourdata.network/api for an example of the output |
| [15:49:28] | <mbconsultinguk[m> | (that's from the Loraserver.io project, which is written in golang) |