[Module] Pistes de recherches pour WebOS et ampoules Magic Home

renaiku · November 14, 2019, 9:28am

Bonjour !

Je pose ici mes recherches pour développer des modules pour ma tv LG webOS et pour une de mes ampoules qui fonctionne avec l’appli Magic Home sur Android.

Si jamais quelqu’un commence à développer ces modules, pas de soucis. Sinon je compte le faire dès que j’ai un peu de temps libre.

LG webOS
Je sais que TanguyNa a développé un service webOS pour la v3, mais j’ai trouvé lgtv2mqtt et je sais que ça pourrait intéresser certaines personnes ici.

Magic Home
J’ai trouvé pas mal de sources (en python) pour contrôler toutes les ampoules wifi « low cost ». Elles partagent très souvent le même module wifi quelle que soit la marque.

Ces ampoules sont potentiellement dangereuses si on leur donne accès au réseau internet (désactivé par defaut) => The many attacks on Zengge WiFi lightbulbs – Viktor Stanchev's Blog

It turned out that my new lightbulb was a router, an HTTP server, an HTTP proxy, and a lot more.

Et en plus on peut les flasher directement en wifi si j’ai bien compris … y’a moyen de hoster un site web dans une ampoule ? hahahah
Bref, les sources en python qu’il « suffirait » de transcrire en js pour contrôler tous les modèles ici et ici

Totof · November 15, 2019, 6:20am

D’où l’importance d’avoir un petit pare-feu local qui controle tous nos petits objets connectés.

Il n’y a pas que les lowcoast qui sont dangereuses les milights et les Phillips cherchent a aller sur internet en permanence ^^

S’ils n’y a pas de contrôle et que les objets chez nous ont internet, il devient très facile pour eux de regarder ce qu’il y a chez nous et remonté des données ailleurs.
Si je ne me trompe pas, les Phillips font un post régulier sur un serveur philips, dans le doute → Drop

Lorsque Gladys v4 sera en stable je ferais un tuto avec l’installation d’un pare-feu pour ceux qui le souhaite ^^

renaiku · November 15, 2019, 10:06am

Ah oui, un pare-feu ca serait une bonne idée.

J’annonce que je suis officiellement sur le service qui s’occupe de tous les devices low-cost du genre magichue, magic home, LED magic color, ledmagical, etc … (et tous les devices qui sont sur un module wifi HF-LPB100 du coup)(fwi: ils tournent sur FreeRTOS )

Comme ces devices ont un routeur intégré, je me demande si ils peuvent servir de répéteur wifi ca permettrait d’avoir du wifi a 100% partout dans la maison !

J’ai vu en regardant dans l’appli android qui peut les contrôler, qu’on peut leur assigner une « room ». J’ai pas encore déterminé si c’était dans le device ou la DB du téléphone que l’info était enregistrée.

EDIT:
En lisant tout ce que je pouvait sur ces périphérique, j’ai vu cette superbe idée: demander a VLC la couleur moyenne de l’image sur l’écran, et l’envoyer à l’ampoule:

github.com

vikstrous/zengge-lightcontrol/blob/master/control/atmolight.go

package control

import (
	"fmt"
	"io"
	"os"
)

// To use this feature create a pair of pseudo ttys with
// `socat -d -d pty,raw,echo=0 pty,raw,echo=0`
// This creates a pipe that VLC can write to and we can read from. It's usually
// found at `/dev/pts/2` and `/dev/pts/3`. Feed one end to VLC and the other to
// this script. VLC will send the "average" color of the scene to us and we can set
// the color of the lightbulb based on it.
func (c *Controller) AtmolightDaemon(pty string) error {
	file, _ := os.Open(pty)
	defer file.Close()
	for {
		// We read exactly 19 bytes at a time continuously because
		// that's how the atmolight protocol works

This file has been truncated. show original

renaiku · November 17, 2019, 1:33am

Pour le moment j’ai pas trouvé comment broadcast alors le temps de développer les features je fait un send sur les 256 adresses 192.168.1.x

J’en profite d’être sur le front et demander à @pierre-gilles qu’on commence à faire très attention car chaque Integration réinvente la roue sur le front … Y’a pas vraiment de composant générique pour un « device » par exemple et j’ai vu beaucoup de répétition entre chaque Integration. J’ai aussi remarqué que plusieurs mot communs, comme par exemple roomLabel: "Room", sont redéfinis pour chaque intégration. Il faudrait commencer à prévoir à factoriser tant qu’il y a moins de 10 intégrations, car après ça sera la jungle non ?

Après, rien n’empêche une Integration de faire un « Device.jsx » rien que pour elle pour des besoins particuliers.

EDIT:
Je viens de bosser une journée entière … et je trouve un package qui fait tout ce que j’ai fait … mais en mieux

Bon ben du coup je vais l’implémenter dans le service à la place de mon code …

pierre-gilles · November 18, 2019, 9:52am

Effectivement, jusque là il n’y avait qu’une intégration qui gérait des Device donc on avait qu’un fichier Device.jsx, après là on commence à avoir plusieurs intégrations donc ça fait sens de les fusionner et de faire des composants génériques

N’hésite pas si tu travailles sur le sujet à proposer une PR, ça sera avec plaisir

Bonne chance pour ton service et n’hésite pas si tu as des questions !

renaiku · November 18, 2019, 10:41am

Ca marche. J’essaye de comparer pour le moment les répétitions entre les autres intégrations et la mienne. Je proposerais une PR dès que je suis capable d’avoir au moins une feature controlable depuis l’UI.

Reno · November 18, 2019, 1:10pm

J’en suis arrivé à la même conclusion en travaillant sur l’intégration de capteurs dans le module Zigbee2mqtt d’@AlexTrovato.

Je peux participer à la PR si besoin car je pense que ce serait bien d’avoir un développeur de chaque service qui y participe, afin de faciliter la mise en oeuvre une fois qu’elle sera validée.

pierre-gilles · November 18, 2019, 1:26pm

Je suis d’accord! Après pour parler de Device, en regardant le code je l’ai déjà fais dans « components/device », il faut juste l’appliquer dans les service qui ne l’utilisaient pas encore, mais le travail est déjà fais

Reno · November 18, 2019, 2:14pm

Cool !
Si il y a déjà une base et qu’il n’y a « plus qu’à » adapter…

renaiku · November 19, 2019, 3:09pm

J’ai décompilé 5 apk android de 5 marques différentes d’ampoule wifi low-cost.

Comment vous dire que c’est le même code source. a 99.9%. Le seul truc qui change c’est le package du nom de l’apk dans les fichiers xml

Bon du coup mon service devrait pouvoir gérer une très très très grosse partie des ampoules low-cost. J’ai qu’un seul modèle pour tester malheureusement. Je fais donc un appel à ~~cobayes~~ témoins … Qui a une ampoule low-cost ?

renaiku · November 23, 2019, 6:10pm

J’ai un peu avancé, je fait circuler l’info en hsl entre le front et le back, et j’arrive a changer les couleurs de mon ampoule depuis l’UI
Sans%20titre%201

J’ai créé quelques constantes qui n’existait pas encore pour propager l’event EVENTS.DEVICE.NEW_STRING_STATE et j’ai un poil modifié le core de Gladys en rajoutant un fichier device.newStringStateEvent.js qui n’existait pas encore.

Ca avance doucement mais surement !
Je vais devoir penser à mettre un BottleNeck car j’ai l’impression que j’arrive très souvent à saturer l’ampoule avec mes setValue.

pierre-gilles · November 25, 2019, 10:46am

Génial c’est ce qu’il fallait faire!

Yes c’est souvent ce qu’il faut faire, je te conseille d’utiliser : https://www.npmjs.com/package/bottleneck

renaiku · November 25, 2019, 12:52pm

Oui super ! J’ai cru en voir dans le service Philips-Hue (ou xiaomi je sais plus), c’est de là que m’est venue l’idée d’en utiliser un.

J’ai aussi remarqué que dans les fichiers device.saveState.js et device.saveStringState.js:

saveStringState demande en plus un device. Est-ce vraiment utile ? Pourquoi ce n’est pas le cas dans saveState du coup?
saveState semblent avoir une meilleur couverture try/catch autour du commit dans la BDD.

pierre-gilles · November 25, 2019, 4:31pm

En fait saveStringState pour l’instant n’est utile que pour les caméras, et a été pensé indépendamment du saveState. Ca peut être repensé avec ce nouvel usage, si le device n’est pas utile on le vire Je suis pour accorder ça avec le saveState.

saveState a 2 opérations en DB, donc on utilise une transaction. Ce n’est pas le cas de saveStringState, donc pas besoin de la transaction.

Après, j’ai une tâche en tête, j’ai l’impression que la transaction du saveState amène des problèmes de performance / de locking de certaines tables en lecture (sur les installations avec beaucoup de device) donc il y a moyen que je retire cette transaction. (Cf Battle test device state creation · Issue #566 · GladysAssistant/Gladys · GitHub)

renaiku · November 25, 2019, 5:23pm

Ok ok.

C’est surtout qu’au début tout naïf que j’étais, j’avais rajouté un switch dans device.newStateEvent.js en fonction d’un typeof de la valeur de event.state, ca renvoyait vers saveState ou saveStringState.

J’avais donc créé une Error de type IllegalType au cas ou on essaye d’envoyer autre chose qu’un number ou une string.

Pour au final me rendre compte que le saveStringState était pas exactement pareil, et j’ai tout annulé en me disant qu’il y avait surement une bonne raison derrière ça x) !

Au final j’ai rien factorisé mais c’est tout aussi propre

Si le device est important pour la camera, autant le garder, ca gène en rien.

renaiku · November 30, 2019, 9:44am

J’ai ouvert un pull request: https://github.com/GladysAssistant/Gladys/pull/620

Avis aux amateurs, je prends toutes les remarques très volontiers

pierre-gilles · December 2, 2019, 3:12pm

Merci pour la PR! Dès que j’ai un peu de temps je regarderais. N’hésite pas à poster un message de ton avancement dans la PR, et à me prévenir sur la PR quand elle est prête à être reviewed pour merge!

renaiku · December 2, 2019, 10:40pm

Screenshot_3

Je penses avoir quelque chose comme ça fonctionnellement. Le css est pas joli, mais les 2 premières couleurs représentent le blanc chaud et le blanc froid.

Mon ampoule de test a 2 mode: Warm White et Color (soit l’un soit l’autre). Le Cold White est simulé par un bleu très clair (horrible), mais certains modèles ont physiquement cette 3ème « couleur ».

Est-ce que les possesseur de philips hue avec couleur pourraient me dire comment se comportent leurs ampoules ? Deux modes Warm et Color comme la mienne ?

Tlse-vins · December 3, 2019, 6:22am

Voici ce que l’on a dans l’appli.
Le bleu représente la couleur blanche, on est vraiment sur un blanc.
Le orange représente la couleur chaude on est sur un jaune orangé.

renaiku · December 3, 2019, 7:04am

Ok, pour les hue il semblerait qu’un gradient comme ça suffirait comme feature control:

Les hue auraient donc 2 « boutons » de couleurs. Le choix parmis les 10 couleurs de base (dont chaud et froid) et un gradient entre chaud et froid.

Je bosses pas sur le service hue mais je ferais évidemment en sorte que les fonctionnalités des couleurs soient suffisamment génériques pour être utilisées partout.