Additional fixes to rules and docs

[CurlyMoo]

No description provided.

[stumbaumr]

Running with Alpha-0776a05 currently.
Attached are my rules and the logfile when DHW production begins.

Problem:
Both #targetLowBeforeDHW and #targetHighBeforeDHW are set to @Z1_Heat_Curve_Target_High_Temp, even though the code looks like this:

   elseif @Operating_Mode_State < 3 then
      print(concat('@Operating_Mode_State (<3): ', @Operating_Mode_State));
      #stateBeforeDHW = @Heatpump_State;
      #opModeBeforeDHW = @Operating_Mode_State;
      if %hour == 13 && %minute == 00 then
         print('Activating DHW production.');
         #targetLowBeforeDHW = @Z1_Heat_Curve_Target_Low_Temp;
         #targetHighBeforeDHW = @Z1_Heat_Curve_Target_High_Temp;

Check logfile starting at 12:59:59. And at 12:57:19 is the last Z1_Heat_Curve_Target_High_Temp: 40 value display.
HeishaMon-Variable-set-wrong-log.txt
Heishamon Rules

[CurlyMoo]

Next step would be printing the actual values of the curves to see if they are not the issue.

  print('Activating DHW production.');
+ print(@Z1_Heat_Curve_Target_Low_Temp, ' - ', @Z1_Heat_Curve_Target_High_Temp);

[CurlyMoo]

What is also see is a delayed SetCurves just before the wrong values are set. Could be that this is a synchronisation issue.

Mon Jun 10 13:00:00 2024 (13749824): SetCurves JSON received ok
Mon Jun 10 13:00:00 2024 (13749828): Already sending data. Buffering this send request

[CurlyMoo]

And @McMagellan is a lot better in finding issues in the rulesets.

[McMagellan]

@stumbaumr
Is this function reproducible?
I can't find any errors in the rule. But the log file ends here too early. Since you issue 4 commands at the same time but only one is processed at a time and you always wait for the response, the following commands are buffered and there is a longer delay in the response.

About the error:
The lines in Rule/Timer 12:
#targetLowBeforeDHW = @Z1_Heat_Curve_Target_Low_Temp;
#targetHighBeforeDHW = @Z1_Heat_Curve_Target_High_Temp;
are correct and clear.

It would now be interesting to know how these lines are stored in memory after parsing.
I suspect that the reference to the variable "@Z1_Heat_Curve_Target_High_Temp;"
should point to another memory address, e.g. "@Z1_Heat_Curve_Target_Low_Temp;".

@CurlyMoo
Is there a way to take a dump to see the parsing results?
I also had a similar malfunction that could have such a cause, but it wasn't reproducible.
Is there a limit to the length of a # variable name?

[CurlyMoo]

Is there a way to take a dump to see the parsing results?

Not easily at the moment.

But here you go:

rule #1 bytecode was created in 0.000276 seconds
bytecode: 88/88, heap: 52/52, stack: 4/4 bytes, varstack: 96/96 bytes
 0	OP_SETVAL	1	-1	0	
 1	OP_SETVAL	2	-2	0	
 2	OP_SETVAL	3	-3	0	
 3	OP_SETVAL	4	-4	0	
 4	OP_SETVAL	5	-1	0	
 5	OP_PUSH		-5	0	0	 // 2
 6	OP_PUSH		-6	0	0	 // 2
 7	OP_CALL		-12	8	0	 // 2
 8	OP_CLEAR	0	0	0	
 9	OP_PUSH		-7	0	0	 // 1
10	OP_PUSH		-4	0	0	 // 1
11	OP_CALL		-12	8	0	 // 1
12	OP_CLEAR	0	0	0	
13	OP_PUSH		-8	0	0	 // 2
14	OP_PUSH		-9	0	0	 // 2
15	OP_CALL		-12	8	0	 // 2
16	OP_CLEAR	0	0	0	
17	OP_PUSH		-10	0	0	 // 1
18	OP_PUSH		-11	0	0	 // 1
19	OP_CALL		-12	8	0	 // 1
20	OP_CLEAR	0	0	0	
21	OP_RET		0	0	0	

 1	VINTEGER	1
 2	VINTEGER	0
 3	VINTEGER	32
 4	VINTEGER	40
 5	VINTEGER	10
 6	VINTEGER	35
 7	VINTEGER	11
 8	VINTEGER	12
 9	VINTEGER	41
10	VINTEGER	13
11	VINTEGER	42
12	VNULL

rule #2 bytecode was created in 0.000034 seconds
bytecode: 20/20, heap: 12/12, stack: 4/12 bytes, varstack: 144/144 bytes
 0	OP_GETVAL	-1	7	0	
 1	OP_SETVAL	3	-1	0	
 2	OP_GETVAL	-2	8	0	
 3	OP_SETVAL	4	-2	0	
 4	OP_RET		0	0	0	

 1	VNULL
 2	VNULL

rule #3 bytecode was created in 0.002474 seconds
bytecode: 224/224, heap: 48/48, stack: 4/12 bytes, varstack: 336/336 bytes
 0	OP_PUSH		-1	0	0	 // 2
 1	OP_PUSH		-2	0	0	 // 2
 2	OP_CALL		-9	8	0	 // 2
 3	OP_CLEAR	0	0	0	
 4	OP_GETVAL	-10	12	0	 // 1
 5	OP_GETVAL	-11	13	0	 // 1
 6	OP_SUB		-10	-10	-11	 // 1
 7	OP_GETVAL	-11	11	0	
 8	OP_SUB		-10	-11	-10	
 9	OP_SETVAL	10	-10	20	
10	OP_GETVAL	-10	10	0	 // 2
11	OP_PUSH		-10	0	0	 // 2
12	OP_CALL		-10	4	0	 // 2
13	OP_SUB		-10	-10	-3	
14	OP_SETVAL	14	-10	20	
15	OP_SETVAL	15	-4	20	
16	OP_GETVAL	-10	16	0	
17	OP_GE		-10	-10	-5	
18	OP_JMP		20	0	0	
19	OP_SETVAL	15	-6	0	
20	OP_GETVAL	-9	16	0	
21	OP_GE		-9	-9	-7	
22	OP_JMP		24	0	0	
23	OP_SETVAL	15	-8	0	
24	OP_GETVAL	-10	10	0	
25	OP_LT		-10	-10	-4	
26	OP_JMP		31	0	0	
27	OP_PUSH		21	0	1	 // 1
28	OP_CALL		-9	7	0	 // 1
29	OP_CLEAR	0	0	0	
30	OP_SETVAL	15	-4	0	
31	OP_GETVAL	-9	14	0	
32	OP_LT		-9	-9	-4	
33	OP_JMP		35	0	0	
34	OP_SETVAL	14	-4	0	
35	OP_GETVAL	-9	14	0	
36	OP_GT		-9	-9	-5	
37	OP_JMP		43	0	0	
38	OP_SETVAL	14	-5	0	
39	OP_GETVAL	-9	5	0	
40	OP_EQ		-9	-9	-3	
41	OP_JMP		43	0	0	
42	OP_SETVAL	5	-6	0	
43	OP_GETVAL	-9	17	0	
44	OP_GETVAL	-10	15	0	
45	OP_NE		-9	-9	-10	
46	OP_JMP		49	0	0	
47	OP_GETVAL	-9	15	0	
48	OP_SETVAL	18	-9	0	
49	OP_GETVAL	-10	13	0	
50	OP_GETVAL	-11	14	0	
51	OP_NE		-10	-10	-11	
52	OP_JMP		55	0	0	
53	OP_GETVAL	-9	14	0	
54	OP_SETVAL	19	-9	0	
55	OP_RET		0	0	0	

 1	VINTEGER	11
 2	VINTEGER	30
 3	VINTEGER	1
 4	VINTEGER	0
 5	VINTEGER	5
 6	VINTEGER	2
 7	VINTEGER	8
 8	VINTEGER	3
 9	VNULL
10	VNULL
11	VNULL

rule #4 bytecode was created in 0.006997 seconds
bytecode: 496/496, heap: 92/92, stack: 4/12 bytes, varstack: 720/720 bytes
 0	OP_PUSH		-1	0	0	 // 2
 1	OP_PUSH		-2	0	0	 // 2
 2	OP_CALL		-18	8	0	 // 2
 3	OP_CLEAR	0	0	0	
 4	OP_SETVAL	22	-3	0	
 5	OP_SETVAL	23	-4	0	
 6	OP_SETVAL	24	-5	0	
 7	OP_SETVAL	25	-6	0	
 8	OP_GETVAL	-18	16	0	 // 1
 9	OP_GETVAL	-19	24	0	 // 2
10	OP_GETVAL	-20	22	0	 // 2
11	OP_SUB		-19	-19	-20	 // 2
12	OP_GETVAL	-20	25	0	 // 1
13	OP_GETVAL	-21	23	0	 // 1
14	OP_SUB		-20	-20	-21	 // 1
15	OP_GETVAL	-21	23	0	 // 1
16	OP_SUB		-18	-18	-21	 // 1
17	OP_MUL		-18	-18	-19	 // 2
18	OP_DIV		-18	-18	-20	 // 2
19	OP_GETVAL	-19	22	0	 // 1
20	OP_ADD		-18	-19	-18	 // 1
21	OP_PUSH		-18	0	0	 // 1
22	OP_CALL		-18	3	0	 // 1
23	OP_SETVAL	26	-18	0	
24	OP_GETVAL	-19	16	0	
25	OP_GETVAL	-20	23	0	
26	OP_LE		-19	-19	-20	
27	OP_JMP		30	0	0	
28	OP_GETVAL	-18	22	0	
29	OP_SETVAL	26	-18	0	
30	OP_GETVAL	-19	16	0	
31	OP_GETVAL	-20	25	0	
32	OP_GE		-20	-19	-20	
33	OP_JMP		36	0	0	
34	OP_GETVAL	-18	24	0	
35	OP_SETVAL	26	-18	0	
36	OP_GETVAL	-19	27	0	
37	OP_GE		-19	-19	-7	
38	OP_JMP		87	0	0	
39	OP_PUSH		39	0	1	 // 2
40	OP_GETVAL	-18	27	0	 // 2
41	OP_PUSH		-18	0	0	 // 2
42	OP_CALL		-18	6	0	 // 2
43	OP_PUSH		-18	0	0	 // 1
44	OP_CALL		-18	7	0	 // 1
45	OP_CLEAR	0	0	0	
46	OP_GETVAL	-19	28	0	
47	OP_GETVAL	-20	29	0	
48	OP_GT		-20	-19	-20	
49	OP_JMP		86	0	0	
50	OP_PUSH		40	0	1	 // 2
51	OP_GETVAL	-18	28	0	 // 2
52	OP_PUSH		-18	0	0	 // 2
53	OP_PUSH		41	0	1	 // 2
54	OP_GETVAL	-19	29	0	 // 2
55	OP_PUSH		-19	0	0	 // 2
56	OP_CALL		-19	6	0	 // 2
57	OP_PUSH		-19	0	0	 // 1
58	OP_CALL		-19	7	0	 // 1
59	OP_CLEAR	0	0	0	
60	OP_GETVAL	-20	30	0	
61	OP_EQ		-20	-20	-8	
62	OP_JMP		86	0	0	
63	OP_PUSH		42	0	1	 // 2
64	OP_GETVAL	-18	30	0	 // 2
65	OP_PUSH		-18	0	0	 // 2
66	OP_CALL		-18	6	0	 // 2
67	OP_PUSH		-18	0	0	 // 1
68	OP_CALL		-18	7	0	 // 1
69	OP_CLEAR	0	0	0	
70	OP_GETVAL	-19	1	0	
71	OP_SETVAL	31	-19	29	
72	OP_GETVAL	-19	2	0	
73	OP_SETVAL	32	-19	29	
74	OP_PUSH		-9	0	0	 // 2
75	OP_PUSH		-10	0	0	 // 2
76	OP_CALL		-19	8	0	 // 2
77	OP_CLEAR	0	0	0	
78	OP_PUSH		-11	0	0	 // 1
79	OP_PUSH		-12	0	0	 // 1
80	OP_CALL		-20	8	0	 // 1
81	OP_CLEAR	0	0	0	
82	OP_PUSH		-13	0	0	 // 2
83	OP_PUSH		-14	0	0	 // 2
84	OP_CALL		-21	8	0	 // 2
85	OP_CLEAR	0	0	0	
86	OP_JMP		123	0	0	
87	OP_GETVAL	-18	27	0	
88	OP_LT		-18	-18	-7	
89	OP_JMP		123	0	0	
90	OP_PUSH		43	0	1	 // 1
91	OP_GETVAL	-18	27	0	 // 1
92	OP_PUSH		-18	0	0	 // 1
93	OP_CALL		-18	6	0	 // 1
94	OP_PUSH		-18	0	0	 // 2
95	OP_CALL		-18	7	0	 // 2
96	OP_CLEAR	0	0	0	
97	OP_GETVAL	-19	33	0	
98	OP_SETVAL	1	-19	26	
99	OP_GETVAL	-20	27	0	
100	OP_SETVAL	2	-20	26	
101	OP_GETVAL	-21	35	0	
102	OP_EQ		-21	-21	-8	
103	OP_GETVAL	-22	34	0	
104	OP_EQ		-22	-22	-15	
105	OP_AND		-21	-22	-21	
106	OP_JMP		123	0	0	
107	OP_PUSH		44	0	1	 // 1
108	OP_CALL		-18	7	0	 // 1
109	OP_CLEAR	0	0	0	
110	OP_GETVAL	-19	7	0	
111	OP_SETVAL	3	-19	11	
112	OP_GETVAL	-20	8	0	
113	OP_SETVAL	4	-19	9	
114	OP_GETVAL	-21	29	0	
115	OP_GETVAL	-22	26	0	
116	OP_NE		-21	-21	-22	
117	OP_JMP		120	0	0	
118	OP_GETVAL	-18	26	0	
119	OP_SETVAL	36	-18	0	
120	OP_SETVAL	32	-16	0	
121	OP_SETVAL	31	-17	0	
122	OP_SETVAL	37	45	0	
123	OP_RET		0	0	0	

 1	VINTEGER	12
 2	VINTEGER	30
 3	VINTEGER	42
 4	VINTEGER	10
 5	VINTEGER	50
 6	VINTEGER	25
 7	VINTEGER	3
 8	VINTEGER	0
 9	VINTEGER	20
10	VINTEGER	210
11	VINTEGER	21
12	VINTEGER	330
13	VINTEGER	22
14	VINTEGER	480
15	VINTEGER	13
16	VINTEGER	4
17	VINTEGER	1
18	VNULL
19	VNULL
20	VNULL
21	VNULL
22	VNULL

rule #5 bytecode was created in 0.000077 seconds
bytecode: 56/56, heap: 24/24, stack: 4/24 bytes, varstack: 800/800 bytes
 0	OP_PUSH		48	0	1	 // 2
 1	OP_GETVAL	-3	4	0	 // 2
 2	OP_PUSH		-3	0	0	 // 2
 3	OP_PUSH		49	0	1	 // 2
 4	OP_GETVAL	-4	4	0	 // 2
 5	OP_PUSH		-4	0	0	 // 2
 6	OP_PUSH		50	0	1	 // 2
 7	OP_CALL		-4	6	0	 // 2
 8	OP_SETVAL	37	-4	0	
 9	OP_PUSH		-1	0	0	 // 1
10	OP_PUSH		-2	0	0	 // 1
11	OP_CALL		-5	8	0	 // 1
12	OP_CLEAR	0	0	0	
13	OP_RET		0	0	0	

 1	VINTEGER	11
 2	VINTEGER	8
 3	VNULL
 4	VNULL
 5	VNULL

rule #6 bytecode was created in 0.000087 seconds
bytecode: 64/64, heap: 28/28, stack: 4/24 bytes, varstack: 832/832 bytes
 0	OP_GETVAL	-4	4	0	 // 2
 1	OP_GETVAL	-5	3	0	 // 2
 2	OP_SUB		-4	-4	-5	 // 2
 3	OP_PUSH		52	0	1	 // 1
 4	OP_DIV		-4	-4	-1	 // 1
 5	OP_GETVAL	-5	3	0	 // 1
 6	OP_ADD		-4	-4	-5	 // 1
 7	OP_PUSH		-4	0	0	 // 1
 8	OP_PUSH		50	0	1	 // 1
 9	OP_CALL		-4	6	0	 // 1
10	OP_SETVAL	37	-4	0	
11	OP_PUSH		-2	0	0	 // 2
12	OP_PUSH		-3	0	0	 // 2
13	OP_CALL		-5	8	0	 // 2
14	OP_CLEAR	0	0	0	
15	OP_RET		0	0	0	

 1	VINTEGER	2
 2	VINTEGER	11
 3	VINTEGER	8
 4	VNULL
 5	VNULL
 6	VNULL

rule #7 bytecode was created in 0.000069 seconds
bytecode: 44/44, heap: 20/20, stack: 4/24 bytes, varstack: 848/848 bytes
 0	OP_PUSH		52	0	1	 // 1
 1	OP_GETVAL	-3	3	0	 // 1
 2	OP_PUSH		-3	0	0	 // 1
 3	OP_PUSH		50	0	1	 // 1
 4	OP_CALL		-3	6	0	 // 1
 5	OP_SETVAL	37	-3	0	
 6	OP_PUSH		-1	0	0	 // 2
 7	OP_PUSH		-2	0	0	 // 2
 8	OP_CALL		-4	8	0	 // 2
 9	OP_CLEAR	0	0	0	
10	OP_RET		0	0	0	

 1	VINTEGER	11
 2	VINTEGER	8
 3	VNULL
 4	VNULL

rule #8 bytecode was created in 0.002031 seconds
bytecode: 240/240, heap: 80/80, stack: 4/24 bytes, varstack: 928/928 bytes
 0	OP_PUSH		-1	0	0	 // 1
 1	OP_PUSH		-2	0	0	 // 1
 2	OP_CALL		-14	8	0	 // 1
 3	OP_CLEAR	0	0	0	
 4	OP_GETVAL	-15	34	0	
 5	OP_SETVAL	54	-15	14	
 6	OP_GETVAL	-17	35	0	
 7	OP_SETVAL	55	-17	14	
 8	OP_GETVAL	-18	55	0	
 9	OP_EQ		-18	-18	-4	
10	OP_GETVAL	-16	54	0	
11	OP_EQ		-16	-16	-3	
12	OP_AND		-18	-16	-18	
13	OP_JMP		26	0	0	
14	OP_GETVAL	-15	16	0	
15	OP_LT		-15	-15	-5	
16	OP_JMP		18	0	0	
17	OP_SETVAL	56	-6	0	
18	OP_GETVAL	-14	33	0	
19	OP_EQ		-14	-14	-4	
20	OP_GETVAL	-15	5	0	
21	OP_EQ		-15	-15	-7	
22	OP_AND		-14	-15	-14	
23	OP_JMP		26	0	0	
24	OP_SETVAL	5	-8	0	
25	OP_SETVAL	31	-8	0	
26	OP_GETVAL	-14	55	0	
27	OP_EQ		-14	-14	-4	
28	OP_GETVAL	-15	5	0	
29	OP_EQ		-15	-15	-8	
30	OP_GETVAL	-16	33	0	
31	OP_EQ		-16	-16	-8	
32	OP_GETVAL	-17	16	0	
33	OP_GT		-17	-17	-10	
34	OP_GETVAL	-18	57	0	
35	OP_GT		-18	-18	-11	
36	OP_GETVAL	-19	54	0	
37	OP_EQ		-19	-19	-9	
38	OP_AND		-19	-19	-14	
39	OP_AND		-19	-19	-15	
40	OP_AND		-19	-19	-16	
41	OP_AND		-19	-19	-17	
42	OP_AND		-18	-19	-18	
43	OP_JMP		45	0	0	
44	OP_SETVAL	5	-7	0	
45	OP_GETVAL	-14	55	0	
46	OP_EQ		-14	-14	-4	
47	OP_GETVAL	-15	54	0	
48	OP_EQ		-15	-15	-12	
49	OP_AND		-14	-15	-14	
50	OP_JMP		59	0	0	
51	OP_SETVAL	56	-13	0	
52	OP_GETVAL	-14	33	0	
53	OP_EQ		-14	-14	-8	
54	OP_GETVAL	-15	5	0	
55	OP_EQ		-15	-15	-7	
56	OP_AND		-14	-15	-14	
57	OP_JMP		59	0	0	
58	OP_SETVAL	31	-4	0	
59	OP_RET		0	0	0	

 1	VINTEGER	13
 2	VINTEGER	30
 3	VINTEGER	6
 4	VINTEGER	0
 5	VINTEGER	12
 6	VINTEGER	150
 7	VINTEGER	2
 8	VINTEGER	1
 9	VINTEGER	18
10	VINTEGER	7
11	VINTEGER	22
12	VINTEGER	20
13	VINTEGER	105
14	VNULL
15	VNULL
16	VNULL
17	VNULL
18	VNULL
19	VNULL

 0 1 0	System#Boot
 1 1 0	#stateBeforeDHW
 2 1 0	#opModeBeforeDHW
 3 1 0	#targetLowBeforeDHW
 4 1 0	#targetHighBeforeDHW
 5 1 0	#sleepAtNight
 6 1 0	timer=10
 7 1 0	@Z1_Heat_Curve_Target_Low_Temp
 8 1 0	@Z1_Heat_Curve_Target_High_Temp
 9 1 0	timer=11
10 1 0	$outletDelta
11 1 0	@Main_Outlet_Temp
12 1 0	@Main_Target_Temp
13 1 0	@Z1_Heat_Request_Temp
14 1 0	$newHeatRequest
15 1 0	$newQuietMode
16 1 0	@Outside_Temp
17 1 0	@Quiet_Mode_Level
18 1 0	@SetQuietMode
19 1 0	@SetZ1HeatRequestTemperature
20 1 0	While catching up to outlet target temperature disable quiet mode
21 1 0	timer=12
22 1 0	$minDHWTarget
23 1 0	$minOutside
24 1 0	$maxDHWTarget
25 1 0	$maxOutside
26 1 0	$newDHWTarget
27 1 0	@Operating_Mode_State
28 1 0	@DHW_Temp
29 1 0	@DHW_Target_Temp
30 1 0	@DHW_Power_Consumption
31 1 0	@SetHeatpump
32 1 0	@SetOperationMode
33 1 0	@Heatpump_State
34 1 0	%hour
35 1 0	%minute
36 1 0	@SetDHWTemp
37 1 0	@SetCurves
38 1 0	@Operating_Mode_State (>=3): 
39 1 0	@DHW_Temp: 
40 1 0	 > @DHW_Target_Temp: 
41 1 0	@DHW_Power_Consumption (==0): 
42 1 0	@Operating_Mode_State (<3): 
43 1 0	Activating DHW production.
44 1 0	{zone1:{heat:{target:{high:60,low:60}}}}
45 0 0	{zone1:{heat:{target:{low:NULL}}}}
46 1 0	timer=20
47 1 0	{zone1:{heat:{target:{high:
48 1 0	,low:
49 1 0	}}}}
50 1 0	timer=21
51 1 0	{zone1:{heat:{target:{low:
52 1 0	timer=22
53 1 0	timer=13
54 1 0	$hour
55 1 0	$minute
56 1 0	@SetMaxPumpDuty
57 1 0	@Room_Thermostat_Temp

[stumbaumr]

@McMagellan , I reduced the logfile to the interesting places. Here is the longer log.
HeishaMon-Variable-set-wrong-long-log.txt

The error itself has been happening for a while now. So yes - reproducible in my complete rule set, but not as a separate shrinked down rule...

[CurlyMoo]

I don't see the additional log entry i suggested.

[CurlyMoo]

And again, is has a buffered SetCurves waiting to be executed:

Mon Jun 10 13:00:00 2024 (13749794): set DHW temperature to 45
Mon Jun 10 13:00:00 2024 (13749794): sent bytes: 111 including checksum value: 229 
Mon Jun 10 13:00:00 2024 (13749797): set heat pump mode to 34
Mon Jun 10 13:00:00 2024 (13749802): Already sending data. Buffering this send request
Mon Jun 10 13:00:00 2024 (13749810): set heatpump state to 2
Mon Jun 10 13:00:00 2024 (13749815): Already sending data. Buffering this send request
Mon Jun 10 13:00:00 2024 (13749824): SetCurves JSON received ok
Mon Jun 10 13:00:00 2024 (13749828): Already sending data. Buffering this send request

[McMagellan]

"So yes - reproducible in my complete rule set, but not as a separate shrinked down rule..."
I also had this experience.

If you change something the error goes away. Therefore it would be a real coincidence if you still had the criteria by expanding a print line with the same calculation. In addition, the parallel print calculation is not the same as in the original code.

For the log file:
Your 4 commands are sent and buffered correctly.
The 3rd command (green) has no feedback because there has been no change in this parameter compared to the previous status.
See attached PDF.
Log auswertung v3.pdf

The parameter "#targetHighBeforeDHW" did not need to be changed at all because it already had the value 40.
Where do the 32 come from?

[stumbaumr]

Where do the 32 come from?

Yep, that is the biggest question here...
32 is the number that has been stored in "#targetLowBeforeDHW" - how does it get into "#targetHighBeforeDHW" as well?

[McMagellan]

You could test what the entire rule would look like if you just changed the old value of "@Z1_Heat_Curve_Target_Low_Temp" from 32 to 33. Then you could see whether this 33 from the parameter is now also in the #targetHighBeforeDHW.

[stumbaumr]

So I added a print statement and changed @Z1_Heat_Curve_Target_Low_Temp to 33 and @Z1_Heat_Curve_Target_High_Temp zu 39.
And of course it just works now...
HeishaMon-Variable-set-working-long-log.txt

And after turning of airplane mode and reloading the HeishaMon WebGUI the usual reboot...

[stumbaumr]

And this is the end of DHW production after reboot and fixing the heat curve settings...
HeishaMon-Variable-set-working-long-part2-log.txt

[McMagellan]

Maybe I expressed myself incorrectly, but my suggestion was to change the value 32 in the heating curve using the cable remote control so that not a single byte in the rule is changed. By inserting another line into Rules you have the opportunity to find the error by destroying the reproduction. The error is still there, we just no longer see the effects or there just happen to be no effects in this constellation.

As far as I have seen, the rule is now working correctly.

[stumbaumr]

Next step would be printing the actual values of the curves to see if they are not the issue.

  print('Activating DHW production.');
+ print(@Z1_Heat_Curve_Target_Low_Temp, ' - ', @Z1_Heat_Curve_Target_High_Temp);

So the print statement seemed to have fixed it... - next test window is this coming friday. Have to make sure the familiy has DHW the next days as I am travelling.

[CurlyMoo]

You can also see if they are active on the stats page.

[McMagellan]

My question wasn't about the number of loaded rules in the ruleset but about the maximum size in bytes.
My old ruleset contained Rule10 as the largest rule with 620 bytes and this caused Heishamon to crash completely during the parsing process (not during the save button upload) after a reboot.
In the new ruleset I have divided the same Rule10 into 3 smaller rules and there are no more errors. Hence my question as to how large a single rule can be. I have now learned when Heishamon crashes to split the longest rule first.

[CurlyMoo]

Can you post that specific long rule?

[McMagellan]

Attached is the old ruleset with the long Rule10 (timer2).
CoPilot V3.280.txt

Here is the new version in which Rule10 was divided into Rule 10, Rule11 and Rule12. (timer2 + Heizbetrieb() + Heizpause())
CoPilot V3.291.txt

But my priority would be the error in connection with the web server.

[McMagellan]

Here is the debug file of what happens when the old ruleset is loaded.
Crash old rulesset.txt

Line 8: Rules are loaded normally via the Rules window with the Save button, OK.
Line 506: Targeted restart after power down.
Line 584: Reload existing ruleset during reboot.
Line 643: Crash while parsing Rule10.
Line 710: Factory Reset + quickly flashing blue LED.
finito

[CurlyMoo]

Shall we first focus on the stability of the whole besides the rules length? In doing so, please check the last commit.

[McMagellan]

Which version of #564 should I test?

HeishaMon_ESP8266-alpha-dc447760cbfe9b6ccee15efbeca01689

or

HeishaMon_ESP8266-debug-f8cfdc9e1659b0e59b324a66fb89262c

[CurlyMoo]

I don't know which hash belongs to what repo, but you should first pick the one from my repo.

[blb4github]

I've now https://github.com/IgorYbema/HeishaMon/actions/runs/10476556300 running successfully with my adapted rules set for 8 hours, the adaptation is a split of rule 2:

Heishamon_rules20240821.txt

[IgorYbema]

As this is not getting any further I would ask to split this PR into multiple smaller ones where it is logicaly to do so. I understand that the PR includes rules changes but also websocket changes

[CurlyMoo]

Done. Let's continue the websocket debugging here: #136

Waiting for test results by @McMagellan

[IgorYbema]

Just checked the remaining changes and they seem right. If the tests are ok also I can opt for a merge into main

[McMagellan]

First of all, I would like to say that the interaction between Heishamon and the Rules Engine is not working well at the moment. Therefore, I strongly advise against releasing a new version. Or remove the Rules button from the main menu in the new version.

I'll give you an example but I need a while to comment.

[IgorYbema]

I am not in a hurry ;-)

[CurlyMoo]

The rules work fine. The main issue is that the new rule parser allows for a lot larger rulesets than the older one. To the extend we enter the limit to what the ESP8266 Heishamon can handle. At least with the other services running as well. There are some optimalizations left on the webserver side, but that's it.

The most safe option for now would be setting a hard limit on how big the rulesets can be to keep enough spare memory.

[McMagellan]

I test the Version 3.62 Repo Igor #576 for ESP8266.

The Logfile is from Debug Port. Numbers are the Lines in the File. I start with clearing the Rulesset (not in File).
21aputty.log

17 Upload new Firmware
60 first start
459 loading Rulesset with Save Button.
621 ERROR loading Rulesset (CoPilot 3303.txt original version)

I can load this Rulesset without Problems in FW #544. This shown Error has CurlyMoo fixed.
The Error is in Rule Nr23.
I changed the Position of this Rule from 23 to Rule Nr2. !!!

669 loading modified Rule
821 Rulesset accepted and Start.

Is this an Error in my Rulesset when i fix this changing the Rule position?

987 Lost MQTT unknown why.
1170 to 1424 See Trigger Chaos during 3 Min bulk- Mqtt. No Triggered Parameter was changed, no Trigger needed.
In #544 there was no (ghost-) triggers.

Next is a Test what happens after a Reboot startet from Browser io the WebIF.

1436 Heishamon starts.
1492 Rulesset does not start.

This is the Situation when after a reboot the rules no longer are runnung. Stats: Rules active: 0.

1940 Next try with a Reboot from Browser.
1997 Reading rules
2150 This time the Rulesset starts working normal.

But there is a new annomally seen for the first Time.
2194 The variable #Delta has now the value NULL and a Blank is missing. Last fault in 2353.
2265 SetCurves failed, do not know why.

Test what happens after a Power off situation

4582 Power Off Simulation
4638 Reload Rules.
4791 Start Rules.
4838 #Delta = NULL during 4994

4902 Setcurves failed
5889 TOP25 Trigger -> 5891 Set Holiday Mode command from the Rule
6092 Read data failed timeout
6109 lost MQTT Connection
6138 Timeout Webserver
6140 Bad header - 6197

The Error #Delta = NULL is only after a Restart phase from Heishamon when the Rulesset is present in the Memory. Not after Load Rules during Save Button.

Here is my Rulesset. If you Test it note that the Rule will change your Heatcurve Parameters.
CoPilot V3303.txt

[CurlyMoo]

@McMagellan We already know that a lot of rule fixes are not yet present in 3.62. So although it's great you have been testing it, but is also somewhat working towards the obvious conclusion for a large part.

So, can we continue the testing here: #136 with build 564 here: https://github.com/IgorYbema/HeishaMon/actions/runs/10409672704

[IgorYbema]

Yes the main idea for splitting the PR is to implement the latest rules fixes without the memory improvement from the websocket changes. So if build #577 (https://github.com/IgorYbema/HeishaMon/actions/runs/10485393767) works with the ruleset but only crashes due to memory issue it is 'fine'.
I can agree with a hard limit of rules for the ESP8266 variant of heishamon.

[stumbaumr]

I updated the HeishaMon to the build from https://github.com/IgorYbema/HeishaMon/actions/runs/10485393767.
9 Rules are active.

Hopefully stable to get this PR merged...

[stumbaumr]

From my perspective the last build from this PR just works. I had the console running for about 12 minutes...

There is nothing that should keep you from merging.

[IgorYbema]

This has been merged into branch v3.7 for release testing

[stumbaumr]

I just updated to the latest build from v3.7 now...

[blb4github]

I'm running that version as well since yesterday 21:00u without issue yet.

[McMagellan]

I'm having another problem loading a ruleset. I use the version (V3.8 138 Alpha 550efd7)
I have now converted my CoPilot Rules to version 4.x and it is a matter of luck that it can be loaded.
The file CoPilot V4.14.txt is attached as an example, with which I can explain the problem in a comprehensible manner.
CoPilot V4.14.txt

The first line in the System#Boot Rule contains the code: #Test = 0;
This means that the ruleset cannot be loaded.
If I now remove this first line with (#Test = 0;), the ruleset can be loaded and goes into operation.
This means that the error can be reproduced for me. The rule is not quite finished yet and it would be nice if the error is found. I have used many print commands here to make the program more understandable. I'm sure I can fix the problem if I remove everything that isn't absolutely necessary.

Attached is also the debug log file of the two different loading processes.
neu 5.txt

1. Rules load failed with reset -> Line 263.
2. Rules load without 1st row -> OK Line 853
3. Rest of heating cycle is OK.

Then I also saw that print sometimes isn't executed at all. Example:
In the code of timer=36, directly after the line $Tim = 36; is a print line. The console shows $Tim = 36, but the print line does not shown.

on timer=36 then
   $Tim = 36;
   print("2nd Service CoPilot Sperrzeit ein");
   if @External_Pad_Heater != 2 then
      print("aktiv");
      @SetExternalPadHeater = 2;
   end
end

[CurlyMoo]

@IgorYbema Can you maybe check if you can catch the exception for the failing ruleset. I can't easily reproduce it.

[McMagellan]

Can the Rule be started for you?

For me the error is permanent.
Of course, the first line here in the rule is not the reason for the error.
But the parsing behavior is different with or without the first line.
We've had a mistake like this before. When parsing in the console that was running, the text: too large read or something similar was displayed. However, this new error here ends in a reset of the Heishamon during parsing, see log file in which the Rule 22 is processed in the message and the termination occurs.

Previously, you could trix the error by adding more lines until the rule was accepted. It was probably due to the key points in memory usage or transmission that didn't fit together. It seems to be similar here. By omitting the first line, the entire rule moves and the incorrect store point is avoided.
What's also interesting is that if I copy the last rule (timer=40) again as rule timer=41 behind it, the error no longer occurs.
Here too, file corner points are moved.

[CurlyMoo]

Can the Rule be started for you?

I only have unittest environments, not real Heishamons to test on.