Proposal - Sketch version and name reporting feature

Hek,

I have completed a first pass at implementing the sketch version reporting feature and am posting it here for some early feedback because I am open to adjusting it to meet your standards or wishes. Below is a summary of the changes and an attachment that shows the new UI:

[ul][li]I ended up adding both a Sketch Name and a Sketch Version internal-message variables because my initial tests only allowed me to transfer 13 characters (interestingly enough, tonight, I was able to transfer the expected 25 characters [32 - 7-byte message protocol header] after syncing my forked repo with your upstream master branch). Anyway, separating them may be bit a more future-proof in case some-day, you want to be able to alert users to sensors that are out-of-date with respect to some public version database on MySensors.org. Also, given the limited UI space, breaking the name and version a part, seemed a bit easier for limited layout[/li]
[li]There are 3 new sensor methods - sendSketchName(const char *name), sendSketchVersion(const char *version) and sendSketchInfo(const char *name, const char *version). sendSketchInfo() is a convenience method that simply calls the other two methods and is what should normally be called by the users in the setup method.[/li]
[li]I’m not sure about the UI - see below. We can either go with as is (but I need your help to avoid the ellipses “…” on the SketchVersion - I’m missing something simple) or I can change the layout back to your original layout but try to place a concatenated sketch name and version in the lower-right corner of the Arduino Node… One can also envision using the Sketch Name for the Node…[/li][/ul]

Sensor.h changes

        /**
         * Sends sketch info to sensor net gateway for this radio node.
         * A sensor node sketch should normally call this method during setup() anytime after calling begin()
         * @param name String containing a short Sketch name
         * @param version String containing a short Sketch version
         */
        void sendSketchInfo(const char *name, const char *version);

        /**
         * Sends sketch name to sensor net gateway for this radio node.
         * @param info String containing a short Sketch name and version
         */
        void sendSketchName(const char *name);

        /**
         * Sends sketch version to sensor net gateway for this radio node.
         * @param info String containing a short Sketch name and version
         */
        void sendSketchVersion(const char *version);

Sensor.cpp changes

void Sensor::sendSketchInfo(const char *name, const char *version) {
        sendSketchName(name);
        sendSketchVersion(version);
}

void Sensor::sendSketchName(const char *name) {
        if (name != NULL)
                sendInternal(I_SKETCH_NAME, name);
}

void Sensor::sendSketchVersion(const char *version) {
        if (version != NULL)
                sendInternal(I_SKETCH_VERSION, version);
}

Alternatives to consider. Thinking about this from a sensor user/developer “keep it simple stupid” stand-point, it might be better to implement the name and version as Sensor class properties that can be used by the Begin() method to send the name and version to the gateway akin to what it does for the node presentation; and either change the sendSketchInfo() to setSketchInfo() or add the name and version as arguments to the Sensor constructor so the instance variables are guaranteed to be set before Begin() is called. Another, somewhat less desirable from best-practices stand-point, but effective option would be to set them as #defines or global static constants at the top of the file… So for example, currently, a sensor sketch can do the following in setup after Begin():

setup() {
     ...
     gw.begin(...)
     ...
     gw.sendSensorInfo("DimmableLED", "1.0"); 
     ....
}

but this entails the user explicitly adding code to report the sensor node sketch and version when maybe it should be more declarative and the Sensor class should take care of the rest when it sends the node presentation to the gateway. For example, in the header of the file, the user could set the following globals to be used by Sensor::Begin(); yes, these could be #defines.

const char *sensorName = “DimmableLED”
const char *sensorVersion = “1.0”

This boils down to the following 3 design decisions:

[ol][li]Single I_SKECTH_VERSION internal variables or 2 - I_SKETCH_NAME and I_SKETCH_VERSION[/li]
[li]Usage pattern - declare as constants in file header that are used by Sensor::begin() to send to gateway or gw.sendSensorInfo in the setup() method.[/li]
[li]UI as is with some cleanup or change dashboard view or change in some other way (e.g. revert to original layout but place “Name Version” in lower-right corner)
[/li][/ol]

I look forward to your thoughts so I can take another pass and submit a pull request.

Once this is a bit closer, I will commit to my fork repo and send you a pull request so you can do a formal code review.

Best,
Bruce

Looks really good Bruce!

Regarding ellipses problem… have a look at the “x”-property in the json file. It has a confusing name as it sets the width of the field (if I remember correctly).

I would also like to squeeze in a “Last Report”-field. But it looks like it could fit at the bottom?
Also don’t forget to do a similar changes to the Relay node device file.

I have no problem with the names you have selected for the new methods. They look good! Regarding the option of setting them as class variables… I would prefer avoiding this as these are typical fire-and-forget properties and I see no need to store them in the class as we (probably) wont have any use for them later in the life of the sketch.
Setting sketch name/version should also be optional.

Great!

/Henrik

Henrik,

Thanks for the quick-turn feedback.

Thanks for the pointer. Either the docs on UI layout are weak or I am in the slow group; I hope it is the former and not the latter :wink:

I will ensure that there is enough room. I don’t know if it is possible, but it would be cool if the last update would change color (e.g. red) if the elapsed time since the last update exceeds some threshold to provide a visual cue. ***Update - could change the icon for a visual cue too - see http://wiki.micasaverde.com/index.php/Luup_plugin_icons ***

Got it! I guess I will have to gin up a Relay Node for testing :wink:

[quote=“hek, post:2, topic:179974”]I have no problem with the names you have selected for the new methods. They look good! Regarding the option of setting them as class variables… I would prefer avoiding this as these are typical fire-and-forget properties and I see no need to store them in the class as we (probably) wont have any use for them later in the life of the sketch.
Setting sketch name/version should also be optional.[/quote]

Ok, fire and forget it is. I was just thinking ahead that they could be queriable by the Gateway node in the future but if that need arises, the respective sendSketchXXX() method can set the class properties.

The Sketch Info is optional - the Gateway will show a place for each on the Arduino Node but there won’t be an associated variable - is that what you were thinking?

Also, should I zip through the existing sensors and add the gw.sendSensorInfo() as part of my pull request? If so, what should the default version be? 1.0?

Finally, it looks like the first pass is pretty close so I will try to wrap this up tonight when I get home and submit a pull request.

Color of tex is not possible (I think), but changing the icon could be a good visual feedback!

Yes.

Yes, the field will just remain empty for sketches not sending in any version/name variable. You don’t have to make anything special for this to work. It’s the default behavior of the Service/Variable-fields in the json.

You can do this later if you want. No Hurry.

That sounds great.

Cheers
H

Hi Henrik,

UI layout cleanup done for the Arduino Node and Relay Node sketch-version reporting and UI implemented as well (see images below).

That said, I didn’t have as much time tonight as I had hoped due to work obligations so I am going to take some time tomorrow night (PST) to rebase with your MySensors.org Arduino and Vera git repos and perform some final testing before I submit the pull request but other than final regression testing, this feature branch is complete.

I will submit the pull request tomorrow night PST.

Best,
Bruce

There is no hurry,

I were fiddling with integration of CLAHub/GitHub yesterday night for handling MySensors Contributor License Agreements (CLA). I hope it works now and is smooth to use… you will be the first to test it :slight_smile:

Yeah, but this is a good learning experience and I’m pushing myself to wrap it up in my limited spare time so I understand how this all works end-to-end so to speak and can get back to finishing some sensor work. :wink:

Cool! Anything I contribute is yours to do with whatever you want - I lay no claim to it whatsoever. I am just having fun and trying to contribute a little something back to your awe-inspiring gift to the automation community. This project has virtually eliminated all previous Z-Wave/Vera limitations and for that, I am extremely grateful and feel compelled to somehow give something back to you and the community; plus, did I mention that I am having fun?

Happy to be the first one to test the CLAHub; there have been a lot of firsts for me on this adventure and look forward to more.

Cheers,
Bruce

Cool! Anything I contribute is yours to do with whatever you want - I lay no claim to it whatsoever. I am just having fun and trying to contribute a little something back to your awe-inspiring gift to the automation community. This project has virtually eliminated all previous Z-Wave/Vera limitations and for that, I am extremely grateful and feel compelled to somehow give something back to you and the community; plus, did I mention that I am having fun?[/quote]

One shouldn’t underestimate the fun part!

Just a small explanation and clarification about CLAs for everyone that is interested in legal stuff ::).

[i]As a contributor you retain ownership of the copyright in your contribution and have the same rights to use or license the contribution which you would have had without entering into the Agreement

But you also grant to the MySensors project a perpetual, worldwide, non-exclusive, transferable, royalty-free, irrevocable license under the copyright covering the contribution (read full agreement below).
[/i]

This is important to keep the MySensors project clear of future problems.

Here is the full agreement I use for MySensors.org:
Welcome to RunCloud

Bruces new feature has now successfully been merged.

Thanks Bruce and have a nice weekend!

Thanks Henrik - you made the process to contribute as smooth as silk :wink: I hope others join in the fun soon!