Rule parsing issue or cannot be done?

[mrwee]

Hi,

Running ESPEasy (ESP_Easy_mega_20210503_normal_ESP8266_4M1M) on an original Wemos D1 mini, I'm struggling a bit with a rule, it seems like it's not parsed correctly.

I have two devices:

2021-07-05_16-47-53.jpg (36.03 KiB) Viewed 14819 times

The rule:

Code: Select all

on MQTT1#Direction do
 if [MQTT1#Direction]=[Dummy1#Direction]
   publish "Pool_3wayValve/test","MQTT2"
 else
   publish "Pool_3wayValve/test","MQTT3"
 endif
endon

But I get the error:

Code: Select all

65732196: IMPT : [MQTT1#Direction] : 0.00
65732285: EVENT: MQTT1#Direction=0.00
65732340: ACT : publish 'Pool_3wayValve/test','MQTT3'
65732366: ACT :  endif
65732371: Command unknown:  endif

I also tried:

Code: Select all

 if [MQTT1#Direction]=[Dummy1#Direction]
   publish "Pool_3wayValve/test","MQTT2"
 endif
 if [MQTT1#Direction]!=[Dummy1#Direction]
   publish "Pool_3wayValve/test","MQTT3"
 endif

but that gives an "Command unknown: endif" error in last != if statement.

[Ath]

I tried the first code you published, and it does seem to work as intended.

Have you checked if there are unexpected (control)characters hidden in the script? I copied from the forum, and it does look right, but maybe in your rules file it isn't correct. Using Notepad++ you can use View/Show Symbol/Show All Characters to display all characters, maybe there is a line-feed instead of a cr/lf, or the files has a unicode-bom (byte order mark) as inserted by Windows Notepad when entering accented characters?
Is there other incomplete code in these rules, maybe even in one of the other rules files 1..4, like an unclosed if/endif in another event handler (on ... do/endon) or an unclosed on ... do/endon?

[TD-er]

Better compare using %eventvalue1% instead of [MQTT1#Direction]
Still I don't see any obvious error

[mrwee]

Thanks both.

I'm really struggling with rules for a new device right now. It was not any illegal character, and I'm below the 2048 character limit, but it simply either complaints about my endif or commands which are unknown. Don't understand why, at all
Reason for using [MQTT1#Direction] is an attempt on finding the problem.

Guess I need to really take it apart, and see which part messes it up.

Just for clarification. Can I nest calling events, like:

Code: Select all

on MQTT1#Direction do
  event,SetToggle
endon

on SetToggle do
  event,DoThis
endon

on DoThis do
endon

[TD-er]

Yes you can, but calling event from event etc. is a good receipt to crash due to stack overflow.
Best to call it using asyncevent.
Asyncevent will be added to a queue and dealt with in a next run to parse rules.

[mrwee]

got it. But as I understand it, asyncevent might get executed in a non-seqential order as opposed to event?

I got my rules working, no idea why. But it seems very sensitive as to when they work and when they dont. Cannot figure out what's causing it.

[TD-er]

Well yes and no...
The "event" command is executed immediately.
The asyncevent is added to a queue and that queue is executed in order it was appended to the queue.
So if you only use asyncevent for events you create, you know those will be executed in the order you created them.

There is one thing to keep in mind.
Not all events generated by ESPEasy are "events", some do not need to be executed immediately and thus are also appended to this same queue as the asyncevent calls.
Whether it must be executed immediately depends on the source of the event.
For example an event for which the reply must be sent back to the source (e.g. via serial, MQTT or http call) are handled immediately.
But events for new values from a task are added to the queue.

[mrwee]

Thx for that explanation. It's a bit difficult to forsee how these conditions affects a specific rule execution when dealing with different devices, MQTT publish / import, internal variables, dummies etc.
However I have not had huge issues with rules before, but somehow this time it's acting up

[Ath]

It can be caused by another part of your rules, so you might want to check on your syntax for other events/rules files as well.
If possible you can share them here, more eyes that can help you identify the cause.

[mrwee]

Sure, thanks for your support. Right now it seems to work, but I'll post all rules if I end up in it again.
I also experienced the situation where all 4 rule pages, only showed the first page. I think that it's wise to wipe all rules, reboot and paste again if a similar situation occurs again.

[mrwee]

Wow. After I got the rule engine working again, I could reduce the code to a minimum.
My project was modifying a 3-Way pool valve from a pre-fabricated controller

2021-07-06_19-49-05.jpg (21.59 KiB) Viewed 14750 times

to being managed by ESPEasy with easy toggle switch and valve status indication .

2021-07-06_19-47-23.jpg (148.97 KiB) Viewed 14750 times

Status can be controlled/viewed in Home Assistant

2021-07-06_19-49-35.jpg (8.35 KiB) Viewed 14750 times

Love it

All that's missing is the automatic temperature control with different mode-settings, which I need to get my head around.

Code:

Code: Select all

on MQTT1#Direction do
 if %eventvalue1%!=[Dummy1#Direction]
    asyncevent,SetState=%eventvalue1%
 endif
endon

on Button#State=0 do
 let,1,1-[Dummy1#Direction]
 asyncevent,SetState=[VAR#1]
endon

on SetState do
  timerset,2,0
  timerset,3,0
  taskvalueset,7,1,%eventvalue1%
  if %eventvalue1%=1
     publish "Pool_3wayValve/Valve_status","Moving to solar"
     mcpgpio,10,1 // RED ON
     mcpgpio,11,0 // Green OFF
     mcpgpio,13,1 // Solar heater
  else
     publish "Pool_3wayValve/Valve_status","Moving to direct"
     mcpgpio,10,0 // Red OFF
     mcpgpio,11,1 // GREEN ON
     mcpgpio,13,0 // Direct
  endif

  mcpgpio,12,0 // Power ON
  timerset,2,17
  looptimerset_ms,3,400
endon

on Rules#Timer=2 do
   mcpgpio,12,1 // Power OFF
   mcpgpio,13,1 // No power to direction
   timerset,3,0
   if [Dummy1#Direction]=0
      publish "Pool_3wayValve/Valve_status","Direct"
   else
      publish "Pool_3wayValve/Valve_status","Solar"
   endif
endon

on Rules#Timer=3 do
   if [Dummy1#Direction]=1 // Reversed
      MCPLongPulse_ms,10,0,200
   else
      MCPLongPulse_ms,11,0,200
   endif
endon

[TD-er]

Just browsed through the code and saw this:

Code: Select all

on Button#State=0 do
 let,1,1-[Dummy1#Direction]
 asyncevent,SetState=[VAR#1]
endon

I assume the button is configured to be a "normal" button?
If it is configured as a toggle button, it may not work as you intended.

[mrwee]

Yes, it's a normal switch button. Had forgotten all about the toggle button

[TD-er]

Not sure if using the toggle button is a good idea here.
The button press does seem to reverse direction and using a toggle button is only useful if you plan to use its internal state.
But this state is not updated when the direction has changed, so it then is no longer usable as "switch direction" option, but more like a direction override/confirmation when pressing it.

So what you have now is probably the most intuitive one.

[mrwee]

ok. I'll keep it as it is. Also since it's working