std:exception: 'Timeout'

[ROBBEJP]

Bonjour à tous,

 

HC3 montée et en test, juste 3 modules installés (Vanne Danfoss, FGS-222, Wall plug).

 

Le WallPlug me permet (en test sur cette HC3) de faire office de capteur manque d'eau pour ma pompe de forage (j'ai peu d'eau dans le puis, et il se trouve à sec très souvent).

Mon capteur manque d'eau à sonde n'est pas fiable car les électrodes sont souvent encrassée ... rien de mieux qu'un système qui détecte la conso car quand la pompe, pompe de l'air, la conso électrique chute de 50%.

Bref, cela marche depuis 4 ans sur ma HC2 sans pb.

 

Sur la HC3, j'ai repris mon code LUA (avec quelques adaptations) et marche nickel aussi... sauf que  (sinon, je ne ferais pas ce POST), au bout d'1 semaine la HC3 semble comme "rebooté" (mais pas un vrai reboot car toutes mes scènes ne sont pas relancée) et j'ai un message d'erreur sur les scènes censées être en cours.

 

Double question:

Ces messages d'erreur sont-ils une conséquence au "reboot" ? ou est-ce la source du problème ?

 

A noter, ce "problème" n'arrive qu'au bout d'une semaine. La scène fonctionne parfaitement bien toute la semaine.

 

Pour répondre d'avance sur la boucle while:

Je n'utilise pas les trigger car c'est un moteur de pompe très "instable" niveau consommation. Les retours d'état de consommation sont très fréquents (et volontairement augmenté depuis les paramètres) car il me faut une réactivité sans faille sinon ma pompe peu cramer ... (1200 balles quand même)

Quand j'utilisais les triggers, même avec un KillOtherInstance, celà arrivait que certain retour d'état passe à la trappe... j'avais à l'époque configuré un autre scénario de secours qui m'alertait si la conso n'était pas normal durant un laps de temps et je réagissait avec un pétard au cul  ... mais même 1min de pompage d'air et la pompe souffre dangereusement. Depuis que j'ai fais cette boucle, nickel confiance total en HC2 jamais eu de soucis.

 

 

Principe du code (somme toute basic):

Je vérifie toutes les secondes si la conso (dans l'exemple j'ai mis une lampe. Donc les valeurs de conso ne sont pas celles de la pompe) si elle se trouve dans la fourchette.

Si tel est le cas (car au démarrage de la pompe, la consommation peut se trouver dans cette fourchette), j'attends 1,5s pour revérifier une seconde fois ==> 1,5 s est le temps pour la pompe de stabiliser sa consommation électrique.

Double check, mais là je coupe le WallPlug car c'est que la pompe ne pompe plus d'eau.

 

Le code:

 

while true do

 

  fibaro.sleep(1000)

 

  local ConsoForage1 = fibaro.getValue(33, "power")

 

  if tonumber(ConsoForage1) >= 20 and tonumber(ConsoForage1) <= 50

 

  then

    fibaro.sleep(1500)

    local ConsoForage2 = fibaro.getValue(33, "power")

    if tonumber(ConsoForage2) >= 20 and tonumber(ConsoForage2) <= 50

    then

      fibaro.call(33, "turnOff")

      fibaro.sleep(5000)

      fibaro.call(33, "turnOn")

    end

  end

end

 

 

Merci pour votre avis.

 

 

[jjacques68]

donc visiblement ce code est dans une scène.

Il y a 5 heures, ROBBEJP a dit :

Je n'utilise pas les trigger

cela veut dire que ta scène se lance comment ?

tu l'a lances manuellement ?

 

pour les erreurs dont tu parles, je pense que il y un nouveau lancement de scène (comment je sais pas) alors que la précédente est encore entrain de tourner.

Le fibaro.sleep() est une catastrophe dans les scènes dans ce genre de cas.

 

là comme ça, je remplacerais ces fibaro.sleep() par des settimeout() et tu n'auras plus d'erreur, je pense...

 

il faut aussi que tu vérifies comment est le paramètre de gestion de la scène quand il y a un nouveau start (dans les onglets).

Je ferai en sorte qu'un nouveau déclenchement annule la scène précédente.

 

EDIT :

 

remarque :

Citation

Quand j'utilisais les triggers, même avec un KillOtherInstance, celà arrivait que certain retour d'état passe à la trappe

normal, il y a trop de variation de la mesure, les scènes n'arrivent plus à suivre.

Les scènes sont devenues le point faible sur la HC3.

il faudrait peut-être se rapprocher de GEA et de l'utilisation du RefreshState dans les QA.

Plus compliqué, mais tu pourras alors le gérer comme tu le souhaiterais à l'origine.

Modifié le 30 mai 2021 par jjacques68

[ROBBEJP]

Bonjour @jjacques68,

 

Merci de m'avoir répondu.

C'est effectivement une scène qui se lance automatiquement au démarrage de la HC3.

La condition de démarrage est celle-là:

 

{

  conditions = { {

      isTrigger = true,

      operator = "==",

      property = "start",

      type = "se-start",

      value = true

    } },

  operator = "all"

}

 

Après reboot, la scène est bien UP. Donc sur ce point, je dirais ... pas de soucis.

 

Quant au multi-instance, je ne souhaite pas justement.

La boucle While permet de s'en affranchir.

 

Moi je pense qu'il y a comme un cleanup de process qui s'exécute 1 fois par semaine car mes scènes sont down précisément 5 jours après.

 

Pour le settimeout, pas glop avec une boucle car l'attente est liée au process que tu souhaite différer, mais pas à la boucle.

Si je fais un truc du genre (si le module est ON alors OFF au bout de 5s):

while true do

fibaro.setTimeout(5000, function()

local deviceValue1 = fibaro.get(23, "value")

if deviceValue1 == true then

    fibaro.call(23, "turnOff") end

end)

end

 

Je me retrouve avec un cœur CPU à donf (au point, je pense, de finir par planter la HC3 si je n'arrete pas la scène) car rien dans le code me permettra d'indiquer à la boucle d'attendre 1s entre chaque itération (sauf si j'ai mal écris qqch... ce qui peut être possible).

 

Pour finir, concernant les QA, j'avoue ne pas maitriser suffisamment le sujet.

Si une âme sensible pourrait me "réécrire" mon code de protection pompe, cela me permettrais d'en prendre exemple afin de mieux appréhender la façon dont fonctionne le truc.

J'avais fais comme ça avec mes débuts LUA ... je pompais du code et si et là puis de fil en aiguille, j'ai fini par comprendre la philo...

 

Merci !

 

 

 

[jjacques68]

Je pensais plus a virer le while true do...

 

function mainLoop()

    local ConsoForage1 = fibaro.getValue(33, "power")
    if tonumber(ConsoForage1) >= 20 and tonumber(ConsoForage1) <= 50 then

        fibaro.setTimeout(1500, function()
            local ConsoForage2 = fibaro.getValue(33, "power")
            if tonumber(ConsoForage2) >= 20 and tonumber(ConsoForage2) <= 50 then fibaro.call(33, "turnOff") end
            fibaro.setTimeout(1000, mainLoop)
        end)

    else
        fibaro.setTimeout(1000, mainLoop)
    end
end

mainLoop()

 

[ROBBEJP]

Merci @jjacques68,

 

Je viens de tester dans une nouvelle scène (j'ai désactivé l'ancienne) et ça marche nickel.

Je vais surveiller si elle tiens plus que 5 jours celle-ci

En tous cas, grand merci !! sincèrement.

 

Juste pour comprendre comment on utilise cette fonction mainloop.

Pourrais tu commenter les lignes car j'ai du mal à saisir le concept d'écriture comme le mainloop() à la fin par exemple.

 

Merci encore !

 

[jjacques68]

je pense que ça devrait tenir.

Par contre j'ai pas compris un truc dans ton scénario :

 

Tu mesures la conso de la pompe -> OK.

Si elle est entre les 2 seuils tu attends 1.5 s -> OK.

Tu refais une mesure -> OK

Si elle est toujours entre les 2 seuils tu coupe la pompe -> OK.

mais pourquoi la rallumer 5 secondes après ? (que d'ailleurs je n'ai pas codé dans le code que je t'ai posté...)

[ROBBEJP]

Car la prise Fibaro se trouve sur un temporisateur qui fait boitier de démarrage de la pompe.

Il est réglé à 15min d'attente (le temps que le forage se remplisse) puis la pompe se relance jusqu'à avoir remplis le ballon tampon réglé à 4,5 bar.

A cette pression, le contacteur manométrique coupe l'alimentation (contacteur manométrique situé en coupure entre le boitier de démarrage et la pompe.

 

En gros:

Pompe ==> Contacteur manométrique ==> Boitier de démarrage ==> Prise Fibaro ==> Prise de courant.

 

Concernant cette fonction mainloop, peut-on faire des boucle imbriquées.

J'en fais sur ma HC2 comme du genre:

 

while true do

 

code boucle 1

 

while true do

code boucle 2

break

end

end

 

Comment on code ça avec la fonction mainloop, aussi, l'équivalent du break (pour sortir de la seconde boucle et retomber dans la première).

 

Merci encore !

 

 

[jjacques68]

c'est possible oui, sans forcement utiliser "break".

Tout dépendra des conditions qui te feront sortir de cette 2 ème boucle.

[ROBBEJP]

Ok good, je vais creuser ça

 

Par contre, tu pourrais m'ajouter dans le code le fait de rallumer 5s après stp ?

J'ai cherché ... et j'avoue encore avoir un peu de mal à comprendre le concept...

 

En tous cas, grâce à toi, j'ai déjà bien avancé.

 

Merci !!

 

[jjacques68]

oui c'est pas evident l'imbrication asynchrone  

 

j'ai pas testé, faut que tu essayes :

 

function mainLoop()

    local ConsoForage1 = fibaro.getValue(33, "power")
    if tonumber(ConsoForage1) >= 20 and tonumber(ConsoForage1) <= 50 then

        fibaro.setTimeout(1000, function()
            local ConsoForage2 = fibaro.getValue(33, "power")
            if tonumber(ConsoForage2) >= 20 and tonumber(ConsoForage2) <= 50 then 
            
                fibaro.call(33, "turnOff")
                fibaro.setTimeout(5000, function() 
                    fibaro.call(33, "turnOn") 
                    fibaro.setTimeout(1000, mainLoop)
                end)
                
            else
                fibaro.setTimeout(1000, mainLoop)
            end            
        end)
    else
        fibaro.setTimeout(1000, mainLoop)
    end
end

mainLoop()

 

[ROBBEJP]

ça marche nickel, pinaise, trop fort, du premier coup

 

Merci encore et bonne soirée !!

 

Bye.

 

[jjacques68]

et le CPU donne quoi ?

[ROBBEJP]

Niveau CPU, c'est calme.

Donc nous ne somme pas dans une boucle sans attente entre chaque itération.

 

J'ai toutefois ouvert un case chez FIBARO concernant le while et les sleep.

Ils me confirme il y avoir un bug entre LUA et le fibaro.sleep.

Par contre, j'adore leur suggestion de faire cela en scène bloc ... no comment

 

 

"Please try deleting this scenario and adding it again as a regular block scene. Sometimes on LUA might happen some bug that is hard to catch. Exception timeout means basically that time period in which a kind of interruption might show up has past. So it has something to do with this function "fibaro.sleep(time)". this is probably a reason but I would relly recommend just doing it on block senes. Instead of Fibaro.sleep use regular delay in block scenes and it should work."
 

Je vais surveiller la stabilité de la scène sur les jours à venir.

 

Merci encore @jjacques68
 

[ROBBEJP]

Bon, des news ... à ce jour tout marchait nickel.

Je me suis aperçu ce matin que la HC3 avait comme rebooté.

 

La nuance toutefois, la scène fonctionne toujours (ce qui n'était pas le cas avec mon code qui ne fonctionnait plus après ce reboot)

Ma question: est-ce que ce "reboot" (peut-être purement web server et non système complet) n'est pas pareil chez tout le monde ?

 

[ROBBEJP]

Réponse de FIBARO:

 

On Home Center 3 there is a watchdog which reboots your gateway automatically if some services are not working for 10 minutes. That is why Home Center 3 may just reboot without your knowledge.

 

Je suppose donc qu'un des services à planté ... avec juste 2 pauvres scènes en service...

Aieeeee. Pas question de basculer pour le moment me concernant

 

Une idée ? Dites moi si votre HC3 reboot également votre coté ou si votre usagetime dépasse les 15jours.

 

[henri-allauch]

Moi aussi cette NUIT à 00h15  Reboot complet

Modifié le 10 juin 2021 par henri-allauch

[Lazer]

J'ai eu un reboot, il y a 1 an, (avec un vieux firmware donc), et c'était clairement à cause de l'un de mes QuickApps qui faisait n'importe quoi. C'est à ce moment là que j'avais constaté le reboot.

 

Depuis plusieurs jours, j'ai basculé toute ma production sur la HC3, et je dois dire que ça fonctionne très bien, malgré les nombreux QuickApps qui tournent.

 

Après, 15 jours, c'est un nombre que je n'atteindrai jamais, vu que j'ai un backup auto chaque week-end (et tous les services sont automatiquement redémarrés)

[ROBBEJP]

Merci pour vos retours,

Alors me concernant il est quand même peu probable qu'un code foireux soit à l'origine de ce reboot (mis à part la boucle évoqué dans ce sujet) car je n'ai que ça qui tourne.

Comme je le dis, c'est une HC3 en TEST pour le moment.

 

Je vais encore une fois m'armer de patience car FIBARO m'indique que cela pourrait aussi venir d'une coupure d'accès Web (ma HC2 est connecté volontairement en RJ45 mais sur un point d'accès Wifi).

Why not que cela pourrait provenir de ça (genre l'interface NET0 reconnu comme down pendant n secondes et paf le reboot) ... à suivre.

 

Mais perso, pour le moment ma confiance est toute relative sur ce nouveau boitier même si toi Lazer tu indique une certaine positivité post migration.

L'approche est sensiblement différente avec des possibilités qui semblent ne plus être à utiliser (comme le fibaro.sleep et j'en passe) et pour des débutants qui étaient au final satisfait de la HC2 et qui arrivaient a en faire ce qu'il en voulait, aujourd'hui, "reset"  retape toi des documentations inexistantes... et passe y encore de longues heures car si ta HC2 crame t'es comme un con...

 

Heureusement qu'il y a ce forum et des gens comme vous qui nous viennent en aide.

Merci une nouvelle fois pour cela.

 

Bye.

 

 

[Lazer]

Tu devrais lire ce topic sur le forum officiel, c'est très instructif, et je pense que tu as exactement le même problème : https://forum.fibaro.com/topic/54552-scenes-crashes-without-an-error-message

 

En synthèse, le setTimeout (ou sleep) n'a rien à voir dans l'affaire, c'est juste que l'erreur redescend jusque là. Le bug se situe plus loin, dans la partie à laquelle nous n'avons pas accès. Difficile à situer précisément, mais il semble que toutes les pistes convergent vers les requêtes sur l'API de la box elle-même (puisque tout ce qu'on fait en LUA attaque l'API à un moment ou à un autre)
Et il semble bien ne concerner que les scènes, pas les QuickApps.

Perso comme je n'utilise plus les scènes (j'en ai seulement 2, qui se déclenchent ponctuellement et ne tournent pas en boucle, ça ne leur laisse pas le temps de planter).

En revanche j'utilise massivement les QuickApps, et c'est vraiment ultra stable (pour peu que ça soit bien codé, donc la responsabilité nous incombe)

 

Laisse tomber le support, ils sont complètement à coté de la plaque.

Ils ne savent répondre que des banalités, alors ça aide bien le débutant ou les box crashées, mais ils ont incapables d'aider les développeurs.

Et d'ailleurs c'est très bien ton câble RJ45, il ne faut pas utiliser le Wi-Fi.

 

Bref, résolvons tes problèmes :

• arrêter d'utiliser les scènes, je l'ai déjà dit plusieurs fois sur le forum, la philosophie depuis la HC2 a changé. Avec la HC3 il faut mettre nos efforts de développement sur les QuickApps, qui permettent de faire tout ce que font les scènes, et bien plus... et en prime c'est plus stable !
• que ça soit dans une scène ou un QuickApp, il faut utiliser pcall() pour protéger l'exécution d'un code, dès qu'on a un doute sur son bon/mauvais fonctionnement :
  • QuickApp : fonctions http:request(), tcp:send(), tcp:receive() et les classiques json.encode() et json.decode() (comme sur HC2)
  • Scènes : visiblement le code complet....

 

 

Et oui, la migration de la HC2 vers la HC3 est un process très lourd, il faut tout reprendre, ce n'est pas pour rien que j'ai mis exactement 1 an à le faire. Bon il faut dire que j'ai pas mal de codes LUA dans tous les sens, d'interdépendance entre tous les éléments de la maison, etc.

C'est vraiment pas l'exclusion/inclusion des modules qui est longue dans l'histoire, ça ne m'a pris que quelques heures (réparties sur 1 semaine, j'ai fait ça en douceur). Mais le codage des QuickApps, ça c'était long.

[henri-allauch]

@Lazer

 

Penses-tu que la mise à jour de valeurs dans des Child-Devices d'un QuickApp  par une application Externe ( Request Python ) pourraient avoir un lien avec le bug cité ci-dessus (  requêtes sur l'API de la box ) ?

Dans la trace de cette appli je trouve parfois 1 ou 2 Erreurs  sans incidence

Parfois une série plus importante de transmission en erreur. Et cela correspond à un reboot de la Box  Je me demande si cela peut être la cause, ou cela est simplement la conséquence de la box qui reboot. Pas facile 

J'envoi toutes les minutes la valeur de 15 sondes avec une seconde d'intervalle entre chacune

Avant j'envoyais directement dans la base de Domochart depuis la HC3 j'envoi dans des devices et laisse Domochats faire l'insertion dans la Base.

Modifié le 11 juin 2021 par henri-allauch

[Lazer]

Sans certitude....

Je ne pense pas que ton application externe cause plus de bugs que n'importe quel autre action.

Je veux dire, attaquer l'API depuis la box elle-même (code LUA dans un QA/Scène, module Z-Wave qui envoie son état), ou bien depuis une appli externe, dans tous les cas, ça passe par l'API HTTP, et après le chemin vers la base de données est le même.

Donc tous ces événements suivent le même chemin et produisent le même résultat.

 

En revanche, on a constaté depuis un petit moment déjà que trop d'écritures répétées finissent par saturer le tampon d'écriture, ce qui a pour tendance à figer la box (on le constate par l'interface Web qui ne répond plus).

La HC2 avait déjà ce comportement depuis la v4.

Depuis cette époque, j'avais pris pour habitude de limiter les écritures.... ou plutôt, d'écrire intelligemment.

C'est à dire, ne pas demander à la box d'enregistrer une valeur qui est identique à la précédente.

C'est pour ça que dans la très grande majorité de mes codes LUA, je commence toujours par vérifier la valeur existante (fibaro.getValue ou getGlobalVariable) avant de la comparer à la nouvelle, et ensuite, seulement si elle est différence, de demander l'écriture de la nouvelle.

De cette façon, je limite au maximum les écriture inutile.
Plusieurs avantages :

- évite la saturation du tampon donc le figeage de la box

- améliore les performances : j'avais fait un benchmark, je n'est plus les chiffres en têtes (et ça varie selon les optimisations de firmwares par Fibaro), mais dans l'idée : une écriture c'est 20 fois plus lent qu'une lecture. Si je vérifier ma valeur chaque minute, mais qu'en réalité elle ne change qu'une fois par heure, au final j'aurai un gain de performance = 60/20 = 3.

- limite l'usure de la mémoire Flash

 

Je ne sais pas si tout cela est réellement utile, mais j'ai envie de croire que oui, car d'une part c'est logique, et d'autre part malgré le grand nombre de VD/QA que j'ai eu, mes box ont toujours été relativement stables. Plus stable que les box de plusieurs forumeurs qui viennent se plaindre ici, et la différence c'est nos codes LUA.

 

Dans ton cas, pendant que la box reboot, il est évident que tu vas avoir des erreurs sur l'API. C'est une conséquence normale.

 

Par ailleurs si toutes les minutes tu écris 15 nouvelles valeurs, à mon avis ça ne va pas. Ta seconde d'intervalle n'y change pas grand chose.

Dans ton script Python, tu devrais tenter de lire la valeur avant de la modifier, comme décrit précédemment.

 

 

[henri-allauch]

Parfaitement compris, je pense que je vais plutôt faire mes écritures comme avant, directement dans la base de domochart car ces données n'ont pas d'utilité dans la box, elle me servent uniquement à suivre ( courbes à la journée  ) les T° des divers organes de chauffage par pompe à chaleur air/eau

Cela diminuera les écritures

Merci de tes explications 

[Lazer]

il y a 55 minutes, henri-allauch a dit :

Dans la trace de cette appli je trouve parfois 1 ou 2 Erreurs  sans incidence

Je rebondis juste là dessus.

A un moment donné, le serveur Web en face, c'est à dire le processus HCServer dans la HC3 qui expose l'API HTTP REST, n'a pas répondu dans le temps imparti. Pour une raison ou un autre (saturation en écriture à cause du tampon plein, bug quelconque, etc)

Ton application reçoit cette erreur, tu la traites, et tu poursuis l'exécution.

 

Et bien c'est exactement le même principe pour tous nos codes LUA qui tournent dans la box.

Je rappelle encore une fois que toutes les interactions avec la box passent par cette même API.

Donc les fameux api.get(), mais aussi les fibaro.getValue ou bien encore fibaro.call() qui toutes appellent en backend api.get()... ou api.post() api.put() api.delete() mais c'est pareil.

 

Et justement, je reviens sur la boucle toute simple de @ROBBEJP qui a crashé, il se trouve qu'elle effectue justement des appels à cet API par le biais de fibaro.call()

 

En interne, l'exécution du code LUA des fonctions mises à notre dispositions par Fibaro ne sont pas protégées.

Donc l'erreur remonte jusqu'à notre code LUA, qui le fait crasher, bien que ça ne soit pas de la faute des lignes qu'on a écrit.

 

D'où ma suggestion de protéger le code par pcall().

Dès qu'on a un doute, un bout de code qui a tendance à planter, il faut avoir ce réflexe d'utiliser pcall(), cela permet d'attraper l'erreur, de la traiter, et de poursuivre l'exécution sans crasher l'application (la scène ou le quickapp).

(attention aux fonctions asynchrones, qui ne sont pas protégés par la fonction pcall précédente... voire mon tuto)

 

Reste à savoir pourquoi les scènes sont plus susceptibles de planter que les QuickApps, ça on ne saura pas, ça se passe dans le code compilé par Fibaro.

J'imagine qu'il y a un certain niveau de mécanismes de protections dans les QuickApps, que Fibaro n'a pas (encore ?) implémenté dans les scènes.

Mais clairement, sur la HC3, l'accent a été mis dès le départ sur les QuickApps, donc ne perdez pas trop de temps sur les scènes.

Comme je l'avais déjà dit, à mon avis les scènes sur HC3 doivent être réservées à des scénarios basiques : un événements (trigger) => une action immédiate. En mode bloc (si on débute) ou code LUA, cela revient au même en fin de compte. C'est bien comme cela que Fibaro a pensé l'usage des scènes.

[henri-allauch]

Effectivement si lors de ma Requête  j'ai une erreur, je la signale dans mon appli, et je passe à la sonde suivante la seconde qui suit.

Donc si je comprend bien ce que tu dis je suis dans le cas du bug fibaro 

Idem alors pour les appli style Imperihome qui lisent des infos dans la hc3 ? 

 

Finalement plutôt q'une application envoi les données à l'api de la HC3, ce serait plus propre (comme pour Netatmo Par exemple) que ce soit le QA qui interroge la sonde au travers d'un php(api) ?

 

Pour le coté HC3 j'ai 0 SCENES et tous les appels http et json ont protégé par un pcall : j'ai en Mars suivi tes conseils, déjà préconisés sur la HC2 par Toi, @Steven et @Krikroff

Modifié le 12 juin 2021 par henri-allauch
Complément

[Lazer]

Oui, mais pas forcément.

Je veux dire, faire un polling ininterrompu de la valeur en interrogeant l'appareil ce n'est pas forcément super optimisé non plus, ça consomme des ressources (CPU RAM Réseau) pour rien en fin de compte.

Moins grave que de faire des écritures inutiles sur un disque/SSD, mais pas optimal non plus.

 

Si tu veux garder la logique de fonctionnement de ton installation, tu pourrais, dans ton script Python, commencer par vérifier la valeur du module, la comparer, et seulement si elle est différence, envoyer la nouvelle valeur vers la HC3.

Ainsi tu appliques la logique de ce que j'ai décrit il y a 2 messages précédemment, sauf qu'au lieu que ça soit un QA qui l'effectue, c'est ton script Python externe. Mais encore une fois, c'est strictement identique, les 2 méthodes exploitent la même API.

 

D'ailleurs j'ai un cas similaire, j'ai FHEM qui tourne dans une VM pour exploiter mes quelques devices EnOcean.

Au départ je voulais écrire un QA qui fait un polling régulier, puis je me suis rendu compte que c'était inutile, et que le push effectué par FHEM suffit bien. Ce n'est pas du Python mais du Perl, mais la logique est la même. Pour l'instant je fais un update systématique du device, c'est temporaire car je n'ai pas eu le temps de faire mieux pendant ma migration vers la HC3, mais je vais changer cela : essayer de modifier les lignes perl pour faire un test avant de modifier.

 

Précision : j'ai associé chaque sonde EnOcean à un QA. J'ai donc plusieurs QA, et chacun contient exactement 0 ligne de code, fichier main totalement vide. Difficile de faire plus simple

En somme, c'est comme les "Fake Devices" sur HC2, sauf que là c'est propre, chaque QA est un vrai module autonome.