Time Input to allow choose from global, flow, msg property value
Closed this issue · 11 comments
Thank you for the wonderful library! Due to the lack of maintenance of https://github.com/rdmtc/node-red-contrib-sun-position I managed to migrate all my rather complex flows into this library and it works very well.
There is one limitation that doesn't look like a pull into Swiss-army-knife territory but an organic addition.
Is it possible to upgrade https://github.com/jensrossbach/node-red-contrib-chronos/wiki#time-input to allow you to choose from global, flow, and msg property values? This seems like a nearly canonical feature to most node-red nodes.
So if I have some specific calculated time set in global.my_special_time, I would like to configure Time Switch Node to use something like between Sunrise and global.my_special_time
I'm happy that you like the library and thanks for the idea!
Just want to point out that it's already possible today to load a whole condition from an environment or context variable. Are you aware of this? It's indeed not possible to retrieve only a portion of a condition (like a single time of a time range as in your example) from the context. If the existing functionality is not sufficient and you see this as an important extension of the already provided possibilities, I can surely consider this for one of the next releases.
@jensrossbach thank you for the quick response. Well, I looked into conditions but I can't say it's simple. For the setup I am trying to achieve it seems the wrong tool for the job.
Moreover, it still does not look trivial how to configure my case via conditions. As I see here https://github.com/jensrossbach/node-red-contrib-chronos/wiki/Time-Switch-Node#source the type operand is pretty much the same that is in the UI: "time", "sun", "moon" or "custom".
I thought adding "global, flow, msg" to the UI is a natural approach that goes along nearly every other node in Node-RED, like:
The basic concept of the time switch and the time filter nodes are conditions, so I don't understand how you want to use one of these nodes without using conditions. If you look at https://github.com/jensrossbach/node-red-contrib-chronos/wiki/Time-Switch-Node#examples, you can see examples of conditions loaded from context variables. Adding "global, flow, msg" to one of the operands would lead to pretty much the same configuration except that you would configure only a single operand instead of a whole condition.
What would be your view about how the context variables for the operands as proposed by you should look like? According to the overall concept of this node library, it would be objects similar to the "operands" property of the first example.
Don't get me wrong, I don't want to discuss away your proposal, I just to make sure that you understand the concept behind time switch node and the conditions correctly.
@jensrossbach maybe I don't explain myself well, but my case seems simple. I just want this to work:
For the between condition I want to be able to choose A to be a Sun position (works) and B to be a dynamic (custom) time value, global in my case, but could be in a msg as well (missing feature).
All the examples with operands still refer to time as a static value, like "22:30", where I want it to be dynamic, taken from either global scope or a current msg payload, etc.
Maybe another reference point. Now Time Switch node's Base Time can be configured to take a dynamic value from msg, global, and flow scopes. So if the same ability is allowed for the Time values in conditions, it would make the feature very advanced.
@jensrossbach just noticed that Scheduler node does have this implemented:
so basically the same options in the dropdown I was suggesting to add to Time Switch node's condition values.
Alright, I think we are on the same page, I just wanted to highlight the difference to what is already possible. So I can certainly implement it in this way, there is something similar already existing for scheduler node and state node.
Regarding the format of the context variables and message properties, I propose the following possibilities:
- String containing a parsable datetime
- Number containing a timestamp:
- if < 86400000 it will be interpreted as number of milliseconds elapsed since midnight
- if >= 86400000 it will be interpreted as Unix epoch timestamp (number of milliseconds elapsed since 01/01/1970)
- Object containing properties
type,value,offsetandrandom
@jensrossbach thank you, this sound great! In my case the String value will be something like “21:30” which I hope goes to your first list point.
UPDATE
I found a way to also parse time-only strings with moment.js, so this should be straightforward then.
Ok, in this case I need to consider this because normally the nodes use moment.js to parse the strings but I observed in the past that moment.js seems not to be able to parse time-only strings, only strings containing a date and a time. Therefore I implemented an own parser for the time input fields. But I can use this one as well for such strings from contexts and messages.
Feature has been implemented in release 1.22.
The format for the environment/context/message input is slightly different than described above. I didn't implement the object format but instead I extended the string format. Besides time and date/time, it is also possible to specify sun and moon times in the strings.
@jensrossbach thank you, I am giving it a spin now. The UI looks uniform and as expected. Thank you for the super quick update!