Het grote ESP topic

[Toppe]

De connectoren van Ali binnen (klik) en best prima. Net even een simpele DS18B20 er aan gezet en werkt echt wel makkelijk. Verkrijgbaar van 2 tot 14 polig en M20 wartel dus meteen te gebruiken in een kabeldoos oid

[ Voor 4% gewijzigd door Toppe op 01-09-2024 12:40 ]

[jack zomer]

oke.

ik heb nu de 6 esp32 identiek geïnstalleerd op mijn bureau liggen
(in HA in ESPhome geklikt op nieuw apparaat, en dan door naar web esphome.)

ze werken alle 6 op mijn bureau en geven hun status goed door aan HA.


Nu heb ik de 6 verplaatst naar de techruimte,
en 3 van de esp32 geven niet meer een firmware update in HA.
Wel geven ze aan dat ze nog steeds thuis zijn.
Update van deze 3 via esphome werkt ook niet meer
en via ubiquiti zie ik dat ze geen netwerk of ap pakken, maar wel een ip hebben?





ik heb ook de uk ultra even geswitcht voor een ac mesh. ook dat maakt geen verschil.
ik ga ze even lekker een paar dagen daar laten liggen. misschien zijn ze wat traag van begrip en hebben ze een paar uur nodig om zich aan te passen

[ Voor 5% gewijzigd door jack zomer op 01-09-2024 14:48 ]

[Toppe]

jack zomer schreef op zondag 1 september 2024 @ 14:47:
oke.

ik heb nu de 6 esp32 identiek geïnstalleerd op mijn bureau liggen
(in HA in ESPhome geklikt op nieuw apparaat, en dan door naar web esphome.)

ze werken alle 6 op mijn bureau en geven hun status goed door aan HA.


Nu heb ik de 6 verplaatst naar de techruimte,
en 3 van de esp32 geven niet meer een firmware update in HA.
Wel geven ze aan dat ze nog steeds thuis zijn.
Update van deze 3 via esphome werkt ook niet meer
en via ubiquiti zie ik dat ze geen netwerk of ap pakken, maar wel een ip hebben?

[Afbeelding]

[Afbeelding]

ik heb ook de uk ultra even geswitcht voor een ac mesh. ook dat maakt geen verschil.
ik ga ze even lekker een paar dagen daar laten liggen. misschien zijn ze wat traag van begrip en hebben ze een paar uur nodig om zich aan te passen

Kan je niet een re-connect doen in je unifi software?

[Raymond P]

@jack zomer Wat voor ESP32? En waar komen ze vandaan?

[jack zomer]

Toppe schreef op zondag 1 september 2024 @ 14:55:
[...]


Kan je niet een re-connect doen in je unifi software?

Ja kan wel een re-connect doen. Maar het resultaat blijft het zelfde.

Raymond P schreef op zondag 1 september 2024 @ 15:11:
@jack zomer Wat voor ESP32? En waar komen ze vandaan?

AZDelivery ESP32 ESP-WROOM-32 NodeMCU Modulo WiFi + Bluetooth Dev Kit C vanuit Amazon..
Het zou natuurlijk kunnen dat er een batch probleem was, en dat ik 3 beperkte bordjes heb gevonden.

[Raymond P]

Dat is een bordje met een wroom-32 erop gesoldeerd toch? Afaik hebben die geen antenne issues, maar om uit te sluiten zou je een verbose debug kunnen doen (terug op je bureau).

[jack zomer]

Raymond P schreef op zondag 1 september 2024 @ 15:53:
Dat is een bordje met een wroom-32 erop gesoldeerd toch? Afaik hebben die geen antenne issues, maar om uit te sluiten zou je een verbose debug kunnen doen (terug op je bureau).

klopt. maar dat gaat na mijn vakantie gebeuren..

voor nu lijkt tijd ook goed te helpen

code:

======================== [SUMMARY] ========================
  - /config/esphome/esp32irrigatie.yaml: SUCCESS
  - /config/esphome/esp32zwembadtemperatuur.yaml: SUCCESS
  - /config/esphome/esphome-web-260a90.yaml: SUCCESS
  - /config/esphome/esphome-web-27430c.yaml: FAILED
  - /config/esphome/esphome-web-279290.yaml: SUCCESS
  - /config/esphome/esphome-web-27a17c.yaml: SUCCESS
  - /config/esphome/esphome-web-e44a98.yaml: SUCCESS
  - /config/esphome/esphome-web-f179ac.yaml: SUCCESS

nog maar 1 in de faalstand. echt bloed vervelend.
fouten maken doet iedereen, en daar leer je van.
Maar dit soort rare dingen, die geen echte rede lijken te hebben zijn bloed irritant



heb zo even mijn test overzicht gemaakt, zodat ik kan zien wat er met welk board gebeurd.


En inmiddels een paar uur later

code:

======================== [SUMMARY] ========================
  - /config/esphome/esp32irrigatie.yaml: SUCCESS
  - /config/esphome/esp32zwembadtemperatuur.yaml: SUCCESS
  - /config/esphome/esphome-web-260a90.yaml: SUCCESS
  - /config/esphome/esphome-web-27430c.yaml: SUCCESS
  - /config/esphome/esphome-web-279290.yaml: SUCCESS
  - /config/esphome/esphome-web-27a17c.yaml: SUCCESS
  - /config/esphome/esphome-web-e44a98.yaml: SUCCESS
  - /config/esphome/esphome-web-f179ac.yaml: SUCCESS

Alles wil updaten,, meeste binnen 30sec, de 17c neemt 80 sec.
Morgen de ubiquiti uk ultra terug als ap. Kijken of dan alles goed blijft

[ Voor 20% gewijzigd door jack zomer op 01-09-2024 22:49 ]

[jack zomer]

even een korte update.
iets sloopt de werking van de esp32 in de techruimte.
En ik ben er nog niet achter waarom dit is.

ik heb de standaard code vervangen door mijn versimpelde zwembad tempratuur code

code:

esphome:
  name: "esphome-web-279290"
  friendly_name: ESPHome Web 279290

esp32:
  board: esp32dev
  framework:
    type: arduino

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

# Enable logging
logger:

# Enable Home Assistant API
api:
  
# Allow Over-The-Air updates
ota: 
    platform: esphome

one_wire:
  - platform: gpio
    pin: GPIO05

in op mijn bureau werkt het allemaal oke.
Wanneer ik ze verplaats naar de techruimte, heb ik er na 1 uur 5 online. maar wanneer ik ze dan weer van stroom haal om in mijn esp32 bordje te plaatsen op 5v dan werken de 2 gewenste esp32 niet.
komende maand eerst even op vakantie, daarna verder spelen en uitzoeken

[Rouwette]

jack zomer schreef op donderdag 5 september 2024 @ 10:29:
even een korte update.
iets sloopt de werking van de esp32 in de techruimte.
En ik ben er nog niet achter waarom dit is.

ik heb de standaard code vervangen door mijn versimpelde zwembad tempratuur code

code:

esphome:
  name: "esphome-web-279290"
  friendly_name: ESPHome Web 279290

esp32:
  board: esp32dev
  framework:
    type: arduino

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

# Enable logging
logger:

# Enable Home Assistant API
api:
  
# Allow Over-The-Air updates
ota: 
    platform: esphome

one_wire:
  - platform: gpio
    pin: GPIO05

in op mijn bureau werkt het allemaal oke.
Wanneer ik ze verplaats naar de techruimte, heb ik er na 1 uur 5 online. maar wanneer ik ze dan weer van stroom haal om in mijn esp32 bordje te plaatsen op 5v dan werken de 2 gewenste esp32 niet.
komende maand eerst even op vakantie, daarna verder spelen en uitzoeken

Gebruik je dezelfde kabel? Ik merk dat sommige espjes erg slecht om kunnen gaan met oude/slechte kabels.

[jack zomer]

Rouwette schreef op donderdag 5 september 2024 @ 15:19:
[...]

Gebruik je dezelfde kabel? Ik merk dat sommige espjes erg slecht om kunnen gaan met oude/slechte kabels.

6 usb kabels.
en 2 bordjes met een vaste 5v voeding.


ik weet zeker dat wanneer ik het probleem vind, dat ik denk'' was het zo simpel''
ergens bij iets iets anders, waardoor alles over de zeik gaat (behalve mijn irrigatie en zwembad esp)

[_ferry_]

Wat voor vaste 5V voeding? En heb je een bordje met een eigen 3,3v regelaar? En hangen er nog sensoren of andere devices aan die stroom verbruiken?

Er zijn wel eens wat spanningsregelaars geweest voor 3.3v die niet echt genoeg stroom konden leveren voor de bordjes. Dus ik zou eens meten (met een fatsoenlijke multimeter) of de 5v en 3,3V in orde zijn. Desnoods nabij de bordjes nog een kleine condensator (10uF+100nF ofzo) plaatsen ter ontstoring.

[Toppe]

Ik zit te kijken naar mmWave sensoren voor het zwembad, mijn gevoel zegt alleen dat dit niet gaat werken omdat het een vloeistof dichte massa is en signalen dat doorgaans niet leuk vinden.

Alleen als ik op de website van Opencircuit kijk: https://opencircuit.nl/pr...esence-detection-sensor-9

Dan lees ik: Sterk anti-interferentievermogen, wordt niet beïnvloed door sneeuw, nevel, temperatuur, vochtigheid, stof, licht, geluid, enz.

Dat zou dus betekenen dat water geen (enkele) invloed heeft op de werking.

Iemand ervaring hiermee?

[Raymond P]

@Toppe Bewegende vloeistof pakt zo'n sensor gewoon op.
Of je erdoorheen kunt kijken met mmw weet ik eigenlijk niet, als dat je bedoeling is kan ik dat wel testen met een bak water ofzo.

[Toppe]

Raymond P schreef op zondag 8 september 2024 @ 17:09:
@Toppe Bewegende vloeistof pakt zo'n sensor gewoon op.
Of je erdoorheen kunt kijken met mmw weet ik eigenlijk niet, als dat je bedoeling is kan ik dat wel testen met een bak water ofzo.

Ik wil er niet dóór heen kijken, ik wil er in kijken. Gaat om het zwembad of er iemand in zit of niet.

[Raymond P]

Toppe schreef op zondag 8 september 2024 @ 17:53:
[...]


Ik wil er niet dóór heen kijken, ik wil er in kijken. Gaat om het zwembad of er iemand in zit of niet.

Je wilt door het oppervlakte van het water kijken toch?
Als het oppervlakte van het water beweegt is dat detecteerbaar, dat betekent dat in ieder geval een deel van de golf weerkaatst wordt en je signaalsterkte verliest waardoor (diepe) penetratie mij niet plausibel lijkt met een legale sensor.

Hier op het bureau 20 cm boven een kunststof bak met een laag van +/-20cm water lijkt het erop dat ik geen beweging zie onder de bak.
Ik heb geen massa water beschikbaar dat diep genoeg is om een goede test te doen.

fwiw: ik detecteer vanaf het plafond minuscule beweging in mijn toiletpot als de bril niet netjes omlaag is én het hard genoeg waait. Een splash detectie lijkt mij dus wel plausibel.

Laserafstandsensors op de 4 zijden en een bordje verboden te duiken heeft denk ik meer kans van slagen.

[Toppe]

Raymond P schreef op zondag 8 september 2024 @ 18:38:
[...]


Je wilt door het oppervlakte van het water kijken toch?
Als het oppervlakte van het water beweegt is dat detecteerbaar, dat betekent dat in ieder geval een deel van de golf weerkaatst wordt en je signaalsterkte verliest waardoor (diepe) penetratie mij niet plausibel lijkt met een legale sensor.

Hier op het bureau 20 cm boven een kunststof bak met een laag van +/-20cm water lijkt het erop dat ik geen beweging zie onder de bak.
Ik heb geen massa water beschikbaar dat diep genoeg is om een goede test te doen.

fwiw: ik detecteer vanaf het plafond minuscule beweging in mijn toiletpot als de bril niet netjes omlaag is én het hard genoeg waait. Een splash detectie lijkt mij dus wel plausibel.

Laserafstandsensors op de 4 zijden en een bordje verboden te duiken heeft denk ik meer kans van slagen.

Als je met een bak van 20cm water al niets meer meet dan heeft het bij een zwembad van 3 meter natuurlijk geen enkel nut.

Thanks in elk geval. Had gehoopt dat het zou werken vanwege de opmerking op de website.

[Raymond P]

@Toppe De bak zelf houdt ook wat RF tegen natuurlijk, vandaar de aanmerking. Maar 3 meter diep lijkt mij idd kansloos.

Die opmerking verwijst vooral naar ruis door stof, regen en sneeuw. Dat kan je wegfilteren/negeren.

[Raven]

Heeft iemand toevallig ervaring met het inzetten van een ESP-module als serial server? Dat probeer ik nu te doen, om PZEM-004t modules via wifi uit te kunnen lezen.

De ESP is een D1 Mini Pro (8266EX) met ESP Easy, er zit een logic level converter achter en daarachter zit de PZEM-004t. Als ik een FTDI-kabel gebruik om de PZEM uit te lezen in Python dan werkt het, via TCP met andere code

Python:

from pyModbusTCP.client import ModbusClient

client = ModbusClient(auto_open=True)
client = ModbusClient('*.*.*.*', port=*)
result = client.read_holding_registers(1,10)
print(result)


None

zie ik de rode LED op de PZEM-module 1 keer knipperen, maar er komt geen data terug. Zelfde met

Python:

from pymodbus.client import ModbusTcpClient
import pymodbus
pymodbus.pymodbus_apply_logging_config("DEBUG")
client = ModbusTcpClient('*.*.*.*', port=*)
client.connect()
result = client.read_holding_registers(1, 10, slave=1)
print(result)
client.close()



2024-10-28 06:33:00,340 DEBUG tcp:169 Connection to Modbus server established. Socket ('*.*.*.*', *)
2024-10-28 06:33:00,341 DEBUG transaction:184 Current transaction state - IDLE
2024-10-28 06:33:00,341 DEBUG transaction:193 Running transaction 1
2024-10-28 06:33:00,341 DEBUG transaction:293 SEND: 0x0 0x1 0x0 0x0 0x0 0x6 0x1 0x3 0x0 0x1 0x0 0xa
2024-10-28 06:33:00,342 DEBUG base:250 New Transaction state "SENDING"
2024-10-28 06:33:00,342 DEBUG transaction:317 Changing transaction state from "SENDING" to "WAITING FOR REPLY"
2024-10-28 06:33:03,343 DEBUG transaction:327 Transaction failed. (Modbus Error: [Invalid Message] No response received, expected at lea
st 8 bytes (0 received))
2024-10-28 06:33:03,343 DEBUG base:92 Processing:
2024-10-28 06:33:03,345 DEBUG transaction:78 Getting transaction 1
2024-10-28 06:33:03,346 DEBUG transaction:258 Changing transaction state from "PROCESSING REPLY" to "TRANSACTION_COMPLETE"
Modbus Error: [Input/Output] Modbus Error: [Invalid Message] No response received, expected at least 8 bytes (0 received)

Op https://espeasy.readthedo.../Plugin/SerialHelper.html staat

HW Serial0: GPIO-3 (D9) <- TX / GPIO-1 (D10) -> RX: The regular serial port of the ESP. NB: Enable Serial port has to be disabled (unchecked) in Tools/Advanced settings for any plugin to be able to use this port!

die nog aan stond, nu niet meer, maar geen verschil. Log van ESP Easy geeft wel aan dat er een connectie plaatsvind:

code:

937937: Ser2Net: Client connected!
940814: Ser2Net: Client disconnected!

Iemand enig idee waar dit misgaat? Of misschien maak ik ergens een denkfout, eerste keer dat ik een ESP zo gebruik

[ Voor 25% gewijzigd door Raven op 28-10-2024 06:38 ]

[laserfreak]

Even helemaal zonder context. Je doet Modbus RTU en dus RS485. Dit is een half-duplex bus en je hebt 1 of 2 I/O pinnen nodig om de transceiver van 'richting' te veranderen. De FTDI kabel doet dit 'automagisch' in de FTDI converter maar jouw hardware wellicht niet. Heb je dit ingesteld/aangesloten?

[Septillion]

@Raven Die dingen werken ook zonder level shifting. Ook al Rx en Tx een triple check gegeven?

@laserfreak Het betreft hier geen RS485, gewoon TTL serial.

[Raven]

laserfreak schreef op maandag 28 oktober 2024 @ 14:28:
Even helemaal zonder context. Je doet Modbus RTU en dus RS485. Dit is een half-duplex bus en je hebt 1 of 2 I/O pinnen nodig om de transceiver van 'richting' te veranderen. De FTDI kabel doet dit 'automagisch' in de FTDI converter maar jouw hardware wellicht niet. Heb je dit ingesteld/aangesloten?

Elektrisch gezien is het TTL 5V (wat @Septillion al opmerkte), alleen het protocol is Modbus RTU. Als ik dit via FTDI-kabel doe, dan kan ik zonder problemen communiceren. Ik wil het echter via wifi (en dus serial server) doen zodat er geen pc vlakbij hoeft te staan.

Septillion schreef op maandag 28 oktober 2024 @ 14:33:
@Raven Die dingen werken ook zonder level shifting. Ook al Rx en Tx een triple check gegeven?

De ESP-module verwacht 3.3V, terwijl de ZPEM-module op 5V (power en communicatie) werkt en niet elke ESP is daar tegen beveiligd, daarom level-shifter ertussen .

Rx/Tx meerdere keren gechecked en als ik het script run, zie ik de Rx-LED kort oplichten dus er komt wat aan. Afgaand op de debug van 2e script, specifiek

Python:

2024-10-28 06:33:00,341 DEBUG transaction:293 SEND: 0x0 0x1 0x0 0x0 0x0 0x6 0x1 0x3 0x0 0x1 0x0 0xa

wordt het niet verstuurd zoals het moet. Manual van PZEM-module zegt

For example, the master sends the following command (CRC check code is replaced by 0xHH and 0xLL, the same below)
0x01 + 0x04 + 0x00 + 0x00 + 0x00 + 0x0A + 0xHH + 0xLL
Indicates that the master needs to read 10 registers with slave address 0x01 and the start address of the regi ster is 0x0000

Er lijkt dus wat mis te gaan m.b.t. opbouw van het te versturen commando.

[Septillion]

@Raven Ik denk inderdaad dat ik die van mij gemod heb Dit was ik alweer vergeten De datalijnen zijn volledig via een opto, dus alleen verlagen van de drive weerstand voor de RXi lijn is voldoende om hem op 3v3 te laten werken. De echte logica wordt gevoed uit de 230V.

Maar geen enkele ESP kan (officieel) tegen 5V, hoogstens sommige modules

[Raven]

@Septillion Ah

Ik heb inmiddels debug aangezet in het script dat van de FTDI kabel gebruik maakt. Die geeft als commando's voor het ophalen van de meetgegevens van de 5 modules achtereenvolgens:

code:

1-4-0-0-0-10-112-13
2-4-0-0-0-10-112-62
3-4-0-0-0-10-113-239
4-4-0-0-0-10-112-88
5-4-0-0-0-10-113-137

Omgezet naar hex:

code:

01 04 00 00 00 0A 70 0D
02 04 00 00 00 0A 70 3E
03 04 00 00 00 0A 71 EF
04 04 00 00 00 0A 70 58
05 04 00 00 00 0A 71 89

^ komt overeen met de docs, dus het lijkt mis te gaan met de Python lib's die het verkeerd versturen (zie debug vorige bericht).

Dus ik dacht, ik stuur 01040000000A700D via een TCP-socket naar de serial server en dan wachten op antwoord, helaas is het niet zo simpel Doc zegt

The command format of the master reads the measurement result is (total of 8 bytes):

Slave Address + 0x04 + Register Address High Byte + Register Address Low Byte + Number
of Registers High Byte + Number of Registers Low Byte + CRC Check High Byte + CRC Check
Low Byte.

en dat is waar 01040000000A700D uit bestaat en omgezet naar dec komt dat overeen met de debug van het FTDI-script.

edit: Ah wacht, met "\x01\x04\x00\x00\x00\x0A\x70\x0D" gaat de Tx-LED (na Rx-LED) aan, alleen script pikt niks op, blijft hangen bij recv(1024).

edit2: Geprobeerd de door de module teruggestuurde data (die niet aan lijkt te komen via de serial server) uit te lezen met de FTDI-kabel, dat levert wat op:

Python:

b'\x01\x04\x14\t\x16\x00\x00\x00'
b'\x00\x00\x00\x00\x00\x00\x00\x00'
b'\x00\x01\xf4\x00\x00\x00\x00\xb5'

Alleen waarom levert de serial server dat niet terug

[ Voor 16% gewijzigd door Raven op 29-10-2024 12:00 ]

[Raven]

@Septillion *pieeeeeep*
Volgens mij weet ik waarom de serial server niets teruglevert, er zijn Wemosjes in omloop waarbij de Rx voorzien is van een pull up weerstand, wat het sturen van data naar die pin een probleem maakt

Pin-swap naar GPIO13-D7 / GPIO-15-D8 zou kunnen, maar GPIO 15 dient tijdens boot low te zijn en met de logic level converter eraan is dat blijkbaar niet het geval.

Na werk https://www.letscontrolit.com/forum/viewtopic.php?t=8914 eens proberen, kijken of ie dan wél wil booten met D7 en 8 aangesloten.

[Septillion]

@Raven Hoezo is de pull up een probleem? De uitgang van de PZEM is open collector. En meeste level shifters ook...

[Raven]

Septillion schreef op donderdag 31 oktober 2024 @ 08:26:
@Raven Hoezo is de pull up een probleem? De uitgang van de PZEM is open collector. En meeste level shifters ook...

Dan heb ik mogelijk een logic level converter die dat niet heeft , ik kreeg de ESP niet zover data te ontvangen op de Rx. Zowel via logic level converter niet, als via spanningsdeler niet. De spanning op die lijn lijkt hooggehouden te worden.

Ben al aan het kijken naar de pin-swap naar D7/D8, alleen een van die 2 is nodig bij het opstarten, dus ff kijken of ik iets heb liggen dat vergelijkbaar is met een BC560 (zie linkje vorige bericht).

[Septillion]

@Raven Welke heb je?

Anders kant, heb je een soldeerbout? R8 verlagen naar 4k7 en je hebt geen shifter nodig

[Raven]

Septillion schreef op donderdag 31 oktober 2024 @ 09:07:
@Raven Welke heb je?

Anders kant, heb je een soldeerbout? R8 verlagen naar 4k7 en je hebt geen shifter nodig

http://msx-elektronika.pl/en/logic-level-converter en de ESP https://arduino-projekte..../d1-mini-pro-4mb-esp8266/

https://github.com/arendst/Tasmota/discussions/10567 doel je op? Het breadboard is toch groot genoeg , kan de logic level converter wel laten zitten. ERSA RDS80 overigens, heb ik al ik weet niet hoeveel jaar, leuk boutje. Wel van een andere (prijs)klasse dan de Weller WXsmart waar ik een tijdje terug op werk een soldeercursus mee heb gevolgd.

[Septillion]

@Raven Dat was wel de inspiratie, maar alleen R8 vervangen door 4k7 is al voldoende voor 3v3. Het is gewoon super wazig dat ze led + R10 parallel hebben gezet aan alleen R8 ipv parallel aan R8 + opto...

Verder ziet dat bord eruit als een standaard mosfet levelshifter dus dan is die ook open collector. Maar je moet wel kanaal 1 en 4 gebruiken, want volgens mij zijn 2 en 3 dus gewoon spanningsdelers...

[Raven]

@Septillion De methode met de transistor (BC557 i.p.v. hier niet aanwezige BC560) i.c.m. de swap naar D7/D8 (GPIO13/15) lijkt te werken, krijg data terug , al is het soms corrupt of incompleet lijkt het

Heb een CRC-check toegevoegd aan de code om de goede eruit te vissen tot ik weet waarom, al is zo'n check sowieso handig, kan later het 4e kanaal eens proberen.

edit: En van ene op het andere moment stuurt ie geen data meer
edit2: Jumperwire van de ground zat los

[ Voor 12% gewijzigd door Raven op 31-10-2024 15:23 ]

[Septillion]

@Raven Gebruik je nu kanaal 1 en 4 van de shifter voor de PZEM?

En als ik jouw was had ik het al geweten, dat had ik de weerstand al vervangen of er een 1k overheen gezet. Makkelijker dan met dingen klooien op een breadboard.

[Raven]

@Septillion Nee, nog niet, overigens werkt het weer, zat een draadje los

[Septillion]

Raven schreef op donderdag 31 oktober 2024 @ 15:25:
@Septillion Nee, nog niet

Is dat een antwoord op de kanalen of de weerstand?

En hehe, dat is dus precies onderdeel van het klooien op een breadboard

[Raven]

Septillion schreef op donderdag 31 oktober 2024 @ 15:26:
[...]

Is dat een antwoord op de kanalen of de weerstand?

En hehe, dat is dus precies onderdeel van het klooien op een breadboard

Beide, PZEM-module is niet aangemod en dat andere kanaal heb ik nog niet getest. Ben allang blij dat het nu via de serial server werkt, schoonheidsfoutjes (of hoe je het wilt noemen ) wegwerken komt nog.

De stekkers die ik aan het kabeltje van de PZEM had gekrimpt hebben een wat dunne pin, die schuift zo uit het breadboard.

De Python-code vereist overigens ook nog enige aandacht. Er is iets heel vaags aan de hand. Als ik het commando voor meetgegevens ("\x01\x04\x00\x00\x00\x0A\x70\x0D") handmatig intik en verstuur, dan werkt het. Laat ik het commando opgebouwd worden door code, waarbij het adres + functiecode + registeradres + aantalregisters achter elkaar worden gezet (in hex) plus het bepalen van de CRC, dan krijg ik exact hetzelfde maar de PZEM is het er niet mee eens, evenals een if om zowel het door code opgebouwde als handmatig ingevoerde commando met elkaar te vergelijken.

Het printen naar console verschilt ook, terwijl ze hetzelfde zouden moeten zijn. De door code opgebouwde (en door PZEM genegeerde) wordt op de console geprint als

Python:

\x01\x04\x00\x00\x00\x0A\x70\x0D

wat dus klopt. De handmatig ingevoerde (die wél werkt)

Python:

command2 = "\x01\x04\x00\x00\x00\x0A\x70\x0D"
print(command2)

ziet er op de console zo uit:

Python:

╔╝
p

Beide zijn (aldus Python) strings, de grootte verschilt om onbekende reden. De door code opgebouwde is 4x zo groot (aldus len() ). Voor zover ik kan zien moeten beide hetzelfde zijn, maar blijkbaar niet Maar dat wordt een beetje offtopic voor dit topic denk ik

[Septillion]

@Raven Dan ben je, denk ik, in een standaard valkuil getrapt

Werkelijk hex waardes sturen vs je hex waardes als ASCII versturen

Want als je in je console ziet "\x01\x04\x00\x00\x00\x0A\x70\x0D" dan heb je namelijk eigenlijk 0x5c 0x78 0x30 0x31 0x5c 0x78 0x30 0x34 0x5c 0x78 0x30 0x30 0x5c 0x78 0x30 0x30 0x5c 0x78 0x30 0x30 0x5c 0x78 0x30 0x41 0x5c 0x78 0x37 0x30 0x5c 0x78 0x30 0x44 verstuurt

[Raven]

@Septillion Hmm, verklaart dat waarom de handmatig getikte \x etc etc die exact hetzelfde is (of lijkt) als de output van de code die het commando genereert, toch als anders wordt gezien?

[Septillion]

@Raven Ja, een backslash is een escape character. \x heeft aan dat de waarde erachter als in hex gedefinieerde character gezien moet worden. Dus \x01 is één 8-bit character.

[Raven]

@Septillion ..... en dat gaat bij het handmatig intikken om de een of andere reden wel goed, maar bij het door een stukje code genereerde commando die ook van \x'en is voorzien niet, verwarrend Zal waarschijnlijk simpel te fixen zijn maar zie het op het moment niet.

[Septillion]

@Raven Ik heb nog geen code gezien hoe je het probeert te doen

[Raven]

Septillion schreef op donderdag 31 oktober 2024 @ 23:23:
@Raven Ik heb nog geen code gezien hoe je het probeert te doen

Woops, bij deze het relevante deel

Python:

Address = 1
Read_Input_Register = 4
Register_address = 0
Number_of_registers = 10

def modbusCrc(msg:str) -> int: # https://stackoverflow.com/a/75328573
    crc = 0xFFFF
    for n in range(len(msg)):
        crc ^= msg[n]
        for i in range(8):
            if crc & 1:
                crc >>= 1
                crc ^= 0xA001
            else:
                crc >>= 1
    return crc

command = ("0x%02x" % Address + "0x%02x" % Read_Input_Register + "0x%04x" % Register_address + "0x%04x" % Number_of_registers).replace("0x","").upper()
print("command:", command)

crc = modbusCrc(bytes.fromhex(command))
crc_bytes = crc.to_bytes(2, byteorder='little')
command = command + "%02X%02X"%(crc_bytes[0], crc_bytes[1])
print("command with CRC:", command)

command = r"\x" + r"\x".join(command[n : n+2] for n in range(0, len(command), 2))
print("command formatted:", command)

command2 = "\x01\x04\x00\x00\x00\x0A\x70\x0D"
print("command2:", command2)

Command2 is de werkende var met het commando, terwijl var command (wat dezelfde inhoud zou moeten hebben) niet werkt.

[Raynman]

Raven schreef op vrijdag 1 november 2024 @ 06:11:
Command2 is de werkende var met het commando, terwijl var command (wat dezelfde inhoud zou moeten hebben) niet werkt.

Je gebruikt voor command uiteindelijk een raw string literal, dus de backslash is dan letterlijk een backslash (waarde 0x5c zoals Septillion zei) en geen escape character meer.

De type hint van de functieparameter is fout, dat moet bytes (of iets vergelijkbaars) zijn ipv str, maar dat doe jij wel goed daar. Je kan dan gewoon met bytes blijven werken en voor consistentie kan je met de b-prefix van commando2 ook bytes maken. Met nog een klein beetje opschonen van de for loop en de initiële samenstelling van command (waarom vier keer "0x" typen en dan replace("0x", "")?) krijg ik dan:

Python:

Address = 1
Read_Input_Register = 4
Register_address = 0
Number_of_registers = 10


def modbusCrc(msg: bytes) -> int:  # https://stackoverflow.com/a/75328573
    crc = 0xFFFF
    for byte in msg:
        crc ^= byte
        for _ in range(8):
            if crc & 1:
                crc >>= 1
                crc ^= 0xA001
            else:
                crc >>= 1
    return crc


command = bytes.fromhex(
    f"{Address:02x}{Read_Input_Register:02x}{Register_address:04x}{Number_of_registers:04x}"
)
print("command:         ", command)

command += modbusCrc(command).to_bytes(2, byteorder="little")
print("command with CRC:", command)

command2 = b"\x01\x04\x00\x00\x00\x0A\x70\x0D"
print("command2:        ", command2)

print(command == command2)

Je kunt voor (debug) printen van bytes ook de .hex()-methode gebruiken.

[Septillion]

@Raven Je gebruikt allemaal string tools om je huidige 'command' op te bouwen, dat zal je dus niet moeten doen.

Zou ik het zelf gelijk als hex variable declareren in een bytes object. Dan kan je het daarna gewoon aan elkaar plakken:

Python:

Address = (1).to_bytes(1, 'big')
Read_Input_Register = (4).to_bytes(1, 'big')
Register_address = (0).to_bytes(2, 'big')
Number_of_registers = (10).to_bytes(2, 'big')

def modbusCrc(msg:str) -> int: # https://stackoverflow.com/a/75328573
    crc = 0xFFFF
    for n in range(len(msg)):
        crc ^= msg[n]
        for i in range(8):
            if crc & 1:
                crc >>= 1
                crc ^= 0xA001
            else:
                crc >>= 1
    return crc

print(Number_of_registers)
command = Address + Read_Input_Register + Register_address + Number_of_registers
print("command:", command)

crc = modbusCrc(command).to_bytes(2, 'little')
print("CRC: ", crc)
command = command + crc
print("command with CRC:", command.hex(' '))
print("command with CRC string:", command.decode())

command2 = "\x01\x04\x00\x00\x00\x0A\x70\x0D"
print("command2:", command2)

print(command.decode() == command2)

[Raven]

@Raynman @Septillion Thanks voor 2 werkende voorbeelden

Je gebruikt voor command uiteindelijk een raw string literal, dus de backslash is dan letterlijk een backslash (waarde 0x5c zoals Septillion zei) en geen escape character meer.

Uit nieuwsgierigheid, had ik met de code die ik had, nog iets kunnen doen zodat de inhoud van command alsnog goed verwerkt werd? Een of andere conversie?

(waarom vier keer "0x" typen en dan replace("0x", "")

Schoonheidsfoutje , erin geslopen toen ik met het vinden van de juiste hex-format bezig was.

Je gebruikt allemaal string tools om je huidige 'command' op te bouwen, dat zal je dus niet moeten doen.

Ah ja, dat was achteraf gezien niet echt handig inderdaad,

[Septillion]

@Raven Als je verder gewerkt had met de bytes.fromhex(command) als het command en daar weer de twee bytes (als bytes en niet als hex ASCII) aan geplakt had was je er denk ik ook.

Maar hele operatie om het naar een string met hex representatie om te schrijven maakt het naar mijn idee niet duidelijker

[PCan]

2 vragen;
Zie afbeelding a.j.b.
Moet ik jumper J5 nu wel of niet verwijderen, voordat ik de 3,3V voeding op de klemmen 3V3 en GND van de C6 inschakel?

Is klem GPIO2 een juiste keuze voor de gele sensordraad (DQ)?

Deze lijkt het meest overeen te komen met het voorbeeld op een ESP32

Heeft niet met HA te maken => schopje

[ Voor 3% gewijzigd door Septillion op 17-11-2024 15:10 ]

[Septillion]

@PCan Van waar heb je de tekst? En waar zit überhaupt J5?

[PCan]

@Septillion J5 is een Jumper die tussen de voeding zit. Als je die eruit trekt, doet niets het meer.
Hij is dus bedoeld om stroom in Amp. te meten.
Die teksten komen uit de diverse bestanden over de ESP32-C6-DevKitC-1.
Bijvoorbeeld van Github.
Ik zal eens zoeken of er een beter topic is om mijn vragen in te deponeren.
Ik heb nu via ESP-IDF "Hello World" example op het bord geflashed.

[Septillion]

@PCan Je bent al verplaatst

Maar het is dus onderdeel van die voedingsmodule tussen de ESP en 9V blok?

[PCan]

@Septillion Nee. Deze zit op de ESP-C6 devicekitC-1.
Zeg maar die 2 gele puntjes op de afbeelding, net onder de processor.

Ik krijg alleen contact als ik de USB-C kabel erin stop.
Blijkbaar kan hij nog geen contact maken via WiFi of Zigbee.
Heb in ESPhome gezocht, maar die ondersteund, na 4 jaar (2020), deze DevKit nog steeds niet.
Mag geen gegeven paard in de bek ....., maar wel jammer.
Ook het Hello World example staat niet in PlatformIO, alleen in de stand alone versie van ESP-IDF.
Er zit nl geen platformio.ini bij.

Anders kon ik kijken of ik e.e.a. zou kunnen ombouwen.
https://next.esphome.io/components/sensor/dallas_temp.html kent hij wel.

Maar, iemand enig idee of GPIO2 de juiste pin is voor de Data van de Sensor?

[ Voor 71% gewijzigd door PCan op 17-11-2024 19:55 ]

[Septillion]

@PCan Ahhhh, dan die lekker laten zitten. Enig moment dat je die eraf wilt doen is dus om een stroommeter tussen die twee pinnen te hangen om het verbruik van alleen de ESP te meten.

En gezien Zigbee nogal wat voeten in de aarden heeft om te implementeren zal dat de reden zijn dat de C6 nog niet in ESPhome zit. Zigbee in ESPhome zou heel tof zijn maar heb je feitelijk gewoon een nieuwe framework voor nodig.

Verder spreekt die DS18B20 gewoon 1-wire, daar is geen functionaliteit voor in hardware. Dus elke GPIO pin (zonder gekke bijzaken) kan gebruikt worden.

[Raymond P]

Fwiw de C6 kwam op de markt in begin '23, 2 jaar na de announce. Support in IDF was er toen nog niet. Ergens eind '23 was er pas support in Arduino (ter indicatie).

Je had je antwoord overigens ook in de user guide of datasheet kunnen vinden.

[PCan]

@Raymond P Dat jaartal komt uit YouTube: ESP32 Guide 2024 | Choosing and Using an ESP32 Board

Ja, die tekst komt uit de user guide, maar is onduidelijk.
Er wordt aangeraden om de J5 jumper te verwijderen als je een externe voeding aansluit op 3V3 en GND.

Wat w.s. bedoeld wordt is dat je dat KAN doen als je wil weten hoeveel stroom (Amp.) er door de ESP getrokken wordt.

[ Voor 22% gewijzigd door PCan op 18-11-2024 08:25 ]

[Raymond P]

@PCan Ik heb die video niet bekeken, maar de press release van Espressif geeft wellicht een duidelijke tijdlijn.

Bij het lezen van user guides en datasheets is het handig om een paragraaf in z'n geheel te lezen. Als je er alinea's uit trekt of zelfs enkele zinnen dan mis je de context.

Uit de component list:


Wat linkt naar paragraaf:


De twee scenario's die van toepassing zijn op de twee mogelijke settings van J5 zijn hier toch duidelijk verwoord?

N.b. absoluut niet aanvallend bedoeld, ik heb zelf ook veel te lang geklooid door manuals te skimmen/scannen.
Bij dit soort dingen stoot je je je tenen omdat er vaak geen woord extra in staat die je mag/kunt missen.

[PCan]

@Raymond P Thanks.
Ik kan die on board temperature sensor die in de press release genoemd wordt, niet vinden op mijn C6-DevKitC=1
Wat is de eenvoudigste manier op WiFi aan de praat te krijgen?
Welk bestand (Platformio met ES-IDF ) moet ik daarvoor editeren?

P.s. Ik heb inmiddels een hobbysetje met een ESP8266-12E Module binnen en krijg morgen nog een ESP32-C3.
Beiden worden vlgns mij wél ondersteund in ESPhome.
Al lees ik dat de C3 geen interne debug ondersteuning heeft. Geen idee of ik daar dan weer problemen mee ga krijgen.

Arduino IDE geinstalleerd, ESP32C6Dev gekozen. Werkt prima. Geen gezeur. Duidelijke interface.

[ Voor 42% gewijzigd door PCan op 19-11-2024 21:33 ]

[Raymond P]

@PCan Ik heb geen recente ervaring met PlatformIO.
Voor esp-idf is er wel een korte start te vinden in hun repo.

De onboard temperatuur sensor van esp32's is ook een toggle in IDF, by default niet beschikbaar afaik. Ook vooral bedoeld om chip temperatuur te meten, niet noodzakelijk ambient temperature.

[PCan]

We zijn weer een stapje verder. Tips zijn altijd welkom.
(3x Dallas DS18B20 waterdicht op ESP32-C6-DevKitC-1 N8. Via Arduino.

[ Voor 18% gewijzigd door PCan op 20-11-2024 19:37 ]

[synoniem]

Septillion schreef op zondag 17 november 2024 @ 20:07:
@PCan Ahhhh, dan die lekker laten zitten. Enig moment dat je die eraf wilt doen is dus om een stroommeter tussen die twee pinnen te hangen om het verbruik van alleen de ESP te meten.

En gezien Zigbee nogal wat voeten in de aarden heeft om te implementeren zal dat de reden zijn dat de C6 nog niet in ESPhome zit. Zigbee in ESPhome zou heel tof zijn maar heb je feitelijk gewoon een nieuwe framework voor nodig.

Verder spreekt die DS18B20 gewoon 1-wire, daar is geen functionaliteit voor in hardware. Dus elke GPIO pin (zonder gekke bijzaken) kan gebruikt worden.

Vraag me af of het niet in ESPhome zit. Ik zie bij de update van ESPhome van gisteren in de List of changes o.a. dit staan:

code:

[fix] ESP32-C6: internal temperature reporting esphome
[fix] ESP32-C6 BLE compile error

Dan zou ik verwachten dat misschien niet alle functies ondersteund worden maar dat hij wel al in het ESPhome framework zit.

[Septillion]

@synoniem Ahh, maar ik denk dat die onder beta hoort te staan ofzo. Want zie de esp32-c6-devkitc-1 wel in de huidige Platform.io versie 6.9.0 staan. Maar ESPHome linkt nog steeds naar Platform.io v5.3.0 en die ondersteund het niet.

Maar goed, überhaupt compilen is maar stap 1. Om werkelijk Zigbee te gebruiken zal er een compleet Zigbee framework moeten komen incl wat kan en wat niet kan met Zigbee. Het is nogal wat anders dan het vrije Wifi.

[RobertMe]

Septillion schreef op donderdag 21 november 2024 @ 09:22:
@synoniem Ahh, maar ik denk dat die onder beta hoort te staan ofzo. Want zie de esp32-c6-devkitc-1 wel in de huidige Platform.io versie 6.9.0 staan. Maar ESPHome linkt nog steeds naar Platform.io v5.3.0 en die ondersteund het niet.

Maar goed, überhaupt compilen is maar stap 1. Om werkelijk Zigbee te gebruiken zal er een compleet Zigbee framework moeten komen incl wat kan en wat niet kan met Zigbee. Het is nogal wat anders dan het vrije Wifi.

Was in ieder geval ESP-IDF niet ook extreem beperkt in het gebruik van Zigbee? In de zin van dat alles predefined is voor velden. Je kunt dus wel zeggen "in het temperatuur veld stuur 15,3" maar niet "in veld 24 stuur numerieke waarde 15,3". Waardoor je ook gebonden bent aan de specifieke zaken die in IDF zitten. En bv een ESP met meerdere temp sensoren zou dan niet kunnen, omdat er bv in de Zigbee standaard maar 1 specifiek veld is dat is vastgelegd als "temperatuur" en IDF ook alleen dat veld kan gebruiken en je dus niet een specifiek veld zelf kunt opgeven. Dat beperkt ee mogelijkheden dus ook nogal enorm.

Nog los van dat volgens mij niet alles uit Zigbee is geïmplementeerd, in de zin van zeer specifieke velden / toepassingen.
En dat vervolgens zaken van buiten de specificaties al helemaal niet kunnen (ik heb een "bed sensor" met een HX711, maar zit in de Zigbee standaard iets van bv gewicht / druk / <eigenlijk is het gewoon een nummertje dat nergens voor staat maar je wel kunt kalibreren naar gewicht>).

[PCan]

Ok, ik heb dus gisteren Dallas sensoren op de C6 geïnstalleerd. Dat werkt nog steeds prima hoor.

Vandaag heb ik een C3 DevKitM met behulp van YouTube: Setting up ESPHome for Home Assistant - ESP32 SMART Home Made EASY! op WiFi aan het werk gekregen met ESPHome.
Het ging niet makkelijk. Wilde eerst de poort niet openen en daarna geen contact met de WiFi router maken. Maar om een of andere reden deed hij het ineens wel. Ik vermoed dat mijn PC nog ff tijd nodig had om e.e.a. in te stellen of zoiets. Drivers of zo.
Ook mis ik het stuk code na Captive_portal (Zie YT video als je wilt).
Waarschijnlijk omdat ik ergens moest kiezen voor een fabrieksbestand.
Geen idee waar ik de rest vandaan moet halen. Kon het op de ESPHome website niet vinden.
Dus kan ik nog niet met het LED tje spelen.
Dingen gingen ook soms anders bij mij, dan in die video.

Mijn vraag. Ik heb in de Arduino.ide Schets gemaakt met behulp van bibliotheek beheer.
Dat is allemaal in C++. Dat kan ook in yaml?
https://esphome.io/components/sensor/dallas_temp.html
Dat ziet er veel strakker uit.

Kan je op een of andere manier het C++ bestand converteren naar .yml?

[laserfreak]

Ik deel heel graag een van mijn laaste projecten op basis van een ESP32-S3. Ik heb een gateway gemaakt die wordt gebruikt met wetenschappelijke sensoren. De gateway zit in een op maat gemaakte behuizing die tot 100 meter onder water kan gaan. Door middel van een druksensor kan de gateway automatisch gegevens doorsturen via LTE-M en/of NB-IoT.

Verder heb ik op de gateway verschillende hardware protocollen voorzien:
- RS232
- RS485
- SDI-12
- CAN

De module is een 'Walter' module, die ik vorig jaar heb gemaakt. Hier alvast wat foto's:







Op dit moment hebben we de gateway al met succes getest op het IJsselmeer en in de plaatselijke beek

[c-nan]

Ik ben op zoek naar een microcontroller die USB-powered is. Verder zo klein mogelijk. Ik wil er een GoPro remote mee maken.

Als ik zoek op esp8266/ESP32 kom ik verschillende formaten tegen.

Daarnaast kom ik termen tegen als Wemos en NodeMCU tegen.

Ik heb geen wifi nodig, enkel BLE.

Welke microcontroller heb ik dan nodig?

[jj85]

c-nan schreef op vrijdag 10 januari 2025 @ 16:03:
Ik ben op zoek naar een microcontroller die USB-powered is. Verder zo klein mogelijk. Ik wil er een GoPro remote mee maken.

Als ik zoek op esp8266/ESP32 kom ik verschillende formaten tegen.

Daarnaast kom ik termen tegen als Wemos en NodeMCU tegen.

Ik heb geen wifi nodig, enkel BLE.

Welke microcontroller heb ik dan nodig?

Ben zelf wel fan van de esp32-c3 super mini. Heeft ook BLE (en wifi).
Mooi klein en ongeveer 2 euro bij Ali

[The - DDD]

Hier een LilyGo T5 4.7 v2.3 aan de praat. Deze werkt net even anders dan de oudere v2.2.

Code staat hier: https://github.com/AppForce1/lilygo-t5-47-plus-esphome

Het was echt even zoeken en puzzelen om de boel aan de gang te krijgen.

Hardware:
- LilyGo T5: https://lilygo.cc/products/t5-4-7-inch-e-paper-v2-3
- Accu: (kale link) https://www.amazon.nl/dp/B0BG82T39Y

Enige wat ik moest doen was even de bij de LilyGo geleverde j2 stekker aan de accupack solderen.

De LilyGo heeft een charge controller aan boord en deze pack over charge beveiliging. Dus plug en play.

En natuurlijk een mooie screenshot.

Ik heb deep sleep heel mooi aan de praat met een nachtelijke downtime en enkel een screen refresh als er daadwerkelijk nieuwe data is.



Ook de status van het device is mooi zichtbaar in Home Assistant.



Oh ja ook nog een binary sensor waarmee ik deep sleep kan uitschakelen zodat het makkelijker firmware uplaoden is. Switch aanzetten, knopje op device druken. Dat knopje triggert een wake-up en refresh. En deep sleep is verboden, dus hij blijft actief.

[ Voor 7% gewijzigd door The - DDD op 26-01-2025 21:37 ]

[superjoost]

Ik gebruik de watermeter toepassing van huizebruin nu sinds c.a. 1 jaar. Ik gebruik Home assistant om de meter uit te lezen. Dit bevalt erg goed. Echter: Ik ben er onlangs achtergekomen dat de meting een tijdje blijft hangen nadat het verbruik gestopt is. Weet iemand waar dit door kan komen? Je ziet het in onderstaande afbeelding. Tijdens het werkelijke verbruik varieert het volumedebiet een klein beetje. Als het verbruik gestopt is en de meting blijft hangen zie je een stabiele, horizontale lijn.

yalerta schreef op vrijdag 20 oktober 2023 @ 13:34:
[...]


De huizebruin.nl esp middels een WemosD1 en een Hilink voeding samen ingebouwd in een stekker doosje van een defecte voeding. 3mm (audio) plugvoetje erbij en verbonden met de sensor via een 4x0,5 of 0,8 mm bel of telefoonkabel naar de sensor op de watermeter. lengte circa 3 meter.

LET OP! Degelijk knutselen met 5V en 230V netspanning in 1 doosje is NIET aan te raden voor de niet ervaren hobbyist die onvoldoende met de gevaren bekend is !

Bovenstaande opbouw inmiddels langer als een jaar in werking.
Wel enige maanden terug een uitval gehad doordat mijn watermeter niet met de NPN sensor maar in de Elstar meter met een Reedcontact gemeten werd. Een nieuw sensorcontact loste het helaas niet op. Een dag een staafmagneetje in de watermeter op de plaats van de sensor zette alles weer in werking en gaat tot op de dag van vandaag foutloos.

Een zelfde opstelling met de NPN sensor, bij familie geplaatst, heeft in datzelfde jaar geen uitval gehad.

[ Voor 13% gewijzigd door superjoost op 28-02-2025 11:32 ]

[delodic]

Ik heb een charger gekocht voor een lipo accu. Deze heeft 3 output currents: 50, 200 en 500. Ik wil deze op 500 zetten (moet kunnen met de 2500mAh accu waarvoor ik m wil gebruiken).

you can easily switch between 3 output currents (the default output current is 50mA) by selecting different bonding pads on the back

Ik snap alleen niet hoe ik die 'bonding pads' gebruik. Ze hebben een gleuf alsof je met een schroevendraaier aan de gang kan. Maar ik check t hier toch maar even voor ik m sloop

[r_255]

@delodic

Lijkt me een soldeer brug, Dus een druppel soldeer op de gewenste pad.

[Gizz]

@delodic die moet je aan elkaar solderen. Zie hier voor een foto.

[delodic]

Ah top. Thanks beide!

[KabouterSuper]

Ik ben aan het zoeken naar een esp32(-achtige) met zoveel mogelijk gpio pinnen, In de buurt van 100 pinnen. Ik wil kijken of ik een low budget HIL simulatie/test systeem kan bouwen (Wikipedia: Hardware-in-the-loop simulation). Elke pin representeert dan een input (door de gebruiker of door een externe sensor) waar op gereageerd moet worden. Bij een auto zou dat kunnen betekenen dat je een remactie simuleert door de snelheid, rempedaal, indrukking vering, etc via wiskundige formules aan de pinnen aan te leveren en dan te onderzoeken wat de auto gaat doen (remlicht, abs, etc).

De gewone esp32-S3 heeft zo'n 45 pinnen. De aangekondigde P4 heeft er 55. Maar ik ben op zoek naar meer pinnen. Iemand een idee of er iets betaalbaars bestaat wat lijkt op een esp32 maar meer pinnen heeft?

[laserfreak]

Een youtuber die ik eigenlijk niet kende heeft een filmpje gemaakt over mijn project. Ik heb voor alle duidelijkheid niet betaald voor dit filmpje:

@KabouterSuper Als je zoveel pinnen zoekt dan zal een I/O expander via I2C of een schuifregister een betere optie zijn dan een chip te zoeken met heel veel pinnen.

[Ruitenwisser]

KabouterSuper schreef op donderdag 19 juni 2025 @ 08:58:
Ik ben aan het zoeken naar een esp32(-achtige) met zoveel mogelijk gpio pinnen, In de buurt van 100 pinnen. Ik wil kijken of ik een low budget HIL simulatie/test systeem kan bouwen (Wikipedia: Hardware-in-the-loop simulation). Elke pin representeert dan een input (door de gebruiker of door een externe sensor) waar op gereageerd moet worden. Bij een auto zou dat kunnen betekenen dat je een remactie simuleert door de snelheid, rempedaal, indrukking vering, etc via wiskundige formules aan de pinnen aan te leveren en dan te onderzoeken wat de auto gaat doen (remlicht, abs, etc).

De gewone esp32-S3 heeft zo'n 45 pinnen. De aangekondigde P4 heeft er 55. Maar ik ben op zoek naar meer pinnen. Iemand een idee of er iets betaalbaars bestaat wat lijkt op een esp32 maar meer pinnen heeft?

Zoals @laserfreak aangeeft zou ik met extra HW werken dan een microcontroller te zoeken met meer dan 100 GPIO's, anders zoek je naar microcontrollers met 144 of 176 pinnen. Je zou bv ook met een multiplexer kunnen werken en dan vlug schakelen tussen de verschillende inputs. Maar zoals ik het lees wil je eigenlijk ook ADC's om een spanning op te meten.

[KabouterSuper]

laserfreak schreef op donderdag 19 juni 2025 @ 09:08:
Een youtuber die ik eigenlijk niet kende heeft een filmpje gemaakt over mijn project. Ik heb voor alle duidelijkheid niet betaald voor dit filmpje:

[YouTube: You’ve Never Seen Cellular Like This]

Cool. De landkaart in het begin is erg verhelderend voor mensen uit Miami, nu weten ze tenminste waar België ligt (not).

@KabouterSuper Als je zoveel pinnen zoekt dan zal een I/O expander via I2C of een schuifregister een betere optie zijn dan een chip te zoeken met heel veel pinnen.

Thanks, daar was ik al een beetje bang voor. Ik ga eens kijken naar een i/o expander.

[toekie]

Hoi allen,

Ik heb even zitten zoeken op het forum maar kan nergens iets van een discussie vinden over GUI software voor noobs zoals ik. Ben gewend met de nextion editor te werken (oude versie), maar die nextion screens zijn sinds de pandemie erg duur geworden terwijl ze ook nog een trager zijn dan de andere keus, CYD met een esp32 erin en dan met LVGL.
Ik heb tot nu toe GUI guider van nxp gevonden, EEZ een opensource project GUI tool, deze lijkt tot zover het makkelijkste en dan is er nog Squareline studio die is betaald maar hebben een 30 dagen trail.
Probeer mijn nextion schermen te vervangen voor esp based schermpjes met lvgl scheelt wat hobby centen.

Iemand ervaringen met een van de 3 of wellicht alles 3 deze GUI programmas?
Alvast bednakt voor de feedback!

[toekie]

Vervelend dat je geen posts meer kunt editen maarja. Ik heb het al een keuze gemaakt. Die van nxp werkt alleen voor nxp chips dus niet voor hobby, en die 30 dagen trail gaat te kort zijn voor mij en die lincence is weer peperduur voor hobby geknutsel voor 1 a 2 projecten. Het wordt die EEZ studio.

[Rukapul]

Iemand wel eens een esp8266 gekocht wat een esp32 bleek te zijn?

In 2023 heb ik wat NodeMCU v3 met esp8266 gekocht. Gewoon hetzelfde als ik eerder wel eens kocht.

Nu ben ik er echter tegenaan gelopen dat die dingen blijkbaar esp32 chips aan boord hebben. Het ziet er precies uit als de NodeMCU v3 die ik eerder kocht, op de chip staat 8266, maar de module identificeert zich als esp32 en het werkt ook alleen maar als ik er een EspEasy firmware naartoe flash die geschikt is voor esp32

[vonkkie]

Esp32 is sneller en wat meer opties niet over klagen

[Raymond P]

vonkkie schreef op vrijdag 19 september 2025 @ 06:27:
Esp32 is sneller en wat meer opties niet over klagen

Nee. Als een NodeMCU V3 ESP8266 besteld is dan hoor je die ook te ontvangen.

Nu valt er wel iets te zeggen voor je case als er daadwerkelijk een NodeMCU V3 ESP32 ontvangen was, maar dan zou het PCB design ook significant anders moeten zijn.
In dit geval is het overduidelijk een namaak product (al dan niet met 'enkel' een verkeerde rf shield), als het reference design niet expliciet gevolgd (of verbeterd) is kan dit leiden tot o.a. antenne/signaal problemen.

Bij namaak worden ook vaak inferieure onderdelen gebruikt. Met name de voltage converter wordt vaak op bezuinigd en wordt gekozen voor een model dat niet/nauwelijks het piekvermogen vraag van de radio kan leveren.
Naar mijn ervaring leidt dit (sowieso op langere termijn) altijd tot problemen, Een van de ergste dingen die kunnen gebeuren is dat de LDO faalt en er gewoon 5V of hoger op je ESP (en randapparatuur) staat, standaard is een slechte WiFi verbinding.

@Rukapul Dat heb ik nog niet meegemaakt, maar het verbaast mij niet.