TaskValueSet for Dummy devices (Used as VARS for Rules) doesn't update value trough MQTT directly (OPENHAB)

[jodur]

NOTE: This is not a support forum! For questions and support go here: https://www.letscontrolit.com/forum/viewforum.php?f=1

Steps to reproduce

How can we trigger this problem? Add a dummy device and create a variabele. Write this variabele with the command TaskValueSet within rules. The variable gets updated only with de acquisition time that is set in the plugin setting

Does the problem presist after powering off and on? (just resetting isnt enough sometimes)

Expected behavior

Tell us what should happen? After a TaskValueSet of a value, an update trough MQTT should imediate follow.

Actual behavior

Tell us what happens instead?

The value only gets updated with the cycle time. I tried to use Taskrun within the rules to force an update, but i then have unexpected behaviour.

Workarround: I manually publish the value trough MQTT with the same topic as used by normal ESP updates, within the rules to send the update immediate

System configuration

Hardware:

Software or git version:

[TD-er]

So to summarize: You would like the MQTT message to be sent as soon as the rule processes it and not only when there is a new measured value? (and thus always one cycle behind) And thus your delay to get the MQTT update is almost equal to the measurement cycle of the device?

[jodur]

No not exactly, the value from a dummy device is normally only updated with the cycle time (delay) that is set in the configure page of the plugin. You could set it to 1 sec. minimum,so it would be updated within 1 sec, but the drawback is that it sends every second a MQTT message. A delay of 0 sec isn't allowed within the plugin.

I would like to that a MQTT message is send, directly after changing a value trough the TaskValueSet command. This should also be the case when you issue the command from http or the serial port.

[uzi18]

maybe we can add an option to dummy device to send to controller if value was updated?

But I think it is expected behavior to work with timeout .... like today.

[TD-er]

@uzi18 I've already planned for such a change, but that may involve quite some other changes.

[giig1967g]

solution proposed on #1324. New command: TaskValueSetAndRun

[thomastech]

I recognize this issue is several months old, but I experienced the MQTT issue reported here. That is to say, I enabled the dummy device to use the "Send To Controller" Option, but was not receiving MQTT updates when the dummy value changed (via my rules' taskvalueset commands).

I saw the same things the author of this issue reported. MQTT updates at each timer interval work fine. And my workaround also involved sending a MQTT publish within my rules.

So after much searching I found this old reported issue and learned that the solution is to use TaskValueSetAndRun.

I tried out the proposed solution. I would like to provide some feedback and encourage the dummy device developer to look at it again:

1. This new command (TaskValueSetAndRun) is not publicized in the ESPEz Wiki and has never been discussed on the forum. So I assume it is not for public use. So that begs the question, is there an official solution that ESPEz users should be using instead?

2. The dummy plugin should include a notation to the user that they must use TaskValueSetAndRun when the Send To Controller option is enabled. A much better solution is to eliminate the special command requirement and revise the plugin so the "Send to Controller" works transparently (without special commands in the rules) like the other plugins.

3. I edited my rules and used TaskValueSetandRun instead of TaskValueSet. I confirmed it sends MQTT when the dummy value is updated. But it often causes reboots, so it is not usable. I've restored my old rules with the TaskValueSet and Publish workarounds.

BTW, I'm using ESP_Easy_mega-20181207_normal_core_241_ESP8266_1024.bin.

• Thomas

[TD-er]

About the documentation. I know we are far behind with documenting stuff. There is a slack channel with topics about what to update/change/add and it has so many topics, which is essentially an enormous todo list.

As you may have noticed, we're now moving to a ReadTheDocs structure, mainly to keep the documentation more in sync with the code. The source for the documentation is in the Git repo and RTD will flag a new version when we set a new version. The RTD is re-built every time a new merge is done.

And since @Grovkillen is the docs' main developer at the moment, maybe a good moment to add the Dummy + TaskValueSet documentation + examples.

About the reboots you see. What is the reboot cause?

The Dummy plugin has never been my favorite, since it is trying to fix something with a kludge approach, instead of some proper change of the model. But I can also see it is been used quite a lot. A lot of quite nifty solutions are made using the dummy plugin too. Also changing ESPeasy to send values per value to a controller, or collecting values from different sources, may involve quite some big changes. So I expect it will be a plugin to stay for a long time.

[thomastech]

About the reboots you see. What is the reboot cause? Boot: | Manual reboot (7) Reset Reason: | Software Watchdog

These reboots occur often with TaskValueSetAndRun. When I use TaskValueSet (along with Publish) everything is happy and good.

I fully understand (and appreciate) that there are a lot of changes going on with ESPEasy that expand its capabilities. But honestly, I'd prefer that any new functions/features be put on hold while the instability issues are resolved.

And when the new features are eventually added they should provide backwards compatibility (without rule and device edits). Sort of follow the Hippocratic Oath, primum non nocere. Otherwise I suspect the developers will face a community mutiny.

• Thomas

[giig1967g]

I had some reboots when using TaskValueSetAnd Run when used in an event called from another event (sort of nested call). I suspected a memory issue. What is your rule syntax?

[thomastech]

Syntax is as follows:

// Sub-Routine: Turn on relay.
on RelayOn do
  TaskValueSetAndRun 2,1,1    // Set RelayState (Dummy Device) and publish MQTT.
  gpio,13,0  // LED On
  gpio,12,1  // Relay On
endon

The workaround (no reboots) is as follows:

// Sub-Routine: Turn on relay.
on RelayOn do
  TaskValueSet 2,1,1    // Set RelayState (Dummy Device)
  Publish %sysname%/RelayState/value,[RelayState#value]
  gpio,13,0  // LED On
  gpio,12,1  // Relay On
endon

• Thomas

[TD-er]

But honestly, I'd prefer that any new functions/features be put on hold while the instability issues are resolved.

Have you looked at the commits of the last 3 months??

And at first impression (based on the name of the command), I would suspect the command is executed immediately from within the rules, which may cause a stack overflow since it will also cause other things to be executed from there.

[giig1967g]

@thomastech where do you call the RelayOn event from? From another rule?

[thomastech]

Have you looked at the commits of the last 3 months??

Yes. I have observed that developers like you and Grovkillen are effectively playing whack-a-mole because the target firmware is constantly changing. Winning that kind of game takes extreme effort.

And at first impression (based on the name of the command), I would suspect the command is executed immediately from within the rules, which may cause a stack overflow since it will also cause other things to be executed from there.

I understand the implications. Just more reason for me not to use the TaskValueSetAndRun solution.

where do you call the RelayOn event from? From another rule?

// If Push Button is pressed toggle the Relay.
on PushSwitch#switch=1 do
   if [RelayState#value]=0 // Relay is currently off.
      event RelayOn
   else 
      event RelayOff
   endif
endon

• Thomas

[giig1967g]

@thomastech I have coded the TaskValueSetAndRun command. Essentially is a sequence of taskvalueset + taskrun Nothing else. I also noted reboots when using taskvaluesetandrun from a nested event. Probably bbecause taskrun sends 4 publish commands in sequence. A solution ccoulkd be to send only one value. I will look unto it.

@TD-er Regarding the future of dummy plugin, I would use system variable instead.

[thomastech]

@giig1967g & @TD-er I appreciate your efforts. And I don't want to interfere with more important firmware issues. So I'll exit now and allow you to get back to Making ESPEz Great Again (MEGA).

• Thomas

[tonhuisman]

This seems to be solved, so can be closed.