Buongiorno a tutti, in una scatolina 9 x 7 cm ho inserito un circuito con un relè, un riduttore di tensione ed un radar.
Il programma (AT85) è:
/*
File: Cortile_Pier_04
Date: 19/07/2025
Version: 4.0
Arduino IDE Version: 1.8.19
RWCL-0516
Processore ATTINY 85/13
Alimentazione max 40 V
*/
int rcwlPin = 2; //RCWL-0516 OUT -> Attiny85 o Attiny13
int ledRele = 3;
unsigned long count_time = 0;
unsigned long att_time = 3000;
void setup() {
pinMode (rcwlPin, INPUT); //Define rcwlPin as INPUT
pinMode (ledRele, OUTPUT); //Define ledPin as OUTPUT
count_time = millis();
}
void loop() {
int value = digitalRead(rcwlPin); //Read rcwlPin value
delay(100);
if (value > 0) {
digitalWrite(ledRele, HIGH);
delay(100);
count_time = millis();
} else if ((value == 0) && (( millis() - att_time) < count_time)) {
digitalWrite(ledRele, LOW);
delay(100);
}
}
Lo schema del circuito è:
Il programma dovrebbe attivare il relè in presenza di un muovimento, invece ottengo un lampeggio continuo di 3 sec.
Non sono riuscito a trovare errori nel programma; è possibile che lo scatto del relè (meccanico) attivi il radar?
Anticipatamente grazie per ogni suggerimento.
Saluti
Enrico
J-M-L
August 4, 2025, 5:01pm
2
Quale sensore radar?
PS/ usa HIGH e LOW per confrontare il valore restituito da digitalRead()
Fatto.
Il risultato NON cambia.
Sembrerebbe invece funzionare l'aumento del primo delay da 100 a 1000. Probabilmente il passaggio da HIGH a LOW non è immediato. Purtroppo ho potuto provarlo solo a 9V; domani proverò utilizzando 12V.
Il radar utilizzato è questo .
Grazie della risposta.
Enrico
La questione è se quel relè è optoisolato
E se l'alimentatore è adeguato
Inoltre le condizioni non sono ottimali
Usa un "if value" invece di un "if value >0"
E nel else if non serve testare di nuovo value: se sei nello else vale 0 per forza
Ricordiamoci che High e low sono solo macro che puntano a 1 e 0
J-M-L
August 4, 2025, 8:06pm
5
Usare HIGH e LOW serve per la leggibilità e la coerenza.
Cosa vedete se provate questo codice?
const byte rcwlPin = 2; // RCWL-0516 OUT -> Attiny85 o Attiny13
const byte ledRele = 3;
void setup() {
pinMode(rcwlPin, INPUT);
pinMode(ledRele, OUTPUT);
}
void loop() {
digitalWrite(ledRele, digitalRead(rcwlPin));
}
Quando il sensore RCWL-0516 rileva un movimento, l’uscita va su HIGH per circa 2 secondi. In questo codice, tale uscita viene letta in tempo reale e copiata direttamente sul pin ledRele.
Quindi si dovrebbe vedere il LED o il relè collegato al pin 3 attivarsi per circa 2 secondi ogni volta che viene rilevato un movimento, per poi spegnersi automaticamente.
J-M-L
August 4, 2025, 8:08pm
6
non sempre
typedef enum {
LOW = 0,
HIGH = 1,
CHANGE = 2,
FALLING = 3,
RISING = 4,
} PinStatus;
➜ può essere un tipo formale
Grazie, quindi basterà aumentare il deley a 2000 per sicurezza!!
Ora mi spiego anche perchè negli altri utilizzi impostati con il radar il tempo effettivo risultava essere superiorenanquello impostato!
Grazie & saluti a tutti.
Lana caprina...
Sempre 0 e 1 sono
enrico24:
Utilizzo questi relè.
Direi che non ci siamo
Cerca relè optoisolati
Esatto, ma mi ci vuole un ciclo if in quanto desidero un ulteriore ritardo.
J-M-L
August 4, 2025, 9:35pm
12
Standardoil:
Lana caprina...
Sempre 0 e 1 sono
No, ora sono tipi enumerati che possono essere implicitamente promossi a 0 e 1.
Questo può avere la sua importanza, cfr
opened 10:33PM - 02 Jan 19 UTC
This project changes `LOW`, `HIGH`, `INPUT`, `INPUT_PULLUP`, and `OUTPUT` from m… acros to enums:
https://github.com/arduino/ArduinoCore-API/blob/e1eb8de126786b7701b211332dda3f09aa400f35/api/Common.h#L10-L23
I'm concerned that this will cause breakage of a significant amount of existing code.
An example is the popular [Keypad library](https://playground.arduino.cc/code/keypad). Compilation of both the [original](https://playground.arduino.cc/uploads/Code/keypad.zip) library and the [version in Library Manager](https://github.com/Chris--A/Keypad) fails once this change is made.
```
In file included from E:\electronics\arduino\libraries\Keypad-master\examples\HelloKeypad\HelloKeypad.ino:10:0:
E:\electronics\arduino\libraries\Keypad-master\src/Keypad.h: In member function 'virtual void Keypad::pin_write(byte, boolean)':
E:\electronics\arduino\libraries\Keypad-master\src/Keypad.h:81:81: error: cannot convert 'boolean {aka bool}' to 'PinStatus' for argument '2' to 'void digitalWrite(pin_size_t, PinStatus)'
virtual void pin_write(byte pinNum, boolean level) { digitalWrite(pinNum, level); }
```
This commonly used code will also now fail:
```c++
digitalWrite(13, !digitalRead(13)); // toggle pin 13
```
```
toggle:2:36: error: cannot convert 'bool' to 'PinStatus' for argument '2' to 'void digitalWrite(pin_size_t, PinStatus)'
digitalWrite(13, !digitalRead(13)); // toggle pin 13
```
I understand that the root cause of these errors is bad code and that any code which followed best practices will have no problems with this change. However, I fear there is a lot of bad code in widespread use that currently works fine. In the case of the Keypad library, it is unlikely it can even be fixed since Chris--A has gone AWOL. I'm sure there are other such abandoned projects.
I do like the spirit of this change (though lumping `CHANGE`, `FALLING`, and `RISING` into `PinStatus` is questionable). I'm open to being convinced that it's worth the breakage and, if so, I'm willing to help ease the transition by providing user support and submitting PRs to fix broken code. I just think this warrants some consideration before ArduinoCore-API goes into more widespread use.
Some previous discussion on the topic:
- http://forum.arduino.cc/index.php?topic=455579 (from [here](http://forum.arduino.cc/index.php?topic=455579.msg4001965#msg4001965) onward)
- https://forum.arduino.cc/index.php?topic=584322
- http://forum.arduino.cc/index.php?topic=602250
- https://forum.arduino.cc/index.php?topic=621429
- https://forum.arduino.cc/index.php?topic=627883.msg4319254#msg4319254
- https://forum.arduino.cc/index.php?topic=659624
- https://github.com/arduino/ArduinoCore-megaavr/issues/68
J-M-L
August 4, 2025, 9:37pm
13
La cosa migliore in questo caso è usare un approccio basato su macchina a stati.
Ho un tutorial in inglese sull’argomento.
Hello everyone,
On this gray day, considering the number of questions that boil down to programming a finite automaton (or a state machine), I thought I would translate my small tutorial I also have in French to explain how to approach this type of code in a structured manner. Of course, there are libraries that do this more or less for you, but understanding how it works can often allow you to do without libraries that might weigh down your code.
The general idea is to write a program that co…
2 Likes
UCAS
Ufficio complicazioni affari semplici
Andrà a finire che coi tipi il C++ ci si strozzera
1 Like
Provato, ieri funzionava, oggi, ripete più volte il lampeggio (ca. 2 sec acceso
, poi spento) anche in assenza di muovimento.
Sto pensando di eliminare lo AT85 (vista la latenza della variazione della "nessun muovimento"), che ne pensate?
Perchè dovrebbe essere optoisolato? Avrei degli optoisolatori CNY74-2 o dei PC897 (se ho letto bene) potrebbero essere utilizzati? e come?
Saluti
Enrico
J-M-L
August 6, 2025, 8:02pm
16
Se usate l’ATTiny85 solo per trasmettere il segnale del RCWL-0516, allora in effetti potete farne a meno. Potete anche scegliere la durata dell’attivazione sostituendo il condensatore presente sulla scheda.
Risolto.
Il mio errore era di considerare il limite di rilevabilità del muovimento di ca 7 mt (come da letteratura!!) invece vi sono degli alberi a ca 12 / 15 mt ed il sensore rilevavav il muovimento delle foglie dovuto al vento!!
Grazie a tutti,
Enrico