Replies: 5 comments 16 replies
-
|
Well it depends I guess. Apart from this, there is also the question on how to access the parameters that have to be replaced at runtime during rules parsing? The current ESPEasy rules now support something like this |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
My fully functional rules library inside an working program, which should replace the ESPEasy implementation can be found here: In the In the |
Beta Was this translation helpful? Give feedback.
-
|
@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. |
Beta Was this translation helpful? Give feedback.
-
|
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:
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
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:
Beta Was this translation helpful? Give feedback.
All reactions