- This topic has 15 replies, 7 voices, and was last updated 5 years, 10 months ago by
.
-
Posts
-
Hola compis,
como decía en otro tema, no estoy trabajando activamente en el proyecto últimamente, principalmente porque no se muy bien qué camino seguir. Os expongo mis reflexiones, a ver que opinais.
Lo primero que me desanima un poco es que la versión para Raspberry Pi (que era la versión mas molona y barata en mi opinion), es una via muerta. Tal como Google ha ideado los términos de uso de Android Things, la Raspberry Pi se puede usar durante la fase de desarrollo, pero el objetivo final es que cuando el software está listo, el emprendedor debe construir un dispositivo y comercializarlo. Es decir, se envían los esquemas y diagramas a algún fabricante de hardware, se producen, qué se yo, unos cuantos miles de termostatos, y se saca un producto al mercado, y se vende en una cajita en Amazon, o en la tienda del barrio de la esquina.
Entonces si, se puede utilizar el sistema operativo en todo su potencial, se pueden hacer actualizaciones OTA, etc. Esto excede mis intenciones iniciales, y como imaginareis, no puedo seguir este camino.
Así que lo mas probable es que la versión para Raspberry Pi pase al archivo, a coger polvo.
En segundo lugar, para la versión “Old Relic”, no hay tantos problemas, ya que se puede distribuir fácilmente como una aplicación Android cualquiera. Os podéis imaginar la cantidad de horas que se invierten en un proyecto de estas características. Lo cierto es que es una cantidad de horas enorme, que se quitan de otras obligaciones (de la pareja, de los hobbies, o del sueño). Todo ello me hace plantearme la necesidad de monetizar el proyecto, por dos motivos:
– La cantidad de horas invertidas es brutal.
– El proyecto requiere de una infraestructura que hay que pagar mensualmente (la sincronización entre termostato y clientes, no ocurre por arte de magia, ocurre porque hay un servidor en la nube que hace de puente).Este último punto me lleva a otro dilema: si el proyecto tiene pocos usuarios, como ahora, no hay forma de monetizarlo lo suficiente con publicidad para que compense las horas invertidas y el coste del servidor. Pero si el proyecto tiene éxito y empieza a ser usado de manera masiva, entonces es necesaria una infraestructura mayor, es decir, un servidor mas potente, el cual cuesta mas, y la publicidad sigue sin llegar. Es la pescadilla que se muerde la cola.
La una opcion valida ahora mismo para sostener un proyecto de este tipo, es un abono de alguna clase en la app (mensual, semestral, o algo asi). Pero obviamente, si un usuario tiene que pagar, digamos, 5€ cada invierno por usar esta app, pues igual se lía la manta a la cabeza y se compra un termostato Nest, y tiene un producto mucho mejor que este.
Y un último pensamiento que me asalta a veces. Supongamos que sigo desarrollando el proyecto, supongamos que es tan chulo que tiene una base de x miles de usuarios dispuestos a pagar unos pocos euros de vez en cuando para usarlo, y de esta manera el proyecto se mantiene, y me motiva para seguir dedicándole tiempo.
Aun en este caso, me asalta el pensamiento de, ¿que pasaría si un usuario hace algo mal, y le planta fuego a su casa por culpa de andar trasteando con la caldera y el proyecto? ¿Hasta donde llega mi responsabilidad como desarrollador? ¿Se puede limitar, no se puede limitar?
En fin, son cosas que me tienen paralizado desde hace varios meses. Algunos de vosotros me habeis pedido nuevas funcionalidades, que podria haber hecho ya, pero, como decia, estoy bloqueado.
Agradezco vuestras opiniones.
Un saludo
Roque.
Muy buenas,
Creo que el proyecto es muy bueno y debe seguir, eso partiendo de la base. Ahora, a ver si entre todos damos con la tecla.
Por un lado, el proyecto de la Raspberry estaba muy chulo, yo tengo una y me gustaba mucho la idea. Pero si se complica por tema de Google no creo que deba seguir.
El de la Raspberry se puede quedar parado (de momento), pero quien no tiene teléfonos viejos por casa o tablets. Es una gran idea darle una segunda vida y encima con un proyecto tan interesante como lo es este.
El tema económico es otro hándicap. Pienso, como tu dices, que si hay que pagar cada invierno por usar la app los usuarios se pensarán hacer el desembolso de una vez en un termóstato comercial.
Quizá, no sé qué te parecerá, es dar 15 días de prueba para usar la aplicación para ver que todo funciona correctamente y pasados los 15 días realizar un pago por ejemplo de 15 o 20 euros que sirva para siempre. No sé si para ti será suficiente, pero piensa que los usuarios que usen este proyecto se habrán tenido que gastar dinero también en comprar los módulos wifi y los relés, que aun que no son elevados de precio, se suman al total.Si elevas el precio mucho, lo mismo los usuarios se plantean comprar un termóstato comercial en ver de realizar el proyecto y si le pones un precio “atractivo” seguro que luego funciona la boca y se multiplicaran los usuarios.
Otra idea es que, por ejemplo, puedas vender el kit de los módulos tú mismo. Imagino que vives en España. Por lo que, si tú ya tienes el material y lo envías tú, el envió es mucho más rápido que si lo pides a china. Yo, por ejemplo, no me importaría pagar un poco más por los materiales si los voy a tener antes o incluso si los vendes ya con una caja hecha en una impresora 3D como vimos que hacia el usuario inglés.
Espero que te sirva de ayuda mi opinión, me gustaría mucho que no dejaras el proyecto.
Un saludo y animo!!
Hola Miguel,
El modelo que propones ya lo consideré en el pasado. Lamentablemente tiene una pega. Si la app fuera algo que se desarrolla una vez, y después se vende muchas veces sin necesidad de volver a dedicarle horas de trabajo, sería el modelo ideal. Este es el caso de un libro: un escritor escribe una novela. Invierte para ello muchas horas, una editorial lo publica, se vende por X euros, y el escritor no tiene que retocar la obra cada pocas semanas. Tampoco tiene que pagar un servidor que el libro utiliza de alguna forma, y sin el cual el libro no funciona.
Esto funciona bien para algún tipo de apps, pero si os habéis dado cuenta, casi todo el software hoy en día ha pasado del modelo de “compro la licencia para la versión de Photoshop 9”, a “pago x euros al mes para usar Photoshop, y obtengo las nuevas versiones siempre”.
Como os decía, aunque la app llegase a una versión estable en el futuro, que no requiriese mas programación, esta el coste del servidor en la nube, que mueve los datos entre el termostato y los clientes. Ese servidor está operativo 24×7, tiene unas características determinadas para que siempre esté operativo, y en fin, hay que pagarlo todos los meses. Cuantos mas usuarios tenga la app, mas caro sera el servidor.
Lo del precio de las apps es algo paradójico. Fijate que estoy barajando precios de 6€ por invierno, es decir, eso serían unos seis euros por el periodo de Octubre a Mayo, por ejemplo. estamos hablando de menos de un euro por mes. Hasta un cortado cuesta mas hoy en dia. De hecho cuando estoy tirado en mi sofá, y se me cae un euro entre los cojines, ni me planteo en buscarlo y ahí se queda. Seguro que más de uno de vosotros me invitaría gustoso no solo a un cortado, sino a una cerveza y unos pinchos, con lo cual el precio de la app se habría pagado con creces.
Y sin embargo el usuario medio de internet (entre los cuales me incluyo), cuando ve que el precio de una app es 0.99€, no la compra aunque sea util. Y si ve que el coste es 0.99€ al mes, pues mucho peor.
Son las paradojas de la vida.
Por otro lado, lamentablemente no vivo en España, y tampoco me embarcaría en la aventura de tener stock de componentes y venderlos yo. Es bastante lioso, y me hace incurrir en mas responsabilidades…
Gracias por tu opinión!
Roque.
Pues visto de esta manera, veo bastante negro el futuro de este proyecto, si no existe la opción de sincronización con servidores gratuitos… O sincronización local, y desde fuera de casa abriendo un puerto y con un dyndns…
Es una pena, porque el proyecto me encanta, llevaba mucho tiempo con una idea así en la cabeza pero sin los conocimientos necesarios para llevarla a cabo. Y según se acerca el invierno investigo a ver qué opciones encuentro que se acerquen más a mi idea. Ahora mismo estaba entre este proyecto y algún termostato wifi de AliExpress, que los hay desde 30€ con su app. Las opciones como nest o netamo me parecen demasiado caras.Si existiese la opción de sincronización local o algo que me garantice que la aplicación me va a funcionar para siempre, gustosamente colaboraba económicamente. Pero la idea de una cuota (que tiene todo el sentido del mundo teniendo en cuenta el alquiler de servidores) no me atrae nada.
Hola,
para prescindir de un servidor “en la nube” que haga de pasarela entre los datos del termostato, y las apps cliente, habría que transformar el propio termostato (osea, la aplicación Old Relic), en una especie de servidor, al que las aplicaciones cliente puedan conectarse y consultar que es lo que hay de nuevo.
Este es el enfoque que utilicé en mi otro proyecto (Smart Thermostat for Arduino Yun), que empecé desarrollando allá por el 2012. El problema de este enfoque fueron varios.
El primero y principal es que si abres un puerto en tu router, y tienes un mini servidor web abierto al mundo, vas a recibir intentos de intrusión al cabo de poco tiempo. Los primeros años esto no fue demasiado grave, pero durante el 2016-2017, muchos usuarios se quejaron de que el Arduino Yun dejaba de responder al cabo de un par de horas de funcionamiento. Tras muchas investigaciones, descubrí que lo que estaba pasando es que una vez que los bots que andan por ahí intentando entrar en servidores, descubren la IP del yun en internet, se dedicaban a hacer ataques de fuerza bruta. Es decir, probar combinaciones de password y contraseña para conseguir conectarse al servidor por el puerto ssh (aunque no esté abierto, el intento es lo que cuenta).
Esto que para cualquier servidor “de verdad” es irrelevante pues cuentan con cortafuegos, o simplemente son capaces de soportar miles de intentos de login por segundo sin despeinarse, para un microcontrolador como un Yun (o una Raspberry Pi, ya puestos), es muy diferente. Al cabo de un rato de recibir intentos de intrusión, el pobre yun se bloqueaba por saturamiento. Y los usuarios estaban descontentos, obviamente, achacandolo a mil problemas diferentes.
Desgraciadamente el yun no me permitía, por su poca memoria, instalar un firewall, o contramedidas efectivas, así que nuestro gozo en un pozo. Este fue uno de los motivos por los que abandoné ese proyecto, aparte de lo difícil que era programar la parte de servidor en el yun.
Aplicando esa idea a nuestro proyecto actual, habría que transformar el móvil que hace de termostato (la app old relic), en una especie de servidor web. Lo primero es que después de investigar un poco en google, no he descubierto nada lo suficientemente bueno que permita transformar una app de Android, en un servidor web (alguna libreria o algo). Lo segundo es que volveríamos al problema anterior: si conviertes un móvil en un servidor web, también tienes que fortificarlo y asegurarlo. Y eso es precisamente lo que quería evitar cuando abandoné el proyecto para arduino yun.
Teniendo un servidor en la nube, es todo mucho mas sencillo. Son mas fáciles de fortificar y asegurar, y en el caso de que se utilice la infraestructura de amazon, microsoft o google, yo diría que se puede dormir casi tranquilo. Por no hablar de las ventajas que aporta. Por ejemplo, un servidor en la nube, puede comprobar que tu termostato está accesible y funcionando, y si no es así, avisar a la app cliente. Si el propio termostato es el servidor, y este tiene un problema, la app cliente tendría muchas menos opciones para enterarse de ello. En fin, esta es solo una de las decenas de razones técnicas que me llevaron a cambiar el tipo de arquitectura del proyecto.
Obviamente esto incurre en costes, y estamos de vuelta al principio.
No se, seguiré dándole vueltas. Probablemente mantenga el proyecto un poco mas, y ponga algo de publicidad en las apps clientes, para ver que tal funciona. Pero para producir unos ingresos, digamos de 30€ al mes, el proyecto tendría que tener un par de miles de usuarios diarios. Y que yo sepa, el termostato de momento lo usan 2 personas, 😀 😀
En fin, como idea no estaba mal, pero la realidad es que consume tanto tiempo, que no me merece la pena hacerlo por amor al arte.
Un saludo
Yo creo que hay que simplificarlo. Hay que dejarlo solo en una app android y el esp32. Hay que sacarle mucho más partido al esp32.
Hay que ver cómo comunicar el esp32 y android. El esp32 debería ser autónomo, y solo enviar y recibir información con la app.
Por ejemplo, yo tengo programado un esp32 que se vincula con iO.adafruit.com. Desde la web puedo comunicarme con el esp32 y recibir y enviar datos, sin servidor ni nada en casa. Ahora con IFTTT, hasta puedo con el asistente de Google Home, encender y apagar luces o subir y bajar persianas. También puedo actualizar el esp32 por wifi desde el portátil (OTA). Si he podido hacer esto yo, que soy un paquete, podrás hacerlo con una app. El esp32 debe loguearse con la app y comunicarse.
Tener un móvil siempre encendido y cargando no es solución, al final se joderá la batería y puede ser peligroso.
Una vez que esta base funcione autónomo (esp32 y app), puedes incluirle funciones de nube para datos, gráficos, estadísticas o lo que quieras, que sería a parte, y el usuario, si quiere podría comprarla anualmente, o no. También como extra hay que vincularlo con Google Home, Alexa…, graficas estadísticas, avisos, pero todo basado en algo que funcione autónomo.
Si consigues que funcione, tienes algo que tendría mucho tirón.
Si puedo ayudar el algo, solo tienes que pedirlo.
Un saludo
Hola NeoRuben, cuanto tiempo.
A ver, he mirado por encima Lo que comentas de ioAdaFruit.com y en el fondo es lo mismo que hago yo. ioAdafruit.com es una empresa que pone a tu disposición su/s servidor/es, y unas librerias especiales para arduino. Esas librerias envian informacion a los servidores de adafruit, y al acceder a su web supongo que tendras un panel de control donde manejas esa información.
No te hagas la falsa idea de que estas accediendo directamente a tu arduino. Lo que haces en el panel de control es hablar con el servidor de adafruit, y el esp habla con el mismo servidor, y asi ocurre la magia.
Esto es lo que he sacado de una primera lectura de la web de ioAdaFruit.com, igual lo he entendido mal. Si con la app de IFFT te comunicas con el ESP32, es porque hay un puente en el medio, que seria el servidor de Adafruit. No existe la magia en todo esto. La tendencia del mercado aqui es la misma, en todos los sistemas. No conozco dispositivos de IOT que se comuniquen directamente con una app, salvo algunos termostatos o bombillas bluetooth. Los cuales por cierto no puedes controlar cuando estas fuera de casa, porque el bluetooth tiene un alcance limitado.
En cuanto tenemos entre manos un dispositivo que puedes controlar desde fuera de casa, la unica forma digna es a través de un servidor que haga de puente. Ninguna empresa que se precie te va a pedir que abras puertos en tu router. Lo primero porque el usuario común no sabe hacerlo. Lo segundo porque es mucho mas eficiente y fácil de mantener un producto teniendo un servidor de la empresa haciendo de puente.
En resumen, ¿se podría modificar todo el proyecto para que funcionase con bluetooth y los esp32 hablasen con la app termostato y la app cliente directamente? Si. ¿Seria laborioso? Muchísimo. ¿Podrías manejar el termostato estando fuera del alcance del bluetooth? No. Creo que parte de la gracia del proyecto es poder controlar tu calefacción cuando no estas en casa.
Saludos.
Hola admin, yo sigo el proyecto desde el año pasado y de hecho lo tengo instalado y funcionando, hago un recordatorío, tengo el ESP montado en una marco de fotos y un movil que me hace de pantalla en el pasillo de casa, luego con mi movil me conecto desde donde sea y lo gestiono.
Respecto a lo que propones, yo visto lo que me aporta, no tendría ningún problema en haceer un pago anual de 5€, pero claro yo que soy un friqui y me mola el handmade, pero entiendo que no todo el mundo estará dispuesto a pagar esas cantidades o incluso menos.
Yo propongo algo por si es factible y desahogar gastos, la app de casa dejarla tal cual, si se tiene como en mi caso conectado un movil permanente para eso, no crees que se podría eliminar el client?. si en el movil le instalas por ajemplo el team viewer, y desde tu movil o pc te conectas al movil de casa y activas el esp.
Es una idea, de esta forma creo que se puede eliminar el coste de servidor y podrías cobrar un precio x una vez por la app y ya está. Por que no sé lo que realmente utiliza la gente del termostato, pero yo lo que necesito es lo básico, poder encender y poder poner una temperatura para que se pare, y si me apuras lo de automatizar las horas, pero ccreo que eso va en el esp, si eso es así sería lo justo de un termostato digital que puedes acceder a distancia.No sé si con el chorreo que he escrito se entiwnde la idea.
Otra cosa puede ser que facilitarás algún tipo de herramienta o directrices para que cada uno se monte su servidor aunque sea en local, tu vendes la app local y el remoto ya cada uno que se lo pueda montar.
Saludos y gracias por tu proyecto.Hola Pedrin,
hombre si sería posible eliminar el cliente usando teamviewer o algo parecido para acceder al termostato en casa. Pero tambien sería… poco elegante… Creo que no me lo permite mi amor propio. Creo que hay que reconocer que la facilidad con la cual se maneja el termostato desde la app cliente, es un punto a favor del proyecto. Si empezamos con chapucillas, perdería algo…
Bueno perdonad que tarde en contestar, pero entro a ver estos mensajes muy de vez en cuando. Os cuento que despues de darle muchas vueltas, ya he decidido que hacer con el proyecto a medio plazo.
Lo primero, he decidido soltar algo de lastre. La app para Raspberry Pi, la he puesto en el congelador de apps, porque aunque funcionaba, el producir termostatos a nivel industrial (que es lo que exige la licencia de uso de Android Things) es algo que esta fuera de mi alcance, asi que me olvido del asunto.
Lo segundo, voy a fusionar la app cliente y la app del termostato en una sola app. Esto me facilita el desarrollo y mantenimiento un poco. Tendre que dedicarle menos horas, para conseguir el mismo resultado. La app se configura cuando la instalas en el aparato y adopta un rol (de termostato o de cliente segun quiera el usuario), y asunto arreglado.
Respecto a la parte de servidor, desde mi punto de vista sigue siendo necesaria. Pero he prescindido del servidor que usaba hasta ahora (usaba Firebase de Google, en concreto su base de datos en tiempo real llamada Realtime Database). Esta base de datos funcionaba muy bien, pero, tenia el problema de que los costes crecian a partir de cierto numero de usuarios de forma bastante brusca.
Lo que he hecho es rediseñar toda la parte que corre en el servidor, para que funcione en un servidor propio que tambien uso para otros proyectos. Creo que podra aguantar varias decenas de miles de usuarios sin despeinarse y tambien creo que nunca llegaremos a ese nivel de exito de la app, asi que deberia esta la cosa sobrada por ese lado.
Respecto a la monetización, no tengo muchas esperanzas de que compense el tiempo y esfuerzo invertido en este proyecto. Para desgracia del usuario, incluiré publicidad en la app (tanto en la del termostato como en la app cliente). De esta forma el usuario podra utilizar todas las funciones, pero tendra que aguantar la publicidad. Como la publicidad es un rollo, para los verdaderamente entusiastas pondre una compra inapp para eliminar la publicidad, digamos por una temprada (un semestre o asi), a un precio de amigo (¿el precio de un café?).
Asi que el que quiera ayudar al proyecto con una aportacion por temporada, podra hacerlo. Y el que sea algo menos desprendido, podrá usar la app, pero tendra que soportar algun anuncio que otro estropeando la experiencia de usuario.
A largo plazo, quizas los que compren la version premium “semestral” tengan alguna funcionalidad mas, como por ejemplo, el acceso a una web, para controlar el termostato y ver graficas, etc. Pero eso es hipotetico y a largo plazo.
Ahora mismo estoy rediseñando la parte de servidor, y adaptando las apps. Esto me llevará posiblemente hasta el invierno que viene, asi que no conteis con una nueva version antes de otoño del 2019.
En ese momento, desaparecerá la app Old Relic de la play store, y la app “Cliente” se convertirá en la app thermostato + cliente. De esta forma, los que esten usando en ese momento el termostato, no veran afectado el funcionamiento, y este seguirá funcionando sin pegas. Obviamente, no podran encontrar la app Old Relic en la play store, y cuando la busquen, se encontrarán la cliente+termostato (que se llamara simplemente smart thermostat), y podran instalar la nueva version (probablemente con nuevos sketchs, etc).
No me olvido de algunas funcionalidades que me habeis pedido (por ejemplo, una interfaz opcional mas adecuada para personas mayores o con problemas en las manos, o la funcion de durante X tiempo subir a una Y temperatura y despues volver al programa anterior). Pero como ya os digo, esto tardará.
Como siempre agradezco vuestros comentarios, fotos, ideas, y experiencias. Por ejemplo, ¿que tal os va con el DHT? El sensor de temperatura cumple el cometido, o es demasiado impreciso?
En fin, no os preocupeis si desaparezco por temporadas. La app esta en el horno, lo que pasa es que es una receta de coccion super lenta 🙂
Muchas gracias, seguire de cerca el proyecto tal cual lo estoy haciendo desde el principio.
Yo comento mi experiencia con el DHT, mi router se reinicia cada tres o cuatro dias por la noche, entonces me tira el DHT fuera y la app no lo encuentra, lo que me obliga a tener que hacer una busqueda desde la app termostato, si no me doy cuenta y quiero encender la calefacción desde la appp clien sin estar en casa, no puedo por que no me deja buscar el sensor, seria mucho pedir que se pudiera hacer la busqueda del sensor desde la app cliente?, o que si se pierde la conexion con el router se reconectara solo el DHT?Saludos y gracias de nuevo por el proyecto.
Buenas Roque. Encantado de que continúes con el proyecto. Desde luego que yo seré uno de los premium.
Gracias.
Hola,
Que raro lo que me cuentas. Los nodos deberían conectar de nuevo. ¿Te ha fijado si cuando vuelves a buscar el nodo, la IP ha cambiado?
En ese caso es más una configuración del router que otra cosa. Igual puedes en tu router asignar una IP fija al nodo en base a la Mac
Si la IP no ha cambiado entonces puede que haya un problema en el código del Arduino
Me lo apunto y lo miro… Para la versión 2019…
Hola, me llamo Alfonso, acabo de llegar al proyecto tras ser un damnificado por la quiebra de momit y me ha parecido muy interesante. Un gran trabajo.
Aunque soy novato en estos temas, ya he pedido los componentes para probarlos. He visto que se ha actualizado la documentación con un nuevo tutorial.Saludos
- You must be logged in to reply to this topic.