Rules: Clock#Time - possible to compare with a variable?

[JR01]

Hi, how would I use variables to compare to clock time, ie. rather than:

Code: Select all

 On Clock#Time=All,18:25 do // every day at 18:25 hours do ...
  gpio,14,0
 endon
 

What about something like below?:

Code: Select all

// --- variables for ie. the time 20:15
Let,1,20
Let,2,15

 On Clock#Time=All,[VAR#1]:[Var#2] do 
  gpio,14,0
 endon
 

[TD-er]

I think it may work, but make sure you don't use spaces in lines in your rules. (except at start/end of a line and between keywords)
A space is also interpreted as a parameter separator.

If you need to use spaces you can use " " to wrap a parameter.
Maybe you also need to use them here to define your parameter

Code: Select all

 On Clock#Time=All,"[Var#1]:[Var#2]" do

[JR01]

I cannot get this to work, the problem is - when I send a message with mqtt (from Node-RED) - say payload: 12 - does not matter if I choose to send it as a String, or a number, and also does not matter if I Register the homie Received device as a Parameter Type integer, or float, or string, it always stores the payload not as 12, but as 12.00. thus - I cannot use it as a time variable.....

I have created a test message back to mqtt:

Code: Select all

//--------
On doTest do
    TaskValueSet,1,4,%eventvalue%
    Let,1,[VAR#4]
    Publish testing/%sysname%/variables,{eventvalue: %eventvalue%, isAuto:%v1%, durOnManual_min: %v2%, durRest_min: %v3%, startHr1: %v5%, startMin1: %v6%, doLeg1: %v9%, durLeg1: %v13%}
endon
//--------

If I fire up doTest, the message back to mqtt is:

Code: Select all

//--------
On doTest do
    TaskValueSet,1,4,%eventvalue%
    Let,1,[VAR#4]
    Publish testing/%sysname%/variables,{eventvalue: %eventvalue%, isAuto:%v1%, durOnManual_min: %v2%, durRest_min: %v3%, startHr1: %v5%, startMin1: %v6%, doLeg1: %v9%, durLeg1: %v13%}
endon
//--------

As you can see, the eventvalue is 1, not 1.00 for doTest, thus - its not the incoming value causing it, but somewhere in the code the values are changed - ,00 added. Bug?

What now?

[TD-er]

Rounding off to 2 decimals sounds like the default behavior of String class to convert a float to a string.
If you convert an integer type, it should not do it like that.
Just as a test, you may try to store the value in a dummy plugin which does output a long type.
Let's hope this is not somewhere in the code converted to a float....

[JR01]

Just as a test, you may try to store the value in a dummy plugin which does output a long type.
Let's hope this is not somewhere in the code converted to a float....

Tested with Dummy values - pushed from mqtt as well, and it does not add .00 to the values. So, the problem must be as you stated - in P086 ?

[TD-er]

Just as a test, you may try to store the value in a dummy plugin which does output a long type.
Let's hope this is not somewhere in the code converted to a float....

Tested with Dummy values - pushed from mqtt as well, and it does not add .00 to the values. So, the problem must be as you stated - in P086 ?

I don't really know how the Homie plugin does work (never looked through the code thoroughly)
I did now peek at it and noticed there is something strange in parsing integer and float values.
It will parse ints also as if they are float.
In the plugin settings there is also an option to set the number of decimals, however I don't see it being used.
And I guess the controller is just using the normal way of using the number of decimals (which is not stored in the same place as these values) and that default is 2 decimals.

But that's just the first result of a quick peek through the code.
Maybe you could add an issue for it on Github, so the original author of that plugin can look at it?

[JR01]

Maybe you could add an issue for it on Github, so the original author of that plugin can look at it?

Thank you TD-er, will do this, at least you have been able to confirm my suspicions.

I moved away from trying the Homie plugins, to the stock standard ones. It works ....., to push a variable via MQTT to a Dummy variable, and then to user this to trigger in the clock-time On function, as before. Below, varSet1 is the 2nd Dummy device, with quad variables, startHr1, and startMin1, 1st and 2nd task of the device:

Code: Select all

On Clock#Time=All,"[varSet2#startHr1]:[varSet2#startMin1]" do
  event,doNextLeg
endon

Code: Select all

On startHr1 do
    TaskValueSet,2,1,%eventvalue%  
endon
On startMin1 do
    TaskValueSet,2,2,%eventvalue%  
    Let,7,%eventvalue%
endon

It works..... except when the variables are not 2 digits, ie. 06 does not work, but 10 works, even when sent via MQTT as a string, rather than a Number.

So, somewhere in the storage or use of a variable, both if I use one of the 16 internal variables, and a Dummy variable, it changes it to a number, and event Clock#Time only accepts '06' for `06` for the hour, and not `6` - same goes for the minutes?

And, with no text processing functions (for obvious reasons), I cannot say, if < 10 then add a 0 infront of the variable, is their a way to store a String / Text, rather than reducing a String to a Number, in Dummy fields?

[TD-er]

Hmm I have to think about this, since there are several options here, all with their pros and cons.
I think the one with the least impact is to have the rule event appear twice in the rules:

Code: Select all

On Clock#Time=All,"[varSet2#startHr1]:[varSet2#startMin1]" do
...
endon
On Clock#Time=All,"[varSet2#startHr1]:0[varSet2#startMin1]" do
...
endon

[JR01]

okay, that can work, with an if statement to check if the number is smaller than 10....

Let me try that.

[TD-er]

I don't think an if statement is needed here to check for number of digits.

For example "12:012" will never match, or else we may have a bug here
Also "12:1" also does not match, like you already noticed.

[JR01]

Ahh, less code ! The if works, so this will work as well. Thank you.

[HarpieC]

I Register the homie Received device as a Parameter Type integer, or float, or string, it always stores the payload not as 12, but as 12.00. thus - I cannot use it as a time variable.....

Float values should be passed via %eventvalue% correctly as float by the homie plugin. There will be an updated version soon showing floats and other values correctly with many bugfixes and improvements. I currently work on a Node-RED custom node to have something to communicate with as openHAB is still unreliable for me (rendering devices offline which are working perfectly and other problems).

2019-09-13 18_27_27-Window.png (5.73 KiB) Viewed 22815 times

2019-09-13 18_28_40-Window.png (2.14 KiB) Viewed 22815 times

Perhaps the docs can help https://espeasy.readthedocs.io/en/lates ... #p086-page
Please give me a little bit more time to perform more tests.

[JR01]

There will be an updated version soon showing floats and other values correctly with many bugfixes and improvements

Cannot wait!! Thank you.

[TD-er]

Yesterday I was going through the rules parser functions and came across the "transformation" options we have.
I knew we had them, but since they were never documented, I also documented them (in a PR not yet merged)

I think it should also solve the original issue here with a bit more elegance by adding leading zeroes.

This is the part I added to the documentation:

Formatting referred values
When referring another value, some basic formatting can be used.

Referring a value using some pre-defined format: [TaskName#ValueName#transformation#justification]

Transformation
Transformations are case sensitive. (M differs from m, capital is more verbose)
Most transformations work on “binary” values (0 or 1)
A “binary” transformation can be “inverted” by adding a leading !.
A “binary” value is considered 0 when its string value is “0”, otherwise it is an 1. (best to round a value to 0 decimals for this)
Binary transformations:

C: 0 => “CLOSE” 1 => ” OPEN”
H: 0 => “COLD” 1 => ” HOT”
I: 0 => “OUT” 1 => ” IN”
M: 0 => “AUTO” 1 => ” MAN”
m: 0 => “A” 1 => “M”
O: 0 => “OFF” 1 => ” ON”
U: 0 => “DOWN” 1 => ” UP”
u: 0 => “D” 1 => “U”
V: value = value without transformations
X: 0 => “O” 1 => “X”
Y: 0 => ” NO” 1 => “YES”
y: 0 => “N” 1 => “Y”
Z: 0 => “0” 1 => “1”
Floating point transformations:

Dx.y: Minimal ‘x’ digits zero filled & ‘y’ decimal fixed digits. E.g. D1.3
Dx: Minimal ‘x’ digits zero filled in front of the decimal point, no decimal digits. Same as Dx.0
D.y: Same as D0.y
F: Floor (round down)
E: cEiling (round up)
Justification
Pn: Prefix Fill with n spaces.
Sn: Suffix Fill with n spaces.
Ln: Left part of the string, n characters.
Rn: Right part of the string, n characters.
Ux.y: Substring Ux.y where x=firstChar and y=number of characters.

Meaning...

Code: Select all

 On Clock#Time=All,"[Var#1]:[Var#2]" do

Could be changed into:

Code: Select all

 On Clock#Time=All,"[Var#1]:[Var#2#D2]" do

While writing this I just realized it would be very practical to also have these translations on other values than just the task-value-references.
So I will also add it for references to [Var#n] types which I believe will make the rules quite a bit more powerful.
It will be included in PR https://github.com/letscontrolit/ESPEasy/pull/2617

[JR01]

Wow, this is can be good for Rules.... Assume it will end up https://espeasy.readthedocs.io/en/latest/ here?

[grovkillen]

Yes I will add that.

[TD-er]

Yes I will add that.

Have you looked at the PR I am preparing?
Will save you some time I guess

[grovkillen]

Yep I have, thanks TD-er!

I've been doing some programming behind the scenes to get all these into the syntax highlight of the new rules editor.