Hello @tou(te)s,
Je suis un peu coincé dans mon avancement, car j’ai des questions de base de noob auxquelles je n’arrive pas à répondre. J’ai besoin d’aide et de conseils, d’avis éclairés, bref d’un (ou plusieurs!) oeil extérieur 
, pour m’aider à prendre une décision sur les questions / remarques ci-dessous. Désolé en avance si c’est un peu long, j’essaye d’être le plus possible clair dans mon raisonnement
Maintenant que mon design est à peu près calé « esthétiquement » (ça tourne en statique et ressemble à ce que je veux pour une v1, affichage OK FullyKiosk sans scrollbar, etc…), j’ai des questions existentielles sur la façon de relier cette interface à Jeedom pour lui donner vie.
Il y a plusieurs façons de faire, de l’envisager, j’en vois 2 principales. Je vous les expose en détail ci-dessous, en gardant en tête qu’il va falloir trancher pour ensuite dérouler les modifs sur tout le dashboard 
Mon point d’entrée est la valeur de température de la pièce / zone, dans la première tuile tout en haut à gauche (plus tard celle de consigne sera visible juste à côté, j’ai voulu pour l’instant garder une valeur simple de température de sonde pour l’exemple…):
Je veux lier les 25 deg. C à Jeedom, pour avoir la valeur évoluer en Live.
Et donc 2 façons d’y parvenir (après avoir supprimé la valeur statique de mon code, conservé la <div></div> et conservé le style CSS à appliquer pour garder le rendu esthétique) :
1. La méthode "interface graphique" :
Je fait « clique droit » sur ma page de design, « Ajouter une commmande » (ou ce qu’on veut d’autre pour la suite) :
De là, je choisis celle qui m’intéresse (= température de la cuisine) :
Pour info je l’ai piquée depuis mon équipement thermostat, j’aurai pu aussi depuis l’équipement de ma sonde, je n’ai pas de préférence. Comme l’un (thermostat) affiche aussi l’autre (sonde), c’est la même dans Jeedom si je ne me trompe pas (même ID de commande = ici #554).
Elle apparait « non formatée » évidemment, en tout petit en haut à gauche de l’image suivante.
Donc « clique droit » sur l’élément, et « paramètres d’affichage » :
Puis j’applique une surcouche CSS qui va bien pour modifier le rendu (en prenant soin de cocher fond transparent, texte blanc, et masquer le nom…) :
J’obtiens bien ce que je souhaite (avec en prime l’accès à l’historique des valeurs au survol (et popup du core avec diagramme en cliquant dessus…) :
2. La méthode "code avec requêtes API" :
Cette fois, je n’utilise pas les outils graphique standard Jeedom, et je reprends mon code html en remplaçant la valeur statique de la <div> prévue dans ma trame par un appel API :
Donc, dans le code html de la page du dashboard, cela nous donne par exemple :
Traduction en quelques mots :
- Je fais un requête API toute simple d’une valeur via la commande
fetch(Url)
(pas trouvé mieux pour l’instant pour un code compact…).
- Conversion en
code json
(peut-être étape inutile ?)
- Insertion dans le html à l’intérieur de la balise
<t id="tempajax"></t>
Le résultat est identique visuellement à la méthode 1, oui, mais je perds pas mal au change (pour l’instant et sans code supplémentaire) :
-
je n’ai pas accès à l’historique (etc, normal puisque je fais juste un appel « brut » de la data seule). Pas forcément rédhibitoire pour un usage tablette familiale… J’ai suffisamment de moyens autres pour aller chercher les infos dans Jeedom si nécessaire, sur ordinateur par exemple.
-
la valeur ne change pas « en live » et nécessite un rechargement de la page (il faut une nouvelle requête pour récupérer l’info à chaque fois…). Cela doit pouvoir se modifier avec d’autres éléments de code. Ou pas, alternative possible en forçant dans FullyKiosk un rechargement de la page systematique après la sortie de veille (déjà testé), juste pas l’idéal, le mieux serait de fairre comme un cron avec une mise à jour régulière des valeurs (d’ailleurs faudrait-il : a / aller chercher la valeur, ou b / pusher la valeur ? Beaucoup de possibilités en code…)
Synthèse de ma réflexion :
Ces x2 façons de faire sont deux approches assez différentes, avec chacune ses avantages et ses inconvénients, de mon point de vue. D’autant que j’essaye de raisonner « à grande échelle » lorsque toutes les tuiles du dashboard seront peuplées, avec chacune ses multiples data…
- Méthode 1 : interface graphique
Avantages : plutôt facile et rapide à mettre en place, liée au core de Jeedom,
Inconvénients : moins précis pour le calage des éléments pour les maniacs comme moi (on les positionne à la mano), lourdeur des surcouches graphiques non nécessaires (ajout + multiplication des équipements, etc) qui multiplient les portions de code à interpréter par le navigateur, surdose d’infos pas forcement nécessaire (accès graphique historique, etc), obligation d’héberger dashboard sur le RPI en production, code source éclaté dans autant de popup à renseigner pour les personnaliser qu’il y a de data sur les tuiles, quid compatibilité du design si passage à Jeedom v5 ou v6 ?
- Méthode 2 : code avec requêtes API
Avantages : plus flexible, code allégé, indépendant du core pour la partie graphique, possible de délocaliser l'hébergement des html + CSS du design en dehors du RPI (en réseau local, ou même externe d'ailleurs avec le principe des requêtes API), code source regroupé au même endroit,
Inconvénients : besoin de compétences supplémentaires en code pour le refresh des valeurs (de mon côté en tout cas), possible lourdeur des multiples requêtes API à chaque chargement de page ? (à me confirmer ?),
Évidemment, j’aurai tendance à privilégier la méthode la moins gourmande en ressources in fine.
Pour l’instant, j’envisage d’héberger mon design sur le Jeedom, en laissant les pages de code dans les répertoires prévus.
Si de bonnes ames veulent bien se pencher sur mon sujet, je vous en remercie grandement d’avance !
Au plaisir d’échanger ensemble
