search

arendst / Tasmota

Alternative firmware for ESP8266 and ESP32 based devices with easy configuration using webUI, OTA updates, automation using timers or rules, expandability and entirely local control over MQTT, HTTP, Serial or KNX. Full documentation at
https://tasmota.github.io/docs
GNU General Public License v3.0
22.23k stars 4.81k forks source link

IR version - Multiple "CMD: Serial buffer overrun" errors and device nonfunctional after "SetOption19 1" #8829

Closed pricewatermouse closed 4 years ago

pricewatermouse commented 4 years ago

PROBLEM DESCRIPTION

A clear and concise description of what the problem is.

I am trying to setup the IR-bridge to work with Home Assistant via MQTT.

I use prebuilt IR version (tasmota-ir.bin) and it works ok (successfully recognizes commands from IR-remote and sends from console) until I am trying to enable HA discovery "SetOption19 1". Then the device become nonfunctional the module type is set to Sonoff Basic (1) and the console shows multiple "CMD: Serial buffer overrun" errors.

The generic version (tasmota.bin) is not affected by this issue and is discovered by HA but doesn't recognize IR commands from my remotes.

REQUESTED INFORMATION

Make sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!

CMD: Backlog Template; Module; GPIO 255 MQT: stat/tasmota/RESULT = {"NAME":"IRBridge","GPIO":[0,0,0,0,56,51,0,0,0,17,8,0,0],"FLAG":0,"BASE":62} MQT: stat/tasmota/RESULT = {"Module":{"62":"YTF IR Bridge"}} MQT: stat/tasmota/RESULT = {"GPIO0":{"0":"None"},"GPIO1":{"0":"None"},"GPIO2":{"0":"None"},"GPIO3":{"0":"None"},"GPIO4":{"56":"Led1i"},"GPIO5":{"51":"IRrecv"},"GPIO9":{"0":"None"},"GPIO10":{"0":"None"},"GPIO12":{"0":"None"},"GPIO13":{"17":"Button1"},"GPIO14":{"8":"IRsend"},"GPIO15":{"0":"None"},"GPIO16":{"0":"None"}}

- [x] If using rules, provide the output of this command: `Backlog Rule1; Rule2; Rule3`:

Rules output here:

- [x] Provide the output of this command: `Status 0`:

STATUS 0 output here:

12:03:56 CMD: Group 0, Index 1, Command "STATUS", Data "0" 12:03:56 MQT: stat/tasmota/STATUS = {"Status":{"Module":62,"DeviceName":"Tasmota","FriendlyName":["Tasmota"],"Topic":"tasmota","ButtonTopic":"0","Power":0,"PowerOnState":3,"LedState":1,"LedMask":"FFFF","SaveData":1,"SaveState":1,"SwitchTopic":"0","SwitchMode":[0,0,0,0,0,0,0,0],"ButtonRetain":0,"SwitchRetain":0,"SensorRetain":0,"PowerRetain":0}} 12:03:56 MQT: stat/tasmota/STATUS1 = {"StatusPRM":{"Baudrate":115200,"SerialConfig":"8N1","GroupTopic":"tasmotas","OtaUrl":"https://thehackbox.org/tasmota/tasmota-ir.bin","RestartReason":"Software/System restart","Uptime":"0T20:07:07","StartupUTC":"2020-06-30T14:56:49","Sleep":50,"CfgHolder":4617,"BootCount":37,"BCResetTime":"2020-06-30T15:29:40","SaveCount":134,"SaveAddress":"F8000"}} 12:03:56 MQT: stat/tasmota/STATUS2 = {"StatusFWR":{"Version":"8.3.1.6(074bef9-ir)","BuildDateTime":"2020-06-29T18:03:10","Boot":31,"Core":"2_71","SDK":"2.2.2-dev(38a443e)","CpuFrequency":80,"Hardware":"ESP8266EX","CR":"378/699"}} 12:03:56 MQT: stat/tasmota/STATUS3 = {"StatusLOG":{"SerialLog":0,"WebLog":4,"MqttLog":0,"SysLog":0,"LogHost":"","LogPort":514,"SSId":["hello",""],"TelePeriod":300,"Resolution":"558180C0","SetOption":["00008009","2805C8000100060000005A00000000000000","00000000","00006000"]}} 12:03:56 MQT: stat/tasmota/STATUS4 = {"StatusMEM":{"ProgramSize":565,"Free":436,"Heap":21,"ProgramFlashSize":1024,"FlashSize":2048,"FlashChipId":"1540C8","FlashFrequency":40,"FlashMode":3,"Features":["00000809","8F5A2583","040003A1","00000002","010000C0","00000000","00004020"],"Drivers":"1,2,4,5,7,9,10,12","Sensors":""}} 12:03:56 MQT: stat/tasmota/STATUS5 = {"StatusNET":{"Hostname":"tasmota-0589","IPAddress":"192.168.1.152","Gateway":"192.168.1.254","Subnetmask":"255.255.255.0","DNSServer":"192.168.1.254","Mac":"98:F4:AB:BC:A2:4D","Webserver":2,"WifiConfig":2,"WifiPower":17.0}} 12:03:56 MQT: stat/tasmota/STATUS6 = {"StatusMQT":{"MqttHost":"192.168.1.80","MqttPort":1883,"MqttClientMask":"DVES%06X","MqttClient":"DVES_XXXXXX","MqttUser":"mqtt","MqttCount":2,"MAX_PACKET_SIZE":1200,"KEEPALIVE":30}} 12:03:56 MQT: stat/tasmota/STATUS7 = {"StatusTIM":{"UTC":"2020-07-01T11:03:56","Local":"2020-07-01T12:03:56","StartDST":"2020-03-29T02:00:00","EndDST":"2020-10-25T03:00:00","Timezone":"+01:00","Sunrise":"04:51","Sunset":"20:56"}} 12:03:56 MQT: stat/tasmota/STATUS10 = {"StatusSNS":{"Time":"2020-07-01T12:03:56"}} 12:03:57 MQT: stat/tasmota/STATUS11 = {"StatusSTS":{"Time":"2020-07-01T12:03:56","Uptime":"0T20:07:07","UptimeSec":72427,"Vcc":3.543,"Heap":21,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":2,"Wifi":{"AP":1,"SSId":"hello","BSSId":"D6:CA:6D:XX:XX:XX","Channel":7,"RSSI":100,"Signal":-50,"LinkCount":1,"Downtime":"0T00:00:03"}}}

- [x] Provide the output of the Console log output when you experience your issue; if applicable:
  _(Please use_ `weblog 4` _for more debug information)_

Console output here:

12:21:19 NTP: UTC 2020-07-01T11:21:18, DST 2020-03-29T02:00:00, STD 2020-10-25T03:00:00 12:21:19 CMD: Serial buffer overrun 12:21:19 CMD: 00:00:02 CMD: Serial buffer overrun 12:21:19 SRC: Serial 12:21:19 CMD: Group 0, Index 0, Command "", Data ":00:02 CMD: Serial buffer overrun" 12:21:19 RSL: stat/tasmota/RESULT = {"Command":"Unknown"} 12:21:19 CMD: Serial buffer overrun 12:21:19 CMD: Serial buffer overrun 12:21:19 CMD: 00:00:02 CMD: Serial buffer overrun 12:21:19 SRC: Serial 12:21:19 CMD: Group 0, Index 0, Command "", Data ":00:02 CMD: Serial buffer overrun" 12:21:19 RSL: stat/tasmota/RESULT = {"Command":"Unknown"} 12:21:19 CMD: Serial buffer overrun



### TO REPRODUCE
_Steps to reproduce the behavior:_

In Tasmota-IR version `SetOption19 1`

### EXPECTED BEHAVIOUR
_A clear and concise description of what you expected to happen._

Device discovered by Home Assistant

### SCREENSHOTS
_If applicable, add screenshots to help explain your problem._
![20200227-P2270010](https://user-images.githubusercontent.com/47009757/86236710-3450df00-bba3-11ea-8fb0-bce3f81c2a0c.jpg)
![20200227-P2270008](https://user-images.githubusercontent.com/47009757/86236726-37e46600-bba3-11ea-914b-76e1e3a8b343.jpg)

### ADDITIONAL CONTEXT
_Add any other context about the problem here._

It is NOT possible (I don't know how) to recover from error state by resetting the configuration. I have to:
- flash tasmota-minimal.bin
- flash tasmota.bin
- upload clean configuration
- flash tasmota-ir.bin
- configure device
Jason2866 commented 4 years ago

You have to compile your own version with increased serial buffer. Using HA AD AND IR with all enabled IR protocols sends a lot. So serial buffer is to small and buffer overrun can occur. Since resources are very limited the buffer size is designed in size for most use cases. This is not a bug.

pricewatermouse commented 4 years ago

Could you please clarify which parameter is responsible for serial buffer size?

TasmotaSerial.h #define TM_SERIAL_BUFFER_SIZE 64? tasmota.h const uint16_t INPUT_BUFFER_SIZE = 520?

What is recommended buffer size in this case?

Jason2866 commented 4 years ago

Change this https://github.com/arendst/Tasmota/blob/development/tasmota/my_user_config.h#L667 to a greater value and test if this is already is enough. If this does not help increase const uint16_t INPUT_BUFFER_SIZE Maybe you run in the next problem. Mqtt packet size Using HA AD with IR remote full version is bleeding edge...

pricewatermouse commented 4 years ago

Just to make it clear:

The errors occur right after reboot. At this point the device does not send or receive any IR packets. Why do you think increasing the IR_RCV_BUFFER_SIZE will do the job?

The device sends and receives IR commands correctly (including very long ones from MITSUBISHI AC) before I do SetOption19 1, so I assume that the buffer size of the IR subsystem is ok.

Probably the error occurs somewhere in HAssPublishStatus(), however as far as I can see the size of the mqtt publish message does not depend on the number of supported IR protocols.

Anyway, I will try to install the build environment and recompile the firmware

Jason2866 commented 4 years ago

Okay, more light in the issue. So the problem seems is HA AD publish message goes over the limits. Try to shorten as much as possible your mqtt topic(s).

pricewatermouse commented 4 years ago

SOLUTION:

Replace hostname, mqtt topic name, client name(?) with shorter values.

I replaced mine with "t1" and after SetOption19 1 the device sends MQT: homeassistant/sensor/AABBCC_status/config = {"name":"t1 status","stat_t":"tele/t1/HASS_STATE","avty_t":"tele/t1/LWT","pl_avail":"Online","pl_not_avail":"Offline","json_attr_t":"tele/t1/HASS_STATE","unit_of_meas":"%","val_tpl":"{{value_json['RSSI']}}","ic":"mdi:information-outline","uniq_id":"AABBCC_status","dev":{"ids":["AABBCC"],"name":"t1","mdl":"YTF IR Bridge","sw":"8.3.1.6(04dca1e-tasmota)","mf":"Tasmota"}} and is discovered my Home Assistant. Bingo!

To maintainers: I would recommend to implement one the following changes, so device will work out of the box:

Jason2866 commented 4 years ago

drop unnecessary information from HAssPublishStatus to make the message shorter increase mqtt message buffer size, so the default host name and topic name will not overrun replace default host name and topic name with shorter values (this might break existing setups)

What is unnecessary information? -> Different use cases different needs mqtt message buffer size is already 1200. -> Increasing has negative side effects. Considering for IR build replace default host name and topic -> Will NOT be done. There are too many existing installations

pricewatermouse commented 4 years ago

I examined the MQTT traffic between device and broker using Wireshark and found out that the size of the most messages is far below 1200 bytes (LWT-122, POWER - 463, STATE - 388, and some smaller ones),

EXCEPT! the 1182 packet marked by Wireshark as "Malformed Packet" presumably containing output from HAssAnnouncerTriggers function

homeassistant/device_automation/BCA24D_SW_2_TOGGLE/config19.7
homeassistant/device_automation/BCA24D_SW_2_HOLD/config10..
homeassistant/binary_sensor/BCA24D_SW_2/config1;.9
homeassistant/device_automation/BCA24D_SW_3_TOGGLE/config19.7
homeassistant/device_automation/BCA24D_SW_3_HOLD/config10..
homeassistant/binary_sensor/BCA24D_SW_3/config1;.9
homeassistant/device_automation/BCA24D_SW_4_TOGGLE/config19.7
homeassistant/device_automation/BCA24D_SW_4_HOLD/config10..
homeassistant/binary_sensor/BCA24D_SW_4/config1;.9
homeassistant/device_automation/BCA24D_SW_5_TOGGLE/config19.7
...

I wonder why this trash is sent to MQTT broker, since my device has only IR sender/receiver, one LED and one Button?

CMD: Backlog Template; Module; GPIO 255
MQT: stat/tasmota/RESULT = {"NAME":"IRBridge","GPIO":[0,0,0,0,56,51,0,0,0,17,8,0,0],"FLAG":0,"BASE":62}
MQT: stat/tasmota/RESULT = {"Module":{"62":"YTF IR Bridge"}}
MQT: stat/tasmota/RESULT = {"GPIO0":{"0":"None"},"GPIO1":{"0":"None"},"GPIO2":{"0":"None"},"GPIO3":{"0":"None"},"GPIO4":{"56":"Led1i"},"GPIO5":{"51":"IRrecv"},"GPIO9":{"0":"None"},"GPIO10":{"0":"None"},"GPIO12":{"0":"None"},"GPIO13":{"17":"Button1"},"GPIO14":{"8":"IRsend"},"GPIO15":{"0":"None"},"GPIO16":{"0":"None"}}
davidalben commented 4 years ago

Same problem, here. Using NAS-IR03W0 V4 device flashed with tasmota-ir.bin version 8.3.1.

BUT, only if sourced with 5V micro-usb adaptor. When I connect it to 3.3V and GND from a FTDI USB adaptor (without wiring RXD nor TXD), the "Serial buffer overrun" messages don't appear.

Hope it help.

Edit: Shortening GND and RXD error messages disappear and module seams to work properly.

Progaros commented 4 years ago

Shortening GND and RXD error messages disappear and module seams to work properly.

image that's for shortening the magic home controller

nagyrobi commented 4 years ago

A 100nF capacitor would be also enough IMHO.

sim0njo commented 4 years ago

Hi, I have a NAS-IR03-2W0 M V3 dated 20191120... with similar problem of continious sending MQTT messages after flashing tasmota-ir.bin.

Having a look with the scope shows that both RX and TX pins have a 38khz square wave, putting a 100nF cap on it does not help !!!

Both these pins are coupled to the external USB connector via a resistor, although there is no UART/USB chip on the PCB, so useless. You will notice this when plugging this device into a USB socket of your PC -> it does not add a COM port for it.

So I just removed R26 and R29 as they have no use.

Now the device works fine, I can receive and send IR codes ;)

ascillato2 commented 4 years ago

Now the device works fine, I can receive and send IR codes ;)

Great. Thanks

KnightsKingdom commented 4 years ago

Same problem, here. Using NAS-IR03W0 V4 device flashed with tasmota-ir.bin version 8.3.1.

BUT, only if sourced with 5V micro-usb adaptor. When I connect it to 3.3V and GND from a FTDI USB adaptor (without wiring RXD nor TXD), the "Serial buffer overrun" messages don't appear.

Hope it help.

Edit: Shortening GND and RXD error messages disappear and module seams to work properly.

Indeed, this solution also works for me. After clean install of tastmota-ir.bin decice immediately goes into serial buffer overrun Keeping in on 3.3 volts also works but that's not really an option. After booting with the 5v micro usb and then wiring the RX with GND works, but booting when the wiring is still in place does NOT work. It wont come online. How did you solve that?

My device is a JS-A1 IR Controller without RF

pricewatermouse commented 4 years ago

In my case its definitely not a hardware / schematics issue, since the device recognizes IR commands perfectly fine before I set SetOption19 1 and HA Discovery . And also the device worked good previously with its factory firmware and FurLife cloud app.

KnightsKingdom commented 4 years ago

Just did a bit more research. It seems that if I power from usb with GND and RX wired then go to the console and type: 16:26:44 CMD: SerialLog 0 16:26:44 MQT: irblaster/RESULT = {"SerialLog":{"0":{"Active":"0"}}}

I can remove the wire between GND and RX.

Maybe there's a possibility to set a rule to fully disable SerialLogging as soon as possible, anyone any idea?

Btw, I also have HA AD on and that works fine, I dont experience the issue you have.

Jason2866 commented 4 years ago

There is no rule needed. Setting one time Seriallog 0 is persistent

KnightsKingdom commented 4 years ago

When I set SerialLog 0 I get this output:

09:46:35 CMD: seriallog 0 09:46:35 MQT: irblaster/RESULT = {"SerialLog":{"0":{"Active":"0"}}}

After rebooting checking SerialLog I get this:

09:47:22 CMD: seriallog 09:47:22 MQT: irblaster/RESULT = {"SerialLog":{"0":{"Active":"2"}}}

Notice the 'Active' part changed back to Active 2 instead of 0 and the serial buffer overrun occurs again. Doing another SerialLog 0 will set Active to 0 again and I can use the device normally.

phinnay commented 4 years ago

Having the same issue on a generic Sonya device flashed with tasmota-ir.bin 8.5.0 - I can send IR commands from the console in the WebUI however doing so via MQTT broker shows a buffer Overrun

I am NOT using HomeAssistant I have tried changing the hostname, mqtt topic name, client name to shorter values ("IR") I have set Seriallog 0 I am running off 5V USB power

Any option other than custom compiling firmware? Would prefer to avoid as it makes updates a pain...

Progaros commented 4 years ago

Having the same issue on a generic Sonya device flashed with tasmota-ir.bin 8.5.0 - I can send IR commands from the console in the WebUI however doing so via MQTT broker shows a buffer Overrun

I am NOT using HomeAssistant I have tried changing the hostname, mqtt topic name, client name to shorter values ("IR") I have set Seriallog 0 I am running off 5V USB power

Any option other than custom compiling firmware? Would prefer to avoid as it makes updates a pain...

https://github.com/arendst/Tasmota/issues/8829#issuecomment-661163886 This worked for me

phinnay commented 4 years ago

Having the same issue on a generic Sonya device flashed with tasmota-ir.bin 8.5.0 - I can send IR commands from the console in the WebUI however doing so via MQTT broker shows a buffer Overrun I am NOT using HomeAssistant I have tried changing the hostname, mqtt topic name, client name to shorter values ("IR") I have set Seriallog 0 I am running off 5V USB power Any option other than custom compiling firmware? Would prefer to avoid as it makes updates a pain...

#8829 (comment) This worked for me

This also works for me, but it must be done after the device is already powered up... Does not seem practical for general use.

phinnay commented 4 years ago

For reference: both devices I've tried that are experiencing this behavior https://www.amazon.com/gp/product/B07ZP5NQWF/ https://www.amazon.com/gp/product/B07HRK36Y5/

DaveCorder commented 3 years ago

Just wanted to chime in that I had this issue on some IR blasters I recently acquired from AliExpress.

Mine are Moes branded and the internal PCB looks identical to what the OP posted. I was not able to flash mine with tuya-convert, but a good ol' serial flash worked fine.

I had remove resistors R14 and R15 (the two teeny tiny ones next to the pushbutton) and after that the "CMD: Serial buffer overrun" messages went away and the ability to send and receive IR signals returned.

GhettoDubs commented 3 years ago

I had same problem on Mirabella Genio IR blaster when I used a Google Home Mini USB power supply (5V 1.8A). When I used the power supply that came with it I got no Serial Buffer Overrun error (5V, 1A). Device worked ok to transmit with both power supplies.

Flashed to tasmota version 8.5.1(ir)

https://www.mirabellagenio.com.au/product-range/mirabella-genio-wi-fi-smart-ir-universal-remote-controller/

reimerp commented 3 years ago

Sy, a closed and rather old bug, but I came accross this while upgrading and forcing "Reset 4" on a Neo Coolcam IR with a Release 9.5.0 IR Firmware. I was facing the same "Serial Buffer underrun" errors unless I switched to the correct module (Module 0 together wirt a template from blakadder). Maybe this helps someone.

demmacs commented 2 years ago

Please, add in GPIO 1 and in GPIO 3 configurations, LED outputs to avoid Tasmota reading those pins.

In your hardware seems that TX and RX pins are soldered together.