Lesing av AMS data (AMS/HAN -> IoT)

[tronde]

Jeg la inn 6.0 mellom 1300 og 1400 idag, og feilen er etter det. Jeg la inn 6.1 mellom 1700 og 1800 mener jeg å huske.

 

Den er er der fortsatt, selv etter flere omstarter,

 

 

 

 

 

Nå sitter jeg her og prøver å liste ut litt om GPIO-settingen for ESP32.

Det midterste feltet for RGB ser ut til å være data fra HAN, men hva er de to andre?

 

Jeg får ikke DS18B20 til å funke. Er den ekstremt kresen på fake? Mine er helt sikkert fake, men de funker i andre applikasjoner. Må jeg konfigurere noe? Det er et felt for temperatur, men det ser ikke ut til å hjelpe. Er det for analog sensor?

 

 

 

Edit:

Det plager meg ikke, men ESP vises som grå med ESP32, og grønn for ESP8266, 

 

 

Endret 9. desember 2021 av tronde

[gskjold]

9 hours ago, tronde said:

Jeg la inn 6.0 mellom 1300 og 1400 idag, og feilen er etter det. Jeg la inn 6.1 mellom 1700 og 1800 mener jeg å huske.

 

Den er er der fortsatt, selv etter flere omstarter,

Når verdien først har blitt lagret så er løpet kjørt uansett, så får vi enn så lenge fundere på hva som skjedde der. Jeg klarer ikke se noe logisk grunn til at det skulle skje, så jeg sikter på å rulle ut 2.0.0 i dag og se om det dukker opp flere med samme sak slik at det blir lettere å identifisere feilen.

 

9 hours ago, tronde said:

Nå sitter jeg her og prøver å liste ut litt om GPIO-settingen for ESP32.

Det midterste feltet for RGB ser ut til å være data fra HAN, men hva er de to andre?

Rød brukes for feil. Ser jeg har glemt å skrive om det i Wiki, skal fikse det.

- Ett blink: Ingen data fra HAN siste 30s

- To blink: Feil med MQTT

- Tre blink: Ikke tilkoblet wifi.

Den har 10s pause mellom hver feilkode

 

Den grønne blinker når det kommer gyldig data fra HAN. Pakker med feil blinker den ikke på.

Den blå er faktisk ikke i bruk.

 

9 hours ago, tronde said:

Jeg får ikke DS18B20 til å funke. Er den ekstremt kresen på fake? Mine er helt sikkert fake, men de funker i andre applikasjoner. Må jeg konfigurere noe? Det er et felt for temperatur, men det ser ikke ut til å hjelpe. Er det for analog sensor?

Litt om temp sensorer her: https://github.com/gskjold/AmsToMqttBridge/wiki/Temperature-sensors

Har du pullup motstand koblet på Data? Legg inn GPIO pin i "Temperature" under GPIO settings. Jeg har selv 20stk fake DS18B20 koblet til min med 4.7k pullup i hver ende av snoren. Bruker ett par cat5 for GND og Data og separat leder for Vcc. Husk å bruke 3.3v på Vcc.

 

Analog temperatur sensor kan også konfigureres i GPIO settings, eget felt "Analog temp" for GPIO pin til denne.

[Hårek]

Kanskje av interesse - oppdaget dette i går.

Timesutlesning ga samme verdi to ganger. Forventet utregning ga da null fra 7 - 8, og dobbelt fra 8 - 9. 

07:00;AIDON_V0001;...;2021-11-08 07:00;75781,984;...
08:00;AIDON_V0001;...;2021-11-08 08:00;75781,984;...
09:00;AIDON_V0001;...;2021-11-08 09:00;75790,922;...
 

Sjekket med data fra nettselskapet, der vises normale verdier. Så det ser ut som en bug for HAN data.

[tronde]

gskjold skrev (7 timer siden):

 

Litt om temp sensorer her: https://github.com/gskjold/AmsToMqttBridge/wiki/Temperature-sensors

Har du pullup motstand koblet på Data? Legg inn GPIO pin i "Temperature" under GPIO settings. Jeg har selv 20stk fake DS18B20 koblet til min med 4.7k pullup i hver ende av snoren. Bruker ett par cat5 for GND og Data og separat leder for Vcc. Husk å bruke 3.3v på Vcc.

 

Analog temperatur sensor kan også konfigureres i GPIO settings, eget felt "Analog temp" for GPIO pin til denne.

Ja, jeg har pullup og 3,3V. har brukt DS18B20 flere ganger, og jeg har hatt mine runder med krangling om sensorer som helt utvilsomt er fake, så jeg kjenner problemene med ebay/ali-utgavene. Har blant annet noen som ikke godtar mer enn maks 3 av den typen i samme systemet, men som samtidig funker helt fint med 3 av sine + mange andre av en annen batch i ett system.

 

Skal se om jeg har noen fra en annen bestilling et sted som kan frigjøres. Det kan godt være at den batchen som disse kom i ikke funker med 3,3V. Når du klarer å drive 20, må det gå an å finne en som kan funke alene.

[tronde]

@gskjold

Oppgraderte ESP32 med upgradefunksjonen som fortale at ny versjon var tilgjengelig. Den funket greit, men API-nøkkel for strømpriser ble byttet ut med en "r" så prisene ble selvfølgelig borte.

 

I tillegg er det fortsatt varsel om  at ny versjon 2.0.0 er tilgjengelig, selv om det står i toppmenyen at det er v2.0.0 som er installert. Dette varselet vises også for ESP8266.

Endret 10. desember 2021 av tronde

[ArnieO]

Quote

Den blå er faktisk ikke i bruk.

For så vidt korrekt at firmwaren ikke gjør noe med den blå delen av en RGB LED.
 

På Pow-U og Pow-K er den blå delen av LEDen direkte koblet til innkommende HAN linje slik at den blafrer i når datagrammet ankommer fra måleren. Det gir en god visuell indikasjon på at måleren er åpnet og at datagrammene kommer som de skal.

Endret 10. desember 2021 av ArnieO

[tronde]

ESP32:

 

Da fant jeg noen andre DS18B20 som funker, og jeg kan flytte dem rundt til forskjellige GPIO. Da vet vi at det finnes noen som ikke liker 3,3V. Det er nok den typen som kalles "almost similar" der borte i Kina.

 

Jeg forstår at den verdien som vises på hovedskjermen er (valgbart) gjennomsnitt av alle sensorene. Når man kopler bort sensorene (simulerer brudd), blir den verdien stående, mens listen over alle sensorene viser N/A som er korrekt. Hovedskjermen burde vel også vise at noe mangler?

 

Kanskje skrive et par ord i Wikien om dette også?

[tronde]

Nå har jeg testet lysdiodene. Det ser ut som om man ikke kan sette høyere GPIO enn 15? 16 er alt opptatt, så jeg prøvde 17 som er fysisk nær, men det blir bare bare rør, for den lever sitt eget liv.

 

Hvis det er en grense, bør vel det også gjøres kjent.

[gskjold]

7 minutes ago, tronde said:

Nå har jeg testet lysdiodene. Det ser ut som om man ikke kan sette høyere GPIO enn 15? 16 er alt opptatt, så jeg prøvde 17 som er fysisk nær, men det blir bare bare rør, for den lever sitt eget liv.

 

Hvis det er en grense, bør vel det også gjøres kjent.

Grensen er implementer allerede. Tror det er 35. Du har sikkert HAN på uart2, og gpio17 er tx for uart2, så da er den opptatt.

 

Takk for gode innspill over, notert

[tronde]

@gskjold

Litt mer å fikse 😊

 

Da jeg holdt på med GPIO-settingen, var det noen ganger at API-nøkkel for strømprisene ble slettet, uten at jeg helt kan se hvorfor. Minner litt om det som skjedde da den ikke klarte å huske valgt prisområde.

 

Nøkkel ble erstattet med "r" da jeg oppgraderte til V2.0.0. I begge tilfelle forsvant også visningen av prisene.

 

*

 

I den generelle beskrivelsen av prosjektet på Github står det:

Later development have added Energy usage graph for both day and month, as well as future energy price. The code can run on any ESP8266 or ESP32 hardware which you can read more about in the WiKi.

 

Selv om det står i wikien, skader det nok ikke å presisere at strømpriser krever ESP32, for det gis inntrykk av at begge ESP-ene gir den funksjonen.

 

*

 

I wikien under "Meter configuration" står det "Substitute missing values - For IT/TT distribution system, calculate current for L2". 

 

Den funksjonen er ikke synlig i konfiguarsjonsmeyen. 

 

Jeg ser helst at den kommer tilbake, for det ser litt corny ut med negative strømmer som man ofte får når det er skjev belastning i nettet. To desimaler er også i overkant. Null desimaler er nok når svaret stort sett er helt utenfor.

 

 

*

 

I wikien under "Initial setup" står det "WiFi - SSID and PSK for the network you want your device to connect to. If you also want to set static IP, read more here"

 

Linken til https://github.com/WiFi-Configuration er død.

 

 

[tronde]

Jeg prøver med med MQTT, men skaller i veggen. For snart to år siden fikk jeg til noe, men nå er det full stopp...

 

Jeg vil prøve med ekstern broker, for jeg vil vise noe til dem som har fått et adapter av meg.

Ingen av brokerne ser ut til å like at mottaker er på samme IP som sender, men det løser seg ved å ha mottaker på mobildata. Da blir i alle fall ingen av dem koplet ned. broker.hivemq.com ser ut til å være samarbeidsvillig.

 

Jeg vet at sender og mottaker må ha samme Client ID.

 

Hva skal jeg sette inn i feltet for "Publish topic" i menyen for MQTT oppsettet?

Er det feltet for at jeg kan sende ut bare en verdi, eller et utvalg? Vil ikke MQTT normalt dytte ut alt som finnes?

 

 

Må jeg ha brukernavn og passord, eller er det valgfritt? Jeg forstår fra wikien at det er valgfritt.

 

 

Jeg prøver å få til noe med androidappen IoT MQTT Panel 

https://play.google.com/store/apps/details?id=snr.lab.iotmqttpanel.prod

 

Den funket for meg sist, mener jeg å huske.

 

Jeg får satt den opp til å holde en forbindelse åpen mot broker.hivemq.com som jeg har satt adapteret opp mot, og det viser grønn MQTT-status, så jeg regner nesten med at det grunnleggende funker i bakgrunnen.

 

 

Jeg ser denne listen over topics, men jeg har vel prøvd det meste av kombinasjoner uten å få til noe. 

https://github.com/gskjold/AmsToMqttBridge/wiki/MQTT-configuration

Er det ikke slik at {root} i listen egentlig representerer Client ID i MQTT?

 

Hva skal jeg skrive i sender og mottaker for å få ut verdien av importert aktiv effekt? 

Data som raw eller JSON?

 

 

 

I appen er et felt for Topic. Det skal vel samsvare med den verdien jeg vil hente fra MQTT, men hva skal stå der?

 

 

 

Hvis jeg velger JSON som data, ber den om JsonPath. Der blir jeg enda mindre klok, for det jeg finner på nett sier ikke noe fornuftig til meg.

 

 

 

 

 

 

 

 

 

 

 

 

Endret 11. desember 2021 av tronde

[Ingar]

Uvurderlig verktøy for MQTT håndtering:.  http://mqtt-explorer.com/  Her ser du alle meldingene og kan enkelt kopiere topics etc...

[tronde]

Etter mer knoting får jeg noe på skjermen.

Det ser ut som om JsonPath skal være §.data.P for effekten, og at §.data.U1 blir spenningen U1 osv basert på det som står i anførselstegn for liste 1 - 3 her ?

https://github.com/gskjold/AmsToMqttBridge/wiki/Message-formats

 

 

Jeg har fortsatt ikke helt skjønt hva som er korrekt for feltet "Publish topic", men ser at jeg må skrive det samme i begge ender, f.eks. /meter/import/

 

 

Litt utbrodering fra noen som skjønner mer av dette ville vært fint, for det kan godt være at jeg bare fikk til noe av ren flaks.

 

Hva er den praktiske forskjellen på payload som raw og Json, rent bortsett fra at jeg ikke ser noe med raw? Er raw binære data?

 

[gskjold]

Jeg skal ikke gå for dypt inn i hvordan MQTT fungerer her, for internett er full av beskrivelser og videoer om dette, men en kort oppsummering:

 

MQTT er meldingsutveksling og må ikke forveksles med database (som jeg opplever at noen gjør).

Det finnes to roller: Broker (server) og Client. Data sendes fra klient til broker og kan mottas av andre klienter som lytter på topic som det sendes data på.

 

Viktig: Client ID på de forskjellige klientene som kobler seg til samme broker MÅ være forskjellig.

 

Publish topic på AMS reader er "stien" (tenk filsystem) den skal publisere data til på MQTT og er det som blir referert til som {root} i wiki. (Skal bytte den til {publish topic} eller noe). Hvis man f.eks. skriver inn "/ams/reader" i publish topic så vil andre klienter som lytter på denne stien motta disse dataene. Hvis man f.eks. kun vil ha det som publiseres på {root}/meter/* så kan en klient i stedet lytte på "/ams/reader/meter".

 

Data format:

JSON - Alt kommer som JSON i én melding rett på publish topic

Raw - All data publiseres på hver sin topic i ren tallverdi (ikke binært) på topic spesifisert i MQTT config i Wiki under "Topics in raw mode".

[xibriz]

Dere burde roe ned bruken av å starte en topic med /

 

Det gir ingen mening og best practice er at man ikke bruker "leading slash".

[tronde]

Det med klient og broker forstår jeg, og det med unik ID er også forstått. Og jeg forstår det med å abonnere på meldinger med ønsket innhold, og at mange kan gjøre det hvis de kjenner den unike ID-en. Men det hjelper ikke noe når det som kommer ut i andre enden i beste fall blir gerblish.

 

Problemet med mange av beskrivelsene på nettet, er at det som virkelig betyr noe, ikke står der, eller ender opp i en masse linker som viser tilbake til noe som heller ikke sier noe for dem som ikke har sett lyset. Dette er noe jeg er veldig godt kjent med fra mitt eget fag som ikke er data/IT; det som synes helt innlysende for meg, er det nødvendigvis ikke for alle andre.

 

*

 

Er det slik å forstå at det som settes inn i feltet for "Publish topic" kan brukes til å filtrere hva som skal sendes ut, slik at man kan velge enten en verdi, flere verdier, eller alle verdiene som det er mulig å sende ut? 

 

 

Jeg fant ut nærmest ved et uhell at $.data.P ga meg filtrert verdi for importert aktiv effekt. Er det den "korrekte" måten å sette JsonPath, eller var det bare flaks?

 

 

Jeg har en mistanke om at det er flere der ute som ikke har helt kontrollen på dette, så det ville vært fint om noen som forstår kan skrive noen få ord så vi som ikke er flytende i MQTT kan sette opp noe som faktisk vil funke slik det er ment, og ikke bare er et resultat av flaks.

 

 

 

 

[frodegill]

Litt usikker på hva det er du trøbler med. Hvis du vil ha litt mere eksempler, kode og kommandoer kan du gjerne leke litt med min MQTT for strømpriser med mere. MQTT topics er dokumentert her , og helt nederst på siden står også en kommando (mosquitto_sub) og eksempel på hvordan du kan bruke denne for å motta MQTT-data. Selve dataene er en JSON, og jsonpath sier bare noe om hvor i json-strukturen du er interessert i data fra. Hvis du er interessert i C++-koden som dytter ut json til MQTT-serveren min finnes den her .

[tronde]

Det jeg savner et klart svar på er hva skal / bør stå i feltet for "Publish topic" for å være sikker på at det sendes ut data som er brukbare, og hva som er korrekt å skrive i feltet for JsonPath i klienten.

 

Etter mye filking satte jeg /meter/import/ i "Publish topic" og payload som Json. Er dette korrekt, eller fornuftig, eller bør det helst stå noe annet der?

 

 

I klienten fant jeg helt tilfeldig ut (via en uklar side på nettet som jeg ikke finner igjen i farta) at $.data pluss noe mer kunne være en løsning når payload var satt som Json. Jeg hadde da fått ut en strøm i den klienten som jeg tror er Json, og der fant jeg noe som kunne tyde på at dette "noe" kunne være en "P", så jeg prøvde med JsonPath  $.data.P, og fikk ut det som ser ut til å være korrekt verdi. I tillegg satte jeg /meter/import/ som Topic i klienten, pluss selvfølgelig at jeg hadde samme ClientID i klienten og adapteret.

 

Jeg mistenker at det bare er et par uklare detaljer som avgjør om det funker eller ikke, så derfor savner jeg en entydig "skriv dette så blir det OK" for å komme gang.

Når man først har noe som man er trygg på er korrekt eller fornuftig, er det tid for neste steg som er å fordype seg.

 

Jeg aner ikke om det jeg har gjort er slik det bør gjøres eller ikke, men det funket på et vis.

 

Endret 12. desember 2021 av tronde

[frodegill]

Sett Publish Topic til "meter/import" (uten innledende path separator). Jsonpath i klienten er jo helt avhengig av hva som sendes. Har du en Json som ser noe slik ut:

 

{

  data: {

    "P": <verdi>

  }

}

 

vil det være korrekt å bruke data.P som Jsonpath. I Node-Red er jeg da vant til å bruke msg.data.P, men det er godt mulig systemet du benytter da vil ha det på formen $.data.P

 

Merk at meldingen godt kan inneholde mere, f.eks

 

{

 "foo": "bar",

  data: {

    "P": <verdi>,

    "Q": <annen verdi>

  }

}

 

Jsonpath for P-verdien vil da være $.data.P , og Jsonpath for Q-verdien ikke uventet vil være $.data.Q

[tronde]

Fint.

 

Jeg har hittil bare brukt den androidklienten jeg linket til for å se om jeg fikk ut noe på en skjerm.

 

Der funker det med $.data.P for effekten og f.eks $.data.U1 for spenning U1 osv. etter det som står i anførselstegn i denne oversikten over liste 1 til 3.

https://github.com/gskjold/AmsToMqttBridge/wiki/Message-formats

 

Da er jeg vel på trygg grunn på klientsiden inntil videre.

 

 

Det som jeg synes er forvirrende her, er at det står ingen ting om "meter/import" under Json i wikien, men det er mange henvisninger til en hierarkisk struktur med blant annet "meter/import" i beskrivelsen over raw mode i denne linken

https://github.com/gskjold/AmsToMqttBridge/wiki/MQTT-configuration

 

Når jeg prøvde med klienten uten å aktivere Json, kom det ingen ting selv om det var valgt Raw i adapteret, så det forvirret enda mer.

 

 

Det ser ut som om om jeg får tak i de verdiene jeg vil med "meter/import", så da har jeg vel gjort ca. rett da, selv om det ble med en ekstra "/"

 

 

Da kan jeg grave videre i hva for noe fornuftig jeg kan få ut av dette i forvisning om at det grunnleggende er riktig. Selv om jeg skjønner ca. hvordan MQTT er ment å virke, er det alltid noen detaljer som mangler. 

 

 

 

@gskjold

 

Bug i henting av strømpriser. Morgendagens priser ble ikke hentet inn før jeg tok omstart av interfacet.

Det er det interfacet jeg brukte til prøve MQTT, og MQTT var aktiv hele tiden, men jeg vet ikke om det har en sammenheng.

 

API-nøkkel var lagret før jeg tok omstart, så det jeg har gjort med MQTT ser ikke ut til å spise den opp slik GPIO-config noen ganger har gjort.

 

Jeg sjekket at ENSTOE hadde publisert nye priser før jeg tok omstart.

[tronde]

Nå er det mulig at jeg er enda mer forvirret enn før, men jeg prøver... Vær snille og bær over med min uvitenhet.

 

Er det slik at "Client ID" egentlig ikke er så viktig? Jeg kan skrive hva som helst der, og det behøver ikke å samsvare med hva jeg har satt opp i klienten der hvor jeg setter opp adressen til broker. Jeg får i alle fall ut data uansett. Er det slik at den Client ID-en egentlig bare har en verdi for meg ved at brokeren skal kunne sende meg data som jeg har mistet, hvis jeg ber om at den skal ta vare på dem? Er det slik at hver eneste tilkopling til en broker skal ha sin unike ID for at den skal kunne skille dem?

 

 

Og at det som egentlig gir den unike identifikasjonen for min måler er hva jeg velger å skrive inn i feltet for "Publish topic"? 

Jeg kan for eksempel skrive "trondsaidon" der, og hvis jeg skriver det samme i klienten, så vil klienten finne de dataene hos brokeren, og sende dem til alle som ber om dem, og at Client ID ikke har noe som helst med dette å gjøre?

 

 

Da er det vel veldig dumt å skrive meter/import hvis dette er en public broker hvis flere med målere gjør det samme? Jeg prøver meg nå bare på de brokerne som ligger åpent på nettet.

 

 

I den androidappen jeg bruker, får jeg ut en logg over Json hvis jeg setter JsonPath til bare $. Det ser ut som om det er hele datastrømmen, og der finner jeg også client ID som "name="

[tronde]

@gskjold

 

Ser ut til å være bug i grafikken for energipriser. Likner mest på gårsdagens.

Det jeg får ut som raw på MQTT stemmer med det som Enstoe viser.

 

 

 

 

 

[gskjold]

On 12/12/2021 at 23:44, tronde said:

Er det slik at hver eneste tilkopling til en broker skal ha sin unike ID for at den skal kunne skille dem?

Korrekt, det er kun en identifikator av klienten og må være unik for hver klient.

 

On 12/12/2021 at 23:44, tronde said:

Og at det som egentlig gir den unike identifikasjonen for min måler er hva jeg velger å skrive inn i feltet for "Publish topic"? 

Det stemmer egentlig det ja, det er dette som skiller data fra de forskjellige enhetene som sender data til brokeren din.

 

7 hours ago, tronde said:

Ser ut til å være bug i grafikken for energipriser. Likner mest på gårsdagens.

Det jeg får ut som raw på MQTT stemmer med det som Enstoe viser.

Interessant. Antar du har lastet siden på ny? Prøv CTRL+F5 for å unngå evt browser cache.

 

On 12/12/2021 at 20:27, tronde said:

Bug i henting av strømpriser. Morgendagens priser ble ikke hentet inn før jeg tok omstart av interfacet.

Skal sjekke dette. Er forøvrig NTP satt opp i config?

[tronde]

@gskjold

 

Det er en eller annen bug der. Jeg så det samme enten det var på desktop, et brett eller på telefonen. Dessuten så var tidsintervallet riktig i grafikken, så cache bør det ikke være.

 

Det som er enda mer merkelig, er at MQTT også begynte å sende ut de samme gale prisene en gang etter midnatt. Da satt jeg med androidappen og fikk til å lese strømprisene inn i den, og de var feil til langt utpå formiddagen i dag. Nå viser også grafikken din rett, men kun priser til midnatt. Det gjør også MQTT.

 

Nå er det etter 13, og Enstoe har presentert nye priser i følge grafikken deres, men adapteret viser kun frem til midnatt. Jeg vet ikke om prisene kommer ut på API samtidig som grafikken, men det kan nesten se ut som om adapteret har fått noe ny info, men ikke viser den siden grafikken er endret i verdier, men ikke tid.

 

 

 

 

*

 

Jeg tror jeg forstår hva jeg forvirret meg med MQTT.

 

Jeg hadde fått det for meg at ClientID var det som broker brukte for å sortere meldingene etter, og at Topic var hva som skulle sendes ut (altså at jeg kunne velge hva selv). Slik jeg forstår det nå, så er Topic sett fra broker det som den sorterer etter, og at alle verdiene henges på denne infoen, og at adapteret alltid sender ut alle verdiene, og at alt utvalg skjer i enden hos mottaker.

 

Jeg har i alle fall fått til å plukke ut data både via JSON og Raw nå, så jeg er vel på rett spor. Problemet med det som er enkelt, er at det plutselig blir vrient når man får en liten detalj feil. Siden jeg trodde at ClientID måtte være lik i begge ender for at sender og mottaker skulle "finne hverandre" forstår jeg også hvorfor det ikke gikk så bra å ha begge på samme IP. Det funket når jeg brukte mobilnett og fiber, men det kan være at broker ikke tolket det på samme måten da.

 

[tronde]

Dette innlegget er endret flere ganger, hvis noen har lest tidligere.

 

Nå har jeg funnet en ESP32 til og satt den opp.

 

Den hentet inn dette. Ser nå ut til å være korrekt.

 

 

 

 

Den første ESP32 viser nå dette (kl 22)

 

 

Dette er loggen for begge mine rett etter kl 23 hvor det tydeligvis ble sendt ut masse nye priser. De var ikke der for den nye før timeskiftet. Går prisene ut hver hele time på MQTT?

 

Den gamle er ikke oppdatert, men den nye ser ut til å stemme med Enstoe.

 

 

 

Begge kjører v2.0.1, men den nye ble startet opp rett over 22 nå i kveld.

 

 

Endret 14. desember 2021 av tronde