Send command to ESPEasy via UDP.

[Smotek7]

Is it possible to send commands to ESPEasy UDP?
I was watching
https://www.letscontrolit.com/wiki/inde ... _Reference
here is just HTTP.
UDP is used in P2P. ESPEasy can also receive UDP commands.
Is it possible?
I want to send the command with the PLC to ESPEasy in the local network.

[TD-er]

The p2p protocol isn't that complex, so you can also implement it in a PLC.

It is processed here:
https://github.com/letscontrolit/ESPEas ... #L298-L325

As you can see, it is just 'plain text' commands.
So you can just send a command like this:

Code: Select all

event,"myevent=12.34,4.5,6.78"

Or any of the other commands which are not restricted...

Here I may have to look into the code myself, as I see the source is set to "VALUE_SOURCE_SYSTEM", so I have to make sure only restricted commands are accepted. (otherwise anyone could just call to set WiFi credentials, perform a factory reset, etc.)

[Smotek7]

That is, when I have done so far
http://192.168.1.128/cmd=GPIO,1,1
I can as UDP to the address 192.168.1.128:8266
send
cmd=GPIO,1,1
and this should work?

[TD-er]

Without the 'cmd='

[Smotek7]

@TD-er
it works perfectly
Thanks for the advice

[TD-er]

Told you it wasn't that complex

Which reminds me, we should make it a bit more complex... ehh add some kind of security as it is now a bit too easy for anyone to do malicious things...

[Smotek7]

It would probably be enough to define not only the port but also the list of IPs from which to receive.
But I suppose that there are more important things in your list.

[TD-er]

Well I was thinking about changing the p2p layer to use the AsyncUDP library (for ESP32) as it currently causes issues in some cases when transferring large files (e.g. upload new firmware) as those unprocessed UDP packets cause the LWIP stack to stall processing packets.
And this also allows for things like Multicast, which does make sharing sensor data a lot easier and a lot more flexible.
So when moving to this, I will probably make it a setting to still allow "the old" way of accepting commands and data.

Adding an IP-filter is also a good idea.

[ThomasB]

Interesting info. I tried and seems I am doing something wrong. P2P controller is enabled.

Using a browser to send them, my emulated P2P commands to a device at 192.168.1.103 all fail. For example:

Code: Select all

http://192.168.1.103:8266/reboot

What is the correct syntax?

- Thomas

[Ath]

You'll need to use UDP communication, and I don't expect your browser to support that in that way

[Smotek7]

But those are two different things. http and udp port 8266. Udp cannot be sent from the browser.
What do you want to do?

[Ath]

From the browser we have the available ways of controlling an ESPEasy device. For devices only having UDP communication available (no handshake), the example shown above will work as intended.

[ThomasB]

No need for it, just thought it was an interesting idea to emulate P2P. When I have more time I'll try again with my UDP sender utility.

- Thomas

[Smotek7]

Another UDP question.
Ser2Net is TCP.
Can it also be used via UDP?
I would like to use it for RFLINK.
But I can't receive TCP on the other side.
I am limited to UDP.

[TD-er]

I don't see why it can't be done, however it does require some changes in the code.
However you can also try to use rules and just 'echo' the received data using the 'sendto' command, right?

[Smotek7]

Everything can be done, it's just a matter of time and money.

I was wondering if it doesn't work with the current code.
I thought of the rules, when I have time I'll try it.
The problem is that I haven't used Ser2Net even with TCP yet.
I have to try.
Thanks for the info.

[TD-er]

In Arduino there are WiFiClient and WiFiUdpClient.
If I'm not mistaken, this plugin uses WiFiClient. So there needs to be a code change for this to work.
And I'm not sure if it is just a matter of renaming those to make a quick test to see if it does work, or whether there might be significant other changes too.

[Smotek7]

I have to try TCP first.
There is a "packet sender" via the PC.
Then I'll try UDP.
And I need a LAN.

[TD-er]

ESPEasy does support quite a lot of LAN modules/chips for ESP boards.
So that should not be a problem

[Smotek7]

So the direction UDP to UART works without problems.
When I send UDP to
192.168.1.136:8266
display
serialsend,TestString\r\n

But I don't know how to direct uart to UDP
I found something in the rules
I tried
1.

Code: Select all

on !Serial# do
  SendToUDP,192.168.1.100,666,'%eventvalue%'
Endon

it doesn't work

2.

Code: Select all

on !Serial# do
  TaskValueSetAndRun,1,1,%eventvalue%
Endon

it doesn't work

I am not sure if the data to my ESP is coming to the uart.
I don't see it in the log.
Can it be checked somehow?

[TD-er]

Can you try sending it to the logs to see what you receive?

Code: Select all

on !Serial# do
  LogEntry,"SendToUDP,192.168.1.100,666,'%eventvalue%'"
Endon

N.B. notice the use of different quotes, single and double quotes, is intentional

And maybe also try sending something to your other node to see if this is expected:

Code: Select all

on !Serial# do
  LogEntry,"SendToUDP,192.168.1.100,666,'%eventvalue%'"
  SendToUDP,192.168.1.100,666,'Testing-1-2-3'
Endon

[Smotek7]

Hello @TD-er,
I came back to this problem today.
I tested the rule, but nothing gets into the log
I think

Code: Select all

LogEntry,"SendToUDP,192.168.1.100,666,'%eventvalue%'"

I assume that's the problem that it doesn't capture

Code: Select all

on !Serial# do

I'm testing on ESP32-C3 super mini now
I have SER2NET defined in the device
RX: GPIO-20 , TX: GPIO-21 , HW Serial0
I have a USB-serial converter on RX, so the data is definitely there.

Why doesn't !Serial# respond?

[Smotek7]

I tried many settings on Ser2Net device.
I noticed that when I put
Event processing: Generic
Process events without client: yes

Then in the log it starts to appear:
354991: EVENT: !Serial#NW
355003: EVENT: !Serial#�

But the event in Rules is not triggered

[TD-er]

And what if you trigger on

Code: Select all

on !Serial do

[Smotek7]

Yes, it worked
trigger is now ok
But it doesn't work
SendToUDP,192.168.1.100,666,'%eventvalue%'
Do I have the quotes right?
Data is HEX, 255 bytes are received
My settings are:
RX buffer size (bytes): 1024
in the log I see
!Serial#�

[TD-er]

And what if you try to log what is in the eventvalue?

Code: Select all

on !Serial do
  LogEntry,"Logging: SendToUDP,192.168.1.100,666,'%eventvalue%'"
endon

[Smotek7]

It ends with a special character

Code: Select all

LogEntry,'Logging: SendToUDP,192.168.1.100,666,'!Serial#�

The problem will be that it is HEX data

Otherwise sending with rules to uart works correctly for me

Code: Select all

SerialSendMix,'0x4E5700130000000000603000000000000068000000129'

[TD-er]

Which build are you using?

[Smotek7]

ESP_Easy_mega_20241222_collection_A_ESP32c3_4M316k_CDC Dec 22 2024

[TD-er]

I will have a look at the recent changes in code to see if there is a recent change which may fix this (or what may causing this)

Or you could pick a binary from the most recent test build of the 'mega' branch: https://github.com/letscontrolit/ESPEas ... 3752867011

[Smotek7]

I would choose it too
I just don't know how to download it.

[TD-er]

You need to have a GitHub account.
Or I can also update the 'latest' on the webflasher with this build....

Edit:
I am now downloading that specific build... Takes 5 minutes as GitHub downloads are extremely slow......

[Smotek7]

I was not logged in.

I used build:
ESP_Easy_mega_20250309_collection_A_ESP32c3_4M316k_CDC Mar 9 2025

The result is the same.

Code: Select all

SendToUDP,192.168.1.100,666,'!Serial#�

[TD-er]

Just uploaded that specific build here: https://td-er.nl/ESPEasy/latest/
If you don't see "20250309" in the selector, you may need to refresh the page.

[TD-er]

OK, you also seem to see that strange character in the event.
The other event I got from your logs shows "!Serial#NW"

Code: Select all

on !Serial#NW* do
  LogEntry,"Logging: SendToUDP,192.168.1.100,666,'%eventvalue1%'"
endon

Can you try this one?

The * is needed as the first eventvalue isn't a numerical, but a string.

[Smotek7]

Yes,
2 events will be created
I tried

Code: Select all

on !Serial#NW* to
LogEntry,"Logging: SendToUDP,192.168.1.100,666,'%eventvalue1%'"
endon

Result

Code: Select all

214599: Logging: SendToUDP,192.168.1.100,666,'%eventvalue1%'

I completely deleted the device and uploaded it again via the web.
Build:
ESP_Easy_mega_20250309_energy_ESP32c3_4M316k_LittleFS_CDC_ETH Mar 9 2025

[TD-er]

Ton just suggested (via chat) to use %eventvalue% instead of %eventvalue1%
Not sure yet why that would work but if it makes a difference, then it looks like a bug...

[Ath]

...
I noticed that when I put
Event processing: Generic
Process events without client: yes

This is according to the documentation, especially the 'Process events without client' checkbox. I added that to be able to test without having to use extra software for keeping a connection 'up'

Then in the log it starts to appear:
354991: EVENT: !Serial#NW
355003: EVENT: !Serial#�

That looks like 2 separate events, maybe you can add a small RX Receive Timeout value, something like 5 msec?

[Smotek7]

Code: Select all

on !Serial#NW* do
  LogEntry,"Logging: SendToUDP,192.168.1.100,666,'%eventvalue%'"
endon

result

Code: Select all

ACT : LogEntry,'Logging: SendToUDP,192.168.1.100,666,'!Serial#NW

and

Code: Select all

on !Serial#NW* do
  LogEntry,"Logging: SendToUDP,192.168.1.100,666,'%eventvalue1%'"
endon

result

Code: Select all

Logging: SendToUDP,192.168.1.100,666,'%eventvalue1%'

I tried adding 5ms, but it didn't help.
The result is the same.

Isn't it a problem that it can't process a HEX string?


Just to add that the device is JK-BMS.
I have a question with rules:

Code: Select all

SerialSendMix,'0x4E5700130000000006030000000000006800000129

I see the BMS response to the serial monitor (USB-uart) correctly

4E 57 00 FD 00 00 00 00 06 00 01 79 0C 01 00 00 02 00 00 03 00 00 04 00
00 80 00 1A 81 00 17 82 00 17 83 00 00 84 00 00 85 00 86 02 87 00 00 89
00 00 00 00 8A 00 04 8B 00 00 8C 00 08 8E 05 A0 8F 04 10 90 0E 10 91 0D
DE 92 00 03 93 0A 28 94 0A 5A 95 00 03 96 01 2C 97 00 C8 98 01 2C 99 00
19 9A 00 1E 9B 0B B8 9C 00 0A 9D 01 9E 00 64 9F 00 50 A0 00 46 A1 00 3C
A2 00 14 A3 00 46 A4 00 46 A5 FF EC A6 FF F6 A7 FF EC A8 FF F6 A9 04 AA
00 00 00 F0 AB 00 AC 00 AD 03 E8 AE 01 AF 00 B0 00 0A B1 14 B2 31 32 33
34 35 36 00 00 00 00 B3 00 B4 49 6E 70 75 74 20 55 73 B5 32 35 30 33 B6
00 00 01 55 B7 31 31 41 5F 5F 5F 5F 5F 53 31 31 2E 35 34 5F B8 00 B9 00
00 00 F0 BA 49 6E 70 75 74 20 55 73 65 72 64 61 34 30 37 30 35 32 43 31
34 35 30 00 C0 01 00 00 00 00 68 00 00 48 23

[Smotek7]

Just for my curiosity I tried sending RX serial to HWserial1 and that to Nextion plugin (it can send UDP).
But I ended up with buffer size.
NEXTION075 : RxD P075_data->easySerial Buffer capacity warning, 255 bytes

[Smotek7]

Last night I thought about it, why doesn't Ser2net send the received data to the configured controller?
I thought there was some reason for that, if it's serial data.
But Nextion is also serial and the received data is sent to the configured controller by default.

[Smotek7]

Guys,
do you think it can be solved in ESPeasy, or should I try another way?
For me, the ideal solution would be if the Ser2net add-on could send received data to the Controller that is selected there.
But if it is time-consuming, I will solve it with other HW.
Thanks

[Ath]

Guys,
do you think it can be solved in ESPeasy, or should I try another way?

That hex-dump output, is that the plain, unaltered output of the BMS, or does the terminal show the binary data from the BMS as hex?

For me, the ideal solution would be if the Ser2net add-on could send received data to the Controller that is selected there.
But if it is time-consuming, I will solve it with other HW.
Thanks

As long as normal ASCII is coming from the BMS it should be doable, but for binary data, maybe a specific plugin is needed.

Not sure we asked, but is the serial configuration set up correctly? (All parameters matter!)

[Smotek7]

That hex-dump output, is that the plain, unaltered output of the BMS, or does the terminal show the binary data from the BMS as hex?

It is HEX as sent by BMS.
I use REALTERM SW.
I can decode the data according to the datasheet.
https://jikongbms.com/wp-content/upload ... n-V6.x.pdf

It's not ASCII, it's binary.
It's something like Modbus, master/slave ,
but it's not Modbus rules.

Communication is nothing special
115200 8N1
If I send with the rules
SerialSendMix,'0x4E570013000000000060300000000000006800000129'
BMS will respond correctly.
Even if I send TCP->uart, the BMS will process the request.

[Ath]

Ah, looking at that manual, it's quite obvious that we're not going to get that working with Ser2Net (P020), as that doesn't support somewhat complex protocols like used here. It looks more like the Victron VE.Direct plugin, except it's not sending ASCII data.

I've reserved plugin ID P179 for that, and will try to do some investigation, but can't give any ETA, as my TODO list is growing...
NB: If you are interested in developing a plugin for ESPEasy, we have a Development starters guide here

[Smotek7]

@Ath
If it's development, don't waste time on it.
If you put it in TODO, then at the very end.
I'll check the victron.

Just for information I did a test
Rules:
on !Serial do
LogEntry,"Logging: SendToUDP,192.168.1.100,666,'%eventvalue%'"
SendToUDP,192.168.1.100,666,'%eventvalue%'
endon

From the terminal I send to uart:
1. "start" as ASCII
on UDP it gets correctly "start" as ASCII
Logging: SendToUDP,192.168.1.100,666,'!Serial#start'

2. "0x4E 0x57" as ASCII
on UDP it gets correctly "0x4E 0x57" as ASCII
Logging: SendToUDP,192.168.1.100,666,'!Serial#0x4E 0x57'

3. "0x4E 0x57" as HEX (binary)
nothing will be sent
Logging: SendToUDP,192.168.1.100,666,'!Serial#NW'

So the plugin does not process HEX.
But it has one positive result.
I originally created this thread so that I could send ASCII characters to UDP. And I already know that it works.
So I have a 50% success rate.

[Smotek7]

So I didn't write everything.
Now I realized that "NW" is in ASCII what I sent in HEX 0x4E 0x57 Point 3.

If I send in HEX 0x4E 0x57 0x01 0x2D 0x06 0x01 0x79 0x30
Then it processes it and the result is
!Serial#NW\x01-\x06\x01y0

What it doesn't process in HEX is if the string contains 0x00 ,
then the adder doesn't process it.
That's the reason why it seemed like nothing would go through,
because the long string contained 0x00

[Smotek7]

@Ath
It really works.
The data is getting to my PLC via UDP.
Even a long HEX string.
The problem is 0x00,
If the string contains 0x00 then nothing is sent.

[Ath]

@Ath
It really works.
The data is getting to my PLC via UDP.
Even a long HEX string.
The problem is 0x00,
If the string contains 0x00 then nothing is sent.

That is probably as expected, as ASCII byte 0x00 is often used as a terminator for a string.
I'll see if I can add support for that.

[Smotek7]

OK,
if it would be possible in the future I would be happy.
You don't have to prioritize it.
It could be at the end of TODO...
Thanks