OK, let's try to answer your questions.
Under the "devices" tab (confusing I know...) are the "tasks".
Each task is an instance of a "plugin".
You can have multiple tasks using the same plugin, so you can have multiple "dummy" tasks for example.
One word of caution though, as not all plugins have been changed to allow multiple instances.
Also some plugins do (still) affect other instances of the same plugin when you change its settings.
This used to be an issue with the "dummy" plugin in the past when changing the output type of it (e.g. switching between number of output fields).
Not sure if it is still applicable, but if you run into these issues check to see if all tasks running the dummy plugin use the same output type.
Now back to the flow of data and how concepts are linked together in ESPEasy.
A task can be linked to 0 ... 3 controllers.
If a task gets a new value from the connected sensor, it will forward these to the linked controllers and these will further process this data.
So you can have multiple controllers active and even send data from a single plugin to multiple controllers.
Each task can be configured like this, so you can have multiple tasks linked to the same controller.
Apart from sending data to a controller, it will also generate an event, which can be processed in the rules.
Such an event is named after the task name and task value name.
For example a task running the BME280 plugin may be called "bme" and have 3 task values: temp/hum/pressure (or whatever name you give them)
A typical sequence of events will then be:
Code: Select all
bme#temp=21.34
bme#hum=71.2
bme#pressure=1002.3
Or when you checked the checkbox to combine the events:
See also the rules documentation for a lot of examples.
N.B. you must use unique task names or else you cannot distinguish between events from different tasks.
A task can only generate new values if it is calling PLUGIN_READ and the attacked sensor does actually return a value. (some sensors may only output a value every N seconds, or if it is not connected it will also not give back something)
You can trigger a PLUGIN_READ either periodically at an interval set by the "Interval" variable in the task configuration (bottom screen), or by calling "taskrun" from the rules or the command window on the Tools page.
Don't forget to include the task index as a parameter for this taskrun (e.g. "taskrun,1" for the first task)
Of course a controller has to be "enabled", as must the task for this to work and the task must be able to generate new values.
The Dummy is a special case as it does not have a physical sensor connected to it, so as long as it is enabled, it will send its task values to the linked controller when it is calling its PLUGIN_READ function.
The HTTP controllers may perform a HTTP GET call.
Just to know the difference between a HTTP GET and PUT call;
When you submit a form on a web page, you have to send this data back to the server.
This is typically done using a POST call, which can send a more complex and larger reply back to the server.
A GET call is putting all in the URL, like this:
Code: Select all
http://myserver.com/bla.html?var1=123&var2=234
One way to remember it is that you can "bookmark" a GET call as all information is present in the URL and you can't on a POST call.
I don't know why your controller does not seem to work as soon as you include some reference to another task value (e.g. [mydummy#bla] )
So it would be helpful to see what is written in the logs when you try to send it.