BlinkM-commands.md

• Go to RGB Color Now
  • Already implemented; just basic RGB functionality
• Fade to RGB Color
  • Can be implemented; needs fading logic
• Fade to HSB Color
  • Can be implemented; needs fading logic and HSB translation
• Fade to Random RGB Color
  • Can be implemented; needs fading logic
• Fade to Random HSB Color
  • Can be implemented; needs fading logic
• Play Light Script
  • Can't be implemented; requires memory built into the component
  • Playing a sequence that's programmed on demand can be implemented
• Stop Script
  • Can be implemented, for the limited play support that's possible
• Set Fade Speed
  • Can be implemented
• Set Time Adjust
  • Can be implemented
• Get Current RGB Color
  • Effectively already implemented with internal state
• Write Script Line
  • Can't be implemented; requires memory built into the component
  • Writing a sequence in-memory in node can be implemented
• Read Script Line
  • Can be implemented, for the limited write support that's possible
• Set Script Length & Repeats
  • Can't be implemented; requires memory built into the component
  • Can be implemented, for the limited write support that's possible
• Set BlinkM Address
  • Can't be implemented, doesn't make sense generically
  • Even where it does make sense, it's not possible with other controllers like PCA9685
• Get BlinkM Address
  • Can be implemented
• Get BlinkM Firmware Version
  • Only makes sense for BlinkM
• Set Startup Parameters
  • Only makes sense for BlinkM

then just power the device with no I2C interface "in production".

Ah, right, I forgot about that part. I think it's safe to say that Johnny-Five's ecosystem precludes that aspect of usage. Of course, a Johnny-Five API can be used to write a script for that use case, but users will have to understand that non-BlinkM components obviously do not store for later.

It can use any valid 7-bit I2C address. It defaults to 0x09 and will always listen to commands on 0x00.

Well, Johnny-Five component classes do accept an address property in the options object (for those devices that allow a range), so it doesn't seem unreasonable to wire that to the BlinkM's address setting capability.

Of course, a Johnny-Five API can be used to write a script for that use case, but users will have to understand that non-BlinkM components obviously do not store for later.

Right, and that's why I think a BlinkM-specific API might be nice. Though I could see this just being built on top of Johnny-Five, rather than being bundled.

Well, Johnny-Five component classes do accept an address property in the options object (for those devices that allow a range), so it doesn't seem unreasonable to wire that to the BlinkM's address setting capability.

Well, I think this is something you'd do outside of the normal environment. Just like you'd change the hardware configurable address of a PCA9685 prior to use in a Johnny-Five program, you'd want to set the address on a BlinkM prior to use in a Johnny-Five program. The only difference being that you can use Johnny-Five to script the address change on the BlinkM, but you would do that in a one-off script rather than as part of the program you're writing.

Overall, I think the BlinkM API shows some interesting ideas that can be added to Led.RGB, but if you want the full BlinkM API, we're probably better off building a separate module.

Right, and that's why I think a BlinkM-specific API might be nice. Though I could see this just being built on top of Johnny-Five, rather than being bundled.

I don't understand, there is nothing being taken away from the BlinkM, it will still store the sequences and play whatever sequence you set it to play. It's just that non-BlinkM things won't do that because they can't, but we can still play a sequence on non-BlinkM components.

something you'd do outside of the normal environment

I don't understand what you mean by this