Get information over API - home assistant dashboard

Hello CNC friends,

I would like to connect my 1F X50 to my domotic controller, home-assistant, and get some information as :

  • What program are currently working on
  • Time left or ETA
  • Emergency Stop

Actually the only thing i’ve got working is the video feedback.

I try to look on the API source code of onefinty and buildbotics and not found anything interresting

Thanks for your help
Regards

1 Like

Hello Wanoo - which controller are you referring to? The Buildbotics or Masso? I’m not sure either as an open API to retrieve the information, but you should be able to put one together for the Buildbotics since it’s based on a raspberry pi.

-Tom

Hello i’ve got the Buildbotics (The Masso look awesome, but i buy my 1F 2 years Ago sadly).

I look on the source code to try to found some “api call” but so far i’ve got no clue

API list from 1F firmware: https://github.com/OneFinityCNC/onefinity-firmware/blob/2baae7965a96795988ceadf4079aa76a1642040f/src/py/bbctrl/Web.py#L632

Api list from Buildbotics firmware: https://github.com/buildbotics/bbctrl-firmware/blob/3db09c84b4c6838bd01bc2ed92f288b3157644fd/src/py/bbctrl/Web.py#L599

it’s seem that Buildbotics have a call “/api/state(/.*)” but not the 1F.

Is anyone had interact with this API ?

PS: @cyberreefguru love your Youtube Channel, thx for your work.

1 Like

@wanoo

I’m probably of limited help here but what I can see is this is a routes file, like what a web client would request off to the backend service. In this case, your web browser would be making a request with that path (a route) in the browser URI. In the parenthesis, it appears that a path is provided here (/.*)?. It looks like a regex where the first character match is a / (this is what makes me think it’s parsed like a path). The following characters .* means a greedy match. So any and all characters after a / should match. The ? usually means that passing a value there is optional (as in, may or may not be provided).

Example. If a uri base looked like this https://my.awesome.server/
then the route of api/state(/.*)? would look like this in a browser:

https://my.awesome.server/api/state/spindle
(where I’m just making up the word spindle).

The question mark means that you ‘might’ technically work like this too:
https://my.awesome.server/api/state

Looking at the screenshots, I can only tell you the following:

  1. If that code is in the originall BBC codebase and not the 1F, you won’t get a response when putting the route part /api/state into the browser’s uri.
  2. To really know how this is used, you’ll need to look at the interface file for how the back-end uses this route. Typically there is a description and if needed, you can drill deeper from the interface into the implementation and checkout how the back end is switching on the variable path to return a response.

I’m betting that this method probably switches on quite a few response objects so it will be fun to read.

If by any means you already understood any of this, my apologies. I hope that you’d just let the message stand for others that are curious.

Good luck.

Thanks for your reply, i already understand the route concept and the RegEx, i’m a senior linux dev, but it will be used for other person for sure.

Right now i found zero docs on this API so it’s kind of a reverse engineering to found what do what, and sadly the “STATE” route is not available on 1F firmware.

I will continue to try all the API call and see what do what i try to out put a kind of API manual, if any of you have information I really will appreciate

PS: the BugReport will freeze your cnc jobs untils the bugReport are send do not freack out like i do :crazy_face:

1 Like

@wanoo

Silly question, but you’re probably right at home in this area. Have you considered doing a git blame and then cherry picking the commits into a local branch? It might be a little work to get it merged into a branch that is forked off of 1f. You’d probably be annoyed with some toolchain setup but you could technically pull in all of those related commits and run a half-baked 1F branch (Franken-bot !).

I know, I know… You’re the support guy at that point. But keep the latest 1F firmware handy I suppose. Maybe this is just not worth it for you. Dunno.

Glad you’re a Dev. Thanks for being cordial when you already understood all of the fancy stuff.

That is an excellente sugestion, and it will fairlly “easy” to do with Git, but it will have to be my last resort if i cannot implement the 1F API.

1F dev should have theire reason to update the API this way and fork from Buildbotic OG firmware but i’ll wish they put a documentation.

I will continue my investigation, specially over the web socket

Regards

If you get it working, I’m curious to see the results.

Enjoy!

2 Likes

Hey wanoo,

Onefinity one day for their machine forked some version of the Buildbotics.com controller and as far as I have seen, while the Original Buildbotics.com Controller evolved some way [1], [2], Onefitity showed no attempts to backport things from upstream (like the requested feature “macros”), so I would not wait on anything being backported. They seem to make more own development recently though, as the work on a 2.x for the Raspi 4. (The Original Buildbotics.com system can be built on a Raspi 4). Also the package ‘onefinity-firmware’ is not packed as ‘deb’ so cannot be upgraded (except by overwriting the installation by unpacking the tarball) (and especially can not be downgraded with ‘apt-get install onefinity-firmware=[older_version]’) that’s why they tell the users to overwrite the whole OS on the SD card that often :frowning:

The underlying Raspbian OS on the SD image is a historic OS version from 2017 and you cannot upgrade it simply as you are used to on a Debian system without turning your controller into a brick. This is because already the Original Buildbotics controller is still in large parts in a dirty-hack style. The crucial bbserial.ko module (which implements the communication between the Raspi and the AVR microcontoller) is hardwired to some ancient kernel version and not available as DKMS (at least the last time I had a look at it), so a kernel upgrade will break the system.

Maybe you know how that comes: you develop a really cool thing and at one moment, it works, and then you do other things.

If I would rely on the Buildbotics as your CNC controller and wanted to contribute or expand its capabilities, I would use the original Buildbotics.com system in its most recent version and get in contact with the developer.

2 Likes

Whoa thanks for this historic feedback, i understand better how the code evolve this past few years.

So it will be possible and better to use the OG buildbotics Fw than the one dev by 1F ?

Tomorrow i’ve got jobs to run on the cnc i will look to test some API call

thx again for your feedback

Did you ever get any further? I’d be interested in this too :slight_smile:

Hey Folks - let’s revive this beast!

Made some headway reading machine state by listening on the websocket endpoint.

ws://xxx.xxx.xxx.xxx/websocket

That returns a JSON string per state update. The first reply contains all state variables; subsequent replies contain only updated variables. Here’s an example of the output: websocket-trimmed.json This file contains output from homing, jogging, running gcode, pausing, unpausing, and emergency stopping. Have a peek!

I’m using Node-RED to string this all together. Here’s a basic flow to get you started:

image

It starts a websocket listener, parses the returned JSON string into a JavaScript object, and passes the object to this function:

var machineState = flow.get("machineState");
if ('xx' in msg.payload) {
    machineState = msg.payload.xx;
    flow.set("machineState", machineState);
    msg.payload = machineState;
return msg;
};

Which places the value of “xx” from the JSON packet into a persistent variable, and passes just it on to the next node.

This will drive dust collection and router power, and already controls my timelapse capture rig. Getting data out of the Onefinity controller is now the least complicated part of my automation setup.

As for the other direction - I’ve sent HTTP PUT requests to pause/unpause/estop, and they worked just as expected. But alas, read on for a mystery.


api/override/speed
api/override/feed

These seem like juicy endpoints - adjusting speeds/feeds on the fly could be pretty flippin’ sweet.

When I send a PUT request to IP/override/speed/* or IP/override/feed/* while running a file:

Always:

  • the API sends back a string containing “ok” (like a generic http 200 response)
  • the output of IP/api/log shows that the value of “so” or “fo” has changed
  • no state change is reported by the websocket listener (though “so” and “fo” are sent in the first response, so I think they’re hard-set at 1000 - er - 1 - right now).

Either:

  • nothing happens physically, i.e. no movement speed change (we have a Makita, so not concerned about spindle speed)
  • or, the UI throws an error message and stops the job. Seems to happen with values larger than four digits, but I haven’t tested that rigorously enough to define a range.

I have a couple of suspicions.

  • I suspect the “ok” response may be a default baked into the Tornado package Buildbotics chose to handle API requests.

  • Since there’s no updated value reported to the websocket (from bbctl firmware on AVR), but the updated value does appear in the log (from the Python/rpi side of bbctl), I suspect that the “so” and “fo” set commands aren’t yet implemented in firmware, so they get chucked by the command processor.

Diving into the command processor headers in the AVR code, there’s no command for speed or feed override. It’s a red-herring in the UI. For now. We can cross our fingers that BB is working to implement it, or one of us can buck up and do it ourselves. Yay FOSS!


Thank you to anyone who takes the time to read this. Please let me know if I can be helpful in your quest to automate around your Onefinity or Buildbotics controller!

1 Like