Ok alors j'ai trouvé mon bug et c'est de ma faute, en effet j'ai touché à la variable basetempo car je voulais un arrêt sur mes chauffage d'un durée de 6 minutes et oh malheurs j'ai mis 3 et en regardant ton code de plus près tu divises basetempo par 2 et du coup on a une valeur en 0,5 et donc comme on retire -1 a chaque fois on ne tombe plus jamais à zero et on boucle a l'infini.
J'ai corrigé en mettant basetempo à 4 et depuis plus de soucis, j'ai également réorganiser mes 10 chauffages en 4 zones de chauffage ( entre 4000 et 5000w par zone), sinon je délestais tout le temps car je n’enlevais pas assez de puissance en coupant 1 seule chauffage.
Depuis je pensais que tout roulais bien jusqu’à ce matin ou une zone était resté en délestage alors que le module n'y était plus, en gros c'est affiché cascado-cyclique et une zone (la dernière) est resté en délestage depuis 11h. en gros lors des délestage suivant comme la zone était déjà coupé il n'y touchait plus.
Donc le bug est que apparemment dans de rare cas à la sortie d'un délestage, le dernier périphérique délesté n'est pas remis à sa valeur précédente qui est en marche.
Ma suggestion : nous indiquons dans le plugin comment arrêté le chauffage, il suffirait peut-être de dire comment le remettre en marche ce qui éviterais de mettre en mémoire dans une array les états précédents car je pense que si par exemple tu délestes 4 fois de suite par la règles, il doit y avoir un cas ou une donnée est écrasée et pour retrouver un tel bug ça va pas être facile sachant que c'est difficile à reproduire.
(pour info, l'arrêt d'une zone de chauffage deslesté est dédié par un état virtuels détecteur d'ouverture, comme ça même si la zone de chauffage est en arrêt de manière manuelle, le détecteur passe ouvert par le délestage, ce qui coupe la zone de chauffage même si au final elle est arrêté. Je te dis cela car tu aurais pu me dire que j'avais éteins la zone en manuelle et que du coup, ça devenait sa précédente valeur)