Community Hangout (Sept 4, 2-3 PST)

We’re having a community hangout Sept 4 (that’s tomorrow, for those of you keeping track) from 2-3 PM PST.

We’ll be discussing, some of the changes in release 30, our new PubNub library, and much more!

If you have any specific questions you would like us to answer, post them here and we’ll do our best to get to them (or tweet them with #impquestions)

Here’s a link to the hangout!

Guys, thanks for the hangout. I did have a couple of questions, but am not a twitter user (did sign up over the course of the hangout, but not fast enough to post anything). Would appreciate it if you could reenable the chat for the hangout next time.

Particularly impressed with Aron’s USB host. Will mention that to the team to see if we can dream up applications for it. The USB Host highlights an existing problem we have with our imp apps.
We attach all sorts of things to our imps. Embedding drivers in the device code eats up the limited codespace in no time at all. Ideally, we’d like to download drivers for these things on the fly, but we can’t currently do that without the compilestring() feature in Squirrel. As a plan B, we download “drivers” to the device that are functions represented as Squirrel tables and arrays. It works, but it would be great if the device could detect what it needs and request drivers (as classes, singles functions or code containers) from the agent (or cloud).

Alternately, with the extra storage available on the imp003, it would then be possible to serialize functionality on the device in order to load it on demand.

Sorry for the lack of alternative Q&A/chat on this hangout, it wasn’t intentional.

We are managing the hangouts in a slightly different way than before, and new things are scary and hard! I’ll make sure we have it sorted out before the next one!

The compilestring() function ends up taking a LOT of resources and space on the imp, which is (one of the reasons) why we have not included it (it also opens the door for some serious security concerns).

I’ll point @aron at this post to thread to comment some more on the USB stuff :slight_smile:

Matt liking the msg bus on pubnub big time. Are you/have you written this up? As the youtube vid doesn’t show the hangout live code.

Found this on google :

Sadly its not websockets just yet, got me all excited :confused:

@controlCloud - hmm, that is frustrating that it didn’t how the coding part… looks like we still have some work to do on making these correctly.

There are actually two PubNub blog posts - the first is the one @MORA mentioned (which covers the basic PubNub library), the next is this one (which covers the MessageBus class):

As MORA mentioned, this is just using PubNub’s REST interface, as opposed to sockets.

Your link to the USB Host info points to this by mistake:

Didn’t see anything in the hardware tree at all for the USB Host stuff.

Whoops! Thanks for that catch @digitalarchivist. Here’s the real link:

message bus looks neat, a lot cleaner code than sending http requests to a server and having it contact each imp in return.

Thanks @MORA! That was exactly the goal of the library. It doesn’t really add “new functionality” - it just makes existing things a lot simpler and cleaner :slight_smile:

I had a lot of fun building the USB host code. I have a bit of a bruise on my forehead from bashing it against the wall a few too many times, but it got there in the end and is nice and stable if a little bit janky.

As promised I added the FTDI driver to the existing keyboard and mouse drivers. Any community feedback and improvements will be well received.

Finally got some time to play with these today, was a bit surprised that we need to include the pubnub code ourselves, but hopefully that just underlines the need for include tags even more, when official code cant be included.

The messagebus example works as advertised, theres a fairly low rate limit on pubnub though, and since the lib does not catch up on its own, maybe it would be a good idea to handle it locally as well, either as a queue, or just a variable to track how much rate is left, once the limit is hit messages are limited to 1 per second, and it seems random what is dropped, so it becomes non dependant.

Delay wise its pretty good, after a period of inactivity the delay is about half a second on the first action, after that around 100-200ms, which isnt bad considdering the event had to first go to EI servers, then pubnub and then back to the other device :slight_smile: