Read internal analog value change, in a running event. But how?

[hoeby]

I am trying to control a somfy telis 4 remote.
This i am using to control the curtains and blinds.
It is possible to run a HTTP event. This controlls the devices, but there was no feed-back.
I made the script to go always back to channel 1 on the remote. So the starting point is always the same on the control.

I want to extend/modify the script.
When a channel is selected, there is a LED flashing. Each channel has it's own LED.
I connected LED channel 1 to A0 on my wemos D1. Without a formula, it changes from 1024 to 470 when LED is flashing.

The problem i have, is changing to the next channel in an event.
This script isn't doing what i like. First i switch gpio16, Than the channel LED is flashing, so i know which channel is selected.
But this changes to state of [test-chanel-1#Analog], but the event is not looking after it. When the event is done, than i see in the log that the value is changed.
Is there a way to read the changing value in an event? or is espeasy stopping whit looking to the A0 when running an event?

Code: Select all

On Test do
 gpio,16,1                                               // Set relay ON to check channel state
 delay 200                                               // Small delay
 gpio,16,0                                               // Set relay OFF
   if [test-channel-1#Analog]<500.0 do                   // Look at the state of A0, it is changed because of GPIO16 switched
     gpio,16,1                                           // Set relay ON to go to the next channel
     delay 200                                           // Small delay
     gpio,16,0                                           // Set relay OFF
   endif
endon

This works, but i prefer to have it in the event. Because the "On test-channel-1#Analog do" can now be triggered by different events

Code: Select all

On Test do
 gpio,16,1                                               // Set relay ON to check channel state
 delay 200                                               // Small delay
 gpio,16,0                                               // Set relay OFF
endon

On test-channel-1#Analog do
  if [test-channel-1#Analog]<500.0 do                    // Look at the state of A0, it is changed because of GPIO16 switched
     gpio,16,1                                           // Set relay ON to go to the next channel
     delay 200                                           // Small delay
     gpio,16,0                                           // Set relay OFF
   endif
endon 

[TD-er]

To stabilize the analog read, you may need to add a small capacitor over the analog input (close to the pin).
Something like 100 nF will probably do.

But handling a value in rule can be made fixed by saving it to a variable and just referring that variable.
An event is not handled immediately, so there is a chance a plugin may update its values in between.

[hoeby]

The problem is not an unstable read of the analog read.

The problem is that i start an event.
The first action of the event, changes the analog value.
But when running the event, it doesn't look at the changed value. It takes the value, which it was just bedoel the event was triggered.

Does the use of the variables help?
If an event does look to change between the start and end of an event. Than that doesn't do the trick.
When looping to the log, of looks that an event is run immediately when i give the command

[TD-er]

When referring to the output of a plugin, you're actually taking a value from the internal (C++) array called UserVar.
This keeps the last output values of the active tasks.
During execution of the rule, no updates will be performed on this array. (a few exceptions, but ADC is not one of them)

What may happen is that an event is fired and before the event is processed a task update is processed.
Such a task update may change the content of this UserVar array.

[hoeby]

I solved it with the use of a dummy devices.
When the event is running a dummy is set to 1.
When the event is finished, an other script is started because the dummy is 1. Because the second script is started within a second after the first is finished, this works for me.