De ontwerptips en domme fouten: Ze raken maar niet op

Ik twijfelde over in huis een perilex of toch anders.
De kracht kabel lag er al en ik ga zeker 3F koken.

Echter die perilex wordt steeds vaker misbruikt voor 2x 1F en 2x N.

Dus dat is onduidelijk.

Even zoeken bij de Hornbach leverde deze knutsel op:

Een centraaldoos waar ik een pootje afgezaagd heb

Nu zit er een 3/4" koppelstukje op

Dan zit hij op de pijp met kabel erin

En met een 16 A CEE form heb je nooit twijfels of het 3F is
:)

heb je een haakse cee stekker dan? anders beste kans dat een lade straks niet gaat sluiten zo :P perilex is geen probleem, ik schijf er altijd op wat het is 1F of 3F en waar de fasen en nullen dan zitten. en zelfs dan mag de elektrieker het fornuis nog komen aansluiten want dat doet de keukenboer niet. zijn ze op t werk nogal klaar mee, hun zetten de marge op die keuken dan lossen ze t zelf maar op. kun je weer gaan rijden voor 10min werk..

Ik heb ca 20 cm ruimte en anders maak ik wel gaatje in het kook eiland :)

Op zondag 29 juni 2025 18:36:00 schreef High met Henk:
Ik heb ca 20 cm ruimte en anders maak ik wel gaatje in het kook eiland :)

Dan moet je even zoeken naar een CEEform van 45 graden of zo. 20cm is tamelijk krap.

Een gaatje maken is geen probleem: die 20 cm is ruimte voor leidingen etc. Maar er zijn ook haakse CEE form stekkers.

En feitelijk hoeft deze nooit los.

Je kunt ook een Phoenix PRC(-5) connector gebruiken, is mooi compact en te koop in 20A en 32A uitvoering. Resp PRC20 en PRC35.

Even de nummers opgezocht van de 20A versie:
Chassisdeeel 1308652
Male kabeldeel 1308660

Zijn schroef uitvoeringen de nummers hierboven.

Er is ook een haakse versie schijnt.

Zie: https://www.phoenixcontact.com/en-nl/prc-series-installation-connector…

Of ... ik weet dom idee ... toch gewoon een perilex ;)

De 'kookgroep' uitvoering is een gedrocht, maar hier doe je gewoon 3+N waar het ding voor bedoeld is.

En zoals je al zegt, het hoeft nooit los, dus werkelijk niemand krijgt het in zijn botte harsens daar een kookgroepbekabeldekookplaat in drukken.

Maar toegegeven, crea-bea is het wel, en nu kun je ook nog een lasapparaat kwijt in het keukenblok.

Oh, en brrr .... je hebt stiekem een centraaldoos gebruikt https://www.circuitsonline.net/images/smilies/dark/wink.gif

Of een CEE met ingang aan de onderzijde er op..

dan moet ik een 2e kelder graven om de steker erop te zetten ;) wordt ook lastig met de vloerverwarming die er al ligt.

en @sine: idd een centraaldoos: maar deze zie je niet en er zitten geen lassen in. Ofwel: geen gaten in het plafond en geen deksel die er compleet af klapt!

[Bericht gewijzigd door High met Henk op (40%)]

Ik zie dat je je lasdoos vastgezet hebt met spijkers. Spijkers willen nog weleens gaan roesten. Nu is het achter je keuken, denk ik, niet zo'n probleem, maar als je ze ook gebruikt in zichtlocaties onder je stuckwerk, kan je over een x-aantal jaren opeens bruine vlekken door je behang/glasvezel zien onstaan. Als je echt spijkers nodig hebt om iets vast te zetten kan je item beter daarna direct met een klodder gips vastzetten. Als dat dan droog is kan je daarna de spijkers er weer uit trekken voordat je de definitieve afwerking erover smeert. Verder mooie oplossing wat betreft de CEE-form.

goed opgemerkt, maar de doos zit inmiddels vast: op de foto was tijdelijk.
ik woon in brabant, Dus ga via het motto:

't mak nie uut 'oe grôt de gat of schur: Vat de PUR
en as ge 't echt nie mir wit: Vat de kit!

echter beiden moeten wel even uitharden.

lang maar echt lang zitten zoeken op deze fout. arduino IDE.

ik declareer vaak dezelfde variabelen op deze manier. en ik ga er vanuit dat ze allemaal de waarde 0 krijgen.



int lader1status, lader2status, lader3status = 0;

vandaag geleerd dat dit


int invamps1, invamps2 = 7;

niet hetzelfde als dit


int invamps1 = 7;
int invamps2 = 7;

in het eerste geval krijgt invamps1 de waarde 0 ipv 7. en ik maar zoeken waarom mijn berekeningen fout lopen. en weet nu dus ook dat ik al zeker 5jaar dezelfde fout maak in tal van programmas

De meeste compilers die ik ken initialiseren globale variabelen stilletjes op 0, dus zolang je dingen op 0 zet merk je dat niet. Precies waarom je dacht dat ze allemaal dezelfde waarde zouden krijgen is me een raadsel, dat zou ik juist helemaal niet logisch vinden.

ergens moet er een programmeer taal zijn die ze wel zo initialiseerd (pascal, perl, python, bash???).
ik heb dat al eens gedaan voor RGB variabelen te definieren.
int R = B = G = 255.

maar die = aanvaard C niet tenzij je B en G eerder hebt gedefinieerd.
int R,B,G = 255; geeft geen fout. alleen zijn R en G dus gelijk aan 0 en niet 255

int R,B,G;
R = B = G = 255;
werkt dan wel

een domme fout die ik dus al jaren overal hergebruik. nu pas naar boven gekomen doordat de berekeningen totaal fout zijn.
vroeger waarschijnlijk in 99% van de gevallen nooit een probleem geweest omdat ik altijd alles initialiseer op 0.
maar goed mogelijk dat er nog software van mij met deze bug rondzwerft...

Dank voor de tip en goed om te weten

Op dinsdag 9 september 2025 22:23:16 schreef fcapri:
....
maar goed mogelijk dat er nog software van mij met deze bug rondzwerft...

Zal wel niet zo'n vaart lopen. In het algemeen ga je aan de slag met de uitkomst van een berekening. Na de berekening is de fout gedeclareerde waarde verdwenen.
Of je gaat aan de slag met een foute beginwaarde, maar die is na een aantal berekeningen verdwenen, dus je hebt er korte tijd na het starten van het programma last van.
Of je had het wel gemerkt na klagende klanten. Heb je nooit iets gemerkt, dan maakt het helemaal niet uit wat de waarde van de fout-gedeclareerde waarde is.

meestal definieer ik max waardes wel zo.

in RGB is dus een max voor R = B = G = 255.
bepaalde loops die tot 100 gaan, zou ik dan ook zo maken
int i, j, k = 100.

bij klanten zal het niet rondzwerven, op mijn eigen server heel goed mogelijk. in eigen arduino chip, redelijk zeker

ik probeer altijd een variabele een waarde te geven, ook al zijn ze 0
int power = 0;
int i = 0;

later vul ik er wel de correcte waarde in.
maar soms hebben ze vanaf het begin zo een waarde nodig...

subroutines die kort een eigen variabele nodig hebben, zelfde manier gedeclareerd.
het betreffende programma is 1839 regels code. diezelfde fout 11 keer tegen gekomen. gelukkig wel allemaal met 0 als begin waarde.
maar alle andere variabele waren dus niet gedefineerd.

en vaak in mijn code zet ik dan als eerste

if (var == 0){
  geef die var een waarde
} else {
  doe berekening
}

zo weet ik dan ook dat de waarde nog niet gebruikt was. ik misbruik dergelijke ook om te bepalen dat ik de eerste keer door een loop ga
ik geef ze dan een waarde van 1-9, aangezien 0 nooit gebruikt wordt, is dat dan de eerste keer dat de code draaid

bv hier= als er 0 in staat, zijn beide logs leeg.
de rest van het programma staat er ofwel 1 ofwel 2 in, nooit meer 0


if (activeLog == 0){
  LOG1 = date + " " + time;
  activeLog = 1;
  return LOG1;
} else {
  if (activeLog == 2) {
    return LOG1 + LOG2;
  } else {
    return LOG2 + LOG1;
  }
}

zo maakt die afwisselend LOG1 of LOG2 leeg en vult aan met nieuwe regels. het weergeven van de logs is onzichtbaar voor de gebruiker. die ziet 1 groot logfile

Voor een microprocessor is ==0 wel mooi. Die laadt een getal en hoeft dan alleen naar het zero-bit te kijken best optimaal.

Op dinsdag 9 september 2025 22:08:48 schreef SparkyGSX:
... dus zolang je dingen op 0 zet merk je dat niet.

Helaas een foute aanname. Wie zegt dat 0 beter is dan een willekeurig ander getal? Die smoes heb ik al zooooooooooooooo vaak gehoord.

Dat initialiseren op nul staat in de C standaard. Een compiler moet dat gewoon altijd regelen.

Ik wist niet of het in de standaard staat, maar blijkbaar mag je er voor globals dus op rekenen.

@henri62: ik bedoelde dat zo'n fout onopgemerkt blijft als je de variabelen op 0 zet, omdat de compiler dat zelf ook doet (voor globals). Pas als dat geen globals zijn, of de waarde iets anders dan 0 gaat het mis.

@fcapri: "activeLog == 1;" doet niets...

Op woensdag 10 september 2025 07:15:22 schreef SparkyGSX:

@fcapri: "activeLog == 1;" doet niets...

typo hier door wat teveel andere code eruit te filteren. code was langer. aangepast

Op woensdag 10 september 2025 07:15:22 schreef SparkyGSX:
Ik wist niet of het in de standaard staat, maar blijkbaar mag je er voor globals dus op rekenen.

Ja! Voor de volledigheid: Globals beginnen als nul, de variabelen binnen functies dus niet. 

int main ()
{
  int bla;
...

is dus niet gegarandeerd dat die op nul begint.

Bij een OS als linux begint een proces met "leeg memory". Het zou een informatie-lek zijn als je daar oude data aantreft. Derhalve zal je vaak je bla variabele aan het begin als nul treffen. Maar als de opstart-code al een en ander heeft aangeroepen, dan kan zomaar al een waarde op de stack staan. Ook heeft de compiler het recht om gewoon een CPU-register aan te wijzen als "daar staat bla". Dan is het helemaal de vraag wat daar aan het begin van de functie staat.

Wist je dat RJ11 kabeltjes in "gespiegeld" en "niet gespiegeld" varianten bestaan?

Ik heb een P1-logger gemaakt. Met dank aan Kapee voor de RJ12 sockets.

Blijk ik in m'n RJ11/RJ12 kabels-en-toebehoren doos geen RJ12 kabels te kunnen vinden. Tja, Voor DSMR5.0 was het toch een RJ11 kabel, dus dan maar dat. Dan kan ik (voorlopig) niet (tot) 1.25W van STEDIN gebruiken, jammerdan.

Net kabeltje "nieuw" met ongebruikt kabelbindertje gevonden. Aangesloten. Nope. Werkt niet. Andere baud rate geprobeerd (DSMR 5.0 schrijft 115200 voor, maar mijn thuis-meter had wat anders en toen ik stedin vroeg hoe dat zat kwamen ze direct m'n meter vervangen... Nooit antwoord op de vraag gehad.)

Ik had op m'n printje een GPIO (3.3V) aan de "DRQ" gehangen. Misschien is dat niet genoeg? Inderdaad volgens de spec moet het 5V (nominaal) zijn, maar meters moeten met 4.0 genoegen nemen als dat het geval is. Dus meter zou in spec zijn als ie 3.3V net niet ziet.

Dus baantje doorgekrast en permanent 5V (niet via GPIO) op de DRQ gezet. Nope.

Nagemeten of de 5V van de meter op de juiste pins zitten dat als die rechtdoorgaan op mijn GND en 5V uitkomen. Jep!

En toen even goed naar de kabel gekeken en... verrek. Bij het zoeken naar een ander kabeltje kom ik een andere kabel tegen met als "sticker" er op: "Gespiegeld".... Hoe lang zou het geleden zijn dat ik dezelfde fout heb gemaakt?

[niet een kick van mijn vorige post, maar totaal ongerelateerd -> nieuwe posting]

Op woensdag 10 september 2025 09:07:35 schreef rew:
[...]Ja! Voor de volledigheid: Globals beginnen als nul, de variabelen binnen functies dus niet. 

int main ()
{
  int bla;
...

is dus niet gegarandeerd dat die op nul begint.

En dat kan tot heel erg onverwachte bugs lijden:
https://cookieplmonster.github.io/2025/04/23/gta-san-andreas-win11-24h…

Hoe een 20(!) jaar oude bug ineens geactiveerd werd door een Windows 11 update...