Code: Select all

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

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
```

**Moderators:** grovkillen, Stuntteam, TD-er

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

What about something like below?:

Code: Select all

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

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
```

Last edited by JR01 on 02 Sep 2019, 18:46, edited 2 times in total.

-----------

IOTPLAY. Tinkerer, my projects are @ http://GitHub.com/IoTPlay . Using RPi, Node-Red, ESP8266 to prove Industry 4.0 concepts.

IOTPLAY. Tinkerer, my projects are @ http://GitHub.com/IoTPlay . Using RPi, Node-Red, ESP8266 to prove Industry 4.0 concepts.

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

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
```

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:

If I fire up doTest, the message back to mqtt is:
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?

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
//--------
```

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
//--------
```

What now?

-----------

IOTPLAY. Tinkerer, my projects are @ http://GitHub.com/IoTPlay . Using RPi, Node-Red, ESP8266 to prove Industry 4.0 concepts.

IOTPLAY. Tinkerer, my projects are @ http://GitHub.com/IoTPlay . Using RPi, Node-Red, ESP8266 to prove Industry 4.0 concepts.

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....

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....

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 ?

-----------

IOTPLAY. Tinkerer, my projects are @ http://GitHub.com/IoTPlay . Using RPi, Node-Red, ESP8266 to prove Industry 4.0 concepts.

IOTPLAY. Tinkerer, my projects are @ http://GitHub.com/IoTPlay . Using RPi, Node-Red, ESP8266 to prove Industry 4.0 concepts.

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?

Thank you TD-er, will do this, at least you have been able to confirm my suspicions.Maybe you could add an issue for it on Github, so the original author of that plugin can look at it?

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
```

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,

IOTPLAY. Tinkerer, my projects are @ http://GitHub.com/IoTPlay . Using RPi, Node-Red, ESP8266 to prove Industry 4.0 concepts.

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:

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
```

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

Let me try that.

Let me try that.

IOTPLAY. Tinkerer, my projects are @ http://GitHub.com/IoTPlay . Using RPi, Node-Red, ESP8266 to prove Industry 4.0 concepts.

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.

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.

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

IOTPLAY. Tinkerer, my projects are @ http://GitHub.com/IoTPlay . Using RPi, Node-Red, ESP8266 to prove Industry 4.0 concepts.

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). 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.

Cannot wait!! Thank you.There will be an updated version soon showing floats and other values correctly with many bugfixes and improvements

IOTPLAY. Tinkerer, my projects are @ http://GitHub.com/IoTPlay . Using RPi, Node-Red, ESP8266 to prove Industry 4.0 concepts.

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:
Could be changed into:
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

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:

Meaning...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.

Code: Select all

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

Code: Select all

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

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

Users browsing this forum: No registered users and 16 guests