Status REST API

[loranger]

Hi,

I struggle with the SM2 REST API.

I tried to follow @parachvte’s explanations, tried to digg a little bit deepper inside Luban’s implementation but still remains stuck:

I can connect remotely to my SM2, and get a brand new token after clicking on the (in)famous confirmation dialog

But as soon as I try to get any other information, I’m locked outside

Here, I use insomnia. _.ip, _.port and _.version are environment variables, corresponding to my SM2. The token is automatically retrieved from the previous Connect request (which is automaticaly triggered, if no value can be fetched).

I tried passing data in json format, multipart or url but none works.

I also tried to re-use the previous confirmed token in Connect request, but I got a new confimration dialog and get a new token back

Did someone figured out how to work with the SM2 API ?
Do you have any clue for me ?

[ElloryJaye]

I’d probably try hitting it from the other end at this point: use Wireshark or similar to capture the network traffic between Luban and the Snapmaker, and then play one-of-these-things-is-not-like-the-other with the results. (Sorry I can’t suggest anything more immediately useful.)

[CNC-Maker]

Try using Fiddler to track the requests and responses from Luban. Worse case, you may need to set it up in proxy mode, but I don’t think that you will need to. Pay particular attention to the headers, as it might be using bearer tokens, or something similar.

[loranger]

Thank you so much for your support
I finally managed to get wireshark working (unfortunately Fiddler, Proxyman or Charles cannot track HTTP clients such as insomnia, or Luban)

But even if I use the exact same headers, it still does not work

I really don’t understand…

[ElloryJaye]

Huh. Odd. Could the issue be that it closes the connection unless it receives a heartbeat with a fairly short interval? Clutching at straws here. Does either message have a body?

[CNC-Maker]

The request in the bottom photo is not the same at the request in Wireshark. The request in Wireshark has 2 entries in the QueryString, a key-value pair for token, followed by a decimal magic number. I would guess that the magic number is Epoch time for the current data/time, but that’s only a guess as I haven’t tried to convert it.

Your QueryString is in a different format, and the magic number is probably what is failing. The “=” (equals) after your magic number may, or may not be an issue. I would try replicating the QueryString exactly as you see it in Wireshark, before trying to make changes to it.

[loranger]

@CNC-Maker, it looks like this number is a kind of random hash (or maybe a timestamp) forcing the SM2’s web server to unvalidate every previous query and avoiding cache effects

@ElloryJaye seems to be right : The token TTL is very short. If I force the Connect request instead of re-using the previous value if exists, it works. I can even use an existing already confirmed token when posting the Connect request, but I have to hurry cause it doesn’t last ten seconds (7seconds, if my tests are corrects). I’d better have to find the real heartbeat interval… Somewhere in the Luban repository…

I would really love a public api documentation instead, even a draft one
ping @parachvte @Alan @Snapmaker-Support (sorry for the noise, I had to try…)

[brent113]

@loranger

(unfortunately Fiddler … cannot track HTTP clients such as insomnia, or Luban)

I’ve done this before, although it’s been quite some time. You may need to create a proxy like so:

No traffic seen from VS 2017 HTTP Client app in Fiddler ? in Fiddler |...

I recall fiddler has a GUI for creating proxies automatically. Also works for HTTPS decoding.

I agree it looks like the request string is different than the original:

May be a different behavior with status?var=param&var2=param2. Possible a home-brewed parser may parse ?1234=&token incorrectly, although technically the same when parsed correctly.

Also there’s essentially no robust security on this. If you have sniffed the Luban token you can reuse that - it’s not authenticated to any particular IP or application. You definitely should not need to hit /connect ever after you have a token.

[loranger]

On the contrary, it seems necessary to keep the token alive by calling frenquently /status or /connect (with the previous token, of course)

123456789 was an attempt to give /status an integer hash, like I saw within wireshark, but it was not very useful

[jane-ross]

[loranger]

Thank you @jane-ross for this silent contribution.
You may have read the previous posts and the evolution since my initial concern, did you found the token ttl ? Have you tried this status query within the few seconds after a new connect ?

[EddieHartman]

@loranger I wrote the snapmaker status app on the android app store.

I had the same initial issue as you. The token initially stays alive a very short time. I called it in a loop until the user confirms the connection on the machine.

Once that’s done, the token you get back essentially never expires (until you update firmware I think). My app keeps that token and re-uses it for subsequent requests so that the user doesn’t need to keep confirming the connection to the machine and it works fine.

[EddieHartman]

Also it’s totally a matter of personal preference, but I’d highly recommend looking into https://hoppscotch.io/

[profhenning]

I’m in the process of interfacing my SnapMaker with my home automation system (FHEM, quite large user community in Germany). For 3D prints this works very nicely, because there is already a FHEM module connecting to OctoPrint. However, for Laser & CNC this is missing so far. Will keep the thread updated on that

Regards

pah

[profhenning]

OK, I made some progress

The software I use - FHEM - has a module called HTTPMOD that allows a quite fine tuned connection to any physical device offering an interface via http, be it REST or just plain web pages.

The first thing I do is to submit a POST request to http://IP-Address:8080/api/v1/connect?token=$sid
where “$sid” is replaced by a previous token. The logical device is named SnapMaker.TEST, hence in my home system I can either type “set SnapMaker.TEST connect”, or push the appropriate button.

The token I have included into this POST request apparently allows to reconnect without the unnecessary confirmation question at the touchscreen.

The “connect” command receives a new token from the SnapMaker, which is again placed into the variable $sid. (Footnote: The whole FHEM system is programmed in Perl).

When the connection event is registered, a loop starts which calls
get SnapMaker.TEST enclosure,
get SnapMaker.TEST status
every 5 seconds. As long as I do this, the connection remains stable and I get regular updates.

These two FHEM commands issue GET requests to the two URL
http://IP-Address:8080/api/v1/enclosure?token=$sid
http://IP-Address:8080/api/v1/status?token=$sid

When I stop the loop, the connection is going down, and the HTTP body received is just “The Machine is not connected yet.” By issueing a “set SnapMaker.TEST connect” I reconnect properly, and the data keeps arriving again.

In the next step (give me some days…) I will make this a little more intelligent, like e.g. binding the loop to the power switch of the SnapMaker (to be precise: This is done by a Shelly WLAN-operated switch), implementing an automatic reconnect etc.

Also, I have to integrate this with the Octoprint module in FHEM, such that I do not need several FHEM devices for one machine. But the door is open now.

[nweolu]

Id recommend you search “heartbeat” at the GitHub repo for controller. I think that’s what they called it. Also some info about API calls in the code and comments there.