22/11/2017, 10:56:13
Bonjour,
Est-il faisable, réaliste et raisonnable de développer un système d'alarme avec des composants KNX ?
Nouveau venu, je précise d'emblée que je n'ai aucune compétence en électronique, ni même pas encore le statut de 'novice' en KNX (que je viens de commencer à explorer systématiquement) et que je n'ai même pas encore installé la version didactique.
Par contre, analyse et programmation me sont familières.
La question évoquée en introduction se heurte à deux catégories d'arguments.
Premier contre, la question des assurances.
Si elle n'est pas pertinente sur le plan de la faisabilité, elle reste évidemment importante sur le plan de la protection à laquelle l'alarme concourt.
Par ailleurs, il n'est pas nécessairement judicieux de négocier une réduction de prime d'assurance eu égard à l'installation d'une alarme (agréée) parce que cela introduit le risque de refus de prise en charge d'un sinistre si on a oublié de la brancher, si elle était en défaut et qu'elle n'était pas en ordre d'entretien ou toutes autres conditions susceptibles d'aboutir à une exclusion de couverture.
Dans mon cas, le montant fixé de la garantie pour vol d'objets précieux est doublé en cas d'installation d'une alarme, dont l'existence ne doit pas être signalée, mais peut donc être revendiquée en cas de sinistre. La garantie contractuelle minimale est donc toujours acquise et il y a un bonus en cas de couverture par une alarme.
Pour le reste, ce n'est évidemment pas le sujet d'un forum KNX et en tout cas pas ma préoccupation dans cette discussion.
Je propose de ne pas en discuter davantage ici.
Second contre, la faisabilité technique.
Elle est généralement rapidement évacuée au nom de "l'insécurité", ou plutôt de la "moindre sécurité", laquelle n'est pas documentée et l’emporte systématiquement.
Bus KNX versus RS485
On trouve des commentaires affirmant que le bus KNX est moins sûr en matière de sécurité.
Moins sûr que ... quoi ? Que ... quel autre bus ? Et pourquoi ?
Le bus habituel en matière d'alarme est le bus RS485, qui ne me semble pas différer fondamentalement du KNX et n'est même pas blindé.
Les deux bus relèvent par ailleurs de l'automation en milieu industriel.
A première vue et sans aucune compétence électronique, je ne vois donc pas pourquoi on prétend que KNX ne serait pas un bus sûr ou tellement moins sûr que RS485 qu’il faille le disqualifier en matière de sécurité.
La communication avec les périphériques.
Les périphériques de sécurité soit sont fermés (càd utilisent des protocoles propriétaires), soit ouverts (utilisent des sorties dont les états sont 'usuellement' exploitables) ou encore mixtes (càd dire qu'ils peuvent être configurés et connectés en mode bus propriétaire ou en mode ouvert).
Exemples de périphériques ouverts, qui sont les seuls concernés ici :
- les sirènes AVS (sauf, pour chaque modèle, la version bus spécifique étiquetée 'HP' )
- les détecteurs externes Risco WatchOut
- les détecteurs Bentels
- tous les détecteurs d'ouverture et de choc (‘reed’)
In fine, ces détecteurs comportent jusque 3 contacts : alarme, auto-protection / sabotage / 'tamper', anti-masquage.
Les effecteurs sont eux aussi gérés par des contacts SELV.
Tous ces contacts peuvent à l'évidence être gérés par une installation KNX.
Les niveaux de tension et ampérage de ces contacts sont compatibles avec les capteurs et actionneurs KNX.
Alimentation
Outre l'alimentation KNX, il faut prévoir l'alimentation des périphériques.
Il faudra cependant faire attention à l'alimentation de ces périphériques et veiller à sérier des voltages compatibles pour simplifier l'installation.
Ces alimentations doivent être protégées et l'autonomie doit être assurée par le biais d'une batterie, comme dans les systèmes classiques.
Des solutions existent, que je dois encore étudier.
Installation
On peut centraliser une installation KNX dans un coffret protégé, avec une alimentation stabilisée et protégée par un système de batterie.
On peut aussi la décentraliser dans des coffrets satellites au même titre que ce que certains systèmes de sécurité proposent, pour autant qu'ils soient protégés et alimentés.
Logique et programmation.
Le problème principal me semble être celui de la 'logique'.
Elle est généralement programmée par le biais d'interfaces graphiques comme c'est le cas de KNX avec ETS.
Qu'elle soit répartie (KNX) au lieu d'être centralisée ne pose pas un problème en soi.
Dans mon cas, elle serait physiquement centralisée dans son coffret général, puisque tout le câblage a déjà été réalisé en étoile avec du câble pour alarme.
Elle semble surtout être moins puissante, moins profonde tant qu'on ne recourt pas à un superviseur ou à un générateur de script (?).
Je ne suis cependant pas certain que les modules logiques disponibles ne permettent pas de développer des imbrications équivalentes à celles proposées par les programmations proposées par les constructeurs d'alarmes.
Il me reste encore à explorer ces superviseurs, générateurs de scripts etc., et à en trouver éventuellement un qui soit compatible avec les besoins en compacité, consommation et fiabilité requis.
En conclusion rapide (et provisoire dans l’attente de vos avis) :
Y a-t-il des objections techniques incontournables que mon inexpérience KNX m'a amené à négliger ?
Merci pour vos analyses et avis.
Hemgé
Est-il faisable, réaliste et raisonnable de développer un système d'alarme avec des composants KNX ?
Nouveau venu, je précise d'emblée que je n'ai aucune compétence en électronique, ni même pas encore le statut de 'novice' en KNX (que je viens de commencer à explorer systématiquement) et que je n'ai même pas encore installé la version didactique.
Par contre, analyse et programmation me sont familières.
La question évoquée en introduction se heurte à deux catégories d'arguments.
Premier contre, la question des assurances.
Si elle n'est pas pertinente sur le plan de la faisabilité, elle reste évidemment importante sur le plan de la protection à laquelle l'alarme concourt.
Par ailleurs, il n'est pas nécessairement judicieux de négocier une réduction de prime d'assurance eu égard à l'installation d'une alarme (agréée) parce que cela introduit le risque de refus de prise en charge d'un sinistre si on a oublié de la brancher, si elle était en défaut et qu'elle n'était pas en ordre d'entretien ou toutes autres conditions susceptibles d'aboutir à une exclusion de couverture.
Dans mon cas, le montant fixé de la garantie pour vol d'objets précieux est doublé en cas d'installation d'une alarme, dont l'existence ne doit pas être signalée, mais peut donc être revendiquée en cas de sinistre. La garantie contractuelle minimale est donc toujours acquise et il y a un bonus en cas de couverture par une alarme.
Pour le reste, ce n'est évidemment pas le sujet d'un forum KNX et en tout cas pas ma préoccupation dans cette discussion.
Je propose de ne pas en discuter davantage ici.
Second contre, la faisabilité technique.
Elle est généralement rapidement évacuée au nom de "l'insécurité", ou plutôt de la "moindre sécurité", laquelle n'est pas documentée et l’emporte systématiquement.
Bus KNX versus RS485
On trouve des commentaires affirmant que le bus KNX est moins sûr en matière de sécurité.
Moins sûr que ... quoi ? Que ... quel autre bus ? Et pourquoi ?
Le bus habituel en matière d'alarme est le bus RS485, qui ne me semble pas différer fondamentalement du KNX et n'est même pas blindé.
Les deux bus relèvent par ailleurs de l'automation en milieu industriel.
A première vue et sans aucune compétence électronique, je ne vois donc pas pourquoi on prétend que KNX ne serait pas un bus sûr ou tellement moins sûr que RS485 qu’il faille le disqualifier en matière de sécurité.
La communication avec les périphériques.
Les périphériques de sécurité soit sont fermés (càd utilisent des protocoles propriétaires), soit ouverts (utilisent des sorties dont les états sont 'usuellement' exploitables) ou encore mixtes (càd dire qu'ils peuvent être configurés et connectés en mode bus propriétaire ou en mode ouvert).
Exemples de périphériques ouverts, qui sont les seuls concernés ici :
- les sirènes AVS (sauf, pour chaque modèle, la version bus spécifique étiquetée 'HP' )
- les détecteurs externes Risco WatchOut
- les détecteurs Bentels
- tous les détecteurs d'ouverture et de choc (‘reed’)
In fine, ces détecteurs comportent jusque 3 contacts : alarme, auto-protection / sabotage / 'tamper', anti-masquage.
Les effecteurs sont eux aussi gérés par des contacts SELV.
Tous ces contacts peuvent à l'évidence être gérés par une installation KNX.
Les niveaux de tension et ampérage de ces contacts sont compatibles avec les capteurs et actionneurs KNX.
Alimentation
Outre l'alimentation KNX, il faut prévoir l'alimentation des périphériques.
Il faudra cependant faire attention à l'alimentation de ces périphériques et veiller à sérier des voltages compatibles pour simplifier l'installation.
Ces alimentations doivent être protégées et l'autonomie doit être assurée par le biais d'une batterie, comme dans les systèmes classiques.
Des solutions existent, que je dois encore étudier.
Installation
On peut centraliser une installation KNX dans un coffret protégé, avec une alimentation stabilisée et protégée par un système de batterie.
On peut aussi la décentraliser dans des coffrets satellites au même titre que ce que certains systèmes de sécurité proposent, pour autant qu'ils soient protégés et alimentés.
Logique et programmation.
Le problème principal me semble être celui de la 'logique'.
Elle est généralement programmée par le biais d'interfaces graphiques comme c'est le cas de KNX avec ETS.
Qu'elle soit répartie (KNX) au lieu d'être centralisée ne pose pas un problème en soi.
Dans mon cas, elle serait physiquement centralisée dans son coffret général, puisque tout le câblage a déjà été réalisé en étoile avec du câble pour alarme.
Elle semble surtout être moins puissante, moins profonde tant qu'on ne recourt pas à un superviseur ou à un générateur de script (?).
Je ne suis cependant pas certain que les modules logiques disponibles ne permettent pas de développer des imbrications équivalentes à celles proposées par les programmations proposées par les constructeurs d'alarmes.
Il me reste encore à explorer ces superviseurs, générateurs de scripts etc., et à en trouver éventuellement un qui soit compatible avec les besoins en compacité, consommation et fiabilité requis.
En conclusion rapide (et provisoire dans l’attente de vos avis) :
- détection d'événements, d'attaques contre l'installation, de défaut de l'installation ou de l'alimentation :
OK pour les périphériques si on recourt à du matériel de sécurité (et même à certains capteurs KNX, semble-t-il). Le matériel de sécurité est en général moins onéreux que le matériel KNX et devrait être plus sensible (à contrôler).
OK également pour la 'centrale' si elle est dans une pièce protégée ou si son coffret est sécurisé.
- lancement d'une réaction (sirène, appel GSM, téléphonique ou internet, gestion de l'éclairage et autres scénarii) : OK.
- gestion de communication normée avec les centrales de surveillance reste à explorer mais ne m'intéresse pas.
- définition de zones distinctes, qu'elles soient géographiques (partie professionnelle versus privée, rez de chaussée, étage, garage etc.) ou logiques (protection périmétriques, présence versus absence, jour versus nuit, vacances) : OK
- temporisation, voire chemin d'accès au clavier etc. : a priori OK
- activation et désactivation de l'alarme peuvent être assurées par des claviers, clés, cartes et tous autres dispositifs d'identification largement disponibles en KNX, voire chez les fabricants de dispositifs de sécurité. Il faut juste, pour chaque périphérique, s’assurer de sa protection et voir si les infos sont censées être centralisées ou y sont stockées.
- la gestion à distance est gérée pars diverses solutions KNX et ne devrait donc pas poser de problème pour ceux qui le souhaitent.
- historiques d'incident, journal etc. : pas exploré, mais a priori pas hors de portée.
- gestion de l'installation : voir comment assurer le back-up et la documentation de l'installation, en fonction des moyens de programmation mis en œuvre.
- Alimentation de l'installation : a priori OK
Y a-t-il des objections techniques incontournables que mon inexpérience KNX m'a amené à négliger ?
Merci pour vos analyses et avis.
Hemgé