Send command to ESPEasy via UDP.

[Aria James]

Yep, ESPEasy can receive UDP commands, so you should be able to send them from your PLC without any issues. Just make sure both devices are on the same network and UDP is enabled in ESPEasy. I’d recommend testing it first with a simple UDP sender tool before setting it up fully.

[Smotek7]

Yep, ESPEasy can receive UDP commands, so you should be able to send them from your PLC without any issues. Just make sure both devices are on the same network and UDP is enabled in ESPEasy. I’d recommend testing it first with a simple UDP sender tool before setting it up fully.

Have you read this thread?
That was solved half a year ago.
Now we are looking for a solution for uart to UDP.

[Ath]

I have done some improvements to P020 - Serial Server in PR #5287

This should at least improve the handling of TCP -> Serial pass through, and when receiving via serial it can now generate an event with the data converted to hex string, as usable by the SerialSendMix command.

Also added a serialsend_test command to test event processing more easily.

Here's an ESP32-C3 Collection A build for testing:

ESP_Easy_mega_20250323_collection_A_ESP32c3_4M316k_CDC.zip

(2.09 MiB) Downloaded 72 times

[Smotek7]

Thanks for the info.
I will test and report back.

[Ath]

Thanks for the info.
I will test and report back.

I have another feature for you to test: Pass-through from UDP to Serial
Available in this build:

ESP_Easy_mega_20250326_collection_A_ESP32c3_4M316k_CDC.zip

(2.1 MiB) Downloaded 65 times

You can select to have TCP (Default), UDP or TCP & UDP handling. UDP will only pass all data received on the configured port (same port is used for both TCP and UDP) to the Serial port.

Please report your findings

[Smotek7]

So the first test.
I used the latest version.
I have a terminal connected to the uart for receiving and transmitting.

I have set
TCP Port: 1234
Protocol: UDP
I am sending UDP messages with PLC
Sending UDP -> uart in HEX works.

Second direction
uart -> UDP
I have an event

Code: Select all

on !Serial do
  SendToUDP,192.168.1.100,666,'%eventvalue%'
endon

At a speed of 115200
That works fine.
0x00 is also sent
even long strings

But at a speed of 9600
the event is divided into several strings, each about 10-20 bytes.
It is already at the event
so I see it in the log.
6660770: EVENT: !Serial#0x0603050701040545682034e1294e57081305091004
6660779: ACT : SendToUDP,192.168.1.100,666,'!Serial#0x0603050701040545682034e1294e57081305091004'
6660823: EVENT: !Serial#0x06030507010405456820f101294e5708130509100406
6660831: ACT : SendToUDP,192.168.1.100,666,'!Serial#0x06030507010405456820f101294e5708130509100406'

But great work, I think this will work for me.
Tomorrow I will make a connection to the BMS and test again.

[Ath]

Looking good already, great

You could increase the RX Receive Timeout a little at 9600 baud, so it'll wait a little longer for more data to arrive, but if you can handle the partial data blocks you might not need it.

[Smotek7]

I didn't realize I could set the
RX Receive Timeout (mSec):
I set it to 100ms and it works even at 9600.

I forgot to ask,
how does the serialsend_test command work?

[TD-er]

Just to make sure, you're not using SoftwareSerial, right?
SoftwareSerial typically slows down just about anything when running at lower baudrates.

[Smotek7]

@TD-er
no
I use HWSerial0

[TD-er]

HW serial is also used by the console and logs.
If you need to send out logs at such a low rate, the system may not be able to send all the data/logs.

[Ath]

I forgot to ask,
how does the serialsend_test command work?

It puts the provided content into the receive buffer, like it was received via serial, and starts the processing as if it was received via a serial port. I (only) use it for testing without anything connected to a serial port, so see if the rest of the 'chain' is working as intended, as I don't own (all) these serial connected devices for testing...

[Smotek7]

@Ath
Today I connected the BMS.
The data is received in the PLC.
But I can't parse it.
I think the problem is that the esp sends data as a string. (Ascii?)
For example, x00 comes to the urat, it sends it as a "0" string
When the plc receives it and converts it to HEX, it is x30
Could this be the problem?
Can it be sent as HEX?

[Ath]

What command is used to send the data to the PLC?
For UDP connection, the ESP does only receive commands to relay them to the serial port, but when sending data from the serial port to an UDP port on the network, the SendSerialMix command has to be used to convert hex strings to binary data. The checkbox "Event data hex format" converts serial received data to a hex string in rules.
Maybe I need to add a SendToUDPmix (or smt similar) command that'll convert a hex string to binary, like the SendSerialMix command

[Smotek7]

@Ath

I use
SendToUDP,192.168.1.100,666,'%eventvalue%'

parameter
Event data hex format:
must be true
so that Hex data is received
it works correctly.

But I struggled for a long time and in a complicated way I managed to parse a couple of values ​​in the PLC and convert them to the correct data.
So far the temperature with BMS.

It would be great if there was a SendToUDPmix
Ideally if it sent to the controller.
Resp. It can't be that if Event data hex format:
is checked and the Controller is set, it sends it to the set controller as HEX.
But if that's a complication, then a command in the rules is enough.

[Ath]

It would be great if there was a SendToUDPmix

Thanks for the feedback, I'm working on this command now.

Ideally if it sent to the controller.
Resp. It can't be that if Event data hex format:
is checked and the Controller is set, it sends it to the set controller as HEX.
But if that's a complication, then a command in the rules is enough.

Currently, Controllers send the values of a plugin to some receiving end, but not string-data, like the (converted) HEX data will most likely be. (Handling string-data in ESPEasy is on the long-term TODO list)
For now, sending will have to be done using the new SendToUDPMix command, as it already does the required connection setup, only have to provide the decoded data.

[Ath]

@Smotek7
I've added a new SendToUDPMix command (in a separate PR #5289 from the P020 improvements), and made a combined build:

ESP_Easy_mega_20250330_collection_A_ESP32c3_4M316k_CDC.zip

(2.1 MiB) Downloaded 60 times

Looking at the rules you shared, all you have to update is the SendToUDP command to be SendToUDPMix.
It accepts only a single argument following the UDP port number, just like SendToUDP, so when sending separated hex and plain text values for the mix, the entire content for that argument must be quoted. And when using commas or spaces in a text argument, that also must be quoted with a different quote-pair (ESPEasy supports single-quotes: ' double-quotes: " and back-ticks: ` for quoting).

Example:

Code: Select all

  SendToUDPMix,192.168.0.100,666,'0x45535045617379," is"," a lot of ",0x46554E," :-)"' // Sends: ESPEasy is a lot of FUN :-)

[Smotek7]

@Ath
I tried the command

Code: Select all

SendToUDPMix,192.168.0.100,666,'%eventvalue%'

but it doesn't work for me.
I thought the problem was that %eventvalue% contains this

Code: Select all

!Serial#0x4e570013000000000603000000000006800000129

or even ascii characters.
But that's not it
I tried sending

Code: Select all

SendToUDPMix,192.168.0.100,667,'0x4E57001300000000006030000000'

but it doesn't send this either.
Am I doing something wrong?

[TD-er]

When in doubt about what is in the eventvalue, you can also try to send it to logs

Code: Select all

logentry,"Eventvalue: '%eventvalue1%' ..."

N.B. I added extra single quotes so you can see if the eventvalue is empty.

And to test the command you can also try sending a string yourself via the command field on the tools page.

[Ath]

Hm, that's somewhat unexpected, as I'm using the existing SendToUDP code, extended with handling the 'mix' content. I'll review my changes.

Port 667 in the last example, was that on purpose?

Edit:
Because of the ! in the event name, variable %eventvalue% (and only that exact variable) is replaced by the data following the # of the actual event, so only the 0x4E... part.

[Smotek7]

Yes, port 667 was the intention
But the error was in the IP xxx.xxx.0.xxx
Now my data is going through
If I use

Code: Select all

SendToUDPMix,192.168.1.100,667,'0x4E57001304231E000603000033'

The data comes correctly in HEX

but if I use

Code: Select all

SendToUDPMix,192.168.1.100,667,%eventvalue%

or

Code: Select all

SendToUDPMix,192.168.1.100,667,'%eventvalue%'

they always come in ascii

There will be no problem that the value in %eventvalue%
starts with !Serial#..... and does not start with 0x

Code: Select all

10674041: EVENT: !Serial#0x4e5700130000000006030000000000006800000129
10674049: ACT : SendToUDPMix,192.168.1.100,667,'!Serial#0x4e5700130000000006030000000000006800000129'

[Ath]

Yes, port 667 was the intention
But the error was in the IP xxx.xxx.0.xxx
Now my data is going through
If I use

Code: Select all

SendToUDPMix,192.168.1.100,667,'0x4E57001304231E000603000033'

The data comes correctly in HEX

but if I use

Code: Select all

SendToUDPMix,192.168.1.100,667,%eventvalue%

or

Code: Select all

SendToUDPMix,192.168.1.100,667,'%eventvalue%'

they always come in ascii

There will be no problem that the value in %eventvalue%
starts with !Serial#..... and does not start with 0x

Code: Select all

10674041: EVENT: !Serial#0x4e5700130000000006030000000000006800000129
10674049: ACT : SendToUDPMix,192.168.1.100,667,'!Serial#0x4e5700130000000006030000000000006800000129'

Hm, my memory seems a bit flaky for that !serial handling, but you are confirming what the code says

Small adjustment should get you going:

Code: Select all

  SendToUDPMix,192.168.1.100,667,%eventpar%

[Smotek7]

But I tried as if the serial %eventpar% in the event did not exist.
I also tried

Code: Select all

logentry,'Test:%eventpar%'

it returned with the log

Code: Select all

13083685: ACT : logentry,'Test:%eventpar%'
13083688: Test:%eventpar%

[Smotek7]

@Ath

Code: Select all

SendToUDPMix,192.168.1.100,667,'0x00%eventvalue%'

It doesn't look pretty but the data looks ok
I'm going to check it out in detail.

[Ath]

Ah, all other %event*% variables are ignored when the event starts with an exclamation mark, I'll discuss with TD-er how we want to handle this.

[Ath]

@Ath

Code: Select all

SendToUDPMix,192.168.1.100,667,'0x00%eventvalue%'

It doesn't look pretty but the data looks ok
I'm going to check it out in detail.

You're a bit lucky with this one as !serial# is a multiple of 2, and the hex-parser ignores invalid hex character-pairs, including the 0x that is part of the data.
When changing your fix to this:

Code: Select all

SendToUDPMix,192.168.1.100,667,'0x%eventvalue%'

you should not need to change anything on your receiving end

[Smotek7]

I confirm that both 0x and 0x00 work.
If I use 0x, I have 0x000E000000 extra on the receiving side.
But that's not a big problem, I can remove it during parsing.
I have the data in the PLC ok.
@Ath perfect work. Thank you.
Another question, will these changes appear in new builds?

[TD-er]

Yep, Ton will message me when it can be merged.
We have Signal open to message eachother all day

If it can be used to discuss military code, we can also use it to discuss C++ code

[Ath]

Made 2 changes to the code:
- When the eventname starts with ! the variables %eventname% and %eventpar% are processed as well, just like %eventvalue%
- The function {substring:<start>:<end>:<string>} now allows <end> to be empty, to get the part of the string from <start> up to the end of the string

Created a special build with SendToUDPCmd also included, for testing:

ESP_Easy_mega_20250331_collection_A_ESP32c3_4M316k_CDC.zip

(2.1 MiB) Downloaded 56 times

This should now send only the hex-coded string part:

Code: Select all

on !serial do
  SendToUDPMix,192.168.1.100,667,'%eventpar%'
endon

[Smotek7]

@Ath
I tested the new version
%eventpar% works correctly
only HEX data is transmitted.

@TD-er
Today I thought about asking if there was any progress with the universal MODBUS plugin.
But I realized that these Ser2net adjustments actually solved it.
If I send HEX data from Rules to the Modbus device correctly via SerialSendMix
I get a HEX response back and I can read the necessary data with it.
I know it's not pretty, but for 1-2 data from a specific MODBUS device it's usable.
I have to test it. I just need to solve the flow control via HW.

[TD-er]

Nope, not yet on the universal modbus plugin.
I did think about it today though, as it needs a central configuration on the hardware tab, just like I2C and the multiple I2C bus config Ton recently added.

However I have been held back in the past ~6 weeks to contribute to ESPEasy.
Well at least way too few things I would like to do.
As I really would like to finish the WiFi/Ethernet rewrite I have been working on as it is holding back just about any other feature/change I want to implement.

[Smotek7]

@TD-er
Thanks for the info.

@Ath
I'm solving another interesting problem.
If I disconnect the power and reconnect it, the ESP does not receive UDP data.
Restarting does not help.
Opening Ser2net devices and pressing the Submit button helps.

The opposite direction from ESP to PLC works, because when restarting I send the UDP command "start" and it arrives at the PLC.

[Smotek7]

@Ath
I'll add some info
I think it will be a problem that it doesn't load new settings after a restart.
I set Protocol: TCP&UDP and I send both TCP and UDP.
After restarting, only TCP works,
UDP doesn't work.
If I press Submit on Ser2net devices, both TCP and UDP start to pass.

[Ath]

@Ath
I'll add some info
I think it will be a problem that it doesn't load new settings after a restart.
I set Protocol: TCP&UDP and I send both TCP and UDP.
After restarting, only TCP works,
UDP doesn't work.
If I press Submit on Ser2net devices, both TCP and UDP start to pass.

How is your serial port configured in the SerialServer plugin?
When having the Serial Console enabled in the Tools/Advanced settings (default: Enabled), you shouldn't use Serial0 for the plugin. Serial1 is a much better choice. SoftwareSerial should better not be used.
Also, the GPIO pins used for the serial configuration shouldn't be in use by other plugins. The Hardware page shows what GPIO pins are used by standard ESPEasy settings, like I2C, SPI, etc., not what pins are used by plugins.

This doesn't explain why (only) UDP won't start, so I'll again review my changes, though I've already done that quite thoroughly
This would imply that UDP also doesn't work on an initial power-up of the device, correct?

[Ath]

An alternative could be to configure only for the UDP port, to free a handle of a very limited pool of handles (5). Or disable the P2P UDP port (if you don't need it) by setting the port number there (Tools/Advanced) to 0.

[Smotek7]

My settings

S2N1.jpg (73.79 KiB) Viewed 2885 times

S2N2.jpg (41.9 KiB) Viewed 2885 times

I tested:
Change Serial0 to Serial1 , didn't help
Disable Enable Serial Port Console: , didn't help (was USB)
Disable ESPEasy p2p UDP port: , didn't help
I changed Protocol: to UDP , didn't help

It always helps just to press Submin on Ser2net.
Is there any command to read the current Ser2Net settings after a restart?

[Smotek7]

@Ath
I found a solution.
I am not sending data to Ser2net on the configured port.
I set back
ESPEasy p2p UDP port: to 8266
and I send the command
SerialSendMix,'0x4e570013000000000060300000000000006800000129'
This works even after restarting ESP.

[Ath]

The serial port for the plugin should not be using HWSerial0 if you have the logging enabled in the Tools/Advanced page, so setting that at HWSerial1 is at least a configuration improvement.
In ESP32 the serial ports are kind of virtual, but they can only be used for a single purpose, and the last initialization 'wins' from a previous initialization. Having logging enabled on HWSerial0 can be very helpful at times

Haven't found an explanation why UDP shouldn't start on a power-cycle yet, though.

[Smotek7]

@Ath
I currently have a working solution, if the cause is found it will be better.

I would try it on another board.
I have a few WT32s here.
Can you make me a .bin for ESP32 ETH?

[Ath]

I would try it on another board.
I have a few WT32s here.
Can you make me a .bin for ESP32 ETH?

Sure:

ESP_Easy_mega_20250402_collection_A_ESP32_4M316k_ETH.zip

(2.31 MiB) Downloaded 84 times

[Ath]

... if the cause is found it will be better.

I think I found the cause for UDP not starting at cold boot. At plugin start-time, rather quick after the ESP is started, WiFi is not initialized yet, and causes the UDP listener not to be initialized.
There was already a check every second for the TCP server to be active, and I now also check the UDP listener in that loop.
2 fresh builds:

ESP_Easy_mega_20250402_collection_A_ESP32_4M316k_ETH_a.zip

(2.31 MiB) Downloaded 47 times

(Added _a suffix to the .zip file to distinguish from today's earlier build)

ESP_Easy_mega_20250402_collection_A_ESP32c3_4M316k_CDC.zip

(2.1 MiB) Downloaded 51 times

[Smotek7]

@Ath
I tested it on ESP32C3 (on my original wiring)
and it works now.
So problem solved.

[Ath]

Ah, great, thanks for the quick response

[Ath]

Both features (P020 with UDP receiver support and SendToUDPMix command) have been merged into the mega branch, and will be included in the next release.

A new beta release, using IDF 5.4 pre-release framework, will be made available tomorrow at https://td-er.nl/ESPEasy/latest/ (The Flash page, can upload a binary when using Chrome or Edge browsers on Windows).

[TD-er]

I did update the webflasher page Ton linked.

[Smotek7]

Yesterday I tried to flash with
https://td-er.nl/ESPEasy/
and there were no new functions .
I didn't know that there was also
https://td-er.nl/ESPEasy/latest/
and then I noticed the link in the thread.

I tried using these commands modbus temperature sensor.
And it works. So the Modbus universal was partially solved.
It's not in two clicks, but it can be done.

I also tried to parse the data directly in espeasy using "substring", so that I could save it in dummy devices.
I can't calculate the result in rules.
I have it like this:
0x0104020117f8ae
0117 are 2 byte values
the calculation should be
01 to dec is 01
17 to dec is 23
then
01 * 256 + 23 = 279 / 10
Temperature 27.9
TaskValueSet 2.1,{strtol:16:{substring:8:10:%eventpar%}}*256+{strtol:16:{substring:10:12:%eventpar%}}/10
The + doesn't work for me
Do I have to do it in two steps?

And the second question is can I run two Ser2net devices on one ESP32 (WT32)?
One speed 9600, the other 19200. Serial1 and Serial2.

[TD-er]

You can also prefix your hex value with 0x and then use it as a numerical.

Code: Select all

TaskValueSet 2.1,0x{substring:8:12:%eventpar%}/10

If it doesn't do the calculations, you can also assign it to a variable first.

Code: Select all

let,1,0x{substring:8:12:%eventpar%}/10
TaskValueSet 2.1,[var#1]

[Smotek7]

@TD-er
The first option also works.

So I'll give a little guide, maybe it will help someone.
This is how you can read various Modbus devices that don't have a plugin.

SHT20 modbus sensor, temperature/humidity s ALI.
ESP32C3, uart to RS485 converter, with HW data flow control.
Task 1 - Ser2net
Event processing: Generic
Event data hex format: true

Task 2 - Generic - Dummy Device
Output Data Type: Temp / Hum
Rules:

Code: Select all

On System#Boot to
 timerSet, 1, 10
endon

On Rules#Timer=1 to
 SerialSendMix,'0x010400010002200b'
 timerSet, 1, 10
endon

on !Serial do
 TaskValueSetandRun,2,1,0x{substring:8:12:%eventpar%}/10
 TaskValueSetandRun,2,2,0x{substring:12:16:%eventpar%}/10
endon

[TD-er]

Cool!

Just one more tip.

You're now calling "taskvaluesetandrun" on the same task twice.
This will also trigger sending to the attached controller (if any).
So what you can do it calling "taskvalueset" on the first call and "taskvaluesetandrun" on the second.
Or simply "taskvalueset" on both and then "taskrun,2" (for task nr 2) right after.

[Smotek7]

Yes
I didn't realize it because I first adjusted the temperature and then just Ctrl C and Ctrl V for humidity