#offAtNight = 0 shows #offAtNight = NULL in Console output

[stumbaumr]

Hi @CurlyMoo,

came across a strange behaviour in my code. Sample Code:

on System#Boot then
   #offAtNight = 0;
   setTimer(10, 40);
end

on timer=10 then
   setTimer(10, 15);
end

The output in the Console shows "#offAtNight = NULL".

After changing the variable name to #sleepAtNight it shows in the Console "#sleepAtNight = 0"...

[CurlyMoo]

Can you check this binary: https://github.com/IgorYbema/HeishaMon/actions/runs/7460559421

[stumbaumr]

My workaround renaming the variable fixed my problem.

I have only one production system here and no test factory, so no, sorry, I can not run test binaries here. If that binary includes a fix I can give feedback as soon as the fix makes it into a release.

[McMagellan]

Your code itself is not the problem. I tested it and couldn't detect the malfunction you described. See console footage below.

Is there perhaps another context in which this error occurs?

The internally constructed variable table of Rules is very unstable. Therefore I don't use more than 12 global variables. Recently I even had the case that after calling up several content changes to global variables from a timer rule, the entire table was destroyed and only 2 of my 12 variables remained.

Rules has many limitations, none of which are documented. All that remains is trial and error and a lot of time. Especially when uploading rules, it can happen that the code is only accepted after changing the name of a variable, for example. The previously used variable table is probably not deleted cleanly and the new upload is then discarded. I then reboot before uploading the new rule.

---

rule #1 was prepared in 1803 microseconds
rule #1 was parsed in 9163 microseconds
bytecode is 79 bytes
rule_function_set_timer_callback set timer #10 to 40 seconds
rule #1 was executed in 1849 microseconds
bytecode is 79 bytes
rule #2 was prepared in 952 microseconds
rule #2 was parsed in 4362 microseconds
bytecode is 50 bytes
rule_function_set_timer_callback set timer #10 to 15 seconds
rule #2 was executed in 5262 microseconds
bytecode is 50 bytes
rules memory used: 804 / 16384
new ruleset successfully parsed

==== SYSTEM#BOOT ====

rule 0 nrbytes: 79
global stack nrbytes: 4
rule_function_set_timer_callback set timer #10 to 40 seconds
rule #1 was executed in 3672 microseconds

local variables

global variables
4 #offAtNight = 0

Sat Jan 20 11:40:46 2024 (45881068): Closing webserver client: 192.168.178.44:64891

.....

Sat Jan 20 11:41:26 2024 (45920749): Measured Watthour on S0 port 1: 3.00
Sat Jan 20 11:41:26 2024 (45920756): Measured total Watthour on S0 port 1: 657786.00
Sat Jan 20 11:41:26 2024 (45920762): Calculated Watt on S0 port 1: 1952

....

rule_function_set_timer_callback set timer #10 to 15 seconds

local variables

global variables

4 #offAtNight = 0

Sat Jan 20 11:41:31 2024 (45925750): Measured Watthour on S0 port 1: 2.00
Sat Jan 20 11:41:31 2024 (45925757): Measured total Watthour on S0 port 1: 657788.00
Sat Jan 20 11:41:31 2024 (45925762): Calculated Watt on S0 port 1: 1954

[CurlyMoo]

Especially when uploading rules, it can happen that the code is only accepted after changing the name of a variable, for example.

This is 99.9% not an issue of the rules library but of the webserver. If you encounter such situations, let me know, then i can look for the issue in the webserver.

Rules has many limitations, none of which are documented.

If you encounter other issues let me know or try the latest library updates that are ready for beta testing to see if it's already fixed.

Besides that, the rules library in the Heishamon is already pretty old in a relative sence. A library update is on it's way, but that doesn't work properly due to something inside the Heishamon itself, not due the rules library. That works as expected.

[McMagellan]

In this file from an excerpt from the Consol you can see that the variable message is displayed two times correctly.
Then a timer is executed in which 7 running timers are reset (8 Jan 8:02:19).
Afterwards all global variables are destroyed except for one.
The propogram continues to run in an undefined state.
Probably too many timers were set within one rule (7 pieces).

Is there a limit?

VariablenCrash1.txt

[CurlyMoo]

@McMagellan Please help test the latest build with the latest rules code. Then we'll see if the issue persists:
#459 (comment)

[McMagellan]

Got it.
Version: Alpha-d9517fa

[McMagellan]

New version discarded.
No rule could be loaded.

See the last 2 lines of the console recording picture befor Console freeze.

Returned to version 3.2.3

[CurlyMoo]

Can you join that thread and post the ruleset you tried there?

[McMagellan]

I tried several long, short rules and none could load.
Attached is the rule in which a reset timer runs after the end of a heat-cycle, which destroys the variable table as described above.

Projekt9.121.txt

[CurlyMoo]

@McMagellan Can you join this thread with your findings? IgorYbema#121

Please post the ruleset that you couldn't get to load there.

[stumbaumr]

My rule set is of course bigger than just that example above...
http://aquarea.smallsolutions.de/index.php?title=Anlage_stumi75#Heishamon_Rules

I just boiled it down to that excerpt as I still could reproduce that NULL value after removing everything else.

So yes, it might be that I got that problem based on using too many variables in the beginning...

[McMagellan]

Ich habe mal über deine Rule geschaut.

1. Im SystemBoot weist du einer globalen Variablen einen Wert aus einer WP- Variablen zu (@...). Zum Zeitpunkt des Neustarts von Heishamon kann es sein, das die @variable noch nicht versorgt sind was zu einem NULL- Wert führt. Besser ist es einen Zwischentimer zu setzen.
2. Du hast 2 Timer die jede Minute gleichzeitig aufgerufen werden. Ich würde Timer 10 anstelle nach 40 Sekunden nach 46 Sekunden starten damit er in der Folge zeitversetzt zu Timer 11 läuft.

z.B.:
Boot:
settimer(1,20);

Timer1:
#xy = @xy;
settimer(10,26);
settimer(11,20);

[stumbaumr]

Zu 1.) Ja, das kann bei einem Neustart der WP oder Heishamons passieren - nach einer Minute löst sich das dann aber auf. Beim Regeln neu abspeichern sorgt das aber dafür, das weiterhin der aktuelle Wert verwendet wird.
Zu 2.) Der eine Timer alle 15 Sekunden, der andere jede Minute - Zeitversatz müsste ich beim System#Boot unterbringen... Mal sehen, bisher läuft das so problemlos.