I’m getting a lot of fun and exciting ideas and examples posted here on the forum. It all starts to become a bit hard to keep track of everything.
To be able to cope with contributions in a easier way I moved the project to the GitHub repo.
The great thing with GitHub is that you can clone the project, make your changes, and send me a “pull request”. It’s easier that it sounds and instructions can be found here:
You can contribute with a bug fix, example sketch or some new functionality you think is essential. Before making large changes core library, please send me a email so we can discuss your ideas and coordinate the effort.
If this is all mumbo jumbo to you and you haven’t programmed a single line of code in your while life you can still continue to post your great ideas here in the forum.
All the relevant project to clone can be found here:
Count me in. These are the items that I will be happy to contribute to in the near term:
[ul][li]DimmableLED Device (Sensor) - General purpose n-channel PWM dimmer for LED lighting[/li]
[list]
[li]Started in this thread as single channel - http://forum.micasaverde.com/index.php/topic,23342.0.html[/li]
[li]Moving to this thread as multi channel - http://forum.micasaverde.com/index.php/topic,18103.0.html[/li]
[/list]
[li]Sketch Version Reporting (Core) - Ability for a sketch to report version information back to the gateway to ease user device management (i.e. Am I running the latest/current version of sketch XYZ?[/li]
[li]Other Devices I would love to see :)[/li][/ul]
Sketch Version Reporting (Core) - Ability for a sketch to report version information back to the gateway to ease user device
I suggest you create a new internalMessageType (I_SKETCH_VERSION) and perhaps a corresponding
void sendSketchVersion(msg) method which sends in the value. This can be used by sketches to send a message which that will be presented in node devices.
It seems that we have varying EOL conventions in the git repot - some files use standard Unix LF for termination and some use Windows/DOS CRLF for line termination. I suggest that we standardize on a single convention (recommend Unix LF) to avoid mixing line termination that will create confusion in git diffs.
Outstanding Hek. Will fetch/merge, test and revert back.
Update - worked perfectly - no more ^M in the git diffs.
That said, can we also add .fzz and .svg to the binary file types? This will allow users to optionally share their Fritzing files for the sensors that they build. For example, I have a DimmableLED.fzz Fritzing that I had hoped to include in the libraries/MySensors/examples/DimmableLED/ pull request when it is ready.
Hi Bruce - quick question, is the dimmableled.fzz a PCB design? Had a quick look at the Fritzing site, but cant d/l it here at work to check it out ( nor have time to read site ).
If so can you pls attach here, so i can have a look tonight? I am awaiting some pcb’s i created on 123d.circuits ( there is a thread here about this )…but open to using other options especially if these are easy to share!
Also, with respect to sharing sketches via github. Rather than put them in the libraries/MySensors/examples/XXX , what about keeping them separate (except for Hek’s base ones)
[quote=“gregl, post:9, topic:179912”]Hi Bruce - quick question, is the dimmableled.fzz a PCB design?
If so can you pls attach here, so i can have a look tonight? I am awaiting some pcb’s i created on 123d.circuits ( there is a thread here about this )…but open to using other options especially if these are easy to share![/quote]
The Fritzing app allows you to design a breadboard, schematic and and layout a PCB design but I did not go as far as to layout a PCB because I didn’t plan to order any. That said, while I am completely new to the Fritzing app, it seems fairly straight-forward to do that type of thing. I have attached the Single-channel LED Fritzing design here as an example - let me know if the LE33 part that I created comes through OK…
I would prefer keeping examples (that could be helpful to others) in GitHub. The main reason is to keep them updated when API changes or bugs is found. I have also done a GitHub integration to the new MySensors site to make downloads and code inclusion on instruction pages easier.
But you can still post your examples somewhere here if you don’t want to learn git
I would prefer keeping examples (that could be helpful to others) in GitHub. The main reason is to keep them updated when API changes or bugs is found. I have also done a GitHub integration to the new MySensors site to make downloads and code inclusion on instruction pages easier.
But you can still post your examples somewhere here if you don’t want to learn git :)[/quote]
Hi Hek,
I think you misunderstood my thought…im all for keeping it in Git - absolutely so! - but rather than have the sketches that others create, stored in the examples of your mysensors library, keep them in a separate repository?
eg:
/mysensors/Arduino
/mysensors/Vera
/mysensors/Raspberry
/mysensors/CommunitySketches ( or similar )
Perhaps you could then permission Communitysketches a little more open to people like me who hack together stuff…but isnt good enough for being under your /examples area.
EDIT: Thanks too Bruce for the fzz file… downloading the software now to try it out.
[quote=“gregl, post:13, topic:179912”]Hi Hek,
I think you misunderstood my thought…im all for keeping it in Git - absolutely so! - but rather than have the sketches that others create, stored in the examples of your mysensors library, keep them in a separate repository?
eg:
/mysensors/Arduino
/mysensors/Vera
/mysensors/Raspberry
/mysensors/CommunitySketches ( or similar )
Perhaps you could then permission Communitysketches a little more open to people like me who hack together stuff…but isnt good enough for being under your /examples area.
Cheers,
Greg[/quote]
Ahh, ok I understand!
The great thing about keeping all the examples where they are right now is that you can access them directly from File->Examples->MySensors in the Arduino IDE. If we move them to another location outside the library this won’t work.
I’m sure yours and others contributed examples will be great addition with a little help and feedback. I don’t think we can get too many of them… If two contributed examples solves the same problem I will try to merge and/or select the best one
With github pull-requests it does not really matter where they are located in the repository.
This is really weird, here is a screenshot from a post to this forum thread just before I went to explaining the first pass implementation for the sketch version reporting but there is no record of it in the forum…
