Ma solution DIY de domotique

[destroyedlolo]

Très intéressant la partie avec directFB.
As-tu des Screenshots pour voir à quoi cela ressemble ?

Juste des trucs pourris avec des lignes, des carrés et des rectangles ... ben oui, je n'ai fait que les couches de bas niveau et je me focalise actuellement sur les échanges inter-threads.

De plus, directFB est une couche de bas niveau où tu dessines des primitives et non des widgets comme GTK ou QT. Donc le résultat dépend du talent (ou non ) du gars.

[Korhm]

J'ai regardé sur internet un peu, ca a l'air pas mal niveau optimisation, mais effectivement il faut avoir du talent, ce qui n'est pas mon cas.... (Déjà qu'en design web...)

Par contre, pour ma part je préfère quand même la méthode d'un server X avec chromium ouvert en mode kiosk. Certes ca demande plus de ressources (mais je l'héberge sur un serveur HP, et non un Raspberry), mais ca a l'avantage je trouve de pouvoir avoir la même interface depuis n'importe quel navigateur, notamment une tablette.

Mais si quelqu'un connaît un navigateur Linux plus light que chromium, je suis preneur

[destroyedlolo]

Par contre, pour ma part je préfère quand même la méthode d'un server X avec chromium ouvert en mode kiosk. Certes ca demande plus de ressources (mais je l'héberge sur un serveur HP, et non un Raspberry), mais ca a l'avantage je trouve de pouvoir avoir la même interface depuis n'importe quel navigateur, notamment une tablette.

Je n'ai pas de problème de ressources sur le BananaPI , mais installé X demande beaucoup de packages, donc des maj plus lourdes.
En plus, je ne connaissais pas DirectFB donc ... c'est plus fun

Mais si quelqu'un connaît un navigateur Linux plus light que chromium, je suis preneur

Sur mes antiquités les plus limitées, j'utilise Midori, mais il est un peu à la ramasse niveau CSS. Le Javascript passe pas mal par contre.

[destroyedlolo]

Bon, j'ai bien avancé sur mon Séléné
Fonctionnent :

• toutes la mécanique Lua
• Bas niveau DirectFB
• réception des messages MQTT
• variables partagées
• notifications inter thread (par eventfd)
• Timer (timerfd)
• boucle d'attente

Bref, c'est bon, je peux commencer à développer le tableau de bord lui-même

Je ne connaissais pas eventfd et timerfd qui simplifie grandement le dev de ce genre d'application par rapport aux classiques sémaphores et timers car tout passe par des filedescriptors classique ; c'est beaucoup plus simple lorsqu'on attend des infos de plusieurs sources. Le blème est que c'est plus ou moins Linux-only ...
Je suis par contre un peu déçus par Lua (que je connaissais d'avant, mais pas l’interfaçage C) : ils ont beau dire ce qu'ils veulent, il y a quand même pas mal de limites lorsqu'on commence a faire des trucs compliqués, par fois des limites débiles. Par exemple, impossible de récupérer les filedescriptors pour les fichiers ouverts par la lib io : pas cool pour faire du poll() dessus

[destroyedlolo]

Ch'tit problème sur mon installation, la liaison TéléInfo avec le compteur EDF s'est interrompues (peut-être dû a une coupure réseau) ... et ça à foutu la grouille : Comme le démon ne lit pas d'info ... il ne publie rien sur le broker, et comme il ne publie rien, tous les souscripteurs restent bloqués
Bref, va falloir que je regarde pour ajouter un timeout (facile en C, faudra que je vois pour les clients Lua), mais surtout il devient plus urgent que génère des SMS d'alerte lorsque qq chose ne va pas ...

Bref, le dashboard passera après l'envoie d'SMS d'alerte ...

[destroyedlolo]

Et voila, c'est fait : Marcel connait une nouvelle section nommée Dead Publisher Detect. Par exemple :

Code : Tout sélectionner

*DPD=Dpd test
Topic=Test
Sample=10

Surveille le topic Test : si pendant une période de 10 secondes il ne reçoit aucune donnée, il envoie un SMS indiquant "un problème pour Dpd test".
Pour éviter de se faire spamer, Marcel mémorise le fait qu'un SMS a été envoyé et ne le fera plus jusqu'à ce que l'erreur soit résolue. Lorsqu'une donnée arrive enfin, l'erreur est effacée et un SMS de retour à la normal est envoyé.

La communication entre le timeout et l'envoie de SMS se fait par message MQTT sur un topic spécial : Alert/ . Le système est donc ouvert à toutes autres applications externes ... Domestik par exemple lorsqu'il détecte un disque défaillant sur une de mes machines (ce qui m'est arrivé ce W.E. ), voir même des arduinos ou des ESP pour des sondes déportées

Bref, même si ses autres fonctionnalités n'ont pas d'utilités pour vous, Marcel peut-être intéressant rien que pour envoyé des SMS si une de vos sondes détecte un problème

[destroyedlolo]

J'ai le plaisir de vous présenté version 3.0 de Marcel. Il est maintenant possible de créer des callback écrits en Lua qui seront appelés lorsque des messages MQTT sont reçus.

Exemple concret avec cette config :

Code : Tout sélectionner

*DPD=UPS battery charge
Topic=onduleur/battery.charge
Func=UPSBatCharge

A chaque fois qu'une valeur est reçue sur onduleur/battery.charge (qui comme vous l'aurez deviné, indique la charge de la batterie de mon onduleur), la fonction UPSBatCharge() est appelée :

Code : Tout sélectionner

function UPSBatCharge( topic, val )
	if val < 20 then
		Marcel.RiseAlert("Battery charge is critical", val)
	elseif val < 50 then
		Marcel.RiseAlert("Battery charge is low", val)
	else	-- Clear alerts potentially sent
		Marcel.ClearAlert("Battery charge is critical");
		Marcel.ClearAlert("Battery charge is low");
	end
end

On enverra des SMS lorsque la batterie passe en dessous de 50% et un second à 20%. N'oubliez pas que Marcel n'envoie qu'un seul SMS par alerte (sauf si elle est effacée par ClearAlert() ), donc pas de risque d'être spamé lorsque la batterie reste sous les 50%.

Voili, voila

[destroyedlolo]

Version 3.2 de Marcel sortie en particulier avec :

• correction d'un bug lié à la librairie Paho qui rendait le démarrage instable (ben ouai, paho n'est pas thread safe lors des soumissions)
• une doc un peu plus complète dans la page d’accueil du projet
• j'ai ajouté ... 2 scripts Lua d'exemple. Un particulier, un qui m'envoie un SMS lorsque mon installation photovoltaïque ne produit rien depuis plus d'1 journée (ben oui, je n'ai rien produit pendant mes vacances car le disjoncteur de production avait disjoncté le 1er jour )

Mon dashboart est quand à lui temporairement en sommeil : en fait, j'ai une tablette (chinoise premier prix) dont l'Androïd s'est corrompu. Comme elle est à base d'Allwinner A13, j'ai réussi à la faire booter sous Linux. Bref, j'envisage la recycler pour le dit dashboard car c'est un peu dommage d'utiliser un A20 juste pour ça ... J'attends qu'un adaptateur USB arrive de HongKong pour aller plus en avant.

[destroyedlolo]

J'ai fait quelques améliorations sur Domestik avec la génération de rapport personnalisés : voici par exemple ce que donne ma conso et ma production électrique



J'attends toujours l'adaptateur USB pour poursuivre avec le dashboard ...

[Korhm]

Bonjour,

bon finalement, je me mettrais bien à faire une interface directement dans le framebuffer. Mais je ne trouve pas beaucoup d'info sur l'Internet.... Et surtout le site directfb.org ne semble pas marcher.
Aurais tu quelques pistes pour moi ?