Accessing it locally...
  • So it's hanging out on my network.. I'd like to just talk to it directly.. possible?
    I'd rather it wasn't talking to the world.... I'd rather communicate with it locally and then let me do the talking to the world... doable?
  • 14 Comments sorted by
  • This is more than slightly important for me. I'm in a remote area where internet is sketchy, and I didn't realize that Twine was a "cloud-based" service. This makes it mostly useless for me, I'm afraid - I need a way to talk to it directly (or, more appropriately, for it to talk to one of my servers directly.) Can an API spec be published? I'd love for there to be a set of scripts (PHP?) that would serve as a local mini-version of the Twine service locally on my low-voltage *NIX box. Even if it's really crude (no scripts) with an HTTP PUT of some sort that's fine - let third parties make the interfaces. The catch is the logic to put rules on the boxes, but again, if there's some sort of API (there MUST be) then that would be great to see documented.
  • Yup, a robust API for direct access is essential if these things are going to go anywhere. Handcuffing developers to the Supermechanical website won't grow anything. We need direct access to and interaction with our Twines. Until then, they're sort of proof-of-concept toys.
  • Yeah, I find the Twine sadly not quite here nor there. If I could access it directly, I could write my own rules and make better use of the thing. As it is, the rules don't allow for something as simple as "send me a temperature update every hour".

    I think that a lot of time was spent trying to get extended battery life out of the thing, but in practice this isn't too useful for a device you want to use for full-time monitoring. Even if the battery life were two months, for most monitoring applications I can think of, a service interval of two months is still too short. If you have to rely on having it plugged in, then a battery life ofyour your Internet connection's UPS is all you need.

    Has anyone run wireshark on this thing to see what's going on? If Supermechanical won't tell us...
  • I like this idea too. Either accessing it locally via the local IP address, or even via USB could be handy sometimes.
  • Paul -

    I'll second (or third, actually...) the suggestion. Something like a routers GUI would be nice.

    Regards - Don
  • Id second this.
    Im often on a boat and our internet is more akin to dialup than broadband when onboard. Id like to have notifications succeed even when our internet connection is down.
  • You can leverage the HTTP request method to get local notifications.  The issue is you need something running to receive those notifications.  If you had a local computer running a server listening for it, you could then locally take action without having the twine access the supermechanical servers.
  • Hi,

    I have something running locally (a web server). I am sending a get request when the vibration sensor activates, but I am not seeing the results of this request on the server. The URL is at a LAN address of 10.20.30.42, so its clearly local. I have tried the same http get request from other LAN clients and it works from those, but not from the Twine.

    Update--- This might be due to an authentication issue. Will update when I know more.

    Update#2 - Definitely an authentication issue.

    Another question though. I am hitting a limit in the length of the url I can build in the Twine interface. What Gives?

  • Another update:

    -I have disabled the authentication scheme on the web server (boa). I have tested that I can successfully submit anonymous requests to the web server from both IE and Chrome. I am able to see these requests arrive at the web server by monitoring the web server logs.

    -I have not yet been able to successfully receive a http get request from the twine.

    The request is not valid on the internet (since it is in a LAN address space), only on the LAN to which the twine is attached. It is reproduced in part here:

    I am not seeing any requests arriving at the web server when I generate them on the twine. So Im guessing that http request notifications are only possible to an internet address? IS that correct? I had thought that running a web server behind my firewall or in a completely internet-disconnected network would be able to work, but this appears to be an unmet expectation.

    Please let me know if I am missing something


    Also, my earlier question is still unanswered and it is related: Is there a length limit for the http request string? From what I can tell on the web site, it appears to be 100 characters. That is kind of limiting, since I believe that the actual limit for a http get is 1024 characters?

    TIA
  • Thanks for the info & links. FYI the 2nd one is dead afaik.

    My question is still unanswered.

    I have sucessfully followed  a thread that got my twine to send http requests to a service at thingspeak, but I am not able to have that same twine communicate with a web server on the same LAN as the Twine. Other clients on the same LAN can send their requests to that web server, but (from the logs on the web server and running tcpdump on the router) I am not able to see any request going from the Twine to the web server.

    So, it appears from where I am that unless the http request is going to a web server which is visible to Supermechanicals site (from which the requests are coming?)_the requests throw an error.

    When I test the http request, I only ever receive 'error', with no further details.

    Could someone from Supermechanical confirm this?


    Has anyone been able to use the Twine to communicate with a local web server while disconnected from the internet (after the rules are saved)?


  • I'm working on the same thing, Charles.

    In my case, I'm using netcat to listen to all traffic coming to port 4000 (just chosen randomly) on the machine at 192.168.1.114. If I use a browser on any other machine on my network and go to http://192.168.1.114:4000" then netcat sees the traffic. But, when I do the same with my Twine, nothing happens. I suspect that either Twine does not make the request because it "doesn't like the URL" or that the request isn't actually being made from the Twine device, but rather from a central server somewhere (which means making a request using a LAN IP would obviously fail).   
  • Bump.


    Please let us know if this is possibly ever going to be resolved?


     

  • ...or at least host it at Amazon web services

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!