ModbusSensor.h compatible ESP8266-12E

[peninquen]

Definir los problemas para utilizar la librería ModbusSensor.h en un ESP8266-12E.

1º Puerto serie. El ESP-12E parece tener dos puertos, pero uno de ellos está dedicado a la comunicación con el módulo WiFi.

2º Voltaje de referencia. ¿son Suficientes los 3.3V para activa TxEnable?¿son suficientes para el SDM120? ¿es necesario utilizar MAX3485?

[cosmopaco]

Los pines esp-12E tx rx no son tolerantes 5V. La entrada RX de Esp tiene que se protegida a 3.3V.
Por otro lado los pines de entradas de MAX485 DI,DE,!RE los niveles de tensión 2V alto, 0,8V bajo.

Eso quiere decir que con un pequeño divisor (o protección con zener) para RX se puede utilizar un modulo 485 estándar.

[helianto]

Puerto serie... tiene 2 pero uno de ellos solo se puede usar para recibir (lo cual es practico, pues nos permite dejar el otro disponible para otras cuestiones).

Otra cuestion, en lugar de esp8266 a secas, recomiendo usar nodemcu, por varias razones:
1º. Mayor estabilidad en la alimentacion (los esp8266 necesitan añadirles algunos condensadores y otros componentes para reducir fallos).
2º. Mas flexibilidad a la hora de alimentarlos (si vamos a equipos D1 (wemos.cc)... podemos alimentarlos directamente con 12 volt, a los nodemcu con conexion directa usb, ademas nos ahorramos el conversor ttl-usb.
3º. Los gpios son tolerantes a 5v... ojo, no a 6.5v...
4º. En nodemcu disponemos de salida 5v... lo que nos da flexibilidad si lo unimos con el punto anterior.

Lo dicho... en el foro, si necesitais algun nodemcu os puedo enviar para hacer las pruebas.

Feliz año nuevo

[peninquen]

Yo ahora mismo dispongo de un ESP-12E que todavía no he conectado pendiente de terminar otros proyectos, pero tenía entendido que también son nodeMCU compatible. La idea de utilizar ESP-12E es por la posibilidad de integrar todos los componentes en un conjunto reducido, sería algo como el D1 mini. su funcion es casi exclusiva gateway entre el Modbus y el entorno a través de WiFi, por lo que n se plantea comunicación USB excepto para cargar sketch.
Ocupar el puerto serie por el canal modbus significa que la salida para debug lo tendremos que hacer por el WiFi.
La otra alternativa es hacerlo compatible SoftwareSerial.
Me inclino por continuar por HardwareSerial.
Antes de hacer divisores para un MAX485 veo más lógico utilizar MAX3485 que tiene los niveles adaptados a 3.3V.
Habrá que pensar en una placa de prototipos donde poner todos los componentes:

• Fuente alimentación de 230V a 3.3V
• nodeMCU
• MAX3485, resistencias y condensadores.
• conectores

[helianto]

Fuente de 220 a 3.3 no he encontrado (a precio coherente), si que he encontrado una buena fuente 220-5v (a buen precio):

http://es.aliexpress.com/item/5-pcs-HLK-PM01-AC-DC-220V-to-5V-Step-Down-Power-Supply-Module-Intelligent-Household/32409558042.html

De todos modos yo prefiero el nodemcu directamente (entiendo por nodemcu el esp8266 que integra el adaptador usb-ttl + alimentador y resto de elementos), por tamaño realmente no merece la pena trabajar directamente con los esp8266 pues al final siempre tienes que colocar los conversores dc-dc asi como algunos condensadores para estabilizar la alimentacion, los conectores (pinouts)... al final acaba saliendo mas caro, con el riesgo de hacer mal alguna soldadura y cargarte el conjunto, es preferible trabajar con un D1, D1mini, o nodemcu (en cualquiera de sus versiones... la v 3.0 tiene la ventaja de tener entrada dc tb por pinout), si lo importante es el numero de gpios, la mejor opcion es nodemcu (tanto d1 como d1mini tienen menos gpios disponibles).

La salida de debug se puede tambien hacer por el puerto serie 2 (gpio13, creo que no estan disponibles ni en D1 ni en D1 mini), o mediante una pantalla lcd por i2c).

Respecto a los niveles... antes de probar con el max3485 yo probaria con el max485, al menos en nodemcu no estoy teniendo problemas de niveles (en gpio, no he probado en ttl).

Otra ventaja añadida de esp8266 (ojo, para utilizarla no sirve la version estable del ide arduino-esp8266, hay que instalar la stagging version) , es que podemos usar hasta 3 Mb como sistema de ficheros (para guardar datos y logs)... a traves de spiffs (aunque para este proyecto no termino de verle ninguna utilidad practica).

[peninquen]

Otra ventaja añadida de esp8266 (ojo, para utilizarla no sirve la version estable del ide arduino-esp8266, hay que instalar la stagging version) , es que podemos usar hasta 3 Mb como sistema de ficheros (para guardar datos y logs)... a traves de spiffs (aunque para este proyecto no termino de verle ninguna utilidad practica).
Con 3Mb te puedes planear el almacenamiento de datos offline para contadores alejados de la red, y descargarlos una vez a la semana o al mes de forma manual conectándote a su hotspot

[helianto]

Si... seria una opcion interesante, incluso en situaciones de sistemas red wifi disponible, para hacer un sistema de bajo consumo (alimentado con bateria), imaginemos un logger de temperaturas, que monitorice cada 10 minutos, y guarde los datos en el fichero... se coloque en modo deepsleep y a los 10 minutos vuelva a hacer lo mismo, y una vez al dia se conecte via wifi y envie la totalidad de datos. (el consumo del esp es muy bajo en deepsleep, bajo en situacion de "despierto" y muy elevado al conectar a wifi... por ello si reducimos las conexiones wifi a una al dia, podemos multiplicar facilmente por 3 o 4 la duracion de el sistema con una simple bateria de litio.

[peninquen]

Si estamos monitorizando la red eléctrica siempre vamos a tener acceso a una fuente de alimentación, en cambio, para contadores de agua por pulsos es una opción muy interesante... no utilizaría la función 'deepsleep' pero sí la situación 'despierto'

[helianto]

Si... para flujos de agua no es recomendable usar la opcion de deepsleep pues parece que el wake-up de las interrupciones via gpio no funcionan demasiado bien en el esp8266 (salvo que lo hayan corregido ultimamente).

[peninquen]

Una vez completada la versión 0.5.2 he creado una copia para compilar en el entorno arduino IDE/ESP8266 y me genera errores, supongo que asociados al precompilador de ESP, no son nada evidentes ¿Alguna guía para adaptar los programas al entorno ESP?

[khawajamechatronics]

Hi,

I am working on your code porting to ESP8266. I have tested and I can suggest few hints.
Although I am also not able to get correct results but I can give you hints for better adaptability to ESP Environment.
We can have quick discussion on Skype as well

[helianto]

Yo no he visto nada... Pero la ultima versión del ide que salio ayer he
leído algo de un debug.
De todos modos tocara lo de siempre...desmontar y montar poco a poco
elementos para ver donde falla... Lo primero ver si la librería modbus
funciona...y a partir de ahí ir añadiendo elementos
El 6/1/2016 20:41, "Jaime García" notifications@github.com escribió:

Una vez completada la versión 0.5.2 he creado una copia para compilar en
el entorno arduino IDE/ESP8266 y me genera errores, supongo que asociados
al precompilador de ESP, no son nada evidentes ¿Alguna guía para adaptar
los programas al entorno ESP?

—
Reply to this email directly or view it on GitHub
#23 (comment)
.

[khawajamechatronics]

First of all, ESP8266 has two Serial Ports.
Serial 0, and Serial 1. Serial, similar to Arduino UNO is used to flash the ESP8266.
Serial 1 has only TX function.
Serial2 is also Serial0 or Just Serial, But swap of pins, means if you dont want to interrupt flashing procedure then you can call Serial.swap() function in setup and Serial function will communicate on other Serial2 pins.

So using hardware Serial, I would recommend to use

Serial(Serial2 pins) for Modbus (Call Serial.swap() in the setup function).
and Serial1 for debugging purpose (Using UART to USB cable).

This is ideal and workable solution.

Issue I am having is:
No communication between ESP with Modbus. As there is less debugging Serial Output in the code, So tonight I will be spending few hours in debugging to find the exact issue.

[khawajamechatronics]

Just for Info, I am able to compile code correctly,

You also need to remove static keyword for declaring variables.

[cosmopaco]

Perfect !!!
Escribo en español ya que mi ingles es penoso.

Los errores que arroja al compilar se discuten en este hilo esp8266/Arduino#574. aunque realmente no entiendo la solución, Prácticamente están pasando la variable a ámbito global.

[cosmopaco]

Efectuando este cambio compila.

void modbusMaster::end() {
  _state = STOP;
  (*_hwSerial).end();
  digitalWrite(_TxEnablePin, LOW);
}

  static uint8_t  indexSensor = 0;                // index of arrray of sensors
  static uint8_t  frameSize;                      // size of the answer frame
  static uint32_t tMicros;                        // time to check between characters in a frame
  static uint32_t nowMillis = millis();
  static uint32_t lastPollMillis = nowMillis;     // time to check poll interval
  static uint32_t sendMillis = nowMillis;         // time to check timeout interval
  static uint32_t receivedMillis = nowMillis;     // time to check waiting interval

//------------------------------------------------------------------------------
// Finite State Machine core, return 'true' when all queries has been processed
boolean modbusMaster::available() {

Aunque la verdad no le veo sentido 😧
Es preferible pasar las variables a global privadas?

[peninquen]

Acabo de encontrar esta otra referencia:
esp8266/Arduino#500
Lo mismo, dice pasar a global. Creo que es preferible mantener el acceso local, teniendo en cuenta que solo se usa una instancia las voy a declarar 'protected' dentro de MBSerial.

[peninquen]

@khawajamechatronics , glad to colaborate.
MBSerial.available() needs some static local variables to control workflow timing when return next call.
We have two posibilities:
1º use global variables. Dangerous if other process access to our variables.
2º use private or protected variables. As we only use one instance of modbusMaster 'MBSerial' we must declare them protected .

Thank you for your advice, If I understand:

• Serial.swap() in setup(), Tx/Rx pins are GPIO13 and GPIO15.(D7 and D8) .
• GPIO2(D4) to Tx to Serial monitor.
• Can I use GPIO12(D6) as TxEnablePin?

What are you using to communicate, MAX485 or MAX3485?

[helianto]

"Serial object works much the same way as on a regular Arduino. Apart from hardware FIFO (128 bytes for TX and RX) HardwareSerial has additional 256-byte TX and RX buffers. Both transmit and receive is interrupt-driven. Write and read functions only block the sketch execution when the respective FIFO/buffers are full/empty.

Serial uses UART0, which is mapped to pins GPIO1 (TX) and GPIO3 (RX). Serial may be remapped to GPIO15 (TX) and GPIO13 (RX) by calling Serial.swap() after Serial.begin. Calling swap again maps UART0 back to GPIO1 and GPIO3.

Serial1 uses UART1, TX pin is GPIO2. UART1 can not be used to receive data because normally it's RX pin is occupied for flash chip connection. To use Serial1, call Serial1.begin(baudrate).

By default the diagnostic output from WiFi libraries is disabled when you call Serial.begin. To enable debug output again, call Serial.setDebugOutput(true). To redirect debug output to Serial1 instead, call Serial1.setDebugOutput(true).

You also need to use Serial.setDebugOutput(true) to enable output from printf() function.

Both Serial and Serial1 objects support 5, 6, 7, 8 data bits, odd (O), even (E), and no (N) parity, and 1 or 2 stop bits. To set the desired mode, call Serial.begin(baudrate, SERIAL_8N1), Serial.begin(baudrate, SERIAL_6E2), etc."

Respecto al serial swap, parece que hay que tener cuidado en la ubicacion del comando:

"The trick is to use Serial.swap() , which is included in ESP8266 Arduino library.
Another trick is to use Wemos D1 pins D7 and D10 (!!!! Not D9) as
Wemos D1 mcu D7 pin -> Nextion TX
Wemos D1 mcu D10 pin -> Nextion RX
Wemos D1 pinout is at http://www.wemos.cc/wiki/doku.php?id=en:d1#pin
and Serial.swap() function is in https://github.com/esp8266/Arduino/blob/master/doc/reference.md
Be careful when to use Serial.swap() . I used mine at the end of setup(){} , after Wifi init and nexInit().
Also keep in mind to check your code to care of the buffer.
As you can see in NexHardware.cpp, it sends commands during nexInit() and read about bkcmd in Nextion Instruction Set : http://wiki.iteadstudio.com/Nextion_Instruction_Set
Any bad values or unwanted execution concerning serial buffer, your execution order may get affected so simplify your test code before trying Serial.swap().
Now will try the solution at NodeMCU because same thing happened in NodeMCU also. Hopefully this time I won`t get bugged at pins."

No termino de entender la utilidad de hacer swap del serial (por lo visto soluciona algo... pero no se exactamente que), si que entiendo usar el serial1 (es lo logico) para el debugging.

[kluszon]

Have anyone got solution for ModbusSensor.h for ESP8266?

[cosmopaco]

Que tal Peninquen.
No te leo por ningun sitio

[bobq11]

Cierto.Hace mucho tiempo que se sabe nada de vosotros.Espero que os vaya todo bien por que sois unos cracks.

Un saludo