Syntax of the "system/message" command in the Scheduler

[Pako2]

I'm relatively new here. I'm gradually getting to know the possibilities of EMS-ESP. Now I wanted to try the Scheduler. According to the documentation, one of the possible Scheduling Actions is "send a message to the log and mqtt using the Command system/message". But I have a problem. I tried (even with the help of AI) many variants of how to enter the Value in this case. However, they all ended with an error. You can see the result in the picture. The yellow lines are the result of the command entered using Telnet:
call system message '{"Outdoor temperature":boiler/outdoortemp}'.
The red lines are the result of the Scheduler action, where the Command was system/message and the Value was '{"Outdoor temperature":boiler/outdoortemp}'.
How can I do it so that the action does not end with an error?

[krotname]

system/message expects one string/expression as the value. It is not parsed as a JSON object, so this shape is the problem:

{"Outdoor temperature":boiler/outdoortemp}

In the Scheduler try:

• Command: system/message
• Value: boiler/outdoortemp

That should publish/log just the computed value, assuming that entity path exists. For a literal test string, quote the value, for example 'hello world!'.

The relevant path in the code is: the scheduler calls compute(scheduleItem.value) and passes that result to /api/system/message; System::command_message() then logs/publishes the resulting computed_value. The tests also cover /api/system/message with quoted literals and entity paths such as system/settings/locale.

If you need a labeled JSON payload like {"Outdoor temperature": ...}, system/message is probably not the right target by itself. First get the plain entity expression working, then do the labeling in the MQTT consumer or with whatever supported expression formatting EMS-ESP exposes for message strings.

[Pako2]

Thank you for trying to help. Yes, I started my experiments with the simple expression boiler/outdoortemp. I also tried (before asking the question) "hello world" expression. But the result always ends with an error. Only then did I start trying (first using Telnet) more complex expressions. The above "JSON" syntax was accepted via Telnet, so I assumed that it could also work in the Scheduler. But it doesn't work. Try it yourself.
I mainly point out the different behavior of the system/message command via Telnet and via the Scheduler. Why does it work in one case and not in the other? It seems that the action "send a message to the log and mqtt using the Command system/message", as one of the Scheduler options, is not functional.
The attached screenshot shows the result with the value boiler/outdoortemp and with the value "hello world" (via the Scheduler).

[VlastiBroucek]

Some working examples to start with are at https://demo.emsesp.org/scheduler

[krotname]

If even a quoted literal such as 'hello world' and a plain entity path fail in the Scheduler, while the same command works through Telnet/API, then I agree my first answer was too focused on value syntax. That points to the Scheduler execution path, not just JSON formatting.

The useful minimal repro is: Scheduler command system/message, value 'hello world' or one of the demo examples, exact firmware version, and the exact error from the screenshot/log. If the demo Scheduler examples work but this command does not, it is probably either a quoting/computation bug in the Scheduler action or system/message is not actually wired as a valid Scheduler command. I would keep this as a bug/maintainer question with that minimal repro.

[yudin-s]

Your second screenshot makes this look less like a quoting/value-syntax problem and more like a Scheduler-specific system/message path.

The demo examples are still useful as a baseline: if one of those simple system/message schedules works on the demo but the same shape fails on your device, compare the exported schedule JSON and firmware version first. But if even a plain Scheduler value like boiler/outdoortemp or "hello world" fails locally while Telnet works, the code path difference is important.

The scheduled job runs from WebSchedulerService::loop() and calls the command with the value already computed:

command(scheduleItem.name, scheduleItem.cmd.c_str(), compute(scheduleItem.value.c_str()));

That then routes to /api/system/message. But System::command_message() does not simply publish the API data it receives. It sets webSchedulerService.raw_value = value and waits for webSchedulerService.computed_value to be filled. That fill normally happens at the top of the scheduler loop:

if (!raw_value.empty()) {
    computed_value = compute(raw_value);
    raw_value.clear();
}

So when system/message is called from Telnet/API, the scheduler task can pick up raw_value and compute it. When it is called from the Scheduler itself, it may already be inside the scheduler loop executing the scheduled command, then waiting for another scheduler-loop pass before it can finish. That would explain a timeout / empty result from Scheduler while the same command works through Telnet.

I would test the smallest case from the demo first. If that also fails on your device, I would report it as: Scheduler action system/message appears to be self-blocking because command_message() waits for WebSchedulerService::loop() to compute raw_value, while Scheduler-triggered commands are already running inside that loop. One possible fix is for system/message to use the already-provided API data directly when called from Scheduler, or for Scheduler to avoid routing this command through the async raw_value path.

If that matches the screenshot log, marking the relevant answer would help separate the syntax examples from the Scheduler implementation issue.

[Pako2]

Thanks for the extensive analysis. But it will probably be a little different, because the error occurs even if the value is constant and does not need to be calculated.
The log snippet shows the case when Value in the Scheduler is 1.

[proddy]

I you just want the message to contain boiler/outdoortemp just write it like that, don't turn it into a JSON object. If you can send a screenshot of the Scheduler in the WebUI, it would be helpful to see what you're doing.

Note: the scheduler has been rewritten in the next dev version and split into two services, a modified Scheduler and a new Commands service, so I wouldn't spend too much time trying to analyse the code.

[Pako2]

As I wrote, I started with the expression boiler/outdoortemp. But since it didn't work, I was looking for a solution. It should be noted that I don't actually need to have this value in the log. It was chosen only because it is very illustrative. I just wanted to learn how to use Scheduler to write something (anything) to the log.
It is probably also necessary to mention that I have version 3.8.2.

[MichaelDvP]

Thanks for reporting and your tests, pointing to a bug in 3.8.x. The system/message command does not work from scheduler. For emsesp without psram it also does not work from mqtt/console, only call from api is possible.

Problem is here:

EMS-ESP32/src/core/system.cpp

Lines 226 to 235 in b8a63ae

	EMSESP::webSchedulerService.computed_value.clear();
	EMSESP::webSchedulerService.raw_value = value;
	for (uint16_t wait = 0; wait < 2000 && !EMSESP::webSchedulerService.raw_value.empty(); wait++) {
	delay(1);
	}
	if (EMSESP::webSchedulerService.computed_value.empty()) {
	LOG_WARNING("Message result is empty");
	return false;
	}

the command waits for scheduler task to process the value. But if the command is called from scheduler it waits until timeout.
In non-psram systems it timeouts for all callers running sync in main loop. so only TCP works.

As a side-effect of the changed command structure in 3.9.0, this issue is solved. But i don't think it will be addressed in 3.8.x.

[Pako2]

Thank you for confirming my suspicion about the system/message command not working in the Scheduler and for the explanation. It goes without saying that there is no point in solving this in 3.8.x, when it is already solved in 3.9.x. I just wanted to learn something. The goal was achieved despite the difficulties.

[MichaelDvP]

Please check dev.6 from https://github.com/MichaelDvP/EMS-ESP32/releases
I have enlarged the ip stack and call the value processing direct.

[Pako2]

I upgraded to v3.8.3-dev.6 and ran new tests. I am happy to confirm that the bug is fixed and the system/message command works as expected.

I have one more note. In the Scheduler in the live demo there is a mistake in the schedule called "bad_wifi". There is an incorrect Condition system/network info/rssi < -70.
The correct form is system/network/rssi < -70.
The original bad version causes unwanted reboots!

[MichaelDvP]

This wrong path is set here:

EMS-ESP32/mock-api/restServer.ts

Line 4142 in b8a63ae

time: 'system/network info/rssi < -70',

but the live demo has to be updated by @proddy

[yudin-s]

Great, that confirmation is useful. Since the maintainer answer has the real 3.8.x cause and the dev.6 result, I would leave that as the canonical answer here. The live-demo bad_wifi condition sounds worth a separate small fix or report, because a wrong path that can trigger unwanted reboots is easier to track outside the system/message scheduler bug.