| [22:42:57] | * JustTB has quit (Ping timeout: 245 seconds) |
| [22:59:24] | * JustTB has joined #farmos |
| [03:06:34] | * JustTB has quit (Read error: Connection reset by peer) |
| [03:06:39] | * JustTB1 has joined #farmos |
| [04:35:43] | * JustTB1 has quit (Quit: Leaving.) |
| [04:37:37] | * JustTB has joined #farmos |
| [05:46:20] | * svenn has quit (Ping timeout: 255 seconds) |
| [12:11:18] | * kion has joined #farmos |
| [12:25:26] | * captmeowgan has joined #farmos |
| [12:25:50] | <MockingbirdConsu> | ACTION uploaded an image: FarmOSLoRaWAN.png (84KB) < https://matrix.org/_matrix/media/v1/download/matrix.org/mzYIVTPkcoloUnTI... > |
| [12:26:22] | <MockingbirdConsu> | It's working! That's a python script listening to the LoRaWAN MQTT feed, repacking the data, and posting to a default "listener" sensor |
| [12:26:52] | <MockingbirdConsu> | I'll clean up the code and publish it a bit later on, but it looks like it's going to be incredibly simple if you've just got one sensor, and only slightly more difficult if you've got more than one sensor! :) |
| [12:27:42] | <mstenta[m]> | Whoa! |
| [12:27:50] | <mstenta[m]> | That's awesome!! |
| [12:31:14] | <MockingbirdConsu> | I need to sort out our evening meal etc, but I should get an hour or so tonight to tidy it up a bit. Are the public/private keys for the sensors stored in the database? If they do, and this runs on the same host as FarmOS then I should be able to query the DB based on the sensor name and find the right API end-point to post to |
| [12:31:49] | <MockingbirdConsu> | Note that the timestamp is the time the packet is received by the script at the moment, not the time it is received by LoRaServer.io, but I've not worked out why that is yet :( |
| [12:32:34] | <mstenta[m]> | > Are the public/private keys for the sensors stored in the database? |
| [12:32:35] | <mstenta[m]> | Yes |
| [12:32:37] | <mstenta[m]> | Yes |
| [12:32:58] | <MockingbirdConsu> | cool, I'll give that a go later on as well then. |
| [12:33:05] | <mstenta[m]> | But it might be nice to keep that as a separate config process for your script - so that it works on other servers as well. |
| [12:33:14] | <mstenta[m]> | (And to make the setup a little more intentional perhaps) |
| [12:33:16] | <mstenta[m]> | But up to you! |
| [12:35:02] | <MockingbirdConsu> | other servers as in alternatives to LoRaServer.io or other servers as in alternatives to FarmOS? |
| [12:36:29] | <mstenta[m]> | Oh I mean if the Python script isn't on the same server as farmOS |
| [12:36:48] | <MockingbirdConsu> | oh, right, yeah, good point :D |
| [12:36:59] | <mstenta[m]> | Eg: if someone is hosting on Farmier, but want to host their own Python script for forwarding Lora data points |
| [12:37:37] | <MockingbirdConsu> | OK, sounds like I need to read the API docs... ;) |
| [12:45:31] | <MockingbirdConsu> | ok, next question - is it possible to create a new sensor or get a list of sensors via the API? |
| [12:45:32] | <MockingbirdConsu> | It looks like I should be able to auth and call /farm.json via basic auth, which would probably do, but I can't see an end-point to list the existing sensors |
| [12:45:33] | <MockingbirdConsu> | any ideas? |
| [12:46:28] | <mstenta[m]> | You can get a list of existing sensors via `/farm_asset.json?type=sensor` |
| [12:46:40] | <mstenta[m]> | And you can create a new sensor asset that way.... but... |
| [12:46:59] | <mstenta[m]> | I don't think that the "sensor type" and other configuration are available over API at this point |
| [12:47:22] | <mstenta[m]> | Those are somewhat custom, so they don't get picked up automatically by the module we are using to generate the API |
| [12:47:22] | <mstenta[m]> | But that would be a great feature request |
| [12:48:54] | <MockingbirdConsu> | ok, cool, so for now, it's a case of "name it in FarmOS, call it the same thing on your LoRa server (whichever one you're using) and we'll match it up and pass the metrics"? Does that sound like a reasonable first pass? |
| [12:50:21] | <mstenta[m]> | Maybe? I don't have a clear picture in my head of the whole thing (just the farmOS side) |
| [12:51:08] | <MockingbirdConsu> | :D OK, I'll work on that approach for now, and when it breaks, we can fix it! :D |
| [12:51:22] | <MockingbirdConsu> | ACTION sent a long message: < https://matrix.org/_matrix/media/v1/download/matrix.org/aZQrjjvKsvCZzRgA... > |
| [12:51:22] | <mstenta[m]> | Sounds good! :-D |
| [12:52:06] | <mstenta[m]> | No... it doesn't... |
| [12:52:28] | <mstenta[m]> | Because that stuff is custom (not part of Drupal's entity API) |
| [12:52:35] | <mstenta[m]> | So we'd need to hook that up for the API |
| [12:52:37] | <mstenta[m]> | But... |
| [12:52:58] | <mstenta[m]> | I'd also like to think through whether or not we SHOULD have that info in the API |
| [12:53:14] | <mstenta[m]> | I can definitely see how that would be useful |
| [12:53:19] | <MockingbirdConsu> | ok, for now, I'll assume it runs on the same host, stick some logic in there for something to do the retrieval via REST when we can get the sensor keys that way, retrieve it direct from the DB and at least get it working. Then when/if FarmOS exposes the keys via the API, I can add the logic to check the API for that data. |
| [12:53:24] | <mstenta[m]> | But what risks does it create? (open question) |
| [12:53:33] | <MockingbirdConsu> | for sure, that's a valid point, and one that needs thinking about |
| [12:53:44] | <mstenta[m]> | My thought is: just make it a one-time manual setup process when you are creating your stream |
| [12:54:15] | <mstenta[m]> | And copy the pub/priv keys at that point... doesn't necessarily need to be an automated setup process (although that would certainly make the process of initial setup easier) |
| [12:54:48] | <mstenta[m]> | But I do like that you're thinking this through... auto-generating sensor assets isn't something we've thought about before... |
| [12:55:07] | <mstenta[m]> | (And can certainly be done via direct DB queries, like you said) |
| [12:58:11] | <paul121[m]> | > It's working! That's a python script listening to the LoRaWAN MQTT feed, repacking the data, and posting to a default "listener" sensor |
| [12:58:12] | <paul121[m]> | Awesome! |
| [13:00:19] | <paul121[m]> | Excited to see the script. I haven't played with sensors in farmOS (or MQTT) yet... But think I will be doing that soon! |
| [13:01:23] | <mstenta[m]> | paul121: i wonder if we should add some features to farmOS.py for interacting with listener sensors |
| [13:01:51] | <mstenta[m]> | the sensor listener API stuff is slightly different than the normal farmOS API stuff that is already in farmOS.py |
| [13:02:01] | <mstenta[m]> | for one, it does not require username/password authentication |
| [13:02:13] | <mstenta[m]> | instead, it uses a public/private key for each sensor |
| [13:02:18] | <MockingbirdConsu> | oh, wow, I'd not see that python stuff already |
| [13:02:29] | <mstenta[m]> | Mockingbird Consulting: oh yea! |
| [13:02:36] | <mstenta[m]> | https://github.com/farmOS/farmOS.py |
| [13:02:43] | <mstenta[m]> | (thanks to paul121 ) ;-) |
| [13:03:15] | <mstenta[m]> | like I said though... it does NOT have stuff for the sensor listener features... (yet) |
| [13:03:25] | <mstenta[m]> | just for dealing with assets, logs, areas, etc |
| [13:05:22] | <MockingbirdConsu> | nice! Is that on PyPi for installation? (Note to self: Cook dinner already! :D ) |
| [13:06:07] | <mstenta[m]> | yes it is! |
| [13:06:08] | <mstenta[m]> | (also thanks to paul121 ) |
| [13:09:27] | <paul121[m]> | Cool! Yeah, we should definitely think about it |
| [13:09:57] | <paul121[m]> | This would be used for sending sensor data to farmOS? Or adding sensors? |
| [13:11:19] | * farmBOT has joined #farmos |
| [13:11:41] | <paul121[m]> | And yes! farmOS.py is on PyPi. It doesn't have the most recent updates (a couple bug fixes, fixing the method responses) |
| [13:12:40] | <paul121[m]> | Was hoping to update that tomorrow. Maybe we could shoot for v0.1 with a solid core API (logs, assets, terms) and some features for sensors |
| [13:47:10] | * kion has quit (Quit: Page closed) |
| [14:25:43] | * captmeowgan has quit (Quit: Page closed) |
| [14:32:38] | * JustTB has quit (Ping timeout: 250 seconds) |
| [14:33:14] | * JustTB has joined #farmos |
| [14:43:55] | <mstenta[m]> | > This would be used for sending sensor data to farmOS? Or adding sensors? |
| [14:43:56] | <mstenta[m]> | I was thinking specifically for GETTING (and maybe also sending) data from a sensor |
| [14:44:27] | <mstenta[m]> | I think adding sensors would already be possible via the asset methods... except for the sensor-specific info that I mentioned above (that will require adding that capability to the server) |
| [15:19:50] | <MockingbirdConsu> | ok, I'm getting there with this, what's the format used for the sensor settings in the database? It looks a bit like JSON, but it's not... |
| [15:20:31] | <mstenta[m]> | ah yea... serialized PHP |
| [15:20:34] | <mstenta[m]> | :-/ |
| [15:20:49] | <mstenta[m]> | https://www.php.net/manual/en/function.serialize.php |
| [15:20:59] | <MockingbirdConsu> | w00t! https://pypi.org/project/phpserialize/ |
| [15:21:05] | <MockingbirdConsu> | Python wins again :D |
| [15:21:22] | <mstenta[m]> | https://stackoverflow.com/questions/5408599/how-to-read-make-sense-of-a-... |
| [15:21:23] | <MockingbirdConsu> | thanks. |
| [15:21:25] | <mstenta[m]> | haha! you beat me to it :-) |
| [16:37:33] | * svenn has joined #farmos |
| [19:10:46] | * JustTB has quit (Quit: Leaving.) |
| [19:14:53] | * JustTB has joined #farmos |