Dummy var in Controller

Moderators: grovkillen, Stuntteam, TD-er

Post Reply
Message
Author
User avatar
DMike92
Normal user
Posts: 29
Joined: 28 Jul 2020, 02:06
Location: Paris - France

Dummy var in Controller

#1 Post by DMike92 » 16 Aug 2021, 18:06

Hi,
I have 2 devices, one is a Switch input (#1) and the second is a Dummy (#2)
The first device calls a generic HTTP controller.

I tried to get the value of my Dummy device variable (myvar) in the controller (the first and only one) like this:

Code: Select all

demo.php?name=%sysname%&task=%tskname%&valuename=%valname%&value=%value%&myvar=[Dummy#myvar]
Unfortunately, it does not work!
The controller stops working when I try to add this value with this syntax.

Of course I do not want to have another controller 'attached' to the Dummy device which would send data every... minute or hour or so.

Is there a way ?

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Dummy var in Controller

#2 Post by TD-er » 16 Aug 2021, 20:16

If you use the default example string for this controller, does it then send what you expect? (see also the logs)

Code: Select all

demo.php?name=%sysname%&task=%tskname%&valuename=%valname%&value=%value%
N.B. the max length for this formatting string is 128 characters.

It should send a GET for each task value.
This GET request should also be shown in the logs (if logs enabled), so you can see to what it replaces the string.

User avatar
DMike92
Normal user
Posts: 29
Joined: 28 Jul 2020, 02:06
Location: Paris - France

Re: Dummy var in Controller

#3 Post by DMike92 » 16 Aug 2021, 20:41

TD-er wrote: 16 Aug 2021, 20:16 If you use the default example string for this controller, does it then send what you expect? (see also the logs)

Code: Select all

demo.php?name=%sysname%&task=%tskname%&valuename=%valname%&value=%value%
N.B. the max length for this formatting string is 128 characters.

It should send a GET for each task value.
This GET request should also be shown in the logs (if logs enabled), so you can see to what it replaces the string.
Yes the controller works fine without my add.
The length is far below 128.
I dont understand who should send a GET...? (but its probably not important).
I Will try the Logs to better answer (I remember having got a look but dont remember what i saw at the moment).

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Dummy var in Controller

#4 Post by TD-er » 16 Aug 2021, 21:05

You have to link a task to a controller (e.g. the Generic HTTP controller you use).
So every time a task is calling its PLUGIN_READ call, which then yields a value, the linked controller(s) is/are called.

For the Generic HTTP controller, it will then create a HTTP GET call to the host you defined in the controller settings.
So the ESP will make the GET call. (alternative is a HTTP PUT, which you cannot make with this controller, just to give some context what I mean with GET)

A task is calling its PLUGIN_READ function when:
- "Interval" set in the task has passed. (not all tasks have this, but most have)
- "taskRun" is called from the rules or an externally given command

An example of a task which does not periodically calls the PLUGIN_READ is a RFID reader plugin.
Typically the plugins that only yield a new value based on an external trigger, or only "output" something instead of "receiving".

What build are you running?
The current source code does seem to call those functions that should replace the [taskname#varname] syntax.

User avatar
DMike92
Normal user
Posts: 29
Joined: 28 Jul 2020, 02:06
Location: Paris - France

Re: Dummy var in Controller

#5 Post by DMike92 » 17 Aug 2021, 01:08

TD-er wrote: 16 Aug 2021, 21:05 You have to link a task to a controller (e.g. the Generic HTTP controller you use).
Sorry for my english. That what I meant when I said in my first post:
"The first device calls a generic HTTP controller."
And just for clarity: Are 'tasks' are what you see in the "device" tab (like Switch input or Dummy and many others)?
TD-er wrote: 16 Aug 2021, 21:05So every time a task is calling its PLUGIN_READ call, which then yields a value, the linked controller(s) is/are called.

OK for that.

For the Generic HTTP controller, it will then create a HTTP GET call to the host you defined in the controller settings.
So the ESP will make the GET call. (alternative is a HTTP PUT, which you cannot make with this controller, just to give some context what I mean with GET)

Agree completely.

A task is calling its PLUGIN_READ function when:
- "Interval" set in the task has passed. (not all tasks have this, but most have)
- "taskRun" is called from the rules or an externally given command
I have tried this taskRun with the Dummy device from the rukles but the linked controller did not fire:
(There was a second controller linked to the Dummy device at this time but I removed it later).
The link was ok in the device and the controller was disabled to avoid repeating HTTP calls (The GET calls you're speaking about).
Maybe I made a mistake. I will try again with and without the 'Enable' in the controller and a simple syntax.
I also write the PHP script at the other end so it's easy for me to see hat's happen (written in a file).
TD-er wrote: 16 Aug 2021, 21:05An example of a task which does not periodically calls the PLUGIN_READ is a RFID reader plugin.
Typically the plugins that only yield a new value based on an external trigger, or only "output" something instead of "receiving".

What build are you running?
The current source code does seem to call those functions that should replace the [taskname#varname] syntax.
This post is growing in questions (all interesting). Let me do some more tests and I'll come back.
But the main question stays : can a controller send values from another Dummy one and with what syntax?

Thanks for your explainations.
(For the moment my project runs with all HTTP calls directly made from the Rules so I can transmit what I want but the controllers are smarter).

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Dummy var in Controller

#6 Post by TD-er » 17 Aug 2021, 01:17

If you want to share values among ESPeasy nodes, why don't you use the p2p controller?
See: https://espeasy.readthedocs.io/en/lates ... #c013-page

Important things to double check when trying this:
- Make sure every ESPEasy node in your network uses an unique unit number (not 0, not 255)
- Make sure to set the same UDP port to all units (8266 is the official port, but you can choose any port)

Then follow the steps as described in this section: https://espeasy.readthedocs.io/en/lates ... e-a-plugin

User avatar
DMike92
Normal user
Posts: 29
Joined: 28 Jul 2020, 02:06
Location: Paris - France

Re: Dummy var in Controller

#7 Post by DMike92 » 17 Aug 2021, 01:26

TD-er wrote: 17 Aug 2021, 01:17 If you want to share values among ESPeasy nodes, why don't you use the p2p controller?
See: https://espeasy.readthedocs.io/en/lates ... #c013-page

Important things to double check when trying this:
- Make sure every ESPEasy node in your network uses an unique unit number (not 0, not 255)
- Make sure to set the same UDP port to all units (8266 is the official port, but you can choose any port)

Then follow the steps as described in this section: https://espeasy.readthedocs.io/en/lates ... e-a-plugin
Thank you. Looks promising but I dont want to share anything between nodes as I only have one (for the moment).
I probably have to make better english descriptions.

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Dummy var in Controller

#8 Post by TD-er » 17 Aug 2021, 01:30

Perhaps it is me, in desparate need of some sleep as it is already 1:28 am here in the Netherlands.

Will have another look at your question tomorrow... Just post another reply to this, as I cannot mark a topic as unread and I will probably forget without a prompt in the form of an "unread" post. :)

User avatar
DMike92
Normal user
Posts: 29
Joined: 28 Jul 2020, 02:06
Location: Paris - France

Re: Dummy var in Controller

#9 Post by DMike92 » 17 Aug 2021, 01:42

Thanks a lot!
Have a good night.
(Dont answer now;-)

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Dummy var in Controller

#10 Post by TD-er » 17 Aug 2021, 15:24

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:

Code: Select all

bme#All=21.34,71.2,1002.3
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.

User avatar
DMike92
Normal user
Posts: 29
Joined: 28 Jul 2020, 02:06
Location: Paris - France

Re: Dummy var in Controller

#11 Post by DMike92 » 17 Aug 2021, 16:32

TD-er wrote: 17 Aug 2021, 15:24 OK, let's try to answer your questions.
Under the "devices" tab (confusing I know...) are the "tasks".
Thanks
Each task is an instance of a "plugin".
The following...
TD-er wrote: 17 Aug 2021, 15:24 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:

Code: Select all

bme#All=21.34,71.2,1002.3
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.
... is interesting but not my case.
task #1 (name: store) is linked to controller #1 and task #2 (name: Dummy) is linked to controller #2.
the task 'store' ('store' means blinds and does not store anything;-) is a switch input type (I call it real as opposed to dummy ones) and has only one value: "Open".
The Dummy task has 4 variables ; the 4th one being 'testvar'.
TD-er wrote: 17 Aug 2021, 15:24 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.
Here is some more information:
The rule is:

Code: Select all

on test do
 TaskValueSet,2,4,%eventvalue% // testvar in Dummy
 if [store#Open]=1
   GPIO,14,0
 else
   GPIO,14,1
 endif
endon
Changing the GPIO state does fires the task and the linked controller #1. (Controller #2 is disabled for these tests purposes)
and the command I issued:

Code: Select all

http://<IP address>/control?cmd=event,test=11
I dont know how to read the logs concerning the controller but here it is when everything works fine:
(The controller sends: demo.php?name=%sysname%&valuename=%valname%&value=%value% in this case)

Code: Select all

350702265: WD   : Uptime 5845 ConnectFailures 0 FreeMem 16776 WiFiStatus 3
350727419: HTTP: event,test=11
350727470: EVENT: test=11
350727490: ACT  : 
350727500: ACT  : TaskValueSet,2,4,11
350727508: Command: taskvalueset
350727529: ACT  : GPIO,14,0
350727531: SW   : GPIO 14 Set to 0
350727540: ACT  : 
350727551: ACT  : 
350727561: ACT  : 
350727641: SW  : GPIO=14 State=0 Output value=0
350727655: EVENT: store#Open=0.00
350732265: WD   : Uptime 5846 ConnectFailures 0 FreeMem 16752 WiFiStatus 3
I do get the 3 values in the php script.
And here it is when it does not work (command was: http://<IP address>/control?cmd=event,test=12):
(The controller now sends: demo.php?name=%sysname%&valuename=%valname%&value=%value%&mavar=[Dummy#testvar])

Code: Select all

352322266: WD   : Uptime 5872 ConnectFailures 0 FreeMem 16776 WiFiStatus 3
352344349: HTTP: event,test=12
352344434: EVENT: test=12
352344455: ACT  : 
352344467: ACT  : TaskValueSet,2,4,12
352344475: Command: taskvalueset
352344500: ACT  : GPIO,14,1
352344502: SW   : GPIO 14 Set to 1
352344507: ACT  : 
352344518: ACT  : 
352344528: ACT  : 
352344605: SW  : GPIO=14 State=1 Output value=1
352344618: EVENT: store#Open=1.00
352352266: WD   : Uptime 5873 ConnectFailures 0 FreeMem 15184 WiFiStatus 3
352353712: EVENT: Clock#Time=Tue,16:13
I dont get anything in the php script (not called at all, I think).

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Dummy var in Controller

#12 Post by TD-er » 17 Aug 2021, 18:45

I don't see the http call in your logs.
I have to check in the source to confirm, but maybe you can try with "debug" log level set? (not included in "test" builds due to size)

User avatar
DMike92
Normal user
Posts: 29
Joined: 28 Jul 2020, 02:06
Location: Paris - France

Re: Dummy var in Controller

#13 Post by DMike92 » 17 Aug 2021, 20:58

Ok. I'll wait
In the mean time, I have tested the TaskRun,2 command. It does the job, calls the associated controller provided that controller is enabled. Otherwise no.
I means, for a Dummy task linked to a controller that the controler wil repeatedly sends GET commands forever.
Of course interval can be set as high as 18 hours, but still...
Zero should be acceptable for interval for those who use Taskrun.

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Dummy var in Controller

#14 Post by TD-er » 17 Aug 2021, 21:05

OK, so the controller set with [dummy#varname] syntax is working as it should?
So then the only concern left is why the taskrun on "switch" is not working?
And why the interval cannot be set to "0" on the dummy task?
Well it can be set, but probably uses a default of 60 seconds then, right?

User avatar
DMike92
Normal user
Posts: 29
Joined: 28 Jul 2020, 02:06
Location: Paris - France

Re: Dummy var in Controller

#15 Post by DMike92 » 17 Aug 2021, 22:47

TD-er wrote: 17 Aug 2021, 21:05 OK, so the controller set with [dummy#varname] syntax is working as it should?
No I did not use this syntax because that makes the controller crash (not called at least).
There was just a question about Taskrun not being calling the controller. Now I can say Taskrun does fire the task AND the controller.
TD-er wrote: 17 Aug 2021, 21:05So then the only concern left is why the taskrun on "switch" is not working?
Again, no (sorry), the only concern is: the controller does not work when I try to send variable values using [dummy#varname] syntax.
Should it work with that syntax?
Is there another way or a workaraound ?
How can logs shows what happens?
TD-er wrote: 17 Aug 2021, 21:05 And why the interval cannot be set to "0" on the dummy task?
Well it can be set, but probably uses a default of 60 seconds then, right?
That's right, if I try to set it to zero, it comes back again to 60 (default) when you submit.
I think it's missing the possibility of having a controller linked to a Dummy device (Task) that would not send GET request repeatedly.

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Dummy var in Controller

#16 Post by TD-er » 17 Aug 2021, 23:01

That "60 seconds default" is something you can set yourself by the way. ("Config" tab)
Still it is rather not intuitive and I do agree that setting it to "0" for the dummy task does not make sense to have it still running every minute.

I will have to think about its consequences for exitsing settings out there.

User avatar
DMike92
Normal user
Posts: 29
Joined: 28 Jul 2020, 02:06
Location: Paris - France

Re: Dummy var in Controller

#17 Post by DMike92 » 17 Aug 2021, 23:25

TD-er wrote: 17 Aug 2021, 23:01 That "60 seconds default" is something you can set yourself by the way. ("Config" tab)
Still it is rather not intuitive and I do agree that setting it to "0" for the dummy task does not make sense to have it still running every minute.

I will have to think about its consequences for exitsing settings out there.
Thanks!

User avatar
Ath
Normal user
Posts: 3417
Joined: 10 Jun 2018, 12:06
Location: NL

Re: Dummy var in Controller

#18 Post by Ath » 18 Aug 2021, 09:45

TD-er wrote: 17 Aug 2021, 23:01 I will have to think about its consequences for exitsing settings out there.
I'd suggest to set the 'Device[n].TimerOptional = true;' option when creating a Dummy device, but setting the default Interval to the current default (in the PLUGIN_SET_DEFAULTS' event). Users will still get the same default that has been there for years, but are now able to inhibit the automatic Interval by setting it to 0.
/Ton (PayPal.me)

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Dummy var in Controller

#19 Post by TD-er » 18 Aug 2021, 12:22

Yep, I think that's the way to go.

User avatar
DMike92
Normal user
Posts: 29
Joined: 28 Jul 2020, 02:06
Location: Paris - France

Re: Dummy var in Controller

#20 Post by DMike92 » 18 Aug 2021, 12:32

Ath wrote: 18 Aug 2021, 09:45 I'd suggest to set the 'Device[n].TimerOptional = true;' option when creating a Dummy device, but setting the default Interval to the current default (in the PLUGIN_SET_DEFAULTS' event). Users will still get the same default that has been there for years, but are now able to inhibit the automatic Interval by setting it to 0.
That would be great! Do I have access to this option?

User avatar
Ath
Normal user
Posts: 3417
Joined: 10 Jun 2018, 12:06
Location: NL

Re: Dummy var in Controller

#21 Post by Ath » 18 Aug 2021, 13:05

I can do a PR, probably later today, and provide a test-build.
/Ton (PayPal.me)

User avatar
DMike92
Normal user
Posts: 29
Joined: 28 Jul 2020, 02:06
Location: Paris - France

Re: Dummy var in Controller

#22 Post by DMike92 » 18 Aug 2021, 13:11

Ath wrote: 18 Aug 2021, 13:05 I can do a PR, probably later today, and provide a test-build.
Thank you Ath :-)
And dou you have an opinion about my very first post (trying to use [Dummy#var] in the php string in a controller)?

User avatar
Ath
Normal user
Posts: 3417
Joined: 10 Jun 2018, 12:06
Location: NL

Re: Dummy var in Controller

#23 Post by Ath » 18 Aug 2021, 14:06

I opened this PR #3770

Did have a quick look at the HTTP controller, but it doesn't do any funky things, for as far as I can see.

What type of .bin file do you use?
/Ton (PayPal.me)

User avatar
DMike92
Normal user
Posts: 29
Joined: 28 Jul 2020, 02:06
Location: Paris - France

Re: Dummy var in Controller

#24 Post by DMike92 » 18 Aug 2021, 15:10

mega-20190523
This is what I'm trying to do:

Code: Select all

demo.php?name=%sysname%&valuename=%valname%&value=%value%&myvar=[Dummy#var]
but it appears that [Dummy#var] is not replaced by any value and even the controller seems to send nothing and more over not called at all when this syntax is used.

User avatar
Ath
Normal user
Posts: 3417
Joined: 10 Jun 2018, 12:06
Location: NL

Re: Dummy var in Controller

#25 Post by Ath » 18 Aug 2021, 15:14

DMike92 wrote: 18 Aug 2021, 15:10 mega-20190523
I'm interested in the type of build (normal/test) and Flash size (4M, 1M), as since that release, there has been quite some changes (read: Improvements and extensions) to ESPEasy, so even the test builds have been split into 4 separate builds...
DMike92 wrote: 18 Aug 2021, 15:10 This is what I'm trying to do:

Code: Select all

demo.php?name=%sysname%&valuename=%valname%&value=%value%&myvar=[Dummy#var]
but it appears that [Dummy#var] is not replaced by any value and even the controller seems to send nothing and more over not called at all when this syntax is used.
I understand your issue, but would be very interested to see how well it works with an up to date software release. That's why you are very much invited to try a build from the PR. :D
As said, just mention what ESP hardware you use and I can provide a matching build.
/Ton (PayPal.me)

User avatar
DMike92
Normal user
Posts: 29
Joined: 28 Jul 2020, 02:06
Location: Paris - France

Re: Dummy var in Controller

#26 Post by DMike92 » 18 Aug 2021, 16:05

Hi,
I'm using a Wemos D1 ESP8266 with ESP_Easy_mega-20190523_normal_ESP8266_4M.bin
I cannot try another software for the moment but will definitly try in early september.

I think that replacing [task#var] with their values in the controller string would be a major enhancement.
Note that :
- [Dummy#var] is device #2 and is used with controller linked to device #1 (normal switch input type)
- Even when it's used in its own controller, problem is still there.

To be more clear, I have:
device #1 switch input type linked to controller #1
device #2 Dummy type linked to controller #2
I'm trying:
- in controller #1:

Code: Select all

demo.php?name=%sysname%&valuename=%valname%&value=%value%&myvar=[Dummy#var]
and the controller does not seems to start
Same if I try this in controller #2 (I dont need it but it's just for test purpose).

For the moment I use a workaround by using SendToHTTP in the rules where this syntax works.

User avatar
Ath
Normal user
Posts: 3417
Joined: 10 Jun 2018, 12:06
Location: NL

Re: Dummy var in Controller

#27 Post by Ath » 18 Aug 2021, 16:29

DMike92 wrote: 18 Aug 2021, 16:05 I'm using a Wemos D1 ESP8266 with ESP_Easy_mega-20190523_normal_ESP8266_4M.bin
I cannot try another software for the moment but will definitly try in early september.
I'll provide you with a current, up to date with mega branch, ESPEasy build that should be compatible with what you have now:

(Updated, see below)
Last edited by Ath on 18 Aug 2021, 20:12, edited 2 times in total.
/Ton (PayPal.me)

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Dummy var in Controller

#28 Post by TD-er » 18 Aug 2021, 18:36

DMike92 wrote: 18 Aug 2021, 16:05 Hi,
I'm using a Wemos D1 ESP8266 with ESP_Easy_mega-20190523_normal_ESP8266_4M.bin
I cannot try another software for the moment but will definitly try in early september.

I think that replacing [task#var] with their values in the controller string would be a major enhancement.
Note that :
- [Dummy#var] is device #2 and is used with controller linked to device #1 (normal switch input type)
- Even when it's used in its own controller, problem is still there.

To be more clear, I have:
device #1 switch input type linked to controller #1
device #2 Dummy type linked to controller #2
I'm trying:
- in controller #1:

Code: Select all

demo.php?name=%sysname%&valuename=%valname%&value=%value%&myvar=[Dummy#var]
and the controller does not seems to start
Same if I try this in controller #2 (I dont need it but it's just for test purpose).

For the moment I use a workaround by using SendToHTTP in the rules where this syntax works.
Like we (Ton and I) tried to say when telling "no idea why it doesn't work, because when looking at the code I don't see any reason why it shouldn't" is actually: "It is intended to and thus should already work, in the current code"

In the past year I did change a lot regarding making the parsing as universal as possible, so we can use those task-valuenames and system variables just about everywhere.
Last week I did als fix it so those can be used in the formula field too.

User avatar
DMike92
Normal user
Posts: 29
Joined: 28 Jul 2020, 02:06
Location: Paris - France

Re: Dummy var in Controller

#29 Post by DMike92 » 18 Aug 2021, 18:44

Ok, Sorry, I didn't understood that.
Thanks a lot.
I'll make more tests on simplier configurations and updated firmware in september and let you know if it still does not work.

User avatar
Ath
Normal user
Posts: 3417
Joined: 10 Jun 2018, 12:06
Location: NL

Re: Dummy var in Controller

#30 Post by Ath » 18 Aug 2021, 20:50

Made a small change so the Interval isn't set to the default Sleep delay value from the Config page, as it would do in the original setup (when set to 0). Now when adding a new Dummy device task, the Interval will be 0.
Updated download:
ESPEasy_normal_ESP8266_4M1M.zip
(2.26 MiB) Downloaded 156 times
/Ton (PayPal.me)

User avatar
DMike92
Normal user
Posts: 29
Joined: 28 Jul 2020, 02:06
Location: Paris - France

Re: Dummy var in Controller

#31 Post by DMike92 » 19 Aug 2021, 01:13

Thank you Ath. See that in september :-)

User avatar
DMike92
Normal user
Posts: 29
Joined: 28 Jul 2020, 02:06
Location: Paris - France

Re: Dummy var in Controller

#32 Post by DMike92 » 04 Sep 2021, 13:14

Hi,
Trying to install ESPEasy_normal_ESP8266_4M1M.zip (unzipped of course) with ESPEasy flasher but the flasher does not detect mmy COM ports correctly.
Downloaded the latest realease does not improve (0.04.007):
Image
https://pasteboard.co/Kj25srz.png
(Sorry, dont know how to put image here)

User avatar
Ath
Normal user
Posts: 3417
Joined: 10 Jun 2018, 12:06
Location: NL

Re: Dummy var in Controller

#33 Post by Ath » 04 Sep 2021, 14:06

Have you tried to restart Windows after initially connecting the ESP (so the COM port is detected)? That usually solves this kind of issues.
/Ton (PayPal.me)

User avatar
Ath
Normal user
Posts: 3417
Joined: 10 Jun 2018, 12:06
Location: NL

Re: Dummy var in Controller

#34 Post by Ath » 04 Sep 2021, 14:09

DMike92 wrote: 04 Sep 2021, 13:14 (Sorry, dont know how to put image here)
If you add an attachment (Attachments tab below the text area to type your message), or by drag & drop into the message area. You can also add it in-line (at the last cursor location), using the button for that, after you have added a file, so you can add more text after your image.
/Ton (PayPal.me)

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Dummy var in Controller

#35 Post by TD-er » 04 Sep 2021, 16:21

Some USB to serial chips are known not to work with the included flasher.
Can you also try this (experimental) web flasher? https://td-er.nl/ESPEasy/
After it has been flashed, you can later upgrade to a newer version via the web interface of ESPEasy.

User avatar
DMike92
Normal user
Posts: 29
Joined: 28 Jul 2020, 02:06
Location: Paris - France

Re: Dummy var in Controller

#36 Post by DMike92 » 04 Sep 2021, 17:28

1) Restarting Windows did not help
2) Trying https://td-er.nl/ESPEasy/ tries to connct first to the same ports than the flasher (not to 11)

Workaround:
I have unplgged all my other ESP a just plugged the one I'm interested in. It has taken port 7 which is ok for the flasher.
Will try to install new firmware;)

(Also trying the attaachment - Thanks Ath)
(Deleting attachment now)

User avatar
DMike92
Normal user
Posts: 29
Joined: 28 Jul 2020, 02:06
Location: Paris - France

Re: Dummy var in Controller

#37 Post by DMike92 » 05 Sep 2021, 11:45

So,
I managed to use ESPEasy_normal_ESP8266_4M1M.bin
It does have the refresh interval optional now:)
But there is only 1 possible variable (I need 3)?
Did I missed something ?

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Dummy var in Controller

#38 Post by TD-er » 05 Sep 2021, 13:02

You can select the output type, which is default 1 value (single)
The names of the options are based on how Domoticz uses them, so there are several options like "Temp Hum Baro", which are typically for sensors like the BME280.
If the values don't need to be used on Domoticz, you just select values like Single/Dual/Triple/Quad.

User avatar
DMike92
Normal user
Posts: 29
Joined: 28 Jul 2020, 02:06
Location: Paris - France

Re: Dummy var in Controller

#39 Post by DMike92 » 05 Sep 2021, 14:06

You're a genius!
Thanks
Let'go for the real test;)

User avatar
DMike92
Normal user
Posts: 29
Joined: 28 Jul 2020, 02:06
Location: Paris - France

Re: Dummy var in Controller

#40 Post by DMike92 » 05 Sep 2021, 14:26

YEAH ! Everithing works!

Even the syntax in controller 2 (associated to Switch input) :
demo.php?name=DummyContr&value=%value%&QUI=[Dummy#Qui]
which send a value from another device (Dummy in this case).

This is what I receive now:

Code: Select all

time= 2021:09:05|14:15 (demo.php) ; name='DummyContr' ; value='1' ; QUI='1'
(I added sigle quotes in my php script to capture empty values)

A big thanks to Smiling TD-er and Ath!

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Dummy var in Controller

#41 Post by TD-er » 05 Sep 2021, 14:50

You're welcome :)

Post Reply

Who is online

Users browsing this forum: Ahrefs [Bot] and 36 guests