Mycroft-core: Solicitud de función: integrar IFTTT en el núcleo

Creado en 15 mar. 2018  ·  9Comentarios  ·  Fuente: MycroftAI/mycroft-core

278 fue etiquetado incorrectamente como una "habilidad". Para que IFTTT funcione, será necesario modificar el código dentro del núcleo para implementar el protocolo IFTTT y hacer uso de la API como mínimo (puede haber algunas piezas más pequeñas que también deban agregarse) y no solo crear algunas "habilidad". La integración de IFTTT en el núcleo podría hacer que la creación de habilidades sea mucho más rápida y fácil, ya que ya se ha realizado mucho trabajo en el mundo de IFTTT para que los complementos vinculen dispositivos / funciones / servicios que de otro modo serían incompatibles. Un punto de partida que veo al buscar en las páginas de Github de IFTTT sería su ifttt-api-example . Personalmente, no sé lo suficiente para integrarlo, pero me complace ayudar de otras maneras (depuración, prueba de penetración, etc.)

hard For Voting Enhancement - proposed

Comentario más útil

@DarthSpock @tsdorsey Gracias por su sugerencia en este caso.

Internamente, hemos discutido la implementación del soporte IFTTT durante algún tiempo. Es algo que queremos hacer a más largo plazo (18-24 meses más o menos), pero no tiene sentido que lo hagamos ahora por varias razones:

  • Hay un alto costo mensual para proporcionar un canal IFTTT en la plataforma. El tamaño de nuestra base de usuarios no hace que esta sea una inversión sensata en este momento, pero nuestra base de usuarios está creciendo a alrededor de 1200 usuarios por mes, por lo que con el tiempo este gasto tiene más sentido.

  • Como @DarthSpock señala correctamente, hay una gran cantidad de mycroft-core que tendrían que escribirse para implementar el protocolo IFTTT, y mucho de ese trabajo, como usted afirma correctamente, estaría en el lado de API de cosas.

  • Una de las piezas _ más importantes_ que también deberíamos considerar es la no técnica. Nuestro punto de diferenciación en un mercado de IoT muy concurrido y fragmentado es la prima de privacidad que ofrecemos. No fisgoneamos en lo que está diciendo para poder venderle anuncios o productos. Los controles de privacidad dentro de la plataforma IFTTT también deberían ser igualmente rigurosos para que podamos proteger la privacidad de un extremo a otro. No estoy diciendo que no lo son, pero es algo que tendríamos que asegurar.

  • También estamos considerando un ecosistema basado en blockchain . Este es otro punto de diferenciación de IFTTT. Sí, al estar totalmente abierto aquí, puse los ojos en blanco la primera vez que comenzamos a charlar sobre eso internamente, pero cuanto más lo pensamos, más sentido tiene, usando un modelo de prueba de participación o prueba de trabajo.

Todos 9 comentarios

@KathyReid ¿Podríamos obtener comentarios del equipo de Mycroft sobre esto? ¿Estarías abierto a esto o pertenece a una habilidad por ahora?

@DarthSpock @tsdorsey Gracias por su sugerencia en este caso.

Internamente, hemos discutido la implementación del soporte IFTTT durante algún tiempo. Es algo que queremos hacer a más largo plazo (18-24 meses más o menos), pero no tiene sentido que lo hagamos ahora por varias razones:

  • Hay un alto costo mensual para proporcionar un canal IFTTT en la plataforma. El tamaño de nuestra base de usuarios no hace que esta sea una inversión sensata en este momento, pero nuestra base de usuarios está creciendo a alrededor de 1200 usuarios por mes, por lo que con el tiempo este gasto tiene más sentido.

  • Como @DarthSpock señala correctamente, hay una gran cantidad de mycroft-core que tendrían que escribirse para implementar el protocolo IFTTT, y mucho de ese trabajo, como usted afirma correctamente, estaría en el lado de API de cosas.

  • Una de las piezas _ más importantes_ que también deberíamos considerar es la no técnica. Nuestro punto de diferenciación en un mercado de IoT muy concurrido y fragmentado es la prima de privacidad que ofrecemos. No fisgoneamos en lo que está diciendo para poder venderle anuncios o productos. Los controles de privacidad dentro de la plataforma IFTTT también deberían ser igualmente rigurosos para que podamos proteger la privacidad de un extremo a otro. No estoy diciendo que no lo son, pero es algo que tendríamos que asegurar.

  • También estamos considerando un ecosistema basado en blockchain . Este es otro punto de diferenciación de IFTTT. Sí, al estar totalmente abierto aquí, puse los ojos en blanco la primera vez que comenzamos a charlar sobre eso internamente, pero cuanto más lo pensamos, más sentido tiene, usando un modelo de prueba de participación o prueba de trabajo.

Votaría a favor del uso de un ecosistema basado en blockchain, pero no estoy seguro de que eso invalide el soporte de IFTTT. Honestamente, solo quiero poder usar Mycroft con Alexa, Google, Siri y cualquier otra IA que haya. Dado que esta es la única IA de código abierto, usarla para obtener el control de los propietarios liberaría a los usuarios de comprar los dispositivos que deseen y aún así poder controlarlos de forma centralizada a través de IFTTT. Y eso tiene sentido financieramente sobre la plataforma IFTTT. Definitivamente dispuesto a esperarlo y esperar que sea parte del próximo dispositivo.

Además, si está considerando considerar blockchain, ¿qué tan profundamente arraigado está el aprendizaje profundo en el núcleo de Mycroft? Teniendo en cuenta cómo funciona la IA actual ahora, este es un campo que necesitará mejoras durante algún tiempo para todas las implementaciones de IA actuales y futuras (de código abierto o de otro tipo). Ya tenemos un robot ciudadano de Arabia Saudita .

Entonces, dos puntos aquí;

  • Para el punto del ecosistema basado en blockchain: tendríamos que averiguar cómo el ecosistema interactuaría con IFTTT, por ejemplo, ¿necesitaría un Mycroft Token para usar Mycroft con Alexa, Google o Siri? ¿O esos servicios consumirían Mycroft Token si recibieran una solicitud de Mycroft? Todavía queda mucho por trabajar allí.

  • Para el punto de aprendizaje profundo: el aprendizaje profundo y el aprendizaje automático no son parte de mycroft-core , sin embargo, son parte de varios otros paquetes de software en Mycroft ecosysem. El motor Precise Wake Word utiliza una red neuronal para distinguir entre lo que es Wake Word y lo que no lo es, mientras que la capa Mimic 2 Text to Speech usa una red neuronal para entrenar modelos de voz.

He estado siguiendo el tema de los ciudadanos de Sophia durante un tiempo, y lo que me sorprende es que en un país como KSA, una IA recibe la ciudadanía, pero su población femenina acaba de obtener el derecho a conducir. _También_ debemos considerar profundamente los problemas de diversidad e inclusión junto con el aprendizaje automático.

No tengo experiencia con IFTTT, ¿podría darme algunas ideas sobre cómo se usaría esto dentro de mycroft-core?

¿Te refieres al soporte para acceder a ciertos webhooks en IFTTT desde habilidades o hay algo más que podamos hacer como permitir que IFTTT active Mycroft?

Tampoco he desarrollado nunca con IFTTT, pero estoy pensando un poco en ambos. No necesariamente esperaría que una habilidad desarrollada específicamente para Mycroft funcione en un Echo Dot, aunque eso sería genial, pero esperaría llamar al Echo Dot y todas sus habilidades de Mycroft a través de IFTTT. En realidad, la mejor comparación que se me ocurre es la nueva edición de Echo Dot Kids en reserva . Deberías echarle un vistazo, cosas muy interesantes para niños. Hay un video que mostrará algo de lo que Mycroft debería poder hacer a través de IFTTT.

@DarthSpock Creo que Mycroft podría ser un consumidor desencadenante de IFTTT sin cambios tan profundos, y probablemente dentro de los límites de una habilidad "tradicional". Entonces, solo para mayor claridad, ¿está proponiendo que una instancia de Mycroft se convierta en un punto final IFTTT completo con acciones y desencadenadores? Si este es el caso, todavía no estoy convencido de que integrarlo en el núcleo sea la única forma (ni la mejor). Propondría un "puente" de ejecución local que pudiera escuchar eventos IFTTT y luego inyectar en el bus de mensajes de Mycroft. Es como poner estas dos ideas juntas:
https://platform.ifttt.com/docs#1 -set-up-your-environment
https://community.mycroft.ai/t/can-i-have-mycroft-auto-run-a-skill/1844/5

Creo que depende de cuál sea cada caso de uso. Algunas personas pueden querer un punto final IFTTT completo, mientras que otras solo quieren algo de compatibilidad. Sería útil que otros aportasen alguna información sobre para qué usarían IFTTT.

Personal y profesionalmente, me encantaría poder tener la capacidad
para comunicarme de un lado a otro entre mis dispositivos compatibles con IFTTT y mi Picroft;
especialmente porque el bebé de ellos solo puede abrirse a IFTTT. Tengo
Varias bombillas "wifi" delicadas que son de 1.ª / 2.ª generación y no se manejan
actualizaciones bien - demasiado costo prohibitivo para reemplazarlos todos porque son
en toda la casa e individualmente las bombillas son caras debido a la
conjunto de funciones disponibles. En general, IFTTT parece ser más compatible en
en general con el slieu de dispositivos "habilitados para wifi" Familiarizado con: ambos
viejo / nuevo y grande / pequeño.

Sin mencionar que el protocolo en sí es más conocido en comparación con
las alternativas entre las masas laicas pero amigables con la tecnología que buscan construir
su propio hogar INTELIGENTE poco a poco, lo que significa que los dispositivos del futuro
a menudo se configura para aprovechar eso cuando los desarrolladores se ven obligados a elegir 1
estándar / protocolo para gastar tiempo + dinero + otros recursos en desarrollo.

Me encantaría poder conversar de un lado a otro o configurar una encuesta o
completa en la relación cliente-host entre mis dispositivos de modo que el
Picroft / Mycroft podría ser el eje central: permitiría más rápido
Implementación SMART-home en todos los dispositivos en lugar de causar una
enorme fragmentación y un respaldo complejo por el que tengo que crear múltiples
HUB que se comunican con [My | Py] croft y mis otros dispositivos IFTTT y
dispositivos no IFTTT.

Sin embargo, si me veo obligado a elegir entre recibir mi pastel mañana (Cliente + Anfitrión
[es decir, implementación completa] en un año o 2) o consumirlo hoy (cliente
implementación solo para darnos algo con lo que trabajar hasta que el equipo haya
tiempo / recursos para el trato completo o alguna otra implementación), estaría
contento con comerlo hoy. Tener algo con lo que trabajar antes versus
esperando una fecha posterior que tal vez ni siquiera sea lo que esperamos / necesitamos hoy
significa que no tenemos que quedarnos de brazos cruzados sobre nuestros pulgares. Abriría la puerta
para soluciones aún más aparentemente imposibles / complejas que podrían hacer que esto
producto deseable en aún más hogares en todo el mundo.

Gracias,
SeriousSoft


Sitios web, aplicaciones y consultas:
Desarrollador ASP.NET, C #, VB.NET, PHP, Ruby y C ++
http://Seriussoft.com
nathan. [email protected]

¿Fue útil esta página
0 / 5 - 0 calificaciones

Temas relacionados

fermulator picture fermulator  ·  6Comentarios

krisgesling picture krisgesling  ·  5Comentarios

ryanleesipes picture ryanleesipes  ·  4Comentarios

el-tocino picture el-tocino  ·  4Comentarios

fxdgear picture fxdgear  ·  6Comentarios