Attribution des types d'entrées binaires sur module Shelly Uni

Bonjour,

Je dispose de plusieurs modules Shelly-Uni dont je sépare totalement les entrées des sorties.
Les deux sorties pilotent des relais, tandis que les deux entrées me servent à remonter des informations. (En fonctionnement standard des Shelly, les entrées pilotent les sorties. Ce qui n’est pas du tout mon besoin)
Dans la configuration des Shelly, j’ai déclaré les inputs comme ‹ detached switch › afin d’obtenir l’indépendance ‹ relais/input ›. Mes 3 modules Shelly sont configurés de la même manière. Achetés en même temps, ils sont de la même génération (Gen. 1).

Dans HA, tout était cohérent il y a quelques mois. Mais depuis quelques temps, je retrouve des types d’entrées différents.
Pour certains modules, HA les considère comme ‹ event › (long/single). Ce qui n’a pas de sens, vu que ce sont des entrées TOR (capteurs de niveaux ou simples retour d’infos de contacts secs).
Pour deux autres modules, les entrées sont considérées dans HA comme des binary sensors. Ce qui est plus cohérent avec mon application. Par contre, je découvre que ces deux là ont une entité batterie… Qui n’existe pas physiquement dans les modules. Bref, c’est devenu le bordel…

Comment puis-je forcer mes entités à prendre le bon ‹ device-class › ?
J’espère ainsi pouvoir retrouver des informations cohérentes dans mes lovelaces.

En images :
Déclaration des entrées dans le module Shelly

Certaines entités arrivent sous forme d’event’ (ce qui pose problème dans le lovelace notamment)

lovelace
Ce ne sont pas des ‹ long push ›, mais des états d’entrées (le marche forcée est un bouton tournant situé au plus près de l’installation. Il permet de faire fonctionner l’installation si HA est HS.)

pourquoi certaines entités sont considérées comme ‹ event ›, d’autres en ‹ binary sensor ›, voir même comme ‹ battery › (3eme ligne).

Hello
ce qui est étrange c’est que tous tes ShellyUni ne se comportent pas pareil.
Perso je n’en ai qu’un qui s’est déclaré en binary sensor ;
As tu la meme version du firmware sur chacun ?

Bonjour,
Oui, c’est très étrange. J’essaie de trouver une raison, mais rien pour le moment.
Pour moi, il sont tous en Gen.1 (achetés en même temps au même vendeur). Mais comment le vérifier ?

Suite à ton message, j’ai revérifié les firmwares. Il ont bien tous le dernier : 20230913-114521/v1.14.0-gcb84623

J’ai presque envie de les supprimer de l’intégration, leur faire un reset usine et de les réenregistrer. Mais je crains de mettre le bazar et d’y passer des heures. Avec le risque que cela se reproduise d’ici quelques mois.

Il n’y a pas moyen de forcer un ‹ device-class › ?

Une adresse IP dupliquée avec un autre équipement ?
Je ne vois pas comment, par exemple, le shelly pourrait remonter une batterie.
Et un reboot ne fait jamais de mal, avant de chercher plus loin.

Re
Peut etre qu’il y a eu conflit au moment ou HA les as détectés…
le plus simple c’est de les supprimer de ton intégration, et de les redéclarer avec les mêmes noms, à la virgule pres, sinon, ils seront déconenctés de tes intégrations.

J’ai assez peu d’équipements Wifi. Il y a peu de risque qu’une adresse soit dupliquée. Je les ai d’ailleurs fixées suite à des pertes de couplage lors de reboot de la Livebox. Peut-être une piste…
C’est d’ailleurs à ce moment que je me suis penché sur cette problématique.

Oui, j’avais tenté des reboot des modules. Je viens d’ailleurs d’en refaire un. Mais aucune différence

Çà va finir comme çà… Mais en dernier recours. Je cherche à comprendre.

Quelques nouvelles…
J’ai eu beau désactiver, désinstaller, rebooter HA, ce module est resté égal à ce qu’il était : Pas d’information sur les deux entrées indépendantes. Uniquement les ‹ events › sont rafraichis au front montant des entrées. Ce qui n’est pas gérable dans mon cas.

Par contre, j’ai découvert que les deux autres modules Shelly (identiques), avaient également les entités ‹ event ›, en plus de l’état des entrées. (Je ne les voyais pas dans mes premières recherches, car je filtrais par le mot clé ‹ shelly ›, et que les entrées des deux modules qui fonctionnaient ne portaient pas le mot ‹ shelly › dans leur nom…).

A force de recherches, j’ai découvert que les entités du module incriminé existaient, mais qu’elles n’étaient pas rafraichies.

En cliquant dessus, on découvre qu’il sagit bien de ‹ binary sensor › et qu’elles sont désactivées

Il suffit de les activer par le curseur pour qu’elles deviennent visibles. J’en profite pour leur attribuer un icône plus adapté. Voilà !

Les entrées apparaissent maintenant correctement


.

Je n’explique pas pourquoi ce module s’est comporté différemment, ni pourquoi les deux autres ont toujours l’icône batterie. Mais mon problème est résolu.
Si d’autres ont ce soucis, j’espère qu’ils trouveront ici le moyen de résoudre le problème.