IRC logs for #farmOS, 2021-09-10 (GMT)

2021-09-09
2021-09-11
TimeNickMessage
[21:19:10]* jonasbits has quit (Ping timeout: 240 seconds)
[01:14:06]* jonasbits has joined #farmos
[01:56:17]* farmBOT has joined #farmos
[11:14:41]* DanielAshcraft[m has joined #farmos
[11:16:43]<DanielAshcraft[m>Hello everyone! The company i cofounded centers around open sourcing sensors and iot devices, i am going through and picking a handful of... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/d95408c94a...)
[11:20:53]<mstenta[m]>1. yes!
[11:20:53]<mstenta[m]>2. this depends on who is hosting farmOS and how they have it configured (to allow http or not), but generally speaking it *should* always be https (and Farmier SaaS hosting is 100% HTTPS fwiw)
[11:20:53]<mstenta[m]>3. There has been some discussion re: MQTT yes! https://farmos.discourse.group/search?q=mqtt
[11:21:12]<mstenta[m]>the HTTPS question is a good one, though, and one that some friends and I have talked a lot about
[11:21:23]<mstenta[m]>the idea if a "gateway" device seems to be the best option
[11:21:34]<mstenta[m]>where all sensors send to the gateway, and the gateway forwards to farmOS
[11:21:41]<mstenta[m]>and it can be beefier, like a Raspberry Pi or something
[11:21:42]<DanielAshcraft[m>Yeah we can do https, but depending on cert response size, we have to throttle our normally 500-800ms sensor push to around 8 seconds on average
[11:22:32]<mstenta[m]>yea, we've done some stuff with Lora sensors too... where they aren't connected to the internet at all... but push to a gateway that is
[11:22:38]<mstenta[m]>that feels like the most scalable approach
[11:22:46]<mstenta[m]>(but i'm not a hardware expert) :-)
[11:23:22]<mstenta[m]>also... if you are considering integration, definitely go for farmOS 2.x, not 1.x
[11:23:25]<DanielAshcraft[m>Yeah we have plans for an intermediate device as a controller. We're trying to avoid it, because it's mostly unnecessary (depends on who you ask).
[11:23:25]<DanielAshcraft[m>But the esp32 base we're working with can port forward and mesh, so the idea of adding another device to work around https is a headache haha
[11:23:30]<mstenta[m]>1.x is going to be deprecated soon
[11:23:43]<mstenta[m]>and 2.x has a whole new and improved system for managing "data streams"
[11:24:28]<mstenta[m]>yea understood... my friend ran into the https issue with esp8266, but i think he actually had success with esp32
[11:24:42]<mstenta[m]>(again, i'm speaking outside my expertise here)
[11:24:54]<mstenta[m]>(just recalling old conversations)
[11:25:19]<DanielAshcraft[m>100% i gotcha. Mqtt seems like it might be a good fit, it's what i've used to integrate with Home Assistant and it's worked wonderfully thus far.
[11:25:48]<mstenta[m]>My understanding of Mqtt is that it requires another service to be running alongside farmOS
[11:25:59]<mstenta[m]>farmOS is basically just Apache, so http server only
[11:26:06]<DanielAshcraft[m>Correct, hassio uses a mosquito broker i believe
[11:26:20]<mstenta[m]>but it's dockerized, so you could run an mqtt broker alongside it i assume
[11:27:09]<mstenta[m]>Daniel Ashcraft: we have weekly farmOS dev calls if you want to hop on one - can give you an intro to some things in farmOS if that would be useful
[11:27:20]<mstenta[m]>thursdays at noon eastern
[11:27:23]<DanielAshcraft[m>Does farmio have a plugin based architecture we could potentially extend?
[11:27:28]<mstenta[m]>https://meet.jit.si/farmos-dev
[11:27:44]<DanielAshcraft[m>I might be able to meet that call, i'll need to check my schedule and double check
[11:27:44]<mstenta[m]>yes! you can write modules that extend it
[11:28:35]<mstenta[m]>farmOS is a Drupal distribution, so they would basically be Drupal modules
[11:29:04]<mstenta[m]>we have some 2.x docs developing here: https://docs.farmos.org/development/module/
[11:29:15]<DanielAshcraft[m>Sweet, i'm not a python person, but i could def brush up and try to get some open source commitment. We're both on open-collective
[11:29:15]<DanielAshcraft[m>so might be able to get some crossover from SPEC.
[11:29:29]<mstenta[m]>PHP actually
[11:29:43]<DanielAshcraft[m>Ooof
[11:29:49]<mstenta[m]>(the farmOS Aggregator is Python., but that's different)
[11:30:00]<DanielAshcraft[m>gotcha gotcha
[11:30:04]<mstenta[m]>haha like I said, it's Drupal
[11:30:48]<DanielAshcraft[m>i mentally switch drupal with django, i haven't written a line of php in 7 years lol
[11:31:13]<mstenta[m]>easy mixup :-)
[11:31:30]<mstenta[m]>i'm trying to get a link you can use to try out 2.x...
[11:31:40]<mstenta[m]>but if you have docker you can also just spin up a quick dev environment
[11:31:57]<mstenta[m]>https://docs.farmos.org/development/environment/
[11:32:35]<mstenta[m]>paul121: is there an easy way to spin up a tugboat of latest 2.x outside of issue queues?
[11:32:51]<DanielAshcraft[m>Good to go on docker, i might have to hit some friends up to develop a mqtt integration through drupal, but it can likely be done.
[11:32:51]<DanielAshcraft[m>Interface for passing in mqtt creds, topic construction and the corresponding internal api hooks.
[11:34:13]<mstenta[m]>Yea... or I wonder: would it make sense to have a separate Dockerized service that receives data via MQTT and then just reformats it into an HTTP API request for farmOS?
[11:34:32]<mstenta[m]>then you could just use existing API and wouldn't need to build anything extra in farmOS/Drupal
[11:35:20]<DanielAshcraft[m>That's actually doable and much more within my skillset
[11:35:46]<DanielAshcraft[m>Are there any current sdk's for farmos or api wrappers in various languages?
[11:35:47]<mstenta[m]>cool!
[11:36:15]<mstenta[m]>yes we have a python library and a JS library: https://github.com/farmOS/farmOS.py / https://github.com/farmOS/farmOS.js
[11:37:19]<DanielAshcraft[m>Excellent, i see oauth2, is there an option for a long lived token?
[11:37:24]<mstenta[m]>check the forum link i posted above too... might be some good ideas in there or things people have already done
[11:37:27]<mstenta[m]>https://farmos.discourse.group/search?q=mqtt
[11:37:51]<mstenta[m]>if you're self-hosting you can customize the token lifespan
[11:38:11]<mstenta[m]>but might be fragile to depend on others doing that
[11:38:53]<mstenta[m]>there are other authorization flows available too besides refresh token
[11:39:14]<mstenta[m]>i think paul121 experimented with JWT
[11:39:35]<mstenta[m]>and there's the username/password authorization too, with security considerations of course
[11:40:03]<mstenta[m]>but you could create a dedicated user for receiving sensor data, and block them if need be
[11:40:23]<mstenta[m]>(lots of considerations) :-)
[11:40:26]<DanielAshcraft[m>100%
[12:26:27]<paul121[m]><mstenta[m]> "paul121: is there an easy way to..." <- When you create a tugboat account you would connect it to your own fork of farmOS
[12:28:36]<paul121[m]><mstenta[m]> "i think paul121 experimented..." <- actually, all of our 2.x oauth uses JWT - that's more of a "lower level" tech
[12:28:50]<paul121[m]>all of the OAuth tokens are JWT!
[12:29:27]<paul121[m]>OAuth doesn't have a good solution for long lived tokens :-/ (not really what it is designed for)
[12:30:05]<paul121[m]>BUT also worth nothing that our farmOS sensors (data streams in 2.x) use a public/private key for authentication
[12:33:07]<paul121[m]>Daniel Ashcraft: I've done a little bit of preliminary work integrating some sensors & third party data apis with 2.x farmOS data streams
[12:34:08]<paul121[m]>I had explored trying to tie farmOS directly to MQTT in the past, but there definitely needs to be something between the two
[12:35:57]<paul121[m]>here is my latest thinking: dump all sensor data into a separate Influxdb time series database, and make 1 integration with farmOS to Influxdb
[12:38:46]<paul121[m]>an early start on this here: https://github.com/Vital-Agronomics/farm_influxdb
[12:39:46]<mstenta[m]>> BUT also worth nothing that our farmOS sensors (data streams in 2.x) use a public/private key for authentication
[12:39:46]<mstenta[m]>Oh right! I forgot! 😅
[12:40:15]<mstenta[m]>We did that for this very reason
[12:40:39]<mstenta[m]>And to be able to revoke individual sensor push access if necessary
[12:40:55]<mstenta[m]>Not tied to users
[12:42:00]<paul121[m]>what really makes Influxdb so cool is actually a separate service called Telegraf: https://github.com/influxdata/telegraf
[12:42:00]<paul121[m]>This is what I would use to pull/push data to Influxdb....but Telegraf can be used separate from Influxdb! I think it could be fairly trivial to use it as an MQTT->HTTP POST intermediary
[12:43:18]<paul121[m]>so you could do sensor -> MQTT broker -> telegraf MQTT input -> telegraf HTTP output -> farmOS
[12:44:08]<paul121[m]>I'd like to try that out myself, but really see some benefits of using Influxdb for storage + querying so I'm investing my efforts there :-)
[19:30:07]* willinux has joined #farmos
[19:41:23]* willinux has left #farmos (Leaving)