Dash Beta Experiences and Troubleshooting

I have a small question, what if I would like to send a newline (\n) to the cloud embedded in a string.

Background: I am testing with the Dash Pro Beta, using miniterm.py connected to an FTDI serial-USB converter wired to the Dash (at 9600 baud). I see the usual bootstrap messages, then I can enter a line, hit enter, and it is sent to the cloud. However, what if the string would be multiple lines, can that be handled? Yes, obviously I could use some kind of encoding to avoid this problem, but that seems redundant for my application, since the Webhook (https://content.konekt.io/blog/route-iot-device-data-with-api-webhooks/) already Base64 encodes what I push to the cloud.

By the way, for anyone interested, hereā€™s what it looks like:

*** POST CALLED ***
HEADERS = 
  Host: mywebsite.us:10123
  Content-Length: 564
  Content-Type: application/x-www-form-urlencoded
  Accept-Encoding: gzip, deflate, compress
  Accept: */*
  User-Agent: python-requests/2.2.1 CPython/2.7.6 Linux/3.13.0-30-generic

BODY = 
  {'key': ['MyKey'],
 'payload': ['{"received": "2015-10-10T22:07:27.855740", "authtype": "otp", "tags": ["_SOCKETAPI_", "_SIMPLESTRING_"], "device_name": "Unnamed Device (35150)", "errorcode": 0, "source": "8944501003151035150", "timestamp": "876", "data": "VGhpcyBpcyBhIGxpbmUgb2YgdGVzdA==", "device_id": 350}'],
 'properties': ['{"url": "http://mywebsite.us:10123", "user_id": 1871, "key":"MyKey"}'],
 'userid': ['1871']}
         
REST/JSON = 
  {u'received': u'2015-10-10T22:07:27.855740', u'authtype': u'otp', u'tags': [u'_SOCKETAPI_', u'_SIMPLESTRING_'], u'timestamp': u'876', u'device_name': u'Unnamed Device (35150)', u'errorcode': 0, u'source': u'8944501003151035150', u'data': u'VGhpcyBpcyBhIGxpbmUgb2YgdGVzdA==', u'device_id': 350}

DATA = This is a line of test

162.242.211.19 - - [10/Oct/2015 17:06:36] "POST / HTTP/1.1" 200 -

The actual message ā€œThis is a line of testā€ was what I entered. The output above was produced by a simple Python server,

  # includes and override of BaseHTTPRequestHandler omitted 
  def do_POST(self):
    print "*** POST CALLED ***"
    print "HEADERS =\n", self.headers
    Size = int(self.headers.get("Content-Length"))
    Body = self.rfile.read(Size)
    ParsedBody = urlparse.parse_qs(Body)
    print "BODY =\n",ParsedBody
    bodystring = ParsedBody["payload"][0]
    JsonBody = json.loads(bodystring)
    print "REST/JSON =\n", JsonBody
    if 'data' in JsonBody:
         print "DATA =", base64.b64decode(JsonBody['data'])
    self.send_response(200)
    self.send_header("Content-type", "application/json")
    #self.send_header("Content-length", str(len(R)))
    self.send_header("Access-Control-Allow-Headers", "Origin, X-Requested-With, Content-Type, Accept")
    self.send_header("Access-Control-Allow-Origin", "*")
    #self.send_header("Transfer-Encoding", "chunked")
    self.end_headers()
    self.wfile.close()

Hi Pat

The instructions are to paste the public key generated by ktunnel into the dashboard, right? And since the script asks for numerical user ID and SIM number, that would presumably be associated with a target device, right?

Yet on the dashboard, under devices, I donā€™t see an obvious place to paste in the public key. Where should it be pasted?

Thanks,

Ted.

ps.

(1) There are several numbers visible for a device on the dashboard, so numerical user id might be confusing. I assumed it was the number in the POST headerā€™s x-www-forml-urlencoded key ā€œuseridā€, which isnā€™t even visible on my dashboard devices/topics. So howā€™s a newbie supposed to know?

(2) Also, itā€™s probably not such a good idea to have files key-ktunnel and key-ktunnel.pub in the home directory. When you next upgrade this code, please consider a more general approach, e.g have a .konekt directory, subdirs for each device, or equivalent.

@TedHerman I am also trying to add a new line in my message.
Unrelated question: Do you know of a way to get the RSSI?

To get the equivalent of RSSI, the firmware would need to access lower-level commands of the modem. For instance, it might look like this at a low level.

AT+CSQ
+CSQ: 16,99

Where documentation on this is http://m2msupport.net/m2msupport/atcsq-signal-quality/

I agree, would be nice for the Dash firmware to expose this information, but currently itā€™s not urgent for my application.

Ted

@TedHerman @rubenk,

The Dash and Dash Pro will support two modes of operation, where one is a simple serial passthrough gateway (the mode youā€™re currently using) and one will be a library that a user program running on the user module will be able to make use of for additional capabilities.

This library will provide a class with a number of functions that can be called to query network/modem state, set config, and write data. It will be possible to write newline (\n) and carriage return (\r) using this library, along with any other type of binary data, and have it conveniently encoded for you like @TedHerman pointed out.

The signal strength RSSI feature you requested is an easy one, and one that is already broken-out in the firmware, so itā€™s just a matter of creating a user-accessible interface for that call. I added a task and Iā€™ll see if I can sneak that in for the next firmware release.

@TedHerman re: inbound tunnelling via ktunnel:

Very good suggestions, so thank you!

Once ktunnel is no longer in ā€œprivate betaā€ status, weā€™ll have another item in the Dashboard menu for Networks, allowing one to configure their own virtual device network, tunnel settings, etc. On that page, there will be a tunnel userid and an ability to paste a generated public key.

(Weā€™ll need to keep the networking userid separate from an account e-mail address, since we want to offer users an ability to have multiple virtual device networks with varied device access between them, which would require separate credentials for each. Perhaps we can call this an ā€œaccess tokenā€ instead of a userid, to make it less confusing.)

For now, if you could send us a support request and include your public key, I can set up inbound device access for you.

FYI, I wanted to let you all know we have updated the pinout sheet. There were some small typos that have moved RX/TX pins around. Let me know if you have any specific questions.

Iā€™m just the lowly EE here, so I only just found out that there is a library command for the LED. I believe these will work on the Pro.

https://github.com/konektlabs/konekt-dash-arduino-integration:
Konekt-Dash-Arduino-Integration\konekt.io\dash\cores\arduino\dash.h

FYI, we fixed some bugs in the Arduino Integration. Weā€™d recommend pulling from github to get the latest version.

Any update on Beta DashPro firmware upgrade and the process?

Any examples of using the DashClass from dash.h. Not sure what everything is in the constructor
DashClass(uint32_t led, uint32_t en_5v, uint32_t v3_3, uint32_t wake, uint32_t wake_llwu);

@pmjackson The Beta upgrade process requires a bootloader upgrade first. Weā€™re working on that currently and, once it completes final testing weā€™ll post that.

Hey @cdasher,

That class is used by very low-level code and is initialized automatically at compile time.

Pretty much the only useful functionality to a user currently inside that class is the LED code.

Try this:

At the top of your setup() function, add Dash.begin();.

Then, add Dash.onLED(); and Dash.offLED(); to your code in various places.

Best,
PFW