Aller au contenu

Lazer

Administrateur
  • Compteur de contenus

    25 335
  • Inscription

  • Dernière visite

Messages posté(e)s par Lazer


  1. Ah je sais pourquoi... il faut injecter un fichier de config YAML différent dans l'ESP32

    Désolé j'avais oublié... je te prépare ça...

     

    Tu as fait comment pour trouver le bon connecteur à 4 broches pour le port CN1110, tu as la référence ? Si c'est la même marque ça doit être facile.

     

    Sur mes splits (récents) j'ai aussi le port CN110 sur lequel est connecté le module Melcloud, et aussi un port CN104 disponible, je me demande dans quelle mesure il pourrait être utilisé.


  2. Et bah dis donc, tu as joué à l'apprenti sorcier là !

     

    Intéressant ta trouvaille pour le port CN110, merci de l'info pour la régulation de tension.

     

     

    Mise en ligne de la version 2 du QuickApp, disponible au téléchargement sur le tutoriel de la 1ère page :

    • Ajout du pilotage de la vitesse du ventilateur
    • Ajout du pilotage de l'orientation verticale des ailettes (statique ou swing)
    • Ajout de la prise en compte d'une sonde de température déportée dans la pièce pour la régulation du thermostat

     


  3. C'est bizarre ce que tu dis là... car la dernière Stable date du 6 décembre 2023, alors certes ça fait "quelques" mois, mais bon... ça ne fait surtout que 2 mois.

     

    La prochaine fois que tu installes une stable, restes-y et surtout assure toi de ne pas installer une Beta en cliquant trop vite sur le bouton.


  4. Le Wi-Fi.... la raison pour laquelle je me suis débarrassé de tous mes Sonos il y a longtemps maintenant...

     

    Marantz ? Je ne savais même pas qu'ils faisaient du multiroom...

     

    Je pense que Yamaha MusicCast est l'écosystème multiroom le plus développé, largement plus que leur principal concurrent Denon Heos.
    Mais l'application mobile est certainement moins évoluée que Sonos, même si perso ça me convient.


  5. Ah désolé j'ai loupé ton message concernant le QA switch

     

    J'ai regardé, mais je ne comprends pas ce qui te pose problème ?

     

    Je ne sais pas si j'ai compris ce que tu cherches à faire, mais j'aurais procédé différemment :
    - Une loop infinie
    - les fonctions turnOn et turnOff activent une variable true/false

    - lors de chaque exécution, la loop vérifie la valeur de la variable, et si true, alors effectue l'action.

    Plus simple et efficace ainsi je pense.


  6. Sur le principe, je suis d'accord, mais .... ce n'est pas si simple, nous avons tous des usages différents.

     

    J'ai longuement expliqué cette histoire de taux d'autoconsommation sur le topic de mon projet.

    Si tu as la capacité de lancer des consommateurs pendant que le soleil brille (routeur solaire, chargeur VE programmable, pompe de piscine, chauffage, ou que sais-je encore) alors tu pourras améliorer ton autoconsommation.
    Sinon, bah... Il sera mauvais, comme la majorité des gens (je dis pas ça méchamment, c'est juste un constat de fait).

    C'est là que la domotique devient utile, elle permet de déclencher les consommateurs en journée, ce qui est difficile à faire à la main sauf à être retraité assis devant sa fenêtre toute la journée pour surveiller les nuages.


  7. Oui voilà tu l'as dit, "une commande" passée en string, pas un "nom de variable" manipulé en string

    Le truc, c'est que quelque soit le langage de programmation, tu ne peux pas jouer avec le nom des variables qui est défini lors de la compilation du programme, c'est à dire avant son lancement.
    Durant l'exécution du programme, le nom des variables n'existe même pas, ce sont juste des emplacements mémoires, à des adresses bien précises, que le CPU va aller lire/écrire.

     

    C'est pour cela que je t'ai indiqué qu'on utilise les Tables en LUA, on peut manipuler leur contenu à loisir avec des index.

    Ces index peuvent être de type numérique (entier à partir de 1 en LUA, ou à partir de 0 dans de nombreux autres langages), ou bien de type chaine de caractère (string)
    Et là, cet index de type string, on peut le manipuler, c'est tout à fait possible.
    Par ex :

    local myTable = {
    	myIndex_1 = "Hello",
    	myIndex_2 = "World",
    }
    
    for i = 1, 2 do
    	local ton_index_en_string_devant_le_prisunic = "myIndex_" .. i
    	print("nom de l'index : ", ton_index_en_string_devant_le_prisunic)
    	local value = myTable[ton_index_en_string_devant_le_prisunic]
    	print("valeur de l'index : ", value)
    end

    Ce qui se rapproche un peu de ce que tu cherchais à faire initialement, un peu plus lourd à manipuler, mais fonctionnel (j'ai pas testé ce bout de code donc j'espère qu'il n'y a pas d'erreur de syntaxe, mais c'est pour expliquer le principe)

     


  8. Alors je développe pas mal en Shell à mes heures perdues, mais le backquote (ou le $(...)) ne sert pas à évaluer le nom d'une variable sous forme de chaine de caractère, mais à évaluer une commande complète.

    Ou alors je veux bien un exemple où tu manipules le nom d'une variable, car il ne me semble jamais avoir vu ça en Shell.

     

    EDIT : après les scripts Shell ne sont pas compilés, mais interprétés, donc ça change beaucoup de choses, les possibilités peuvent être différentes.

     


  9. Ah oui ça, je ne dis pas le contraire... après on connait Fibaro, l'équipe de développement n'a jamais été capable de suivre les promesses marketing. Ils sont lents, et leurs box n'ont jamais été les plus ouvertes et évolutives qui soient.
    Pour ça, rien ne vaut les projets communautaires... aujourd'hui la mode est à Home Assistant.

    C'est une autre philosophie.

     


  10. Ce n'est ni lié à Fibaro, ni au LUA, mais au mode de fonctionnement des compilateurs de langage de programmation en général.
    Tu connais un language de programmation où tu peux manipuler le nom d'une variable et en évaluer son contenu ?

    En LUA, ce que tu peux manipuler, ce sont les noms (sous forme de string) des index des tableaux.

    J'aurais pu t'écrire un bout de code en sens là d'ailleurs, mais c'était plus lourd que la solution très basique que je t'ai proposé.

     

    D'ailleurs ta question n'a rien à voir avec les QuickApp directement, mais plutôt aux possibilités du langage LUA en général.

     


  11. Tu ne peux pas manipuler les noms des variables, il faut travailler avec des tableaux ("table" en LUA)

     

    Exemple de code, à tester :

     

    local ids = {
    	[1] = 1234,
    	[2] = 4567,
    }
    
    for _, ID_device in ipairs(ids)
    	print("Device under analysis :", ID_device)
    	local value = hub.getValue(ID_device, "power")
    	print("value_" .. ID_device .. " :", value)
    end

     


  12. Comme tu l'as bien compris, toute la rentabilité de ton installation dépendra de ta capacité à autoconsommer le maximum de ta production, donc c'est là dessus que tu dois travailler si tu veux affiner ton projet.

     

    JPME tu peux oublier, l'entreprise n'est pas fiable (aucune communication, paiements très en retards, etc) et ils s'orientent vers le système de batterie virtuelle.... comme Urban Solar, qui est plus sérieux, donc inspire plus confiance (je n'ai vu aucun client s'en plaindre)

×