Open BSD31 opened 2 years ago
Same result with an ESP01, ESP07, ESP12 AND ESP32 ... I also tried with the 'Dev' version of ESPHome. The logs are correct but no real signal on TX. Is the problem only with me ? Thank you for your help
So is there no one who can analyze my simple little piece of code ? No one to say if this is a big mistake on my part or a little bug from the last update ? Please guide me.
Hey there @esphome/core, mind taking a look at this issue as it has been labeled with an integration (uart
) you are listed as a code owner for? Thanks!
(message by CodeOwnersMention)
If it were a simple error, I'm sure somebody would have responded by now. Looking at the code I see no obvious mistake. The debug logs tell us that there is data being sent to the UART component, because it's the UART component that is logging the bytes on their way out.
What would help is if you would try with older versions, to find the last version for which things still worked. That would make it a lot easier to look at what might have caused the issue for you.
You say "But in reality there is nothing on the TX". How did you check that? Did you connect the TX to a serial logger to verify this?
Oh thank you for your analysis. I feel less alone. I have not connected a laboratory serial logger but the device which is connected to my UART port lights a connection icon if the acknowledgment is received and valid. This icon has two different states: 0x2F: 0x32: 0x0A -> The icon blink. 0x2F: 0x33: 0x0A -> The icon is On. I created two switches in my .YAML that write directly to the UART port. When I click manually the icon lights up in the two different states. On the other hand, automatic writing to the UART port via the .h file does not light up the icon in any case. Finally, my code was working before the last update. I do not really know what else to do...
I will try to find an oscilloscope to visualize the signal...
Eureka! I found the reason for my bug. With the oscilloscope, I noticed that when I write from the .h file :
.../...
write (0x2F);
write (0x33);
write (0x0A);
.../...
this is not equal to what I write from the .yaml
switch:
- platform: uart
name: "TEST (0x2F: 0x33: 0x0A)"
data: [0x2F, 0x33, 0x0A]
In the .h file the data is sent independently of each other (on different lines) while in the .yaml file the data is sent one after the other (on the same line ). It seems to me that this problem did not exist before the December update ! How now to write to the same line from the .h file because [0x2F, 0x33, 0x0A] does not work ? Thank you for your help.
using write_array ?
Exactly ! Using 'write_array' it works perfectly.
The problem
Hello. I am using a custom UART Device which no longer works since today (update 2021.12 this morning) Typically, I receive a message on RX (56: 62: 02: AC: 00: 00) and I acknowledge receipt via TX (2F: 33: 0A)
Here is my .h file
and my .yaml file
The logs do not give any error : [15:04:37][D][uart_debug:114]: <<< 56:62:02:AC:00:00 [15:04:37][D][uart_debug:114]: >>> 2F:33:0A [15:04:40][D][uart_debug:114]: <<< 56:62:02:AC:00:00 [15:04:40][D][uart_debug:114]: >>> 2F:33:0A [15:04:46][D][uart_debug:114]: <<< 56:62:02:AC:00:00 [15:04:46][D][uart_debug:114]: >>> 2F:33:0A [15:04:49][D][uart_debug:114]: <<< 56:62:02:AC:00:00 [15:04:49][D][uart_debug:114]: >>> 2F:33:0A ---/---
But in reality there is nothing on the TX
I added a switch in my .YAML to send my acknowledgment manually and it works ...
[15:11:07][D][switch:021]: '0x2F:0x33:0x0A' Toggling ON. [15:11:07][D][switch:037]: '0x2F:0x33:0x0A': Sending state ON [15:11:07][D][uart.switch:020]: '0x2F:0x33:0x0A': Sending data... [15:11:07][D][switch:037]: '0x2F:0x33:0x0A': Sending state OFF
What happened ? Am I doing something wrong?
Best regards
Which version of ESPHome has the issue?
v2021.12.0
What type of installation are you using?
Home Assistant Add-on
Which version of Home Assistant has the issue?
HA-OS core-2021.12.1 in Synology VMM
What platform are you using?
ESP8266
Board
nodemcuv2
Component causing the issue
CUSTOM UART
Example YAML snippet
No response
Anything in the logs that might be useful for us?
No response
Additional information
No response