Backup d'un superviseur

[Jonathan007]

Je pense que le sujet à sa place dans la section ETS car dès que l'on est en pur KNX, c'est de l'ETS.

   

Le petit schéma illustre mon interrogation.

On s'en doute tous, le point faible d'un installation KNX est sans doute le gars qui est derrière l'ETS, ensuite l'alimentation et puis vient le superviseur (enfin, c'est mon avis).
Tous ce qui tourne avec un système embarqué avancé est susceptible de planter (je n'ai jamais dû redémarrer un Nokia 3310 ou une cafetière senseo contrairement à un android).
Je pense que les modules classique KNX embarque un système plus ou moins robuste contrairement à un superviseur qui doit embarquer un OS.

Donc, dans le cas ou l'on voudrait profiter de le puissance de son superviseur, il faudrait charger le bus KNX en faisant passer toutes les informations par ce dernier afin qu'il les traitent et renvoie les GA correspondant vers les participants concerné.
On double donc le nombre de GA par action (1 GA vers le superviseur et 1 GA du superviseur vers l'actionneur par exemple). OK.

Mais si ce superviseur part en cacahuète ? Est il possible d'avoir une communication pur KNX en backup. Celle que l'on aurait sans superviseur en somme, mais en plus basique. Avec un GA d'un participant vers un autre.
Une sorte de priorité dans les communications peut-être ? Et encore... il faudrait une info pour dire que tout est ok.

Cela pourrait aussi être un second superviseur (un pour la logique et l'autre pour la visu, mais qui pourrait remplir certaines fonctions au cas ou...). Le problème reste le même : l'envoie de messages au moment ou l'un est HS.

Merci pour vos retours.

[vf62]

Hello,

J'avoue que j'ai un peu de mal à comprendre ton besoin et la configuration que tu exposes (on double le nombre de GA par action ?)
As tu un exemple concret ?
Pourquoi utiliser des GA différents pour le superviseur que ceux en place en "pur knx" ?

De mon côté, je suis parti sur le principe que les fonctions core d'une maison comme allumer une lumière ne doit pas être totalement géré d'un superviseur, ou tout au moins, qu'un simple appui sur un bouton d'un interupteur permet d'allumer cette lumiere. Le superviseur est dédié aux fonctions de confort et d'automatisation qui, en cas d'indisponibilité, sont gênante mais n’empêche pas de pouvoir vivre dans la maison.
Du coup, le superviseur ne vient qu'en surcouche et utilise les GA standard et n'intervient pas en coupure complète comme tu le présente (1 GA vers le superviseur et 1 GA du superviseur vers l'actionneur par exemple)

Mais peut être que je suis hors sujet et n'ai pas compris ton besoin (et retour au debut de mon post )

[filou59]

Pour moi un superviseur : c'est de la supervision, ca sert a pouvoir modifier certaines choses comme des consignes de temp que l'on ne doit jamais changer a part pour de la mise o point, déclencher des modes de fonctionnement exceptionnels qui ne serviraient que très rarement.

Meme un simple crénaux horaire je ne le gère pas par le superviseur.

Comme je l'ai dit dans un autre post, la logique que certains mettent en oeuvre dans un superviseur peut très bien se faire via de l'apparaillage KNX

-Un automate WAGO / Logo avec module KNX
-Un Raspberry avec Codesys et la couche KNX
-Des Horloges et modules logiques qui vont bien.

Les 2 1ere solution seront un peu plus compliqué a mettre en oeuvre pour le commun des mortels, cela touche plus a l'automatisme industriel, mais l'avantage pour un automate WAGO/Logo c'est la fiabilité, après l'autre avantage c'est de permettre de transformer votre automate en passerelle multiprotocole (dans le cas du wago que je connais bien), mais aussi de baisser le cout des E/S

Un raspberry pourra etre considéré comme peu fiable a cause des prb lié au carte SD, mais en prenant les précaution adequat on peut être tranquille pendant des années. 
Après pour quel euros, on peut facilement avoir un backup de la carte SD mise en prod, ce qui permet de redémarrer en cas de prb sur une config saine en moins de 30s si besoin.

L'avantage du superviseur, c'est la simplicité de mise en oeuvre comparé aux solutions que je propose a base d'automate.

[cocothebo]

Alors moi j'ai (encore) aucune implémentation KNX mais pour répondre à vf62, je pense que Jonathan parle de 2 GA par action pour que quand tu appuies sur l'interrupteur le superviseur fait son processing complexe puis actionne ce qui va bien avec d'autres GA.
Ca permet de séparer les processing du superviseur des actionneurs.

Sinon pour la question initiale, si je voulais faire cela, j'utiliserais un module logique (à voir si ça marche dans ce cas) pour appliquer un masque de GA. Masque dépendant de la reception d'un "heartbeat" du superviseur.
En choisissant bien les masques, on peut faire que sans preuve de vie du superviseur, on renvoie les même type de GA que celles du superviseur ou des GA spécifiques du mode "dégradé" (ou si c'est possible faire une table de mapping etc.).

Le gros moins de cette solution (si c'est possible de faire ça avec un module logique), c'est qu'on recentralise tout ce qui est dépendant du superviseur sur le module logique qui devient donc critique.


Une autre solution serait d'utiliser des "capteurs" (quoi n'importe quel module de commande, je sais plus si ça a un nom) intègre un peu de logique pour envoyer des GAs différentes suivant la réception du heartbeat, mais je ne crois pas avoir croisé ce genre de matos (du moins du côté des interrupteurs par ex)


@filou59, l'automate WAGO ne revient pas plus cher qu'un truc basique quand même ?

[Kevlille]

Faut que je me penche sur l'histoire de l'automate Wago car actuellement j'ai serveur Loxone qui ne me sert que pour les modules logiques et un peu de supervision.

Comme je suis en train de passer sur Openhab pour la supervision (car je n'arrive pas a faire ce que je veux sur Loxone), le Wago pourrait être une solution. Par contre, il ne fait que du TOR? ou d'autre modules existent pour du dimming par exemple?

Je vais jeter un oeil sur le site wago

[filou59]

@filou59, l'automate WAGO ne revient pas plus cher qu'un truc basique quand même ?

J'avais déjà détaillé le prix de base, le plus rentable sera de choisir dès le départ cette solution afin de ne pas avoir de doublon dans son installation

750-889 - 490€ Automate KNX (Routeur)
753-646 - 259€ Borne TP1 KNX
750-600 - 12€ - Borne de Fin

C'est l'investissement mini.

Avec ca vous avez un routeur KNX, cela evite au minimum l'achat d'une interface IP (economie mini de 140€ par rapport a une interface IP)
Vous avez un gros module logique, je n'ai pas toute les ref en tete, mais un module logique ABB/S 1.2.1 coute 315€
Vous avez une horloge : Theben TR648 top2 RC coute 308€
Vous avez une passerelle modbus TCP.


Après si vous voulez faire du Dali , il vous faudra une borne 753-647 200€ + Alim 787-1007 82€
Une passerelle Dali TYA670D coute 353€


Pour des sortie TOR une carte 8 sortie 750-530 57€ + 5.59€*8 = 105€ (13€ / Sortie)
Une carte 8 Entrée TOR = 51€
Une carte 16 Entrée TOR = 86€

Si besoin on peut bien sur avoir des cartes analogique 0-10V, 4-20ma, PT100... , Enocean,  ou modbus RS232/485


Une solution a base de Raspberry + Codesys + KNX coutera moins cher, il faut compter 50€ (Codesys)+100€ (KNX) + 65€ pour le dongle de la licence (Prix en HT)
On pourra faire ce que fait un module logique, horloge, passerelle modbus TCP, RS232/RS485 (via l'ajout de convertisseur), Enocean...

Coté E/S, c'est un peu plus limité, il faudra passer soit par des modules d'extension.

[Jonathan007]

Hello,

J'avoue que j'ai un peu de mal à comprendre ton besoin et la configuration que tu exposes (on double le nombre de GA par action ?)
As tu un exemple concret ?
Ex : GA 1/1/1 Pression BP1 + GA 1/1/2 ON/OFF Lampe 1 -> Le superviseur reçoit l'info de pression, traite l'info avec d'autres données et actionne GA 1/1/2 au besoin.
2 GA pour une action. En KNX pur, ca donne du BP vers l'actionneur GA 1/1/2 ON/OFF, sans avoir le GA de pression BP.
 
Pourquoi utiliser des GA différents pour le superviseur que ceux en place en "pur knx" ? Sinon, on bypass le superviseur...

De mon côté, je suis parti sur le principe que les fonctions core d'une maison comme allumer une lumière ne doit pas être totalement géré d'un superviseur, ou tout au moins, qu'un simple appui sur un bouton d'un interupteur permet d'allumer cette lumiere. Le superviseur est dédié aux fonctions de confort et d'automatisation qui, en cas d'indisponibilité, sont gênante mais n’empêche pas de pouvoir vivre dans la maison. D'ou mon interrogation. Mais si la pression d'un interrupteur doit passer par une logique, il faut passer par le superviseur...
Du coup, le superviseur ne vient qu'en surcouche et utilise les GA standard et n'intervient pas en coupure complète comme tu le présente (1 GA vers le superviseur et 1 GA du superviseur vers l'actionneur par exemple). Comment le mettre en surcouche ? Pour moi, une surcouche c'est une couche au dessus, qui devrait donc avoir les même fonction, mais avec plus de finesse.

Mais peut être que je suis hors sujet et n'ai pas compris ton besoin (et retour au debut de mon post )

Meme un simple crénaux horaire je ne le gère pas par le superviseur. Je dispose d'une horloge KNX hardware avec 8 sorties. Mon superviseur en dispose de 50.
Les 8 sorties sont pour les choses plus essentiel, celles du superviseur pour le confort. Mais 8, c'est clairement pas assez si on veux se passer de superviseur.

Comme je l'ai dit dans un autre post, la logique que certains mettent en oeuvre dans un superviseur peut très bien se faire via de l'apparaillage KNX. Oui et non. Mon superviseur calcule la courbe du soleil et actionne les stores en fonction. (une station météo peut le faire aussi, je sais)

-Un automate WAGO / Logo avec module KNX
-Un Raspberry avec Codesys et la couche KNX. Le rasberry est un outil de développement, pas de production. Il dispose de contrainte de coût qui en font un produit fragile. Donc un point faible, comme un superviseur "commercial".
-Des Horloges et modules logiques qui vont bien. Je pense que le module logique de ABB ABA/S 1.2.1 dispose également d'un petit OS, donc également sensible... Et je suis totalement opposé à la dispertion des modules logique via divers participant qui embarquent cela. C'est du dépannage.


Un raspberry pourra etre considéré comme peu fiable a cause des prb lié au carte SD, mais en prenant les précaution adequat on peut être tranquille pendant des années. 
Après pour quel euros, on peut facilement avoir un backup de la carte SD mise en prod, ce qui permet de redémarrer en cas de prb sur une config saine en moins de 30s si besoin.

L'avantage du superviseur, c'est la simplicité de mise en oeuvre comparé aux solutions que je propose a base d'automate.

Alors moi j'ai (encore) aucune implémentation KNX mais pour répondre à vf62, je pense que Jonathan parle de 2 GA par action pour que quand tu appuies sur l'interrupteur le superviseur fait son processing complexe puis actionne ce qui va bien avec d'autres GA. Voilà...
Ca permet de séparer les processing du superviseur des actionneurs.

Sinon pour la question initiale, si je voulais faire cela, j'utiliserais un module logique (à voir si ça marche dans ce cas) pour appliquer un masque de GA. Masque dépendant de la reception d'un "heartbeat" du superviseur.
En choisissant bien les masques, on peut faire que sans preuve de vie du superviseur, on renvoie les même type de GA que celles du superviseur  ou des GA spécifiques du mode "dégradé" (ou si c'est possible faire une table de mapping etc.). Ouais, mais cela retarde les actions car le heartbeat ne se ferait pas à fréquence élevée sinon surcharge du bus. Ce qui va créer des latences... Par ailleurs, je ne pense pas que les participants puissent attendre un heartbeat pour renvoyer ou pas leur commande.
A moins que l'on joue sur le fait qu'il n'y ait pas de ACK. Mais je ne voit toujours pas comment dévier l'ordre initial vers un second GA...

Le gros moins de cette solution (si c'est possible de faire ça avec un module logique), c'est qu'on recentralise tout ce qui est dépendant du superviseur sur le module logique qui devient donc critique.


Une autre solution serait d'utiliser des "capteurs" (quoi n'importe quel module de commande, je sais plus si ça a un nom) intègre un peu de logique pour envoyer des GAs différentes suivant la réception du heartbeat, mais je ne crois pas avoir croisé ce genre de matos (du moins du côté des interrupteurs par ex)


@filou59, l'automate WAGO ne revient pas plus cher qu'un truc basique quand même ?

Je précise que je n'ai pas la science infuse et que ma façon de penser n'est peut être pas la bonne, mais ça en est une...
D'ou le débat...

Certains éléments n'ont pas d'autres choix que de passer par une supervision si on veut une habitation "intelligente". Mais cela doit rester viable en cas de panne.

[filou59]

Le rasberry est un outil de développement, pas de production. Il dispose de contrainte de coût qui en font un produit fragile. Donc un point faible, comme un superviseur "commercial".

Là tu te trompes, je travaille en milieu industriel, et on utilise des Pi depuis quelques années maintenant, en remplacement de PC industriel un peu "viello" qui tournait avec des vieux XP et des disques Flash IDE devenant plus cher qu'un PI. 
Pour d'autre appli on utilise des Pi afin de les utiliser en tant que passerelle de protocole en faisant tourné Codesys dessus.

En quoi le Pi serait plus fragile qu'un ordi classique ? 
Meme par rapport a un automate Industriel, si je n'ai pas besoin d'E/S je ne me pose pas de question.

Certaines société vendent des solutions a base de pi que ce soit pour du milieu indus et même du KNX, si le produit n’était pas fiable elles ne le feraient pas a mon avis.
Maintenant même certains automate fond tourner un Linux a coté de leur tache principale

Comme tu le dis le pi est un outil de dev a la base, ce n'est pas une solution clé en main, il faut parfois chercher un peu pour bien sécurisé la chose mais le gros avantage c'est la communauté qu'il y a derrière et qui a trouvé toutes les solutions au problèmes existant.

Je pense que le module logique de ABB ABA/S 1.2.1 dispose également d'un petit OS, donc également sensible... Et je suis totalement opposé à la dispertion des modules logique via divers participant qui embarquent cela. C'est du dépannage.

Si tu pars de ce principe il va falloir que tu reviennes a une installation électrique classique avec de bon vieux inter relais  ou télérupteur, car chaque participant KNX dispose d'une appli plus ou moins sophistiqué et qui peu être sensible , un participant peu ne plus répondre après une tentative de programmation ou même en utilisation normal.

Que tu te poses la question d'une éventuel panne est tout a fait normal, maintenant a moins d’être dans un environnement sensible ou la continuité de service est primordial (Bureau/Tertiaire...) les contraintes ne sont pas les même.

Par exemple inutile de prévoir une double alim redondante comme la MDT qui est parfois cité, il suffit de prévoir une 2nd alim en attente dans son tableau que l'on pourrait mettre sous tension via un départ distinct.
Dans le même style utilisation d'une solution a base de pi que ce soit un superviseur (Jeedom/openhab/Codesys+Knx) qu'est-ce qui empeche d'avoir un Pi en secours et ou le support de stockage* en secours avec l'image de la derniere config stable que l'on utilise.

*Carte SD/Cle USB/SSD

[Kevlille]

Salut Jonathan,

Je ne comprends pas trop ta logique des GA pour le superviseur.

Si tu lis ta GA d'action et ta GA de retour d'état vers le supervisieur (dans le cas d'un switch), il n'y a pas besoin de créer d'autre GA spécifiques pour le superviseur, non?

Le superviseur à juste besoin du retour d'état pour mettre à jour la visualisation et de la GA d'action pour déclencher l'action depuis le superviseur (simulation de l'appui sur le BP)...

Je dis des conneries?

[cocothebo]

Merci Filou59

Pour mon idée de "heartbeat", il n'est pas question que pour celui ci soit diffusé en continu, plutot genre toutes les 10s, 30s (?), bref avec un délai raisonnable pour ne pas saturer le bus et ne pas non plus avoir un risque de non fonctionnement trop long.

Après, le module logique "garde" la présence ou non du heartbeat, et il faut aussi une horloge ou équivalent pour que le module logique sache qu'il n'a pas reçu de hartbeat pendant X temps et donc basculer sur le second masque/autre mapping si nécessaire.
Bon après ça me semble quand même bien compliqué, même un peu du bricolage mais conceptuellement je me dis que ça marche.

Après pour la programmation de ça, ça reste de la logique booléenne à bien choisr pour faire le masquequi va bien.
Si on prend des GAs sur 3 niveaux, on a des GA du style X Y Z, avec Z sur 8 bits, donc X Y Z8...Z1
Moi je partirai sur le bit de poids faible pour faire distinction GA superviseur, GA actionneur; par exemple 1.1.2 pour superviseur et 1.1.3 pour l'actionneur.
On considère que l'@ de base est 1.1.2 et en applicant un simple OU avec 0.0.1 dans le cas ou on a plus de heartbeat, on passe de 1.1.2 à 1.1.3
Dans le cas ou le heartbeat a été reçu, on fait rien ou un OU avec 0.0.0 (ce qui revient au même).

Au départ j'avoue que j'imaginais que le superviseur envoie un heartbeat, mais en réfléchissant, il est plus simple que périodiquement le module logique demande si le superviseur est la, il faut donc une horloge ou un module logique pouvant envoyé périodiquement des trames (je sais pas du tout si ça existe). Evidemment, l'horloge ne doit pas être le superviseur.


Et maintenant que j'y réfléchis un peu plus, si on a pas trop de monde sur le bus, le module logique peut même par défaut envoyer sur la GA superviseur et le superviseur renvoie des réception son heartbeat.
Si le module logique ne le reçoit pas alors il bascule en mode "superviseur mort" (et avec un peu de logique on doit pouvoir même lui faire renvoyer la dernière commande avec la deuxième @ mais suis pas vraiment sur, j'ai pas étudié les possibilités des modules logiques).


Par contre tout mon truc se base sur le fait que le module logique puisse s'enregistrer sur toutes les GAs qui doivent aller au superviseur et ça je sais vraiment pas si c'est possible.

[Jonathan007]

Salut Jonathan,

Je ne comprends pas trop ta logique des GA pour le superviseur.

Si tu lis ta GA d'action et ta GA de retour d'état vers le supervisieur (dans le cas d'un switch), il n'y a pas besoin de créer d'autre GA spécifiques pour le superviseur, non?

Le superviseur à juste besoin du retour d'état pour mettre à jour la visualisation et de la GA d'action pour déclencher l'action depuis le superviseur (simulation de l'appui sur le BP)...

Je dis des conneries?

Le superviseur doit savoir quand il y a eu pression sur le BP afin de lancer son traitement et prendre action ou pas. Donc 2 GA. Un entre le BP et le superviseur et un second entre le superviseur et l'actionneur.
Tandis que en KNX pur, tu lie le GA d'action directement entre le BP et l'actionneur.

On ne parle pas encore des retour d'état dans ce cas-ci afin de rester simple.

[Jonathan007]

D'après vos réflexions, je dois constater qu'il n'y a rien de prévu pour palier au problème avec un système qui prendrait la main en cas de panne sauf en élaborant une usine à gaz au détriment de la fiabilité du système de base à cause de la complexité de la programmation.

Dans le cas d'une résidence, il serait en effet donc plus simple d'alimenter un superviseur de backup. A la limite, avec un heartbeat qui détecte dans le superviseur déconne et ferme un contact qui alimente alors le second superviseur. Ce serait du KNX pur. Mais bon, cela implique de dédoubler la programmation et implique un coût important si ce sont des superviseur commerciaux.

Mais ok, c'est une solution commercialement acceptable et automatisée.

J'eus espéré une solution plus "intégrée" au KNX.

[cocothebo]

Après dans l'absolu avec un module logique on ne peut pas faire la même chose qu'un superviseur, et ne garder que la partie affichage sur le superviseur?

Après moi perso j'aime bien l'approche avec automate industriel pour les traitements complexes si on veut avoir une disponibilité maximum. Normalement ces dits automate sont fait pour ne pas (trop) planter.

Ou si juste supervision dans du résidentiel, je suis d'accord qu'une PI ne plante pas non plus toutes les 10 secondes, quitte à faire comme tu le dis un système heartbeat qui reset le dit Pi si plantage (un watchdog en info quoi). Dans ce cas limite ya pas besoin de dédoubler, on a juste potentiellement la perte de la supervision et de ce qu'il contrôle pendant le temps de détection du plantage + le reboot.
Pour plus de sécurité, faut coir si ya pas la possibilité d'avoir sur le PI un OS qui tourne tout en RAM (par exemple piCore) et qui soit compatible avec ce qu'il faut faire. Ca permet d'éviter tous les pb liés à l'écriture sur carte SD, en gros même un redémarrage sauvage ne risque vraiment plus de corrompre l'image de l'OS.

[vf62]

si je prends un exemple concret avec mon couloir qui comporte un détecteur de mouvement, 2 circuits de lumieres : un pour les plafonniers et un pour les balises led en bas de mur.
Effectivement, je n'ai pas de GA direct entre le détecteur et les sorties des 2 circuits, le superviseur (jeedom) est entre les 2 et évalue selon des conditions (mode nuit par exemple) si il faut allumer les plafonnier ou les balises.
Mais si jamais le superviseur est HS, en secours, il y a un bouton à chaque bout du couloir qui permet d'allumer les plafonniers en pur knx.
et si le bouton est utilisé alors que le superviseur est en fonction, avec les retours d'état, il est très simple pour lui de gérer ce cas.

Au final, pas d'usine à gaz pour gérer le très rares cas où le superviseur est pas dispo et très facile à comprendre pour les membres de la famille.

Et concernant la plateforme du supervisuer, de mon côté, c'est sur une VM d'un ESXI sur un mini serveur qui héberge également d'autres VM pour la gestion et l'enregistrement des camera IP mais aussi pour d'autres petits services (comme une VM avec ETS installé dessus qui reste stable dans le temps)
La VM du superviseur est sauvegardée une fois par jour, et si problème, il est très facile et rapide de restaurer une sauvegarde

[Kevlille]

@Cocothebo

Avec les RPI 3B+, plus besoin de SD on peut booter direct sur un support branché en USB.

J'en ai un qui tourne H24 depuis quasi un an (avec un SSD M2 sur une carte fille branché en USB) et aucun plantage.... DOnc la solution RPI peut être robuste ;-)

[Jonathan007]

si je prends un exemple concret avec mon couloir qui comporte un détecteur de mouvement, 2 circuits de lumieres : un pour les plafonniers et un pour les balises led en bas de mur.
Effectivement, je n'ai pas de GA direct entre le détecteur et les sorties des 2 circuits, le superviseur (jeedom) est entre les 2 et évalue selon des conditions (mode nuit par exemple) si il faut allumer les plafonnier ou les balises.
Mais si jamais le superviseur est HS, en secours, il y a un bouton à chaque bout du couloir qui permet d'allumer les plafonniers en pur knx.
et si le bouton est utilisé alors que le superviseur est en fonction, avec les retours d'état, il est très simple pour lui de gérer ce cas.

Et si pas de BP par exemple vu qu'il y a un capteur de présence ? Car dans ce cas, je peux tout dédoubler. Les BP qui communiquent avec le superviseur et ceux au cas ou, en pru KNX. Ce n'est pas l'idée. Certaines pièces n'ont pas de hardware en backup. Je cherche une solution plus "universelle". Mais tu as cerné la problématique.

@Cocothebo

Avec les RPI 3B+, plus besoin de SD on peut booter direct sur un support branché en USB.

J'en ai un qui tourne H24 depuis quasi un an (avec un SSD M2 sur une carte fille branché en USB) et aucun plantage.... DOnc la solution RPI peut être robuste ;-)
Laisse moi faire un tour près de ton RPi avec un appareil photo... 
Juste a voir la partie alimentation, on voit que c'est light... Surtout si le RPi chauffe un peu. Ca peut fonctionner pendant qques temps mais ce n'est pas écrit noir sur blanc, contrairement à du matériel conçu pour un usage intensif.
Un peu comme pour les HDD RAID et Green...

[Kevlille]

@Jonathan:

Des utilisations "pro" des raspberry existent: https://proknx.com/fr/product/realknx-air-fr/ preuve que niveau robustesse ce n'est pas si mal ;-)

[Jonathan007]

@Jonathan:

Des utilisations "pro" des raspberry existent:  https://proknx.com/fr/product/realknx-air-fr/  preuve que niveau robustesse ce n'est pas si mal ;-)

Je pense que c'est plutôt de l'opportunisme. Ils ont trouvé là une solution linux embarqué plus abordable, car développé en masse.

Enfin soit. C'est un débat qui va tourner en rond et chacun défend ses positions. J'ai analysé le RPI dès sa sortie en 2012 et suivit le développement avant lors de mes études d'électronique. J'ai donc sans doute un autre avis sur la question.
Un peu comme Androïd ou iOS ou Télé Samsung ou LG...

[Kevlille]

Oui j'ai relancé pour te titiller mais je suis d'accord sur le fait que chacun voit midi à sa porte. Tout dépend de son niveau d'exigence ;-)

Pour le moment le RPI avec OpenHAB me convient mais ce choix évoluera peut-être en fonction d'hypothétique couacs