| [20:12:25] | * JustTB has quit (Ping timeout: 240 seconds) |
| [20:31:32] | * JustTB has joined #farmos |
| [23:07:55] | * JustTB has quit (Ping timeout: 265 seconds) |
| [23:22:38] | * JustTB has joined #farmos |
| [00:35:45] | * JustTB has quit (Quit: Leaving.) |
| [01:13:52] | * JustTB has joined #farmos |
| [04:44:48] | * martha[m] has joined #farmos |
| [08:38:45] | * tcmah[m] has quit (*.net *.split) |
| [08:38:45] | * paul121[m] has quit (*.net *.split) |
| [08:38:45] | * samrose[m] has quit (*.net *.split) |
| [08:38:45] | * gunter[m] has quit (*.net *.split) |
| [08:38:45] | * pllagn[m] has quit (*.net *.split) |
| [08:40:31] | * friedrich[m]1 has quit (Write error: Connection reset by peer) |
| [08:40:34] | * martha[m] has quit (Write error: Connection reset by peer) |
| [08:40:34] | * jgaehring[m] has quit (Read error: Connection reset by peer) |
| [08:40:35] | * calbasi_matrix has quit (Read error: Connection reset by peer) |
| [08:40:35] | * botlfarm[m] has quit (Read error: Connection reset by peer) |
| [08:40:36] | * andifi[m] has quit (Read error: Connection reset by peer) |
| [08:40:36] | * ghpstudent[m] has quit (Read error: Connection reset by peer) |
| [08:40:36] | * cekerber[m] has quit (Remote host closed the connection) |
| [08:40:37] | * skipper_is[m] has quit (Read error: Connection reset by peer) |
| [08:40:37] | * lpuro[m] has quit (Read error: Connection reset by peer) |
| [08:40:37] | * canadrian[m] has quit (Read error: Connection reset by peer) |
| [08:40:38] | * Dorn[m] has quit (Read error: Connection reset by peer) |
| [08:40:38] | * laurademmel[m] has quit (Read error: Connection reset by peer) |
| [08:40:39] | * mstenta[m] has quit (Remote host closed the connection) |
| [08:40:40] | * symbioquine[m] has quit (Read error: Connection reset by peer) |
| [08:40:40] | * anashaddad[m] has quit (Remote host closed the connection) |
| [08:40:40] | * getic[m] has quit (Remote host closed the connection) |
| [08:40:40] | * germarsh[m] has quit (Read error: Connection reset by peer) |
| [08:40:41] | * spitz234[m] has quit (Write error: Connection reset by peer) |
| [08:40:41] | * tool172[m] has quit (Remote host closed the connection) |
| [08:40:41] | * ddsh[m] has quit (Read error: Connection reset by peer) |
| [08:40:41] | * dazinism has quit (Remote host closed the connection) |
| [08:40:41] | * scrdcow[m] has quit (Write error: Connection reset by peer) |
| [08:40:42] | * ringo[m]2 has quit (Read error: Connection reset by peer) |
| [08:40:43] | * peter[m]3 has quit (Write error: Connection reset by peer) |
| [08:40:43] | * donblair[m] has quit (Read error: Connection reset by peer) |
| [08:40:43] | * munjoma[m] has quit (Read error: Connection reset by peer) |
| [08:40:43] | * leogaggl[m] has quit (Read error: Connection reset by peer) |
| [08:40:43] | * kunigunde[m] has quit (Read error: Connection reset by peer) |
| [08:40:44] | * farmtech[m] has quit (Remote host closed the connection) |
| [08:40:44] | * jsauma[m] has quit (Read error: Connection reset by peer) |
| [08:40:45] | * mindcls[m] has quit (Write error: Connection reset by peer) |
| [08:40:45] | * komatek[m] has quit (Read error: Connection reset by peer) |
| [08:40:45] | * jack_monty[m] has quit (Write error: Connection reset by peer) |
| [08:40:45] | * stefanie[m] has quit (Read error: Connection reset by peer) |
| [08:40:45] | * kirsten-mc[m] has quit (Remote host closed the connection) |
| [08:40:46] | * abinash[m] has quit (Write error: Broken pipe) |
| [08:40:47] | * olaf[m] has quit (Write error: Connection reset by peer) |
| [08:40:47] | * michail[m] has quit (Write error: Connection reset by peer) |
| [08:40:47] | * antoine[m] has quit (Write error: Connection reset by peer) |
| [08:40:47] | * petra[m] has quit (Write error: Broken pipe) |
| [08:40:47] | * frederike[m] has quit (Write error: Broken pipe) |
| [08:40:47] | * rafaeltcc[m] has quit (Remote host closed the connection) |
| [08:48:30] | * abinash[m] has joined #farmos |
| [08:50:00] | * getic[m] has joined #farmos |
| [08:57:08] | * JustTB has quit (Ping timeout: 256 seconds) |
| [09:12:58] | * JustTB has joined #farmos |
| [09:13:39] | * antoine[m] has joined #farmos |
| [09:13:40] | * calbasi_matrix has joined #farmos |
| [09:13:40] | * friedrich[m]1 has joined #farmos |
| [09:13:40] | * frederike[m] has joined #farmos |
| [09:13:40] | * gunter[m] has joined #farmos |
| [09:13:40] | * jack_monty[m] has joined #farmos |
| [09:13:41] | * kunigunde[m] has joined #farmos |
| [09:13:41] | * martha[m] has joined #farmos |
| [09:13:41] | * michail[m] has joined #farmos |
| [09:13:41] | * mindcls[m] has joined #farmos |
| [09:13:41] | * norbert[m] has joined #farmos |
| [09:13:41] | * olaf[m] has joined #farmos |
| [09:13:41] | * petra[m] has joined #farmos |
| [09:13:41] | * phantomse[m] has joined #farmos |
| [09:13:41] | * pllagn[m] has joined #farmos |
| [09:13:41] | * ringo[m]2 has joined #farmos |
| [09:13:42] | * scrdcow[m] has joined #farmos |
| [09:13:42] | * stefanie[m] has joined #farmos |
| [09:13:46] | * ghpstudent[m] has joined #farmos |
| [09:13:46] | * ddsh[m] has joined #farmos |
| [09:13:46] | * andifi[m] has joined #farmos |
| [09:13:46] | * jgaehring[m] has joined #farmos |
| [09:13:46] | * Dorn[m] has joined #farmos |
| [09:13:46] | * cekerber[m] has joined #farmos |
| [09:13:46] | * anashaddad[m] has joined #farmos |
| [09:13:46] | * germarsh[m] has joined #farmos |
| [09:13:46] | * farmtech[m] has joined #farmos |
| [09:13:46] | * donblair[m] has joined #farmos |
| [09:13:46] | * komatek[m] has joined #farmos |
| [09:13:46] | * jsauma[m] has joined #farmos |
| [09:13:46] | * botlfarm[m] has joined #farmos |
| [09:13:47] | * kirsten-mc[m] has joined #farmos |
| [09:13:47] | * canadrian[m] has joined #farmos |
| [09:13:47] | * munjoma[m] has joined #farmos |
| [09:13:47] | * mstenta[m] has joined #farmos |
| [09:13:47] | * laurademmel[m] has joined #farmos |
| [09:13:48] | * symbioquine[m] has joined #farmos |
| [09:13:48] | * spitz234[m] has joined #farmos |
| [09:13:48] | * tcmah[m] has joined #farmos |
| [09:13:48] | * peter[m]3 has joined #farmos |
| [09:13:48] | * samrose[m] has joined #farmos |
| [09:13:48] | * rafaeltcc[m] has joined #farmos |
| [09:13:48] | * skipper_is[m] has joined #farmos |
| [09:13:49] | * tool172[m] has joined #farmos |
| [09:13:50] | * paul121[m] has joined #farmos |
| [09:13:51] | * lpuro[m] has joined #farmos |
| [09:30:12] | * dazinism has joined #farmos |
| [09:30:18] | * leogaggl[m] has joined #farmos |
| [10:25:27] | * JustTB has quit (Ping timeout: 240 seconds) |
| [10:41:18] | * JustTB has joined #farmos |
| [11:15:37] | * norbert[m] has left #farmos ("Kicked by @appservice-irc:matrix.org : Idle for 30+ days") |
| [11:16:32] | * phantomse[m] has quit (Quit: Idle for 30+ days) |
| [11:17:32] | * getic[m] has left #farmos ("Kicked by @appservice-irc:matrix.org : Idle for 30+ days") |
| [12:07:45] | * JustTB has quit (Ping timeout: 240 seconds) |
| [12:21:45] | * JustTB has joined #farmos |
| [13:21:53] | <paul121[m]> | hey mstenta just came across the issue for generalizing sensor listener code: https://github.com/farmOS/farmOS/issues/174 |
| [13:23:25] | <paul121[m]> | In addition the Arable sensor module I've been working on, I might need to create another sensor module for a custom integration |
| [13:24:07] | <paul121[m]> | the integration might be able to just be a `farm_sensor_listener` module but still thinking it though... |
| [13:24:50] | <paul121[m]> | either way, curious if I might be able to contribute to generalizing the sensor listener code in the process! |
| [13:25:23] | <mstenta[m]> | paul121: cool! |
| [13:25:29] | <paul121[m]> | seems like the main motivation is generalizing the notifications that listener sensors have? |
| [13:26:00] | <mstenta[m]> | yes, when i created that issue i had a very specific set of things in mind |
| [13:26:11] | <mstenta[m]> | (the issue also has some other discussions in it) |
| [13:26:21] | <mstenta[m]> | > What we can do in farmOS, if it would be helpful, is to generalize some of the code in the farm_sensor_listener module (which provides the simple "Listener" sensor type) out to the farm_sensor module (which provides the general sensor features, and pluggable sensor type system). For example, the sensor alerts code is currently in farm_sensor_listener, which means it only works with that type. There may be other code that |
| [13:26:21] | <mstenta[m]> | would be useful to other sensor types as well, so it might be useful to split some of it out. I think that can be done on a case-by-case basis, so we probably don't need a dedicated issue for it, now that I think more about it. And we may find that some things are just too tightly coupled to the way farmOS stores simple sensor data anyway, so it doesn't make sense to try to generalize it. I guess we'll see. |
| [13:26:28] | <mstenta[m]> | https://github.com/farmOS/farmOS/issues/174#issuecomment-500514227 |
| [13:27:02] | <mstenta[m]> | But... it might need some more thought... |
| [13:27:34] | <mstenta[m]> | The "notifications" are tightly linked currently to the listener type |
| [13:27:45] | <mstenta[m]> | They are triggered when a data point is received by the listener endpoint |
| [13:27:57] | <paul121[m]> | yea looking at that code now |
| [13:28:22] | <mstenta[m]> | So it might make sense to actually create a new issue specifically for generalizing the notification logic, and setting it up in a way that other sensor types can leverage |
| [13:29:18] | <paul121[m]> | right.. |
| [13:29:38] | <paul121[m]> | does Drupal have any "core" support for notifications/alerts? |
| [13:29:57] | <paul121[m]> | I'm thinking similar to `drupal_set_message` but maybe something a bit more persistent? |
| [13:30:55] | <mstenta[m]> | no, not really |
| [13:31:09] | <mstenta[m]> | one thing I would love to see is a transition to using something like Rules |
| [13:31:13] | <mstenta[m]> | https://drupal.org/project/rules |
| [13:31:25] | <paul121[m]> | perhaps allowing module to provide notification "callbacks" would be handy |
| [13:31:45] | <paul121[m]> | ohh yeah keep needing to play with Rules |
| [13:31:56] | <mstenta[m]> | but we definitely won't be adopting Rules in 7.x-1.x |
| [13:32:09] | <mstenta[m]> | still - you could consider using it for your specific needs |
| [13:32:10] | <paul121[m]> | one use case: set a "Needs attention" flag on a Planting asset when sensor values are "high" |
| [13:32:22] | <mstenta[m]> | ah cool yea - Rules could do that |
| [13:32:33] | <mstenta[m]> | Rules is really powerful |
| [13:33:01] | <paul121[m]> | sweet I'll look into that! |
| [13:33:08] | <mstenta[m]> | it basically lets you set up automated actions with a "Trigger", "Conditions", and "Actions" |
| [13:33:20] | <mstenta[m]> | it's easy to write your own plugins for each of those too |
| [13:33:42] | <mstenta[m]> | so we would probably need a new "Trigger" plugin, for example, to fire when data is received, which then pipes it into Rules |
| [13:34:40] | <mstenta[m]> | https://git.drupalcode.org/project/rules/-/blob/7.x-2.x/rules.api.php#L370 |
| [13:35:09] | <mstenta[m]> | > The module has to invoke the event when it occurs using rules_invoke_event(). This function call has to happen outside of MODULENAME.rules.inc, usually it's invoked directly from the providing module but wrapped by a module_exists('rules') check. |
| [13:35:49] | <mstenta[m]> | So.... we *could* consider adding OPTIONAL support for Rules in the `farm_sensor` module... without actually using or depending on it ourselves |
| [13:36:26] | <paul121[m]> | hmmm |
| [13:36:42] | <mstenta[m]> | Thing is... Rules has it's own UI where all rules are defined... it's not necessarily tied to specific assets |
| [13:36:45] | <mstenta[m]> | So that's another angle to it |
| [13:37:05] | <paul121[m]> | sorta like Views? |
| [13:37:11] | <mstenta[m]> | But definitely ways to go about that... passing extra info into the event, etc |
| [13:37:15] | <mstenta[m]> | Yes |
| [13:37:51] | <mstenta[m]> | So ideally, I think there would be a single "sensor notification" Rule, which all individual sensor assets feed details/conditions into somehow |
| [13:38:03] | <mstenta[m]> | (As opposed to having to configure a new Rule for each sensor) |
| [13:38:28] | <mstenta[m]> | That's how I would do it IF WE WERE SUPPORTING RULES in farmOS haha |
| [13:38:37] | <paul121[m]> | yeah that makes sense |
| [13:38:39] | <mstenta[m]> | but yea I'm also wary of setting expectations i ncore |
| [13:38:47] | <mstenta[m]> | at least before 2.x |
| [13:39:08] | <paul121[m]> | and I think that is prob too much to bite off for this little project anyways |
| [13:39:14] | <mstenta[m]> | notably from the Rules project page: |
| [13:39:15] | <mstenta[m]> | > Rules cannot be compatible with Drupal 9 until https://www.drupal.org/project/drupal/issues/3126747 is fixed. |
| [13:39:44] | <mstenta[m]> | oh and: |
| [13:39:44] | <mstenta[m]> | > Rules will also not sacrifice compatibility with the currently-supported versions of Drupal core, so Drupal 9 will not be supported until Drupal 8.8 is the lowest-supported version of Drupal core. The issues that are postponed because of this are listed in https://www.drupal.org/project/rules/issues/3089502 |
| [13:39:52] | <paul121[m]> | what would be handy..... being able to extend `farm_sensor_listener` |
| [13:40:05] | <mstenta[m]> | I had been following Rules' D8 upgrade progress for a while, and it's been SLOW |
| [13:40:16] | <mstenta[m]> | ah hmm yea that's another option |
| [13:40:28] | <paul121[m]> | basically just need to add additional `sensor_settings` |
| [13:40:30] | <mstenta[m]> | in what ways do you imagine? what requirements are you htinking about ? |
| [13:40:38] | <mstenta[m]> | oh ok - well that's easy! (iirc) |
| [13:40:43] | <mstenta[m]> | you can just use hook_form_alter() |
| [13:40:58] | <mstenta[m]> | but I think any fields you add to that form will be saved to the db settings automatically |
| [13:41:10] | <paul121[m]> | yup that is correct |
| [13:42:17] | <paul121[m]> | I guess I could use `hook_form_alter()` |
| [13:42:39] | <paul121[m]> | but I also don't want these additional settings to appear on ALL listener sensors |
| [13:43:22] | <paul121[m]> | basically, want a new sensor type, with the "listener" pub/private key logic |
| [13:44:43] | <mstenta[m]> | ah yes |
| [13:45:21] | <mstenta[m]> | i suppose you could provide a new type, but then just reuse all the functions from `farm_sensor_listener` |
| [13:45:27] | <mstenta[m]> | (adding what you need on top) |
| [13:45:46] | <mstenta[m]> | So just kind of a wrapper around the listener code |
| [13:46:35] | <paul121[m]> | ahhh yes |
| [13:47:08] | <paul121[m]> | and `hook_form_alter` or just re-create parts of that form that are needed |
| [13:48:21] | <mstenta[m]> | yea if you make a wrapper you can probably just provide your own form function that delegates to the listener form function |
| [13:52:33] | <paul121[m]> | right |
| [13:53:44] | <paul121[m]> | that might be what I do! |
| [13:53:54] | <paul121[m]> | last thing I was curious about... |
| [13:54:31] | <paul121[m]> | this sensor really just needs to be associated with an individual planting asset |
| [13:54:35] | <paul121[m]> | not an area |
| [13:55:12] | <paul121[m]> | (its a dendrometer measuring plant stem growth) |
| [13:56:10] | <mstenta[m]> | ah |
| [13:56:28] | <paul121[m]> | but... the only way to do this would be creating another field on that "custom sensor type" asset, yea? |
| [13:56:38] | <mstenta[m]> | not that this helps you now, but my thinking for the future is: when "areas" become "assets" themselves, we will essentially allow any asset to be located on any other asset |
| [13:56:40] | <paul121[m]> | (or a bit messier, adding it as a `sensor_setting` ?) |
| [13:57:13] | <paul121[m]> | oohhh yes |
| [13:57:28] | <mstenta[m]> | what is your desired result? that the sensor shows up when you are looking at the planting? |
| [13:57:55] | <paul121[m]> | yep |
| [13:58:35] | <mstenta[m]> | a very simple (not very good UX) solution would be to add an "asset ID" setting to the sensor, and then use `hook_entity_view_alter()` to add stuff to the asset page |
| [13:58:37] | <mstenta[m]> | kinda hacky, but it would work |
| [13:59:05] | <paul121[m]> | yea, already doing something similar |
| [13:59:50] | <paul121[m]> | graphing observations associated with an area, on all plantings in that area |
| [13:59:55] | <mstenta[m]> | the other question there is: what happens next year? |
| [13:59:59] | <mstenta[m]> | make a new planting, update the ID in the sensor? |
| [14:00:07] | <mstenta[m]> | you don't really get to keep track of the old planting data that way |
| [14:00:45] | <mstenta[m]> | idea: maybe we should start thinking about the data itself being associated with an area/asset, rather than with the sensor |
| [14:00:54] | <paul121[m]> | true |
| [14:01:13] | <mstenta[m]> | so... you could have a sensor associate with a planting, but then you could associate it with something else, and all the old data would stay associated with the old planting |
| [14:01:23] | <mstenta[m]> | something to think about for 2.x perhaps... |
| [14:01:35] | <paul121[m]> | well, you could use movement logs to associate when/where/what data was associated with |
| [14:01:54] | <paul121[m]> | but its sorta complicated |
| [14:01:58] | <mstenta[m]> | yup true... because you can move sensor assets |
| [14:01:59] | <paul121[m]> | definitely something to think about! |
| [14:02:57] | <mstenta[m]> | well what about this: keep the sensor associated with the area, but put some logic in custom module that, when you are looking at a planting, it looks for sensors in the same area and shows data from that |
| [14:03:11] | <mstenta[m]> | (back to your specific case right now) |
| [14:03:30] | <mstenta[m]> | so it's not technically associated with the planting, but you see the data on the planting page |
| [14:03:35] | <mstenta[m]> | so you get the end result you want |
| [14:03:57] | <mstenta[m]> | and that logic could in theory take into account the sensor movement logs to make sure it was actually in that area at the same time as the planting... more complicated but possible |
| [14:04:16] | <paul121[m]> | yeah I think that will be best |
| [14:05:17] | <paul121[m]> | associating it with the planting ID would work too |
| [14:05:27] | <paul121[m]> | and just archive + recreate the sensor |
| [14:06:17] | <paul121[m]> | still need to figure out how I'll be sending data to the farmOS listener.... |
| [14:06:44] | <paul121[m]> | have to pull data off an FTP server.... |
| [14:08:08] | <mstenta[m]> | :-P |
| [19:50:45] | * JustTB has quit (Quit: Leaving.) |