jjacques68

merci pour le SDK !! ben dis donc, je vois (physiquement) pas de différence entre le pas pro et le pro...

ben avec le SDK, je pourrais au moins savoir quelles trames font quoi... Mais j'ai pas. sur github, ça existe pour le modèle S20 (prédécesseur du Allone). ça avec ça que j'ai testé, mais rien... aucune réponse. j'espère avec wireshark chopper les trames que mon téléphone envoi vers cette boîte, et le port. Après je pense pouvoir me démerder... oh punaise mais on peut pas faire de l'UDP sur la HC3 !!!

ERRATUM, j'ai dit une bêtise. c'est le Orvibo Allone Pro que j'ai commandé. Le broadlink semble fermé de chez fermé niveau accès. Le Orvibo semble accessible via UDP sur le port 10000. Aucune doc officiel. J'ai contacté le support pour en avoir, mais je pense que je peux toujours rêver. Y a des pseudo script sur github en python, mais ça donne rien. Je sens que je vais me taper du wireshark et sniffer la com...

y'a encore plus jolie, on peut mettre la tête sur Off, on a un joli rond avec marqué off sur la HC3. Bon, la tête ne réagit pas à cette commande. Et garde la consigne précédente. Mais suffit de tricher et de lui envoyer 4° puis off, et le tour est joué

les têtes Danfoss font ça très bien, une fois par semaine elles font des allé/retour avec le press étoupe. Depuis que j'ai ces vannes, j'ai plus jamais eut de collement. Et en été elles sont fermées

c'est exactement ça. Et que pour ça. D'où mon hésitation à le faire, Mais je sens que je vais le faire...

@jang : waouh ! I must study this ... but it seems complex...

oui suis d'accord, la doc, pour bien comprendre : tu la lis dans un sens, puis dans l'autre, puis tu tournes l'écran de 90° et tu recommences. Quand tu as fini, tu sais plus ce que tu cherchais alors tu recommences...

@Nico : avec plaisir sinon, ben en fait ça marche super bien, le fait de passer par un QA de type thermostat. j'avais une tête en spare, je me suis amusé avec. Mais ça veut dire qu'il faut faire un QA thermostat pour chaque zone... ça sent le Parent/Child ça... En se servant du parent pour régler les zones. Mais, en fait tout ça c'est juste pour pouvoir avoir un vrai "Off" de la zone !! c'est quand même du lux !! Parce que le climat panel fait très bien le job. C'est les Danfoss qui n'acceptent pas le "Off" et qui foutent le bordel dans la logique. Je sais pas encore quoi faire, soit je garde en l'état, soit je refais tout. Mais alors il faudra aussi que je refasse l'interfaçage avec mon IHM sous Windev

hm, je m'étais posé la même question à l'époque. A part les VG, y a pas de remèdes miracles. sinon en détournant l'utilisation des fichiers dans les QA... J'avais fait un truc là-dessus : Mais c'est très lourd, je ne l'utilise pas. Vaut mieux copier/coller la fonction dans le QA

help : J'arrive pas à convertir cette argument à envoyer à la tête : ça c'est une copie de ce que j'envoi depuis l'outil REST, et ç a marche, mais j'arrive pas à le convertir pour le mettre dans une requete HTTP { "args":[ {"setpoints":[{"type":"Heating","unit":"C","value":"16"}],"mode":"Heat"}, {"type":"Minutes","value":15} ] } EDIT : j'ai trouvé : { args={ {setpoints={{type="Heating",unit="C",value="15"}},mode="Heat"}, {type="Minutes",value=15} } }

si c'est bon, je m'y prenais mal... et le QA thermostat réagit très bien suivant les modifications dans le climat panel (passage de consigne, changement de mode, ...) c'est marrant, quand on passe le pannel sur off, il envoie d'abord la consigne en cours et ensuite seulement il change le mode. ça m'embête j'ai l'impression de ré-inventer la roue...

sauf que j'arrive pas à piloter ces put... vannes l'API se met bien à jour, met la vanne bouge pas d'un milimètre.

bon ça a cogité sévère... J'ai juste dans ce résumé ? en espérant que ce soit lisible...

attends là je comprends pas ?

mouai c'est vrai que la tête se régule toute seule. j'ai essayé de savoir si on pouvait voir au moins la température qu'elle mesure, mais rien du tout.

yeuuu... ça c'est mignon

en fait le seul device qui sera présent dans la zone du panel, c'est le QA thermostat même. et comme tu dis, il fera le relais vers les têtes. on a un algo tout prêt pour la régulation avec une sonde ?

yapuka yapuka yapuka... faut que ça cogite encore un peu en tout cas merci pour ces explications !!

ça veut dire qu'il faut que je sorte les têtes des zones alors !! ben ça c'est que je fais déjà avec mon QA Heating Manager. j'envoi la consigne mini qu'accepter la tête (4°C) pendant un temps infini.

je teste demain...

non pas encore mais là tu me fais peur !!

oui je viens de voir, il fait rien du tout. Mais du coup ça aide pas du tout à réaliser le truc ! C'est même très compliqué en fait, car on a le panel qui envoi ses consignes sans réfléchir, et on doit avoir un autre système (le QA) pour faire la régulation ! Le tout doit cohabiter... et les linked device n'ont pas l'air d'aider non plus, du moins dans les cas des têtes danfoss. oulalalala ça fume dans ma tête...

oh putain !!! Si je comprends bien mes sondes de température dans les pièces n'ont aucun rôle dans la régulation de la température ? C'est les Danfoss qui fond ça elles-même en fonction de la consigne envoyé par le panel ? Mais alors pourquoi on définit le capteur de température principal dans chaque pièce ? Je pensais que c'état pour que le panneau de chauffage sache justement quelle température il fait ! Du coup je suis pas d'accord non plus avec ce que j'ai écrit roooooh punaise !!! c'est pour ça que j'étais jamais à l'aise avec ce foutu truc !! Et je comprends maintenant le rôle du QA thermostat. Alors si on en met un maintenant : Quand le panel envoi une consigne à la tête. Et que le QA thermostat mesure une température dans la pièce (donc via la sonde) supérieure à la consigne, que va-t-il faire ? Surchargé la consigne du panel ? éteindre complètement la tête ?

euh la je suis pas d'accord... si tu as ton programmateur qui doit déclencher 22 °C à x heure. Si la sonde de température mesure 24 °C, les têtes ne vont pas s'ouvrir !!