Let's Control It

Hello all,

I would like to control my Devialet amplifier through my Openhab (OH) home automation system.

Thanks to some kind assistance I received from this community, I have already managed to implement OH control of my Mitsubishi heat pump, using a D1 mini that receives MQTT instructions from OH and sends them to the heat pump, thanks to a plugin that was contributed by @crnjan.

I was wondering if there is a ready made plugin that I could use in order to:

1) establish a serial connection with my amplifier (see https://www.devialet.com/docs/D-Premier-RS232.pdf).

2) receive MQTT strings that represent commands to be sent to the Devialet and send them through the serial connection; and)

3) in the case of commands that happen to constitute queries, receive the response from the amp and wrap it as an mqtt message for the OH controller.

The Serial Server plugin appears to be designed for telnet-like TCP communication. But perhaps I can use it anyway with a MQTT controller? Or perhaps you know of another better suited plugin?

Thanks in advance,

Pierre

Clues, anyone?

The closest which comes to mind is the serial proxy plugin, but that one mainly receives strings and publishes them to MQTT.
There is a command to send data to the serial port, but that's also not binary.

These commands can be given via MQTT though, or by triggering an event, you can send fixed strings via the rules.

But if the device is not sending a string (terminated by a newline) then it does not work.

Thanks a lot for your response (I was starting to despair)!

I am fairly new to Espeasy. What distribution should I use in order to gain access to the serial proxy plugin?

Many thanks again.

See the list of plugins: https://espeasy.readthedocs.io/en/lates ... al-plugins
It is plugin 87, so it is in "TESTING C"

Thanks a lot: now I am starting to understand how to find particular plugins.

When I attempted to flash the relevant binary into a new D1 mini using "ESP Easy Flasher, I stumbled onto another problem. I don't know if you can help with that. I am running the esp tools under Windows 10.

In ESP Easy Flasher, the COM port slot is having me select between two different possible COM ports:
- (COM3) FTDI USB Serial Port (Port_#0008.Hub_#0003); and
- (COM5) USB-Serial CH340 (Port_#0012.Hub_#0003)

Only the second one corresponds to an actual device listed by the Windows device manager. Unsurprisingly, if I try to start the flashing process on COM3, I immediately get the error: "Failed to open COM3".

Following what I understand to be the simplest procedure, I leave the "Post flash action" box unchecked and I start the flashing process on COM5. From what I can see in ESP Easy Flasher, the process appears to be working normally. After ESP Easy Flasher is finished, I disconnect and then reconnect my ESP32. At that point I am supposed to get an "ESP_Easy_0" WIFI SSID to which I would connect in order to complete the setup. However no such SSID appears.

Looking at the log, I find that around the end of the flashing process, an error occured:
"The COM port was already in use... the post-flash did not complete."

I don't understand what the problem is and what can be done to fix it.

I am including the complete log below in case it is useful.

<code>
####2022-02-28######
#######0.04.007#######
######FLASH INFO######
BIN file: ESP_Easy_mega_20211224_test_C_ESP32_4M316k.bin
COM port: (COM5) USB-SERIAL CH340 (Port_#0012.Hub_#0003)
Baud rate: 115200
######POST FLASH######
No post flash information entered...
######FLASH LOG######
[esptool.exe -vv -cd nodemcu -cb 115200 -cp COM5 -ca 0x00000 -cf "C:\Users\Pierre\Documents\ESPeasy2\bin\ESP_Easy_mega_20211224_test_C_ESP32_4M316k.bin"]
[2022-02-28 15:28:38] esptool v0.4.12 - (c) 2014 Ch. Klippel <ck@atelier-klippel.de>
[2022-02-28 15:28:38] setting board to nodemcu
[2022-02-28 15:28:38] setting baudrate from 115200 to 115200
[2022-02-28 15:28:38] setting port from to COM5
[2022-02-28 15:28:38] setting address from 0x00000000 to 0x00000000
[2022-02-28 15:28:38] espcomm_upload_file
[2022-02-28 15:28:38] espcomm_upload_mem
[2022-02-28 15:28:38] setting serial port timeouts to 1000 ms
[2022-02-28 15:28:38] opening bootloader
[2022-02-28 15:28:38] resetting board
[2022-02-28 15:28:38] trying to connect
[2022-02-28 15:28:38] flush start
[2022-02-28 15:28:38] setting serial port timeouts to 1 ms
[2022-02-28 15:28:38] setting serial port timeouts to 1000 ms
[2022-02-28 15:28:38] flush complete
[2022-02-28 15:28:38] espcomm_send_command: sending command header
[2022-02-28 15:28:38] espcomm_send_command: sending command payload
[2022-02-28 15:28:38] read 0, requested 1
[2022-02-28 15:28:38] trying to connect
[2022-02-28 15:28:38] flush start
[2022-02-28 15:28:38] setting serial port timeouts to 1 ms
[2022-02-28 15:28:38] setting serial port timeouts to 1000 ms
[2022-02-28 15:28:38] flush complete
[2022-02-28 15:28:38] espcomm_send_command: sending command header
[2022-02-28 15:28:38] espcomm_send_command: sending command payload
[2022-02-28 15:28:38] espcomm_send_command: receiving 2 bytes of data
[2022-02-28 15:28:38] espcomm_send_command: receiving 2 bytes of data
[2022-02-28 15:28:38] espcomm_send_command: receiving 2 bytes of data
[2022-02-28 15:28:38] espcomm_send_command: receiving 2 bytes of data
[2022-02-28 15:28:38] espcomm_send_command: receiving 2 bytes of data
[2022-02-28 15:28:38] espcomm_send_command: receiving 2 bytes of data
[2022-02-28 15:28:38] espcomm_send_command: receiving 2 bytes of data
[2022-02-28 15:28:38] espcomm_send_command: receiving 2 bytes of data
[2022-02-28 15:28:38] Uploading 1728192 bytes from C:\Users\Pierre\Documents\ESPeasy2\bin\ESP_Easy_mega_20211224_test_C_ESP32_4M316k.bin to flash at 0x00000000
[2022-02-28 15:28:38] erasing flash
[2022-02-28 15:28:38] size: 1a5ec0 address: 000000
[2022-02-28 15:28:38] first_sector_index: 0
[2022-02-28 15:28:38] total_sector_count: 422
[2022-02-28 15:28:38] head_sector_count: 16
[2022-02-28 15:28:38] adjusted_sector_count: 406
[2022-02-28 15:28:38] erase_size: 196000
[2022-02-28 15:28:38] espcomm_send_command: sending command header
[2022-02-28 15:28:38] espcomm_send_command: sending command payload
[2022-02-28 15:28:38] setting serial port timeouts to 16368 ms
[2022-02-28 15:28:38] setting serial port timeouts to 1000 ms
[2022-02-28 15:28:38] espcomm_send_command: receiving 2 bytes of data
[2022-02-28 15:28:38] writing flash
[2022-02-28 15:28:46] ................................................................................ [ 4% ]
[2022-02-28 15:28:54] ................................................................................ [ 9% ]
[2022-02-28 15:29:03] ................................................................................ [ 14% ]
[2022-02-28 15:29:11] ................................................................................ [ 18% ]
[2022-02-28 15:29:19] ................................................................................ [ 23% ]
[2022-02-28 15:29:28] ................................................................................ [ 28% ]
[2022-02-28 15:29:36] ................................................................................ [ 33% ]
[2022-02-28 15:29:45] ................................................................................ [ 37% ]
[2022-02-28 15:29:53] ................................................................................ [ 42% ]
[2022-02-28 15:30:01] ................................................................................ [ 47% ]
[2022-02-28 15:30:10] ................................................................................ [ 52% ]
[2022-02-28 15:30:18] ................................................................................ [ 56% ]
[2022-02-28 15:30:27] ................................................................................ [ 61% ]
[2022-02-28 15:30:35] ................................................................................ [ 66% ]
[2022-02-28 15:30:44] ................................................................................ [ 71% ]
[2022-02-28 15:30:53] ................................................................................ [ 75% ]
[2022-02-28 15:31:01] ................................................................................ [ 80% ]
[2022-02-28 15:31:10] ................................................................................ [ 85% ]
[2022-02-28 15:31:19] ................................................................................ [ 90% ]
[2022-02-28 15:31:27] ................................................................................ [ 94% ]
[2022-02-28 15:31:36] ................................................................................ [ 99% ]
[2022-02-28 15:31:37] ........ [ 100% ]
[2022-02-28 15:31:37] starting app without reboot
[2022-02-28 15:31:37] espcomm_send_command: sending command header
[2022-02-28 15:31:37] espcomm_send_command: sending command payload
[2022-02-28 15:31:37] espcomm_send_command: receiving 2 bytes of data
[2022-02-28 15:31:37] closing bootloader
[2022-02-28 15:31:37] flush start
[2022-02-28 15:31:37] setting serial port timeouts to 1 ms
[2022-02-28 15:31:37] setting serial port timeouts to 1000 ms
[2022-02-28 15:31:37] flush complete
[2022-02-28 15:31:37] DONE!
############################
[2022-02-28 15:31:37] The COM port was already in use... the post-flash did not complete.
[2022-02-28 15:31:37] JOB COMPLETED, over and out!
</code>

Apparently you have another device connected to your system which also shows up as a serial port.
One easy way to check is to see which one is left in the device manager if you unplug the ESP device.

You can also try the web based flasher (a slightly older build, still have to update the bin files there) https://td-er.nl/ESPEasy/

You can also run a test version of the flasher, which allows to open a command prompt: https://td-er.nl/ESPEasy/index_4.html
This way you can enter the WiFi credentials manually Of course with changing the parameters to match your network.
N.B. you cannot correct any mistake while typing, so better copy/paste it from some notepad.

The initial flash via serial of an ESP32 must be done with an ESP_Easy...factory.bin, that includes the bootloader and flash-partitioning of the device. After that the unit can be updated from the Tools page with Update Firmware, using the 'normal' .bin file.

NB: A Wemos D1 mini usually means that it has an ESP8266, but there seem to be devices with that name that have an ESP32, confusing...

@TD-er

Apparently you have another device connected to your system which also shows up as a serial port.
One easy way to check is to see which one is left in the device manager if you unplug the ESP device.

Only one COM port is listed in Device Manager, the one associated with my D1 mini. When I disconnect the D1 Mini, no COM port remains in the list of devices.

Actually, even with my D1 Mini disconnected, ESP Easy Flasher continues to display the same two COM ports as option. This remains true even when the "Only active ports" option is checked. Thus, it seems that ESP Easy Flasher does not have a correct assessment of the port status.

You can also try the web based flasher (a slightly older build, still have to update the bin files there) https://td-er.nl/ESPEasy/

I did that. While ni log is available there, I believe the result is the same, since no "ESP_Easy_0" WIFI SSID is made available there either.

You can also run a test version of the flasher, which allows to open a command prompt: https://td-er.nl/ESPEasy/index_4.html
This way you can enter the WiFi credentials manually

It looks as if this URL is taking me to the very same place as the previous one. Thus I cannot see any command prompt.

@Ath

The initial flash via serial of an ESP32 must be done with an ESP_Easy...factory.bin, that includes the bootloader and flash-partitioning of the device. After that the unit can be updated from the Tools page with Update Firmware, using the 'normal' .bin file.

Understood. Unfortunately, this does not change the results I am getting.

NB: A Wemos D1 mini usually means that it has an ESP8266, but there seem to be devices with that name that have an ESP32, confusing...

Good point! My D1 is probably an ES8266, since I succeeeded some time ago to correctly flash an identical one using tye following binarry:

ESP_Easy_mega_20200913_test_ESP8266_4M1M_VCC.bin

Thus I also tried to flash my new D1 with the following one:

ESP_Easy_mega_20211224_test_C_ESP8266_4M1M.bin

Unfortunately, the result was again the same. The log ended with
"The COM port was already in use... the post-flash did not complete."

Update:

I tried flashing another brand new D1 mini on a different computer (Windows 11) and I got exactly the same result: COM port error at post-flash time, and no WIFI SSID showing up after flashing-disconnecting-reconnecting.

So, it looks like the problem has to do with my Windows environment and the use of CH340 drivers.

Here is a screenshot of my ESP Easy Flasher setup:


Any help would be most welcome. I am attaching the log below.



```
######2022-03-01######
#######0.04.007#######
######FLASH INFO######
BIN file: ESP_Easy_mega_20211224_test_C_ESP8266_4M1M_VCC.bin
COM port: (COM3) USB-SERIAL CH340 (Port_#0002.Hub_#0003)
Baud rate: 115200
######POST FLASH######
No post flash information entered...
######FLASH LOG######
[esptool.exe -vv -cd nodemcu -cb 115200 -cp COM3 -ca 0x00000 -cf "C:\Users\Pisabell\Documents\ESPeasy\bin\ESP_Easy_mega_20211224_test_C_ESP8266_4M1M_VCC.bin"]
[2022-03-01 17:39:47] esptool v0.4.12 - (c) 2014 Ch. Klippel <ck@atelier-klippel.de>
[2022-03-01 17:39:47] setting board to nodemcu
[2022-03-01 17:39:47] setting baudrate from 115200 to 115200
[2022-03-01 17:39:47] setting port from to COM3
[2022-03-01 17:39:47] setting address from 0x00000000 to 0x00000000
[2022-03-01 17:39:47] espcomm_upload_file
[2022-03-01 17:39:47] espcomm_upload_mem
[2022-03-01 17:39:47] setting serial port timeouts to 1000 ms
[2022-03-01 17:39:47] opening bootloader
[2022-03-01 17:39:47] resetting board
[2022-03-01 17:39:47] trying to connect
[2022-03-01 17:39:47] flush start
[2022-03-01 17:39:47] setting serial port timeouts to 1 ms
[2022-03-01 17:39:47] setting serial port timeouts to 1000 ms
[2022-03-01 17:39:47] flush complete
[2022-03-01 17:39:47] espcomm_send_command: sending command header
[2022-03-01 17:39:47] espcomm_send_command: sending command payload
[2022-03-01 17:39:47] read 0, requested 1
[2022-03-01 17:39:47] trying to connect
[2022-03-01 17:39:47] flush start
[2022-03-01 17:39:47] setting serial port timeouts to 1 ms
[2022-03-01 17:39:47] setting serial port timeouts to 1000 ms
[2022-03-01 17:39:47] flush complete
[2022-03-01 17:39:47] espcomm_send_command: sending command header
[2022-03-01 17:39:47] espcomm_send_command: sending command payload
[2022-03-01 17:39:47] espcomm_send_command: receiving 2 bytes of data
[2022-03-01 17:39:47] espcomm_send_command: receiving 2 bytes of data
[2022-03-01 17:39:47] espcomm_send_command: receiving 2 bytes of data
[2022-03-01 17:39:47] espcomm_send_command: receiving 2 bytes of data
[2022-03-01 17:39:47] espcomm_send_command: receiving 2 bytes of data
[2022-03-01 17:39:47] espcomm_send_command: receiving 2 bytes of data
[2022-03-01 17:39:47] espcomm_send_command: receiving 2 bytes of data
[2022-03-01 17:39:47] espcomm_send_command: receiving 2 bytes of data
[2022-03-01 17:39:47] Uploading 1007008 bytes from C:\Users\Pisabell\Documents\ESPeasy\bin\ESP_Easy_mega_20211224_test_C_ESP8266_4M1M_VCC.bin to flash at 0x00000000
[2022-03-01 17:39:47] erasing flash
[2022-03-01 17:39:47] size: 0f5da0 address: 000000
[2022-03-01 17:39:47] first_sector_index: 0
[2022-03-01 17:39:47] total_sector_count: 246
[2022-03-01 17:39:47] head_sector_count: 16
[2022-03-01 17:39:47] adjusted_sector_count: 230
[2022-03-01 17:39:47] erase_size: 0e6000
[2022-03-01 17:39:47] espcomm_send_command: sending command header
[2022-03-01 17:39:47] espcomm_send_command: sending command payload
[2022-03-01 17:39:47] setting serial port timeouts to 15000 ms
[2022-03-01 17:39:47] setting serial port timeouts to 1000 ms
[2022-03-01 17:39:47] espcomm_send_command: receiving 2 bytes of data
[2022-03-01 17:39:47] writing flash
[2022-03-01 17:39:55] ................................................................................ [ 8% ]
[2022-03-01 17:40:04] ................................................................................ [ 16% ]
[2022-03-01 17:40:12] ................................................................................ [ 24% ]
[2022-03-01 17:40:20] ................................................................................ [ 32% ]
[2022-03-01 17:40:29] ................................................................................ [ 40% ]
[2022-03-01 17:40:37] ................................................................................ [ 48% ]
[2022-03-01 17:40:46] ................................................................................ [ 56% ]
[2022-03-01 17:40:54] ................................................................................ [ 65% ]
[2022-03-01 17:41:02] ................................................................................ [ 73% ]
[2022-03-01 17:41:11] ................................................................................ [ 81% ]
[2022-03-01 17:41:19] ................................................................................ [ 89% ]
[2022-03-01 17:41:28] ................................................................................ [ 97% ]
[2022-03-01 17:41:30] ........................ [ 100% ]
[2022-03-01 17:41:30] starting app without reboot
[2022-03-01 17:41:30] espcomm_send_command: sending command header
[2022-03-01 17:41:30] espcomm_send_command: sending command payload
[2022-03-01 17:41:30] espcomm_send_command: receiving 2 bytes of data
[2022-03-01 17:41:30] closing bootloader
[2022-03-01 17:41:30] flush start
[2022-03-01 17:41:30] setting serial port timeouts to 1 ms
[2022-03-01 17:41:30] setting serial port timeouts to 1000 ms
[2022-03-01 17:41:30] flush complete
[2022-03-01 17:41:30] DONE!
############################
[2022-03-01 17:41:30] The COM port was already in use... the post-flash did not complete.
[2022-03-01 17:41:30] JOB COMPLETED, over and out!
```

Another (more interesting) update:

Good progress: I finally managed to flash my D1 mini. The trick was simply to check both the Post flash action checkbox (enter wifi info there) and the Pause after flash checkbox. Perhaps the problem was that if you let the system do the automatic post-flash, the delay between closing and reopening the COM port is too short?

OK, now I have managed to install plugin 87 (serial proxy). Unfortunately there is no doc available at this time for the plugin. I wonder if I could help a little bit of help to get it working for my needs?

I have set up an MQTT controller in the plugin that will allow me to communicate with my Openhab home automation system. I can see that the plugin is already connected to my MQTT broker.

Before I try connecting my Devialet amp at the other end, I would like to start with a simple test that will confirm that strings are successfully received on the serial port and then sent to my MQTT broker. I was hoping I could use the Arduino serial monitor to input strings through the D1 mini serial port and thereafter see them received by my MQTT broker, but that does not seem to work. Any suggestions?

I don't know much about this plugin, but I hope you have enabled it, after configuring the settings, as then you will see much more options to have optional filtering, based on regular expressions.
Also, you can send the (numeric) data out to your MQTT controller, by checking the matching box.
You can send commands out the serial port you configure, by using the command: "serialproxy_write,<text-to-send>". If the text-to-send has spaces, then use quotes around that text.
Any result read from the serial port is then filtered, and sent to the connected controller.
When watching the log, you will most likely see more info during receive of the serial data.

I'm afraid there is no direct documentation available, I've even looked at the commit history of the involved files, but I didn't find any. Hopefully, the author can find some time to write that down, to make this more useful for the 'less informed'.
Searching this forum may also return some useful posts.

Thanks for your feedback.

I am not sure what you mean by numeric data. I need to communicate with the amp using strings such as "[DEVIALET>POWER=0]". The amp is then supposed to respond with the same kind of strings.

My plugin is enabled and I have defined an MQTT controller. Through that controller, I am sending strings like "serialproxy_write,[DEVIALET>POWER=0]".

With my D1 mini serial port set to "HW Serial0" (but nothing yet connected to the corresponding pins), I get the following log:

```
2191850: WD : Uptime 37 ConnectFailures 0 FreeMem 19096 WiFiStatus 3 ESPeasy internal wifi status: Conn. IP Init
2205140: Proxy: Sending: [DEVIALET>POWER=0]
2205141: [DEVIALET>POWER=0]
```
I assume that this is the desirable result, right?

On the other hand, if the port is set to "SoftwareSerial", I get the following error message, which is also fed back to the MQTT controller:

```
3001850: WD : Uptime 50 ConnectFailures 0 FreeMem 19736 WiFiStatus 3 ESPeasy internal wifi status: Conn. IP Init
3009255: Command unknown: serialproxy_write,[DEVIALET>POWER=0]
```
I suppose this is normal too.

Do you think I am now good to move forward, implementing all my amplifier commands in the same way and then trying to connect my hardware?

Many thanks again.

pisabe;; wrote: ↑03 Mar 2022, 18:18 I am not sure what you mean by numeric data. I need to communicate with the amp using strings such as "[DEVIALET>POWER=0]". The amp is then supposed to respond with the same kind of strings.

My plugin is enabled and I have defined an MQTT controller. Through that controller, I am sending strings like "serialproxy_write,[DEVIALET>POWER=0]".

When sending sensor data directly from the task, by enabling the checkbox for the desired Controller, only numeric data can be sent, ESPEasy doesn't handle string-type data very well.

pisabe;; wrote: ↑03 Mar 2022, 18:18 With my D1 mini serial port set to "HW Serial0" (but nothing yet connected to the corresponding pins), I get the following log:

```
2191850: WD : Uptime 37 ConnectFailures 0 FreeMem 19096 WiFiStatus 3 ESPeasy internal wifi status: Conn. IP Init
2205140: Proxy: Sending: [DEVIALET>POWER=0]
2205141: [DEVIALET>POWER=0]
```
I assume that this is the desirable result, right?

I expect your device receiving the command, echos it back to the sender, but I'd expect some response from the serial proxy, telling that it's handling the received output. Does that show in the logs too?

pisabe;; wrote: ↑03 Mar 2022, 18:18 On the other hand, if the port is set to "SoftwareSerial", I get the following error message, which is also fed back to the MQTT controller:

```
3001850: WD : Uptime 50 ConnectFailures 0 FreeMem 19736 WiFiStatus 3 ESPeasy internal wifi status: Conn. IP Init
3009255: Command unknown: serialproxy_write,[DEVIALET>POWER=0]
```
I suppose this is normal too.

That usually means that software serial isn't configured correctly, as the command is only accepted, and responds OK, by the plugin if all is well there. So this doesn't look as expected.

pisabe;; wrote: ↑03 Mar 2022, 18:18 Do you think I am now good to move forward, implementing all my amplifier commands in the same way and then trying to connect my hardware?

Well, I'd first want the response from the device to be seen by the plugin, so you now that you can return the answers to the MQTT server via rules. Rules need to be enabled (Tools/Advanced) for most plugins to generate these events. Not sure if you already activated that setting?
Once 1 command is working as you want, I'd continue to implement the rest.

Once again, many thanks for your comments.

As I mentioned before, I have not connected my hardware (Devialet amplifier) yet.

However, I have now managed to simulate communication events in both directions. For that purpose, I am using the Arduino serial monitor (D1 mini connected to Windows 10 through a USB port). I found that even when the D1 mini is set to HW Serial0, the Arduino monitor does receive and display the strings that are sent by Openhab through MQTT communication (e.g. "[DEVIALET>POWER=0]"). Moreover, strings sent from the Arduino monitor (i.e. manually entered in the monitor "send" window) are also received by the D1 mini and transmitted to my MQTT broker (even though my Openhab is not configured to use them yet).

Given that situation, I am now tempted to try connecting the respective serial ports of my amplifier and the D1. You can see how the amplifier port is arranged in this document:
https://www.devialet.com/docs/D-Premier-RS232.pdf
Basically: a 3.5 mm mini-jack that carries RX, TX and GND.

I have no experience doing that sort of thing. But according to what I have read, the amplifier output is not necessarily TTL-level, so that some kind of adapter may be needed. Any advice on that would be most welcome.

You are on the right track, from what I'm reading, great!

It looks like the amplifier accepts voltages up to 12V on the serial port but there is no info on the out-going level, so I'd use a level converter that can handle 12V, and use 3.3V on the ESP side, as that's the preferred signal level. ESP's like a NodeMCU usually will accept up to 5V signals, but it's better to be safe than sorry.

Unfortunately, I have had no luck yet. I tried connecting the D1 mini to the serial port of the Devialet amp, and nothing happened. There was no evidence that the amp was receiving anything whatsoever.

Then, I thought I should try conecting my D1 mini to a device that I have more control on. The obvious candidate was using another D1 mini running the same serial proxy plugin. Thus, I now have two D1 minis that feature the exact same configuration of the serial proxy plugin (including of course, the same communication speed). Their serial channels are crossed: RX-->TX and TX-->RX. I was hoping that whatever is written using serialproxy_write on one of the D1's would show up on the log of the other D1, but no, nothing get echoed on the log of the alternate D1.

My first D1 remains setup to accept strings received from my desktop Openhab through MQTT. The strings it receives in that way are shown on its log:

```
1171237: Command: serialproxy_write
1171239: Proxy: Sending: [Devialet>POWER=0]
1171239: [Devialet>POWER=0]
```
But the second D1, at the other end of the serial link does not appear to be receiving that same string. At least, nothing is shown on its log.

The situation is the same if I enter the "serialproxy_write,string" directly from the web interface of either D1 mini: nothing get echoed on the log of the other D1 mini.

I don't understand where the problem is. Could it be that something needs to be entered if the "filter" part (RegEx, etc) of the serial proxy task page? Thus far, I haven't touched that part at all: I have assumed that the default values meant the string should be passed as received.

Also, it is not clear to me how the "Enable serial port" option in "Advanced setting" is related with the serial proxy plugin. But I tried that option both ways, and it didn't seem to make any difference.

"Enable serial port" on the Tools->Advanced page does enable a few things:
- Accepting commands from serial port (serial0) thus also taking all received bytes from the input buffer on hardware Serial0 port.
- Sending log to hardware Serial0 port, depending on the serial log level
- Setting the baud rate to what is set on the same page.

Thus if you try to use any task with hardware Serial0 port, then you should uncheck the "Enable Serial Port" or else you may end up with unexpected behavior.

Thanks for this explanation. So, I will make sure to uncheck that option on the Advanced page whenever I run the Serial proxy plugin.

However, since my Serial proxy setup fails to work even when that option is unchecked, I must be doing something wrong elsewhere. Any suggestions as to where I should be looking? Am I right in assuming that I can ignore all the filtering options if I just want to read and write the exact strings that are used in my application?

It has been a while since I used that plugin, so I have to look at it to be sure.
Sending data should work regardless the config (except for serial config obviously).
Try to look at the signals too, to see if you see the right levels for that appliance.
Some older devices may need a higher voltage for serial communication.
Really ancient ones even needed voltages > 5V.

I understand that the voltages on my application (Devialet amplifier) will need to checked.

However, at this point in time, I am just trying to get the serial communication working between two D1 mini's. Both are running the serial proxy plugin. They are interconnected with crossed lines (TX-->RX and RX-->TX). Thus, voltages should not be an issue in this case.

Am I correct to assume that a command "serialproxy_write,5684" given on one of the two D1 minis should have an echo on the web log (debug turned on) of the other one? And also that the task value of the receiving D1 Mini should thereafter become "5684"?

At this point in time, there is no trace in the web logs of either D1 mini of any input received on their serial lines. However, both D1 mini's display input received from their MQTT controllers.

Update:

I verified that the wired HW Serial0 connection between my two D1 Mini's is OK. I did that in the following way:

1) temporaily disable the Serial Proxy plugin in one of the D1 Mini's;

2) check the "Enable serial port" box in Advanced Settings of the same D1 Mini; and

3) enter the command "Settings" in the Web command window of the same D1 mini;

4) Result: the settings of the first D1 Mini do get displayed in the web log of the second D1 mini. Thus, HW0 serial communication is working in that case;

5) As mentioned above, the Serial proxy task was disabled. Regardless of that fact, the data received by the second D1 mini from the first one turned out to be assigned as a value for the that disabled task; from there, that value (Settings of first D1 Mini) was sent to the MQTT controller of the second D1 mini.

I don't really mind the fact that serial proxy task does not appear to be fully disabled even though the "Enable" option is left unchecked. The only real problem for me is to find why "serialproxy_write" does not work in my setup.

OK, I think the problem was not really in the serial proxy plugin. More likely, it was a harware issue in my setup. Consequently, I am closing this thread. And starting a different one about my hardware issue...
Sorry if I wasted your time