experimenting with lead scout bridging at the socket level

[quartzjer]

This implements a bridging mode where it fully becomes the lead scout and just sends the hq json wire protocol over serial instead of a socket. Should be very re-usable for BLE bridging too, and easier to refactor in the future.

Hello from Pinoccio!
 (Shell based on Bitlash v2.0 (c) 2014 Bill Roy)
 Custom Sketch (rev unknown)
 18563 bytes free
 Field Scout ready
> hq.bridge()
[hq-bridge] {"type":"token","token":"6e42245b08c7f62512255eb98ffa7a72"}
> hq.bridge("{\"type\":\"online\"}\n")
[hq-bridge] {"type":"report","from":4,"report":{"type":"scout","lead":true,"version":255,"hardware":255,"family":-1,"serial":-1,"sketch":"Custom","build":-1,"revision":"unknown"}}
[hq-bridge] {"type":"report","from":4,"report":{"type":"uptime","millis":87688,"sleep":0,"random":-21287,"reset":"External"}}
[hq-bridge] {"type":"report","from":4,"report":{"type":"power","battery":60,"voltage":400,"charging":true,"vcc":true}}
[hq-bridge] {"type":"report","from":4,"report":{"type":"backpacks","list":[]}}
[hq-bridge] {"type":"report","from":4,"report":{"type":"digital","mode":[-1,-1,-1,-1,-1,-1,-1],"state":[-1,-1,-1,-1,-1,-1,-1]}}
[hq-bridge] {"type":"report","from":4,"report":{"type":"analog","mode":[-1,-1,-1,-1,-1,-1,-1,-1],"state":[-1,-1,-1,-1,-1,-1,-1,-1]}}
[hq-bridge] {"type":"report","from":4,"report":{"type":"mesh","scoutid":4,"troopid":1,"routes":0,"channel":20,"rate":"250 kb/s","power":"3.5 dBm"}}
[hq-bridge] {"type":"report","from":4,"report":{"type":"temp","c":43,"f":115}}
[hq-bridge] {"type":"report","from":4,"report":{"type":"led","led":[0,0,0],"torch":[0,221,255]}}

[quartzjer]

Heya @soldair whatcha think? This should ideally make any js hq "server" code 100% re-usable for serial bridging, since it's just the hq wire protocol back and forth :)

[amcjen]

This looks solid. This'll let us solve the fragmentation/chunking stuff for BLE bridging as well I think? And puts us in a good spot for other bridge mode types like GSM/cellular or ethernet backpacks. slick!

[soldair]

Looks good. So to write input data I call hq.bridge(data).

Looks like it doesn't read off of WiFi while it's bridged though. right?

[quartzjer]

Right, because the wifi/backpack logic needs to be more deeply decoupled from isLeadScout(), which IMO is beyond the scope of this as a first-pass MVP :)

[matthijskooijman]

I've been wondering if "[hq-bridge]" is the right escaping to use here. It sounds like you might actually somehow include the text "[hq-bridge]" in regular bitlash output at some point, which would horribly break things. Furthermore, using a newline as the message terminator prevents having a newline inside the message (which should be acceptable for JSON, but it might be better to make the protocol binary-safe at this level?).

Also, having a bitlash function for the PC -> scout channel is easy, but also seems a bit fragile. Having some kind of escape sequence for these messages also makes sense to me.

Having said this, it probably makes sense to merge this now and continue experimenting like this. We can later switch over to something more robust (which probably requires fixing #132 as well first).

[soldair]

We can change the byte sequence to something more novel but we already have a working implementation and it works well. On Jun 30, 2014 2:33 AM, "Matthijs Kooijman" notifications@github.com wrote:

I've been wondering if "[hq-bridge]" is the right escaping to use here. It sounds like you might actually somehow include the text "[hq-bridge]" in regular bitlash output at some point, which would horribly break things. Furthermore, using a newline as the message terminator prevents having a newline inside the message (which should be acceptable for JSON, but it might be better to make the protocol binary-safe at this level?).

Also, having a bitlash function for the PC -> scout channel is easy, but also seems a bit fragile. Having some kind of escape sequence for these messages also makes sense to me.

Having said this, it probably makes sense to merge this now and continue experimenting like this. We can later switch over to something more robust (which probably requires fixing #132 https://github.com/Pinoccio/library-pinoccio/issues/132 as well first).

— Reply to this email directly or view it on GitHub https://github.com/Pinoccio/library-pinoccio/pull/147#issuecomment-47512133 .

[quartzjer]

I def hope we can get to a more "pure" serial level binary safe escaping in both directions, but it's def a future step after #132 :)

[soldair]

im going to merge this eod if no one has any issues. im going to send instructions for testing within the hour