Node-red-contrib-simpletime enhancement

[cymplecy]

Carrying on from this thread

Easy way of adding only mytimes to a msg

The node-red-contrib-simpletime does what its says on the packet and returns the current (DST corrected) time [image] Instead of writing my own boiler plate code to add hh:mm:ss to status/logging messages I'd thought I'd just use this node in the flow and just add in mytimes but I'm struggling to come up with a simple way of doing it without adding in all the others as well Any clever/simple ideas?

@Paul-Reed

It occurs to me anyway, that being able to just use simpletime for single/partial myXXXXX payloads by having a set of tick boxes would be an enhancement for the node (default being all of course)

What do you think?

I'd do the work to acheive it and send your a PR if you approve the concept

[Paul-Reed]

@cymplecy

having a set of tick boxes would be an enhancement for the node

Sounds good to me

I've added a feature branch - tickboxes to the repo, so we can see what it looks like.

[cymplecy]

I think I've tested it out enough on my systems (3 of them inc new beta) and I'm happy that it works so PR on its way

I incremented version to 2.9.2 - having found out that saying 2.9.1_cymplecy doesn't work

If you publish it as is, it'd be nice if you could increment it again so I can tell difference on my systems

[cymplecy]

PS Other edits just to replace tab spacing with 4 space spacing on a couple of lines

[Paul-Reed]

Nice work Simon!
I've merged it into the tickboxes feature branch, which can be loaded by;

cd .node-red
npm install Paul-Reed/node-red-contrib-simpletime#tickboxes

It will then overwrite your existing version.
EDIT - now merged into master branch.

Don't know if it's even possible... but it would be nice to have select none & select all button/link/whatever in the node properties???

[cymplecy]

@Paul-Reed

Don't know if it's even possible... but it would be nice to have select none & select all button/link/whatever in the node properties???

Drat - I was hoping to slip that past you

Can I suggest that once your happy with the modification and have merged it into the main branch - you then create another new branch (I've already deleted my fork) and I'll fork that and then work out how add those options?

On another note - I could do with having a yymmdd option for writing stuff to my logging system(and therefore maybe there should be a yyyymmdd and a yyyy-mm-dd ones as well?)

And I'm contemplating asking for a hh:mm:ss.zzz one as well but only for completeness - I'm not sure I can fully justify it but I just think that maybe it should be there?

[Paul-Reed]

@cymplecy

and have merged it into the main branch - you then create another new branch

Merged into Master branch and a new tickboxes branch added.

@cymplecy

On another note - I could do with having a yymmdd option for writing stuff to my logging system(and therefore maybe there should be a yyyymmdd and a yyyy-mm-dd ones as well?)

I started off with the intentions of just providing the basic elements, with a view to any combination of the elements then being constructed using a template node, but a few combinations crept in....
However, I quickly realised that there are countless combinations of those elements, and potentially the node could become swamped with options as different users request different elements in different orders, some with hyphens, some with slashes, etd, so would prefer if possible to avoid, unless it's something which is a well used standard date/time format, or something that couldn't be easily constructed.
Does that make sense?

[cymplecy]

@Paul-Reed

Does that make sense?

Fully
Can I make my case

1. I'll accept just getting one variation added if I can

2. So, you have mytime hh:mm and mytimes hh:mm:ss but no equivalent yy-mm-dd type date - to get the date - you either have to concat 3 properties or (even worse) substring myrawdate and get the "wrong" date as myrawdate is not local DST corrected

So I think its a fundamental missing property

I'd vote for yymmdd personally (as its shortest I can use in logging) but happy to accept yy-mm-dd or yyyymmdd or yyyy-mm-dd if you accept the basic proposal

I rest my case

[Paul-Reed]

ISO-8601 recommends a locale neutral date format of yyyy-mm-dd so yes, let's go with that.

[cymplecy]

@cymplecy

I incremented version to 2.9.2 - having found out that saying 2.9.1_cymplecy doesn't work

If you publish it as is, it'd be nice if you could increment it again so I can tell difference on my systems

Cough............................

[dceejay]

You should be able to call it what you like. But you will have to use the exact name to install it.

[cymplecy]

I'm a bit (more ) confused now - when I tried changing node version number in the branch I was using from 2.9.1 to 2.9.1_cymplecy , I then couldn't install it using npm install

Got a very wierd error that didn't make a lot sense (end of stream??? something wierd like that anyway)

When I changed it to 2.9.2 - I could then do an npm install

[Paul-Reed]

@cymplecy

If you publish it as is, it'd be nice if you could increment it again

I haven't published it to npm yet, only committed it to the git repo.
You don't need to increment the package, as I will sort out the semantic version prior to publishing it.
The version number shouldn't affect your local installation, as I assume you are installing it from git, ie from my repo it would be as below, but you'll be using your repo.

cd .node-red
npm install Paul-Reed/node-red-contrib-simpletime#tickboxes

[cymplecy]

I've lost the plot now
I'll wait to see what happens when the github/npm publishing dust has settled and then come back if I've got an issue

[Paul-Reed]

@cymplecy

I've lost the plot now

If you make a fork of the simpletime repo, you can then install it over the top of your existing simpletime node that you have already installed in your node-RED installation,

cd .node-red
npm install cymplecy/node-red-contrib-simpletime

It doesn't matter about the version, it will update it regardless.Then you make whatever changes you need locally.
If you later decide to create a PR, it doesn't matter if it's to the master or feature branch, as I can switch branches here.

When all the changes are in master, then I'll sort out the versioning and publish it to npm.

Hope that make sense.

[Paul-Reed]

@cymplecy have you found the changes backwards compatible.
I've just updated my 2nd system with the latest, and it broke my flows.

Opening the properties of my existing simpletime nodes, all of the options were unticked,

Adding a new simpletime node, they are all selected, however existing nodes are deselected?

[dceejay]

In the oneditprepare you will need to check if each of the new properties is undefined and if so set it to its default.

[cymplecy]

On it - re-forking
..................................

I thought I might need to do something but when I did my final testing I couldn't get them to not be filled in

Trying to make sure I can replicate the issue before I commit any more code

I went back to see what was needed when I was contributing to neopixel node so hopefully this is the syntax I'll need for each myXXXX

        oneditprepare: function() {
            if (this.mydate === undefined) {
                this.mydate = true;
                $("#node-input-mydate").prop('checked', true);
            }
        }

[Paul-Reed]

@cymplecy

so hopefully this is the syntax I'll need for each

So if that ensures backwards compatibility when upgrading, just wondering if the default state for the checkboxes -

mydate: {value:true},

should be all ticked or all unticked - is it easier to tick the ones that you want, or remove the ticks that you don't want.

What do you think?

EDIT - Having thought about this, I agree with Si, must be 'all ticked'.

[cymplecy]

for compatibility - I think they should all be ticked so that same result as previous version

That's what I was aiming for

My testing technique obviously failed me so just developing a repeatable setup at moment that fails like what happened to you and then works when I've fixed it