tx timeout

[manjh]

Vreemd, dacht dat ik dit al ge-post had maar zie het nergens, dus nogmaals.

Sinds enige tijd ondervind ik problemen met mijn RFLink-Wifi. Hij werkt goed, maar soms krijg ik in Domoticz opeens meldingen "tx timeout", of iets in die strekking.
Soms komt hij er spontaan weer uit, maar soms moet ik de RFLink entry in de HW tab van Domoticz op disabled zetten, en daarna enabled. Dan werkt hij weer.

Ik heb ook een tweede RFLink in mijn zomerhuis, maar die is USB verbonden en heeft geen enkel probleem.

Enig idee wat hier aan de hand kan zijn?

Inmiddels heb ik de "data timeout" maar eens van 5 naar 1 minuut verlaagd, eens zien of dat iets uitmaakt. Zal er in elk geval voor zorgen dat hij max 1 minuut "down" is. Maar dat wil je natuurlijk ook niet. Ik zie dit dan ook niet als een echte oplossing van het probleem.

Tips?

[Stuntteam]

Deze?:
viewtopic.php?f=17&t=7423&p=42299#p42299

Wellicht je wifi oplossing eens goed bekijken?

[manjh]

Heb ik al gedaan (RF band). Twee Chinese PIR sensors, een KAKU PIR, en een deursensor: allemaal voorzien van verse (en goede) batterijtjes.
Wifi is ook in orde, dekking is uitstekend.
Ik heb nu pakweg 15 ESPEasy units draaien, allemaal op WiFi. Geen enkel probleem (data volume is heel klein, en ik zorg dat ze niet nodeloos vaak transmitten).

[manjh]

Ik overweeg om de ESPEasy in deze unit bij te werken, wat er nu inzit is stokoud (124 - RX buffer 1024, core 2_3_0).
Maar het was wel een versie met een vergrote RX buffer, destijds speciaal aangemaakt voor gebruik met de P1 meter.
Is dit bij nieuwere ESPEasy versies ook nog nodig? Welke versie kan ik het beste pakken?

[TD-er]

Houd dan wel een backup van je huidige versie bij de hand, want de nieuwere builds zijn niet altijd stabieler wat betreft WiFi.

Nieuwere versies van ESPEasy pollen de serial buffer wel met een hogere frequentie, naast dat er zeer veel andere zaken verbeterd zijn.
Sowieso heeft de ESP zelf geen grotere buffer dan 128 bytes, oftewel als je de nu een grotere buffer hebt, is dat ook in software gedaan en hangt het dus ook af van hoe snel je die HW buffer kunt uitlezen.

[manjh]

Houd dan wel een backup van je huidige versie bij de hand, want de nieuwere builds zijn niet altijd stabieler wat betreft WiFi.

Nieuwere versies van ESPEasy pollen de serial buffer wel met een hogere frequentie, naast dat er zeer veel andere zaken verbeterd zijn.
Sowieso heeft de ESP zelf geen grotere buffer dan 128 bytes, oftewel als je de nu een grotere buffer hebt, is dat ook in software gedaan en hangt het dus ook af van hoe snel je die HW buffer kunt uitlezen.

Begrijp ik. Betekent dus dat je een P1 interface liefst niet te veel moet belasten met andere sensoren, maar dedicated houden.
Welke release beveel je aan? Ik zocht in de Wiki naar een stuk release-info, maar volgens mij is deze pagine outdated:
https://letscontrolit.com/wiki/index.php?title=ESPEasy

[TD-er]

De wiki is outdated inderdaad.

Sowieso zou ik een recente versie pakken.
Misschien niet de allerlaatste versie, maar een van dit jaar.

[manjh]

Domme vraag, maar het is alweer lang geleden sinds ik ESPEasy downloadde...
ik zie op Github alleen een download van source. Is er niet ergens een repository van pre-compiled versies? Ik herinner me dat er per build een versie van 512, 1024 en 4096 was...

[manjh]

Domme vraag, maar het is alweer lang geleden sinds ik ESPEasy downloadde...
ik zie op Github alleen een download van source. Is er niet ergens een repository van pre-compiled versies? Ik herinner me dat er per build een versie van 512, 1024 en 4096 was...

Laat maar, heb het al gevonden.
Ik denk dat ik versie 20200204 kies. Is dat verstandig?

[TD-er]

Yep, let alleen wel op de grootte van de flash.
De notatie ervan is iets veranderd tegenwoordig.
Bijv. "4M1M" wil zeggen 4MB flash, 1 MB SPIFFS (wat waarschijnlijk de setting is die je vroeger gebruikte op een 4M module)

[manjh]

OK, dus deze zou goed moeten zijn:

ESP_Easy_mega-20200204_normal_ESP8266_4M1M

[manjh]

Excuses, ik ben een beetje "roestig" met het flashen.
Heb een P1 interface met daarop een ESP 8266 unit. Via USB aan een Win10 laptop.
ESP.Easy.Flasher gestart, de juiste COM wordt gevonden. File geselecteerd, en op Flash geklikt.
Na een paar seconden een error message, en dit staat in de log:

Code: Select all

######2020-03-20######
#######0.04.007#######
######FLASH INFO######
BIN file: ESP_Easy_mega-20200204_normal_ESP8266_4M1M.bin
COM port: (COM8) Silicon Labs CP210x USB to UART Bridge (Port_#0001.Hub_#0001)
Baud rate: 115200
######POST FLASH######
No post flash information entered...
######FLASH LOG######
[esptool.exe -vv -cd nodemcu -cb 115200 -cp COM8 -ca 0x00000 -cf "C:\Users\Peaq\Desktop\Domotica\ESPEasy flasher & images\bin\ESP_Easy_mega-20200204_normal_ESP8266_4M1M.bin"]
[20-3-2020 12:54:16] esptool v0.4.12 - (c) 2014 Ch. Klippel <ck@atelier-klippel.de>
[20-3-2020 12:54:16] 	setting board to nodemcu
[20-3-2020 12:54:16] 	setting baudrate from 115200 to 115200
[20-3-2020 12:54:16] 	setting port from  to COM8
[20-3-2020 12:54:16] 	setting address from 0x00000000 to 0x00000000
[20-3-2020 12:54:16] 	espcomm_upload_file
[20-3-2020 12:54:16] 	espcomm_upload_mem
[20-3-2020 12:54:16] 	setting serial port timeouts to 1000 ms
[20-3-2020 12:54:16] opening bootloader
[20-3-2020 12:54:16] resetting board
[20-3-2020 12:54:16] trying to connect
[20-3-2020 12:54:16] 	flush start
[20-3-2020 12:54:16] 	setting serial port timeouts to 1 ms
[20-3-2020 12:54:16] 	setting serial port timeouts to 1000 ms
[20-3-2020 12:54:16] 	flush complete
[20-3-2020 12:54:16] 	espcomm_send_command: sending command header
[20-3-2020 12:54:16] 	espcomm_send_command: sending command payload
[20-3-2020 12:54:16] 	serialport_receive_C0: 02 instead of C0
[20-3-2020 12:54:16] trying to connect
[20-3-2020 12:54:16] 	flush start
[20-3-2020 12:54:16] 	setting serial port timeouts to 1 ms
[20-3-2020 12:54:16] 	setting serial port timeouts to 1000 ms
[20-3-2020 12:54:16] 	flush complete
[20-3-2020 12:54:16] 	espcomm_send_command: sending command header
[20-3-2020 12:54:16] 	espcomm_send_command: sending command payload
[20-3-2020 12:54:16] 	serialport_receive_C0: 04 instead of C0
[20-3-2020 12:54:16] trying to connect
[20-3-2020 12:54:16] 	flush start
[20-3-2020 12:54:16] 	setting serial port timeouts to 1 ms
[20-3-2020 12:54:16] 	setting serial port timeouts to 1000 ms
[20-3-2020 12:54:16] 	flush complete
[20-3-2020 12:54:16] 	espcomm_send_command: sending command header
[20-3-2020 12:54:16] 	espcomm_send_command: sending command payload
[20-3-2020 12:54:16] 	serialport_receive_C0: 82 instead of C0
[20-3-2020 12:54:16] resetting board
[20-3-2020 12:54:16] trying to connect
[20-3-2020 12:54:16] 	flush start
[20-3-2020 12:54:16] 	setting serial port timeouts to 1 ms
[20-3-2020 12:54:16] 	setting serial port timeouts to 1000 ms
[20-3-2020 12:54:16] 	flush complete
[20-3-2020 12:54:16] 	espcomm_send_command: sending command header
[20-3-2020 12:54:16] 	espcomm_send_command: sending command payload
[20-3-2020 12:54:16] 	serialport_receive_C0: 68 instead of C0
[20-3-2020 12:54:16] trying to connect
[20-3-2020 12:54:16] 	flush start
[20-3-2020 12:54:16] 	setting serial port timeouts to 1 ms
[20-3-2020 12:54:16] 	setting serial port timeouts to 1000 ms
[20-3-2020 12:54:16] 	flush complete
[20-3-2020 12:54:16] 	espcomm_send_command: sending command header
[20-3-2020 12:54:16] 	espcomm_send_command: sending command payload
[20-3-2020 12:54:16] 	serialport_receive_C0: 81 instead of C0
[20-3-2020 12:54:16] trying to connect
[20-3-2020 12:54:16] 	flush start
[20-3-2020 12:54:16] 	setting serial port timeouts to 1 ms
[20-3-2020 12:54:16] 	setting serial port timeouts to 1000 ms
[20-3-2020 12:54:16] 	flush complete
[20-3-2020 12:54:16] 	espcomm_send_command: sending command header
[20-3-2020 12:54:16] 	espcomm_send_command: sending command payload
[20-3-2020 12:54:16] 	serialport_receive_C0: 70 instead of C0
[20-3-2020 12:54:16] resetting board
[20-3-2020 12:54:16] trying to connect
[20-3-2020 12:54:16] 	flush start
[20-3-2020 12:54:16] 	setting serial port timeouts to 1 ms
[20-3-2020 12:54:16] 	setting serial port timeouts to 1000 ms
[20-3-2020 12:54:16] 	flush complete
[20-3-2020 12:54:16] 	espcomm_send_command: sending command header
[20-3-2020 12:54:16] 	espcomm_send_command: sending command payload
[20-3-2020 12:54:16] 	serialport_receive_C0: 00 instead of C0
[20-3-2020 12:54:16] trying to connect
[20-3-2020 12:54:16] 	flush start
[20-3-2020 12:54:16] 	setting serial port timeouts to 1 ms
[20-3-2020 12:54:16] 	setting serial port timeouts to 1000 ms
[20-3-2020 12:54:16] 	flush complete
[20-3-2020 12:54:16] 	espcomm_send_command: sending command header
[20-3-2020 12:54:16] 	espcomm_send_command: sending command payload
[20-3-2020 12:54:16] 	serialport_receive_C0: 00 instead of C0
[20-3-2020 12:54:16] trying to connect
[20-3-2020 12:54:16] 	flush start
[20-3-2020 12:54:16] 	setting serial port timeouts to 1 ms
[20-3-2020 12:54:16] 	setting serial port timeouts to 1000 ms
[20-3-2020 12:54:16] 	flush complete
[20-3-2020 12:54:16] 	espcomm_send_command: sending command header
[20-3-2020 12:54:16] 	espcomm_send_command: sending command payload
[20-3-2020 12:54:16] 	serialport_receive_C0: 00 instead of C0
[20-3-2020 12:54:16] warning: espcomm_sync failed
[20-3-2020 12:54:16] error: espcomm_open failed
[20-3-2020 12:54:16] error: espcomm_upload_mem failed
[2020-03-20 12:54:16] STOPPED due to 2 errors! (try reset on the unit, then start a new flash attempt)

Ik heb het ook geprobeerd na "reset", zelfde resultaat.
Wat doe ik verkeerd?

[TD-er]

GPIO-0 moet aan de GND getrokken worden (via weerstand) om in de flash-mode te komen bij het booten.
Hoe zit die P1 aangesloten op de ESP? Als 'ie Serial0 gebruikt, heb je kans dat je daarmee het flashen beïnvloed.

Als er al ESPEasy op staat, kun je natuurlijk ook een OTA update doen.

[manjh]

OTA heb ik geprobeerd (als eerste, ik ben lui....). Maar lukte niet. Unit herstartte met de oude versie.
Probleem met deze unit is dat hij op de P1 interface print gesoldeerd zit. Ik kan hem er dus niet eenvoudig even vanaf trekken... misschien is dat de reden?

[martinus]

Houd dan wel een backup van je huidige versie bij de hand, want de nieuwere builds zijn niet altijd stabieler wat betreft WiFi.

Nieuwere versies van ESPEasy pollen de serial buffer wel met een hogere frequentie, naast dat er zeer veel andere zaken verbeterd zijn.
Sowieso heeft de ESP zelf geen grotere buffer dan 128 bytes, oftewel als je de nu een grotere buffer hebt, is dat ook in software gedaan en hangt het dus ook af van hoe snel je die HW buffer kunt uitlezen.

Volgens mij heeft de ESP geen hardware FIFO en gebruikt een low-level interupt driven ringbuffer met een default size van 256, zie header file:

Code: Select all

HardwareSerial::HardwareSerial(int uart_nr)
    : _uart_nr(uart_nr), _rx_size(256)

Maar in tegenstelling tot de oudere cores is er nu blijkbaar wel een call om de size te vergroten in runtime:

Code: Select all

size_t HardwareSerial::setRxBufferSize(size_t size)

Dus in plaats van een tweede buffer in ESP Easy is het denk ik beter om de onderliggende core buffer te vergroten als dat nodig is. Setting in de GUI?

[TD-er]

Volgens mij zit die extra buffer gewoon in de core lib, oftewel is nog steeds software. (alleen dan interrupt driven)
De 128 bytes is -voor zover ik weet- de HW-serial. (Serial0)
Serial1 kan alleen maar de TX gebruiken, dus ik vermoed dat die dan een enkele buffer heeft.

Maar een extra setting voor de buffer-grootte kan wel interessant zijn, al denk ik dat het meer een setting voor die plugin zou moeten zijn aangezien andere plugins geen moeite lijken te hebben met de grootte van de buffer?
Aan de andere kant het is niet alsof je >1 HW serial gebruikt.

[manjh]

Ik merk dat ik in deze post twee dingen door elkaar heb gehaald RFLink en P1.
Hou het voor nu even bij de RFLink. In draaide op build 147, en zag steeds vaker de TX timeouts.
Heb vandaag het ding maar eens uitgegraven en er een recente Mega op gezet:

Code: Select all

ESP_Easy_mega-20200204_normal_ESP8266_4M1M

Installatie ging goed, en ik heb alles ingesteld. Alleen merkte ik dat hij een lifespan van pakweg 2 minuten had, daarna ging hij spontaan een reboot uitvoeren.
Ik had er geen rules ingezet.
Heb van alles geprobeerd, maar niets hielp.
Wat wel werkte: áls hij dan up was, dan kon ik prima RF signalen uitsturen!
Maar die reboot elke 2 minuten is natuurlijk niet handig.
Ben dus voor nu maar weer even terug naar build 147 gegaan...

Wat kan hiervan de oorzaak zijn?

[manjh]

Hmmm... vreemd. Ook met build 147 vertoont hij dit gedrag.
Maar als ik de ESP van de RFLink koppelprint afhaal, en stand alone laat draaien, dan blijft hij wel alive...
Het ligt dus ófwel aan de Arduino en/of de koppelprint, ofwel aan een configuratiefout!

[manjh]

Stapje verder: ik heb een nieuwe Arduino Mega erbij gepakt en daar RFLink R48 op gezet.
Het koppelprintje met de ESP unit overgezet, ingeplugged. Draait.
Maar ook nu weer binnen 2 minuten een reboot....

[Stuntteam]

Logisch.. het probleem zit niet in RFlink en niet in de Arduino Mega..
maar in de esp firmware.

[manjh]

Om verder deze ui af te pellen, heb ik de devices eruit gegooid: uptime reporter, en de Rflink serial server.
No luck, hij reboot nog steeds om de minuut of zo. Begin een beetje radeloos te worden...

[manjh]

Logisch.. het probleem zit niet in RFlink en niet in de Arduino Mega..
maar in de esp firmware.

OK, maar hoe kan het dan dat ik het probleem heb in build 147, en ook in de nieuwe Mega build?
Ik heb nu een nieuwe Mega, een nieuwe ESP, nieuwe RFLink firmware en een nieuwe Mega build van de ESP. Volgens mij heb ik alles vervangen, behalve de koppelprint...

[TD-er]

Zou het kunnen zijn dat de RF-link zaken op de ESP verstoort?
Of wellicht lopen er buffers vol?
Zou je als test kunnen kijken hoe snel het 'free memory' afneemt?

[manjh]

Heb een tijdje zitten meekijken op het log, maar zag niks bijzonders. Hij reboot gewoon elke twee minuten.
Inmiddels heb ik de handdoek in de ring gegooid. RFLink hangt nu met een USB kabel aan mijn R-Pi. Betekende wel dat ik alle RF signalen in Domoticz opnieuw moest inleren, omdat een RFLink-LAN een heel ander beest is dan een RFLink-USB... ik heb nog gezocht naar een migratie mogelijkheid, maar kon zo gauw niks vinden.
Wel iets anders: ik had inmiddels een nieuwe Mega met RFLink-48 erop in gebruik. Alle signalen heb ik opnieuw kunnen instellen, behalve vier Quigg schakelaars. Hij herkende het signaal van de RC niet. Ik heb de oude Mega met RFLink-45 er weer op gezet, en die herkent de signalen wel.
Is het support voor deze Quigg gestopt?

[TD-er]

Heeft dat protocol wellicht een vrij lange sequence? (buffer lengte seriële poort)

[manjh]

Heeft dat protocol wellicht een vrij lange sequence? (buffer lengte seriële poort)

Geen idee. Ik weet alleen dat ik die dingen ooit kocht bij Aldi of Lidl, en dat het signaal gewoon herkend werd. Met de nieuwste RFLink release is dat niet meer zo.
Hoe kan ik dat signaal capturen voor je?

[manjh]

Ik heb sinds gisteren de LAN versie van de RFLink vervangen door een USB versie. Kostte wat zweetdruppels en tijd om alles om te zetten, maar het draait nu al een hele tijd stabiel. Lijkt erop dat Domoticz ook wat stabieler blijft, geen spontane restarts meer.
Het is misschien wat vroeg om conclusies te trekken, maar.....

[manjh]

Ruim een week verder, en tijd voor een update.

Sinds de omschakeling van RFLink-LAN naar RFLink-USB zijn alle problemen verdwenen. Ik kan niet hard aantonen dat het hieraan lag, maar het is wel frappant dat ik in een week tijd niet één Domoticz restart heb zien gebeuren, terwijl dat voorheen minimaal eens per dag was, vaak zelfs meer.

Het lijkt ook wel alsof het RF signaal "krachtiger" is. Onzin natuurlijk, want de hardware is niet veranderd: ik heb alleen de ESP unit van de kaart afgetrokken en heb een USB kabel ingeprikt.
Maar toch... devices reageren sneller (kan ik me iets bij voorstellen, USB is rechtstreeks en LAN loopt via WiFi, plus nog de ESP ertussen), maar devices reageren ook betrouwbaarder: vroeger ging er nog wel eens een commando de mist in, en dat gebeurt eigenlijk niet meer.
Al met al: RFLink-USB blijft erin!

[TD-er]

Een probleem wat zich bij de ESP nogal vaak voort doet is dat 'ie ARP requests mist.
Oftewel je netwerk weet dan na een bepaalde tijd niet meer waar pakketjes voor die ESP naar toe moeten, omdat de switches niet meer weten achter welke poort de ESP zich bevind.

In ESPEasy heb ik hiervoor de Gratuitous ARP optie ingebouwd.
Deze zend dan periodiek, en zeker na een gefaalde netwerk-actie (DNS lookup, connect, etc) Gratuitous ARP pakketje.
Oftewel een antwoord op een vraag die niemand stelde, namelijk "wie heeft IP-adres a.b.c.d?"
Op die manier voorkom je dat de switches en overige netwerk-apparatuur vergeet waar het MAC-adres van de ESP zich bevind.

[manjh]

Alles goed en wel, maar dat verklaart nog niet waarom Domoticz regelmatig "onderuit" gaat....

Bovendien: RFLink ontvangt bij mij zeer regelmatig signalen. Ik heb diverse PIR sensors, plus een handvol temp&hum sensors die via RF elke 45 seconden hun waardes insturen. Dus de kans dat de ESP unit op de RFLink in de vergetelheid verdwijnt bij de switches lijkt me erg klein..

[TD-er]

De tijd van "vergeten" verschilt per netwerk-apparaat.
Meestal is het in de orde van enkele minuten, maar soms ook in de orde van 30 seconden.
En een goedkope switch gaat echt niet z'n tabellen opnieuw ordenen als er een nieuw pakketje van AA:BB;CC:DD:EE:FF voorbij komt.
Die entry gaat er gewoonweg uit X seconden nadat 'ie toegevoegd is aan de MAC-tabel.

Dus zelfs met een TTL van een uur, kan het zo zijn dat 'ie op 59:59 na toevoegen aan de MAC-tabel nog prima een pakketje kon doorsturen naar de juiste poort, terwijl 'ie 1 seconde later geen idee meer heeft waar 'ie moet zijn met z'n pakketje voor MAC AA:BB:CC:DD:EE:FF.

Dus zelfs als je elke 5 seconden een Gratuitous ARP verstuurt, kan het voorkomen dat een verbinding opbouwen bijna 5 seconden kan duren.

En dat missen van ARP pakketjes komt op de ESP helaas best wel heel erg vaak voor.

[manjh]

Even een korte update... het is nu ongeveer een maand geleden dat ik mijn RFLink om-gekat heb van LAN naar USB. Sindsdien is Domoticz nog niet één keer onderuit gegaan, terwijl dat vóór die omschakeling zeer vaak gebeurde, vaak zelfs meerdere keren per dag.
Begin nu toch echt te geloven dat ik hiermee de ellende kwijt ben...