SerialProxy - serial port settings

[ghtester]

I would like to use SerialProxy plugin on ESP8266 through GPIO1 and GPIO3 pins (HW serial) but the issue is that the lowest configurable baud rate is 2400 Bd. Also there're no options for remaining serial parameters. I need to set the port to 300/7/e/1. Is there a way to do it please?

The SerialServer plugin has the necessary settings but I have another issues with it so my plan was to use SerialProxy.

[tonhuisman]

If you are self-building, you could try to change line 134 of _P087_SerialProxy.ino for the minimum value allowed 300 instead of 2400.

[ghtester]

Thanks for the hint but I need to change some other parameters as well (7 bits, even parity)... :-(

[tonhuisman]

The SerialServer plugin has the necessary settings but I have another issues with it

Can you elaborate on that?

[ghtester]

Yeah, already working on that... It looks the latest custom build 20220616 has some troubles, it seems I am not able to send the data. Receiving works. Tested with another ESP node with custom build dated 20220428 and it works. Need to do more tests to confirm. Is there a way to send a control characters (CR, LF) through the SerialSend command please? I can't find it in the documentation, only encountered some PR regarding to send .hex data but AFAIK it's not finished?

[tonhuisman]

Hm, doesn't seem like that's possible right now. The PR you hint at is one way of solving that, but I'm not sure if the code is acceptable yet, there are still a few unresolved comments.

[ghtester]

OK, thanks for info, it's a pity... It really looks that serialsend in my latest custom build from 20220616 does not send any data (at least to GPIO1 when HWSerial0 is selected).

[tonhuisman]

You have disabled the regular serial port in Tools/Advanced, I assume?

[ghtester]

Yes, also tried with both settings of a new config parameter Process events without client: without any effect. Telnet client was connected during the test, output also was not send to GPIO1, input from GPIO3 was displayed OK.

[ghtester]

I have downgraded node to custom firmware compiled 20220508 and sending through SerialSend now works fine. As I had also an issue with HW sensor (to convert a serial data to IR), need to check again with the latest firmware. I am going to fresh compile because there're some merged updates. So the major issue for me looks to be a missing possibility to send a control characters through SerialSend command. What I need to do is to send the short command to Energy Meter (partially compatible with IEC 62056-21 protocol) through serial / IR adapter at 300Bd/7bits/Even parity/1stopbit , receive about max. 1000 bytes of text data and publish them (or just some filtered lines) to MQTT controller. I am able to do the things through telnet to ESP node running Serial Server but then I need another device to do that so I would rather use RPi instead of ESP.

[ghtester]

Just compiled a fresh ESP custom build, sending through Serial Server plugin works fine, also the modified minimal baudrate in Serial Proxy plugin as adviced by @tonhuisman works. But the missing bits/parity parameters is a problem. The defaults in Serial Proxy are 8 bits / none parity so unfortunately I can't use it. It would be great if the Serial Proxy plugin could contain the same config parameters as Serial Server, also a possibility to send a control characters (at least CR, LF) would help a much...

[tonhuisman]

Doesn't look too hard to add, I'll see if I can fix this for you.

[tonhuisman]

@ghtester Please test the new feature for configuring the technical serial parameters I added 😃

[ghtester]

Thanks a lot, I'll do. Then I'll have some other requests... ;-] The first one - it looks that minimum baudrate in the sources at line 134 is still 2400 Bd, could you please change it to 300? The second one - would it be also easily possible to allow sending CR LF somehow? Perhaps a checkbox which would add CR LF to every string sent through serialproxy_write... Or after a specific sequence of characters... Or with a specific command like serialproxy_writeCRLF etc...

[TD-er]

You can write CRLF. Use %CR%%LF% See the System Variables page

Also about the really low baud rates.... don't use them if using SW serial as it will cause all kinds of side effects since the interrupts are temporary disabled when receiving a byte and at low baud rates this takes "forever". Not sure if HW serial does support these, but I guess that could be made to work with some other tweaks too if the basic API doesn't allow for it.

[ghtester]

You can write CRLF. Use %CR%%LF%

_Thanks for the hint but unfortunately it does not look working in serialproxywrite command... I can only send the control characters with HTTP link like: http://ESPNodeIP/control?cmd=serialproxy_write,12345%0A678%0D90 But even in this case when the %0D%0A is at the end, it's ignored (??) - the other side does not receive the control characters. I need to put some other character at the end of the HTTP link (except space character, even with %20 form).

I am using HW serial and it works fine at 300 Bd, currently with serial server plugin.

Edit - OK, after some more testing I can say the %CR%%LF% can be send through serialproxy_write command as well from rules or through tools/Command form but not at the end of the string otherwise they seems to be ignored. So the same behaviour like from HTTP ( the difference is in HTTP variables needs to be %0d and %0a).

[tonhuisman]

minimum baudrate in the sources at line 134 is still 2400 Bd

Sorry, that one slipped my mind. I'll fix that later today

the %CR%%LF% can be send through serialproxy_write command... but not at the end of the string otherwise they seems to be ignored

Does it help if you wrap that string you want to send in quotes?

[TD-er]

Please try to send the command via the command field on the Tools page. Then the URL in the browser will be converted to HTML-escaped so it will preserve the %CR%LF% syntax which is later parsed in ESPEasy.

Anyway you can also wrap it in a rule and just trigger it by sending an event via the browser/HTTP-GET

[ghtester]

minimum baudrate in the sources at line 134 is still 2400 Bd

Sorry, that one slipped my mind. I'll fix that later today

No problem at all, thanks a lot for your effort!

Does it help if you wrap that string you want to send in quotes?

Unfortunately not, tested with putting string inside "" and ''.

[ghtester]

Please try to send the command via the command field on the Tools page.

That's what I did, the same with rules. If %CR% %LF% are at the end, it looks they are not sent. The same with %0d and %0a at the end of HTML link.

[tonhuisman]

If %CR% %LF% are at the end, it looks they are not sent.

I think that this line (while it looks rather harmless and useful 😉) is the cause for that...

[ghtester]

I suppose it won't be easy to fix as StringConverter is probably used widely and it could affect many other plugins?

[tonhuisman]

Introducing an extra optional argument like bool trimResult = true should be able to fix that, passing in false for the few cases where any prefixed and post-fixed white-space should be preserved.

I think that this line (while

The most used instance is actually this one, (those function names are quite similar 😊), they will both need the same fix.

[tonhuisman]

Both issues (baudrate and trimming) should now be fixed.

NB: The log functions seem to trim off any extra white-space by itself to avoid having empty lines in the logging (tested by adding a non-white-space character before writing the text to the log)

[ghtester]

Thanks a lot for your help, I'll recompile, upgrade the firmware, test and provide you with a feedback.

[ghtester]

Thanks for your great work again, I can confirm now everything looks working fine. The baudrate parameters can be now configured properly and control characters %CR% and %LF% are sent even at the end of the string as soon as the string is inside of "" or ''

I have only encountered nothing is send at all when the odd number of " or ' characters are in the string. I think the same behavior was before your PR as well but I don't think it is an issue. Therefore I believe this thread can be closed, thanks a lot again! :-)

[tonhuisman]

Thank you for testing.

There is no need to close the issue, as it would have been closed automatically once the linked PR is merged, but you can leave it as is. Now it is a little harded for other users with similar issues to find it, as it seems to be solved, but the PR isn't merged yet... but it also has to be released to be generally available 😃

[ghtester]

OK, thanks for the note, I'll keep it in my mind for next... :-) If it's better, the issue is now reopen just for that technical reason. ;-)