Het grote ESP topic

[Raymond P]

@HF5236 Gezien je kabels hebt gesoldeerd: meet rx/tx eens door op kortsluiting.

[HF5236]

Raymond P schreef op donderdag 9 maart 2023 @ 12:51:
@HF5236 Gezien je kabels hebt gesoldeerd: meet rx/tx eens door op kortsluiting.

Dan moet ik even een multimeter ergens regelen of kan dit ook op een andere manier?

[Raymond P]

@HF5236 Je kunt creatief aan de slag met 3V en een ledje/buzzer, maar een multimeter met doorpiepstand is sowieso handig om te hebben.
Je kunt het ook visueel inspecteren, wat wel eens voorkomt bij gebruik van kabel (neem voor het gemak aan dat dat geen massieve kern was) een strand brugt tussen twee soldeeroogjes. Wel iets waar je ontzettend makkelijk overheen kijkt.

fwiw: op een esp32-s2 zou je aan praktisch elke pin uart kunnen koppelen en had het switchen in code gewoon gewerkt. Of dat ook zo is in esphome weet ik niet.

[HF5236]

Heb even gekeken of het helpt als ik twee nieuwe kabels er in hang maar helaas geen effect.

[Frij5fd]

renevdstap schreef op zondag 22 januari 2023 @ 17:56:
Ik lees dat meerdere mensen issues hebben met de stabiliteit van de ESP-32 CAM. Nu heb ik net voor het eerst ook twee van deze modules besteld en krijg ze ook niet stabiel aan de praat. Eerst probeerde ik ze te flashen vanuit ESPHOME maar daar lijkt in de laatste versie een bug te zitten. Vervolgens heb ik ze geflasht vanuit Arduino IDE volgens de AI thinker versie, hoewel het geen originele is. Ik krijg wel een webinterface online maar met moeite komt daar een foto uit. De stream wil al helemaal niet starten.

Ook bij mij vermoed ik dat het aan de stroomtoevoer ligt. Heb het geprobeerd via de bijgeleverde seriele controller, vanaf een ESP8266 en vanaf een Raspberry PI. Heb ook een USB kabel gestript maar die kwam helemaal niet online.

Hebben jullie nog advies voor een stabiele stroomtoevoer? Of ervaring met een bepaalde versie ESP-32 CAM module? Ik heb de volgende:
https://www.amazon.nl/dp/...o2ov_dt_b_product_details

UPDATE:
Ik heb inmiddels een derde ESP-32 CAM ontvangen en die werkt zonder problemen. Dat is denk ik het risico van het shoppen op Amazon.

Ik heb wat zitten uitproberen met de de ESP-32 CAM die ik bij Tinytronics gekocht heb (ESP32-CAM - WiFi and Bluetooth Board with OV2640 Camera, AI-thinker-model), met de webcamserver sketch.

Als ik deze vanaf mijn PC met 5 Volt voedt met de FT232RL 3.3v-5v TTL USB Serial Port Adapter van Tinytronics kan ik een resolutie van 1600x1200 pixels met een refresh rate van 1 beeld per 2 à 3 seconden krijgen. De serial monitor van de Arduino IDE geeft daarbij overigens geen melding van brown-outs.

Als ik dezelfde voeding via een ESP32-CAM-MB Programmer Shield van Tinytronics gebruik, dan kan ik deze framerate alleen bij 320x200 pixels krijgen. Bij 1600x1200 bouwt er bijna geen beeld meer op.

Ik neem aan dat ik een add-on bordje nodig heb met losse 5 Volt-voeding aansluiting, waar de ESP-32 CAM opgeprikt kan worden, voor de beste framerate bij 1600x1200 pixels?

[PurpleBlue]

Ik heb een vraagje over een stukje lambda waar ik niet uitkom bij mijn Mi-Desklamp 1S.
Deze is geflasht met ESPHome.

Als ik aan de draainkop op de lamp draai, wordt de lamp feller, of zwakker.
Echter als hij "te ver dimt" gaat hij uit.

Dimmen gaat via dit stukje:

YAML:

- platform: rotary_encoder
    id: rotation
    pin_a: GPIO27
    pin_b: GPIO26
    resolution: 2
    on_value:
      # Draait iemand aan de knop?
      then: 
        - if:
            #Ga na of de lamp aan staat?
            condition:
              - light.is_on: light1
              
            then: 
            # Staat de lamp aan, ga kijken of hij is ingedukt
            - if:
                condition:
                    - lambda: 'return id(button).state;'
                    
                then:
                  # Ja, knop ingedrukt, stel temperatuur in
                  - lambda: |-
                      auto min_temp = id(light1).get_traits().get_min_mireds();
                      auto max_temp = id(light1).get_traits().get_max_mireds();
                      auto cur_temp = id(light1).current_values.get_color_temperature();
                      auto new_temp = max(min_temp, min(max_temp, cur_temp + (x*10)));
                      auto call = id(light1).turn_on();
                      call.set_color_temperature(new_temp);
                      call.perform();
                      
                else:
                  # niet ingedrukt, stel felheid in
                  - light.dim_relative:
                     id: light1
                     relative_brightness: !lambda |-
                      return x / 20.0;
                                              
            # Reset de waarde          
            - sensor.rotary_encoder.set_value:
                id: rotation
                value: 0

Ik dacht het zelf "simpel" te kunnen oplossen door dit toe te passen:

YAML:

- platform: rotary_encoder
    id: rotation
    pin_a: GPIO27
    pin_b: GPIO26
    resolution: 2
    on_value:
      # Draait iemand aan de knop?
      then: 
        - if:
            #Ga na of de lamp aan staat?
            condition:
              - light.is_on: light1
              
            then: 
            # Staat de lamp aan, ga kijken of hij is ingedukt
            - if:
                condition:
                    - lambda: 'return id(button).state;'
                    
                then:
                  # Ja, knop ingedrukt, stel temperatuur in
                  - lambda: |-
                      auto min_temp = id(light1).get_traits().get_min_mireds();
                      auto max_temp = id(light1).get_traits().get_max_mireds();
                      auto cur_temp = id(light1).current_values.get_color_temperature();
                      auto new_temp = max(min_temp, min(max_temp, cur_temp + (x*10)));
                      auto call = id(light1).turn_on();
                      call.set_color_temperature(new_temp);
                      call.perform();
                      
                else:
                  # niet ingedrukt, stel felheid in
                  - light.dim_relative:
                     id: light1
                     relative_brightness: !lambda |-
                     if (x / 25.0 >= 2){
                        return x / 25.0;
                      } else {
                        return 2;
                      }
                                              
            # Reset de waarde          
            - sensor.rotary_encoder.set_value:
                id: rotation
                value: 0

Dit werkt helaas niet, en de waarde/felheid blijft altijd op 100%

Iemand een idee hoe ik ervoor kan zorgen dat hij niet uitgaat bij "te ver dimmen"?
Iemand een idee hoe ik dit voor elkaar kan krijgen?

[Voor 64% gewijzigd door PurpleBlue op 12-03-2023 16:06. Reden: Iets meer yaml code]

[19roland70]

Ik heb een esp32 in gebruik voor de monitoring van de zonnepanelen.
Als ik nu in home assitant kijk staat deze ook in esphome , hier staat adoptie bij.
Wat kan ik hiermee en moet ik dit doen?

[vonkkie]

als je hem met esphome heb geprogrammeert zou hij er al in moeten staan zo niet voegt hij hem toe zodat je hem uit esphome kan beheren

[19roland70]

vonkkie schreef op zondag 12 maart 2023 @ 20:11:
als je hem met esphome heb geprogrammeert zou hij er al in moeten staan zo niet voegt hij hem toe zodat je hem uit esphome kan beheren

Ik heb in de esp een aparte bin file in geladen met specifieke software voor zonnepanelen , deze staat verder (voorlopig)los van HA

[vonkkie]

dan zou ik hem niet toevoegenaan esphome

zou balen zijn als hij hem overschrijft

[Kalkran]

PurpleBlue schreef op zondag 12 maart 2023 @ 13:39:
Ik heb een vraagje over een stukje lambda waar ik niet uitkom bij mijn Mi-Desklamp 1S.
Deze is geflasht met ESPHome.

Als ik aan de draainkop op de lamp draai, wordt de lamp feller, of zwakker.
Echter als hij "te ver dimt" gaat hij uit.

Makkelijkste is denk ik om je originele code te omringen met een max(), zo komt-ie nooit onder een minimumwaarde (in dit geval 2.0).

code:

#...
                  # niet ingedrukt, stel felheid in
                  - light.dim_relative:
                     id: light1
                     relative_brightness: !lambda |-
                      return max(x / 20.0, 2.0);
#...

[PurpleBlue]

Kalkran schreef op maandag 13 maart 2023 @ 14:41:
[...]


Makkelijkste is denk ik om je originele code te omringen met een max(), zo komt-ie nooit onder een minimumwaarde (in dit geval 2.0).

code:

#...
                  # niet ingedrukt, stel felheid in
                  - light.dim_relative:
                     id: light1
                     relative_brightness: !lambda |-
                      return max(x / 20.0, 2.0);
#...

Dank, echter blijft hij nu op 100% staan.

Ik zie in de logging als ik naar links draai:

code:

[16:11:20][D][sensor:127]: 'rotation': Sending state -1.00000 steps with 0 decimals of accuracy
[16:11:20][D][custom:092]: The value is: -0.050000
[16:11:20][D][light:035]: 'Bureaulamp Light' Setting:
[16:11:20][D][light:050]:   Brightness: 100%
[16:11:20][D][sensor:127]: 'rotation': Sending state 0.00000 steps with 0 decimals of accuracy
[16:11:20][D][custom:092]: The value is: 0.000000
[16:11:20][D][light:035]: 'Bureaulamp Light' Setting:
[16:11:20][D][light:050]:   Brightness: 100%

blijkbaar doet hij een stapje van "-0.050000" bij dimmen, of "0.050000" bij feller ten opzichte van de bestaande "felheid"
Ik moet dus eerst zien te achterhalen wat de huidige status is, en welke kant de rotary op gaat denk ik?

Edit:
Het is gelukt!:
Via de "id(rotation).state" kan ik bepalen of deze linksom of rechtsom draait (-1.0 of 1.0)
Verder een check via "id(light1)->remote_values.get_brightness()" gekeken of hij niet onder de gestelde waarde komt.
Hij blijft nu netjes gedimt, en bij inschakelen gaat hij dan ook naar laatste waarde in plaats van 100%
Voor de geïnteresseerde het resultaat:

YAML:

 - platform: rotary_encoder
    name: "Rotary decoder"
    id: rotation
    pin_a: GPIO27
    pin_b: GPIO26
    resolution: 2
    on_value:
      # Draait iemand aan de knop?
      then: 

        - if:
            #Ga na of de lamp aan staat?
            condition:
              - light.is_on: light1
              
            then: 
            # Staat de lamp aan, ga kijken of hij is ingedukt
            - if:
                condition:
                    - lambda: 'return id(button).state;'
                    
                then:
                  # Ja, knop ingedrukt, stel temperatuur in
                  - lambda: |-
                      auto min_temp = id(light1).get_traits().get_min_mireds();
                      auto max_temp = id(light1).get_traits().get_max_mireds();
                      auto cur_temp = id(light1).current_values.get_color_temperature();
                      auto new_temp = max(min_temp, min(max_temp, cur_temp + (x*5)));
                      auto call = id(light1).turn_on();
                      call.set_color_temperature(new_temp);
                      call.perform();
                      
                else:
                    - if:
                        condition:
                            - lambda: 'return id(rotation).state == -1.0;'
                        then:
                            - logger.log: "Links"
                            - light.dim_relative:
                                id: light1
                                relative_brightness: !lambda |-
                                    if (id(light1)->remote_values.get_brightness() >= 0.04) {
                                        return x / 25.0;
                                    } else {
                                      return 0.0;
                                    };
          
                    - if:
                        condition:
                            - lambda: 'return id(rotation).state == 1.0;'
                        then:
                            - logger.log: "Rechts"               
                            - light.dim_relative:
                                id: light1
                                relative_brightness: !lambda |-
                                    return x / 25.0;
        
            # Reset de waarde naar 0        
            - sensor.rotary_encoder.set_value:
                id: rotation
                value: 0

[Voor 52% gewijzigd door PurpleBlue op 14-03-2023 15:52]

[leecher]

Ik heb een ESP32 waar micropython op draait. Ongeacht de code die ik erop zet heb ik het volgende probleem: Als je voor het eerst stroom op de ESP zet dan boot hij niet, dat doet hij pas als je op de RST knop heb gedrukt. Wat ook werkt is hem om aan een pc te hangen en dan de IDE/REPL te openen, dan gaat hij ook van start.

Hoe kan ik ervoor zorgen dat hij direct boot.py (boot.py is leeg) -> main.py doet?

[bartbh]

Ik heb een ESP8266 in mijn koffiemachine waarmee ik via SoftwareSerial een input uitlees en deze 1-op-1 doorstuur. Op deze manier zit mijn ESP8266 als het waren tussen de input van het bedieningspaneel en de body van het apparaat in. Doel is om de machine zowel via de esp8266 (dus wifi) als via het bedieningspaneel te kunnen bedienen.

Via onderstaande code lees ik in loop() de eventuele input op sofwareserial uit en stuur deze door naar de hardware tx.

code:

  while (swSer.available() > 0) {
    Serial.write(swSer.read());
  }

Echter als het apparaat aanstaat, komt er een constante stroom data vanaf het display. Dit resulteert in een constante stroom van data (opvragen van status-updates). Het lijkt erop dit dit eigenlijk altijd binnen korte of langere termijn leidt tot een reset van de esp8266.

Als ik dan esp.getResetReason() opvraag krijg ik deze output

code:

Fatal exception:4 flag:1 (Hardware Watchdog) epc1:0x40102fe5 epc2:0x00000000 epc3:0x00000000 excvaddr:0x00000000 depc:0x00000000

Alleen ik kan niet echt herleiden wat nu precies de oorzaak is. Ik heb al verschillende esp's geprobeerd, dus het lijkt me geen daadwerkelijk hardware probleem. Als de koffiemachine uitstaat (er staan dan wel spanning op de esp8266) kan het apparaat een hele tijd draaien zonder reset, dus het lijkt te maken te hebben met zodra er daadwerkelijk data binnenkomt.

Concreet heb ik 2 vragen

1. Is mijn manier van 'doorsturen' van seriële data via softwareserial een ok-oplossing?
2. Wat kan de oorzaak zijn van het resetten van de esp via de watchdog?

[septillion]

@bartbh Over wat voor baudrate hebben we het?

En moet je beide kanten (dus display en main board) zowel zenden als ontvangen?

[bartbh]

@septillion Baudrate van 115200.

Het is alleen ontvangen vanaf het display. De TX vanaf de body is aangesloten op de RX van zowel de esp als op de RX van het display.

Schematische poging:

code:

[display] TX ---->   RX(software)   [ESP]   TX ---->  RX [main]
                                            RX  <---  TX
           RX  <------------------------------------|^

Het is qua aansluiting hierop gebaseerd

[septillion]

@bartbh 115200 is vaak wel pittig voor SoftSerial....

Neem even aan dat er een foutje in het schema staat en dat de klassieke verwisseling van Rx en Tx op het main board. Of het is mooie onhandige labeling

Dus je wilt alleen naar de Txo van het display luisteren en dat doorsturen naar de Rxi van het main board? Wat het main board tegen het display roept wil je niet weten? Dan zou je namelijk ook gewoon af kunnen met een enkele Serial waarvan je de Rxi voor het display gebruikt en de Txo naar het main board stuurt.

En klein dingetje nog, gezien de rest op 5V werkt, is het serial signaal wel 3v3? ESP is niet 5V tolerant.

[jantje112]

Een forumlid heeft mij geholpen om met deze software mijn abb/powerone uit te lezen. Dit bevalt erg goed.

https://github.com/michelsciortino/esphome-aurora-inverter

Ik zou ook een upload willen naar pvoutput. Zoals bijvoorbeeld in deze code..

https://github.com/jantenhove/GoodWeLogger

Is dit (eenvoudig) te combineren? Beide omvormers gebruiken rs485 (modbus?)

[Albert_x]

bartbh schreef op woensdag 15 maart 2023 @ 17:45:

code:

  while (swSer.available() > 0) {
    Serial.write(swSer.read());
  }

Echter als het apparaat aanstaat, komt er een constante stroom data vanaf het display. Dit resulteert in een constante stroom van data (opvragen van status-updates). Het lijkt erop dit dit eigenlijk altijd binnen korte of langere termijn leidt tot een reset van de esp8266.

Als ik die "constante stroom data" letterlijk neem, kan het zijn dat je esp continue in de while loop blijft hangen. Dan worden de normale esp house keeping taken niet uitgevoerd en dus ook de wdt niet gereset.
Dat kan je oplossen door een yield() in de while loop op te nemen.

code:

  while (swSer.available() > 0) {
    Serial.write(swSer.read());
    yield();
  }

Van arduino.cc:

Scheduler - yield()


Passes control to other tasks when called. Ideally yield() should be used in functions that will take awhile to complete.

[bartbh]

septillion schreef op woensdag 15 maart 2023 @ 20:51:
@bartbh 115200 is vaak wel pittig voor SoftSerial....

Volgens de docs zou t/m 115200 nog moeten kunnen of zit ik daarmee al aan de max?

Neem even aan dat er een foutje in het schema staat en dat de klassieke verwisseling van Rx en Tx op het main board. Of het is mooie onhandige labeling

Dus je wilt alleen naar de Txo van het display luisteren en dat doorsturen naar de Rxi van het main board? Wat het main board tegen het display roept wil je niet weten? Dan zou je namelijk ook gewoon af kunnen met een enkele Serial waarvan je de Rxi voor het display gebruikt en de Txo naar het main board stuurt.

Plaatje is niet van mij. Doel is om zowel via display (met input buttons) als via esp8266 de status uit te lezen en input te geven.

Daarom gaat de Tx van het main board naar zowel het display als ook naar de esp8266. Dus 1 TX naar 2RX.

Daarnaast gaat dus de TX van het display (met de input commands van de buttons) naar de RX van SoftwareSerial. En dan via de TX van de esp8266 naar de RX van het main board.

Deze oplossing werkt an sich prima. Ik kan de status uitlezen via de esp8266 én input geven via zowel display/buttons als via de esp8266. Punt is dat de esp8266 dus zichzelf reset 1x in de zoveel tijd waardoor deze even niet reageert. Ergens verslikt ie zich dus in. En als de esp zich verslikt en opnieuw opstart wordt dus ook de data vanaf het display/buttons niet meer doorgestuurd en is het hele apparaat voor een paar seconden even niet te bedienen.

Alleen hoe lang de esp blijft draaien heb ik nog geen goed patroon in kunnen ontdekken. Dat kan 5-15 seconden zijn maar soms ook wel 5 min of meer.

En klein dingetje nog, gezien de rest op 5V werkt, is het serial signaal wel 3v3? ESP is niet 5V tolerant.

Zowel met 5v als met een logic level converter er tussen: de oplossing werkt wel maar de esp8266 blijft zichzelf af en toe resetten.

Albert_x schreef op woensdag 15 maart 2023 @ 21:56:
[...]


Als ik die "constante stroom data" letterlijk neem, kan het zijn dat je esp continue in de while loop blijft hangen. Dan worden de normale esp house keeping taken niet uitgevoerd en dus ook de wdt niet gereset.
Dat kan je oplossen door een yield() in de while loop op te nemen.

code:

  while (swSer.available() > 0) {
    Serial.write(swSer.read());
    yield();
  }

Van arduino.cc:

[...]

De webinterface van de esp werkt wel, dus dan ga ik er vanuit dat deze zich niet verslikt in de while loop?

[ThinkPad]

ThinkPad in "Datalogging: PV systemen" Sonoff POW R2 rechtstreeks laten uploaden naar PVOutput

Het lijkt er alleen op dat met if upsecs%300==0 het commando twee keer wordt gerund. Vermoedelijk omdat hij alleen kijkt naar de seconden en niet ook de miliseconden.

Iemand wat meer ervaring met de Tasmota scripting engine die weet hoe ik dat kan voorkomen?
Ik heb ook if uptime%5==0 geprobeerd (minutes since start), maar dan triggert het script continu

https://tasmota.github.io...nguage/#special-variables

[Voor 66% gewijzigd door ThinkPad op 16-03-2023 11:53]

[Albert_x]

bartbh schreef op donderdag 16 maart 2023 @ 00:12:
De webinterface van de esp werkt wel, dus dan ga ik er vanuit dat deze zich niet verslikt in de while loop?

Als je zeker weet dat de webinterface ook de laatste 8 sec voor de reset nog werkte niet nee. Dat is de timeout van de hardware watchdog.

[septillion]

@bartbh Toen ik met een P1 meter aan het spelen was zag ik op 115200 baud toch af en toe bitjes omvallen met SoftSerial. Jammer dat de tweede UART op de ESP8266 juist niet kan ontvangen maar alleen zenden in de standaard config Zou ik zeker kijken of de bus met meeste data op de hardware serial te zetten en de ander op de software.

Maar begin toch te twijfelen of dat echt de reden van reset is. Draait je ESP echt alleen die forward while of nog meer? Anders denk ik niet dat het de SoftSerial is die voor problemen zorgt maar simpelweg een ander deel van je programma zodra dat werkelijk data te verwerken krijgt. En dat er dan ergens lang in een functie gehangen wordt ipv weer naar loop() te gaan.

Paar vuistregels:
- Geen delay() (ook al doet die op een ESP standaard wel yield() volgens mij)
- Voorzichtig met while() (maar eigenlijk alle loops), alleen toepassen als je weet dat je altijd snel er doorheen bent
- Gebruik de loop() werkelijk om te loopen, dus zorg dat je niet in een functie blijft hangen. Heb je veel te doen, maak dan een state machine en keer terug naar loop() en ga de volgende keer weer verder waar je was.

Overigens was de opmerking over 5V niet zo zeer voor het crashen. Maar dat de ESP er gewoon niet voor gemaakt is, level shifter toepassen van 5V => 3v3 is dus wel verplicht. Ook al hebben genoeg mensen laten zien dat hij niet gelijk stuk gaat maar door een chip buiten spec te gebruiken ka n je mooie spook zaken krijgen, zeker op lange termijn.

[Raymond P]

@ThinkPad Je kunt upsecs naar een variabele schrijven en een logic compare doen. Of gaat dat niet met enkel Rules?

[septillion]

ThinkPad schreef op donderdag 16 maart 2023 @ 11:35:
ThinkPad in "Datalogging: PV systemen" Sonoff POW R2 rechtstreeks laten uploaden naar PVOutput

Het lijkt er alleen op dat met if upsecs%300==0 het commando twee keer wordt gerund. Vermoedelijk omdat hij alleen kijkt naar de seconden en niet ook de miliseconden.

Iemand wat meer ervaring met de Tasmota scripting engine die weet hoe ik dat kan voorkomen?
Ik heb ook if uptime%5==0 geprobeerd (minutes since start), maar dan triggert het script continu

https://tasmota.github.io...nguage/#special-variables

code:

>D 42
;long string required for key
y=0
m=0
d=0
b=0
key="Your-API-key"
id="Your-System-ID"
ws="WebSend [pvoutput.org]"
et=0
p=0
vlt=0

>T
et=((ENERGY#Total)*1000)
p=ENERGY#Power
vlt=ENERGY#Voltage
; every 5 minutes
if upsecs%300==0
and b==0
then
b=1
y=sb(tstamp 0 4)
m=sb(tstamp 5 2)
d=sb(tstamp 8 2)
=>%ws%/service/r2/addstatus.jsp?key=%key%&sid=%id%&d=%1.0(y)%%2.0(m)%%2.0(d)%&t=%1(sb(tstamp 11 5))%&v1=%s(2.0et)%&v2=%s(2.0p)%&v6=%s(2.0vlt)%&c1=2
else
b=0
endif

@ThinkPad Denk dat zoiets er wel voor moet zorgen dat hij niet twee keer getriggerd kan worden doordat hij snel genoeg (aka, binnen een seconde) weer loopt. Weet alleen niet of de variabele static zijn dus nog hun waarde hebben de volgende loop? Of is daarvoor een "permanent variable" voor nodig?

[Voor 29% gewijzigd door septillion op 16-03-2023 15:08]

[Tim_bots]

@septillion @bartbh. Ondanks dat een ESP8266 officieel een 3V3 IC is (en een level shifter dus wel degelijk nodig is om van 3V3 naar 5V te komen), zijn de inputs wel degelijk 5V tolerant.
Bron:
https://www.qworqs.com/20...-yes-they-officially-are/
https://www.facebook.com/...33731442/?hc_location=ufi (facebook post van de oprichten van espressif)

[septillion]

@Tim_bots Mja, ben niet van de "het stond op Facebook dus het is waar".... Datasheet is er duidelijk over iig.

[bartbh]

@septillion de esp draait (natuurlijk ) meer dan alleen dat. In mijn eigen versie serveert de esp ook de webinterface. Daarnaast kun je ook een wens (1 kop koffie) ingeven en gaat de esp zelf net zo vaak het commando koffie/water/sterkte sturen zodat het overeenkomt je wens en start daarna met koffiezetten. Doel ervan is om geheel geautomatiseerd koffie te zetten.

Om te testen heb ik ook even de sketch van mijn inspiratie geladen (https://github.com/chris7...ESP8266/withWebserver.cpp) maar daar treed hetzelfde probleem in op.

Om dat uit te sluiten zal ik denk ik eens 3 dingen doen

1. yield() toevoegen in de loop
2. de while loop tijdelijk uitschakelen
3. een sketch maken met daarin alleen de while loop voor het doorsturen van de serial input
(4). de soft en hard serial eens omwisselen


@Albert_x Nee, niet 100% zeker. De webinterface is dan ook even non-responsive en durf eerlijk niet te zeggen of dat inderdaad rond die 8 seconden is. Dus ik ga zeker yield() eens toevoegen.


edit: nabrander
Zou een ESP32 nog verschil kunnen maken?

[Tim_bots]

@septillion, Dat snap ik. In dit geval is het alleen wel de oprichter van espressif die de opmerking maakt. Daarnaast heeft de community nog wat extra testen gedaan. https://hackaday.com/2022...is-curve-tracer-says-yes/

[Albert_x]

bartbh schreef op donderdag 16 maart 2023 @ 13:29:

edit: nabrander
Zou een ESP32 nog verschil kunnen maken?

Ja, die heeft twee hardware uarts dus dan heb je die softwareserial niet nodig...

[Tim_bots]

Albert_x schreef op donderdag 16 maart 2023 @ 13:35:
[...]

Ja, die heeft twee hardware uarts dus dan heb je die softwareserial niet nodig...

Sterker nog. De ESP32 heeft 3 UARTs. Standaard zijn er echter maar 2 bruikbaar.
Echter omdat de ESP32 een IO matrix aan boord heeft kun je middels code de poorten verplaatsen. Als je in de setup() methode Serial.begin() aanroept met de gewenste pinnen als argumenten dan kun je de pinnen aanpassen naar wens.*

code:

    //Set the serial 0 port to 9600 baud on pins 2 and 4
    Serial1.begin(9600, SERIAL_8N1, 2, 4);
    //Set the serial 1 port to 9600 baud on pins 15 and 0
    Serial1.begin(9600, SERIAL_8N1, 15, 0);
    //Set the serial 1 port to 9600 baud on pins 32 and 33
    Serial1.begin(9600, SERIAL_8N1, 33, 32);

bron: https://microcontrollersl...mmunication-pins-example/
*de pinnen 35, 36, 37 and 39 zijn "input only". (zie https://randomnerdtutoria...2-pinout-reference-gpios/)
Mocht je toch een output pin op een input only pin aansluiten zal de ESP vanzelf een foutmelding genereren in de seriële log.

[septillion]

ESP32 heeft inderdaad een UART meer en feitelijk twee meer doordat ze te mappen zijn.

Maar denk dus niet dat daar het probleem zit, denk dat het programma zich ergens anders ophangt als er daadwerkelijk data te verwerken valt.

[ThinkPad]

septillion schreef op donderdag 16 maart 2023 @ 13:02:
[...]

code:

>D 42
;long string required for key
y=0
m=0
d=0
b=0
key="Your-API-key"
id="Your-System-ID"
ws="WebSend [pvoutput.org]"
et=0
p=0
vlt=0

>T
et=((ENERGY#Total)*1000)
p=ENERGY#Power
vlt=ENERGY#Voltage
; every 5 minutes
if upsecs%300==0
and b==0
then
b=1
y=sb(tstamp 0 4)
m=sb(tstamp 5 2)
d=sb(tstamp 8 2)
=>%ws%/service/r2/addstatus.jsp?key=%key%&sid=%id%&d=%1.0(y)%%2.0(m)%%2.0(d)%&t=%1(sb(tstamp 11 5))%&v1=%s(2.0et)%&v2=%s(2.0p)%&v6=%s(2.0vlt)%&c1=2
else
b=0
endif

@ThinkPad Denk dat zoiets er wel voor moet zorgen dat hij niet twee keer getriggerd kan worden doordat hij snel genoeg (aka, binnen een seconde) weer loopt. Weet alleen niet of de variabele static zijn dus nog hun waarde hebben de volgende loop? Of is daarvoor een "permanent variable" voor nodig?

Goed idee, maar helaas. Blijkbaar is de trigger gewoon te snel, dat hij binnen één seconde al twee keer kan triggeren.

Ik heb ook geprobeerd met een timer die op 300 staat en die ik elke seconde met -1 verlaag. Maar ik zie via een print dat de -1 actie alsnog 2x per seconde gedaan wordt. Heel accuraat is die methode dus ook niet

[Voor 160% gewijzigd door ThinkPad op 16-03-2023 15:09]

[septillion]

@ThinkPad Als hij nu nog te snel is dan zijn de variabele denk ik niet static tussen de runs van het script. Ofwel, dan is hij bij elke run 0. Mij is even niet duidelijk of een "permanent variable" een static var is die wel bewaard blijf tussen runs.

Verwachting is dat dit niets meer post:

code:

>D 42
;long string required for key
y=0
m=0
d=0
b=1
key="Your-API-key"
id="Your-System-ID"
ws="WebSend [pvoutput.org]"
et=0
p=0
vlt=0

>T
et=((ENERGY#Total)*1000)
p=ENERGY#Power
vlt=ENERGY#Voltage
; every 5 minutes
if upsecs%300==0
and b==0
then
b=1
y=sb(tstamp 0 4)
m=sb(tstamp 5 2)
d=sb(tstamp 8 2)
=>%ws%/service/r2/addstatus.jsp?key=%key%&sid=%id%&d=%1.0(y)%%2.0(m)%%2.0(d)%&t=%1(sb(tstamp 11 5))%&v1=%s(2.0et)%&v2=%s(2.0p)%&v6=%s(2.0vlt)%&c1=2
else
b=0
endif

En om permanent variable te doen:

code:

>D 42
;long string required for key
y=0
m=0
d=0
p:b=0
key="Your-API-key"
id="Your-System-ID"
ws="WebSend [pvoutput.org]"
et=0
p=0
vlt=0

>T
et=((ENERGY#Total)*1000)
p=ENERGY#Power
vlt=ENERGY#Voltage
; every 5 minutes
if upsecs%300==0
and b==0
then
b=1
y=sb(tstamp 0 4)
m=sb(tstamp 5 2)
d=sb(tstamp 8 2)
=>%ws%/service/r2/addstatus.jsp?key=%key%&sid=%id%&d=%1.0(y)%%2.0(m)%%2.0(d)%&t=%1(sb(tstamp 11 5))%&v1=%s(2.0et)%&v2=%s(2.0p)%&v6=%s(2.0vlt)%&c1=2
else
b=0
endif

En nu ik zit te lezen, is het niet makkelijker het van >T naar >S te verplaatsen, dat wordt überhaupt maar 1x per seconde doorlopen.

[ThinkPad]

septillion schreef op donderdag 16 maart 2023 @ 15:18:
[...]
En nu ik zit te lezen, is het niet makkelijker het van >T naar >S te verplaatsen, dat wordt überhaupt maar 1x per seconde doorlopen.

Uiteindelijk bleek dit de oplossing De extra boolean in de 'if' bleek niet nodig.
Ik moest overigens wel de ENERGY variabelen nog onder >T houden, anders kende hij ze niet. Heb het originele script bijgewerkt: ThinkPad in "Datalogging: PV systemen"

[Voor 4% gewijzigd door ThinkPad op 16-03-2023 16:40]

[bartbh]

@septillion en @Albert_x

Ik heb hele simpele sketch gemaakt met daarin alleen de SwSerial die de inkomende data 1 op 1 doorstuurt en 1 pin hoog zet.

C++:

#include <SoftwareSerial.h>
#define D7 (5) //Gnd for display 
SoftwareSerial swSer (4, 12);


void setup() {

    //HW serial
    Serial.begin(115200);

    //SW serial
    swSer.begin(115200);

    Serial.println("");
    Serial.println("Reset cause:");
    Serial.println(ESP.getResetInfo());

    pinMode(D7, OUTPUT);
    digitalWrite(D7, HIGH);
}

void loop() {
  while (swSer.available() > 0) {
    Serial.write(swSer.read());
    yield();
  }
}

Op de serial monitor zie ik heel veel gibberish voorbij komen, maar ook een reset van de esp.

code:

21:21:23.987 -> 
21:21:23.987 -> wdt reset
21:21:23.987 -> load 0x4010f000, len 3584, room 16 
21:21:24.007 -> tail 0
21:21:24.007 -> chksum 0xb0
21:21:24.007 -> csum 0xb0
21:21:24.007 -> v2843a5ac
21:21:24.007 -> ~ld
21:21:24.095 -> 
21:21:24.095 -> Reset cause:
21:21:24.095 -> Fatal exception:4 flag:1 (Hardware

Moet ik het dan toch hardwarematig zoeken? Ik heb al meerdere eps8266's geprobeerd.

[septillion]

@bartbh En dat krijg je dan meerdere keren spontaan? Er hangt nu wel iets aan dat data stuurt?

Gebruik je van alles de laatste versie? Dus Arduino, board def en SoftSerial? Nu moet ik zeggen dat ik nog ben blijven hangen bij Arduino 1.8.13 maar goed, dat zou je ook kunnen proberen.

Andere kant zou ik eens naar de voeding kijken, hoe voedt je de boel nu? Is het een losse ESP of een module zoals een WeMos?

[Albert_x]

@bartbh ZIe je behalve gibberish ook wel eens geldige data voorbijkomen?
Naast de voeding die septillion al noemde zou ik ook gaan denken aan het koffiezetapparaat. Komt daar wel geldige seriële data uit? Hoe zeker weet je dat het 115200 baud, 8N1 is? Misschien geïnverteerd?

Aan de software kant kan je nog een paar dingen proberen:
- naast de yield ook een expliciete reset van de wdt met ESP.wdtFeed();
- data sneller naar je computer doorsturen, bijv dubbele snelheid
- puur om te testen, data helemaal niet doorsturen

Wat zie je overigens net voor de wdt reset op de seriele monitor. Is die echt 8 seconde stil?

[bartbh]

@septillion
De hardwarematige setup is gelijk gebleven. Dus het display hangt eraan een functioneert. Daarmee spuugt ie dus ook constant data uit (status-update requests). En dan krijg ik dus inderdaad meerdere keren spontaan de reboot

Ik zat nog op 1.8.9 maar heb zojuist alles bijgewerkt naar de laatste versie. Dus Arduino 2.0.4 en alle libraries bijgewerkt, helaas geen verschil.

Voeding is parasitair, dus voeding vanaf het main body op de vcc. Ik heb ook al eens een extra usb adapter aangesloten voor extra voeding, maar dat is het ook niet.

@Albert_x
Nee, als ik de ruwe data voorbij zie komen in de serial monitor zie ik alleen maar gibberisch. Maar in de daadwerkelijke sketch wordt de ontvangen input omgezet. Alleen begrijp ik zelf niet zo goed wat daar precies gebeurt. Alleen dat het daarna een voor mij 'leesbare code' oplevert. De ontvangen serial data van het display wordt dan in een char 'gedrukt'

code:

    char b = Serial.read();
    sprintf(&serInCommand[serInIdx], "%02x", b);
    serInIdx += 2;

Dit is de request die het beeldscherm maakt om een nieuwe status op te vragen.

code:

byte requestInfo[] =  {0xD5, 0x55, 0x00, 0x01, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x01, 0x14};

Maar dat staat los van de reset lijkt me. In mijn simpele test sketch werkt de bediening van het koffieapparaat wel. Dus de ontvangen data wordt netjes doorgestuurd naar de main van het apparaat. In mijn daadwerkelijke sketch werkt het allemaal ook. Dus ik kan daar de status uitlezen en het apparaat bedienen. Alleen de esp8266 reset zich dus op onregelmatige momenten. Hij kan het dus ook prima langere tijd (dus ruim langer dan 8 seconden, eerder 20-200 seconden) volhouden.

edit: ik kan dus niet precies triggeren of voorspellen wanneer de esp8266 zich reset. Dat lijkt vooralsnog vrij random. Dat kan kort zijn maar ook wat langere met daarin veel input (dus te verwerken data).

edit2:

Albert_x schreef op donderdag 16 maart 2023 @ 22:57:
@bartbh ZIe je behalve gibberish ook wel eens geldige data voorbijkomen?

Aan de software kant kan je nog een paar dingen proberen:
1. naast de yield ook een expliciete reset van de wdt met ESP.wdtFeed();
2. data sneller naar je computer doorsturen, bijv dubbele snelheid
3. puur om te testen, data helemaal niet doorsturen

1. Dat zal ik nog eens meenemen. > Getest: help niet helaas.
2. Volgens mij kan ik dat niet veranderen, ik zit vast aan de 115200 van het display<>body vast.
3. Dat kan inderdaad ook nog.

[Voor 18% gewijzigd door bartbh op 17-03-2023 00:24]

[JBS]

Conform deze opzet heb ik al wat jaren m'n domme deurbel slim gemaakt. Dat werkt perfect. Wanneer de ESP echter geen verbinding kan maken (dat gebeurde toevallig van de week tijdens een, gelukkig zeldzaam, issue met de verbinding, gaat ie periodiek herstarten. Prima, maar de relay schakelt een fractie van een seconde tijdens deze reboot, wat een korte rinkel van de deurbel gong betekent.

Iets met restore_mode toevoegen lost dit echter niet op:

YAML:

  - platform: gpio
    id: relay
    inverted: true
    restore_mode: RESTORE_DEFAULT_OFF
    name: ${display_name} Chime
    pin: GPIO0

Iemand dit klikken van de relay bij een reboot wel succesvol kunnen voorkomen?

[Tinusvolkel]

JBS schreef op vrijdag 17 maart 2023 @ 11:40:
Conform deze opzet heb ik al wat jaren m'n domme deurbel slim gemaakt. Dat werkt perfect. Wanneer de ESP echter geen verbinding kan maken (dat gebeurde toevallig van de week tijdens een, gelukkig zeldzaam issue, met de verbinding, gaat ie periodiek herstarten. Prima, maar de relay schakelt een fractie van een seconde tijdens deze reboot, wat een korte rinkel van de deurbel gong betekent.

Iets met restore_mode toevoegen lost dit echter niet op:

YAML:

  - platform: gpio
    id: relay
    inverted: true
    restore_mode: RESTORE_DEFAULT_OFF
    name: ${display_name} Chime
    pin: GPIO0

Iemand dit klikken van de relay bij een reboot wel succesvol kunnen voorkomen?

Zit er een pullup op GPIO0? want op die pin zit dacht ik ook de flash button.
Dus misschien kan je het op een andere GPIO testen?

[septillion]

bartbh schreef op donderdag 16 maart 2023 @ 23:54:
@septillion
De hardwarematige setup is gelijk gebleven. Dus het display hangt eraan een functioneert. Daarmee spuugt ie dus ook constant data uit (status-update requests). En dan krijg ik dus inderdaad meerdere keren spontaan de reboot

Doelde dus niet of hij gelijk gebleven is of niet maar waar hij uit bestaat. Is het een ESP module incl spanningsregeling of een losse ESP? Neem even aan een module als een WeMos?

Ik zat nog op 1.8.9 maar heb zojuist alles bijgewerkt naar de laatste versie. Dus Arduino 2.0.4 en alle libraries bijgewerkt, helaas geen verschil.

Belangrijkste mis ik dan nog in het rijtje, de board definities, die doen het wekelijke compilen. Alle versies echt benoemen is altijd handig als mensen het ook willen testen.

"Gibberisch" lijkt me normaal, de communicatie is geen ASCII maar gewoon geoptimaliseerde datapakketjes. Maar zie je met de simpele sketch ook werkelijk de rest ("Reset cause: " over de serial) voorbij komen spontaan? Je post het namelijk maar een enkele keer.

En met de simpele sketch, wat gebruik je dan op de PC? Dat kan namelijk ook een reset geven. Net als dat het hebben verbonden van een USB kabel meedoet met de voedingsspanning. Wil je dat niet zal je even met een losse USB-Serial adapter mee moeten luisteren.

[septillion]

@JBS en @Tinusvolkel GPIO0 is inderdaad de flash en zou dus hoog moeten zijn tijdens boot. Maar ik zie de pin als inverted staan dus juist hooggetrokken zou de bel stil moeten zijn.

Enige wat ik me dan kan bedenken is dat ESPhome de pinMode() en digitalWrite() (on in Arduino verkeerdom doet bij inverted. Dan zou je dit gedrag ook moeten hebben op een andere GPIO. Door de complexe opzet van ESPhome alleen geeeeen idee of het Dat zou helaas wel betekenen dat het niet is op te lossen voor een active low relais module.

[ThinkPad]

Ben m'n PVOutput upload script in Tasmota nog wat verder aan het optimaliseren. Volgens mij heb ik een vreemde bug gevonden in Tasmota. Hij lijkt niet goed om te gaan met het vergelijken van de tijd t.o.v. sunrise/sunset

Als ik op dit moment (21:50) een conditie erin heb staan om te bepalen of het dag is:
if time>sunrise and time<sunset dan evalueert deze als true, terwijl ik false zou verwachten.

Edit 7:52: om te testen nog even wat debugging geprint:
>S
print Time is %time% Sunrise is at %sunrise%, sunset is at %sunset%.
if time>sunrise
print tijd groter dan sunrise 1
endif
if time<sunrise
print tijd kleiner dan sunrise 2
endif
if time<sunset
print tijd kleiner dan sunset 3
endif
if time>sunset
print tijd groter dan sunset 4
endif

07:52:32.658 Time is 472.00 Sunrise is at 400.00, sunset is at 1133.00. 
07:52:32.661 tijd groter dan sunrise 1
07:52:32.664 tijd kleiner dan sunrise 2
07:52:32.667 tijd kleiner dan sunset 3
07:52:32.669 tijd groter dan sunset 4

Alle 4 de if's valideert hij vrolijk als true

Iemand een idee wat hier misgaat? De tijden die hij teruggeeft kloppen verder wel trouwens (zijn het aantal minuten vanaf middernacht).

[Voor 46% gewijzigd door ThinkPad op 21-03-2023 08:01]