Het grote ESP topic

[lubbertkramer]

Tanuki schreef op zondag 3 december 2023 @ 20:40:
[...]

Kan je niet gewoon met esptool de esp uitlezen? Volgens mij staat in die info o.a. de grootte van de flash enz, en ook wat info over de cpu. Mogelijk ook het aantal cores?

Is beter dan het ding open forceren.

Dat ik dat zelf niet eerder bedacht, waarom altijd moeilijk denken vraag je je dan af Maar inmiddels kunnen bevestigen dat mijn batch van vorig jaar BF single core is (dual core werd sinds 09-20-22 verkocht) en die van dit jaar allemaal dual core Zoals @ Esphome beschreven dezelfde chip en had ik alleen het verschil gezien tussen HXXXXX of DHXXXXX als ik hem had opengemaakt

Detecting chip type... ESP32
Chip is ESP32-U4WDH (revision 3)
Features: Wi-Fi, BT, Single Core, Embedded Flash, VRef calibration in efuse, Coding Scheme None

en

Chip is ESP32-U4WDH (revision 3)
Features: Wi-Fi, BT, Dual Core, 240MHz, Embedded Flash, VRef calibration in efuse, Coding Scheme None

[ Voor 14% gewijzigd door lubbertkramer op 03-12-2023 22:41 ]

[Repsect]

Ik wil ESPHome installeren op een ESP-12S WiFi module. Ik heb hiervoor inmiddels twee verschillende USB-to-serial adapters geprobeerd basis van de CP340 en CP2102 chips.

Het aansluiten om te kunnen flashen zou enkel -als ik het goed begrepen heb- de 3.3V, GND, TX en RX aangesloten moeten worden wat ik ook gedaan heb. Tevens heb ik aan de RST een draadje gesoldeerd zodat ik deze met de GND kan verbinden om een reset uit te kunnen voeren.

Ik maak gebruik van de ESP web tool en ik kan de juiste COM poort selecteren. Vervolgens klik ik op "Prepare for first use" waarna er geprobeerd wordt een verbinding te maken. Helaas lukt dit niet. Ik zie echter wel de TX en RX LEDs knipperen op de USB-to-serial adapter.

Ik heb meerdere malen de reset verbonden, zowel tijdens als voor het verbinden, maar zonder resultaat.

Ik kan via de Arduino IDE wel gewoon de seriële monitor openen en AT commando's versturen. Ook lukt het op die manier om de ESP-12S te verbinden met mijn WiFi netwerk. Maar ESPHome flashen is me dus nog niet gelukt.
Inmiddels heb ik de chip naar fabrieksinstellingen teruggezet met de AT+RESTORE commando.

Iemand een tip om ESPHome te installeren evt. via een andere weg?

[Raymond P]

@Repsect Om in flash mode te booten moet gpio0 sowieso laag getrokken worden tijdens reset.

Daarbuiten zijn er nog wat pins die een specifieke state vereisen.

[Septillion]

@Repsect Je moet wel de juiste boot-mode selecteren, en of je die nu selecteert wanneer je hem power geeft of via een reset maakt niet uit (aka, reset is wel de laatste die je echt nodig hebt).
GPIO0 @ GND
GPIO2 @ Vcc
GPIO15 @ GND

Gezien de laatste twee ook die state moeten hebben voor normale boot zijn die dat waarschijnlijk al en moet je dus alleen GPIO0 laag trekken. En als je zelf een printje maakt, plaats een auto-reset circuitje

Als ik klooi met een ESP8266 dan heb ik eigenlijk altijd de Beginner's Guide to the ESP8266 open.

[Repsect]

Thanks @Raymond P en @Septillion! Het was inderdaad GPIO0 die naar GND moest. Flashen ging daarna in een keer goed. Kan ik weer verder met m’n projectje .

[Tanuki]

Zijn er goede "shields" (zo heet dat toch?) om op een mooie manier een max485 (modbus) aan te sluiten op een esp32? En de esp32 ook "op zijn kop" te kunnen aansluiten met schroefgaatjes?

Ik heb wel een shield gevonden voor de esp32 waarmee dat kan. Maar nog geen shield waar dan ook een max485 meteen op geprikt kan worden.

Ik was in ieder geval niet van plan om het zelf te designen.

Overigens wel een shield gevonden voor een wemos (esp8266). Maar ik heb dus een esp32-wroom.

[Raymond P]

@Tanuki Als je Lego wilt dan is het handiger om een ecosysteem te kiezen dat daarin faciliteert.
Bijvoorbeeld Adafruit Feather, Grove modules of Wemos hebben een hoop dingetjes die je kunt stapelen en/of makkelijk kunt verbinden zolang je binnen die platformen shopt.

De wemos bordjes 8266/32 zijn pin-compatible met hun shields.

[heintjeput]

Ik ken er geen, dus ik heb laatst zelf maar een bordje ontworpen. Als je een modus-rs485 koopt zorg wel dat je de 3.3V unit koopt, anders werkt het niet. Ik vond het wel nog deze dus misschien is dat wat voor je.

[sypie]

Ik ben voor mijn zoontje een projectje aan het doen. Ik wil met 2 setjes Ikea Ravunge op een grote plaat hout een mooi stukje weg maken. Daar moeten natuurlijk stoplichtjes bij, die heb ik inmiddels ook in huis.

2 Stoplichtjes werkend maken lukt me prima. Even wat nadenken en gaan. Ik ga zo de derde er bij proberen te maken, kijken of ik die ook netjes in mijn programma kan krijgen. Zo breid ik stapje voor stapje wat uit. Het is vooral mijn eigen logische nadenken.

Waar ik nu even mee zit is dat ik straks iets met een drukknopje wil doen, voor de voetgangers. Die moet dan na X-seconden het programma wijzigen en een eigen loop doorlopen. Daarna weer verder gaan met het normale programma.

Mijn vraag is: naar welke functie moet ik op zoek om dit voor elkaar te krijgen? Is dat een "for loop"?

Misschien zijn er nog tips voor de huidige code die ik voor een T-splitsing gebruik? 1 en 2 gaan rechtdoor, 3 is het pootje van de T.

code:

//Define LEDs
const int red1 = 23;
const int yellow1 = 22;
const int green1 = 21;
const int green2 = 32;
const int yellow2 = 33;
const int red2 = 25;
const int red3 = 12;
const int yellow3 = 13;
const int green3 = 14;
const int Pot = 2;



// define time delays
int redtime = 3000;
int yellowtime = 2000;
int greentime = 4000;

void setup() {
  // put your setup code here, to run once:
  pinMode(red1, OUTPUT);
  pinMode(yellow1, OUTPUT);
  pinMode(green1, OUTPUT);
  pinMode(red2, OUTPUT);
  pinMode(yellow2, OUTPUT);
  pinMode(green2, OUTPUT);
  pinMode(red3, OUTPUT);
  pinMode(yellow3, OUTPUT);
  pinMode(green3, OUTPUT);
  pinMode(Pot, INPUT);

  //must initialise pins all as off initally
  initialise_pins();
}

void loop() {
  // put your main code here, to run repeatedly:
  if (digitalRead(Pot) == LOW){
    traffic_light1();
  }

}

// function to initialise pins
void initialise_pins(){
  digitalWrite(green1, LOW);
  digitalWrite(yellow1, LOW);
  digitalWrite(red1, LOW);
  digitalWrite(green2, LOW);
  digitalWrite(yellow2, LOW);
  digitalWrite(red2, LOW);
  digitalWrite(green3, LOW);
  digitalWrite(yellow3, LOW);
  digitalWrite(red3, LOW);
}

// function for traffic lights 1
void traffic_light1(){
 //stap 1
  
  digitalWrite(green1, HIGH);
  digitalWrite(green2, HIGH);
  digitalWrite(red3, HIGH);
  digitalWrite(red1, LOW);
  digitalWrite(red2, LOW);
  digitalWrite(yellow3, LOW);
  
  delay(redtime);
  
  //stap 2
  
  digitalWrite(yellow1, HIGH);
  digitalWrite(yellow2, HIGH);
  digitalWrite(green1, LOW);
  digitalWrite(green2, LOW);

  delay(yellowtime);
  
  //stap 3
  
  digitalWrite(red1, HIGH);
  digitalWrite(red2, HIGH);
  digitalWrite(green3, HIGH);
  digitalWrite(yellow1, LOW);
  digitalWrite(yellow2, LOW);
  digitalWrite(red3, LOW);
  
  delay(yellowtime);

  //stap 4
  
  digitalWrite(yellow3, HIGH);
  digitalWrite(green3, LOW);
  
  delay(greentime);
}

[ Voor 52% gewijzigd door sypie op 28-12-2023 20:59 ]

[ocmer]

sypie schreef op donderdag 28 december 2023 @ 20:17:
Ik ben voor mijn zoontje een projectje aan het doen. Ik wil met 2 setjes Ikea Ravunge op een grote plaat hout een mooi stukje weg maken. Daar moeten natuurlijk stoplichtjes bij, die heb ik inmiddels ook in huis.

2 Stoplichtjes werkend maken lukt me prima. Even wat nadenken en gaan. Ik ga zo de derde er bij proberen te maken, kijken of ik die ook netjes in mijn programma kan krijgen. Zo breid ik stapje voor stapje wat uit. Het is vooral mijn eigen logische nadenken.

Waar ik nu even mee zit is dat ik straks iets met een drukknopje wil doen, voor de voetgangers. Die moet dan na X-seconden het programma wijzigen en een eigen loop doorlopen. Daarna weer verder gaan met het normale programma.

Mijn vraag is: naar welke functie moet ik op zoek om dit voor elkaar te krijgen? Is dat een "for loop"?

Misschien zijn er nog tips voor de huidige code die ik voor een T-splitsing gebruik? 1 en 2 gaan rechtdoor, 3 is het pootje van de T.

code:

//Define LEDs
const int red1 = 23;
const int yellow1 = 22;
const int green1 = 21;
const int green2 = 32;
const int yellow2 = 33;
const int red2 = 25;
const int red3 = 12;
const int yellow3 = 13;
const int green3 = 14;
const int Pot = 2;



// define time delays
int redtime = 3000;
int yellowtime = 2000;
int greentime = 4000;

void setup() {
  // put your setup code here, to run once:
  pinMode(red1, OUTPUT);
  pinMode(yellow1, OUTPUT);
  pinMode(green1, OUTPUT);
  pinMode(red2, OUTPUT);
  pinMode(yellow2, OUTPUT);
  pinMode(green2, OUTPUT);
  pinMode(red3, OUTPUT);
  pinMode(yellow3, OUTPUT);
  pinMode(green3, OUTPUT);
  pinMode(Pot, INPUT);

  //must initialise pins all as off initally
  initialise_pins();
}

void loop() {
  // put your main code here, to run repeatedly:
  if (digitalRead(Pot) == LOW){
    traffic_light1();
  }

}

// function to initialise pins
void initialise_pins(){
  digitalWrite(green1, LOW);
  digitalWrite(yellow1, LOW);
  digitalWrite(red1, LOW);
  digitalWrite(green2, LOW);
  digitalWrite(yellow2, LOW);
  digitalWrite(red2, LOW);
  digitalWrite(green3, LOW);
  digitalWrite(yellow3, LOW);
  digitalWrite(red3, LOW);
}

// function for traffic lights 1
void traffic_light1(){
 //stap 1
  
  digitalWrite(green1, HIGH);
  digitalWrite(green2, HIGH);
  digitalWrite(red3, HIGH);
  digitalWrite(red1, LOW);
  digitalWrite(red2, LOW);
  digitalWrite(yellow3, LOW);
  
  delay(redtime);
  
  //stap 2
  
  digitalWrite(yellow1, HIGH);
  digitalWrite(yellow2, HIGH);
  digitalWrite(green1, LOW);
  digitalWrite(green2, LOW);

  delay(yellowtime);
  
  //stap 3
  
  digitalWrite(red1, HIGH);
  digitalWrite(red2, HIGH);
  digitalWrite(green3, HIGH);
  digitalWrite(yellow1, LOW);
  digitalWrite(yellow2, LOW);
  digitalWrite(red3, LOW);
  
  delay(yellowtime);

  //stap 4
  
  digitalWrite(yellow3, HIGH);
  digitalWrite(green3, LOW);
  
  delay(greentime);
}

Het is beter om niet met delay() te werken; want dan worden dingen al snel lastig. Het kan beter met millis(). Zie https://randomnerdtutoria...e-arduino-delay-function/

Ook zou ik de kleur van het stoplicht als "status" opslaan en op basis van de status de kleuren aansturen. Ook dat de knop is ingedrukt is een status.

Als je dan die statussen combineert met de millis() dan kan je alles netjes automatiseren.

Misschien handig om vooraf een state-model uit te tekenen. Spoiler: https://medium.com/well-r...introduction-b7ac9aaf482e

[ Voor 5% gewijzigd door ocmer op 29-12-2023 08:39 ]

[jomas]

sypie schreef op donderdag 28 december 2023 @ 20:17:
Ik ben voor mijn zoontje een projectje aan het doen. Ik wil met 2 setjes Ikea Ravunge op een grote plaat hout een mooi stukje weg maken. Daar moeten natuurlijk stoplichtjes bij, die heb ik inmiddels ook in huis.

2 Stoplichtjes werkend maken lukt me prima. Even wat nadenken en gaan. Ik ga zo de derde er bij proberen te maken, kijken of ik die ook netjes in mijn programma kan krijgen. Zo breid ik stapje voor stapje wat uit. Het is vooral mijn eigen logische nadenken.

Waar ik nu even mee zit is dat ik straks iets met een drukknopje wil doen, voor de voetgangers. Die moet dan na X-seconden het programma wijzigen en een eigen loop doorlopen. Daarna weer verder gaan met het normale programma.

Mijn vraag is: naar welke functie moet ik op zoek om dit voor elkaar te krijgen? Is dat een "for loop"?

Misschien zijn er nog tips voor de huidige code die ik voor een T-splitsing gebruik? 1 en 2 gaan rechtdoor, 3 is het pootje van de T.

Voor zo een toepassing zou ik Micropython gebruiken in combinatie met asyncio. Je hoeft dan voor een stoplichtengroep maar 1 class te maken en die gebruik je voor een willekeurig aantal stoplichten. Dus voor je programma maakt het dan niet uit of je 1, 2, 1000!!! stoplichten aan wil sturen. Als je asyncio gebruikt hoef je ook geen state diagrammen te gebruiken (want cyclus verloopt altijd volgens vastgesteld patroon). Asyncio zorgt dat alles parallel verloopt. Dus als stoplichtengroep 1 op de helft van z'n cyclus is en voetganger bij stoplichtgroep 2 drukt op de knop dan zullen beide cycli parallel afgewerkt worden.

[sypie]

Hohoho... *merry christmas*. Dat is veel info om te verwerken, als niet programmeur zijnde.

De tip van @ocmer over de millis in plaats van de delays kom ik vast uit. Het uitwerken van een state model gaat wat meer onderzoek vergen. Ik heb even vluchtig de link bekeken en het klinkt nogal begrijpelijk.

@jomas Het stukje over micropython moet ik induiken. Zoals gezegd ben ik geen programmeur maar probeer ik zo eens wat. Over asyncio moet ik helemaal inlezen, nog nooit van gehoord. Dat wordt dus compleet wat nieuws.

Ik ga er mee aan de slag en ga kijken waar ik uit kom.

[Tanuki]

Ik ben wat aan het knutselen met modbus en eastron energie meters. Werkt allemaal netjes, ik kan de modbus informatie uitlezen en zo kWh / V / W / A etc beschikbaar maken in Home Assistant.

Nu is de volgende aan de beurt: Een Zeversolar TL-3000 omvormer (zonnepanelen). Deze heeft een RS485 poort welke werkt met een RJ45 connector:

Ethernet pin	Function
1	TX_RS485A
2	TX_RS485B
3	RX_RS485A
4	GND
5	GND
6	RX_RS485B
7	+7V
8	+7V

Dat betekent dus dat ik 3 paren over houd voor mijn modbus (A+/B-/GND). Volgens mij moet ik dat wel werkend krijgen.

Nu vermoed ik dat pin 7 en 8 dus +7V leveren, enkel als de omvormer aan staat uiteraard (moet ik wel nog verifieren). Dat zou dan betekenen dat ze 0V leveren als de omvormer uit staat. Ik denk dat op dat moment het uitlezen van de registers ook niet werkt.

Ik zou het een nette oplossing vinden, als ik het voor elkaar kan krijgen om die +7V / 0V te kunnen vertalen naar een boolean in ESPHome (of in Arduino code, dan kan ik vanuit daar verder). Maar volgens mij kan ik die pin niet zomaar verbinden met een van de GPIO's van de ESP32. Die zijn geschikt voor 3,3V, niet voor 7V.

Wat zou een goede manier zijn om die pins te kunnen gebruiken als input? Simpelweg een diode erop (bijvoorbeeld) om het voltage naar beneden te brengen lijkt me een minder accurate oplossing (want de kabel zal door de lengte ervan de 7V droppen naar 6,x of 5,x V zelfs).

Ik vraag geen kant en klare oplossing, maar ik weet zeker dat iemand hier al eens eerder zoiets heeft willen doen.

[Raymond P]

@Tanuki Voltage divider.

[vso]

Tanuki schreef op zondag 31 december 2023 @ 13:57:
Wat zou een goede manier zijn om die pins te kunnen gebruiken als input? Simpelweg een diode erop (bijvoorbeeld) om het voltage naar beneden te brengen lijkt me een minder accurate oplossing (want de kabel zal door de lengte ervan de 7V droppen naar 6,x of 5,x V zelfs).

Ik vraag geen kant en klare oplossing, maar ik weet zeker dat iemand hier al eens eerder zoiets heeft willen doen.

een voltage divider als je de variatie tussen +7 en 0v wil lezen, (adc) een aan/uit is 3,3v (weerstand) wellicht voldoende ..

[heintjeput]

Een 50/50 voltage divider, dus bij 5k / 5kOhm geeft je dan 3.5V. Dat zou prima binnen de 3.9V max pin input vallen. En dan kun je het gewoon als digitale pin beschouwen en is het direct een bool.
Ik heb zelf een ESP laten voeden door de omvormer, dus alleen signaal als de omvormer aan staat.

[Tanuki]

Thanks voor de input! Kan ik weer wat google searches aan besteden!

[Tanuki]

heintjeput schreef op maandag 1 januari 2024 @ 10:53:
Een 50/50 voltage divider, dus bij 5k / 5kOhm geeft je dan 3.5V. Dat zou prima binnen de 3.9V max pin input vallen. En dan kun je het gewoon als digitale pin beschouwen en is het direct een bool.
Ik heb zelf een ESP laten voeden door de omvormer, dus alleen signaal als de omvormer aan staat.

Hier heb ik aan gedacht, maar dan is ie dus ook "spontaan" offline zodra de omvormer ermee stopt. En, is hij wellicht aan het knipperen? Ik weet niet precies hoe dat spanningsverloop gaat bij het opstarten/afsluiten. Werkte dat in jouw geval altijd prima?

[heintjeput]

Tanuki schreef op maandag 1 januari 2024 @ 12:37:
[...]

Hier heb ik aan gedacht, maar dan is ie dus ook "spontaan" offline zodra de omvormer ermee stopt. En, is hij wellicht aan het knipperen? Ik weet niet precies hoe dat spanningsverloop gaat bij het opstarten/afsluiten. Werkte dat in jouw geval altijd prima?

Hij gaat dan inderdaad uit. Maar er komt toch geen data meer uit de omvormer, dus dan is het ook geen probleem. Hij lijkt inderdaad soms wel een paar keer aan en uit te gaan bij het opstarten (dat doet de omvormer soms ook op dagen zoals deze), maar ook dat zie ik niet echt als een probleem.
Ik had wel nog een temperatuursensor mee geintegreerd, maar die doet het dus ook alleen als de zonschijnt. Wel scheelt het me weer een adapter / kabel trekken en is daarmee een stuk makkelijker.

[Raymond P]

Tegenwoordig is er een groot aanbod van dev-boards met onboard laadcircuit en li-po aansluiting.
Of met batterijhouder op de achterkant.
Daarmee kan je prima een paar uurtjes semi-inactief overbruggen.

Maar 'gewoon' aan MQTT hangen met LWT en uit laten gaan zou mijn voorkeur hebben als 'ie verder toch niets te doen heeft.

[vso]

ligt het aan platform IO dat een esp32 reboot als het ontwaakt uit deepsleep of is dat esphome / platform IO ?

@Raymond P de tijd dat hij kan overbruggen is toch wel prettig beetje accu--pack met capaciteit is ook wel prettig.

[Raymond P]

@vso Bij deep sleep gaat er prik af van een hoop.
Simpel gezegd: als het niet in RTC memory staat is het foetsie. Een wakeup is dan meestal ook praktisch gelijk aan een reboot.

Accu is altijd tof, maar als een unit geen data te leveren heeft dan is een last will zodat ik weet dat er geen data komt voor mij ook voldoende. Beetje afhankelijk van de toepassing.

[vso]

Raymond P schreef op dinsdag 2 januari 2024 @ 01:18:
@vso Bij deep sleep gaat er prik af van een hoop.
Simpel gezegd: als het niet in RTC memory staat is het foetsie. Een wakeup is dan meestal ook praktisch gelijk aan een reboot.

Accu is altijd tof, maar als een unit geen data te leveren heeft dan is een last will zodat ik weet dat er geen data komt voor mij ook voldoende. Beetje afhankelijk van de toepassing.

voor mij is het meer dat ik niet elke seconde 300 metingen hoef te hebben... waar elke 5 min of 15 min voldoende is

Homeassistant (vandaar esphome) vind echter dat niet altijd, de esp's gaan meteen mekkeren als je hun api gebruikt dat device offline is. Ja dan kan je wel naar MQTT overschakelen

voor nu ben ik me maar eerst aan het focussen op wat ik wil meten in huis, voordat ik wellicht devices ga omgooien naar iets anders bv ESP-NOW dat lijkt beter / efficenter te zijn.

[Raymond P]

@vso Ahja, m'n post was generiek maar meer bedoeld voor (de specifieke case van) @Tanuki.

Er is hier, gelukkig, geen noodzaak om Home Assistant als database te gebruiken. En m'n ervaring met esphome is praktisch niet-bestaand.

[Tanuki]

Hm. Ik kom er nog niet helemaal uit, en dit is misschien ook niet helemaal het juiste topic voor mijn vraag:
Ik heb dus een Zeversolar TL3000 waar een RS485 poort op zit. Ik krijg nu via de netwerkkabel die ik eraan heb gehangen de volgende pins:

Pin1------- TX_RS485A
Pin2-------TX_RS485B
Pin3-------RX_RS485A
Pin4-------GND
Pin5-------GND
Pin6-------RX_RS485B
Pin7-------+7V
Pin8-------+7V

(Komt uit de handleiding van de omvormer)

Nu heb ik een MAX485 adaptertje, exact deze:


Ik vraag me af hoe ik deze nu moet bedraden naar de MAX485 toe. Ik heb geprobeerd pin 1+2 naar A & pin 3+6 naar B te verbinden, ook andersom. En ook pin 1+3 naar A & pin 2+6 naar B en andersom.

Ik ben erg in de war door hoe het in de handleiding van de omvormer staat tov wat ik zie op mijn adaptertje.

Eerst dacht dat ik de omvormer modbus zou spreken, maar volgens mij doet de omvormer gewoon RS485 met een eigen protocol, wat dus niet modbus is.

Ik weet ook niets van de baud rates (ik zie mensen op internet 9600 gebruiken).

Hier zie ik wel wat code: https://github.com/solmol.../blob/master/eversolar.pl Maar dat ben ik dus aan het proberen te vertalen naar Arduino code (om later hopelijk met ESPHome e.e.a. werkend te krijgen).

Dit is me wel gelukt met het uitlezen van mijn SDM meters (Eastron energie meters), dus leek me dit een logisch vervolg. Maar, nu tast ik in het duister. Ik heb helaas ook geen logic analyzer.

Wel meet ik met een multimeter 8,43V op zowel pin 7 als pin 8. En lijkt het te kloppen dat pin 4 en 5 GND zijn. So far so good dus. Maar hoe krijg ik nu een bepaalde communicatie tot stand? En allereerst natuurlijk, hoe verbind ik de draadjes op de juiste manier zodat TX/RX A/B klopt met de A/B op mijn MAX485?

[heintjeput]

Tanuki schreef op dinsdag 2 januari 2024 @ 11:28:
Hm. Ik kom er nog niet helemaal uit, en dit is misschien ook niet helemaal het juiste topic voor mijn vraag:
Ik heb dus een Zeversolar TL3000 waar een RS485 poort op zit. Ik krijg nu via de netwerkkabel die ik eraan heb gehangen de volgende pins:

Pin1------- TX_RS485A
Pin2-------TX_RS485B
Pin3-------RX_RS485A
Pin4-------GND
Pin5-------GND
Pin6-------RX_RS485B
Pin7-------+7V
Pin8-------+7V

(Komt uit de handleiding van de omvormer)

Nu heb ik een MAX485 adaptertje, exact deze:
[Afbeelding]

Ik vraag me af hoe ik deze nu moet bedraden naar de MAX485 toe. Ik heb geprobeerd pin 1+2 naar A & pin 3+6 naar B te verbinden, ook andersom. En ook pin 1+3 naar A & pin 2+6 naar B en andersom.

Ik ben erg in de war door hoe het in de handleiding van de omvormer staat tov wat ik zie op mijn adaptertje.

Eerst dacht dat ik de omvormer modbus zou spreken, maar volgens mij doet de omvormer gewoon RS485 met een eigen protocol, wat dus niet modbus is.

Ik weet ook niets van de baud rates (ik zie mensen op internet 9600 gebruiken).

Hier zie ik wel wat code: https://github.com/solmol.../blob/master/eversolar.pl Maar dat ben ik dus aan het proberen te vertalen naar Arduino code (om later hopelijk met ESPHome e.e.a. werkend te krijgen).

Dit is me wel gelukt met het uitlezen van mijn SDM meters (Eastron energie meters), dus leek me dit een logisch vervolg. Maar, nu tast ik in het duister. Ik heb helaas ook geen logic analyzer.

Wel meet ik met een multimeter 8,43V op zowel pin 7 als pin 8. En lijkt het te kloppen dat pin 4 en 5 GND zijn. So far so good dus. Maar hoe krijg ik nu een bepaalde communicatie tot stand? En allereerst natuurlijk, hoe verbind ik de draadjes op de juiste manier zodat TX/RX A/B klopt met de A/B op mijn MAX485?

Ik zou verwachten dat Pin 1+3 naar A en 2+4 naar B moeten. Heb je aan je ESP wel met de DE / RE verbonden en in je modbus component je flow_control_pin gedefinieerd?

8.4V is trouwens wel wat te veel als je een 1:1 voltage divider gebruikt. Dan moet je wel wat verder omlaag gaan met de spanning.

[Tanuki]

heintjeput schreef op dinsdag 2 januari 2024 @ 11:56:
[...]

Ik zou verwachten dat Pin 1+3 naar A en 2+4 naar B moeten. Heb je aan je ESP wel met de DE / RE verbonden en in je modbus component je flow_control_pin gedefinieerd?

Yes, ik gebruik de flow control pin (nu nog in de Arduino code).

Pin 1 + 3 naar A, en 2+4 naar B lijkt me niet zo'n goed idee? Gezien pin 4 GND is? Maar pin 1+3 naar A en 2+6 naar B heb ik al eens geprobeerd idd.

Ik heb nu in de Arduino code:

code:

// DI -> TX2 (17), DE+RE -> D4 (GPIO4), RO -> RX2 (16)
#define RS_RO 16
#define RS_DI 17
#define RS_DE_RE 4
#define LED_PIN 2

const int RS485_TRANSMIT = HIGH;
const int RS485_RECEIVE = LOW;

void setup() {
  Serial.begin(9600);           // Start the built-in serial port  
  // 9600 baudrate, no parity, 8 bits, 1 stop bit, no handshake, raw datatype
  Serial2.begin(9600, SERIAL_8N1, RS_RO, RS_DI); // RS485 serial
  pinMode(LED_PIN, OUTPUT);     // Configure any output pins
  pinMode(RS_DE_RE, OUTPUT);    
  
  digitalWrite(RS_DE_RE, RS485_RECEIVE);  // Put RS485 in receive mode  
}

void loop() {
  Serial.println("Sending..."); 
  digitalWrite(RS_DE_RE, RS485_TRANSMIT);  // Put RS485 in Transmit mode

  // aa 55 01 00 00 10 11 00 00 01 21
  // Aa 55 01 00 00 00 10 00 00 01 10
  
  // 0xaa 0x55 0x01 0x00 
  // send_request( 0x00, $CTRL_FUNC_CODES{"REGISTER"}{"OFFLINE_QUERY"} )

  // 0xaa 0x55 0x01 (OUR_ADDRESS) 0x00 0x00 0x00 (destination)

    // Offline query  
    byte msg[] = {
       0xaa,
        0x55,
         0x01,
          0x00,
           0x00,
            0x00,
         0x10,
         0x00,
         0x00,
          0x01,
           0x10
           };
           Serial.write("Sizeof: "); Serial.write(sizeof(msg));

    for (int x = 0; x < sizeof(msg); x++) {
      Serial2.write(msg[x]);  
    }
    delay(3000);                                        // Wait before going back to Receive mode
    digitalWrite(RS_DE_RE, RS485_RECEIVE);   // Put RS485 back into Receive mode    
  
    delay(3000);
    digitalWrite(LED_PIN, HIGH);          // Show activity on LED
    byte buf[10];

    Serial.write("response:\r\n");
    int byteReceived6 = Serial2.readBytes(buf, 10);    // Read received byte
    for (int x = 0; x < sizeof(buf); x++) {
      Serial.write(buf[x]);
    }
    delay(10);
    digitalWrite(LED_PIN, LOW);           // Turn LED back off
  
   delay(5000);
}

Het ledje knippert, er komt wat output op de serial, maar dat is puur en alleen mijn eigen statische output. Ik krijg niets te zien over wat de RS485 interface dan terug krijgt of zo.

[Tanuki]

heintjeput schreef op dinsdag 2 januari 2024 @ 11:56:
[...]

8.4V is trouwens wel wat te veel als je een 1:1 voltage divider gebruikt. Dan moet je wel wat verder omlaag gaan met de spanning.

Ik had gelezen dat andere mensen al hadden gespot dat er 10V op de lijn zou zitten, ipv 7V. De 8,xV die ik lees is dus waarschijnlijk de 10V die een voltage drop is ondergaan.

Ik heb de ESP32 nu gewoon met microUSB van stroom voorzien, dus niet met de voltage line vanaf de omvormer.

Ik wil eerst graag de communicatie werkend zien.

[Raymond P]

Zojuist een pakketje ESP32 C3 Supermini binnen gekregen van Ali tegen een gunstige prijs.

Ze zijn ongeveer even groot als een ESP8266 12E, maar dan inclusief USB-C poort. En ze werken.

[RobertMe]

Raymond P schreef op woensdag 3 januari 2024 @ 18:20:
Zojuist een pakketje ESP32 C3 Supermini binnen gekregen van Ali tegen een gunstige prijs.

Ze zijn ongeveer even groot als een ESP8266 12E, maar dan inclusief USB-C poort. En ze werken.

Oe, die zijn er verdomd nice uit, al helemaal voor < 3 euro. Alleen... doe ik echt veel te weinig met ESPs En heb ik zowel nog Wemos-en met ESP8266 en ESP32 devkits liggen. Zelfs die mmWave sensoren waar ik een paar maanden terug wat vraagjes over heb gesteld heb ik (nog) niet in gebruik genomen

Maar toch... toch, jeukt het om 4 van deze te bestellen (uiteraard 4 voor de gratis snelle verzending).

[Raymond P]

Zo ben ik er ook ingetrapt, maar dan 8 want extra korting en free delivery. (En ik had ze ook werkelijk binnen 4 dagen in huis.)
Het was ook al een poos relatief ongunstig om officiële Wemos C3-mini te kopen en de S3-mini hikte alweer tegen de 6 euro aan. Dus als je bluetooth en niet veel GPIO nodig denkt te hebben...

[Rouwette]

Interessant ja, wat is het stroomverbruik tov de normale esp32?

[ Voor 20% gewijzigd door Rouwette op 03-01-2024 20:55 ]

[Raymond P]

@Rouwette Met de power led eraf getrokken en 3.30V aangeboden: 83µA (0.08ma), inclusief led 420µA, na een simpele esp_deep_sleep_start() in Arduino. Volgens mij is de coprocessor dan wel default actief, weet ik niet zeker meer. (edit: c3 heeft geen coprocessor )
Met wifi connected en een delay(500): 24mA.

Die 24mA zit waarschijnlijk niet ver van de werkelijkheid af. De <100µA ben ik niet zo zeker van.

[ Voor 6% gewijzigd door Raymond P op 04-01-2024 10:46 ]

[DurkVell]

Raymond P schreef op woensdag 3 januari 2024 @ 18:20:
Zojuist een pakketje ESP32 C3 Supermini binnen gekregen van Ali tegen een gunstige prijs.

Ze zijn ongeveer even groot als een ESP8266 12E, maar dan inclusief USB-C poort. En ze werken.

Hey, die heb ik ook zojuist binnen gekregen. Ik probeer ble te gebruiken. Vooralsnog een, voor mij, mistig verhaal.
Opzet is een pc (met bluetooth dongle en Python met bleak library) verstuurt via Bluetooth opdrachten naar de esp32 (te programmeren vanuit Arduino ide). In het verleden heb ik met die hc-05 hc-06 modules geëxperimenteerd en dat lukte prima. Je stuurt alles via serieel (tx en rx) en het Bluetooth-gedoe wordt door die modules afgehandeld. Ik dacht dat het nu net zo eenvoudig zou zijn, maar dat valt dus tegen: een simpel voorbeeld heb ik nog niet gevonden.

[Raymond P]

@DurkVell Gedoe moet je inderdaad zelf regelen op een kale microcontroller icm Arduino.
Als je communicatie "secure" en two-way moet zijn en GATT je niets zegt zou ik daar beginnen met zoeken.

Heb je de NimBle library al bekeken? Dat scheelt een hoop werk.
Een voorbeeldje vind ik hier: https://www.instructables...th-ESP32-C3-and-ESP32-S3/

[manusjevanalles]

Ik heb geprobeerd om vandaag een batch 18dsb20's aan de praat te krijgen. Ik had ze hiervoor jaren geleden voor het laatst besteld, en recent https://a.aliexpress.com/_EHWe7Gv. Ik krijg ze echter niet aan de praat, ik heb ze allemaal geprobeers. In de log van esphome verschijnt geen sensor. Als ik een oude aansluit, dan werkt het perfect. Ik heb zowel 3.3 als 5V geprobeerd. De nieuwe sensoren worden ook erg heet. Is er in de jaren iets veranderd aan deze sensoren of heb ik een ni6eut functionerende batch ontvangen?

[Wolfram55]

Ik ben code over aan het zetten van een esp8266 naar een esp32 minikit wroom32



De code compileert goed maar als ik hem runt gaat het niet goed.
Enigste wat ik zie qua wat er fout zou kunnen zijn is :

code:

E (338) esp_core_dump_flash: Incorrect␀��ize of core dump image: 268440073

en:

code:

Free heap: 252508

Maar dat zou ook kunnen zijn dat die daarmee komt omdat het progje niet goed werkt.


Heb al even lopen zoekemn en dacht dat ik in platform.ini het verkeerde boardje had genomen ... esp32dev
ipv wemos_d1_mini32 maar krijg hetzelfde resultaat.

Verder googelen bracht geen soelaas.
In welke richting moet ik het zoeken?

Ben geen programeur .... Beter knip en plak werk

[Raymond P]

@Wolfram55 Welke chip zit daar exact op?
Ben verder niet bekend met platformio, maar je partitioning klopt waarschijnlijk niet. En de Wemos die je noemt ken ik niet, en kan ik niet terugvinden bij Lolin.
(Kleine letters op het glimmend dekseltje)

@manusjevanalles Er zijn DS18B20's die verkeerd om nagemaakt zijn, de pinout is dan gespiegeld.
Ik heb er een batch van, die verder overigens goed genoeg functioneren.

[ Voor 5% gewijzigd door Raymond P op 05-01-2024 19:15 ]

[Wolfram55]

@Raymond P

esp32 wroom-32

[vso]

Raymond P schreef op vrijdag 5 januari 2024 @ 19:15:
@manusjevanalles Er zijn DS18B20's die verkeerd om nagemaakt zijn, de pinout is dan gespiegeld.
Ik heb er een batch van, die verder overigens goed genoeg functioneren.

idd omdraaien van 1 is de meest handige test die je kan doen.

als je wat gaat solderen is deze ook wel handig


Stop je componentje erin (1 per ingang) en druk op het knopje het kan diverse dingen identificeren
+ eventueel V voor bv een ledje ..

zat onder de boom

[ Voor 4% gewijzigd door vso op 05-01-2024 19:25 ]

[manusjevanalles]

@Raymond P ik heb al geprobeerd om de gnd en plus om te draaien, zonder effect. Zou het ook kunnen dat de data niet de middelste pin is maar een van de buitenste?

[Raymond P]

manusjevanalles schreef op vrijdag 5 januari 2024 @ 19:31:
@Raymond P ik heb al geprobeerd om de gnd en plus om te draaien, zonder effect. Zou het ook kunnen dat de data niet de middelste pin is maar een van de buitenste?

Dat zou dan wel de meest mislukte kloon zijn.
Ik heb ze zo nog niet gezien, maar ik ben ook geen supergrootverbruiker ofzo. Het is waarschijnlijker dat ze gewoon niet werken.

[manusjevanalles]

Raymond P schreef op vrijdag 5 januari 2024 @ 19:36:
[...]


Dat zou dan wel de meest mislukte kloon zijn.
Ik heb ze zo nog niet gezien, maar ik ben ook geen supergrootverbruiker ofzo. Het is waarschijnlijker dat ze gewoon niet werken.

Ik heb net elke mogelijke pincombimatie getest zonder success. Ik bestel wel een nieuwe set bij een andere verkoper.

Edit: iemand nog een tip voor een betrouwbare verkoper?

[ Voor 6% gewijzigd door manusjevanalles op 05-01-2024 19:59 ]

[Raymond P]

Wolfram55 schreef op vrijdag 5 januari 2024 @ 19:21:
@Raymond P

esp32 wroom-32

Als er verder niets bij staat zou dat dan een 4MB unit moeten zijn. Dan zou esp32dev de juiste keuze zijn.

Heb je in platformio de target van je bestaande project veranderd? Zo ja: probeer eens een heel nieuw/leeg project te flashen?
Of wellicht kan iemand met wat meer platformio ervaring je een handje helpen.

[Wolfram55]

Raymond P schreef op vrijdag 5 januari 2024 @ 19:55:
[...]


Als er verder niets bij staat zou dat dan een 4MB unit moeten zijn. Dan zou esp32dev de juiste keuze zijn.

Heb je in platformio de target van je bestaande project veranderd? Zo ja: probeer eens een heel nieuw/leeg project te flashen?
Of wellicht kan iemand met wat meer platformio ervaring je een handje helpen.

Nog wat verder lopen ..... proberen

Bleek https://docs.platformio.o...f32/mhetesp32minikit.html te moeten gebruiken.

In platformio.ini :

code:

[env:mhetesp32minikit]
platform = espressif32
board = mhetesp32minikit

Het vreemde was dan wel weer dat ik een nieuw boardje moest gebruiken. Blijkbaar was er idd toch iets verandert aan de partitielayout waardoor het bij het 1e boardje mis ging .... idk ... moet ik nog even naar kijken.

Ook bijzonder dat dit boardje niet in de ArduinoIDE te gebruiken is

[Wolfram55]

Het pragramma laat nog geen data zien.

Nu wordt er in het origineel voor de Wemos D1 mini pins 4 & 5 gebruikt.

Als ik :
https://community.openmqt...o-lolin-esp32-pinout/2320

bekijk moet ik dan

code:

SoftwareSerial intergas(4, 5, false); // RX, TX, not inverted

vervangen voor :

code:

SoftwareSerial intergas(GPIO16, GPIO18, false); // RX, TX, not inverted

... ?

[Raymond P]

@Wolfram55 Duidelijk. Dat ziet er ook uit als het plaatje wat je hebt gepost.

Op internet vind ik deze website waar pin mapping te vinden is:


Het is dus een bordje dat pin-compatible is met een Wemos D1-mini. Als dat je opzet was en je 'm gewoon erin wilt prikken zal je dus GPIO 16/17 moeten gebruiken.

Bordjes met issues gooi ik door ESP-IDF. Partitioning zal vast ook te fixen zijn met Platformio of esptool.

[Wolfram55]

Raymond P schreef op zaterdag 6 januari 2024 @ 16:51:
Het is dus een bordje dat pin-compatible is met een Wemos D1-mini. Als dat je opzet was en je 'm gewoon erin wilt prikken zal je dus GPIO 16/17 moeten gebruiken.

16/17 ?
4 & 5 bij wemos maakt dan toch 16/18 ?

Net met 16/18 geprobeerd maar dat werkt nog niet .....

Bordjes met issues gooi ik door ESP-IDF. Partitioning zal vast ook te fixen zijn met Platformio of esptool.

Ok ... thx ... ga ik proberen

[Raymond P]

Mea culpa! Ik las dus 4+1 . 16/18 inderdaad.

[Wolfram55]

Raymond P schreef op zaterdag 6 januari 2024 @ 17:02:
Mea culpa! Ik las dus 4+1 . 16/18 inderdaad.

hehe ... no problemo ...


Dus alleen het getal he?
Geen gpio ofzo ervoor?

code:

SoftwareSerial intergas(16, 18, false); // RX, TX, not inverted

Dat wordt dan nog wat verder hakku want geen response ...

[Raymond P]

@Wolfram55 Ja, ervanuitgaande dat dat plaatje klopt. Anders even doorpiepen met een multimeter naar die Wroom 32 zelf.

[ThinkPad]

manusjevanalles schreef op vrijdag 5 januari 2024 @ 19:50:
[...]
Edit: iemand nog een tip voor een betrouwbare verkoper?

offtopic:
Ik kijk bij AliExpress tegenwoordig meestal met het filter 'aantal bestellingen' en pak dan eentje die al veel van het product verkocht heeft i.t.t. de allergoedkoopste kiezen. En even de recensies vluchtig scannen.

[Rouwette]

Ik ben bezig met een esp solar setje.
deze tuto heb ik gevolgd.
https://randomnerdtutoria...battery-level-monitoring/

Wat doe ik fout?

[heintjeput]

Rouwette schreef op zaterdag 13 januari 2024 @ 13:39:
Ik ben bezig met een esp solar setje.
deze tuto heb ik gevolgd.
https://randomnerdtutoria...battery-level-monitoring/

Wat doe ik fout?

[Afbeelding]

Wat is precies je probleem? Als in welke spanningen had je verwacht en welke heb je nu?
Ik denk dat je plaatje of metingen misschien niet kloppen want volgens mij zijn 2 3 en 4 hetzelfde. Kun je het misschien eens naar een circuit tekenen?

Waar het wel op lijkt is dat je 100uF elco verkeerd om zit aangesloten, al kan ik dat niet heel goed zien.

[Rouwette]

heintjeput schreef op zaterdag 13 januari 2024 @ 14:13:
[...]

Wat is precies je probleem? Als in welke spanningen had je verwacht en welke heb je nu?
Ik denk dat je plaatje of metingen misschien niet kloppen want volgens mij zijn 2 3 en 4 hetzelfde. Kun je het misschien eens naar een circuit tekenen?

Waar het wel op lijkt is dat je 100uF elco verkeerd om zit aangesloten, al kan ik dat niet heel goed zien.

Goed punt, ik heb hem omgedraaid maar nog geen succes.

2 = 0.14v nu

[jj85]

@Rouwette Zou het eens zonder de condensatoren proberen om de werking van de LDO te checken

[Wolfram55]

Heb inmiddels de code zo ver dat hij op de esp32 een verbinding heeft met de Intergas ketel en dat hij waardes terug ontvangt.

Het was heel simpel maar het heeft wat uurtjes gekost . Maar dat is niet erg .... weer veel geleerd !


Alleen .... de waardes kloppen niet.

Gaat de esp32 anders met waardes om dan de esp8266 ?
Met andere woorden .... het lijkt er op dat ik in de code nog de omrekening moet veranderen.
Klopt dat ?

[ Voor 24% gewijzigd door Wolfram55 op 16-01-2024 19:17 ]

[Wolfram55]

Redelijk onstabiel ....
Kan het zijn dat er iets met de weerstanden gewijzigd moet worden tov de esp8266 ?

[Raymond P]

@Wolfram55 Ik neem aan dat je met opentherm bezig bent? De "code" is nogal breed, maar normaliter compile je voor je platform/chip en zou een eventuele verandering in interpretatie automagisch aangepast worden.
Ook hardwarematig zou je niets hoeven aan te passen tussen een esp8266 en 32, die werken op dezelfde TTL levels. Meer dan twee optocouplers en bijkomende weerstanden zal je ook niet hebben?

Intergas en opentherm werkt niet lekker en/of stabiel beneden een bepaald bouwjaar, aldus mijn conclusie.

@Rouwette Niet direct gerelateerd aan je probleem maar: laden én verbruiken tegelijk op een tp4056 bordje is niet ideaal. Ik mis je source switch.
https://www.best-microcontroller-projects.com/tp4056.html

Wel gerelateerd: wat meet je zonder condensators, komt er wel prik uit die MCP1700 of enkel rook?

[Wolfram55]

@Raymond P

OK ... dus ik kan aardig wat uitsluiten ....

Nee ... uitlezen van de ketel direct via de IDS aansluiting in de ketel.
Heb het met de wemos D1 mini n jaar of 4 stabiel draaien dus daar zal t niet aan liggen lijkt me.

Het bestaande schema is idd simpel , 2x 4N25's en 4weerstandjes (2x 1K & 2x 220).

Heb er ook een OTGW naast hangen en werkt ook prima al langer zelfs.

Blijft er over de pinnen te gebruiken.
Heb nu de pinnen gebruikt van de 8266 zodat ik de bestaande print kon blijven gebruiken.
Op de mh et esp32 minikit :

#define RXD2 16
#define TXD2 18

Een ander mogelijkheid is n faulty esp32 maar ook al n 2e geprobeerd en de communicatie rechtstreeks met ze met een ander code en dat werkte ook ok.


Kwam nog wel een schema tegen van iemand die ook naar de esp32 was gegeaan en die heeft dat wel verder uitgebreid. Ben ook geen elektroman maar lijkt me dat dat ook het probleem niet kan zijn ...

https://github.com/little...main/images/schematic.png

Als extra 2 BC337 en een LP2950 met condensator.

Heb aan zijn code niks want hij gaat via esphome.

[Raymond P]

@Wolfram55 Dat schema gaat volgens mij iets mis gezien een 337 een NPN zou moeten zijn. Maareh, ik ben ook geen electroman.

Het verschil zit 'm dan in de softwareserial die je gebruikt. Een ESP32 heeft meerdere UART's en je kunt die ook pinmappen. Hardwareserial heeft de voorkeur.
Wellicht dat even proberen?

[Wolfram55]

Raymond P schreef op dinsdag 16 januari 2024 @ 22:58:
@Wolfram55 Dat schema gaat volgens mij iets mis gezien een 337 een NPN zou moeten zijn. Maareh, ik ben ook geen electroman.

Het verschil zit 'm dan in de softwareserial die je gebruikt. Een ESP32 heeft meerdere UART's en je kunt die ook pinmappen. Hardwareserial heeft de voorkeur.
Wellicht dat even proberen?

Hieronder wat er anders is wat betreft code .... Dit heb ik zo geprobeerd.
Het 1e deel is van de 32 en 2e gedeelte van de 8266

esp32 :

code:

#include <Arduino.h>
#include <WiFi.h>
#include <PubSubClient.h>
#include <TimeLib.h>
#include <Timezone.h>    // https://github.com/JChristensen/Timezone
#include <WiFiUdp.h>
#include <HardwareSerial.h>

#define RXD2 16
#define TXD2 18

HardwareSerial intergas(2);


Serial.begin(115200);
intergas.begin(9600);

esp8266:

code:

#include <ESP8266WiFi.h>
#include <PubSubClient.h>
#include <SoftwareSerial.h>
#include <TimeLib.h>
#include <Timezone.h>    // https://github.com/JChristensen/Timezone
#include <WiFiUdp.h>

SoftwareSerial intergas(4, 5, false ); // RX, TX, not inverted

Serial.begin(115200);
intergas.begin(9600);

Ik zie zelf hier geen bijzonderheden ... jij?


Vandaag weer wat aan t proberen geweest en ik flashte hem weer n keer en terwijl hij aan de laptop hing, en dus niet aan de ketel, kreeg ik toch info van de ketel terug .....
Dus er gaat iets mis met flashen/parities wipen ?
Daarom n keer via Arduino IDE gedaan maar ook nada.

En zo rommelen we door de dagen heen

Wat ik nog kan doen is de .... de 'preferred' te gebruiken pinnen .... 16 & 17.
Maar ik heb 2 32's aan elkaar gehangen met elk zijn eigen code en dat werkt prima. Op veel pinnen getest. Allemaal probleemloos.
Neem aan dat als je tekst over stuurt en dat komt over dat dat allemaal ok is.

Komt er dan toch wellicht niks terug van de ketel ?

code:

######################  Zender : ###########################

#include <HardwareSerial.h>
#define RXD2 16
#define TXD2 17

HardwareSerial intergas(2);

void setup() {
  Serial.begin(115200);
    intergas.begin(9600, SERIAL_8N1, RXD2, TXD2);
}

void loop() { 
  intergas.write("tttttttttttttttttttttttttttt\n");
  delay(200);
}

 ######################  Ontvanger : #######################

#define RXD2 16
#define TXD2 17

String incoming;

void setup() {
  Serial.begin(115200);
  Serial2.begin(9600, SERIAL_8N1, RXD2, TXD2);
}

void loop() { 
  while (Serial2.available() >= 1) {
    //Serial.print(char(Serial2.read()));
    incoming = Serial2.readStringUntil('\n');
    Serial.println(incoming);
  }
}

[Raymond P]

@Wolfram55 In je eerste voorbeeld mis ik je pin remap.
Uart2 is default #16/17, als je #18 wilt gebruiken zal je dat nog wel even aan moeten geven (zoals in je derde voorbeeld).

[Wolfram55]

Raymond P schreef op woensdag 17 januari 2024 @ 16:55:
@Wolfram55 In je eerste voorbeeld mis ik je pin remap.
Uart2 is default #16/17, als je #18 wilt gebruiken zal je dat nog wel even aan moeten geven (zoals in je derde voorbeeld).

Zie regel 9 & 10 toch .... (?)

code:

#define RXD2 16
#define TXD2 18

[Wolfram55]

Heb nog niet geprobeerd om ze om te wisselen ....

code:

#define RXD2 18
#define TXD2 16

Dat kan ik nog gaan doen ....

[Raymond P]

Nee, op regel 16. Als je geen pins meegeeft start 'ie op de default pins.

[Wolfram55]

Raymond P schreef op woensdag 17 januari 2024 @ 17:50:
Nee, op regel 16. Als je geen pins meegeeft start 'ie op de default pins.

Yep .... helemaal gelijk in. Dat ontbreekt idd mijn de intergas-code.
Dat je ... ik dus .... er zo overheen kan kijken is en blijft bijzonder ...

maar .....

Het was niet de oplossing.

Beide geprobeerd :

code:

#define RXD2 16
#define TXD2 18
intergas.begin(9600, SERIAL_8N1, RXD2, TXD2);

code:

#define RXD2 18
#define TXD2 16
intergas.begin(9600, SERIAL_8N1, RXD2, TXD2);

En via Arduino IDE en vsc

[Wolfram55]

Op het circuit van een paar post terug heeft hij het over :




Lijkt me geen dingetje omdat er optocouplers tussen zit ....

Als jij zegt dat de code in weze gelijk kan blijven. Enigste is idd Softwareserial en Harwareserial. En die hebben we lijkt mij op deze manier goed vertaald nu.


Enigste is dat hij een melding geeft over dat de Timezone voor een avr is ipv esp32 is. Maar de tijd is ok .

[Raymond P]

@Wolfram55 Je weet zeker dat die optocouplers (nog) correct werken?

[Wolfram55]

Raymond P schreef op woensdag 17 januari 2024 @ 19:20:
@Wolfram55 Je weet zeker dat die optocouplers (nog) correct werken?

Ik gebruik de print met de esp8266 die goed werkt telkens ook voor de 32.
Dus ja .... iig icm de 8266.

[Raymond P]

Heb je je volledige code ergens online staan? Wellicht spot ik of iemand anders iets...

[Wolfram55]

Raymond P schreef op woensdag 17 januari 2024 @ 19:48:
Heb je je volledige code ergens online staan? Wellicht spot ik of iemand anders iets...

Nee ... heb geen github ofzo
Heb hem 'geleend' van iemand (die er niet meer op die manier mee verder is gegaan) maar geloof dat ik wel eea (niet bijzonder veel) gewijzigd heb omdat het niet werkte zo in 1e instantie. Weet niet zeker meer. Lang geleden. Ook niet gevraagd ofzo.
Weet niet of dat ongebruikelijk is om code van een ander zomaar te openbaren .... ?

Code is 550 regels.
Kan hem anders hier plaatsen?

[Wolfram55]

Valt reuze mee wat ik verandert heb. Heb er alleen erg mee geworsteld toendertijd omdat het compleet nieuw voor me was

https://github.com/keesma...rc/ch_intergas_reader.ino

[Raymond P]

@Wolfram55 #105, inverted.
Probeer je hardwareserial eens met de inverted flag?

code:

intergas.begin(9600, SERIAL_8N1, RXD2, TXD2, true);

Volgens mij had ik dat ook wel eerder kunnen spotten...

[ Voor 17% gewijzigd door Raymond P op 17-01-2024 20:31 ]

[Wolfram55]

tot debug :

code:

#include <Arduino.h>
#include <WiFi.h>
#include <PubSubClient.h>
#include <TimeLib.h>
#include <Timezone.h>    // https://github.com/JChristensen/Timezone
#include <WiFiUdp.h>
#include <HardwareSerial.h>


#define RXD2 16
#define TXD2 18

HardwareSerial intergas(2);

deze regel is vervallen

code:

SoftwareSerial intergas(4, 5, false ); // RX, TX, not inverted

Deze:

code:

intergas.begin(9600);

Vervangen voor:

code:

intergas.begin(9600, SERIAL_8N1, RXD2, TXD2);

[Wolfram55]

Raymond P schreef op woensdag 17 januari 2024 @ 20:30:
@Wolfram55 #105, inverted.
Probeer je hardwareserial eens met de inverted flag?

code:

intergas.begin(9600, SERIAL_8N1, RXD2, TXD2, true);

Volgens mij had ik dat ook wel eerder kunnen spotten...

Ah ... dat is niet 'gewoon' omwisselen?
Wat ik dacht en daarom niet meegenomen ...

[Raymond P]

Dat wisselt de polariteit, hoog <> laag.

En edit, de softwareserial lib laag staat gelijk aan de default in hardwareserial.
Dat zal 'm dus waarschijnlijk ook niet zijn.

Ik zie verder enkel normale seriële communicatie...

[ Voor 76% gewijzigd door Raymond P op 17-01-2024 20:48 ]

[Wolfram55]

Raymond P schreef op woensdag 17 januari 2024 @ 20:36:
Dat wisselt de polariteit, hoog <> laag.

En edit, de softwareserial lib laag staat gelijk aan de default in hardwareserial.
Dat zal 'm dus waarschijnlijk ook niet zijn.

Ik zie verder enkel normale seriële communicatie...

idd .... nothing changed

[Wolfram55]

Raymond P schreef op woensdag 17 januari 2024 @ 20:36:
En edit, de softwareserial lib laag staat gelijk aan de default in hardwareserial.

Hoe/waar kan je dat zien?
Dan snap ik t ook

[Raymond P]

Wolfram55 schreef op donderdag 18 januari 2024 @ 00:05:
[...]

Hoe/waar kan je dat zien?
Dan snap ik t ook

Softwareserial.h #92
Hardwareserial.h #254

Ik las de comment uit je git linkje in de verkeerde brainmode en vertaalde dat naar defaults: not inverted = false ipv false = not inverted
Een !boolean vond ik wel een beetje raar voor een Arduino lib dus dubbelcheck.

[ComTech]

Iemand ervaring met een TSL2561 i2c lichtsensor?
Ik heb deze op een Wemos D1 mini met esphome.
In de log zie ik dat de sensor gevonden wordt maar er komen geen waardes voorbij. (en in HomeAssistant blijft de waarde op onbekend staan).

[Wolfram55]

@Raymond P

Ben er uit wat het probleem was.
Dat heb je als je er niet dagelijks mee bezig bent ... hou ik me dan maar voor ... .

In de code wordt pinnen 4 & 5 gebruikt ... en je voelt m al aankomen vrees ik ....4&5 is GPio 1&2 .... zucht.
Heeft me jaren geleden met de wemos D1 ook wat tijd gekost.

Waarom kunnen ze niet gewoon op t boordje zetten wat de gpio pennen zijn ipv een andere benaming ?

Veel dank voor je hulp iig anders had ik veel meer tijd gestoken in de code. Nu wilde ik een wemod lolin 32 gaan gebruiken als test en ben toen de pinnen na gaan lopen om eea even met jumper wires aan te sluiten.

Thx iig

[Raymond P]

@Wolfram55 Mooi, dat scheelt weer!
Deze had je gemist?

Raymond P schreef op zaterdag 6 januari 2024 @ 18:45:
@Wolfram55 Ja, ervanuitgaande dat dat plaatje klopt. Anders even doorpiepen met een multimeter naar die Wroom 32 zelf.

[Wolfram55]

Het hele idee om over te gaan van 8266 naar 32 was ble.
Heb een aantal Xiaomi thermometerjes hier liggen die ik met esp32 icm met tasmota uitlees. Wilde deze van de intergas gaan combineren met het uitlezen van die dingen.

Kan je me een richting geven waar te starten met ble ?

[Wolfram55]

Raymond P schreef op maandag 22 januari 2024 @ 11:50:
@Wolfram55 Mooi, dat scheelt weer!
Deze had je gemist?


[...]

Nee had ik niet gemist en ook gedaan. Weer veel wijzer van geworden ook. Erg leuk !

Maar als je verkeerd denkt dan kom je zo 123 niet uit die tunnel en moet er 'iets' gebeuren of helemaal overnieuw alles nalopen. Wat ik deed.

Wil nog wel eens teveel op het 'verkeerde' focussen

[Raymond P]

@Wolfram55 Veel ervaring met BLE heb ik ook niet.
Wat ik heb draaien is op basis van NimBLE examples.

[Wolfram55]

Raymond P schreef op maandag 22 januari 2024 @ 12:01:
@Wolfram55 Veel ervaring met BLE heb ik ook niet.
Wat ik heb draaien is op basis van NimBLE examples.

Het is altijd de 'kunst' een github te gebruiken die het beste is.

Ik kwam zelf deze tegen : https://github.com/MHEtLive/ESP32-MINI-KIT welke met met "SimpleBLE.h" werkt.

Hoe zoek en vindt je de 'beste' lib zeg maar.
Deze lijkt van het boordje te zijn, of ze pretenderen het iig.
Maar als ik op https://github.com/MHEtLive naar https://forum.mhetlive.com/ ga krijg ik een "||iyfbodn.com^" wat dan ook weer niet uitnodigend is.

[Raymond P]

Als je ergens instapt is het handig om datgene te kiezen wat het beste gedocumenteerd en/of meest gebruikt is.
Kans dat je dan tegen issues aanloopt waarvoor oplossingen en/of lotgenoten niet snel te vinden zijn beperk je dan zo veel mogelijk.
(Zo ook met hardware/sensors)

Optimalisatie is thuis toch vaak helemaal niet nodig en speciale vereisten zijn schaars zolang je die strategie volgt.
Werkende code is wel zo prettig.

Edit: een lib waar 7 jaar niets aan gedaan is zou niet direct mijn interesse wekken.

[ Voor 9% gewijzigd door Raymond P op 22-01-2024 12:53 ]

[Wolfram55]

Raymond P schreef op maandag 22 januari 2024 @ 12:38:
Als je ergens instapt is het handig om datgene te kiezen wat het beste gedocumenteerd en/of meest gebruikt is.

Edit: een lib waar 7 jaar niets aan gedaan is zou niet direct mijn interesse wekken.

Helemaal correct !

Kwam deze al tegen : https://randomnerdtutoria...w-energy-ble-arduino-ide/ en die verwijzen naar Neil Kolban . Die naam ben ik vaker tegen gekomen.
Hij schrijft ook : "ESP32 BLE for Arduino (This repository is kept for archive. BLE code is now included in Arduino directly.)"
Maar ook 7jaar niet meer in gewerkt.
Als ik dan kijk op "jouw" https://github.com/h2zero zie je dat ze verwijzen naar .... Neil Kolban

Dus ga maar met deze aan de slag ...

[Raymond P]

Fwiw die gelinkte lib hangt (uiteindelijk/deels) aan NimBLE van Apache.

[JayPe]

Gasten, geen idee of dit het juiste forum topic is, dus als ik elders mijn vraag beter stel: Ik hoor het graag.

Ik ben al een tijdje met Home Assistant, aan het knutselen. Ik wilde eerst een puls-counter bouwen, om m'n stroommeter uit te lezen, maar dat project ging stof liggen happen omdat ik toch niet helemaal uit de GPIO pinnen, pull-up, weerstanden en meer van zulks kwam.

Ik heb inmiddels ESPhome ontdekt, en dat je met een assortiment ' standaard ' sensoren best okay luchtkwaliteitsmetingen kunt doen. Temp en RV zijn super saai, maar voor een badkamer ventilator aan te sturen wel geschikt.
Met een Wemos D1 mini een DMT22 vocht/temp + S8 Sensiron CO2 sensor een sturing gebouwd, en alles hang heel professioneel (Biereco) aan een USB-Adapter te bungelen. Die DMT22 blijkt niet echt betrouwbaar. Kost niets, maar valt na een tijdje uit. BME280 doet 't stabieler, via I2C. S8 via UART op de TX/RX. Inmiddels heb ik zo'n klimaat dingetje ook hangen in mijn werkplaats. Temperatuur een beetje bij houden, barometer druk is leuk voor het weer, CO2 is fijn om ventilatie in de gaten te houden, en ik voegde een PIR sensor toe om de lampen te schakelen. Inmiddels begint het aantal GPIO poorten krap te worden. Ik wil, om niet alleen maar op de smartphone te hoeven kijken, drie led's toevoegen, dus al naar gelang de luchtkwaliteit gaat de groene, oranje of rode led branden.

Maar: Het aantal pinnen is beperkt, en zo gaat met mijn huidige setup de blauwe LED op het (Wemos D1 Mini V4) bordje aan, als de rode led uit is. Uit ervaring / schade en schandelijke wijsheid, weet ik dat die GPIO pinnen niet allemaal gelijk zijn. Ik weet dat er TX/RX & scl sda pinnen ' gereserveerd ' zijn en dat sommige pinnen gebruikt kunnen worden voor flashen, resetten of naja van alles. Maar echt genoeg verstand, ik heb het nog niet. Omdat ik inmiddels voor bijna alle slaapkamers in huis dit soort kastjes gebouwd heb ( gewoon in een lasdoosje van de praxis ) en elke versie weer wat ' beter ' werkt, wordt het tijd om eens een collegiale toets te laten uitvoeren. Doe ik het wel goed, gebruik ik niet de verkeerde pinnen voor de verkeerde toepassingen, en is het niet makkelijker / beter / slimmer / simpeler op te lossen?

Kan/Mag ik hier een lijstje plaatsen van de in gebruik zijnde GPIO poorten, met de functie waarvoor ik het gebruik erbij? Ik gebruik bijvoorbeeld voor één led aan te sturen, 2 poorten: Eén Output poort ( waar niets op aangesloten zit) en één contactpoort ( die GPIO pin waar daadwerkelijk een LED op is aangesloten ). Die output GPIO is 'een fysiek aanwezig' pin. Terwijl, als ik ga tellen, er ook een aantal 'non-exposed' poorten zijn, voor intern gebruik op de chip/bordje. Ik weet echter niet of ik daar 'zomaar' gebruik van kan maken, of dat ik dan mayhem over mij afroep.

Ik zal eens een lijstje maken, dan hoor ik graag commentaar :-)

[JayPe]

code:

#Pins to connect Anode side of led to ( ground via 330ohm resistor ) 
output:
  - platform: gpio
    pin: D6  (GPIO 12)
    id: green_led_output

  - platform: gpio
    pin: D7 (GPIO 13)
    id: orange_led_output

  - platform: gpio
    pin: D3 (GPIO 0)
    id: red_led_output

#Switches exposed to HA to switch led's
switch:
  - platform: gpio
    id: green_led_switch
    pin: D0 (GPIO 16) 
    name: "Green LED Switch"

  - platform: gpio
    id: orange_led_switch
    pin: D8 ( GPIO 15 ) 
    name: "Orange LED Switch"

  - platform: gpio
    id: red_led_switch
    pin: D4 ( GPIO 2 ) 
    name: "Red LED Switch"

#UART for S8 CO2 sensor
uart:
  rx_pin: GPIO3
  tx_pin: GPIO1
  baud_rate: 9600

#I2C for BME280
i2c:
  sda: D2 ( GPIO 4) 
  scl: D1 (GPIO 5)

#PIR
binary_sensor:
  - platform: gpio
    pin: D5 ( GPIO 14)

Ergo: GPIO 0 , 1 , 2, 3, 4, 5 zijn in gebruik, en GPIO 12, 13, 14, 15, 16.

GPIO 6 t/m 11 zijn op een Wemos D1 mini volgens mij niet 'exposed' ( of wel? )

Is de volgorde die ik nu gebruik logisch? Zijn er andere, slimmere manieren om die LED's te schakelen zonder 2 GPIO's per led te hoeven gebruiken?

[ Voor 7% gewijzigd door JayPe op 26-01-2024 12:24 ]

[Raymond P]

Neopixel?

[ Voor 87% gewijzigd door Raymond P op 26-01-2024 12:28 ]

[jj85]

@JayPe Inderdaad wat @Raymond P zegt. Pak een adresseerbare LED, zoals een neopixel, of WS2812B of... (vele opties beschikbaar).
Deze heb je ook in 'gewone' LED vorm. Of je gebruikt een ledstrip of een LED circel, kortom heel veel mogelijkheden.
Voordeel is dat je maar één pin nodig hebt op je ESP.

Je kunt trouwens ook de logica in ESPhome 'programmeren'. Dan werkt het zonder tussenkomst van Home Assistant automations.
Op basis van de luchtkwaliteit van de S8 en BME kun je rechtstreeks vanuit ESPhome de led aansturen.

[JayPe]

jj85 schreef op vrijdag 26 januari 2024 @ 14:27:
Je kunt trouwens ook de logica in ESPhome 'programmeren'. Dan werkt het zonder tussenkomst van Home Assistant automations.
Op basis van de luchtkwaliteit van de S8 en BME kun je rechtstreeks vanuit ESPhome de led aansturen.

Ja, klopt, maar ik wil de automations graag in HA hebben; de lampjes die de luchtkwaliteit aangeven is één, maar ik wil er bijvoorbeeld ook ventilatie mee regelen, of een app sturen: "zet eens een raam open". Dàt kan natuurlijk allemaal afzonderlijk van de lampjes geregeld, maar ik wil bijvoorbeeld óók de LED's 's nachts uit laten, etc etc, dan is centrale besturing gemakkelijker.

[ThinkPad]

Lampjes 's nachts uit kun je met een binary_switch doen en een regel in ESPHome, dat de lampjes alleen mogen branden als die virtuele switch aan staat. Via HA laat je dan die switch uitzetten zodra je gaat slapen. Maar alles in HA doen kan natuurlijk ook, ieder z'n eigen wensen

[ Voor 6% gewijzigd door ThinkPad op 28-01-2024 19:44 ]

[RobertMe]

ThinkPad schreef op zondag 28 januari 2024 @ 19:43:
Lampjes 's nachts uit kun je met een binary_switch doen en een regel in ESPHome, dat de lampjes alleen mogen branden als die virtuele switch aan staat. Via HA laat je dan die switch uitzetten zodra je gaat slapen. Maar alles in HA doen kan natuurlijk ook, ieder z'n eigen wensen

Of je houd een slapen stand bij in HA zelf en haalt die als binary sensor binnen in ESPHome. Dat is wat ik doe

[tjanssen]

Weet iemand waar de jumper 3.3V / 5V voor dient?



Verder zijn er 3 manieren van poweren? Micro USB, USB-C en de ronde DC connector?

[Raymond P]

@tjanssen Aan de onderkant te zien, voltage selectie voor de expansion rails (V).
Met inderdaad drie connectors voor voltage input.

[Opperhoof]

Wolfram55 schreef op zaterdag 6 januari 2024 @ 14:49:
Het pragramma laat nog geen data zien.

Nu wordt er in het origineel voor de Wemos D1 mini pins 4 & 5 gebruikt.

Als ik :
https://community.openmqt...o-lolin-esp32-pinout/2320

bekijk moet ik dan

code:

SoftwareSerial intergas(4, 5, false); // RX, TX, not inverted

vervangen voor :

code:

SoftwareSerial intergas(GPIO16, GPIO18, false); // RX, TX, not inverted

... ?

Mag ik vragen wat voor soort koppeling je probeert te maken met je intergas ketel? Ik ben namelijk opzoek naar een mogelijkheid om het tapwater van mijn intergas ketel te kunnen aanpassen met een ESP oid.