IRC logs for #farmOS, 2019-05-09 (GMT)

2019-05-08
2019-05-10
TimeNickMessage
[22:32:27]* JustTB has quit (Ping timeout: 248 seconds)
[22:46:56]* JustTB has joined #farmos
[23:51:17]* JustTB has quit (Quit: Leaving.)
[00:02:50]* JustTB has joined #farmos
[05:03:51]* JustTB has quit (Quit: Leaving.)
[05:27:36]* JustTB has joined #farmos
[08:13:11]* karna[m] has joined #farmos
[08:17:24]<karna[m]>Hey everyone, I'm working on an aquaponics project, where we're looking to push sensor (temp, humidity, lux, pH) data to farmOS, which we'll possibly be hosting our own implementation of. Our aquaponics unit will be in a public space. Initially we are concerned with integrating with farmOS to help us in troubleshooting when things go wrong, but eventually the public may be able to interact with this
[08:18:17]<karna[m]>Just wanted thoughts on best thing to use for time-series graphing of data. Sensors will be pushing data to farmOS using a listener
[08:31:44]<MockingbirdConsu>At the moment, all sensor data is stored one row per measurement in a table for sensor data. We're hoping to work out a better way of doing this for our IoT sensors, but for now we're sending data to both FarmOS (so it can be graphed in the UI) and either InfluxDB or Elasticsearch depending on the customer.
[08:31:45]<MockingbirdConsu>Graphing is done via Grafana.
[08:31:46]<MockingbirdConsu>Which technology are you using to send the data back from the sensor to the platform?
[09:09:27]<karna[m]>ESP32 + RaspPi
[09:09:34]<karna[m]>What are InfluxDB/Elasticsearch used for?
[09:12:24]<MockingbirdConsu>Metrics storage, but they're designed for it unlike MySQL which is fine for low-volume ( < 10 metrics/5 minutes ) sensors, but as soon as you start to hit a couple of hundred (or even thousand!) metrics points/minute it tends to get unhappy about the number of writes you're doing.
[09:12:53]<MockingbirdConsu>https://www.influxdata.com/ and https://elastic.co are the respective websites
[09:13:27]<MockingbirdConsu>We're partners for Elastic, and working on getting Influx Partner status, so I'm more than happy to talk about either of them :)
[09:19:13]<karna[m]>Nice one, I'll check them out :) need to check with my team how frequently we intend to be posting sensor data to work out whether a MySQL solution is sufficient for now or not. It's very much a proof of concept piece of work atm so it's just the one unit we're getting data from
[09:23:14]<MockingbirdConsu>No worries. Also, depending on where the public space is and how far away you are from the access point, it might be worth considering LoRaWAN - it'll cost you about £300GBP to buy a gateway, and then you buy the sensors like http://www.nke-watteco.com/product/lora-temperature-humidity-sensor/ or build your own using arduino-style devices, but it's got a range of up to 1km in buildings, 3km in urban areas, and 20km
[09:23:15]<MockingbirdConsu>in rural environments
[09:23:27]<MockingbirdConsu>(it's entirely possible that it's also complete overkill for your use case ;) )
[09:27:46]<MockingbirdConsu>FWIW, I just created https://www.drupal.org/project/farm/issues/3053674 to look at the way we deal with metrics in FarmOS, but as I don't really know PHP I'd appreciate some help!
[11:06:02]<ludwa6>G’day room. Nice surprise in my inbox this morning, from @jgaehring -thanks for the invite to test farmOS Field Kit, mate (and thanks @mstenta for the quick response to my request in last nite’s Google Hangout). Installed the app on my iPhone, entered a new log entry, clicked to sync… And it appears via web interface to my account at Farmier, so that’s a fair bit of coolness right there. Lovin’ it! :-)
[11:07:37]<mstenta[m]>> so that’s a fair bit of coolness right there. Lovin’ it! :-)
[11:07:38]<mstenta[m]>YES!
[11:07:54]<mstenta[m]>all credit goes to jgaehring and @alexasbeet for that coolness ;-)
[11:08:05]<mstenta[m]>they made it happen!
[11:08:17]<jgaehring[m]>ludwa6: that's great, glad you're finding it useful!
[11:10:27]<ludwa6>Yep, that’s an important bit of utilty right there: to capture & sync log entries in field. Usability could be improved, but of course -it’s early days. Have you got a list of function points or features you’d like feedback on?
[11:20:49]<mstenta[m]>ludwa6: if you're interested, take a look through some of the issues in Github: https://github.com/farmOS/farmOS-client/issues
[11:20:54]<mstenta[m]>I think jgaehring
[11:21:21]<mstenta[m]>.. is hoping to "feature freeze" (meaning no new features) until some of the behind-the-scenes things are stabilized
[11:21:38]<mstenta[m]>and a v1.0.0 is released, and made officially available on app stores (not in beta/test-flight)
[11:22:07]<mstenta[m]>But feel free to add ideas to the issue queue, for after that's done
[11:22:09]<ludwa6>yeah -my early (i.e. 1st 10 min :-) impression is: refinement is needed, before you add features.
[11:22:11]<mstenta[m]>There's always lots to do! :-)
[11:22:43]<mstenta[m]>And ideas are always welcome
[11:23:03]<mstenta[m]>No gaurantees that they'll happen, but that's the nature of open source dev... :-)
[11:23:29]<mstenta[m]>Working with limited time and resources
[11:23:38]<ludwa6>ok, so: about this issue tracker at GitHub: is this just for the Field Kit? iOS and Android versions both?
[11:23:48]<mstenta[m]>Yup - all of those
[11:24:15]<mstenta[m]>farmOS-client is a JavaScript app, which we wrap into a native app (for Android/iOS) using Cordova
[11:24:33]<mstenta[m]>called "farmOS Field Kit"
[11:25:08]<mstenta[m]>In the future... I'd like to see farmOS-client become the default offline-first UI for farmOS in general, though... and what we have now becomes more of the "advanced" UI for data management, searching, etc
[11:25:25]<mstenta[m]>So it serves both short-term and long-term goals right now
[11:28:47]<ludwa6>OK. I’m struggling a bit right now to know how to use this thing; it’s not perfectly intuitive. Like, first off: it default names the log entry (an observation or an activity) the current date/time...
[11:29:40]<ludwa6>… Which is good default logic, i guess… But the two log entries i have just created where (1) a retroactive observation from yesterday; and (2) a planned activity for tomorrow.
[11:30:14]<mstenta[m]>Yea, it's just default logic. You can edit the default name.
[11:30:52]<mstenta[m]>Open to alternative ideas
[11:31:34]<ludwa6>Yes, but… Since the first field is freeform text, and the 2nd field is a structured date entry widget, i guessed that i should stick to the default for log entry name, and use the structured widget for either retroactive entry or planned entry, as the case may be.
[11:31:35]<mstenta[m]>farmOS has similar default log name logic... the difference is that when you open a new log form, the name field is blank. And it gets an automatic name only if you leave it blank.
[11:32:06]<mstenta[m]>So maybe the field kit log form should work similary
[11:32:06]<ludwa6>It makes as much sense as anything, mstenta, and so i’m gonna stick with that default, is my inclination.
[11:33:14]<ludwa6>But there’s a qualitative difference between log entries and planned activities, IMHO. That is not reflected in the mobile app, tho the drupal interface has the “Done” button at bottom to let you know the status.
[11:38:18]<mstenta[m]>In the mobile app, there is a "Done" toggle at the top of the log edit form
[11:38:27]<mstenta[m]>And icons in the "My Logs" list
[11:38:43]<ludwa6>Now i see that there is a “Done” button in the mobile app… But i’m not clear if that means the planned activity is done, or just the entry in the form field.
[11:38:57]<ludwa6>See what i mean?
[11:39:23]<mstenta[m]>Maybe this would clarify?
[11:39:24]<mstenta[m]>https://farmos.org/guide/logs/#planning-ahead
[11:40:16]<mstenta[m]>In the database, there is no difference between a planned event and a completed event, apart from the date and "done" status
[11:40:17]<ludwa6>thanks, i’ve read that mstenta, but it does not clarify the confusion in mobile app UI
[11:40:31]<mstenta[m]>Maybe we need to make that more clear?
[11:40:45]<ludwa6>It seems in this iOS app that, to get an entry in a form field to update, i have to click “Done”
[11:41:21]<ludwa6>But then i see that it shows up in the web app as a finished activity, when really it’s a planned activity.
[11:42:28]<ludwa6>This feels to me like a significant usability issue in the mobile app.
[11:42:40]<mstenta[m]>> It seems in this iOS app that, to get an entry in a form field to update, i have to click “Done”
[11:42:41]<mstenta[m]>Not sure I know what you mean by this...
[11:43:00]<mstenta[m]>Specifically: "to get an entry in a form field to update"
[11:43:10]<mstenta[m]>Do you mean on the server? Or just saving changes locally in the app?
[11:43:21]<ludwa6>have you got an iOS device to see what i mean in the UI, mstenta?
[11:43:38]<mstenta[m]>No, I have Android (but should be identical, unless there's a bug)
[11:44:12]<ludwa6>OK. I just created an activity, which is: grafting 100 trees in my carob orchard this coming Saturday.
[11:44:33]<mstenta[m]>You should be able to make changes to any field in the log form, and click the back arrow to get back to "My logs", then click that log again and the changes are still there... is that not working for you?
[11:45:39]<ludwa6>ACTION testing...
[11:46:29]<ludwa6>I got two versions now, both of which report “error in syncing”
[11:47:45]<ludwa6>yet they both appear in the web interface, so evidently they did sync.
[11:50:34]<mstenta[m]>huh
[11:50:45]<mstenta[m]>time to file a bug report :-)
[11:50:54]<ludwa6>now i just tried to create a new log event, and even that blank entry (which has “Done” selected by default) says at the top in a purple band “406 erro whuile syncing “5/9/2019 - 4:34:39 PM”: Not Acceptable””
[11:52:05]<ludwa6>If you say so -i’ll try to recreate and document.
[11:53:19]<ludwa6>huh - i see an issue somebody else filed that sounds similar, only it involves a photo: CFWHISPERER commented 10 days ago
[11:53:20]<ludwa6>We are testing out the photo upload from the farmOS mobile app, trying to add a planting, taking a photo from the phone, then trying to sync we get this error..."406 error syncing 4/29/2019 - 8:41:27 AM 406 Not Acceptable Unknown data property equipment"
[11:54:46]<ludwa6>This reminds me of another issue: This app appears to have no connection to Areas… So do i presume correctly that it relies on the GPS co-ordinates (presuming that you are making entry in-sitiu) to localize it to a particular area?
[11:56:36]<mstenta[m]>ludwa6: thanks yea add your details to github... i need to run in a minute...
[11:56:44]<mstenta[m]>re: areas - you can select from a list of areas
[11:56:54]<mstenta[m]>or, it can also attempt to figure out what area you're in based on GPS
[11:57:03]<ludwa6>ok -will keep trying on it.
[11:57:09]<mstenta[m]>although that really varies based on how accurate your phone's GPS is
[11:57:16]<mstenta[m]>most phones are not very accurate
[12:34:44]<karna[m]>Mockingbird Consulting: have access to a LoRaWAN gateway already :) we've modified the ESP32 to include a LoRa chip so we might well make use of this
[12:48:30]<MockingbirdConsu><karna[m] "Mockingbird Consulting: have acc"> Cool, well, if you want a data store, as long as you're happy for the data to be public I'd be happy to host the proof of concept on https://shared.ourdata.network as well as you sending it to your farmos installation?
[13:09:49]* ludwa6 has quit (Quit: ludwa6)
[13:16:58]<karna[m]>Mockingbird Consulting: that could work. I'll hopefully chat with my team soon and see what they reckon. there seems to be a preference for the project to use Wi-Fi rather than LoRaWAN. I need to get clear on why that is
[13:36:50]<MockingbirdConsu><karna[m] "Mockingbird Consulting: that cou"> Sure, no worries, let me know. Either way, I can give you a script that should get the data into FarmOS and InfluxDB (which is what we use on the backend of that grafana installation) at the same time :)
[13:45:31]<karna[m]>Nice one. Checking out an Andreas Speiss vid on use of InfluxDB and Grafana right now. Looks like 'The Business' :)
[19:18:22]* JustTB1 has joined #farmos
[19:18:27]* JustTB has quit (Quit: Leaving.)