Tema: Averiguar comandos y respuestas ("sniffear" puerto serie) inversor voltronic

Buenas a todos,

Voy a dejar por aquí la técnica que he utilizado para obtener los comandos que me faltaban por no estar identificados correctamente en la documentación existente del protocolo P30 (creo que se llama así) de los Voltronic, en mi caso para un Axpert King 5Kw 48v.

Quería cambiar el valor del parámetro 16 "Solar energy priority", para cambiar ente sus dos primero valores:
- SbL UCb: Solar energy for battery first, Allow utility to charge battery
- SbL UdC: Solar energy for battery first, Disallow utility to charge battery

La idea es jugar con los parámetros

01: Output Source Opriority: USb/SbU
10: Operation Logic: ONL / ECO Online o ECO
16: Solar energy priority: SbL UCb / SbL UdC


El parámetro 01 está claramente documentado, es el POP00 (Utility) /POP02 (Solar, battery, utility)
El parámetro 10 esta documentado en las últimas versiones: POPLG01 (InLine), POPLG02 (ECO/Bypass))
El comando 16 no lo he encontrado en ningún sitio, pero finalmente he averiguado que las dos primeras opciones son:
- SbL UCb: PPCP100
- SbL UdC: PPCP101

Lo más gracioso es que esos comandos están documentados, pero con la siguiente descripción que parece que nada tiene que ver con el parámetro 16:
PPCP<MNN><cr>: Setting parallel device charger priority (For 4000/5000)


Con estos 3 parmámetros, ahora sí con sus respectivos comandos por protocolo, quiero automatizar ahora en invierno la carga de baterías por la noche.

Pero vamos al grano del hilo, dado que no lo he encontrado documentado voy a explicar cómo he averiguado el comando del parámetro 16:


Utilizando mi PC Portátil con Debian GNU/Linux:

- Instalar el software oficial WatchPower para linux, versión 64Bits, en mi caso la V1.14SP1
- Probar con puerto serie con el típcio adaptador USB y conectado por el rj45 al inversor
- Si funciona, desconectarlo y creamos el puerto virtual:

Código:

sudo socat /dev/ttyUSB0,raw,echo=0 SYSTEM:'tee in.txt |socat - "PTY,link=/dev/ttyUSBV0,raw,echo=0,waitslave" |tee out.txt'

/dev/ttyUSB0 es, en mi caso el Puerto serial Real
/dev/ttyUSBV0 es el puerto virtual a crear

Los comandos que enviaremos aparecerán en el fichero out.txt y las respuestas que nos llegan desde el inveror quedarán en el fichero in.txt
- Damos permisos al puerto virtual:

Código:

sudo chmod 777 /dev/ttyUSBV0

- Conectamos el Software WatchPower al puerto virutal recién creado
- Aplicamos la configuración deseada en el software
- Paramos inmediatamente con Control + C el comando socat lanzado para crear el puerto virtual

De esta forma, encontraremos el comando al final del fichero out.txt (si es de modificación suelen empezar por "P" o "M" y si es de consulta suele empezar por "Q"

Seguramente se pueda hacer parecido desde Windows, pero ni idea...

Espero que sea útil, lo comparto por aquí porque llevaba mucho tiempo buscando el dichoso comando para el parámetro 16 y sinceramente creí que averiguarlo con el tráfico del puerto serie me sería más complicado...

Un saludo!

Iniciado por ministropepon

Buenas a todos,

Voy a dejar por aquí la técnica que he utilizado para obtener los comandos que me faltaban por no estar identificados correctamente en la documentación existente del protocolo P30 (creo que se llama así) de los Voltronic, en mi caso para un Axpert King 5Kw 48v.

Quería cambiar el valor del parámetro 16 "Solar energy priority", para cambiar ente sus dos primero valores:
- SbL UCb: Solar energy for battery first, Allow utility to charge battery
- SbL UdC: Solar energy for battery first, Disallow utility to charge battery

La idea es jugar con los parámetros

01: Output Source Opriority: USb/SbU
10: Operation Logic: ONL / ECO Online o ECO
16: Solar energy priority: SbL UCb / SbL UdC


El parámetro 01 está claramente documentado, es el POP00 (Utility) /POP02 (Solar, battery, utility)
El parámetro 10 esta documentado en las últimas versiones: POPLG01 (InLine), POPLG02 (ECO/Bypass))
El comando 16 no lo he encontrado en ningún sitio, pero finalmente he averiguado que las dos primeras opciones son:
- SbL UCb: PPCP100
- SbL UdC: PPCP101

Lo más gracioso es que esos comandos están documentados, pero con la siguiente descripción que parece que nada tiene que ver con el parámetro 16:
PPCP<MNN><cr>: Setting parallel device charger priority (For 4000/5000)


Con estos 3 parmámetros, ahora sí con sus respectivos comandos por protocolo, quiero automatizar ahora en invierno la carga de baterías por la noche.

Pero vamos al grano del hilo, dado que no lo he encontrado documentado voy a explicar cómo he averiguado el comando del parámetro 16:


Utilizando mi PC Portátil con Debian GNU/Linux:

- Instalar el software oficial WatchPower para linux, versión 64Bits, en mi caso la V1.14SP1
- Probar con puerto serie con el típcio adaptador USB y conectado por el rj45 al inversor
- Si funciona, desconectarlo y creamos el puerto virtual:

Código:

sudo socat /dev/ttyUSB0,raw,echo=0 SYSTEM:'tee in.txt |socat - "PTY,link=/dev/ttyUSBV0,raw,echo=0,waitslave" |tee out.txt'

/dev/ttyUSB0 es, en mi caso el Puerto serial Real
/dev/ttyUSBV0 es el puerto virtual a crear

Los comandos que enviaremos aparecerán en el fichero out.txt y las respuestas que nos llegan desde el inveror quedarán en el fichero in.txt
- Damos permisos al puerto virtual:

Código:

sudo chmod 777 /dev/ttyUSBV0

- Conectamos el Software WatchPower al puerto virutal recién creado
- Aplicamos la configuración deseada en el software
- Paramos inmediatamente con Control + C el comando socat lanzado para crear el puerto virtual

De esta forma, encontraremos el comando al final del fichero out.txt (si es de modificación suelen empezar por "P" o "M" y si es de consulta suele empezar por "Q"

Seguramente se pueda hacer parecido desde Windows, pero ni idea...

Espero que sea útil, lo comparto por aquí porque llevaba mucho tiempo buscando el dichoso comando para el parámetro 15 y sinceramente creí que averiguarlo con el tráfico del puerto serie me sería más complicado...

Un saludo!

Muy interesante, yo en algunas ocasiones utilicé un par de sistemas parecidos, pero en esta ocasión bajo Windows. Realizan algo muy parecido, se crean puertos virtuales en un caso, y en el otro es una especie de hub donde se pueden obtener más de una salida para el mismo puerto. Estos sistemas funcionan, pero todos tienen un digamos fallo de base, y es que si el programa que usas para obtener datos, no conoce o no usa determinadas instrucciones, nunca podrás obtenerlas por este sistema, esto afecta sobre todo el tema de los híbridos, donde las aplicaciones en muchas ocasiones no parecen estar muy actualizadas, y versiones más modernas de firmware pueden tener instrucciones no soportadas por el programa en cuestión.

En cualquier caso es muy interesante todo lo relacionado con este tema ¡¡¡

Habeis probado a escuchar las señales del conector RJ45 remote (el que va fijo en la caja, no los que van en el display desmontable) ?

Creo que ese conector va directo a la placa de control del inversor y se podrian interceptar los traficos entre el display y el hibrido sin que hiciera falta el watchpower. Es decir, configuras un parametro en el display y tienes que verlo en ese trafico tanto el comando como la respuesta.

No he probado, pero no me extrañaría que los comandos/protocolo fuesen los mismos que ya conocemos porque en la pantalla los datos que muestran van con un retraso de varios segundos....

Sería interesante verlo, pero eso no tengo muy claro cómo podría hacerse sin un cacharro aposta...

Un saludo.

Iniciado por ministropepon

No he probado, pero no me extrañaría que los comandos/protocolo fuesen los mismos que ya conocemos porque en la pantalla los datos que muestran van con un retraso de varios segundos....

Sería interesante verlo, pero eso no tengo muy claro cómo podría hacerse sin un cacharro aposta...

Un saludo.

Primero habria que saber el pinout de ese conector. Ya he comprobado que no es el mismo pinout que el RJ45 del puerto serie del display. He medido señales de 12V y -12V tanto fijas como variables (datos rs232, no hay 5V luego no es TTL). Y varias de ellas son lo mismo como si estuvieran puenteadas.

No quiero meter nada por ese conector hasta no conocer exactamente que es cada pin pero si hay datos rs232 sera el trafico que hay entre el display y la placa de control del hibrido. Otra cosa sera si se puede interceptar ese trafico porque si el display ve inyecciones de datos es posible que salte algun error de comunicacion del tipo 32.

Ese trafico puede ser muy interesante ya que clarificaria mucho los algoritmos que usa el hibrido para manejar las baterias de litio de la marca soportada. Y estoy mas que seguro que si los comandos fueran los mismos que se usan por el puerto serie del display se podria usar el hibrido sin el display. O por lo menos de forma provisional por si el display se te estropea.

Iniciado por Jean-Luc Picard

Primero habria que saber el pinout de ese conector. Ya he comprobado que no es el mismo pinout que el RJ45 del puerto serie del display. He medido señales de 12V y -12V tanto fijas como variables (datos rs232, no hay 5V luego no es TTL). Y varias de ellas son lo mismo como si estuvieran puenteadas.

No quiero meter nada por ese conector hasta no conocer exactamente que es cada pin pero si hay datos rs232 sera el trafico que hay entre el display y la placa de control del hibrido. Otra cosa sera si se puede interceptar ese trafico porque si el display ve inyecciones de datos es posible que salte algun error de comunicacion del tipo 32.

Ese trafico puede ser muy interesante ya que clarificaria mucho los algoritmos que usa el hibrido para manejar las baterias de litio de la marca soportada. Y estoy mas que seguro que si los comandos fueran los mismos que se usan por el puerto serie del display se podria usar el hibrido sin el display. O por lo menos de forma provisional por si el display se te estropea.

Estos hibridos es posible usarlos sin MCU, o sea sin panel de control. Todo se controla a traves del conector RJ45 del remoto. Los 8 pines de ese conector que es el mismo que conecta al MCU NO son los mismos que el RJ45 de puerto serie que lleva el MCU. Asi que no os vale ese cable que usais con el conversor USB-SERIE.

Los pines del RJ45 remoto son los siguientes como se ve en la foto de arriba.

1.- MASA
2.- +12v
3.- -12V
4.- MASA
5.- RXdata (entran datos a la placa de control del hibrido)
6.- TXdata ( salen datos de la placa de control del hibrido)
7.- Interruptor encendido. Es un polo del interruptor de encendido del puente inversor de toda la vida. No hay electronica.
8.- Interruptor encendido. Es el otro polo del interruptor de encendido del puente inversor.

Abriendo o cerrando 7 y 8 encendeis y apagais el hibrido si esta solo con baterias o bien encendeis y apagais el puente inversor si esta alimentado con red. Puede ser una buena opcion para apagar y encender el hibrido remotamente con los reles adecuados.

Para conectar un convseror USB-SERIE (no TTL) tendreis que usar la masa de 1 o 4, el 5 ira a TXD del conversor y el 6 a RXD del conversor. De esta forma saltais el MCU y podeis acceder a comandos capados por el MCU como el BTA y similares.

Tambien es posible usar simultaneamente el MCU y este RJ45 remoto. El interruptor del MCU son los pines 7 y 8 del RJ45 remoto, por si alguno solo necesita encenderlo y apagarlo remotamente.

Creo que esto es posible hacerlo en todos los Axpert con MCU.

Para averiguar lo que hacen algunos comandos no documentados en voltronics con MCU lo mejor es interceptar las comunicaciones entre la MCU y la placa de control.

La MCU es el panel con el display por si todavia alguno no sabe que es la MCU.

Con el watchpower lo unico que haceis es interceptar comunicaciones entre el watchpower y la MCU. Para lo que hace ministropepon es valido pero hay bastantes comandos no documentados que no lleva el watchpower y que se pueden sacar escuchando esas comunicaciones entre placa de control y MCU.

No hace falta desarmar nada. Desde el conector RJ45 del remote (el que va fijo en la caja) con los pinouts adecuados que no estan documentados en ningun sitio excepto aqui y ahora, puedes interceptar ese trafico ademas de otras cosas, entre ellas descartar completamente la MCU y manejar el Voltronics solo desde el remote, incluido su apagado y encendido.

La forma de interceptar el trafico es con dos conversores USB-SERIE haciendo que uno escuche lo que habla la MCU y otro lo que habla el hibrido (comando-respuesta). Es decir llevar el pin 5 al RXD de un conversor y el pin 6 al RXD del otro conversor de tal forma que los dos conversores estan escuchando. Esto es importante ya que si conectamos a un TXD de algun conversor estariamos inyectando cosas al canal de comunicacion y el MCU daria un error 32. Una vez recibamos ambos flujos los llevamos a un fichero con anotacion de tiempo. Esto desde nodered es muy facil hacerlo.... incluso podriamos filtrar los comandos y respuestas via funcion js para aligerar trafico.

Hay unos traficos de comandos muy curiosos cuando manejan baterias de litio, la verdad es que se ve claramente por ejemplo el algoritmo de carga que usan con esas baterias. Por ejemplo en pylontech el comando variable que usan para cuando estan casi cargadas es el parametro 2 de amperios totales a baterias. Lo van disminuyendo progresivamente conforme llegan al 100% SOC.
Hay otros comandos que no pasan a la placa de control y se quedan en el MCU. Todos los comandos temporales como fecha y hora mas las timeseries de consumo y produccion se fabrican en el MCU.

La MCU interroga cada 4 segundos a la placa de control con comandos el tipo Q1, QPIWS, QPGS0, QMOD, QPIGS y QPIGS2 si lleva dos campos solares, mientras que interroga cada minuto con QVFW, QSID, QPIRI, QFLAG QBEQI y otros de menor importancia.

La MCU como digo no deja pasar algunos comandos que vienen por el puerto USB o RS232 desde un progama externo ya que hace de cortafuegos. Por ejemplo, un comando BTA de ajuste de voltaje de bateria no es posible usarlo desde el puerto USB o RS232 del MCU mientras que si es posible usarlo desde el conector RJ45 remote sin presencia del MCU.

Dicho todo esto si teneis ganas y tiempo os emplazo a sacar todos esos comandos no documentados entre hibrido y MCU. Estudiando esos comandos y sus respuestas se podria saber realmente que hacen. Y si hay dudas, decompilar algun firmware para buscar ese comando y clarificar su funcion, pero antes hay que aislarlos.

Vaya chute de info en un post!! Que no se os atragante.
Yo vuelvo a mis "ejercicios espirituales". Todavia estoy vivo pero mi tiempo es limitado.... muy limitado. Por eso no me dejo ver mucho y menos puedo forear por aqui. Siento que a algunos no os haya contestado hace meses.

Saludos y cuidaos ahi fuera...

Dios!!!!!!!!!!!!!!!!

Tengo que leer todo esto varias veces y despacio.

Esa placa de la foto es de un MAX ? Supongo que la mayoria de inversores con ese display separable tendran la misma placa y los pinouts seran los que pones.

El protocolo RS232 supongo que sera 2400 8N 1 como el RS232 del display no?

Voy a pillar un par de conversores a ver si se sacar esos traficos.

Ya ire comentando.

Iniciado por Jean-Luc Picard

Dios!!!!!!!!!!!!!!!!

Tengo que leer todo esto varias veces y despacio.

Esa placa de la foto es de un MAX ? Supongo que la mayoria de inversores con ese display separable tendran la misma placa y los pinouts seran los que pones.

El protocolo RS232 supongo que sera 2400 8N 1 como el RS232 del display no?

Voy a pillar un par de conversores a ver si se sacar esos traficos.

Ya ire comentando.

Si es de un MAX pero creo que tendran todos los que llevan MCU la misma placa de comunicaciones. No lo puedo asegurar pero es mas que evidente.
Si, el protocolo es 2400 8 N 1. Si usas nodered solo es necesario el nodo de puerto serie de RX (serial IN) con el split input \r en el setup del dev que sea.

Un flujo basico con filtraje de queries con dos conversores podria ser este, derivando a fichero txt para posterior analisis:

Código HTML:

[
    {
        "id": "44ccc817a8e46565",
        "type": "tab",
        "label": "Flow 1",
        "disabled": false,
        "info": "",
        "env": []
    },
    {
        "id": "ca03636d5b6e515f",
        "type": "serial in",
        "z": "44ccc817a8e46565",
        "name": "",
        "serial": "d8dc84a20ed4ef08",
        "x": 150,
        "y": 40,
        "wires": [
            [
                "9aa627af5f80d31e",
                "857fa76f4017a71c"
            ]
        ]
    },
    {
        "id": "9aa627af5f80d31e",
        "type": "debug",
        "z": "44ccc817a8e46565",
        "name": "Datos procedentes del hibrido",
        "active": true,
        "tosidebar": true,
        "console": false,
        "tostatus": false,
        "complete": "payload",
        "targetType": "msg",
        "statusVal": "",
        "statusType": "auto",
        "x": 690,
        "y": 40,
        "wires": []
    },
    {
        "id": "f7cd65c3d76e2307",
        "type": "serial in",
        "z": "44ccc817a8e46565",
        "name": "",
        "serial": "b498475269f54ea1",
        "x": 150,
        "y": 120,
        "wires": [
            [
                "dd0c3a6c33dd62f4"
            ]
        ]
    },
    {
        "id": "1e3e347fa2a46864",
        "type": "debug",
        "z": "44ccc817a8e46565",
        "name": "Datos procedentes del MCU",
        "active": true,
        "tosidebar": true,
        "console": false,
        "tostatus": false,
        "complete": "payload",
        "targetType": "msg",
        "statusVal": "",
        "statusType": "auto",
        "x": 680,
        "y": 120,
        "wires": []
    },
    {
        "id": "dd0c3a6c33dd62f4",
        "type": "function",
        "z": "44ccc817a8e46565",
        "name": "",
        "func": "var data = msg.payload;\nif (data.includes(\"Q\")){\n    msg = null;\n}\nelse {\n    msg.payload = data;\n}\nreturn msg;",
        "outputs": 1,
        "noerr": 0,
        "initialize": "",
        "finalize": "",
        "libs": [],
        "x": 340,
        "y": 120,
        "wires": [
            [
                "1e3e347fa2a46864",
                "857fa76f4017a71c"
            ]
        ]
    },
    {
        "id": "857fa76f4017a71c",
        "type": "file",
        "z": "44ccc817a8e46565",
        "name": "",
        "filename": "/home/pi/sniffer.txt",
        "appendNewline": true,
        "createDir": false,
        "overwriteFile": "false",
        "encoding": "none",
        "x": 650,
        "y": 80,
        "wires": [
            []
        ]
    },
    {
        "id": "d8dc84a20ed4ef08",
        "type": "serial-port",
        "serialport": "/dev/ttyUSB0",
        "serialbaud": "2400",
        "databits": "8",
        "parity": "none",
        "stopbits": "1",
        "waitfor": "",
        "dtr": "none",
        "rts": "none",
        "cts": "none",
        "dsr": "none",
        "newline": "\\r",
        "bin": "false",
        "out": "char",
        "addchar": "",
        "responsetimeout": "1000"
    },
    {
        "id": "b498475269f54ea1",
        "type": "serial-port",
        "serialport": "/dev/ttyUSB1",
        "serialbaud": "2400",
        "databits": "8",
        "parity": "none",
        "stopbits": "1",
        "waitfor": "",
        "dtr": "none",
        "rts": "none",
        "cts": "none",
        "dsr": "none",
        "newline": "\\r",
        "bin": "false",
        "out": "char",
        "addchar": "",
        "responsetimeout": "10000"
    }
]

En los condicionales de la funcion puedes poner lo que quieras para filtrar trafico o hacer otra funcion para filtrar el trafico de las respuestas. El trafico hay que filtrarlo porque el MCU esta cada 4 secs pidiendo datos al hibrido y eso hay que quitarlo, tanto los comandos como las respuestas. Las respuestas se podrian quitar con otra funcion en base a tiempo de comando. No seria muy dificil.

Bueno, a ver que descubris....

Ya me ire pasando por el hilo cuando pueda....

buenas, gracias por la información a la que solo llego al encendido remoto, en mi caso tengo una instalación semiaislada de la red que controlo con un disyuntor automático comandado por un relé de voltaje a la batería, a 51v cambia los consumos a la red y a 52,5v los vuelve a conectar al inversor con sus respectivos retardos para los picos, tengo el problema que los días muy nublados el inversor se come la capacidad restante de la batería hasta que corta el bms, una vez que pasa esto el regulador no se inicia al día siguiente al no detectar voltaje

si conectara los pines 7 y 8 del rj45 al relé por voltaje se apagaría el inversor al llegar a 51v y se encendería cuando subiera a 52,5v ya que el regulador funciona aunque el inversor esté apagado

¿esto funcionaria?

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

la batería es lifepo4

Iniciado por Angel Baselga

buenas, gracias por la información a la que solo llego al encendido remoto, en mi caso tengo una instalación semiaislada de la red que controlo con un disyuntor automático comandado por un relé de voltaje a la batería, a 51v cambia los consumos a la red y a 52,5v los vuelve a conectar al inversor con sus respectivos retardos para los picos, tengo el problema que los días muy nublados el inversor se come la capacidad restante de la batería hasta que corta el bms, una vez que pasa esto el regulador no se inicia al día siguiente al no detectar voltaje

si conectara los pines 7 y 8 del rj45 al relé por voltaje se apagaría el inversor al llegar a 51v y se encendería cuando subiera a 52,5v ya que el regulador funciona aunque el inversor esté apagado

¿esto funcionaria?

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

la batería es lifepo4

Si, de hecho ese encendido remoto estaba implementado en voltronics de primera y segunda generacion desde el conector verde cambiando unos puentes en la placa de comunicaciones. En los de tercera generacion que son estos del MCU remoto no esta implementada tal cual pero los pinout siguen estando ahi en ese RJ45 remote. Si haces lo que has dicho el interruptor del panel de control debe estar en OFF (abierto) ya que ese interruptor estara en paralelo con los pines 7 y 8 que vas a maniobrar desde tus reles.
Ese pinout 7 y 8 no es como tal un encendido apagado del inversor. Solo se enciende o se apaga la parte inversora, o sea la que da servicio a las cargas ACOUTPUT. Lo que pasa que si no hay ACINPUT equivale a apagarse el display y el consumo sera minimo del inversor pero seguira habiendo un poco.

Los pines en un RJ45 se cuentan segun se ve en la foto:

Recuerda que es el RJ45 REMOTE. No son los RJ45 del panel de control.
Las baterias LiFePO4 con la electronica que llevan tambien tienen autoconsumo. Sobre unos 20Wh. Tenlo en cuenta porque las baterias se seguiran descargando, menos pero se seguiran descargando.

Iniciado por Tejota

Si, de hecho ese encendido remoto estaba implementado en voltronics de primera y segunda generacion desde el conector verde cambiando unos puentes en la placa de comunicaciones. En los de tercera generacion que son estos del MCU remoto no esta implementada tal cual pero los pinout siguen estando ahi en ese RJ45 remote. Si haces lo que has dicho el interruptor del panel de control debe estar en OFF (abierto) ya que ese interruptor estara en paralelo con los pines 7 y 8 que vas a maniobrar desde tus reles.
Ese pinout 7 y 8 no es como tal un encendido apagado del inversor. Solo se enciende o se apaga la parte inversora, o sea la que da servicio a las cargas ACOUTPUT. Lo que pasa que si no hay ACINPUT equivale a apagarse el display y el consumo sera minimo del inversor pero seguira habiendo un poco.

Los pines en un RJ45 se cuentan segun se ve en la foto:

Recuerda que es el RJ45 REMOTE. No son los RJ45 del panel de control.
Las baterias LiFePO4 con la electronica que llevan tambien tienen autoconsumo. Sobre unos 20Wh. Tenlo en cuenta porque las baterias se seguiran descargando, menos pero se seguiran descargando.

gracias, ya esta funcionando a la perfección

el inversor solo por estar encendido consume 1,65 Ah x 53 v = 87,45wh x 16 h = 1,399 Kwh, que los días muy nublados, mas o menos desde las 6 de la tarde hasta las 9 de la mañana tenia que dejar de reserva en la batería y ahora puedo aprovechar en el consumo

cuando abro el interruptor, inmediatamente apaga el inversor y se queda como 15 o 20 segundos en apagar el regulador y la pantalla, sin entrada de paneles claro, ahí consume entre 20 y 25 mAh lo que x 53v = 1,2 wh

los bms que tengo son daly que se se supone que cuando tienen poco consumo se quedan dormidos, tienen muy poco consumo, de hecho ni siquiera conectan por BT si no se despiertan con una carga o descarga más alta o pulsando el botón del dispositivo

gracias de nuevo, ya me veía abriendo el display para intercalar el interruptor en el pulsador de encendido

Voy a enlazar este hilo con el de la review del MAX que supongo que esto del remoto le interesara a mas gente, sobre todo lo de los pines 7 y 8 que no estan documentados en ningun sitio.

'Angel Baselga' lo de dar las gracias esta muy bien !!!, pero en este foro entran muchos con un conocimiento muy justito de electricidad por lo que te pediria que describieras con detalle el cableado que has realizado (que conexiones has realizado en el RJ45 que ha aportado 'Tjota' si has añadido algun interruptor u otro elemento para activar/desactivar que el inversor no trabaje, y en que puerto del hibrido lo conectas, ya que en las fotos de #6 puede verse que hay tres conexiones RJ45), cuando dices "cuando abro el interruptor, inmediatamente apaga el inversor..." tu sabes de que interruptor estas hablado, pudiera ser el On/Off del hibrido o uno que hubieras cableado a los pines 7 y 8 del de ese nuevo RJ ...

por favor detalla la operativa y gracias por el aporte de los valores de consumos que nos subes.

Home me alegra verte activo Tejota ¡¡¡ , yo tampoco es que este muy activo últimamente. Ya echaba de menos tos post técnicos... Y efectivamente, aunque no le metí mano a la MCU, yo también detecte ese comportamiento de reducción de amperaje en carga de las weco, incluso varia dependiendo del numero de baterías que tengas en carga.
Lo del apagado remoto, parece algo interesante y no complicado de hacer... lo mismo me animo y lo monto en mis dos inversores.

Muchas gracias por la info, como siempre información muy util ¡¡¡
Saludos ¡¡

Iniciado por solflitos

'Angel Baselga' lo de dar las gracias esta muy bien !!!, pero en este foro entran muchos con un conocimiento muy justito de electricidad por lo que te pediria que describieras con detalle el cableado que has realizado (que conexiones has realizado en el RJ45 que ha aportado 'Tjota' si has añadido algun interruptor u otro elemento para activar/desactivar que el inversor no trabaje, y en que puerto del hibrido lo conectas, ya que en las fotos de #6 puede verse que hay tres conexiones RJ45), cuando dices "cuando abro el interruptor, inmediatamente apaga el inversor..." tu sabes de que interruptor estas hablado, pudiera ser el On/Off del hibrido o uno que hubieras cableado a los pines 7 y 8 del de ese nuevo RJ ...

por favor detalla la operativa y gracias por el aporte de los valores de consumos que nos subes.

Solflitos: la operativa esta perfectamente detallada en las fotos y en la explicacion que doy de los pinouts. El RJ45 q se usa es el que esta fijo en el chasis. Lo llamo MCU remote y en la foto esta con una flecha señalado. Es donde se conecta el cable extensor para el display removible. Esos pinouts no estan documentados en ningun manual ya que ahi solo se conecta un cable de red de 8 pines directos uno a uno hacia el display que lleva otro RJ45 hembra. Esos pinouts los he sacado siguiendo las conexiones de la placa de comunicaciones de la foto de #6, o sea, trabajo de investigacion o de campo. Es logico pensar que si el display es removible, el boton de encendido tiene que ir en esos pinouts y son el 7 y 8. Lo que me sorprende es que nadie haya documentado ese pinout en dos años que lleva ese equipo en el mercado. VMIII, KINGs y demas tambien.
Para simplificar todo, los pines 7 y 8 de ese RJ45 son el interruptor del display. Si pulsas el interruptor (enclavamiento) cierras 7 y 8. Y si desenclavas el interruptor abres 7 y 8. Eso lo puedes hacer con reles, con contactores, como estimes oportuno. No hay nada electronico en 7 y 8 ni tiene que haberlo. El resto de pines son de datos y de tensiones para alimentar cosas. No hay mas.

Iniciado por Au-PRX

Home me alegra verte activo Tejota ¡¡¡ , yo tampoco es que este muy activo últimamente. Ya echaba de menos tos post técnicos... Y efectivamente, aunque no le metí mano a la MCU, yo también detecte ese comportamiento de reducción de amperaje en carga de las weco, incluso varia dependiendo del numero de baterías que tengas en carga.
Lo del apagado remoto, parece algo interesante y no complicado de hacer... lo mismo me animo y lo monto en mis dos inversores.

Muchas gracias por la info, como siempre información muy util ¡¡¡
Saludos ¡¡

Bueno, que no este activo en el foro no quiere decir que no este activo en lo que realmente importa. Lo que pasa que tengo que elegir entre estar por aqui o hacer trabajo de campo con estos equipos.... como ves voy por esto ultimo ya que es mas divertido. El problema viene cuando vengo por aqui y suelto de golpe algo de info interesante. Estoy ahora metido con unas pylon y sus datos por puerto serie. Nada que no se pueda parsear y poner bonito. Pero me ha intrigado el algoritmo de carga que usan los chinos con las pylon y la unica forma de saberlo es snifeando ese rj45. Cuando lo tenga claro ya pondre que es lo que hacen exactamente porque hay comandos no documentados habilitados en el firmware. Los veo pero hay que investigar que hacen exactamente porque se podrian mandar directamente por ese rj45 sin necesidad del display que es algo que no me gusta nada debido a que recolecta datos y los manda a taiwan si le abres la puerta. De chinos, chinadas. Otro problema añadido es que no puedes inyectar datos en ese rj45 si el display esta conectado, solo puedes escuchar. Por eso hay que ver hasta que punto vale la pena quitar el display o no.

Buenos días,

Me gustaría poder colaborar en este tema si aún no lo tienes todo documentado, que veo que hace meses de esto.
En mi caso, llevo una semana justo con una instalación parecida a la tuya: en cuanto a inversor y baterías; y estoy dándome cabezazos con la escasa información y menos funcionalidad de la aplicación y, dando pasitos con vuestros posts.
Trabajo como Administrador de Sistemas, por lo que tengo cierta experiencia en la captura de comunicaciónes, especialmente ethernet pero, no me importaría documentarme y hacerlo de transmisiones RS232 o RS485.
Si te parece, voy a prepararme el laboratorio de pruebas y, capturo algunos paquetes y veo qué consigo y te consulto.
Por otro lado, creo que también podría ser interesante coger una actualización de firmware y desemsamblarla, aunque posiblemente vaya ofuscada pero, hay métodos de desofuscación que nos podrían ayudar.

Un saludo.

Iniciado por sereuca

Buenos días,

Me gustaría poder colaborar en este tema si aún no lo tienes todo documentado, que veo que hace meses de esto.
En mi caso, llevo una semana justo con una instalación parecida a la tuya: en cuanto a inversor y baterías; y estoy dándome cabezazos con la escasa información y menos funcionalidad de la aplicación y, dando pasitos con vuestros posts.
Trabajo como Administrador de Sistemas, por lo que tengo cierta experiencia en la captura de comunicaciónes, especialmente ethernet pero, no me importaría documentarme y hacerlo de transmisiones RS232 o RS485.
Si te parece, voy a prepararme el laboratorio de pruebas y, capturo algunos paquetes y veo qué consigo y te consulto.
Por otro lado, creo que también podría ser interesante coger una actualización de firmware y desemsamblarla, aunque posiblemente vaya ofuscada pero, hay métodos de desofuscación que nos podrían ayudar.

Un saludo.

Oh! un operador de sistema... una rara avis por estos ecosistemas...
De que inversor y baterias estamos hablando?? Porque cada fabricante aqui va a la suya, cada uno tiene su protocolo y cuando tienen que ponerse de acuerdo entre fabricantes siempre hay problemas de todo tipo.
Yo he optado por "hablar todos los idiomas" y hacer de interprete. Es decir, entre ellos ni una palabra para evitar problemas.
Al ser equipos industriales se hablan en rs232, rs485.... no hay encriptacion de nada.... simplemente algunos CRC de comprobacion para unos y modbus para otras cosas.
Yo estoy usando NODERED como plataforma de desarrollo. NodeJS en debian. Aunque para sacar algun trafico interesante desde programas windows de algun fabricante seria bueno un NODERED bajo Windows y pillar trafico rs232, rs485 entre el programa win del fabricante y sus productos. O bien, encapsular un rs232 sobre tcpip y ver el trafico.
De que desofuscaciones estamos hablando?? En los firmwares se ve mucho ASCII ordenado, quizas no haya tanta ofuscacion. En inversas estoy algo espeso pero bueno es saber de alguien que desofusca.

A falta de raspberry pi a precio asequible, voy a montar un viejo PC que tenia con Molinux para los estudios de mi hijo. He pensado en poner una Debian ligerita aunque, si interesa capturar información de comunicación con software de windows, puedo poner un dual boot o, poner windows en máquina virual con VirtualBox, por ejemplo.
Mi inversor es un Voltronic Axpert 7.2 y, me tiene loco con los datos que aporta la aplicación porque carecen de toda lógica. El instalador me dice que mire mejor los datos rn pantalla pero, no puedo estar todo el día mirando la pantallita. Me aprece absurdo que en esta época y con la cantidad de software open source que hay, no tengan una solución de monitorización decente.
Pero bueno, si ellos no la hacen, la haremos nosotros. El mismo capitalismo hipercompetitivo está haciendo que los consumidores de los que viven se vean forzados a independizarse y ser autosuficientes.

Iniciado por sereuca

A falta de raspberry pi a precio asequible, voy a montar un viejo PC que tenia con Molinux para los estudios de mi hijo. He pensado en poner una Debian ligerita aunque, si interesa capturar información de comunicación con software de windows, puedo poner un dual boot o, poner windows en máquina virual con VirtualBox, por ejemplo.
Mi inversor es un Voltronic Axpert 7.2 y, me tiene loco con los datos que aporta la aplicación porque carecen de toda lógica. El instalador me dice que mire mejor los datos rn pantalla pero, no puedo estar todo el día mirando la pantallita. Me aprece absurdo que en esta época y con la cantidad de software open source que hay, no tengan una solución de monitorización decente.
Pero bueno, si ellos no la hacen, la haremos nosotros. El mismo capitalismo hipercompetitivo está haciendo que los consumidores de los que viven se vean forzados a independizarse y ser autosuficientes.

El instalador va a flipar cuando vea los datos de ese inversor fuera de la pantallita....

La ultima Rpi 4 q pille hace una semana me costo 128€ nueva a estrenar. Me da que mas barata tal cual esta el patio mundial sera dificil. Despues falta, ssd, disipadores y alimentador. Los 200 y pico € no te los quita nadie.

Para monitorizacion standard no hace falta investigar datos. Con la info actual se sacan los mas importantes. Lo de la investigacion de datos es para comandos raritos y cosas muy especificas que no estan documentadas en ningun sitio.

hola, soy nuevo por este foro, y después de mucho leer, estoy empezando a crear mi propio programa en node red, para poder monitorizar mi vm3, nunca conseguí hacerlo funcionar desde el puerto rs 232, pero si con el micro puerto usb.
Después de mucho tiempo conseguí realizar un dasboard en el cual me muestra todos los datos que creo interesantes, incluso conseguir graficas diarias de consumos.
Ahora mi pregunta es, que comando uso para enviar al voltronic para que me devuelva la produccion solar y el consumo de la red eléctrica, tal como se muestra en la mcu.
Yo e conseguido sacarlo haciendo cálculos en node red, pero no llegan a coincidir con los del voltronic mostrados en pantalla.
Quizás, este comando se pueda ver observando el trafico de comandos de la MCU.
Os dejo con unas capturas de mi proyecto