Usando la IA para organizar el club de pádel donde juego

Utilicé un método sencillo para transformar un PDF en una infografía visual con objeto de explicar un algoritmo para formar partidos de pádel y llevar un ránking en el club de pádel donde juego.

https://blogpocket.es/usando-la-ia-para-organizar-el-club-de-padel-donde-juego/

Si, continuamos con la serie de tutoriales basadas en el hecho de que ya tenemos una red privada virtual (VPN) desde la que podremos acceder a la autenticación de servicios a los que solo nosotros accedemos.

Introducción

Hasta el momento hemos tenido éxito en dejar solo las rutas necesarias para NextCloud y dejando en secreto una instancia FreshRSS. La primera ruta es parcial y la segunda, oculta completa. Ahora, nos toca ocultar parcialmente una que puede resultar un poco más compleja debido a que hablamos de WordPress. El sistema de blogs utilizado para casi cualquier cosa y por eso puede tener puertas por todas partes. Ya no es necesario poner los requisitos puesto que ya los cumplimos todos, así que vamos directo a la teoría.

Desarrollo

La verdad pensé que sería tan sencillo como mandarle un location deny all, pero no. WordPress usa un sistema de rutas y embellecedores de URL que puede hacer que olvides que /wp-login no es lo mismo que /wp-login.php. Además, bloqueando el /wp-admin se te carga también el sistema AJAX, con lo que el contact form 7 dejaría de funcionar. Vamos repasando lo que hemos hecho para evitar todo esto. 1 2 3 4 5 6 7 8location = /wp-admin/admin-ajax.php { allow all; # Permitir que el público lo use para formularios/filtros # IMPORTANTE: Aquí debes incluir tu configuración de PHP # para que Nginx sepa cómo procesar el archivo. include snippets/fastcgi-php.conf; fastcgi_pass unix:/var/run/php/php8.4-fpm.sock; # Ajusta a tu versión de PHP } Debes agregar este fragmento a tu archivo de configuración de nginx después de tu bloque de php. Esto es porque luego bloquearemos la ruta /wp-admin la cual terminará cargándose al admin-ajax.php el cual sirve para muchas funciones, especialmente para los plugins. pero si no tienes casi nada, es posible que solo afecte al funcionamiento de contact form 7 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21location /wp-admin{ allow 10.0.0.0/24; deny all; include snippets/fastcgi-php.conf; fastcgi_pass unix:/var/run/php/php8.4-fpm.sock; # Ajusta a tu versión de PHP} location /wp-login{ allow 10.0.0.0/24; deny all; include snippets/fastcgi-php.conf; fastcgi_pass unix:/var/run/php/php8.4-fpm.sock; # Ajusta a tu versión de PHP}location = /wp-login.php { allow 10.0.0.0/24; deny all; include snippets/fastcgi-php.conf; fastcgi_pass unix:/var/run/php/php8.4-fpm.sock; # Ajusta a tu versión de PHP} Estos bloques son de lo mas predecible. Al igual que en los casos anteriores, basta con definir la ruta que queremos bloquear y pues… bloquearla. Recuerda que la intención es que se pueda acceder por la red privada virtual, así que agrega tu rango de subred con el que tienes configurado WireGuard. Por ultimo, haremos unos cuantos ajustes de seguridad. 1 2 3location ~* (readme.html|debug.log|license.txt) { deny all; } Esto es mas para protegerte de descuidos. El archivo readme.html y licence.txt está públicamente accesible. Bloquéalo para no delatar tu versión exacta de WordPress (es mas fácil atacar una versión especifica que atacar al azar hasta que aciertas a la vulnerabilidad que buscas). Debug.log es un archivo que queda visible si has habilitado la depuración. Hay mucha info sensible allí. Lo mejor es que lo escondas por si las dudas. Con estos cambios ya no tendrás que preocuparte tanto por ataques de fuerza bruta pues, no pueden forzar la cerradura si no hay cerradura XD. También te beneficia si tienes pocos recursos, porque tu servidor no tiene que estar atendiendo al ruido de Internet (bots, scrappers, etc) y puede centrarse en el trafico real.

Conclusiones

Pues verás, a diferencia de mi pobre lector de RSS que no tenia muchas visitas indeseadas, mi blog principal si que es atormentado todo el tiempo. Los que responden 200 son solo de tanteo. Confirman que la página existe. Pero los que devuelven otros errores son de ataques. Si no los bloqueara, estarían ahí todo el rato probando combinaciones de contraseñas hasta dar con la correcta y joderme la vida. Y verás, probablemente puedas comprobar por ti mismo si estos códigos funcionan. Basta con que entres a la url de /wp-admin o /wp-login y encontraras errores 403 Pero el resto del sitio esta completamente funcional. El hecho de que pueda seguir escribiendo y puedas leer este post, es prueba de que las configuraciones aquí aplicadas han funcionado. ¿Sobre qué ganamos con esto? la verdad, algo mas de paz. Ya no tienes que preocuparte tanto por la calidad de tu contraseña, pero no te descuides, para todo, activa A2F (autenticacion en dos factores) porque aun puedes tener accidentes. Ya sabes, errores de capa 8 jajaja. En adelante, los logs ya no deberán dar respuestas 200, sino un error 403. Ya es cuestión de modificar las reglas de fail2ban para que bloquee a los que provocan esos errores, pero claro, recordando que no te bloquees a ti mismo porque si olvidas entrar con wireguard activo, puede dejarte pateado afuera. https://interlan.ec/blog/2026/05/01/tutorial-mejorando-la-seguridad-de-wordpress-mediante-regas-nginx/ #Blog #devops #experimentos #linux #nginx #seguridadInformática #selfhosting #servidores #spam #tutorial #vps #wordpress

Dado lo bien que salio el ejercicio anterior, vamos a probar aislar un servicio por completo para posteriormente, aislar parcialmente un servicio. En este caso, FreshRSS.

Introducción

En el caso anterior, lo que hicimos fue segmentar un servicio que ya era privado y del que solo queríamos un segmento específico atendiendo a Internet. Este proceso se llama «reducción de superficie de ataque». Este proceso permite cerrar las puertas que pueden intentar forzar para entrar y causarte daño, pero en mi caso es más como reemplazar la puerta por una pared. Te adelanto que tal vez esta técnica no aplique para todos los casos, así que numeraré unos cuantos para que veas si te conviene seguir el camino del ermitaño o continuar como ya estabas.

• Eres el único usuario de tus servicios e infraestructura. Es decir, montaste un servicio público por alguna necesidad puntual como, un lector RSS que puedas alcanzar desde cualquier parte de Internet o algún servicio de notas o algún servicio de sincronización.
• Quieres tener control de tu infraestructura por una «puerta trasera» Suena feo, pero es cuestión de seguridad. No necesitas que todo el mundo esté tocando a la puerta todo el tiempo si eres el único que tiene la llave y el único que puede (y debe) entrar.
• Quieres tener un terreno seguro de juego mientras desarrollas tus cosas. No necesitas desplegar SSL en un entorno privado. Eso facilita muchas cosas.

En ese sentido, reducir la superficie de ataque puede ayudarte a no tener que preocuparte tanto por vulnerabilidades, pero puede complicar un poco la administración. Además claro, tienes que confiar en servicios que pueden caer y dejarte aislado de todo.

La idea es simple y se basa en la siguiente premisa: «¿Si soy el único que usa los logins y demás sistemas de autenticación, ¿para qué tengo que dejarlos al aire para que todos los días estén dale que dale tratando de hackearlos por fuerza bruta los crawlers de Internet?» Así que la idea es simplemente negar el acceso a los sistemas de autenticación a la red expuesta a Internet y dejarla solo para la red expuesta a la red local o la red de WireGuard. Así que en teoría, lo que se necesita es lo siguiente:

• Crear una red WireGuard.
• Crear un servidor DNS para la red WireGuard
• Configurar el DNS para que solo funcione en la interfaz de WireGuard
• Configurar un servicio para que trabaje en la interfaz de WireGuard
• Limitar los accesos a áreas públicas por la interfaz de red
• Limitar los accesos a áreas de autenticación solo a la red de WireGuard

Mira tú, ya tenemos casi todo completo y ahora solo falta ir resolviendo los casos particulares.

Cambiando puertas por paredes

En este ejercicio vamos a bloquear por completo el acceso y uso publico de un servicio que no necesita mas visitas que las mías. En este caso, FreshRSS.

Esta vez no comparto los logs porque realmente hay poco trafico basura que mostrar.  La cosa es muy distinta cuando intente bloquear parcialmente el wp-admin y ya verán por que.

Como esta vez el dominio es distinto del equipo de origen, tendremos que hacer algunos ajustes. Recuerda que esto es parte de un tutorial anterior.

Agregamos nuevas reglas a Nginx para que solo permita el acceso desde la interfaz de Wireguard

Al principio del archivo de configuración de nginx:

1 2 3 4 5map $remote_addr $es_vpn { default 0; "~^10\.0\.0\." 1; # Esto usa una expresión regular para atrapar a cualquiera que empiece con 11.0.0.}

Dentro de tu regla server

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 # 1. REGLA ESPECIAL PARA AJAX (WordPress la necesita pública) location = /wp-admin/admin-ajax.php { include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_pass unix:/run/php/php8.4-fpm.sock; } # 2. BLOQUE ÚNICO PARA TODO PHP (Incluye la seguridad VPN) location ~ \.php(?:$|/) { # 1. Definir una variable de control set $permitido 0; # 2. Si es la VPN, sumamos 1 if ($es_vpn = 1) { set $permitido 1; } # 3. Si NO es zona restringida (o sea, es el front del sitio), sumamos 1 if ($uri !~* "(wp-admin|wp-login)") { set $permitido 1; } # 4. Si después de ambas comprobaciones sigue en 0, es que es zona restringida Y NO es VPN if ($permitido = 0) { return 403; }

Esta acción genera un error 403 para todos los directorios del dominio. Es justo lo que buscamos. Ahora tenemos que editar en el archivo que creamos antes. el hosts.wireguard para cambiar las rutas y dominios.

10.0.0.2 freshrss.misitio.com #la ip en la red wireguard de tu servicio

Y ejecutas el systemctl restart dnsmasq y listo. Como puedes ver, esta vez tuvimos que hacer muchos menos pasos y recuperamos, esta vez de forma exclusiva, el acceso a nuestra pagina de lector de RSS.

Debido a que el firmado SSL no se encuentra fuera del servidor, esta vez no tenemos que mover nada mas. Lo tendremos firmado apenas lo abrimos.

Conclusiones

Esta vez logramos hacer esta tarea mucho mas rápido y metiendo menos código. Para este ejercicio, la verdad pensaba que iba a ser mas sencillo y funcionar a la primera con un simple deny al directorio correspondiente, pero como puedes ver, es un monton de lineas de codigo. Esto es porque tras algunas pruebas descubrí que si bien bloqueaba efectivamente al Internet abierto, en la VPN dejaba libre como esperabamos, pero dejaba de procesar el archivo php, devolviendo un wp-login.php en texto plano. Es decir, cualquiera que estuviera en tu VPN iba a poder ver los archivos PHP de tu servidor. Pero solo los que bloqueamos, claro. Tras algunas practicas, finalmente llegue a esta conclusion y creo que es la mas funcional. Lo sigo revisando por si hay alguna sorpresa, pero parece muy funcional.

¿Sobre los resultados de esto? han pasado varias semanas desde que lo implementé. Parece que si el servidor responde con 403, los crawlers llegan a cansarse y dejar de insistir. En el caso del log de hoy, solo hay un intento de acceder. mientras que para el día de ayer, solo fueron 4. Parece funcionar, ¿no?

Estoy cuestionándome un poco sobre la practicidad de esto, puesto que si desplegaste Freshrss en una VPS o hosting, es probable que haya sido por lo práctico que es tener el lector unificado y accesible desde cualquier parte de Internet. En ese sentido, podrías elegir tener un lector local en tu dispositivo, pero esto es una práctica y vamos a hacer estas locuras hasta encontrarle un uso práctico. En próximas entregas ya hablaremos de un uso más serio, segmentando un sitio con más tráfico para probar y ver resultados.

https://interlan.ec/blog/2026/04/24/tutorial-reduccion-superficie-de-ataque-mediante-wireguard-nginx-dnsmasq/ #experimentos #freshrss #la #linux #nginx #rss #seguridad #seguridadInformática #selfhosting #servidores #tutorial #vps

Dado que aprovechar la inteligencia artificial para tareas sencillas es imposible sin una supercomputadora (o muchas supercomputadoras), volvemos a los orígenes con un nuevo plan de mejora para las VPS. Contamos con WireGuard, lo hemos pulido hasta que funciona con el ancho de banda completo. Vamos a confiar un poco más en el para administrar los servicios que tenemos expuestos por internet… ¡En privado!

Introducción

La idea es simple y se basa en la siguiente premisa: «¿Si soy el único que usa los logins y demás sistemas de autenticación, ¿para qué tengo que dejarlos al aire para que todos los días estén dale que dale tratando de hackearlos por fuerza bruta los Crawlers de Internet? Así que la idea es simplemente negar el acceso a los sistemas de autenticación a la red expuesta a Internet y dejarla solo para la red local o la red de WireGuard. Así que en teoría, lo que se necesita es lo siguiente:

• Crear una red WireGuard.
• Crear un servidor DNS para la red WireGuard ←Estamos aquí
• Configurar el DNS para que solo funcione en la interfaz de WireGuard
• Configurar un servicio para que trabaje en la interfaz de WireGuard
• Limitar los accesos a áreas públicas por la interfaz de red
• Limitar los accesos a áreas de autenticación solo a la red de WireGuard

Todo esto se me ocurre en el contexto de que tengo un servidor NextCloud que trabaja en público y a diario tengo crawlers intentando entrar. La solución simple es fácil. Ya que ahora trabaja mediante WireGuard, puedo agregar la IP de la VPN y usarla de forma privada. No es gran problema excepto porque me interesa que se mantengan las funciones públicas, como los enlaces compartidos, las agendas de calendarios y alguna cosa que se me antoje por ahí. En ese sentido, la complejidad aumenta bastante porque no es solo desconectar de la interfaz pública, sino también elegir las rutas que dejarán de ser accesibles por Internet y que estas sean accesibles por la red WireGuard. Si la teoría es posible, me gustaría poder aplicar esto a más servicios en los que soy el único que se autentica, como por ejemplo este blog. Por esa razón, vamos a necesitar la ayuda de un DNS local exclusivo para WireGuard.

Agregando Reglas Nginx

Para empezar, tomaré como modelo mi servidor de Nextcloud, puesto que no necesito hacer mas maromas para lograr lo que quiero. Lo primordial será bloquear el acceso de las rutas de autenticación a través de Internet. Para eso vamos viendo como están los logs. logs de mi instancia de nextcloud mostrando algunos accesos por login y un monton de escaneos de directorios Como se puede ver en la imagen, hay varios intentos de acceso por la url login, pero un montón de escaneos de directorios (debo mejorar las reglas de fail2ban) Ya he descontado mis propios accesos y también del monitor uptime. Lo primero es agregar las reglas apropiadas para limitar el acceso a la ruta /login Hay que recordar que NextCloud tiene una regla que redirecciona el trafico no autenticado desde el directorio raíz al directorio /login, por lo que si tienes algo monitorizando esa ruta, disparará la alarma de inmediato. location /admin { allow 10.0.0.0/24; # Tu red de WireGuard deny all; # Bloquea al resto del mundo include snippets/fastcgi-php.conf; fastcgi_pass unix:/var/run/php/php8.4-fpm.sock; # Ajusta a tu versión de PHP } Recuerda cambiar la ruta que quieres bloquear. en el caso de NextCloud, la ruta es /login Apenas aplicas los cambios con systemctl restart nginx ya notaras el cambio al acceder al login desde Internet. Login de Nextcloud antes de aplicar la regla de Nginx Login de Nextcloud luego de aplicar la regla de Nginx Por supuesto, esto nos deja pateados afuera. Pero puedes acceder a Nextcloud mediante la VPN normalmente. Aunque faltan hacer algunos ajustes todavía.

Un DNS personal

Si dejamos esto hasta aquí, nos encontraremos con que Nextcloud desconfía de nosotros. Nextcloud, error de acceso por dominio sin confianza Esto es normal y bastaría con agregar la ip de tu servidor como dominio de confianza, pero queremos tener más servicios con la autenticación escondida. Y eso que no estamos contando que los servicios que dependen de SSL pueden dar conflictos al acceder solo por IP. lo primero es instalar dnsmasq sudo apt install dnsmasqDnsmasq es un software ligero y de código abierto diseñado para redes pequeñas, que actúa como servidor DNS (sistema de nombres de dominio) caché y servidor DHCP (protocolo de configuración dinámica de host). Proporciona servicios esenciales como la resolución de nombres locales y la asignación de IPs, siendo muy común en routers domésticos y entornos Linux. Aunque puedes instalar esta herramienta en cualquiera de tus equipos de la red WireGuard, es recomendable instalarlo en la que hace de servidor. Lo que vamos a hacer, es crear un servidor DNS intermediario, que reemplace las direcciones de tu dominio para que apunte a las redes locales de forma prioritaria. De esta manera, tu configuración de red normal va a seguir apuntando al Internet de siempre, pero con esta configuración, al encender wireguard, las consultas DNS se harán mediante dnsmasq, permitiendo poder acceder normalmente con la dirección de dominio anterior sin cambiar nada mas. En la configuración de los clientes de wireguard debes poner ya la IP de tu servidor. Esto lo hace opcional pues cada cliente puede configurar sus cosas a gusto, asi que no estas forzando a nadie que no quiera. Ahora, vamos a /etc/dnsmasq.conf interface=wg0 # Escucha solo en la interfaz de la VPN listen-address=127.0.0.1, 10.0.0.1 bind-interfaces # Evita conflictos con otros servicios DNS domain-needed # No reenvía nombres sin punto (seguridad) bogus-priv # No reenvía IPs privadas a internet# DNS públicos para lo que no sea tu red localserver=8.8.8.8 server=1.1.1.1 # No busques en el archivo de hosts de internet no-hosts # Pero SÍ usa este archivo que crearemos para tus dominios locales addn-hosts=/etc/hosts.wireguard Recuerda revisar tu archivo dnsmasq.conf por si estas lineas no están comentadas ya. Dado que es una instalación nueva, basta con agregar todo esto al final del archivo pues todo esta comentado. Ahora tenemos que crear el archivo /etc/host.wireguard para agregar los dominios e ip que necesitamos 10.0.0.1 ://tu-dominio.com y ya con esto, basta con reiniciar el servicio dnsmasq systemctl restart dnsmasq A partir de este momento, cuando ingreses a tu dominio con wireguard apagado, veras el mismo error 403 como todos. pero cuando lo hagas con wireguard encendido, veras tu instancia de Nextcloud completamente funcional.

Últimos Pasos

He estado describiendo estos pasos asumiendo que ya te has encargado de los problemas relacionados con SSL. Después de todo, si tienes un sitio web, seguro sale por https. Sin embargo, aunque la redireccion permite aprovechar las mismas credenciales que los servicios que quieres ocultar, en este caso en particular teniamos el siguiente esquema: Internet → dominio publico/Nginx → WireGuard → servidor privado/Nginx Por lo que tenemos que lidiar con dos servidores Nginx, asi que el paso que buscabamos ahorrarnos, pues nos lo tenemos que cargar. Pero tampoco es para tanto. SI ves las configuraciones de tu sitio publico, encuentras las rutas donde deben estar los certificados y tambien como habilitar https. basta con que copies los archivos en el mismo lugar de tu servidor privado. Entonces ya todo vuelve a quedar funcional y bonito.

Conclusiones

Digamos que esta serie de tutoriales serán un caso de «Sobreingeniería de la pereza«. Me gusta cómo están funcionando las cosas ahora, pero empieza a cansarme teniendo los crawlers ahí tocando la puerta todo el tiempo. Al hacer estos ajustes, puedo seguir como siempre sin tener expuestas las puertas de mis servicios y claro, tengo menos exposición a vulnerabilidades de las que no estén pendientes. Además, tampoco es necesario tener tanta cosa expuesta. Siendo el único que usa los servicios que estoy desplegando, tampoco es que me haga falta que más gente conozca dónde está la cerradura para intentar forzarla. Aún estoy decidiendo cuál es el próximo servicio a ocultar, pero estoy entre WordPress y mi servidor de correo electrónico. Mi blog, aunque tiene códigos y funciones especiales, prácticamente es un sitio estático y en cuanto al correo, solo hace falta tener a postfix ahí escuchando los correos entrantes. Los salientes, ni siquiera necesitan un puerto abierto.

Actualización

Aunque aún no se ha publicado este post, he estado haciendo pruebas y viendo los resultados. Efectivamente el tráfico ha disminuido y a fail2ban solo le queda bloquear a toda IP que haga 404 o 302. El uso del VPS bajo muchísimo, así que se puede aprovechar el potencial extra en otras tareas. Pero ya sé cuál será el próximo servicio que oculte mediante este método.     https://interlan.ec/blog/2026/04/17/tutorial-desplegando-dns-privado-para-red-wireguard/ #experimentos #nextcloud #nginx #seguridadInformática #selfhosting #servidores #spam #tutorial #vps

Inertia se mueve para comercializar uno de los experimentos científicos más elaborados del mundo #científicos #comercializar #del #elaborados #experimentos #fusión_nuclear #Inertia #Inertia_Enterprises #laboratorio_nacional_lawrencelivermore #los #más #mueve #mundo #para #poder_de_fusión #uno #ButterWord #Spanish_News Comenta tu opinió...
https://butterword.com/inertia-se-mueve-para-comercializar-uno-de-los-experimentos-cientificos-mas-elaborados-del-mundo/?feed_id=77651&_unique_id=69de2b1153d8f

Materializando Karel 40 años después

En octubre de 1985 presenté mi proyecto de fin de carrera sobre Karel el Robot, un lenguaje de programación educativo creado por Richard Pattis en 1981. Cuarenta años después, he decidido darle una nueva vida convirtiéndolo en una aplicación web interactiva que cualquiera puede usar desde el navegador (puedes probarla en blogpocket.es/karel). Mi proyecto de fin de carrera fue puramente teórico: una modificación al lenguaje Karel y su gramática formal, incluyendo la especificación […]

https://blogpocket.es/materializando-karel-40-anos-despues/

Generación (optimizada) automática de la página con noticias de IA

Cómo conectar NotebookLM con Claude Desktop mediante MCP para automatizar flujos de trabajo con IA.

https://blogpocket.es/generacion-optimizada-automatica-de-la-pagina-con-noticias-de-ia/

Como era de esperarse, este aparato dejó de funcionar. Irreparablemente. Claro, en realidad es reparable, pero las molestias son tantas para su tan bajo coste que sale mejor comprar otro y olvidarse del asunto. Igual tenia curiosidad por desarmarlo y así lo hice.

Introducción

Como muchas de las cosas que desarmo, esto sufre de un efecto de obsolescencia programada. No creo que sea tan intencional como sugiere la expresión y mucho de lo que he visto que se califica como obsolescencia programada, solo es flojera o un intento de abaratar costos. Por supuesto que existe la que trata de maximizar ganancias, pero no parece ser tan común como la simple flojera o intentos de abaratar costos. Este aparato cuenta con solo 4 tornillos. Es perfectamente desarmable, y otros componentes estan fijos en su lugar por fijacion mecanica y no adhesivos. es posible desarmarlo por completo sin romper nada, pero no invita a repararse. Las cuatro pilas de Niquel y Cadmio estan encerradas en el cuerpo del aparato y no hay forma de reemplazarlas sin desarmarlo. Tampoco da alternativas de funcionamiento cuando las pilas dejen de hacerlo, asi que una vez muertas, para el comun de la humanidad, el aparato entero sera inservible. Las pilas de Ni-Cd (4.8V) son un sistema de almacenamiento de energia barato y ya anticuado, que sufre un fuerte efecto de memoria que las mata en poco tiempo. Ademas, tienen una baja densidad energética, por lo que tampoco es que sean la cosa mas potente del mundo. Tanto asi, que para alcanzar sus 4.8V necesitaron poner 4 pilas bien gordotas que hagan el trabajo de lo que ahora se podría hacer con una sola 18650 y la mitad del peso. Pack de baterias Ni-Cd

El Desarme

Como dije, no es complicado de desarmar. solo hay 4 tornillos. Vista interior motorTornillos PhilipsVista interior TurbinaCircuito de bomba de aire para inflar colchones Por pura intuicion determine que la bateria habia dejado de funcionar, asi que intente hacer una prueba para saber si efectivamente era asi. Conecté un pack de baterias cuya salida era de solo 5v 2A directamente al motor sin resultado alguno. Resulta que el motor, uno sencillo de 8V, puede tirar tanta corriente que dispara los circuitos de proteccion del pack de bateria, interrumpiendo la conexion de inmediato. Al parecer, esto pasaria tambien con los cargadores de pared, por lo que no serviría para intentar probarlo. Usando el mismo pack de baterias, esta vez cablee de forma directa, sin pasar por los circuitos de proteccion, consiguiendo 3.7V y mas de 10000Mah, por lo que esta vez si que funciono el pequeño motor. El problema es que los Amperajes aportan velocidad al motor, pero el voltaje es el que aporta fuerza, por lo que aunque todo provenga del mismo pack de baterías, hay que organizar de diferente forma para obtener mejores resultados. Asi, conectando 2 18650 en serie, obtuve 7.4V con lo que el motor, aunque con menos pilas, si que giraba con fuerza, aunque con menos velocidad. Esto si es útil para inflar un colchón.

Curiosidades

Aunque es un adefesio simple, la verdad me sorprendió encontrar que no era tan primitivo como otras cosas que hemos analizado. El circuito del aparato estaba conformado por un cerebro n79e814A, que no es un simple regulador, sino un microcontrolador de 8 bits de Nuvoton. Esto significa que el inflador tiene lógica programada. Es el encargado de medir el voltaje de las baterías y, si detecta que están por debajo de un umbral (como cuando mueren las de Ni-Cd), bloquea el paso de corriente por seguridad. Por eso no arrancaba simplemente «inyectando» energía al circuito. Como intuia a primera vista por la bobina inductora 470, también tiene un boost converter. Este inductor de 47µH es el corazón del sistema Boost. Junto con un MOSFET (seguramente cercano), se encarga de «patear» el voltaje hacia arriba. El número 470 indica su valor inductivo, esencial para convertir los 4.8V de las pilas en un voltaje estable para el motor. Por ultimo, también destacan los filtros (Capacitores 100 10V VT): Son capacitores electrolíticos de 100µF a 10V. La serie VT suele indicar que son de baja impedancia (Low ESR), diseñados para filtrar el ruido eléctrico del motor y estabilizar los picos de tensión del convertidor Boost. Que sean de 10V nos confirma que el circuito interno nunca debería superar ese voltaje, validando nuestra elección de 7.4V (2S) como el límite seguro.

Conclusiones

Puede parecer raro lo que digo, pero tal vez no valga la pena repararlo. Es cierto que es posible, pero es un aparato que genera mucho calor y las baterías de litio no son especialmente amigas del calor. Tampoco les va bien con la sobredescarga, por lo que un motor asi, puede drenarlas antes de que te des cuenta y terminaras con baterías muertas ademas del propio inflador. Con los riesgos y lo que cuesta repararlo, seguro sale mas barato y cómodo comprar otro. Pero si puedes, elije uno que no sea recargable. Los aparatos recargables que no son de uso frecuente, especialmente los de Niquel y Cadmio, mueren en los cajones y te traicionan cuando mas los necesitas. https://interlan.ec/blog/2026/03/27/desarme-inflador-generico-para-colchones-inflables/ #cosasChinasTruchas #desarme #experimentos #solucionDeProblemas

«Blogpocket Notes» o como estoy construyendo una centro de operaciones en mi navegador web

Presentamos «Blopogket Notes», una PWA (app que funciona en el navegador independientemente de Backend) para que apuntes tus ideas sin distracciones.

https://blogpocket.es/blogpocket-notes-o-como-estoy-construyendo-una-centro-de-operaciones-en-mi-navegador-web/