Evento x-> fa scattare una hhtp request verso il secondo arduino che istantaneamente risponde con una http request al primo arduino...
In questo scenario la rete di casa non funziona piu!!! Il primo arduino è praticamente bloccato e da monitor ottengo una serie di yyyyyyyyyyyyyyyyy. Sono costretto a riavviare router, e webserver (nas synology)
La mia paura è che la gestione della chiama in questo modo non è sincrona...in poche parole mentre il primo arduino sta ancora tentando di chiudere la request, ne è partita un'altra dal secondo verso il primo creando una sovrapposizione.
Vi dico questo perche se evito di far partire immediatamente la request del secondo arduino, tutto funziona!
Di seguito il codice che uso per la chiamata
int Send(String Consenso) //client function to send/receie GET request data.
{
//Serial.print("stil connect");
if (pushMaster.connect(arduinomaster, 8083))
{
String command = "GET /?sir-" + Consenso;
Serial.println(command);
pushMaster.println(command);
pushMaster.println(" HTTP/1.1");
pushMaster.println("Host: ");
pushMaster.println(arduinomaster);
pushMaster.println("User-Agent: Arduino");
pushMaster.println();
}
else
{
Serial.println("connection failed sirena");
Serial.println();
}
while(pushMaster.connected() && !pushMaster.available()) delay(1); //waits for data
while (pushMaster.connected() || pushMaster.available()) { //connected or data available
char c = pushMaster.read();
Serial.print(c);
}
pushMaster.stop();
return 1;
}
Indirizzi Ip e Mac address sono diversi per i due arduino. Un aiutino?
Evento x-> fa scattare una hhtp request verso il secondo arduino che istantaneamente risponde con una http request al primo arduino...
Il secondo dovrebbe rispondere con una response, e successivamente fare una request..
Il fatto è che arduino non è multitasking per cui le operazioni devi farle in modo sequenziale:
evento-> http request verso ARD2
(ARD2 sta in attesa) riceve, elabora e risponde (invia response)
(ARD2 chiude la prima sessione (cioè completa la response)
attendi qualche secondo (empirico per dare tempo a ARD1 di elaborare la response)
ARD2 passati i secondi esegue una HTTP request verso il primo.
Comunque se descrivi cosa vuoi ottenere, forse è più semplice.
In questo scenario la rete di casa non funziona piu!!! Il primo arduino è praticamente bloccato e da monitor ottengo una serie di yyyyyyyyyyyyyyyyy. Sono costretto a riavviare router, e webserver (nas synology)
Usi indirizzi ip o hostname?
Molto probabilmente inviano dei pacchetti broadcast,ma da verificare.
L'infrastruttura di compone di due arduino (con IP STATICI) diciamo come allarme casalingo,
Un arduino che gestisce la sirena, e altri eventi. Il secondo...per motivi di cablaggio, è collegato al primo tramite wireless.
In una infrastuttura di rete, entrambi sono nodi in quanto, entrambi hanno una funzione client/server e non solo client.
Passando nello specifico:
1° arduino manda una GET verso arduino 2, dicendo "Abilitati"
2* arduino si abilita ed il pir ad esso collegato è volutamente in condizione di allarme
2° arduino se in condizione di allarme manda GET verso 1° arduino attivando la sirena ( e questo avviene istantaneamente visto la forzatura al punto 3, se il pir è in condizione di non allarme, tutto funziona, perche di fatto non viene inviata una request a ridosso di quella che richiede l'abilitazione.)
Quindi, o il mio codice non è sufficientemente robusto..ma uso la libreria standard come riportato sopra oppure mi perdo qualche altra cosa.
Premetto che piuttosto che una GET dovresti fare una POST: VEDI ARCHITETTURE REST, RESTFULL.
In breve se da un nodo di serve una informazione fai una GET, se invece vuoi "modificare" un valore sul nodo (per esempio un inserimento su un database, un cambio di stato) dovresti fare una POST!
Nel tuo caso il primo arduino dice "abilitati" al secondo, ciò è da configurare come una POST!( è un cambio di stato)
Ma anche il secondo "dice" "avvia sirena" e anche questa è una POST!
A parte ciò,rilleggendo i punti, da quello che ho capito la logica che fa scattare l'allarme è sull'arduino 1, la sirena la "suona" l'arduino 1 ma su comando del 2.
A questo punto mi chiedo a cosa ti serve il 2?
ripeto, arduino 2 gestisce il pir che per problemi di cablaggio non è collegato ad arduino 1. inoltre arduino 2 svolge altre funzioni, che per i stessi motivi non posso far fare ad ardunio 1
Mi intrometto, ma ha senso creare un allarme che lavori con la rete? Se si parla di wi-fi (così mi pare dato che parli di infrastrutture di rete) se va via l'elettricità in casa salta anche il router wireless, e con esso il tuo allarme dato che gli shield wi-fi non hanno più modo di comunicare essendo morto l'access point. Non sarebbe meglio usare un altro sistema?
@arduico: no. Sono ben accette altre soluzioni. Puoi indicarmi la strada? @leo72: è tutto sotto gruppo(alimentatore+batteria al piombo da 7ampere arduino1+ access point e stessa cosa per Arduino 2) se va via l'elettricità.. tutto funziona per almeno 12 ore. Che soluzione alternativa proponi?
Sono ben accette altre soluzioni. Puoi indicarmi la strada?
http://arduino.cc/en/Tutorial/WiFiSendReceiveUDPString
In pratica, piuttosto che utilizzare HTTP che richiede (in questo caso in entrambi i nodi) un server web in ascolto, una post e/o una get del chiamnate, se instanzi un socket (specificando IP e porta) puoi spedire verso ll'latro nodo un qualsiasi valore, int, byte, string, come se fosse una funzione "interna".
Per quanto ti riguarda basta spedire un intero (x esempio 1) se devi abilitare un allarme.
Il funzionamento a grandi linee è questo:
ARD2(IP 192.168.100.2) sta in ascolto sulla porta 60002(per un certo timeout sul socket ) in attesa che qualcuno si connette.
ARD1 (192.168.100.1) sta in ascolto sulla porta 60001(per un certo timeout sul socket ) in attesa che qualcuno si connette.
arriva interrupt-----> si connette al socket di quindi chiama 192.168.1.2:60002
ARD 2 quando ha completato la lettura di ARD1 (è un buffer) elabora il dato chiude il socket.
ARD2 si connette al socket di Ard1 192.168.100.1:60001 e spedisce il suo di dato.
Spero che possa esserti di aiuto, nn so se hai delle conoscenze di networking.....
