ESP8266 - A Pequena Maravilha para Comunicação WIFI

lucianolcoa · 13 de janeiro de 2017

@alexandre.mbm O blynk acabei de testar, funcionou com meu nodemcu de buenas, tem mais funçoes como graficos de iot, timers, e ate envio de alertas pelo twiter, brinquei rapidim com ele. Como voce fez funcionar o cloud mano? tentei usar ele e não consegui,muito confuso...

adicionado 2 minutos depois

@Intrudera6 Então mano comprei uns ds no mercado livre vou esperar chegar.vou ver se implemento um acionamento configuravel por tempo pra ver se "encarece" mais o produto hehe, mas ja to vendo que isso vai ser uma baita duma peleja...

alexandre.mbm · 13 de janeiro de 2017

@lucianolcoa , eu ainda não o testei com o ESP-01. Apenas com o desktop como pusblisher e subscriber. Estou organizando o código de exemplo no GitHub. Mostro já a vocês. Mas é basicamente o exemplo oficial rodando.

Update

@lucianolcoa, pronto! AQUI. Agora eu vou ao ESP-01.

Intrudera6 · 13 de janeiro de 2017

3 horas atrás, lucianolcoa disse:

@alexandre.mbm São hipoteses, não sei se me aventuraria a adaptar horario.Sei que isso vai me dar dor de cabeça, pois se for seguir a logica do botão de estado inicial, senhas de acesso, aumentar a struct,rs.Mas se eu não deixar o produto o mais atrativo possivel ninguem se interessará em compra-lo, ou se o fizer, será por um valor baixo.

É fácil implementar um relógio apenas incrementando um contador tipo unsigned long a cada segundo (ou decimo, centésimo ou milésimo, fica ao gosto do fregues, mas quanto mais interrupções por segundo mais chance de ter problema), mas a precisão é a do cristal oscilador, 50 ou 100 PPM, um erro de 9 segundos por dia ou maior é esperado. Com um servidor NTP você pode corrigir o relógio, mas sempre vai precisar da internet (acertar na mão é chato), com um RTC como o DS3231 ajustado deve demorar meses para ter o mesmo desvio que o oscilador do ESP8266 teria em apenas 1 dia.

alexandre.mbm · 13 de janeiro de 2017

@Intrudera6 , para o meu caso talvez esse erro ainda seja bem razoável. Obrigado.

rodrigocirilo · 13 de janeiro de 2017

Pessoal, os equipamentos que trabalho (sistemas de DVR para CFTV) todos que já vi tem um (ds13xx) e um cristalzinho do lado. O relógio é importante para buscar gravações depois e não vejo os fabricantes preocupados com extrema precisão e nem os consumidores preocupados também..

Intrudera6 · 13 de janeiro de 2017

Testa e veja quanto é o erro, a precisão normal dos cristais é 100ppm, não deve ser muito diferente disso no caso do ESP8266. E você ainda pode usar as minhas rotinas de leitura do NTP e conversão do USTAMP para data hora.

adicionado 10 minutos depois

14 minutos atrás, rodrigocirilo disse:

Pessoal, os equipamentos que trabalho (sistemas de DVR para CFTV) todos que já vi tem um (ds13xx) e um cristalzinho do lado. O relógio é importante para buscar gravações depois e não vejo os fabricantes preocupados com extrema precisão e nem os consumidores preocupados também..

Antigamente os ds13xx eram baratos e os DS3231 eram caros, mas atualmente o preço dos DS3231 deve estar o mesmo do 13xx (quase) e a precisão é 50 a 100 vezes melhor, até o soft é quase totalmente compatível, então para que usar um Rtc muito pior? Nesse caso o timer do ESP8266 faz um serviço tão bom como os 13xx.

Papibakigrafo · 13 de janeiro de 2017

É, estou a 2 dias quebrando a cabeça e ainda não consegui fazer a conversão de char* pra int, e funcionar uaHauAHauHAuahAUa

Vejam se podem me ajudar:

char utc[3];

O char* salvo na EEPROM é: -3

Na conversão usando ATOI, é: 0

Na conversão usando INT, é: 1073690468

Sinceramente, não sei mais o que fazer auHauAHauhAUa

alexandre.mbm · 13 de janeiro de 2017

@Papibakigrafo , eu estou por fora disso, e "fugindo" de mexer com EEPROM. Vou precisar gerenciar configurações, mas já comecei a torcer para dar tudo certo com WifiManager.

Papibakigrafo · 13 de janeiro de 2017

Eu vi essa biblioteca, parece ser interessante.

O mais engraçado que eu já possuo uma conversão dessa no meu sistema (com numero positivo), e funciona normalmente!! E já tentei com positivo e negativo, e dá o mesmo resultado: 0!

alexandre.mbm · 13 de janeiro de 2017

Ei @Papibakigrafo , não é a estória de confundir ponteiro e variável?!

Update

Em 13/01/2017 às 07:52, Papibakigrafo disse:

Eu vi essa biblioteca, parece ser interessante.

Mais: Biblioteca WiFiManager para o ESP8266

Papibakigrafo · 13 de janeiro de 2017

@alexandre.mbm sinceramente, eu não sei. Sei pouco de C, e não faço ideia porque não está funcionando kkkk =/

alexandre.mbm · 13 de janeiro de 2017

Spoiler

Pois dê uma olhada no assunto. Pois até onde eu me lembro, char e char* são coisas bem diferentes. Não vale a pena ficar perdendo tempo com tentativa-e-erro. Em situações assim eu prefiro fazer um pouco de leitura.

@Papibakigrafo, o que está no spoiler acima foi um equívoco. Marcelo Mosczynski acaba de me ensinar que ponteiros são codificados com &. O modificador * é para array.

Não sei C de verdade. Nunca optei pela linguagem. A Wiring da IDE é muito mais comportada, e mesmo assim eu ainda não trabalhei mais de 500 linhas.

lucianolcoa · 13 de janeiro de 2017

Vale lembrar que no ramo dos embarcados não existe c puro, cada linguagem que tem por ahe é apenas mais uma variação de C

adicionado 14 minutos depois

@Papibakigrafo Me explica a situação desde o começo, por que voce quer salvar um dado negativo na eeprom????

Penso que talvez seria melhor voce inverter o sinal numa formula que inicia no setup do que tentar gravar o sinal negativo na eeprom.

ViniciusKruz · 13 de janeiro de 2017

@Papibakigrafo Cara, tem alguma coisa errada é no processo de escrita/leitura, porque o código que te passei por último ta rodando aqui, eu testei.

adicionado 0 minutos depois

A conversão que te passei por último está correta.

adicionado 3 minutos depois

22 horas atrás, ViniciusKruz disse:
@Papibakigrafo Estive estudando a coisa aqui e a forma como você está fazendo não está errada, o que acontece é que para a conversão funcionar, você precisa primeiro passar a string recebida para o padrão em C.

Faça assim:
String variavel_recebe_argumento;
int string2int;

variavel_recebe_argumento= server.arg("ARGUMENTO");

string2int=atoi( variavel_recebe_argumento.c_str());
O ".c_str()" é uma função que faz a conversão do valor atual da string passando ela para o padrão da linguagem C.

Testa aí e depois me fala.

Tinha um erro e corrigi...

@Papibakigrafo É bem possível que sua variável não esteja sendo passada para a eeprom, posta o trecho do seu código na struct pra eu ver uma coisinha.

Papibakigrafo · 13 de janeiro de 2017

@ViniciusKruz Rapaz, pior que está recebendo o valor certinho. Sempre deixo uma div oculta com o valor para verificar...

Struct:

// Estrutura de configuração da EEPROM
struct ConfigStruct
{
  char ssid[50];
  char senha[50];
  IPAddress ip;  
  IPAddress gateway;
  char cidade[50];
  char utc[3];
  char local_prog[10];

} wifiConfig;
//////// Fim da Estrutura ///////////

Valores:

- horario_verão é o valor gravado na EEPROM (wifiConfig.utc);

- utc é o valor da variável trasnformando em INT:

int utc = atoi(wifiConfig.utc);

O mais ***** de entender, é que fiz um teste com esse valor do local.programado. O valor dele é sempre 5... Beleza, na função da programação de ligar/desligar, o ATOI funciona!!! Mas quando coloquei o wifiConfig.local_programado no lugar do wifiConfig.utc, deu ZERO!

@lucianolcoa salvar o UTC do Brasil (-3).

ViniciusKruz · 13 de janeiro de 2017

@Papibakigrafo Como eu já te disse outro dia, eu não consegui usar esse sistema do Renato e só tive dor de cabeça tentando usar, como o tempo é curto, resolvi fazer do jeito tradicional(mais trabalhoso) que é como já tenho o hábito de fazer.

De qualquer maneira, vejo algumas coisas no seu código(struct) que pode ser a causa, por exemplo, você está recebendo um char[3](utc[3]) e mandando gravar isso na eeprom, logo o sistema vai gravar essa informação em 3 posições da eeprom, se for isso mesmo a confusão está aí, uma solução seria mudar sua struct na variável utc para:

int utc

Daí quando receber o dado pelo argumento, faça antes a conversão para int com o código que te passei e somente aí você insere na eeprom, ficaria assim:

struct ConfigStruct
{
  char ssid[50];
  char senha[50];
  IPAddress ip;  
  IPAddress gateway;
  char cidade[50];
  char utc[3];
  char local_prog[10];

} wifiConfig;


String UTC="-3";
int UTCint;

/////////////aqui está incorreto, não tem esta variável "horario_verao" na struct
//faz a leitura do utc na eeprom (caso coloque a variável que deveria ser um char[3])
UTC = wifiConfig.horario_verao;
//////////////////////////////////////

//converte a string para int
UTCint=atoi( UTC.c_str());

//grava na eeprom como int (não sei como seria isso nesse sistema do renato)
wifiConfig.utc=UTCint;

Se nada disso der certo, pare de sofrer e grave/leia isso da forma tradicional hehehe:

para gravar:

i2c_eeprom_escrita(posição,UTCint);

Para ler:

UTCint = i2c_eeprom_leitura(posição);

lucianolcoa · 13 de janeiro de 2017

@Papibakigrafo Pega a wificonfig, transforma em int e subtrai o 3, isso lá no setup, e ahe voce coloca uma logica maluca que se for menor que 0 volta pro 24...

----------------------------------

int horariobrasil=wifiConfig.horario.toInt();

int horariobrasil=horariobrasil-3;

if( horariobrasil<0){

horariobrasil=24;

}

if(horariobrasil>24){

horariobrasil=0;

}

Papibakigrafo · 13 de janeiro de 2017

Não deu certo, e já deixei pra lá! kkkk

Mas muito obrigado pela ajuda!!

lucianolcoa · 13 de janeiro de 2017

@Papibakigrafo Não deu certo o que eu coloquei?

Papibakigrafo · 13 de janeiro de 2017

@lucianolcoa rapaz, nem tentei... vou deixar por último isso! Se não der certo, fazer o que né! ^^

ViniciusKruz · 13 de janeiro de 2017

1 hora atrás, Papibakigrafo disse:

Não deu certo, e já deixei pra lá! kkkk

Mas muito obrigado pela ajuda!!

Dinada!!!

Larga essas estruturas e faz do outro jeito, porque não?

adicionado 5 minutos depois

Se puder, posta uma parte maior do seu código, de maneira que eu possa testar exatamente como você está fazendo, só assim pra poder te ajudar porque aí eu vou testar aqui até dar certo.

Papibakigrafo · 13 de janeiro de 2017

o -3 (ou -2), entraria nessa função aqui:

//UTC Brasil =  -3:00
int utc = -2;
uint32_t currentMillis = 0;
uint32_t previousMillis = 0;

NTPClient timeClient(ntpUDP, "b.st1.ntp.br", utc * 3600, 60000); //PEGA O HORÁRIO EXATO

Nenhum, absolutamente nenhum dado gravado na eeprom, dava certo. Só dava o valor zero!

ViniciusKruz · 13 de janeiro de 2017

@Papibakigrafo Olha só, pegando trechos daqui e dali fica muito difícil de simular e descobrir onde está a falha, então vou fazer da seguinte forma, vou criar do zero uma função que recebe uma string contendo o valor "-3", fazer a conversão dela para int e gravar na eeprom, depois vou fazer o inverso, lendo na eeprom o valor e mostrando em um print, isso resolveria pra você?

Papibakigrafo · 13 de janeiro de 2017

@ViniciusKruz Ohh, ajudaria completamente! kkkk

alexandre.mbm · 13 de janeiro de 2017

6 horas atrás, ViniciusKruz disse:

Larga essas estruturas e faz do outro jeito, porque não?

4 horas atrás, ViniciusKruz disse:

@Papibakigrafo Olha só, pegando trechos daqui e dali fica muito difícil de simular e descobrir onde está a falha, então vou fazer da seguinte forma, vou criar do zero uma função que recebe uma string contendo o valor "-3", fazer a conversão dela para int e gravar na eeprom, depois vou fazer o inverso, lendo na eeprom o valor e mostrando em um print, isso resolveria pra você?

Era o que eu ia dizer. Analisar código alheio em parcelas é algo que pode reservar muitas armadilhas. E mesmo quando o código está sendo trabalhado inteiramente por mim, se eu me deparo com um "erro de outro mundo", geralmente eu faço um minúsculo sub-projeto ad hoc, reduzindo extremamente o escopo, só para que possa testar direito "a coisa".

Bom, eu tenho várias abas abertas aqui, no Firefox. Tive de dormir durante o dia. Acordei há pouco. Mas quero começar apontando um tutorial que está chamando a minha atenção de uma forma especial. Eis um trecho dele:

Citação

Como vimos, os dados são gravados de byte em byte, mas quando programamos o Atmega utilizamos memórias que muitas vezes são maiores que 1 byte. Um int por exemplo, ocupa dois bytes, um long 4, etc.

Fonte: Memória EEPROM no Arduino (interna e externa)

Deem uma olhada em como ensinam a gravar inteiros. Talvez isso dê uma luz para se mexer com struct. Não sei, não faço ideia. Estou apenas tentando ajudar com uma seleção do que tenho disponível até agora. Ainda vou demorar algumas horas para usar meu conversor serial pela primeira fez. Já estudei o bastante para fazê-lo agora, mas estou cheio de pendências e quero ter o máximo de cuidados possível, para não fazer caca no único ESP-01 que possuo.

Ah, já ia esquecendo...

O tal exemplo do sistemasembarcados.org:

void EEPROMWriteInt(int p_address, int p_value) {
     byte lowByte = ((p_value >> 0) & 0xFF);
     byte highByte = ((p_value >> 8) & 0xFF);
     EEPROM.write(p_address, lowByte);
     EEPROM.write(p_address + 1, highByte);
}

unsigned int EEPROMReadInt(int p_address) {
     byte lowByte = EEPROM.read(p_address);
     byte highByte = EEPROM.read(p_address + 1);
     return ((lowByte << 0) & 0xFF) + ((highByte << 8) & 0xFF00);
}

Update

Ei pessoal, eu acho que a resposta está com o paulo1205 em "Gravar dados de uma struct em arquivo binário na linguagem C": o tamanho real dos dados numa struct dependerá da arquitetura, do compilador e do conjunto e da ordenação desses dados na struct.