How to provide rules to the library?

[CurlyMoo]

At the moment, the rule parses just parses rule provided to it. The developer should handle the list of rules to be parsed or (re)executed. Or should the rule library have the possibility to read rules from external locations such as files?

@TD-er commented on this:

I haven't looked at your code in great depth as of now, but I was thinking maybe I can add some wrapper to call the rules parsing with some range/location parameters.
For example an offset in a file, or maybe you can add some jump condition based on a hash of some event name?

[TD-er]

Well it depends I guess.
Your rules currently have a different syntax to the ESPEasy rules.
So the first step would probably be to "convert" the ESPEasy rules into a syntax that's easier to parse.
I don't know where this responsibility should be.
If you intend to have this rules project independent of ESPEasy, then it makes sense "I" translate it and thus the rules parser does not read from the rules directly.

Apart from this, there is also the question on how to access the parameters that have to be replaced at runtime during rules parsing?
For example, does the rules handler have direct access to UserVar in ESPEasy? Or should there be a call for "give me [taskname#varname] value"?
The same applies for system variables, but those can be encoded using an enum I guess.

The current ESPEasy rules now support something like this [var#%v1%] so that's a 2-step replacement.

[CurlyMoo]

Even if we would opt for using the new syntax together with a translator, we still need to think the current syntax through properly. So we don't have the same issue in the future. That some developer pops in and tells us the current new rule system is bogus 😉

[TD-er]

That some developer pops in and tells us the current new rule system is bogus

Well that's always going to happen :)
I don't think there is a more stubborn kind of person like a programmer :)

Not sure if Theo is even considering switching rules engine. I only mentioned it as a comparisson to "defend" the ESPEasy syntax even though I don't think it is a good syntax/grammar. It was only to point out there currently is quite a large user base using it right now.

[CurlyMoo]

It was only to point out there currently is quite a large user base using it right now.

I understand. I will check if i can easily make a lexer for the ESPEasy syntax. Can you provide me with a good example rule to test with?

[AloisKlingler]

a big 👍 for the ruleset of the heatpump. and I thought my shuttercontrol-ruleset is kind of "do not do this with the rules". :-)
If you guys want the opinion from an end-user with scripting and slightly programming experience: what a pity, there is no Block-based coding GUI for the current rules, because it is exactly what I had to do by hand.
not because I am not able to write if's or "functions". because a lot people will be able to understand and use it as soon as the do not need any programming experience. with block-based coding the obstacle is very low.

"outsourcing" functions to the event-based approach looked for me like: "yes, we can handle it, less memory on the ESP or less developing time brings me in the situation to attach this simply in the already existing event-logic."

@TD-er the existing users will not go away just by switching the rules engine. create another build which has still the "old" rules engine in place, mark it as legacy with a link for new rules.
give a (web based?) possibility to transform existing rules (not on the ESP). there should not be much magic behind.
give a web based possibility to create block-based coding for new rules only (import by e.g. json the esp-config to have the devices and controllers as blocks available - oh, how cool would that be!). this will be the breaking point where users stop typing and start clicking. ;)

[CurlyMoo]

Just to give you a sneek peek. This is how i (still partly) moving my current heatpump ESPEasy code to the new rules library.

on setThermostaat then
	#nachtverlaging = -2;
	#T1 = 21.25;
	#T2 = 20.25;
end

on @Room_Thermostat_Temp then

	setThermostaat();

	$Taanvoer1 = 30;
	$Tbuiten1 = 12;
	$Taanvoer2 = 41;
	$Tbuiten2 = -6;

	$MaxTa = 0;

	$Temp = @Room_Thermostat_Temp;

	$targetTempDiff = #T1 - $Temp;

	if @Outside_Temp >= $Tbuiten1 then
		$MaxTa = $Taanvoer1;
	else
		if @Outside_Temp <= $Tbuiten2 then
			$MaxTa = $Taanvoer2;
		else
			$MaxTa = $Taanvoer1 + (($Tbuiten1 - @Outside_Temp) * ($Taanvoer2 - $Taanvoer1) / ($Tbuiten1 - $Tbuiten2));
		end
	end

	if $Temp > #T1 then
		@SetHeatPump = 0;
	else
		if $Temp < #T2 then
			@SetHeatPump = 1;
		end
	end

	if @Heatpump_State == 1 then
		if @Outside_Temp > 0 then
			if @Compressor_Freq == 0 && @Defrosting_State == 0 then
				@Main_Outlet_Temp = @Main_Outlet_Temp + 5;
			else
				@Main_Outlet_Temp = @Main_Outlet_Temp - 1;
			end
		end
	end
end

In this case:
@ = heatpump command
# = global variable
$ = local variable

[CurlyMoo]

The latest changes indeed allows the library to parse multiple rule blocks in a single file. This is intentionally not all done inside the rules library. This prevent a long blocking function call or the rule initialization.

[CurlyMoo]

My fully functional rules library inside an working program, which should replace the ESPEasy implementation can be found here:
https://github.com/CurlyMoo/HeishaDaemon

In the rules.txt you can see the actual new syntax fully implemented.

In the main.cpp source file you can see i how modularly dealt with events, timers, globals, variables and system values.

[CurlyMoo]

@TD-er The last version of my library is the best i could do after testing various implementations. E.g. what i tried with commits 4db5a4b, 1137227, 1d3687c, 759f035 which finally lead to commit 7863ea5

I've been testing this last code on my ESP8266 and it already runs fine for hours with no exceptions.

The accompanied README describe pretty well how the whole thing works.

[TD-er]

I just browsed through the code a bit and I'm not really sure where to start to even get clear for myself what still has to be done to get this integrated in ESPEasy.

Things I can see so far:

• Transform rules syntax of ESPEasy into what is expected by this rules parser (e.g. adding ;, marking commands to be like functions, if...then etc)
• Feed the rules into the rules parser to create interpreted byte code
• What to call to execute the rules given a specific event?
• How does the rules parser call commands, read values, etc?

[TD-er]

Right now, I don't have time to dive into it, I hope to have time this weekend...

[CurlyMoo]

Take your time. In the meanwhile i've added two example to illustrate most of your questions.

[CurlyMoo]

That were some busy weekends 😉

[TD-er]

Extremely busy and still is....

[CurlyMoo]

😔