Johnny-five: J5 Collaborator Summit at JSConf US

Created on 21 Apr 2018  ·  84Comments  ·  Source: rwaldron/johnny-five

Date/Time

Monday, 8/20 10am - 5pm
Friday, 8/24 1pm - 6pm

Location

Poolside Cabana - Exact location TBD

Agenda

8/20

  • Languishing Issues and PR's
  • Zombie platforms

    • Galileo

    • Nino

  • Breaking changes

    • Refactor freq constructor option

    • Standard event object

    • Add missing error args in callbacks

  • io plugin feature parity

    • Evolving out of firmata coupling for IO plugins (is current interface too bound to firmata behaviors)

  • SPI Support in io-plugins

    • Start discussing next steps for getting it into the non-firmata plugins and to think about timeframes and logistics.

  • Board scriptable behavior, eg running a set of actions on a clock (thinking node pixel here mostly)
  • IMU/Multi organization

8/24

  • PWM support for platforms with > 8-bit resolution and migration from 0.0 - 1.0
  • ES6 J5 status / supported node versions
  • ES6 IO classes with an official Board.IO superclass
  • Alternative transports beyond serial (and serial over radio replacements) and what that means for messages etc (eg ble, mqtt, network)
  • Web-based J5 patterns using (webbluetooth, webusb, midi, audio, network connections, etc)
  • Shutdown/Restart J5 in the same process

Attendees

@rwaldron, @lyzadanger, @nebrius, @noopkat, @monteslu, @dtex, @ajfisher, @lynnaloo, @sandeepmistry, @HipsterBrown, @reconbot, and Fleet Admiral Nathan!

Discussion

Most helpful comment

Would you prefer August 20th or August 24th? Please react to this message with 😄 for August 20th, and 🎉 for August 24th.

All 84 comments

Hi Everyone,

It looks like we are going to have a lot of J5 contributors at JSConf US this year so @nebrius proposed that we have a J5 Collaborator Summit which is, of course, a great idea.

I'm opening this issue to help us organize a time, place, attendees, and agenda for the meeting(s).

I've added a few seed items on the Agenda and listed the attendees that I believe will be there.

If you plan on attending or have an agenda item to add, just add a comment here. I'll keep that first comment updated so we can see at a glance what the plan is.

It's entirely possible I missed this conversation earlier, but is there any updates on getting SPI support into Firmata? If so, maybe this could be a good time to start laying out plans to add support to IO plugins.

@nebrius There's this: https://github.com/firmata/arduino/issues/245

I'll add an agenda item

I look forward to catching up with everyone!

Same. Looking forward to hanging with all of you!

a few more potential agenda items:

  • ES6 J5 status / supported node versions
  • ES6 IO classes with an official Board.IO superclass
  • Web based J5 patterns using (webbluetooth, webusb, midi, audio, network connections, etc)
  • Shutdown/Restart J5 in same process

Oh I really like the ES6 Board.IO superclass idea. We could even look into creating other "intermediate" derived classes based on linux-io and raspi-core-io (which contrary to the name is not Raspberry Pi specific...I should really rename it).

There's this: firmata/arduino#245

I plan to pick this up again over the next month. I'd love to have some more feedback on the proposal, but I may just have to commit to an implementation and put it out there then make a breaking change if it ends up not scaling well. The part where I'm hung up is handling the CS pin in a way that reduces the number of commands that need to be sent over the wire.

I did some more thinking about SPI today and came up with some changes to the current proposal: https://github.com/firmata/protocol/issues/26#issuecomment-388656950. I'd appreciate any feedback regarding Option A vs B in that proposal, especially as it relates to how this API may map to non-Arduino architectures like the Raspberry Pi.

not sure who else is planning on being at jsconf, but thought I'd ping some more nodebot friends in case they missed this thread :)
@ajfisher @rockbot @julianduque @nodebotanist @lynnaloo @KatieK2 @sandeepmistry

I did miss this thread and yes, hoping to be at jsconf and around before +
after so would be good to be part of this

On Thu, May 17, 2018, 09:35 Luis Montes notifications@github.com wrote:

not sure who else is planning on being at jsconf, but thought I'd ping
some more nodebot friends in case they missed this thread :)
@ajfisher https://github.com/ajfisher @rockbot
https://github.com/rockbot @julianduque https://github.com/julianduque
@nodebotanist https://github.com/nodebotanist @lynnaloo
https://github.com/lynnaloo @KatieK2 https://github.com/KatieK2
@sandeepmistry https://github.com/sandeepmistry


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rwaldron/johnny-five/issues/1463#issuecomment-389698361,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAHRoyWeJzgYGxaoKrKnUOVqZ9PGr9lRks5tzLelgaJpZM4Tek7o
.

I'll not be at JSConf US 😭 - have fun friends!

I will be there!

Alas, I haven't got a ticket. But I love seeing this. Y'all keep doing awesome! 💖

I'll be there as well!

To get the ball rolling on scheduling, I’d like to make an initial proposal/recommendation:

Let’s hold the collaborator’s summit on Monday August 20th, the day before JSConf US starts. Let’s have it run from, say, 10am to 4pm, perhaps with a breakfast before we get started to catch up and socialize.

Here’s my current thoughts on why:

  • Holding it during the day during the conference doesn’t seem ideal to me

    • We’d need to skip talks on the first and third days (which some of us may be giving!)

    • The second day is definitely out due to NodeBots activities

  • Holding it in the evening doesn’t seem ideal to me either

    • if it’s a conference evening, there would be planned conference events we’d need to skip

    • if we held it on Monday evening we wouldn’t have any conflicts, but I fear ~3 hours wouldn’t be enough time

  • Holding it the day after the conference is a better option, but still doesn’t seem as ideal to me

    • Everyone will probably be worn out from the conference and after parties

    • This may only apply to me, but JSConf US is already alarmingly close to Burning Man and closing the gap another day isn’t feasible for me.

What do you all think?

Pinging @opheliasdaisies and @hipsterbrown in case they missed the thread and want to be there

@nebrius I'm traveling that day, but am willing to change my flight for this.

That’s a good point to bring up @dtex. How many folks have already booked their travel? And perhaps another related question, would it be difficult for any of you to stay an extra day (work conflict, extra travel costs, etc)?

For the record, I haven’t booked anything yet because I’m still figuring out my plans for the conference.

I wasn’t invited to speak or help with any workshops this time, so I’m thinking about maybe only going for the first half or something to help ease my schedule. It depends on timing of this summit (which is now my top priority at JSConf)

Would be a bit easier for me to do a post-conf summit, but totally understand the thoughts you listed.

One thing to keep in mind though is a few years ago we had a little mini summit in the lobby the morning after jsconf until about 2pm( or as people headed out to their flights). About 5 or 6 people showed up, but the result was @ajfisher 's backpacks, some j5 bug fixes, some changes to IO classes and firmata and a few other things I can't remember. I was a bit newer to the scene, but even more psyched for nodebots after the conf than I was at the start :)

@dtex Thanks for pinging me. 😄 I've been watching this thread and looking forward to seeing folks in August.

I'm not sure if my travel is booked yet, maybe @dlindahl knows?

Let's get something of a poll going to figure out availability, since as @rwaldron mentioned, travel constraints are a thing.

I'm going to post a series of follow up posts with options to vote on both what days you can/cannot make it and which day you prefer. Hopefully that'll help us figure out details and get a date solidified and we can all finalize our travel :)

Are you available to attend on August 20th, the day before the conference? Please react to this message with 👍 for "yes," 👎 for "no."

Are you available to attend on August 24th, the day after the conference? Please react to this message with 👍 for "yes," 👎 for "no."

Would you prefer August 20th or August 24th? Please react to this message with 😄 for August 20th, and 🎉 for August 24th.

@rwaldron While we can book your airfare for you, we prefer to offer reimbursement. Let me know which option you'd like to go with (along with anyone else in this thread)

Thanks everyone for voting so far. @noopkat @sandeepmistry @lynnaloo @rwaldron , can you vote in the above comments so we can get scheduling finalized?

I also had another thought: what do you all think about getting some sort of teleconferencing going for the folks who can't be there in person?

I can't commit to either date at this point, since I'm still unsure of travel, and will have my baby with me. Looping in @reconbot too.

Sorry about the late vote. My sister’s birthday is on Sunday 19th and I am on my last day of vacation with family that day, which means I cannot fly to SAN until Monday. I won’t be able to make it in until 9pm Monday 20th as a result even though I’m on the first flight out that morning. If Monday works better for everyone else I completely understand and can catch up on the discussions if someone is willing to take notes.

Tell your sister happy birthday from the J5 crew @noopkat! 🎂😊

Here's a thought, since we're at 5/2 yes/no for both days: what if we held a summit on both instead of picking? I'm sure there's enough stuff to talk about, call it a hunch 😉

That works for me. We should identify the things that @monteslu and @noopkat are most interested in and put those on the agenda for the day after.

That works for me. We should identify the things that @monteslu and @noopkat are most interested in and put those on the agenda for the day after.

That's a great idea! We could also do the same for the things me and @sandeepmistry are most interested and get them on the day before agenda

Hi! Sorry also for late vote; traveling. I don't have travel arrangements yet for August, so I'm OK with whatever datetime.

I'm having trouble interpreting the results of the vote... it looks like 5:2 for both days and then the third vote shows 5 for August 20th and 3 for 24th?

There are two people who can't do the 20th and two others who can't do the 24th. The majority of people seem to prefer the 20th.

@monteslu can't do the 20th and he had some specific issues he wants to discuss, so I'll take a stab at splitting the agenda to see how that works out. @noopkat, if there are specific things that interest you let me know and I'll get them onto the 24th's agenda.

I haven't formalized my schedule yet, but probably good for either.


Francis Gulotta
[email protected]

On Sat, Jun 16, 2018 at 12:16 PM, Donovan Buck notifications@github.com
wrote:

There are two people who can't do the 20th and two others who can't do the
24th. The majority of people seem to prefer the 20th.

@monteslu https://github.com/monteslu can't do the 20th and he had some
specific issues he wants to discuss, so I'll take a stab at splitting the
agenda to see how that works out. @noopkat https://github.com/noopkat,
if there are specific things that interest you let me know and I'll get
them onto the 24th's agenda.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rwaldron/johnny-five/issues/1463#issuecomment-397822970,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABlbpSO6Wj1r3AtD9Mzyw6DGQ3K0G01ks5t9S9HgaJpZM4Tek7o
.

I know I said "either is fine" in a previous comment, but I have developed a strong preference for the 20th. Need to know ASAP if we're doing the 24th as I'd love to get flights this week. Sorry for the late opinion!

Attempting to put a steak in the ground so we can book travel, how about this: let's plan on having a "primary" collaborator's summit on August 20th from 10am to 5pm, and a "secondary" or "optional" collaborator's summit on August 24th from, say, 1pm to 6pm (so folks can go to the brunch). Does this work for everyone else?

Since all the responses to @nebrius's comment were "thumbs up" I went ahead and let @dlindahl know that we were looking for a spot. He is reserving a pool-side cabana for our use on both days.

We are still open for agenda items and if there is something that interests you on a day/time you can't attend, just let me know and I will shuffle the schedule.

For me, the big things I'll like to talk about are (not surprisingly) IO plugin related:

  • SPI Support in io-plugins

    • @fivdi is definitely the right person to take technical lead on this, since the raspi-io SPI support will come from his spi-bus module, but I would like to start discussing next steps for getting it into the non-firmata plugins and to think about timeframes and logistics.

  • ES6 IO classes with an official Board.IO superclass
  • Shutdown/Restart J5 in the same process

    • I realize there's already a lot scheduled for the first day, so if we can't move this one over it's fine, it's less important to me.

My stuff is largely IO plugin related as well and thinking between Arduino + firmata and full SBC.

  • thinking through alternative transports beyond serial (and serial over radio replacements) and what that means for messages etc (eg ble, mqtt, network)

  • what options do we have for evolving out of firmata coupling for IO plugins (is current interface too bound to firmata behaviors)

  • board scriptable behavior eg running a set of actions on a clock (thinking node pixel here mostly)

You're giving me more ideas of things I want to talk about @ajfisher 😜

In order to prepare, I'd like more information on just about every agenda item. Can we get brief summaries written?

Notes from my side @rwaldron

Alternative transport methods

Right now we're heavily bound to how serial works in terms of the transport model. Whilst technically we can go to things like WiFi or BLE etc, we're really just simulating how serial works in these scenarios.

What I want to explore is how we make J5 more independent of the underpinning transport methods to enable situations like UDP over WiFi without running into network issues. This in turn would allow for distributed messaging systems such as mqtt.

Evolving out of firmata?

This is more of a discussion than hard action. Firmata currently governs a lot of the required interface for an IO plugin because it's a great first crack and has historical relevance.

Firmata however is fundamentally tied to midi (eg 7 bit bytes) and Arduino in terms of factor. It's also heavily oriented towards serial comms too.

I want to explore if we can find a next step out of firmata that gives is backwards compatibility but enables a forward step for newer boards and architecture (eg 32bit micros, networked by default, ideally distributed)

What does v2 even hypothetically look like?

Board scriptable behavior

One of our fundamental challenges is breaking the loop between laptop running code and deploying that code to the device. When you start thinking about more distributed systems then you run into problems like, "how do I get a note to just keep executing this code on a loop?".

A good example from node pixel might be creating an animation sequence then getting it to keep running on a timer.

Being able to have a mechanism to deploy code to a device in a limited way to do this type of task could solve a stack of distributed problems even at a simple level.

One more I want to add to the list and been a heavy topic over last few months at Melbourne hacker space.

What would we need to do to create "microJS"?

There's been attempts using eg ductape, espruibo etc so there's some demand.

If we assume that the ESP32 board is the "next Arduino" in terms of open source enough, powerful enough and connected enough then it follows that it should be a target we think about a lot more.

Given the push that's happened on micro python this year and my continued frustration with how low level it is I think there's an interesting space here that's worth exploring further.

@rwaldron let me know if you want more details and will edit.

@ajfisher thanks for this!

Languishing Issues and PR’s

The problem isn’t so much the number of issues and PR’s, but the number that have been open for over a year. There is no single class, device or io-plugin at fault.

screen shot 2018-07-14 at 7 45 08 pm

Things that I believe are contributing to the buildup:

  • Anytime we actually need to test something, the hardware is required
  • When we have the hardware we have to take time to assemble a circuit
  • So. much. hardware.
  • Generally classes have one SME and Rick, or just Rick because Rick is the SME.
  • Huge network of related projects (J5, IO plugins, SerialPort, device code, backpacks) plus alternative delivery platforms like NodeRed and NW. It's too much for any one person to stay on top of.
  • Day jobs

Possible solutions:

  • One big sprint
  • Smaller sprints by class / plug-in / delivery platform
  • Just close issues that have been inactive for a few months

v1.0.0

We have a 0.10.0 label in the repo issues that is tagged to some breaking changes. We also have issue #370 which addresses the migration from 0-255 to 0-100 range. Per semver, anything prior to 1.0.0 is “non stable API”. I believe that once these 0.10.0 issues and #370 are complete we can confidently bump Johnny-Five to v1.0.0

Zombie Platforms

Plug-ins are their own repos and the platforms will self attrite, but does having them in the docs overcomplicate things? Galileo-io still accounts for >5% of users and that's supposed to be a "zombie platform", so maybe a non-issue.

Evolving out of firmata

Based on npm download stats* it appears that ~71% of all Johnny-Five installs are simply using firmata which supports the “firmata-first” approach, but I think it’s important to remember that we are standardizing around firmata.js, not firmata. Is it realistic to define firmata.js API’s before they can be implemented in firmata? The current discussions around SPI are a good example of how tricky this can be.

2018 Downloads based on dubious sources

  • Johnny-Five: 60,317
  • raspi-io: 7818
  • galileo-io: 5192
  • beaglebone-io: 1566
  • tessel-io: 1482
  • particle-io: 879
  • imp-io: 281

IMU/Multi organization

Each member class wraps IMU/Multi instead of Multi grouping the member classes. This seems bass-ackwards. It makes Multi huge, mixes all kinds of different devices into a single file (device types that already have their own appropriate class files), and if we stay with this multi will eventually reach critical mass and collapse in upon itself.

A note on zombie platforms. Node 10 has dropped 32bit Intel builds. And I'm finding it hard to continue to support node 4 for SerialPort. Our world moves slower than nodejs LTS Support drops platforms but... It's hard to maintain. The scheduled time for our meeting is during event setup but I should update about where I want SerialPort to go.

SerialPort roadmap

  • monorepo with packages for components of sp
  • more doc improvements with guides (as good as pouchdb is the goal)
  • optional bundled binary bindings for no prebuild download. Bindings without debug are much smaller than I could have imagined.
  • async iterator binding API change.
  • consider a funding platform to hire a dev (student or professional) for directed low level work

Future SerialPort consumers might not need to use streams at all 🙃

SerialPort issues

  • need c++ help to keep up to date with node and performance issues (much better than previous but still could be better)
  • need windows help to close known bugs (flush, and close while reading both error in silly ways)
  • need issue triage (not as bad as j5 tbh)

A lot of firmata over network/Bluetooth etc rely on a SerialPort like object and that's not going to go away, but I think the async Iterator binding level API is how new stuff should look and I'll roll that out after the monorepo. There's much less code doing basically the same thing as streams.

There are 2 primary issues with Firmata that I think it would be good to figure out how to move away from in firmata.js and any io-plugins:

  1. Digital pins default to digital out, which causes all sorts of problems, especially with relays. This is however not possible to resolve in a non-breaking way in StandardFirmata.
  2. There is no real digital read/write at the pin level, only at the Firmata "port" level. This is also the reason all pins have historically defaulted to digital out (because there was no way to enable individual digital pins in the past).

I agree that the midi 7bit aspect is annoying as well, but it's easy enough to abstract out and when you look at what it would take to use another format (header, checksum, etc) the 7bit is still less clock cycles. Bjoern Hartmann had a Firmata-like implementation based on OSC at one point so that is something to look into for inspiration if anyone is up to the challenge.

@ajfisher

What would we need to do to create "microJS"?

You should check this out: Moddable XS


@ all

I'm reading all of the notes provided so far and I have to be honest with everyone: I'm already feeling super overwhelmed. I've clearly failed to document all of the decisions that have been made and the rationale behind them.

@dtex

IMU/Multi organization

Given the requirements, I don't think this is backwards at all. Again, I accept that this is entirely my fault for neglecting to document why things are designed the way they are.

Since i'm based in Europe, i'd love to connect via Teleconference. My main gripe is still the ESP8266 and PWM but i'd also love to hear about future plans. I'm slowly moving my Robots&Workshops into the AI territory.

@ghtomcat I'll add ESP8266 and PWM to the agenda but just in case our connectivity is sketchy can you outline the issue for us here? I'm sure someone there can champion it if we can't get you on the line (Hangouts maybe?)

Which day is better for you to try and connect (note we will be at UTC -7)?

I think I have an understanding of the issue: Firmata on esp8266 correctly reports 10-bit PWM resolution, and firmata.js does store it: https://github.com/firmata/firmata.js/blob/master/lib/firmata.js#L233-L236 however that property isn't utilized when actually doing writes from j5.

Ah yes, I know that issue (firmata and firmata.js have been ready for this for two years). J5 needs to be updated to match, but it's going to be a breaking change. It should be tightly coupled with the migration from 0-255 to 0.0-1.0 but is more important than getting to a v1 so I'm going to break those out from the v1.0.0 topic.

@ghtomcat Thank you for reminding us about that one! It's a really important issue.

@dtex i can join both days, it will be 7pm-2am on the 20th and 10pm-3am on the 24th .. i prefer the 24th .. since it will be late, a chat based teleconference seems to be the easiest.

@ghtomcat I've made that issue the first to cover on the 24th. I'm not sure how good/bad the connectivity is where we are having the meeting (literally in a pool-side cabana), but I know that @monteslu and I are both prepared to speak about this issue if things don't work out. I don't think anyone will argue against this, we just need to chart a path to get it done sooner rather than later.

I'll create a Hangouts event. I followed you on Twitter if you want to just DM me with your email address for the invite, or just post here (your call).

@ghtomcat I've sent an invite to the Hangout. If anybody else would like to be invited to the Hangout, just let me know and send me your email address.

Pool wifi should work, nodeboats was assured of that.

On Sat, Aug 11, 2018, 3:07 PM Donovan Buck notifications@github.com wrote:

@ghtomcat https://github.com/ghtomcat I've sent an invite to the
Hangout. If anybody else would like to be invited to the Hangout, just let
me know and send me your email address.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rwaldron/johnny-five/issues/1463#issuecomment-412295522,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABlbkGSRFIbIjFKAtnGgywZfztJdA1qks5uPyt5gaJpZM4Tek7o
.

Slightly OT, i made nodeboats last year, based on Sumobots, with paddles and PET Bottles :)
boat2

I might not be able to change my flight on Friday to be able to attend the meeting. So it looks like I cannot attend both meetings I am very sorry 😞I'll keep trying to find something that works.

One thing I'd like to take on this year is to put together a proposal for a friendly component extension API. Happy to chat with anyone at the conference in more detail about this since I'll miss both meetings (and will be on flights during them so the plane wifi probably won't hold up to me attending the meetings remotely).

Hey gang, it looks like our cabana is not available so we are going to meet in Derek’s room, #958. Given the mosquito situation this is probably a good thing.

What time are we meeting peeps?

On Mon, Aug 20, 2018, 09:29 Donovan Buck notifications@github.com wrote:

Hey gang, it looks like our cabana is not available so we are going to
meet in Derek’s room, #958
https://github.com/rwaldron/johnny-five/issues/958. Given the mosquito
situation this is probably a good thing.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rwaldron/johnny-five/issues/1463#issuecomment-414379119,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAHRo5s18QvTbHOr4nyCKwvycI2g1e60ks5uSuP8gaJpZM4Tek7o
.

@ajfisher 10am

Cool. May be a bit late as thought it was later and I'm still out. See you
all in a bit

On Mon, Aug 20, 2018, 09:44 Donovan Buck notifications@github.com wrote:

@ajfisher https://github.com/ajfisher 10am


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rwaldron/johnny-five/issues/1463#issuecomment-414383914,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAHRo3xC4WdFowREUgo_sk-F7y5-1eprks5uSudmgaJpZM4Tek7o
.

Johnny-Five Collaborator Summit Day 1 - Takeaways and ToDo's

  • Languishing Issues and PR's

    • [x] Add Stale to Johnny-Five Repo. Issues that have no activity in the past year will be marked as "Stale". Issues that have been stale for 7 days will be closed. Users can comment while an issue is "Stale" to keep it fresh, and issues can be re-opened once closed. @dtex

    • [x] Tag the existing release of Johnny-Five as v1.0.0. This immediately puts us into "semver mode" and we can start making breaking changes. This will happen Wednesday night, after the workshops. @rwaldron

    • [x] Write a johnny-five.io news post talking about this and our commitment to match support with official node LTS versions. @lyzadanger & @nebrius

  • Zombie platforms

    • [ ] Galileo - Reach out to Derek at Sparkfun and ? at Intel and make sure they know they need to lock down on version 0.14.3 in order to ensure compatability for Galileo and Edison (until someone adds support for new Servo methods from c33155e5e8eb6d8a1f594793ec64655aa6175d06) @rwaldron

    • [x] Nino - Mark Repo and package as not maintained/deprecated @rwaldron

  • Breaking changes - Our new semver approach and tagging as 1.0.0 puts us in place where we can actually make breaking changes so it will be possible to move forward with these changes individually instead of landing everything before we can tag as 1.0.0. This has been a blocking problem for years and is a huge, positive shift for J5.

    • [ ] Replace all ocurrences of freq in constructor options with period and update examples and docs @hipsterbrown

    • [ ] Remove all ocurrences of this.emit("read") @hipsterbrown

    • [ ] Find all the callbacks and add them to a spreadsheet. Include the args passed to the callbacks and wether the callback can be called more than once. We are working towards following node's standard error first pattern, even if we are just passing null for things that will never error @ajfisher

    • [ ] Update contributing.md to note that any breaking commits must have a short description that is prefixed with [Breaking] @lyzadanger

    • [ ] Update sensor data event to pass an object like { value: scaledValue, raw: ADCValue } where "scaledValue" is [0, 1.0] and "ADCValue" is the raw value which will vary with the ADC bit depth @ajfisher

    • [ ] Update all examples to destructure objects passed to event listeners, grabbing only the values needed @ajfisher (Delegate this task by class maybe?)

  • IO plugin feature parity. We clarified the position re: making changes to io-plugins. Rather than a "firmata first" approach where new features were never added to other io-plugins before they were available in firmata.js, we can now add features in io-plugins first. Care must be taken to coordinate with other plug-in maintainers to ensure that we create an API that will work for all. This API spec will be maintained in rwaldron/io-plugins.

    • [ ] Revisit rwaldron/io-plugins to make sure it is current and complete and reflects the format we want to use for the "Standard" @rwaldron

    • [x] Create abstract-io @nebrius

    • [ ] Open issue on each io-plugin repo informing maintainers of our clarified approach to new features and the new/improved io-plugins repo @dtex

  • SPI Support in io-plugins

    • [ ] Add SPI support to raspi-io @nebrius

    • [ ] Add SPI support to imp-io @dtex

    • [ ] Add SPI support to tessel-io @rwaldron

    • [ ] Add SPI support to ble-io @monteslu

    • [ ] Add SPI support to firmata.js @rwaldron

  • Board scriptable behavior

    • [ ] Draft a scriptable package protocol @ajfisher

    • [ ] Test protocol on imp-io @dtex

  • IMU/Multi organization

    • [ ] Explore breaking individual multis out to component plugins

  • PWM support for platforms with > 8-bit resolution

    • [x] Just effing do it @dtex

  • ES6 J5 status / supported node versions - We now officially support all Active, Maintenance and Current LTS releases and we drop official support when they hit EOL.

Not everyone could be there today so if you see a ToDo you would be interested in helping with, reach out to the assignee.

@ghtomcat We were ahead of schedule so we actually got to the bit-depth issue today and there honestly wasn't anything to discuss or debate. Everyone agreed that this is something that needs to be done sooner rather than later and it was assigned to me so look for something in the next few days. All of the heavy lifting is done already so it should be pretty easy.

@dtex awesome news! my ESP8266 plus DRV8833 is standing by to test :)

Johnny-Five Collaborator Summit Day 2 - Takeaways and ToDo's

  • Update examples - Stop using this, use arrow functions where appropriate, spread operators, const on requires, and appropriate variable scoping (let)

    • [ ] Update sensor class examples @ajfisher

    • [ ] nit new sensor class examples @rwaldron

    • [ ] Set plan for updating all the other examples (assign by class) @dtex

  • Component plugin super class

    • [ ] Draft specification @noopkat

  • Alternative tranports within serialport

    • [ ] Add bindings for WebUSB @monteslu @reconbot

    • [ ] Based on this add bindings for other transports TBD

  • Handle disconnects gracefully

    • [ ] Propose heartbeat feature for firmata that allows users to define a heartbeat interval and a target state for disconnected devices (The OFS) @dtex

    • [ ] Ping @sandeepmistry to see if there is a way for the board to know if a serial connection has been lost. See cdc.cpp line state which is currently marked as a to-do. (Note that this is not a panacea as off-board devices will still be connected to serial even if their connection to the host has been lost).

Not everyone could be there today so if you see a ToDo you would be interested in helping with, reach out to the assignee.

thank you @dtex for the amazing note taking, and it was wonderful to see you all this week! ❤️

seriously @dtex this is like a roadmap for the next year 👏

it wasn't on the roadmap but we did bring this up. I made a nodebots/rfcs for nodebots and larger than core j5 discussions. And I kicked things off with discussion around moving serialport to the nodebots org https://github.com/nodebots/rfcs/issues/1 I'm also moving forward with decommissioning https://github.com/johnny-five-io

Ya'll should watch that repo.

@ghtomcat I've got a PR (#1495) for the ESP32 and ESP8266 non-8-bit PWM support. I've only tested with nodeunit. I need to dig up some actual hardware. When you have time can you test with your motor shield. Really important to make sure it runs forward and backward at various speeds. Also if you have time/hardware I had to update the LED and RGB LED classes as well.

Following up on my TODO items from above:

I created the repo for Abstract IO at https://github.com/nebrius/abstract-io, and I filed an issue to get SPI support into Raspi IO at https://github.com/nebrius/raspi-io/issues/106.

I've decided that I want to reimplement Raspi IO using Abstract IO first before I really call it done and let everyone else start using it, which I cataloged at https://github.com/nebrius/raspi-io/issues/107. I also think integrating SPI into Raspi IO at the IO plugin level should be fully functional before I call it done too.

I've identified a few blockers though to the above tasks, namely https://github.com/nebrius/raspi-io-core/issues/6. I'm cranking away on that one, but I wanted to set expectations with you all that it'll probably be a while.

@noopkat, I noticed you're looking into creating a base class for components, which sounds pretty similar in concept to what I'm doing with Abstract IO. Do you think it would be worthwhile to coordinate and try and get our approach/style synchronized?

@nebrius hey, thanks for flagging this! Let's chat, because I'm interested to hear your thoughts on how they can be similar. I'll need to read your Abstract IO design first, but let's talk about this in the next week or so 😄

Hey gang, I did an audit of all the io-plugins (you know, for fun) and compared them to the firmata.js API to see which features are supported. Here is the result. I thought it might be a nice-to-have for y'all.

Hey folks, I've got a pretty big update. Abstract IO is now powering Raspi IO in production!

yay!

i think you pro's should make few example tuts on interacting js with firmdata protocol, so that everyone can contribute

The open issues have been migrated to #1588

Was this page helpful?
0 / 5 - 0 ratings