[Farmware] Did you stop supporting the local webserver on port 27347?

[muenchris]

Expected Behavior

Connect to the local webserver with REST should give access as documented here: https://hexdocs.pm/farmbot/Farmbot.BotState.Transport.HTTP.html

Actual Behavior

Webserver on PI refuse connection

Steps to Reproduce

Try a REST call with a valid token in the Bearer to http://farmbotiP:27347/api/vi1/bot/state"

[RickCarlino]

@muenchris This was permanently removed from FBOS starting with v8. We recommend using AMQP or FarmBotJS for streaming state updates in v8.

[muenchris]

do these two APIs work locally or do I have to install the whole FB Cloud infrastructure onsite? The beauty of the previous APIs were that I can run emergency code locally when the connection to the cloud is unreliable or down.

[RickCarlino]

@muenchris FarmBotJS and AMQP require a connection to the home server (usually my.farm.bot unless you are self hosting). If you wish to self host your infrastructure on a LAN for increased connectivity, the instructions can be found here. Please note that the only OS distribution we officially support is Ubuntu and the only supported hardware architecture is x86_64 (ARM is not supported).

[muenchris]

Any special version of Ubuntu? Is your farmware no longer using celeryscript? Does that mean all move and water commandos are coming from the cloud? Nothing local anymore?

If so I guess I have to find a way to use my own controller for the bot, I don't want to be dependent on a cloud. Also the data I create is my data - and will not be shared with cloud services that I do not give explicit permission (very similar to PID of the GDPR in Europe). These regulations are not yet very popular in the US ...but they will come once privacy is becoming more of an issue here.

[RickCarlino]

Any special version of Ubuntu?

They were last tested and working on a fresh install of Ubuntu 18.10

Is your farmware no longer using celeryscript?

It is still using CeleryScript, but over Unix sockets. It is best to use a wrapper like FarmBot Tools. This will allow compatibility for future versions if the underlyng platform must change.

Does that mean all move and water commandos are coming from the cloud? Nothing local anymore?

Farmware still exists in FBOS v9. The underlying APIs have changed, though.

I don't want to be dependent on a cloud. Also the data I create is my data

We agree entirely. You don't need to use our servers if you don't want to. Really- it's OK! That's why we always have and always will give users the option to self-host their devices. It's also why we leave our entire source code available for inspection and modification with a permissive Open Source license (something that many cloud and IoT companies are unwilling to do for their customers). The software you see on Github is the same software that is running in the cloud.

The only caveat to the self-hosting route is that support is provided on a best-effort basis. FarmBot only has two full time developers, so we cannot spend too much of our time helping people get setup or training people on Docker and Rails. With that being said, plenty of folks are self-hosting their devices just fine and we will always provide this as an option to our customers.

[muenchris]

Thank you for your excellent support and answers. I have worked many years at Siemens and with KUKA and would love to experiment with the Farmbot. Its a great test case for our industrial IoT Solution but its fully based on .NET and requires at least some way to get to the linux on the PI. Unix Sockets is something we are using on other projects therefore I might go this route next (running my IoT solution side by side on the PI with your and communicate via Unix Sockets - if this is documented somewhere?)

Again thanks and keep up the good work.

[RickCarlino]

@muenchris Unlike TCP sockets, Unix sockets are not accessible over a network and they should be considered an internal API (they are an interprocess communication tool provided by the OS). I would highly recommend against directly interacting with the Unix sockets because if you base your entire application around a private API, it may break later on. If you use Farmware tools or FarmBotJS, it is easier for us to provide clean upgrades, keeping the same external API but possibly changing underlying infrastructure.

The reality with on device software is that it has eaten up huge chunks of our developer hours (sometimes entire work weeks). I only have evidence of 8 other people actually authoring farmware. This Github issue here is a good example. We removed it over a year ago and you are the first person to even notice. We've spent countless weeks implementing these features, hunting bugs and making compromises elsewhere in the system to allow for on-device scripting support. I can't say it makes sense from a business perspective to continue encouraging people to write on-device software, at least with the way it is currently architected.

Conversely, telling people to use wrappers like FarmBotJS does make sense because it is the tool that we use internally to build things like the Web App. The Web App is essentially just a GUI front end to FarmBotJS and if you write an application on top of it, you can be highly certain that FarmBotJS will continue to work as intended (it's what the Web App uses, after all).

Moving forward, we are thinking that the Farmware v3 library may be substantially different from the current system that has been plagued with problems and poorly adopted by third-party developers. I had an interesting conversation with @whitecapso in the forum where they propose some ideas about what a next-gen farmware system would look like, along with comparisons to some other platforms that do similar things.

In v3 of Farmware, I could see us transitioning to an integrated IDE (such as Monaco) in the web app that gives users a choice of a few popular languages that are well suited to embedded systems (such as MicroPython or Lua). The idea behind the integrated editor would be that you do not need to host your farmware code externally or on Github, and you do not need to install an IDE or runtime on your host device.

This would be a huge step in a different direction than the current farmware system and I am skeptical of the usefulness of providing an upgrade path for an API that has only been used by 9 people (keeping in mind we have shipped literally thousands of FarmBots at this point). It would be better to give the v3 system a clean slate and not drag legacy problems into the new system.

I welcome your feedback and ideas on this, although I think it may be better to move the conversation over to the forum, since Github issues are better suited for troubleshooting and your main questions have been answered. It would also be good to hear more feedback from the other folks who have written third party integrations, since we want to build a solution that is useful for third party development.

[muenchris]

I do understand your point. My problem is that I am in a rural environment with very spotty internet. The risk that my crop is not watered because of "internet issues" is not generating high confidence. Down the road I envision fields of farmbots - completely autonomous - only "monitoring" via the cloud but all the farmware running even if the cloud is down. If this should scale, the "on premise" solutions needs to be easier to setup as it is right now. People with interest in farming are not necessarily robotic-engineers.

If the next generation Farmware goes towards this goal I am all in. If not, how can I help making this happen?

[whitecapsO]

Hi guys, please forgive me for jumping in.

I read the conversation and had some thoughts on future architectures for folks with poor internet connectivity. The easyist solution is to have the web app run on a local web server with the option of ethernet or local wifi network connectivity to the FBOS on the Pi. This would require an easier way to deploy, configure and update the webapp and associated libraries for non technical folks.

It would be nice if the webapp ran on the Pi and you could access that over the FB wifi (similar to how the config app runs) but I'm not sure if the Pi is powerful enough to run both the FBOS and the WebApp. The Pi could then be shipped with all the software installed.

Both of these solutions will require a new upgrade process and no doubt create maintenance headaches that come with local deployments. So a use at your own risk / best efforts etc approach may be initially needed.

[RickCarlino]

Dealing with Netowrk Partitions

The risk that my crop is not watered because of "internet issues" is not generating high confidence.

This issue has been fixed in 1.5 devices. Adding an RTC chip to your device will prevent farm events from failing to execute. It is possible to upgrade older devices. We've intentionally cut the internet off of devices in the warehouse for days on end and things are OK as long as the RTC chip has a good battery. The problem before was that FarmBot's only means of keeping time was via an NTP server, which led to clock skew (failed farm events, invalid SSL certs, etc..).

We've still got a way to go, but the addition of RTC support has had a great effect on reducing failure during network partitions.

FarmBot Product Road Map

I envision fields of farmbots - completely autonomous

We're not focused on that use case. Although we will continue to design the software to handle network partitions, we're still focused on small to large automated gardens at home and in schools where there is a decent internet connection. We plan to introduce "workspaces" where multiple users control multiple devices, but again, this is from the perspective of a home/school user operating at a garden scale.

Self-Hosting as a Secondary Focus at FarmBot

... the "on premise" solutions needs to be easier to setup.

This would require an easier way to deploy, configure and update the webapp and associated libraries for non technical folks.

Before I respond to this, I would like to re-state what I said in a previous message (in case anyone is joining the conversation late, finding it off of Google, etc...). FarmBot will always allow customers to self host their devices. The web server code will ALWAYS be open source. With that being said, cloud users are our main priority and the device is architected with that assumption in mind. Let me explain this with more detail, since the proposal for an autonomous, 100% off-grid FarmBot comes up pretty often in discussions.

When we founded FarmBot, Inc. we had a vision of creating a consumer-facing robot that would gain mainstream adoption, not just among developers, but also non-technical people. I don't think self-hosting has a place in the mainstream and I don't think it ever has or ever will be a solution for non-technical folks. With the understanding that FarmBot aspires to be a consumer product rather than a product for "power users", I don't see a future in self-hosting as the first option for users. We will always allow self-hosting for the power users or people who do not want us to store their data, but it's never going to be our main focus. If a motivated developer wishes to create a more streamlined "FarmBot Easy Installer", I would absolutely support their efforts, but we can't provide development support on such a project because again, our main focus is non-technical users that will be on the official server provided at my.farm.bot. That's not to say we don't support sellf-hosted users, it just means that the majority of our time and effort will be spent where the majority of our customers are, which is at my.farm.bot.

Consider the following example. Given a large list of self-hosted software packages, it is nearly impossible to come up with an example of one being succesfully deployed by a non-technical user, even among the ones that have amazingly simple installers. I highly doubt a non-technical family member (especially a "digital non-native") would be able to successfully / safely deploy any of them. Running a server has serious security implications that end-users are not aware of. This is one of the reasons that projects like WordPress have (I think unfairly) gained a reputation as "insecure".

Alternatives to Self-Hosting

If the next generation Farmware goes towards this goal I am all in. If not, how can I help making this happen?

The most helpful thing for us would be to hear about how you would plan to use the Farmware and what sort of features would make it useful to you. . We are still in the planning phase at this point and having input from users has been extremely helpful as we plan. Having the integrated editor will be a big win for users since it eliminates the need to host Farmware externally on sites like Github and is one less whitelist exception that enterprise / school users need to add to their firewall.

Furthermore, if someone in the community wishes to create a self-hosted installer to simplify the self-hosting process, we would also be happy to answer questions.

What sort of things would you do with such a solution?