Recientemente compré un par de relés wifi de Xiaomi. Si bien han sido sólidos hasta ahora, realmente no me gusta la aplicación de Xiaomi. Pero, me gusta la idea de que realmente funciona tanto en LAN como a través de Internet. Cuando están en LAN, se encienden y apagan rápidamente, considerando que los servidores de Xiaomi están en China.
Así que quiero rodar mi propio relé basado en ESP8266 (sé que puedo preparar el hardware, así que es una ventaja). Mi problema es, ¿cómo puedo detectar automáticamente los relés en mi red desde una página web?
Desde una "aplicación" podría usar SSDP, mDNS-SD o UPNP para detectar cosas. Pero no he encontrado información sobre si esto es posible desde el navegador web (Chrome en Android básicamente). Desde que cambié la página web de mi estación meteorológica para que sea una aplicación web progresiva, me he enganchado. Realmente me gusta la idea de que las cosas solo sean páginas web y no aplicaciones que tienes que instalar. Y los PWA también llenan el vacío con el modo fuera de línea.
Sin embargo, es extraño que la parte "difícil" (encender y apagar los relés desde fuera de la LAN) sea trivial de resolver a través de un servidor MQTT. Pero preferiría no confiar en el servidor MQTT externo. Si estoy en la LAN, quiero hablar directamente con los relés. De lo contrario, envíe el comando a través de MQTT.
Podría, por supuesto, confiar en el servidor para consultar los relés, pero en ese caso necesitaría una conexión a Internet (si mi servidor MQTT está en la "nube"), o un servidor alojado en casa. Tengo un servidor en casa, e incluso si no lo tuviera, un raspberry pi podría llenar fácilmente el vacío. Pero lo ideal sería ni siquiera necesitar un servidor cuando se habla con los dispositivos a través de LAN (Wifi en este caso). Prefiero mantenerlo P2P tanto como sea posible, y solo uso MQTT como alternativa para cuando estoy en WAN (MQTT resuelve los problemas de CG-NAT y el reenvío de puertos).
fuente
Respuestas:
No conozco ninguna capacidad de descubrimiento local genérica integrada en un navegador. De hecho, consideraría que cualquier capacidad es una veneración de seguridad, ya que permitiría a los atacantes perfilar su red de forma remota a menos que tuviera un paso de interacción manual para iniciarla, lo que realmente ralentizaría el flujo de trabajo que creo que está apuntando.
Puedo pensar en 2 cosas que se acercan:
La capacidad de descubrimiento de Chromecast se convirtió en Chrome. Esto solía ser un complemento por separado antes de que se implementara. Pero esto aún requiere un paso manual hacia donde el usuario desencadena una búsqueda y luego una selección manual de los detalles del dispositivo que se devolverán a la página / javascript. (esto usa SSDP bajo las cubiertas iirc)
El soporte de escaneo WebBluetooth. Esto sigue un modelo similar al descubrimiento de Chromecast. El usuario debe iniciar el escaneo, luego debe elegir manualmente de los dispositivos encontrados por el navegador cuyos detalles se devuelven al javascript en la página.
He utilizado el enfoque WebBluetooth para descubrir un interruptor de luz local (tengo una aplicación BLE en un pi cero que controla una bombilla Belkin WeMo https://github.com/hardillb/physical-web-lightswitch ). Funciona, pero no es transparente, ya que requiere al menos 2 interacciones del usuario para descubrir un solo dispositivo.
Si bien no cumple con todos sus requisitos locales, creo que usar el enfoque de agente en la nube, incluso cuando se opera localmente, será una experiencia de usuario más fluida.
fuente
Si tiene una interfaz web en un dispositivo y la configura para que tenga un nombre de host MDNS a través de un servicio de respuesta MDNS como bonjour o avahi, entonces, desde sistemas operativos con funciones, simplemente puede apuntar su navegador a
https: //livingroomlight.local
O como lo haya configurado para llamarse a sí mismo.
Esto funcionará de forma inmediata con navegadores que se ejecutan en OSX, iOS y la mayoría de los Linuces, todos los cuales admiten la resolución de nombres de host MDNS a nivel de sistema.
Sin embargo, esto no funcionará desde Windows a menos que instale el complemento MDNS, y no funcionará con los navegadores Android estándar, aunque es posible crear aplicaciones de navegador personalizadas para Android que lo admitan.
El descubrimiento de instancias desconocidas en la red generalmente no es compatible con un navegador, pero generalmente es compatible a través de API del sistema operativo y herramientas de línea de comandos como
dns-sd(OSX) yavahi-browse(Linux).Entonces, aunque no parece obvio que un navegador pueda encontrar sus dispositivos, si simplemente puede recordar cómo llamó a uno de ellos, puede conectarse a él y potencialmente podría mostrarle enlaces a todos sus pares, haciendo un MDNS buscar en sí mismo.
O puede encender una terminal y obtener una respuesta. Para el caso, podría ejecutar un demonio local que haría una búsqueda MDNS y le mostraría el resultado como una página de enlaces que se sirve solo en la interfaz de bucle invertido y, por lo tanto, no es accesible a ninguna otra máquina.
fuente