Yep, we’ll let you know soon how that procedure will work.
I’ve had some success pushing bytes to the cloud. Now I’m thinking how to engineer the particular application need I have. I’ll have the Dash Pro Beta communicate, through an Intel Galileo and BLE dongle, to a sensor device manufactured by a well-known “Unicorn” company. This device has to report sensor values and get information back, through an HTTP conversation, to their database. Doing this in real time safely records sensor values and resets them for continued sensing. The interaction is encrypted and BASE64 strings, not REST or JSON. Due to the encryption, we pretty much have no choice other than to use HTTP connection to their site (nobody has been able to reverse engineer the protocol). The HTTP connection seems to have multiple messages back and forth (maybe using Connection Keep-Alive, I can’t recall the details). Bottom line? I’d like to move from the basic Konekt tutorials of serial write, on to actually using HTTP to an external URL on the Dash Pro Beta.
I suspect that to do this, I may need to program in C using Kinetis Design Studio or similar. Perhaps using the program button and the USB it will be possible to upload new code in the Dash Pro Beta. However, I have no idea about what kind of stack there is for HTTP and how it would work. So far, I’ve not seen anything about this in the documentation. Can you point me in the right direction?
Ted.
Hello Ted,
For clarity for everyone reading this thread, the Dash and Dash Pro can be programmed with either the Arduino IDE (instructions here) or Kinetis Design Studio.
Option A (might work): In a future version of our Dash and Dash Pro firmware, it will be possible to perform HTTP communications directly to a server of your choosing. It might be tricky to work with a Connection Keep-Alive scenario, though—we’ll have to think through that one!
Option B (would likely work): it might be possible for you to implement a web relay service around our platform to do what you need, where your web relay service would be keep-alive–friendly. We just launched the Konekt Tunnel Service for inbound data to devices, and will soon be launching a REST API method in the Konekt Cloud for sending inbound serial data to/through the Dash as well (the REST API method won’t need to use the Tunnel Service).
With this option, the theory of operation would be:
DEVICE (SERIAL) --> KONEKT DASH --> KONEKT CLOUD --> YOUR RELAY SERVICE --> THIRD-PARTY SERVER (HTTP)
and:
THIRD-PARTY SERVER (HTTP) --> YOUR RELAY SERVICE --> KONEKT CLOUD (or Tunnel) --> DASH --> DEVICE (SERIAL)
Your relay service would be able to maintain communications with the third-party server over a Connection Keep-Alive HTTP session, and you could use either the Konekt Cloud REST API method or the Konekt Tunnel Service as a means to send inbound serial data to/through the Dash or Dash Pro.
Effectively, this would be using a Dash or Dash Pro as a hardware-version of the Linux/Unix netcat tool.
Now that I’m able to communicate with the Dash board and send messages to the cloud (I’m also experiencing the blank data messages but hopefully that bug gets resolved soon), I would like to port over some functionality from a device built using a Teensy 3.1. How do I enable the following:
- Power savings - My device is inactive most of the time and should be switched to a low power state when not in use. I was using the popular Snooze library on the Teensy. The kickstarter page mentions some sleep/wake optimizations
- Charging - Do the beta Dash units have a functioning battery manager and how do we go about using it? Other forum posts seem to indicate that the boards cannot be run off both USB and battery so it’s not clear how to charge them
- Clock - Does the Dash have a RTC? How is it set/powered?
- OTA Firmware updates - Is this feature included on the Beta Dashes?
PS: Helpful hint if you’re experiencing similar errors as I was (Computer recognizes something was plugged in but does not recognize/mount/install Dash): check to see that your computer is providing sufficient power through USB. Mine was not but one I plugged the Dash in through a powered USB hub, it worked! --debugging courtesy of Ruben
Just wanted to say that I got everything up and running. Windows 10; Python 2.7 (actually using a version that installed with my ArcGIS software), already in path, scripts added to path; installed pip, installed additional py software from repo using pip; didn’t worry about version control of hidapi; moved Arduino directory to C:\ (apparently unnecessary now); pushed the little button nearest the ublox module on the dash pro, compiled and uploaded. Didn’t activate my cellular module but hey, no errors.
Is there no way to get a serial monitor with the dash through the USB cable? I don’t have an FTDI converter laying around.
Are there plans to add this in the future?
Hello @canmobilities,
The occasional blank cloud message bug should be resolved in the next firmware release (along with an easy-to-use firmware updater client!)
Thank you for the questions you asked. Here are responses, in order:
- Power savings - We are working to release sleep/low-power modes with our production firmware shipment this month. The Snooze library on the Teensy is fantastic, and we’ll try to make our implementation as similar as possible.
- Charging - I’m going to ask @DazzlingDuke to chime in on this one, because I’m focusing mostly on firmware.
- Clock - Yes, the Dash has more RTCs than we even know what to use them for! As the Dash associates with the cellular network, network time is provided to the modem during the association (and in a handshake that doesn’t consume any of the device’s data plan). We are working on syncing the RTC with this time. As RTC is useful in both power saving implementations and proper crypto implementation, this is a dependency of some of the other features that are planned in our stock firmware. You will be able to set/read this value in a similar fashion as on a Teensy using their Time abstraction methods.
- OTA Firmware updates - The firmware that shipped with Beta dev kits does not yet support OTA updates; however, I can say that, over this past weekend, we made significant progress on implementing OTA updates for both underlying system firmware AND user programs. We plan to release a firmware update for the Beta dev kits to add OTA update support when we ship the rest of the dev kits this month.
Thanks,
Pat
1 Like
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
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