Particle's TCPClient on Oak?

[dougal]

So I mentioned a while back that I'm working on a garage door control using one of my Oaks, and I want to be able to monitor the status and control it via homebridge on my RasPi.

The strategy I decided to use is to use an MQTT server as an intermediary, with the homebridge-mqtt plugin. With this, I can send MQTT messages to define devices, and get/set their status.

While I've seen MQTT libs that look like they work with Oak, they seem to use WiFiClient underneath, and expect your code to explicitly set up the network SSID/password for the ESP.

I expected to be able to do it more like on Particle's other devices (e.g., Photon), where the underlying network connection is already set up, and they have a 'TCPClient' class which has the same interface as EthernetClient and WiFiClient.

Has anybody already done any work to create a TCPClient lib for the Oak? If not, I might start one.

[PeterF]

I haven't seen anything like that (not that I have specifically looked), but you can use the pubsubclient that you can install right from the Arduino IDE library manager and it works on top of the Oak wifi setup - you don't have to manage wifi setup manually. The esp8266 example with that library suggests that you do, but this is because it is for the esp8266, not the oak. I had this code running on an Oak a couple of weeks ago without any issue. Bonus points if you can guess what it does (it's not hard!)

[dougal]

Ahhh, thanks @PeterF. All the examples I saw seemed to suggest that with ESP8266WiFi, I'd have to manually set up the wifi connection.

I'll give it a try without any special setup.

The next fun piece of the project will be integrating the JsonStreamingParser library...

[PeterF]

This one? I'll be interested in hearing your experiences with that... I tried using the ArduinoJson library with the Weather Underground API to grab sunrise and sunset times, and it only ended in tears, and it would work perfectly well for 20-30 minutes, or even hours at times, and then suddenly go into zombie lets-keep-requesting-data-until-the-API-boots-me-for-the-day-even-if-you-have-protections-for-exactly-that-in-place mode... so I gave up on that idea!

[pkourany]

@dougal, an RGBMatrixPanel clock I ported to Particle gets its weather from openweatherapi using Particle webhooks.  I have the webhook parsing the return weather payload using a Mustache json parser to get only the elements I need.  This brought my payload size from > 2KB to under 100 bytes.  Have you thought of using webhooks?

[dougal]

@PeterF: Yes, that's the JSON parser. In my case, I don't have to do anything too complicated to do. The JSON data format I'll be parsing looks like this:

Code: [Select]

{"name":"Garage Door","characteristic":"TargetDoorStatus","value":1}
My device will look at the values of the "name" and "characteristic" properties to make sure that this MQTT payload is intended for itself, then save the value. I'm doing a sort of state-machine thing to keep track of things.

@pkourany: I thought about using webhooks, but it seemed like that would be yet another separate piece that would need separate debugging. *For now*, I really wanted to try to keep the code more self-contained. I'm already relying on two different services from the home automation server (RasPi running mosquitto and homebridge + homebridge-mqtt plugin).

It's possible that I might re-think some of this later. Trying to parse JSON from C/C++ code is a pain in the neck. If I stick with Oaks and other devices that use the Particle Cloud, I might put up another local service anyways, to translate the MQTT JSON messages into simpler Particle.function() and Particle.variable() calls.

The eventual goal is that I could have my devices controllable by HomeKit/Siri on our iOS devices, via homebridge, and by a web interface on non-iOS devices. Using MQTT and homekit-mqtt is what will allow everything to stay in sync, so that if somebody turns a light on via the web interface, it will update the HomeKit status, so that the iOS devices will see the correct state.

The problem right now, is that I some how seem to have hosed my Oak. I need to do some troubleshooting and see what I need to do to reflash it...

[PeterF]

Oh no... you roasted your Oak!! 

You'll be needing this then: https://github.com/digistump/OakRestore

I'll have to give that parser a try then... maybe it won't suffer from the same issue (memory leak?) as the other one... was quite annoying...  I only wanted to get two bits of data!!!!!!!

[dougal]

Yeah, not sure what happened to my Oak. I was modifying my sketch and uploading updates remotely, and it quit responding. I was messing with some pointer variables, so maybe that cause my problem.

I've tried going through the normal update process (including using local OakUpdateTool), but it doesn't seem to want to leave config mode now. It still knows its deviceID, though, so it's probably not *too* messed up. I'll have to dig out my serial adapter and try a restore.

[dougal]

Well, poop. I've tried updating via serial (both the standard update and the force update), and it appears to work, but I can't get the Oak to accept config and connect to wifi.

I pull up the oakconfig web tool, give it my Particle login info, connect to the Acorn AP, give it my local wifi credentials, and... Nothing. The web page just sits there forever with the status bar moving, but nothing else happens. The Oak doesn't connect to wifi, and the browser never gives a next step.

It responds to browser requests, though. For example, the "/info" api returns

Code: [Select]

{
  "id":"xxxxxxxxxxxxxxxxxxxxx",
  "claimed":1,
  "claim_code":"blahblahblahblah",
  "server_address_type":1,
  "server_address_domain":"device.spark.io",
  "firmware_version":0,
  "version_string":"",
  "meta_id":0,
  "meta_data":"",
  "first_update_domain":"oakota.digistump.com",
  "first_update_url":"/firmware/firmware_v1.bin",
  "first_update_fingerprint":"98 66 d5 5c 3d 4a 49 24 e3 1b 72 8b 8f 2e 65 2e 32 2a 7b 95"
}
I might try manually resetting the claim info, because I already unclaimed it.

I've noticed that I just get a steady one-blink on the status light though. And grounding P1 doesn't seem to change anything. I never get the three-blink for config mode like I used to be able to do.